damien_vancouver

The problem is a bug in 1.6.29, it added this require to the main header-footer-elementor.php flie:

/**
* Include Composer autoloader.
*/
require_once HFE_DIR . ‘vendor/autoload.php’;

Unfortunately though, the “vendor” folder was not included in the plugin package. So you get a fatal error.

This causes real havoc when auto-updates are enabled, recovery mode does not seem to always happen and that leaves the site broken and needing server-side repair. A new version needs to be packaged with the missing folder urgently so sites don’t update to 1.6.29!

Downgrading to 1.6.28 will work, for totally broken sites that can be done by replacing the wp-content/plugins/header-footer-elementor folder using the hosting backend. Don’t forget to disable the auto updates on the plugin or it will auto-update again.

Hopefully a fixed version is put up ASAP and then everything will be fine-ish again.

in what universe is this “Resolved”????? Your latest plugin version 3.5.1.23 is STILL injecting broken HTML strings because of this bug and that causes whitescreen of death on affected sites, they are unable to add post content or edit posts because javascript blows up from your slider injecting un-escaped quotation marks. What the heck are you doing!?!?!?!?!? If you’re going to reinvent wheels at least make them round!!!!!!!!!!! Fix the bug, don’t just mark it resolved because you get less support requests since your change. Shameful!

Can anyone on this thread confirm if the error went away?

This error message is happening on logouts too. I’ve had two distinct bug reports from WP hosting customers today who both had the same error. They are both running 5.2.7 already it looks like (the same one in your link).

Here are stacktraces from the two sites (totally different codebases and servers and hosting plans):

PHP Fatal error: Uncaught Error: Call to undefined function get_active_blog_for_user() in /wp-content/plugins/all-in-one-wp-security-and-firewall/classes/wp-security-user-login.php:678\nStack trace:\n#0 /web/wp-includes/class-wp-hook.php(324): AIOWPSecurity_User_Login->wp_logout_action_handler(0)\n#1 web/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters(false, Array)\n#2 web/wp-includes/plugin.php(517): WP_Hook->do_action(Array)\n#3web/wp-includes/pluggable.php(671): do_action(‘wp_logout’, 0)\n#4 /web/wp-login.php(793): wp_logout()\n#5 {main}\n thrown in /web/wp-content/plugins/all-in-one-wp-security-and-firewall/classes/wp-security-user-login.php on line 678′, referer: https://…/wp-login.php?action=logout&_wpnonce=4681bd1f0e

here is the second one , again it’s logout triggering it, slightly different URL though, this one has the slug in it too.

PHP Fatal error: Uncaught Error: Call to undefined function get_active_blog_for_user() in web/wp-content/plugins/all-in-one-wp-security-and-firewall/classes/wp-security-user-login.php:678\nStack trace:\n#0 web/wp-includes/class-wp-hook.php(324): AIOWPSecurity_User_Login->wp_logout_action_handler(0)\n#1 web/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters(false, Array)\n#2 web/wp-includes/plugin.php(517): WP_Hook->do_action(Array)\n#3 web/wp-includes/pluggable.php(671): do_action(‘wp_logout’, 0)\n#4web/wp-content/plugins/all-in-one-wp-security-and-firewall/other-includes/wp-security-rename-login-feature.php(712): wp_logout()\n#5 ‘, referer: https://…/loginslug/?action=logout&_wpnonce=a8357da108

both sites are running version AIO5.2.7. Neither site is a multi-site.

Examining the code i see that the problem must be that $logging_out_of_correct_site is false, even though it’s not a multi-site.

• This reply was modified 1 year, 1 month ago by damien_vancouver.

The problem is that query-monitor creates an *absolute* link to the db.php file out of your wp-content. Then if you clone the site or copy it elsewhere, this link can point to somehwere you don’t hvae permission to.

My db.php looked like this:

db.php -> /home/olduser/public_html/wp-content/plugins/query-monitor/wp-content/db.php

and it was red and angry because the newuser did not have access.

I removed the symlink and re-added it relative instead:

rm db.php
ln -s plugins/query-monitor/wp-content/db.php

if the plugin were to add the symbolic link this way (using a relative path to the wp-content folder) then it would not be so fragile and blow up when the site was cloned.

Hi guys! There probably are quite a few plugins on the site I was profiling, it was a heavy Woocommerce site that has been through a few developers (that old story!). Thank you so much for looking into it, that is fantastic! Cheers!!

Deactivating and deleting the plugin also works.

“The wp_ajax_cff_save_settings AJAX action, which is responsible for updating the plugin’s inner settings, did not perform any privilege or nonce checks before doing so. This made it possible for any logged-in users to call this action and update any of the plugin’s settings.”

This is ridiculous flailing by Smash Balloon because 2 months ago CVE-2021-24918 came out which was the exact same issue. At that point the plugin should have been audited for other XSS injections to the AJAX encpoint.

