Trey

[Trey]

Thanks for getting it taken care of, one less thing for me to maintain!

[Trey]

The URL to the stylesheet isn’t changed. It’s the logo and favicon attachments, the theme expects them to be in a local directory.

If you walk through my last post you will see that, in fact, kleo_write_dynamic_css_file() is called any time an admin page is loaded when the ReduxFramework::_register_settings() method determines it needs to be.

It sets a flag to do an update here:
File: /kleo-framework/options/framework.php
Lines: 2212-2284

If I can find time I’ll try to set up a backtrace and post it later.

Install WP Offload S3 and upload a logo, you can add some debug output to the kleo_write_dynamic_css_file() function and see that it triggers every time an admin page is loaded.

[Trey]

Incidentally, the issue is here:

kleo/kleo-framework/options/framework.php line 450:

The method “set_default_args”, which is called from the construct magic method, sets “opt_name” to a blank string. This is altered in the subsequent filters in construct to contain what I’m guessing is the name of the activated theme (because mine is a child theme).

then on

kleo/kleo-framework/options/framework.php line 258:

it checks to see if that array value ($this->args['opt_name']) is empty, which it is not, so it continues to line 355, where it adds the admin_init hook to call the _register_settings method, which is where the framework determines if the CSS needs to be updated.

So, in fact, your comment that:
“The file is regenerated only after you re-save theme options or customizer.”

is incorrect. The file is regenerated if _register_settings thinks it needs to be on ANY admin page load.

[Trey]

To elaborate, the S3 plugin alters the file URL to point to S3, so it is a valid media resource, with an attachment ID, but the framework thinks that since it has an attachment ID, and the URL is NOT local, it must be wrong, so it tried to get the image URL again and flag the CSS for rebuild, when that happens, S3 again changes the URL to point to the correct file and the next time that an admin endpoint is loaded it goes through the process again. This could also be mitigated by only flagging the css for update when someone actually loads the theme options, instead of every single admin URL

[Trey]

No, actually after some more testing that didn’t work. The problem was that any ajax callback was triggering the file to be regenerated, so if any user used the header search, or facetwp, or loaded an admin page, the file was deleted and rebuilt. The issue was that sometimes another page would be loaded before Kleo was finished writing the new file. As I said in my last comment, the source of the problem was us using S3 to host our icon and logo. The check determines that those files aren’t local and flags the CSS for update. I just put the link to a local file there instead and it “fixed” the problem.

It would be easier to diagnose if when the framework determined that the CSS needed to be rebuilt due to a setting it thinks is “wrong”, it put up a message on the admin side explaining what triggered the rebuild, even if this was only done when debug mode was on. It never let me know that it expected those images to be local files, which could also just be added into the field description.

[Trey]

Ok, I tracked down where it happens. It triggers after admin-init, so even on the front end if there is an ajax call. In /kleo-framework/options/framework.php the _register_settings method triggers it when it’s checking for “wrong” media URLs. We serve ALL of our media from S3, so the check to see if its URL contains the WP_CONTENT_URL ALWAYS fails, meaning that it is constantly regenerating the file.

I removed the files and it solved the problem completely. I was able to check because if I pressed enter in the search box the dynamic.css file was never loaded (the live search feature uses ajax which triggers admin-init and deletes the old file), made it much easier to track down when I could replicate the problem.

[Trey]

I’ve been trying to track this down as well for the last couple of weeks. It seems completely random, none of the settings screens are open when it happens. We don’t have any caching plugins, and the directory is writable by wordpress. I guess something is triggering the file to be regenerated and the front end is getting loaded at that precise moment, before the file is finished saving. It seems that this could be easily fixed in the dynamic-css.php file by adding a file_exists check to the wp_is_writable check on line 29.

In the interim, I’ve just added this to my child theme, so far so good.

COPY CODE

if ( ! is_admin() && has_action( 'wp_enqueue_scripts', 'kleo_load_dynamic_css' )) {
    global $kleo_config;
    if(!file_exists(trailingslashit( $kleo_config['custom_style_path'] ) . 'dynamic.css')){
        remove_action( 'wp_enqueue_scripts', 'kleo_load_dynamic_css', 22 );
        add_action( 'wp_head', 'kleo_custom_head_css' );
    }
}

[Author]

Posts