Clean kirki install causing intermittent 503 errors in wp admin

[mekshq]

Issue description:

On 2 different servers, we get the same issue. Even without the config (just a clean plugin installation), no other plugins, default WP theme, WP 5.1. Kirki causes 503 server errors when installing new plugins, saving menus, publishing pages, etc... The problem is that it's not crashing every time so this is something related to PHP resource usage as it is happening intermittently.

I think I've found the problem and I'm 99% sure it is caused by deprecated/filters.php When looking into the code, this part is obviously a duplicate, it applies some of the filters twice. When I remove it, the 503 issues doesn't appear.

if ( false !== strpos( $kirki_deprecated_filters_iteration[1], '-' ) ) { $kirki_deprecated_filters_iteration[1] = str_replace( '-', '_', $kirki_deprecated_filters_iteration[1] ); add_filter( "kirki_{$config_id}_{$filter_suffix}", function( $args ) { global $kirki_deprecated_filters_iteration; $kirki_deprecated_filters_iteration[1] = str_replace( '-', '_', $kirki_deprecated_filters_iteration[1] ); return apply_filters( "kirki/{$kirki_deprecated_filters_iteration[0]}/{$kirki_deprecated_filters_iteration[1]}", $args ); }, 99 ); }

When I print to see what kirki deprecated filters are hooked onto init, this is the list:

kirkiglobal/dynamic_css kirkiglobal/output/control-classnames kirkiglobal/output/control-classnames kirkiglobal/css/skip_hidden kirkiglobal/styles kirkiglobal/output/property-classnames kirkiglobal/output/property-classnames kirkiglobal/webfonts/skip_hidden

Version used:

3.0.38 (but maybe it applies to earlier versions too)

Using theme_mods or options?

Doesn't matter.

The best way to reproduce it is to install the plugin on a live website which has visits and try to add some random items to menus, create a couple of draft posts or pages, install several plugins, etc...

EDIT

Just wanted to say that my provided solution, unfortunately, doesn't work. While it makes sense to remove the code I pointed to, it doesn't resolve the 503 errors...

[aristath]

@mekshq the above code is basically only used if you're using a theme that is pretty old and never changed their code for Kirki in the past couple of years. Which theme are you using?

[aristath]

Oh I see now you mentioned the default theme... That's extremely weird. Kirki by itself doesn't really run anything until you add some fields to it. From that point on it all depends on how many fields, what kinds of fields, what features you use etc. But even then, on a simple cheap shared host where I do stress tests for Kirki I can use 1200+ fields with each one of them generating CSS & HTML on the frontend without any issues whatsoever. After that point my browser just crashes 'cause it's trying to load too many things. But the server never crashed for me, perhaps this is not at all related to Kirki?

[mekshq]

@aristath We started using Kirki for our recently published WP theme. I spent a lot of time trying to isolate this problem, and as I said, it happens even without config assigned. That's the first thing I did, removed config. So no fields/controls at all. Then I deactivated all plugins, then I switched to a default WP theme. So it went down to just a plain plugin installation of Kirki. When I deactivate Kirki, everything works fine.

As it is hard to trace 503 error I cannot see which part of the code is causing the problem. My best guess here is that it is something related to default action hooks Kirki assigns, and doing specific actions in wp admin triggers that part of code and it exceeds server resources for a moment. And, as far as I can notice, these only happen on "save" actions which are called through admin-ajax.php, such adding items to menus, or publishing pages, or uploading images, for example.

[stevenselcuk]

I have the same problem but It occurs only "post-new.php" screen in my scenario and with Gutenberg editor when I switch to Classic editor everything works well with Kirki. I tried with kirki develop branch & WordPress repo version on WP 5.1.1 with an almost clean underscores theme without any plugin except Kirki & Classic Editor thing. So at this moment, I give up tracing.
I am on localhost with gulp-connect-php & browsersync & PHP72

[aristath]

hmmmm so issue is for both of you when using Kirki with the new editor? I'm not saying it's impossible, just that this has never been reported before and I have never encountered it myself either, so I was never even aware that there was an issue. @mekshq @stevenselcuk could you please both share as many details about your environments as possible? I'm assuming PHP 7+, latest WP etc. No fields, no nothing? Removing the config does not also mean that there are no fields... @stevenselcuk localhost on Windows? OSX? Linux? LAMP/LEMP/WAMP/MAMP/VVV, something else? If you both share enough details we may be able to pinpoint something that can make me replicate this... Or perhaps you have a test server somewhere where this happens consistently? If you do then having access to the dashboard and FTP would probably allow me to pinpoint the issue and fix this ASAP

