Scriptrunner (Doug Sparling)

Sorry I didn’t see this earlier. It shouldn’t be possible to blacklist an admin user, it’s explicitly whitelisted in the plugin and not available as a choice to blacklist. (at least in the latest version of the plugin.)

If you indeed blacklisted the admin (it may have been possible in an earlier version of the plugin), you’ll need to delete three rows from the wp_options table in the database. (where option_name equals the following values):

wp_admin_no_show_redirect_type
wp_admin_no_show_blacklist_roles
wp_admin_no_show_redirect_page

Then delete and reinstall the plugin.

If you do indeed have the latest version (1.4.3), then double check that you’re actually logging in as an admin. If so, I’d really be curious on what version of the plugin and WordPress you are using, and anything that may be out of the ordinary.

You should be able to activate the plugin as you do with any other plugin. After that, you should be able to navigate to settings by going to:

Settings->WP Admin No Show

which should take you to

https://www.example.com/wp-admin/options-general.php?page=wp-admin-no-show/wp-admin-no-show.php

where example.com is replaced with your host.

duplicate topic

duplicate topic

Did you move the old page to the trash or delete permanently? If the old page is in the trash, you need to delete it permanently.

It’s also possible you may need to flush your permalinks, which you can simply do by going to Settings->Permalinks in the admin and then click “Save Changes.”

It appears your server (most likely Apache) has a 32M memory limit for PHP (the max amount of memory a PHP process is allowed to consume) and your import process needs more. You either need to split your files into yet smaller files, or update your memory limit. (I try to always have at least 64M.)

There are ways to adjust this configuration, but if you’re using a hosted solution, then the odds are slight that you’ll be allowed to do so. You may ask your host if they can give you a 64M memory limit for PHP or try some of the solutions in this thread. (but as I said, but most hosts won’t allow this.)

Fatal error: Allowed memory size

Then you’ll most likely you’ll it at https://www.mywebsite.com/blog/wp-admin

Via wp-admin, go to: Settings->Permalinks and select radio button for “Post name” and then click “Save Changes.”

You might read through this thread:

Not able to search for new themes

It’s possible the host doesn’t allow outbound http connections or cURL or other transport mechanisms used by WordPress aren’t installed on the host’s server.

@telesemana – Awesome, thank you for the detailed info! I’ll be working on the plugin tonight. I’ll probably address current_user_can issue first, and then look into the pseudo user role.

@telesemana – I had updated the plugin to deal with multisite a few versions ago. I’m going to make some updates and I’ll see if I can look at that as well.

Apparently I missed the comment from @massimopadovan, so I’ll be updating the plugin in the next few days to address that issue.

Common php best practice is to not include the closing “?>” php tag if it’s the last line in the file. Just put the code above at the bottom of functions.php. (actually, it can go anywhere in the file.)

@willem.deboer – Awesome, thank you for the update and I’m very happy you got it figured out! If possible, could you kindly set the thread as “resolved”?

OK, this thread is up to 100 posts, so I’m going to summarize what’s been discovered and try and close this thing down. I’d also like to make sure the original poster (@willem.deboer) gets a solution.

Overview: The overarching issues is that after upgrading to WordPress 3.7 or 3.7.1 the user now gets the following error message onscreen when attempting to login:

“Cookies are blocked or not supported”

What should be happening (as of WordPress 3.7): When a user goes to wp-login.php, either directly or through a redirect from wp-admin, a test cookie should be set on that request. (an http GET.) When the login form is submitted, a check is made on the POST to see if the test cookie was set. This happens before authentication. If a test cookie was not set, then the user returns to the login form page (wp-login.php) and the “Cookies are blocked or not supported” message is displayed onscreen. Otherwise normal authentication occurs. (either user is taken to wp-admin or gets an onscreeen error message stating login failed due to incorrect username/password.)

Why am I getting this error with WordPress 3.7/3.7.1?:

1. (Confirmed) An update to WordPress 3.7 fixed a logic error that prevented the code in wp-login.php that actually tested for the presence of the test cookie from running. Some proxy/caching servers (confirmed with Varnish) are deleting WordPress cookies on GET requests, but since pre-WordPress 3.7 wasn’t actually checking the presence of the test cookie, the fact that the test cookie was being deleted by the caching server was overlooked by WordPress and users could login successfully.
2. (Unconfirmed, but some users have reported) Some plugins/themes may not be compatible with WordPress 3.7/3.7.1. The problem appears to be that a plugin/theme is sending output before the headers are being sent, causing a “headers already sent” warning, and consequently preventing WordPress from setting the test cookie (since “headers already sent” is a warning and not a fatal error, the web server will complete the request and simply not set the cookie).

How do I tell which issue is effecting my site?:

1. If you get the “Cookies are blocked or not supported” when you submit the login form, try logging in a second time. If you can successfully login on the second attempt, this is a good indicator that you have a proxy/caching server deleting WordPress cookies on http GET requests. (wp-login.php will also set the test cookie on a POST request, which is why you can login on the second attempt.)
2. Rename your plugins directory under wp-content and then attempt to login. (basically, you need to disable all your plugins.) If you can now login, then you’ve got a problem with a plugin. (NOTE: Set WP_DEBUG to true in wp-config.php before renaming your plugin directory, this may tell you which plugin is at fault.) If you still can’t login, try changing to a default theme like TwentyTweleve or TwentyThirteen.
3. To state the obvious, make sure your browser is accepting cookies…

Important: I’m not a moderator, so I can’t close this thread, but we need to make sure it remains useful for anyone who may search for a solution to this problem. If you’re not the original poster and this doesn’t fix the problem you’re having, please start your own thread and someone will be glad to help you there.