Forum Replies Created
-
Posts
-
Hi Günter,
I would love to give the update a shot on our staging environment.
Yet we do NOT use the official plugin. We have our own feature toggle API and platform MU-Plugins which handle all of this. Our code simply renders out the required script Tag when our toggles are enabled.
If you could add a filter to the check I will be more than happy to implement it in the relevant case
Thank you Günter! We have this scheduled for around Easter to implement this into our DEV environments. I will get back to you as soon as I have feedback.
Hi @ismael,
thank you very much for your feedback and the quick fix.
What is the reasoning behind the decisions to hide the sidebar? Sounds like this was changed intentionally with one of the recent updates.
There are many settings within the Block Editor sidebar which are not accessible otherwise. Like category, author, all other custom meta boxes, etc. As I wrote, Plugin sidebars like the one from Yoast are unreachable as well.Or is there something else I missed how to get back access to this elements?
Best Regards,
JanYup, exactly that one. Or the Yoast button right next to it.
After Downgrading we still saw some CSS artifacts which caused just the Avia element toolbar overlapping the sidebar. But they were gone after flushing the browser cache / using DEV Tools with “Disable Cache” enabled.
Hey Mike,
perfect :-) I guess I missed that in the changelog then.
Thanks for pointing it out to me.Best,
JanHi @guenter ,
thank you very much for this. Sure, it will give us the option to work around the issue without patching the sources :-)
But as I believe you will roll out this (cool) feature to further components I would kindly ask for a real “fix”. As in “see if you can make the responsive feature work in a way that does not break existing css stylings”. As it is css specificity related there should be a reasonable way to actually solve this.
It will be a gamble in any other way where any new release might break existing pages. That wouldn’t be a good future.
Best,
Jan
For reference: We hotfixed the
cell.phpre-adding the old code. It seems to us that you do leave it in there just commented out for a reason ;-)So the grid_row/cell.php lines 602+603 looks as the following now solving the issues:
$element_styling->add_callback_styles( 'container', array( 'padding' ) ); // $element_styling->add_responsive_styles( 'container-padding', 'padding', $atts, $this, '!important' );But this is clearly just a temporary hotfix ;-).
Good Morning @guenter,
Just a follow up from my side. On Friday we actually changed our caching configuration to align with avia files being in wp-content/uploads. There was one particular thing which I would open up for discussion (again). We figured out that there are now several folders for enfold / avia content directly below /uploads/.
Am I correct that there are at least these folders?
./avia_fonts
./avia_posts_css
./dynamic_aviaConsidering that we require a reliable path to configure the caching for (consider /wp-content/uploads/enfold/*), this makes life quite hard. Especially if new folders are added from time to time. Like it recently happened with the avia_posts_css.
Would it be possible to at least group these folders inside one parent folder? This would allow one to easily catch all current and future(!) folders you create. With the current setup any cache exclusions would have “exploded” when you added the avia_posts_css folder.We also investigated the filter you mentioned and this would actually not solve the issue with new folders. So whenever you add a new folder we would need to add a new filter to align this with our folder structure. This does not really scale or work reliably.
Talking about filters, this would actually require one global filter which is then also reliably implemented for new folders – yet posing the risk when you miss that, that caching again explodes for custom configs. This filter could be responsible for creating the common parent folder.All the filter stuff seems kind of unstable due to the reasons mentioned. Yet I totaly understand that you hesitant changing the folder structures…
And sorry for all the ping pong. We needed some time digging into this and try to find a stable and scalable solution which doesn’t make you work and code more complex than it already is :-)
What do you think of this approach?
Best,
JanI just double check and you are right. Don’t know what went wrong in my DEV env … most certain stale folders from previous test runs with plugins.
Fun fact: There is actually one reference to this particular cache directory in the WordPress sources: https://github.com/WordPress/wordpress-develop/blob/1cf97a3c1479f90a86450f19bd361c71f4b999e3/src/wp-includes/rss.php#L721
Yet the code ist 14 years old ;-)If you can make the two additional filters work to allow paths outside the uploads directory, that would be amazing. And yes it’s on us to care for proper folder access rights and stuff :-)
Thank you very much for your patience and double checking this!
Best regards,
JanHi @guenter,
thanks for the explanation and the hint to the filter :-) I do get your reasoning behind the file naming and the versioning using query params. That makes sense. But I still haven’t given up the opinion that these files would be better placed in /wp-content/cache. Especially as I do not think that Elementor is a good reference for many things they do. But that’s another topic and one reason why we choose Enfold over another Theme + Elementor ;-).
Yet I especially considered @yigit s input regarding the /wp-content/cache folder not being there in “default” installation. Which is absolutely true. I took this for granted and traced back where my issue came from. The folder is being created when the Constant WP_CACHE is set to true.
So what about instead or in addition to adding a filter to control the output folder letting the presence of the WP_CACHE variable determine whether these files are created in /wp-content/cache or /wp-content/uploads ?
If you dislike introducing this as kind of a breaking change automatically, what about a filter controlling this? Like avia_store_generated_files_in_cache_folder which defaults to false.Personally I believe this might be a way allowing for a more fine granular control. What do you think?
Best regards,
Jan
Hey @jordan_s @Guenni007
will or is this fix already included in Enfold Core? I couldn’t find anything in the recent changelogs.
Thanks an best regards,
Jan
Hi Günter, this should work, if you say so :-)
But it is not an option for pages with page cache enabled or those who simply update to the new enfold version and didn’t know, that the had the issue. The database entry would only stop to grow but there is no chance to get it “back to normal”.
That’s why I would have expected some kind of cleanup run. Like the one we implemented by deleting all the error entries from the array.But it is just a suggestion. If you know for sure only a small group of people is affected by this, then a note within the Release Notes should be fine.
Best,
JanHi Günter,
sorry for the late reply. We were finally able to give it a test run.
We updated Enfold to 4.7.5 with our fixes disables: As expected, database and filesystem went crazy with the file generation.
Updating to your Beta solved the issues as expected.So I can confirm, that you code fixes this issue.
Still I couldn’t see any kind of databse cleanup. If there are old error entries for the header or footer scripts, they should be deleted as they could be massive considering the time this code was live.
Have a great day,
Jan@yigit: You are welcome! You should also update the code example for “Remove Post Navigation for a post type” in your docs.
/* Remove Post navigation for CPT */ function custom_disable_avia_post_nav_for_cpt( $settings ) { if ( is_singular( 'portfolio' )) { $settings['skip_output'] = true; } return $settings; } add_filter( 'avf_post_nav_settings', 'custom_disable_avia_post_nav_for_cpt', 10, 1 );Good Morning Günter,
Fix is applied and runnig smoothly on our production system. We will keep monitoring close, but for now I would say that it solves the issue with the “error-generating-file” entries.
As written previously: We have Object Caching DISABLED at the moment. So I can only confirm the fix for the database write issues at the moment.
Best regards,
JanAs this is one of the top Google search results for how to remove the Enfold Post Navigation / Previous / Next Buttons:
You should use this code with more recent versions of Enfold instead to prevent PHP Warnings:/* Remove Post navigation */ function custom_disable_avia_post_nav( $settings ) { $settings['skip_output'] = true; return $settings; } add_filter( 'avf_post_nav_settings', 'custom_disable_avia_post_nav', 10, 1 );As this is one of the top Google search results for how to remove the Enfold Post Navigation / Previous / Next Buttons:
You should use this code with more recent versions of Enfold instead to prevent PHP Warnings:/* Remove Post navigation */ function custom_disable_avia_post_nav( $settings ) { $settings['skip_output'] = true; return $settings; } add_filter( 'avf_post_nav_settings', 'custom_disable_avia_post_nav', 10, 1 );Hey Günter,
thanks for your quick response. It looks good so far on our staging servers with our workarounds disabled. Nice and easy approach by the way!
Personally, I would vote against the “alloptions” race conditions fix for object caching in Enfold (it’s not just redis) and prefer a clean implementation of the wp_cache API itself.
Having the alloptions fix within 3rd party code makes it harder to control our environment. We do deploy it ourselves for example and wouldn’t use it out of the Enfold code base.
But I know that it takes more time to add and test the wp_cache API implementation and assume this is just a temporary workaround :-)I will give your fix a test run in production tomorrow morning. Right now is peak traffic, so we cannot do anything experimental.
Have a great evening and thanks alot,
Jan
Thanks Günter.
You are very welcome and your open mind is highly appreciated :-)
Just as a little pre-warning: We will püem another topic regarding the merged files and file suffix today or tomorrow. While debugging this topic in depth, we were able to confirm, that there are still massive issues with database pollution. Even with no object caching in place. The latter only creates masses of files on the disk.
Best regards,
JanHey Günter,
you are absolutely correct. get_option uses wp_cache_get under the hood:
wp_cache_get( $option, 'options' );Considering the way the wp_options works, there are known issues with race conditions and the
alloptionsfetching / caching: https://github.com/pantheon-systems/wp-redis/issues/221Anyway, this means, that the solution to these problems is to add Object Caching support to your code. In this way, you can control when to update/flush your cache keys without relying on the WordPress options cache being flushed. Only if the object cache does not return anything because it is not used or empty, you could fallback to the default WordPress Options. In this cases there shouldn’t be any problems, because no object caching seems to be in place.
This should be quite a simple task. All you would need to do is using the Object Cache API before falling back to the WP_Options default when working with the css modules and merged files. After having this, you should be safe to remove the “advanced” option to generate single merged files as well.
This should be all you need:
If the
wp_cache_getcommand returnsfalse, fallback toget_option. Just make sure to add a proper caching group identifier:wp_cache_set( ' avia_merged_file_name ', 'enfold', $cached_file_name);$file_name = wp_cache_get( ' avia_merged_file_name ', 'enfold'); if ( false === $file_name) { $file_name = get_option( 'avia_merged_file_name'); }Do you think this is something you could add to the shortterm bugfix releases to add Object Cache compatibility to Enfold?
Thank you very much and best regards,
Jan
Jup, we tried that. Worked well.
But using WP-Redis also led to problems with the dynamic merging of only required styles. Enfold wasn’t able to reliable recognize new modules being activated or used. And thus their styles were missing in the avia-merged css.Sounds to me that both issues are very closely related. As far as I know, the status of the used modules is also stored as options, correct?
But still, as they are default WP Options, therer shouldn’t be an issue. For example, WP-Redis only caches transients as well as the WordPress Object Cache => https://codex.wordpress.org/Class_Reference/WP_Object_Cache
We didn’t see any other issue with options being wrongly read.If you have any more debug information, I would highly appreciate it. If not, we will have to do some debugging with activated WP-Redis.
Thanks and best regards,
Jan
Please find a minimal update for the German formal (“Sie”) files here. Based on Enfold 4.7.3:
http://www.mediafire.com/file/j30abpceal7whs4/de_DE_formal.zip/file
It fixes the strings for the built-in 404 page. These are informal in 4.7.3
Here is a working code solution for those searching for a temporary workaround. Afterwards WP-Rocket lazy loading works with Enfold. The logo will neither lazy-load nor disappear ;-)
/* Compatibility fix for Enfold Main logo with WP-Rocket Lazy-Load */ add_filter('avf_logo_final_output', 'mip_fix_enfold_logo_wp_rocket'); function mip_fix_enfold_logo_wp_rocket($logo) { return str_replace("<img","<img data-no-lazy=\"1\"",$logo); }Best,
JanHi @ismael will you ship a permanent fix with one of the next Enfold updates? Or do we have to keep the manual fix?
Best,
JanDear @victoria_d, we encountered the same issue and reported it to wp-rocket.
They asked us to open a ticket with you to have this fixed. Here is what I got from WP-Rocket. So the fix (one of the two possibilities) should be easy to apply:
The class=”logo” should be applied to the
attribute instead of being in a <span> attribute to be automatically detected and excluded from our LazyLoad option.
Or even simply, they could add a data-no-lazy attribute to this
. That way, most self-respecting lazyload solutions, will exclude that image from being lazyloaded.
@adman1180 Vielleicht hilft das: https://kriesi.at/support/topic/font-manager-handles-font-files-with-suffix-regularitalic-wrong/
Enfold erkennt nur Font Dateien, deren Dateinamen einer bestimmten Konvetion entsprechen. Passt der Suffix der Datei nicht, werden die Schrift Stile nicht erkannt. Ist nur ne Idee, falls es hilft. Einfach mal im Enfold Code nach “avf_google_fonts_style_definitions” suchen und die Namen mit den Dateien aus dem Google Fonts Paket abgleichen.
Grüße,
Jan