[mekshq]

@aristath Here are the details:

Server OS Linux (Centos) PHP version 5.6.38 MySQL version 5.6.41 PHP execution time 1,800 s PHP memory limit 1 GB Max post size 64 MB Max upload size 64 MB

As I said in the previous messages, I have another server with a similar configuration and a bit fewer resources and I got the same issue a bit more frequently. On the other hand, on my localhost which is Windows 10 (XAMP), I never encountered this problem.

I can see these notices in PHP logs but I'm not sure if they are related to Kirki. PHP Notice: ob_end_flush(): failed to send buffer of zlib output compression (0) in wp-includes/functions.php on line 4212

The server gets busy for a moment, it throws 503 error and after a couple of seconds (or minutes), everything is fine. My best guess is that it is something related to memory usage and it can be related to Kirki VS WP 5.x. I will try both latest Kirki on WP 4.9 as well as older Kirki on WP 5 and I'll let you know.

I would be glad to provide a test WP installation for you, the problem is that it is hard to catch the issue as it does not happen every time. Let's say you need to spend 2-3 minutes in wp-admin doing specific actions and you can see it. Sometimes it throws the error immediately, sometimes after 30 seconds and 10 clicks, etc...

[stevenselcuk]

I have just downgrade Kirki 3.0.38 to 3.0.37 and now there is no problem. I am on Mac OS Sierra / PHP 7.2 / Wordpress 5.1.1 by the way.

[mekshq]

I can also confirm that I don't have this problem with 3.0.34. Just tried and it seems everything is working fine.

[mekshq]

UPDATE: Getting the same problem even on 3.0.34 it's just much less frequent

[aristath]

Just an update here, I'm still unable to replicate this issue. I even tried lowering PHP memory limit to 64M and all other config options to the bare minimum to run WP, then added about 120 controls in my customizer and made them output CSS in the editor as well as the frontend with some pretty complicated calculations, field co-dependencies and anything else I could think of. So far nothing I do results in an error anywhere. :thinking: Is there a consistent way in any of your sites to replicate this? I'm sure we can fix the issue once we manage to replicate it and debug properly, but so far this seems to be a pretty inconsistent and elusive bug, one that I've never encountered.

[stevenselcuk]

@aristath I isolate the error in my scenario and it is probably not the same problem w/ @mekshq There is a conflict with add_theme_support( 'editor-styles' ); in modules/gutenberg/class-kirki-modules-gutenberg.php

[mekshq]

@aristath I can set up a clean WP install for you on our server. Just let me know what kind of access do you need and let me know the email where I can reach out to you with all the details.

[aristath]

@mekshq I'll need admin access to the WP dashboard and also FTP. You should be able to see my mail on my github profile. Also a workflow on how to replicate the issue on your test site will be necessary so I don't waste hours trying to replicate :+1:

[mekshq]

@aristath Email sent!

[aristath]

Thank you @mekshq for the test site.

It took 47 revisions to a page in order to get a single 503 error in the browser console. When I finally did get the error, I saw that it was from admin-ajax.php. Which does seem to agree with what you both described, an error occurring when a save action occurs or when something like changing menus etc happens since all these things trigger ajax calls in WordPress. I then happened to leave my browser on the posts screen (not editing a post, just on the posts list) and switched to my code editor for a few minutes to check what the plugin does in the editor. When I got back to my browser I noticed that there was another 503 error in the console, this time with no interaction whatsoever. It was coming again from admin-ajax.php, from the WP Hearbeat API. So that peaked my curiosity and I pasted this in the browser console, forcing WP to make a heartbeat request every second.

var i = 0;
var foo = function() {
    wp.heartbeat.connectNow();
    setTimeout( function() {
        foo();
    }, 1000 );
    i++;
    console.log( i );
};
foo();

I left that running and 10 minutes later there's still no error there with Kirki enabled. So it's not an issue with Kirki and the heartbeat API.

To be honest I'n not even sure this is even an issue with Kirki. 1 failure in 50 post updates could be anything, from server resources to a wp-core bug, to an issue with the default theme or an issue with kirki. I'll keep trying to debug this, but to be honest if it happens once every 5 minutes I'll never be able to pinpoint the issue.

[mapsteps]

Hello and thank you for reporting this issue.

We are closing most open GitHub issues with the release of Kirki 4 to start fresh with this major release.

If you are still running into issues after you have tested your theme with Kirki 4, please let us know so we can reopen the issue.

Please note that Kirki 3 is no longer actively supported. Moving forward, we will only provide support the very latest version of Kirki.

Thank you for your understanding.

Best, David