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.
Related
after reading many similar topics, I still can’t solve this problem; the quantities in the cart don’t update with the new values once the “update cart” button is clicked.
I’ve already tried disabling themes and plugins, but even as the only extension installed and with default theme (tried both StoreFront & Twenty Twenty-one), the WooCommerce cart continues to behave this way. I have also enabled the WordPress debugging logs and I can’t find anything there, just like in the console.
Someone already run a debug on my cart and think that I am a victim of a code conflict, he found this error :
Element.querySelectorAll: '\' is not a valid selector
I don't know where to look for the source of this error or what procedure to follow to recover the expected behavior...
You can try the bug here.
Mini-update : I created a new Wordpress project and installed WooCommerce. I then transferred all the files of this new WooCommerce on my site and the problem still persists.
I also noticed that the columns of the woocommerce_sessions table were not updated when the quantity was changed. I assume that the script responsible for writing to this database could be the cause of this bug.
As I could not find the source of the problem, I started from scratch by changing my hosting solution. Once the files were uploaded on the new server and the configuration files were adapted, the shopping cart works normally again.
A PHP session was created by a session_start() function call. This interferes with REST API and loopback requests. The session should be closed by session_write_close() before making any HTTP requests.
In most cases, the real reason of the above errors is the incorrect mechanism for using PHP sessions within plugins or themes when they are using the session_start() function.
Now you need to identify what plugin cause this issue by deactive your plugin one by one.
Then in that plugin, you need to find a piece of code similar to this:
if ( !session_id() ) {
session_start();
}
then change it to:
if ( !session_id() ) {
session_start( [
'read_and_close' => true,
] );
}
Then you are done. In most cases, this will fix the issue. Good luck!
Had the same issue due to WP Hotel Booking plugin use. I fixed it! Took me a while to find a plugin it caused and editing the plugin .php didn’t help. But I fixed it adding a snippet of code to functions.php of the CHILD theme:
function mymodule_curl_before_request($curlhandle){
session_write_close();
}
add_action( ‘requests-curl.before_request’,’mymodule_curl_before_request’, 9999 );
There's a background to this solution at: Make WordPress Core, Loopback request fails if headers set in curl
(Original link in German doesn't exist anymore and was referring to this other related discussion.)
Often this critical issue is caused by conflict in SESSION when using the PHP session_start() function.
For example I have used a Calculation plugin in Wordpress and after Wordpress version update this error occured.
So I detected the plugin which causes this issue as activated/deactivated plugins one by one.
SOLVING these errors: In File manager of my site I got the .php files of the plugin and searched for session_start() function. Where it was used after it I used this function in a row session_write_close();
Source of the function
Regards!
To chime in with my own experience here, this very issue was resolved by turning off the “cross sell pop up” module of Shopengine Pro. Indeed there’s a session start in the php. I have notified them about this today. Maybe it’ll help someone else meantime!
I found out that you get these critical health warnings when you install a plugin or a plugin Adon and fail to complete its setup to the end. So the simplest solution is to deactivate the plugin or complete the plugin set-up. My errors were caused by a Woocommerce Adon which I deactivated and when I refreshed the health status the two issues were gone. I hope this helps.
#David M., If the issue is specifically happening with the Cross-Sell Popup Module of the ShopEngine PRO plugin, then it can be fixed by adding a small piece of code on the cross-sell-popup.php file that will read and close the session of the Cross Sale Popup module immediately.
Big Thanks to #thống nguyễn for the solution.
On the line 18th, from where the session starts, replace the session_start() with the following code:
session_start([
'read_and_close' => true
]);
Hope it will help.
If you tried the above and it's not working try to change the php version from your hosting's CPanel
I had the same error ande i changed the php version from 7.4 to 7.3 and it all went well
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.
I have this error and I seems can't get any decent answer on the web. Your answers will be much appreciated.
Thanks
Take a look at the documentation for wp_get_active_and_valid_themes(). You'll see that it's a private core function, which means plugins and themes aren't supposed to use it. It's also defined on wp-load.php. This most likely indicates one of two things.
1) Your WP Installation isn't valid. Reinstall the most recent version of WordPress and it should fix itself.
2) If you're attempting to use WordPress functions outside of WordPress (for example, in a custom PHP file), you're not properly loading in wp-load.php with require_once( 'path/to/your/wp-load.php' );
this just happened to several sites for me as well that were using WP Super Cache. i just deactivated all plugins and the theme (via wp_options db table) and reactivated them and it was fixed. strange
I have a WordPress blog that I admittedly haven't been looking after/not upgrading the plug-ins etc I'm regularly emailed about - and now it's down.
No matter what page I go to, I get:
Fatal error: Call to undefined function get_network_option() in /home/gfptlkxn/public_html/blog/wp-content/plugins/wordfence/lib/wordfenceClass.php on line 747
I've done a bit of googling on this and it seems a common problem, but more for people making changes/trying to use certain features etc - I've not changed anything/not doing anything fancy - it's just a simple blog.
So I figured maybe I could just go into my login page for WordPress, have a dig around, upgrade some plugins etc as a starting point.
Problem is, even my login page presents this error.
Any ideas where to start please?
There may be a compatibility issue between the WordFence plugin and your version of WordPress (as noted in the WordFence forums).
You should log into your website using FTP and delete the directory: /home/gfptlkxn/public_html/blog/wp-content/plugins/wordfence/
If you do not know or have FTP/SFTP access to your site, you may be able to log into your web hosting cPanel (or equivalent) and remove the directory using the File Manager feature.
Once that directory has been deleted, WordPress will be able to load again (and will automatically disable the no longer present WordFence plugin).
Once you've managed to log into WP-Admin, upgrade WordPress to the latest version, the install the WordFence plugin again if you need to.