Broken plugin after update to 2.6.0

@retetecugust – I’ve noticed you’re still on 2.5.5 – have you rolled back?
I have also noticed you are hosting your website with wordpress.com, and was wondering whether your issue was shared with @primathon above however it is not.

If you are having issues with 2.6.1, they must be a different cause.

After some digging, I found that it didn’t seem to have anything to do with WPEngine, but rather a security plugin that I wasn’t even running anymore.

Sucuri Security (and many others, I’m sure) have many options for hardening wordpress. One of Sucuri’s, and that they include in their one-click “Harden WordPress” button, applies an option that disables PHP execution in the /wp-content directory. It does this by writing an .htaccess file that sets a “deny-from-all” option to all PHP files in that path.

In my case, I had uninstalled Sucuri ~6 months prior, but the files were still there. Testing with a fresh install and only those two plugins confirmed that the behavior is repeatable, and that disabling Sucuri will also remove the offending .htaccess. No idea why some files were left behind in my case, but I had three different sites showing this issue.

Deleting the .htaccess files in /wp-content solved the issue immediately. In my case, the PHP denial ruleset was the only thing in the file; if you’ve got other directives in there, you probably don’t want to remove everything, just the bit about PHP execution.

Hi,

I rolled back since I needed to modify some files.
2.5 is working with no issues. My site is on the business environment of wordpress.com, so it is working almost like a .org. I do not have some features of the .com and I don’t have some of the .org, it’s a managed server. But I can modify most files – plugins and themes. I can’t see logs though, I have to ask them or maybe there’s a plugin for that – I will investigate.

It would have been nice to be able to stop this plugin from updating, until it is working. Since that is not available I had to install another plugin to control this.

I figured as much – no worries. I don’t believe server logs will be of much use in your case. I think WordPress is somehow aborting the ajax call pre ajax hooks. That’s all I can assume thus far, as it’s not disallowing PHP code in wp-content.

I’d be interested in working with you to solve your issue, if that’s ok with you.

In regards to automatic updates, WordPress can be configured to allow automatic updates of non-major releases. This is the setup of your site, not anything the plugin is doing. If you wish to disable this feature or exclude AceIDE from doing this, the following instructions should help:

https://www.wpbeginner.com/plugins/how-to-enable-automatic-updates-for-wordpress-plugins/

Regards,
Shane Thompson

I’ll need to dig this one out as well as I don’t have any left over security .htaccess rules in the wp-content folder but I would imagine that executing PHP inside this directory is something we weren’t doing in 2.5.5 or older versions which is why rolling back seems to be the fix in all our cases.

So now I’m off to hunt down why this is happening on all host environments I’ve tested and what is the common factor as some very greatly in environments, some are VPS/ nginx while others are cpanel/apache and not all are hardened the same way. In fact, I haven’t found one yet that works except when rolling back 2.5.5 or older.

Hi Philip,

The ajax handler did change from admin-ajax.php in the wp-admin directory to Ajax.php in the plugin directory, therefore under wp-content. This change happened in 2.6, so you are correct.

There must be something common with your setup, maybe a WordPress hardening plugin you use in all installs? I’d be surprised if it’s doing it on a non-hardened cPanel installation without it being the WordPress installation itself.

I eagerly await your results.

Thanks again to all

The blank scenario happened to me with 2.6.1 on all of the sites that I use the Divi theme with. I was able to rollback to 2.6 with no problems and it functions without issue. There is no common thread other than the theme as I have a site hosted on Siteground and others on GoDaddy and the issue exists either way. Don’t know if that’s helpful but thought I’d share.

Hmm that would be a curious edge case. What issues are you experiencing?

The issues thus far are common to both 2.6.0 and 2.6.1.

I think the issue with Divi might be caused by something else. One of my client sites runs that theme and I’m seeing the same behavior, but a different error.

POST https://domain.com/wp-content/plugins/aceide/src/Ajax.php - HTTP 500 (Internal Server Error)

Checking the server logs shows this:

PHP Fatal error:  Uncaught Error: Call to undefined function et_core_portability_register() in /websitename/wp-content/themes/Divi/functions.php:8940
Stack trace:
#0 [internal function]: et_divi_register_customizer_portability('')
#1 /websitename/wp-includes/class-wp-hook.php(286): call_user_func_array('et_divi_registe...', Array)
#2 /websitename/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters(NULL, Array)
#3 /websitename/wp-includes/plugin.php(453): WP_Hook->do_action(Array)
#4 /websitename/wp-admin/admin-ajax.php(44): do_action('admin_init')
#5 /websitename/wp-content/plugins/aceide/src/Ajax.php(23): require('/websitename...')
#6 {main}
thrown in /websitename/wp-content/themes/Divi/functions.php on line 8940, referer: https://websitename.com/wp-admin/admin.php?page=aceide

Looks like Divi sets some actions that fire on the admin_init hook, and when AceIDE tries to load that file, things aren’t quite set up right and the server chokes because it doesn’t know where the appropriate functions are located.

This one will take some digging to get to the bottom of… :/

Yeah this one sounds fun and complex.
How do you want to tackle this one, are you going to look into it yourself, or would you like a hand?

I probably won’t have time to dive into this for quite a while, honestly. Will definitely let you know if I manage to figure this out though.

Hey @shanept, I fixed it! And it’s a super ugly fix, too!

Digging through stack traces got really boring after a while, so I just went for the primitive brute-force approach. Thankfully, the offending Divi code does a function_exists check before defining itself, so I’m abusing that. For the fix, insert this block around line 12 in /src/Ajax.php (right after you define WP_ADMIN as false and before requiring admin-ajax.php):

define( 'WP_ADMIN', false );

// Ugly stub hack to fix Divi's janky portability registration implementation
if ( ! function_exists( 'et_core_portability_register' ) ) {
	function et_core_portability_register( $context, $args ) {
		return true;
	}
}

I haven’t done a thorough deep-dive on what the consequences of this might be, but from what I can tell, it’s only ever going to be doing this when we’re trying to handle ajax actions from within AceIDE… so Divi shouldn’t even be involved, as far as I’m concerned. Preliminary testing (I loaded, edited, and saved a file) has not shown any negative effects, though I’ll update this thread if anything pops up.

And just like that, I’ve got AceIDE working again on this site!