Not getting around to that is understandable from a free plugin with volunteer work, but from a commercial company taking money for the plugin that is negligent behaviour. Shame!

This bug just took down a customer’s server by using up over 1.75 Million inodes on the file system. The server ran out of disk space with 80% of its disk space free.
The root cause was wp-cassify and it binding its session start to init, as described in this post.

I see it’s been updated to wp_loaded which is the exact same problem.

The root issue is that the top level plugin page (plugins/wp-cassify/wp-cassify.php) is loading up an instance of the public class *and* the admin class on every single page load. This (among other things) creates a PHP session, which not only breaks cachign (bad) but can fill up the entire filesystem by using up all the inodes (also really bad, crashes the entire server).

In the top level wp-cassify.php we have:

$GLOBALS['wp-cassify'] = new \wp_cassify\WP_Cassify_Plugin();
$GLOBALS['wp-cassify']->init_parameters(
        $wp_cassify_network_activated,
                $wp_cassify_default_xpath_query_to_extact_cas_user,
                $wp_cassify_default_xpath_query_to_extact_cas_attributes,
                $wp_cassify_default_redirect_parameter_name,
                $wp_cassify_default_service_ticket_parameter_name,
                $wp_cassify_default_service_service_parameter_name,
                $wp_cassify_default_gateway_parameter_name,
                $wp_cassify_default_bypass_parameter_name,
                $wp_cassify_default_cachetimes_for_authrecheck,

The WP_Cassify_Plugin::init_parameters() method calls the session_start that creates all the problems.

This is easily fixed becgause you only need a session for users that have submitted the login page! Only if someone *submits* the login form do you need a session. All other instances should have no session started, so that caching can work, and so that the disk is not filled with zero byte session files.

This bug means that any site with wp-cassify on has zero caching active, which leads to overloads and downtime. the fact that every bot HTTP hit can create a php session leads to a DDoS vulnerability and site outages. Please fix!

also had this issue with 6.3, there is no dist/chunks folder so the URL 404s.

Downgrading the plugin to 6.2 worked fine for me and fixes the problem.

The way the filter works has changed in Woo 3.x.

Instead of filtering the entire date itself, the filter is now just on the date format string used by PHP. There is no second $post argument passed in, which is what the error you’re seeing is. And instead of returning an actual date, it’s just supposed to return the date format string.

In other words, instead of returning a string like “2017/11/18 09:01 AM” , your filter function now needs to return a string like: “Y/m/d h:i A” and WooCommerce is responsible for looking up the date on the post.

Here is a fixed implementation that works for me, it’s much simpler now!

// show timestamp on orders screen, instead of just the date.
add_filter('woocommerce_admin_order_date_format', 'custom_post_date_column_time');
function custom_post_date_column_time($format)
{
    // Any PHP date format string will work for the 'Y/m/d h:i A' part.
    // see the PHP docs at: https://php.net/manual/en/function.date-format.php
    return __('Y/m/d h:i A', 'woocommerce');   
}

The way the filter works has changed in Woo 3.x.

Instead of filtering the entire date itself, the filter is now just on the date format string used by PHP. There is no second $post argument passed in, which is what the error you’re seeing is. And instead of returning an actual date, it’s just supposed to return the date format string.

In other words, instead of returning a string like “2017/11/18 09:01 AM” , your filter function now needs to return a string like: “Y/m/d h:i A” and WooCommerce is responsible for looking up the date on the post.

Here is a fixed implementation that works for me, it’s much simpler now!

// show timestamp on orders screen, instead of just the date.
add_filter('woocommerce_admin_order_date_format', 'custom_post_date_column_time');
function custom_post_date_column_time($format)
{
    // Any PHP date format string will work for the 'Y/m/d h:i A' part.
    // see the PHP docs at: https://php.net/manual/en/function.date-format.php
    return __('Y/m/d h:i A', 'woocommerce');   
}

@kathieker: has nothing todo with BackWPup.

Nice attitude! Actually, it has everything to do with BackWPUp. A design flaw in the plugin causes it to DoS any server it’s running on if the path to the website files change. This sharp edge needs to be adequately documented at the very least, if not mitigated by proper sanitization of the log path before trying to use it.

The PHP error in question can and hopefully now is tested for in code, preventing the plugin from doing anything catastrophic like writing endlessly as fast as it can to the PHP error log (which will completely take down any server regardless of hosting company).

If you are having this problem don’t worry, you can fix it by either removing wp-content/plugins/BackWPUp from your codebase, or moving it to another location. Then you can address the problem (by removing the temporary files as suggested in @labarbiche answer above, or hopefully by upgrading the plugin to the latest version).

Of course upgrading is impossible if you have just moved your site and now the whole server is down.. your only option to get back online in that case is to remove/move the wp-content/plugins/BackWPUp folder so that WordPress loads without it.