Forum Replies Created
-
Posts
-
Yes I do mean that I have modified the patch even further beyond what is currently now available as the patch in question.
I don’t like the way that enfold chooses whether or not the layer slider is available in the logic, and furthermore I don’t like how we can’t change that with a child theme.It would be pertinent to be able to make this modification at the child theme level.
I have referred to a variation of this patch to get the layerslider parsed and display in my content, but every time that I install a new version of the theme, this patch will get overwritten.
It would be nice to be able to have a solution that works in my child theme.This is such a bad solution, adding more code on top of code we don’t want.
Please add a filter to remove the gravity forms styling to the next version update.Your latest response is unacceptable. Please review the entire conversation of the ticket everything is there.
In particular:Content mismatch: Missing embedded video
I’m sorry, if I am contributing to your project without payment, there’s got to be some sort of compensation for it. After all, I’m paying you guys for your code. It should only go that you somehow “pay” for mine.
Is there a place that I can submit a pull request for the change? I have corrected the embed code on the core parent theme (which will obviously break if it doesn’t get added in the next release).
It would be nice to be able to have the Advanced Layout Builder available for custom taxonomies, especially on the term pages editable Description box.
Is it possible to use a child theme and allow ALB show up in the taxonomy term description field without having to hack the enfold theme directly.There doesn’t seem to be any filters to allow this, but a simple code block with filters/hooks in the parent enfold theme would allow for us to add it.
I figured out that a locations plugin we were using was altering the title of the current page for use in a vCard option, and that somehow was affecting the megamenu titles.
I’ve since disabled the vCard option as we don’t use it anyhow, and that fixed this problem.You may close the ticket.
@Nikko can you please provide an example?
So:
1. why aren’t you guys sanitizing/accommodating the special characters in your saving process?
2. why aren’t you spitting back the changes that the users are using, and highlighting the special characters so they can make changes?
3. or, why aren’t you notifying the users of special characters as they create the page??You should be using a discovery process here, and your shortcode parser should be more robust here. This is why other page builders are more successful and why I use other page builders with all of my other clients. I am stuck using this theme due to the client’s willingness to learn something different.
Regardless……
First: you notify and block all special characters as they enter them.
Second: you allow people to send recommendations for specific characters they need, this will happen a lot at the beginning, and less over the course of time.You should be building your code in iterations that instead of trying to accommodate all of them at the beginning.
By slowly adding them over time, you allow yourself to acclimate to the special characters that people use.I hate to say it but this record in the postmeta table is redundant. There is a specific process that is well documented to avoid the autop method in the wp_posts content entries and it appears that enfold is simply unaware of this and not using it correctly.
I am having this issue as well. I wish we could disable the use of _aviaLayoutBuilderCleanData. It’s redundant, and proves that there is issues with the avia layout builder.
Yes unfortunately we have a firewall on our network that blocks any external traffic from specific locations outside the US.
You will have to access it from a proxy route that has an endpoint that resides within the US – my IT department will not change the firewall settings to accommodate anything outside of this scenario.@Ismael, what is the progress with this. If your wordpress developers haven’t replied by now, and there isn’t a fix in place, then they do not know what they are doing. ezFl0w is completely correct.
This is a serious issue, the wp_options table should not be used for this sort of purpose.
If anything, allow us to add a filter or action to that field that we can define in our functions file to add our own shortcode support in that field.
Well, if the shortcode in the copyright meta field for the image breaks the layout, then the customer shouldn’t put the shortcode that breaks the layout, into that field. This is no different than any other locations in wordpress where shortcodes can be inserted, but break the layout. It’s a “use if you know what you’re doing” kinda thing.
As for the copyright field on hover, I don’t have a concept of how that scenario is valid.
Would a pull request be helpful if I manage to figure it out, yet still retain the original functionality as well?
