Wordpress plugin works only for logged users - wordpress

I'm using Dave's Wordpress Live Search.
The problem I have, is live search - it works only for logged users. If i'm logged in, plugin works fine. I found this line:
'ajaxURL' => admin_url('admin-ajax.php', is_ssl()),
which mean plugin is using admin-ajax.php and i think unlogged users haven't access to it.
I tried to define ajaxURL without , is_ssl():
'ajaxURL' => admin_url('admin-ajax.php'),
but didn't help.
Is it a problem with access to wp-admin/admin-ajax.php? How can i change it?

This is old, but I was looking into this.
Rather than changing the core, you can duplicate the hooks of the plugin and add ''no_priv'' versions. I am sure this is more elegant than duplicating a file in the core.
See: http://codex.wordpress.org/AJAX_in_Plugins
From that page:
"Ajax on the Viewer-Facing Side
As of WordPress 2.8, there is a new hook similar to 'wp_ajax_my_action':
'wp_ajax_nopriv_my_action' executes for users that are not logged in.
So, if you want it to fire for both visitors and logged-in users, you can do this:
add_action('wp_ajax_my_action', 'my_action_callback');
add_action('wp_ajax_nopriv_my_action', 'my_action_callback');"

In your case I would clone admin-ajax.php and rename it and remove all admin related conditionals from the file.
More specific:
Make sure to include the new cloned file where required instead of
the old one.
Make sure also you are changing only the permissions
levels from the file.
The cloned file just put in the same directory as it is the admin-ajax.php, "wp-admin"
Good luck! :)

Related

Notice: register_rest_route was called incorrectly

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 can not access my WordPress dashboard because of a plugin called "Clef"

I have activated a Two Factor Authentication sing in method called "Clef" on my WordPress based site. It turns out they have shut "Clef" down on July 2017.
The problem is that when I want to sign in to my WordPress dashboard, I get a "loading clef login" page and nothing happens.
How can I remove it?
As promised, here are the steps you could take:
Option A:
Download FileZilla
Log in, using the Login Credentials supplied by your Registrar/Hosting Provide
Go to: /httpdocs/wp-content/plugins
If /httpsdocs/ is not there, simply head to /wp-content/plugins
Find the name of your Plugin (Presumably 'Clef') and simply delete the Folder.
Option B:
I am not sure who is providing your Domain/Hosting but you can always login via your Domain/Hosting Control Panel and delete the Folder from the Web files, that way.
If I were you, stick to Option A. Not only is it the most universal but something I would advise getting an understanding for, since you could use FileZilla to backup your Web Files in the future.
Any problems, drop me a Comment and I will help you along the way, if needs.
The easiest (and possibly the only) way will be going to the FTP server, going to wp-content/plugins/ directory and removing clef directory (or whatever is the name of this plugins directory name).
WordPress will disable this plugin automatically, if it doesn't exist anymore.

How to update get_stylesheet_directory_uri in wordpresss

How do I update get_stylesheet_directory_uri? Transferring a website and I have already updated the url for the site inside wp-config using:
define('WP_HOME','https://somewebsite.com');
define('WP_SITEURL','https://somewebsite.com');
Still when get_stylesheet_directory_uri is called it is using a previous url, any idea on how to force this to update?
Thanks!
Once you change the site URL using those DEFINE statements, you also need to flush the permalink settings. Just go to wp-admin -> Settings -> Permalinks, and save without making any changes. That should force it to use your new values.
If you have access to the site via FTP, then this method will help you quickly get a site back up and running, if you changed those values incorrectly.
FTP to the site, and get a copy of the active theme's functions.php file. You're going to edit it in a simple text editor and upload it back to the site.
Add these two lines to the file.
update_option( 'siteurl', 'http://example.com' );
update_option( 'home', 'http://example.com' );
Use your own URL instead of example.com, obviously.
Upload the file back to your site, in the same location. FileZilla offers a handy "edit file" function to do all of the above rapidly; if you can use that, do so.
Load the login or admin page a couple of times. The site should come back up.
Another thing that can happen if your site is multilingual is that get_stylesheet_directory_uri is used in a registered string whose translation is still using the previous domain. In that case, search and replace your translations with the new domain.

How do I password protect a page of posts on Wordpress?

I have several pages on my site and I want to password protect a page which contains the latest posts.
Simply going to the admin panel and setting Visibility: Password protected isn't doing anything so.
How could I achieve this?
Follow these steps:
Check you browser console first may be some javascript file cause
of error.
If the issue not resolved with this, deactivate all plugins and
check console again. Then activate the plugins one by one
and check which one is conflicting.
If the error is still there change you theme to one of default WordPress
themes and check, has your issue been resolved.
If issue still there then update your WordPress core files only.

Moved Wordpress site, can not login as admin anymore

I've moved my local copy of wp to my production site and did all the annoying stuff you have to do when moving WP around.
My only issue now is that I can not login anymore to my WP as admin. The user gets logged in but obviously does not have it's admin permissions.
I've already checked the serialized permission array for that user and it seems to be correct but my user still gets not recognized as an admin type user.
Any ideas what the cause of this issue could be?
Edit: Solved, see my answer.
Make sure you migrated the database entirely to the new location, if admin is missing permisions of its role, edit them manually in the database table wp_usermeta, field wp_user_level
Solved the issue:
I have not seen anywhere in the documentation that WP obviously uses the db prefix for it's table wp2_usermeta and its meta_key field.
So somehow I've ended up with wp2_capabilities AND wp_capabilities. The wp2_ one was wrong. It did not migrate or change this properly.
If wordpress is ever going to get unit tests and proper migrations with rollback and changelogs...

Resources