When I manually triggered WordPress auto update using the wp_maybe_auto_update()function, after the auto update process completes the plugins are getting deactivated.
I was experiencing the same problem, and digging into the code revealed the cause.
The Automatic_Upgrader uses the Plugin_Upgrader to update the plugins. The plugin upgrader has a method, deactivate_plugin_before_upgrade(), that is used to deactivate the plugin before upgrade, but only in specific cases. It contains these lines:
// When in cron (background updates) don't deactivate the plugin, as we require a browser to reactivate it
if ( wp_doing_cron() )
return $return;
So when the updates are being run by a cron job, the plugins don't get deactivated. The automatic updates normally are run via cron, and so the code has made an assumption that they always will be. If the automatic updates get triggered outside of cron (as when you are manually calling wp_maybe_auto_update(), then the plugins will get deactivated, but they won't automatically get reactivated.
One solution would be to trick the upgrader into thinking that cron was running, by hooking into the 'wp_doing_cron' filter before you call wp_maybe_auto_update():
add_filter( 'wp_doing_cron', '__return_true' );
wp_maybe_auto_update();
remove_filter( 'wp_doing_cron', '__return_true' );
Related
In my Wordpress site, this issue appears when adding or editing posts.
Notice: register_rest_route was called incorrectly. REST API routes must be registered on the rest_api_init action. Please see Debugging in WordPress for more information. (This message was added in version 5.1.0.) in /project/wp/wp-includes/functions.php on line 5167
Note: I didn't make any WP update or any plugin update on the site.
Any idea to fix this issue? Thank you.
In WordPress 5.5, a change was made to how REST routes are registered and now required a permission_callback.
The reason you may see it the notice on one site and not all is that notices only appear when WordPress is run in DEBUG mode, confirm by checking the value of wp-config.php for
define( 'WP_DEBUG', true );
If the site showing the notices should not be in debug mode, simply change the value of WP_DEBUG to false.
A plugin or your theme are creating a REST-Api route in a wrong hook.
This is correctly done by using add_action('rest_api_init', 'function_to_create_end_endpoint');
function_to_create_endpoint contains the function register_rest_route().
In your case it's something else ('init' or 'plugins_loaded' instead of 'rest_api_init')
Some solutions:
Update all Plugins/your Theme to a current Version
If this doesn't help you can: Deactivate Plugins one by one, to see which one causes the issue, than maybe replace it or check if is abandoned
Search for "register_rest_route" in your wp-content folder and find the plugin that calls it in a hook something other than "rest_api_init".
Lastly Notices only show up when you turn on full debugging in your wp-config, this isn't meant for sites running in production. You could turn it off.
Im using the WordPress Multisite MU-Plugins directory to run some custom functions which i need to be
available to ALL subsites in my network. When i run the function in the primary sites' functions.php
file it runs as expected but it obviously cannot access any subsites.
Is the problem with the loading order that WP utilises - i read here the order is:
the WordPress core code
mu-plugins
plugins
functions.php
the theme code for the specific template being displayed
I believe the issue may be that im trying to call wp funcs that are not yet loaded yet. Is there a way to defer the loading of 'Must-Use' -plugins until, say when functions.php runs??
You can't defer the load, no, but you can move the code in the mu-plugin that requires on other things to be loaded into action hooks for actions that are triggered later in the load order:
hook plugins_loaded to run code after all plugins have loaded
hook after_setup_theme to run code after the theme has loaded
(I guess that's what you mean by 'functions.php' ?)
However I think all of WordPress's own functions are loaded before mu-plugins are loaded, so this may not be your problem.
Without changing anything WordPress version updated from 4.9.4 to 4.9.5. on Azure server.
Please let me know how this happened?
It is an auto-update. (as already show in the image you posted)
By default, only minor releases – such as for maintenance and security purposes are auto-updated but they are configurable. This is the recommended behavior.
However this can be prevented by defining certain constants or by applying filter hooks
To completely disable all types of automatic updates, core or otherwise, add the following to your wp-config.php file:
define( 'AUTOMATIC_UPDATER_DISABLED', true );
You can also disable all automatic updates using the following filter:
add_filter( 'automatic_updater_disabled', '__return_true' );
It is also possible to allow the partial updates.
The detailed instruction can be found in the link https://wordpress.org/support/article/configuring-automatic-background-updates/
In reference to the following existing question. Wordpress Plugin : Can't process Indexing Queue I was unable to participate in the comments due to having a new account and less than 50 reputation.
I am having a problem getting the Algolia WordPress plugin to process the index. Running the latest version of WP and just downwloaded the WP Plugin from Algolia today. When I run WP_DEBUG and WP_DEBUG_LOG in my wp-config file I get the following output on any WP back end page.
has_cap was called with an argument that is deprecated since version 2.0.0! Usage of user levels by plugins and themes is deprecated. Use roles and capabilities instead. in /var/www/html/dealer/wp-includes/functions.php on line 3890
Line 3890 in wp-includes/functions.php just references the code that generated the error.
trigger_error( sprintf( __('%1$s was called with an argument that is <strong>deprecated</strong> since version %2$s! %3$s'), $function, $version, $message ) );
This appears to be an unrelated issue.
I should point out that this is a dev test server running locally on our internal network. I'm starting to wonder if that's causing the issue. I installed the same plugin on our live version of the site and everything works as expected.
We have never noticed any logs related to user capabilities. Your best bet to remove those notices is to:
Be sure all your plugins are updated,
Disable/Test/Enable plugins one by one to locate the plugin raising those.
Please ensure that all the requirements are met: https://community.algolia.com/wordpress/installation.html
Do you have any errors logged on the "Logs" page of the Algolia plugin?
Might be useful to also give us the list of plugins you are using.
Just working on a custom wordpress plugin. It will have an export and import function that need to be run at very exact times. So for those 2 functions I am ditching the wp-cron and set up cron jobs via crontab.
But how do I run only those 2 functions in this plugin but nothing else?
Thanks for your help.
I am not sure but this ideas might work.
You can create custom php file at root of wordpress installation and add
<?php
define('WP_USE_THEMES', false);
require("wp-load.php");
Now you can use all wordpress and plugin functions. Then you can set this file to execute by your webhost cron.
Other than that in functions.php of your theme whatever is outside function will be always executed. so you can set some GET parameter and check in functions.php for that parameter in url and execute a function. You need to set that parameter in cron job url at your webhost cpanle.