I have a strange problem, that I have never encountered.
I migrated web-site from my PC to the server. Well, I have done this a lot of times, but never encountered this issue.
Ok, what I did is, i copied the theme and exported the database and imported on the server + I replaced the table prefixes from wp_ to site_ to match the servers pre-made WordPress installation prefixes.
The page works fine, but, when I log in as an administrator ( there are no other users, then the admin ) I get this error:
And when I open the actual page I see this:
The white line one the top is where the admin menu should be.
It seems, that the user has actually logged in, but somehow is getting rejected from the server?
I know that this is a small isue that can be solved, by reinstalling WordPress with the exact settings that I have on my local PC, but I want to know why this happened and how to actually fix it.
PS: There are no addons involved in this. Just my custom theme.
It looks like you're being logged in, but your account doesn't have administrator privileges. Go to your site_usermeta table in the database and confirm that the meta_key and meta_value are using the correct prefix. They should be site_capabilities, site_user_level etc instead of wp_capabilities and wp_user_level etc. Also make sure that site_capabilities is set to administrator.
Additionally, check the site_options table to see if there are any option_names that are still using wp_ and not site_ Essentially, if you changed the prefix in the config file, you will need to change all entries of the prefix in your MySQL database as well.
Here's a good resource to follow: http://www.wpbeginner.com/wp-tutorials/how-to-change-the-wordpress-database-prefix-to-improve-security/
Related
I was following this guide: http://mrbool.com/how-to-create-a-login-page-with-php-and-mysql/28656 to create a login page. I followed everything to the letter but when I uploaded the two files (login.html and connectivity.php) to my public_html folder of my godaddy linux shared hosting server and attempted to test it out, I was met with a blank page when I navigated to: mydomainname.com/connectivity.php. Now after reviewing the code within connectivity.php, my suspicion was that my mistake lay somewhere in my database setup. This is what I am referring to:
I changed the database name "practice" to the actual name of my database that I created through godaddy. I got a little bit stuck on the "DB_USER" section though. I added a user to my database through godaddy's mysql application and changed the name "root" to the name I set for the user. Here is what I'm referring to:
After I did that I changed the "DB_Password" to whatever I had set for the username's password. I thought at this point I was done but when I attempted to navigate to the page, it still didn't work. I know the "DB_HOST" is set to localhost but I wasn't sure what I was supposed to change that to since phpMyAdmin panel stated the following: "Server:localhost" even though I'm using a server. I added all the tables and users to the mysql database correctly so I really think this has something to do with my configuration. If anyone could help me I would greatly appreciate it. Thanks.
I just pulled down a copy of a customers live site to correct some plugin issues and set up a demo site on our local dev server, but I cannot get into the administration panel of the site due to a broken captcha (the captcha image does not display, so entering it correctly is pretty much impossible).
I do however have access to the codebase and the database, so if I can toggle this off somewhere, remove something from config.xml or comment out a line to temporarily shut it off until I can get in and disable it correctly, that would be perfect, because I only really have about ten minutes of work to do in the backend.
This issue is due to a missing resource, probably due to some DNS setting somewhere that doesn't match up with the URL on our dev server, though I don't know exactly where. The customer is running Magento EE v.1.13.0.2 if that is relevant. Thanks in advance.
Search on core_config_data table in your database .Search admin/captcha/enable on run the below code
Update
core_config_data set value=0
WHERE path LIKE '%admin/captcha/enable%'
insert into core_config_data (scope,value,scope_id,path) values ('default',0,0, 'admin/captcha/enable');
Remove the cache
Solution:
For Magento 2.x & higher versions
If you have access to Database:
Run the following query
SELECT * FROM `core_config_data` where path LIKE "%captcha%"
Set both the rows to 0
If you have access to code base
Remove the backend_login form entry in the following config file
Magento\vendor\magento\module-captcha\etc\config.xml
Don't forget to Flush the cache : php bin/magento cache:flush
NOTE: Once login in to admin revert the code changes.
We were having similar issues, after duplicating & moving an existing site to a new domain.
The other answers here helped but did not entirely solve the issue. When attempting to login it would silently error and not login.
To fix this we did the following:
Search in the core_config_data table in your database for the web/cookie/cookie_domain entry, and ensure the value here is correct for the new domain.
I just figured this out actually, I navigated to /app/code/core/Mage/Captcha/etc/config.xml and removed the following node (required sudo vi because it was read only):
<admin_user_authenticate_before>
<observers>
<captcha>
<class>captcha/observer</class>
<method>checkUserLoginBackend</method>
</captcha>
</observers>
</admin_user_authenticate_before>
I still like Amit's answer better because it does not require manually editing any files in the core, but this also works and I wanted to put this up as an option in case someone had the same issue in the future and did not have access to the database. Probably a good idea to restore the config to it's original state when you are done, unless you need to get back to the backend in the ongoing sense. I do like doing it through the database better though when possible.
After logging in, I restored the file to it's original state and disabled the captcha properly through the backend.
On M2.4 disable admin google recaptcha
select * from core_config_data WHERE path LIKE '%recaptcha_backend%';
update core_config_data set value=NULL WHERE path LIKE 'recaptcha_backend/type_for/user_login';
I was in the middle of migrating a local WP site to a live server and came across a problem.
I edited my WP config file and uploaded it along with the rest of the WP files. I also uploaded the mysql database through phpMyAdmin.
Once i tried to test the site i got an error message "The page isn't redirecting properly". I then, mistakenly, logged in to the admin area and in the Settings > General tab I deleted the localhost part of the URL. Now I'm unable to log back in to the WP admin area.
EDIT
To clarify, my major problem is that i can no longer log in to the wp admin area because of something I've done. The steps i took to get to this point were:
Backed up WP using the BackUpWordpress plugin
Edited back up wp-config file with define('WP_HOME','http://example.com'); define('WP_SITEURL','http://example.com');
Created mySQL database through DreamHost
Changed database info in wp-config file
Uploaded wp files (not including mySQL backup) to my url using Filezilla
Imported mySQL database backup to DreamHost
I then checked the site from my browser, an error message said too many redirects occurred
From the wp admin area i went to Settings > General and deleted the localhost part of the url that was displayed.
I believe it's due to the previous step I'm now unable to access the wp admin area at all.
I need a way of getting back into the admin area
You can also edit those options within phpMyAdmin. Go to wp_options and locate siteurl and home. Make sure the URL matches your site URL.
You can also edit the site URL in your wp-config.php.
Add these lines somewhere above the /* That's all, stop editing! Happy blogging. */ line.
define('WP_HOME','http://my-site.com');
define('WP_SITEURL','http://my-site.com');
This should overwrite your database settings.
I believe the problem is that studiomed.co.uk is permanently redirected (301) to www.studiomed.co.uk and www.studiomed.co.uk is permanently redirected (301) to studiomed.co.uk
Login to your Dreamhost account go to Domains->Manage Domains and choose one of the three options there are in "Do you want the www in your URL?".
After that use an ftp program to download the .htaccess file that exists in your root installation of wordpress and open it with your favorite editor. Check if you have any kind of redirection in the .htaccess file.
Which version of WordPress do you use?
Can you list the plugins you are using?
Have you gone through the basic WordPress troubleshooting steps?
flush any caching plugins you might be running, as well as server
and/or browser caches.
deactivate all plugins to see if this resolves the problem. If this
works, re-activate the plugins one by one until you find the
problematic plugin(s). Sometimes, an apparently inactive plugin can
still cause problems.
If you can't get into your admin dashboard,
try resetting the plugins folder by FTP or PhpMyAdmin (read
http://codex.wordpress.org/FAQ_Troubleshooting#How_to_deactivate_all_plugins_when_not_able_to_access_the_administrative_menus.3F
if you need help).
switch to the Twenty Eleven theme (depends on your WordPress version) to rule out any theme-specific problems.
If you can't log in to change themes, you can remove the theme folders via FTP so the only one is twentyeleven. That will force your site to use it.
manual upgrade. When all else fails, download a fresh copy of the latest.zip file to your computer, and use that to copy up. You may need to delete the wp-admin and wp-includes folders on your server. Read the Manual Update directions first: http://codex.wordpress.org/Updating_WordPress#Manual_Update
check the Master List to see if you're experiencing a known issue
Login to your wordpress dashboard (wp-admin) and go to Settings->Permalinks, select Default and save changes.
Update all urls(path) using this querys then check:--
Use this querys for change all urls(path) for db then check
UPDATE wp_options SET option_value = replace(option_value, 'http://live_ste_path.com', 'http://localhost/local_site_path') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts SET post_content = replace(post_content, 'http://live_ste_path.com', 'http://localhost/local_site_path');
UPDATE wp_postmeta SET meta_value = replace(meta_value,'http://live_ste_path.com','http://localhost/local_site_path')`
[WSOD RESOLVED]
Since I could not find any solution to my problem by googling around, a crucial tracking info I finally found in WP error logs. So I would recommend to inspect logs before spending to much time looking for a proper answer by google.
After migration from an old web host to a new one, in my multisite environment all sites were working. Also, I was able to administer all subsites - but one! Trying wp-admin login to that site led me to fatal white screen. Without any message or any indication about the reason. And the culprit was corrupted file /public_html/subsite-x/wp-admin/admin.php. I really could not understand how that happened, just might suppose it appeared somehow while transferring files (FTP) from old host to a new one.
I am trying to move a WordPress site from my local server to the online server.
The problem is that, after the migration, if I try to open the administration page (wp-admin) I only obtain a white page, as you can see here: http://scorejava.com/wordpress/wp-admin/. Everything else seems work well in the homepage: http://scorejava.com/wordpress/.
In my local web server I have the WP site into the folder: /var/www/wordpress. I have moved it into a wordpress folder that is into my root directory of my online web server.
I have also import the local database into the onlyne database using MySql and then I have use the Search and Replace for WordPress Databases Script to change automatically all the http://localhost/wordpress occurrence into the database tables with http://scorejava.com/wordpress/.
There is an error on your site, and you need to find out what's happening.
WordPress URLs
When migrating WordPress sites where the URL changes, you will need to tell WordPress about the new URL. WordPress stores that information in the database, so if you're comfortable with that, you could find the correct entry in the wp_options table in your database and update its value.
I will show some fixes for standard WordPress installs (where the site URL is the WordPress root), but you may need to use different values for home and siteurl if you have a different setup.
Fix URLs via SQL
You will need to update the relevant fields in the DB, those being the entries of wp_options where the option_name is siteurl or home. You can find these fields using phpmyadmin, mysql-workbench, or another database management tool, or you can use the following query, changing the URL to be your own.
UPDATE `wp_options` SET `option_value`='http://www.myurl.com' WHERE `option_name` IN ('siteurl', 'home');
Fix URLs via wp-config.php
However, you can also do this via wp-config.php, which I find to be much more comfortable. Just open wp-config.php and add the lines:
// Site URLS (override DB settings)
define('WP_HOME','http://www.myurl.com'); //<-- NO TRAILING /
define('WP_SITEURL','http://www.myurl.com'); //<-- NO TRAILING /
Obviously you'll need to supply your correct URL.
It's possible that this is the only error you're having, and after adding those lines to wp-config.php, you will be able to log in and use your site normally.
Debugging WordPress errors
However, if you continue to experience problems, and any time you're working on developing a website, you will want to see error output. You can check your server logs for information about the errors, but you may find it more convenient for WordPress to simply display the errors in the page. To enable error display, change the following setting to true in wp-config.php.
define('WP_DEBUG', true);
Now WordPress will display any errors it encounters directly in the webpage. Be sure to change the setting to false for use on a production site.
Working with wp-config.php
This file will be located in the root directory of your wordpress installation. To make any of the changes mentioned here, you may either edit the file directly on the server (via ssh for example), or download the file with an FTP client, make your changes using a text editor, and upload the file again.
It's also a good idea to keep a backup copy before making any changes in case you break something while you're working.
References
You can read all about changing the WordPress site URL on the docs page.
Late To the party, I've experienced this recently and I managed to solve the issue. Here is what I've done.
Step 1: Set WP_DEBUG to true from the wp-config.php file
Step 2: I tried domain.com/wp-login.php instead of domain.com/wp-admin by this I was able to get atleast login form and some errors of Warning: Cannot modify header information - headers already sent by
Step 3: I've added ob_start(); in wp-login.php file after <?php in first line, of course to get me in for a while.
Step 4: This trick worked. I've disabled all the plugins, and errors are gone.
Step 5: Activated all the plugins one by one to find which plugin is causing error, So that I can fix the error in particular plugin. Like there was one plugin adding style before wp_enqueque_style so I set it to a function and hook it properly.
There were some minor errors too like deprecated functions. Its up to you whether you want to correct it or use alternate plugin.
And Don't forget to remove ob_start from wp_login.php file. The core files should not be changed.
Hope this helps someone like me.
Inside your settings for your WordPress dashboard there are two fields named "WordPress address (URL)" and "Site address (URL)". These are also known as the "Home" and the "Site URL" settings for your website. The values need to match the server you're actually running on.
If you can't get to the admin, you can use phpmyadmin, go into your database, find the fields kin the wp_options table, and make sure they reflect your domain.
It should be enough in most of cases.
I've fought the dreaded "White Screen of Death" myself a few times. You can browse the threads at the Wordpress Support Site to glean some suggestions, or Google it for lots and lots of people's stories and advice dealing with these. I can't recommend a single, authoritative reference for this.
In most of my cases it was caused by whitespace after a closing ?> tag that got introduced because of changes in newline schemes between my dev and production servers, usually in a plugin.
You might also try putting Wordpress into debug mode or adding error_reporting(E_ALL); to the first line of your site's /wp-admin/admin.php file to see if these give you any hints.
I've personally been able to avoid these (touch wood) by using the XCloner plugin to make transfers between my Win dev machine and *nix production server.
Edit wp-content/themes/active-theme-folder/function.php and add this code just before:
<?php
define('WP_HOME','http://www.myurl.com'); //<-- NO TRAILING /
define('WP_SITEURL','http://www.myurl.com');
Add the below line into the wp-config.php file:
define('WP_HOME', 'http://' . $_SERVER['SERVER_NAME']);
define('WP_SITEURL', WP_HOME . '/');
In you wp-config.php file just above the line stop editing line add this line:
define('RELOCATE',true);
/* That's all, stop editing! Happy blogging. */
Then go to your login URL, refresh the page and log in.
IMPORTANT: If you can log in, then remove the RELOCATE line before preceding any further. Then navigate to:
Settings > General
Set your Wordpress URL and Site address to the correct locations:
WordPress Address (URL): http://example.com/wordpress
Site Address (URL): http://example.com/myblog
Press "Save".
In many cases when migrating files to a different server this issue arises simply because of a minor error in one of your PHP files. The error is additional characters after the closing?> PHP tag in the file. These may just be simple whitespace or returns but they can often be the cause of the white screen of death.
A primary culprit is the functions.php file in your WordPress theme. Take a look at it in a plain text file editor (often available with most hosting accounts) and ensure you delete any lines after the closing tag.
If it's not in this file use error reporting to identify the culprit file, it may be in a plugin or another file in your theme.
As mentioned by Jon Surrell enable error display, change the following setting to true in wp-config.php.
define('WP_DEBUG', true);
I had the same problem after migrating to a local server.
A first attempt failed because there were many hardcoded filepaths in the database.
So I tried again and took care to create the same path as on the live server and the same hostname and databasename. Now the website was good but wp-login gave a white screen.
With wp-debug I found that the problem was caused by wp-super-cache plugin that had a full filepath hardcoded in the config.php
Changing this path to the full local path did the trick.
These are the steps I usually follow.
Upload files and database.
Set the correct file permissions.
Update the database configurations in the wp-config.php file to match the server db login.
Update the wp_options table for updating the site url and home url.
If everything goes well you should be able to login to the admin using the wp-login.php as the url.
The first thing next to do is to go to the permalinks and click save it will automatically update the .htaccess file. If there is no write permisson it will show you can copy it and edit the file via ftp.
Next thing you can easily update all the urls safetly with a plugin named velvet urls . Using it for many years. It will update all other urls in the database.
All these steps will be enough if everything goes correctly.
If you get a blank page or something you can turn on the error reporting and write the logs from the wp config file itself. You can try some of these to debug.
Just remove plugins from the folders one by one.
Remove the custom theme which you are using.
Unless you edited the core files mostly it will solve the issue. Only other chance is the version mismatch for php or mysql that is also very important thing to note while migrating. Hope this helps someone.
I'm adding this answer to the fray, in the hope, it might help somebody else. I followed all of the advice above to no avail. I actually had to hack the PHP files to force my administrator to have access to the panel. It's through the panel that I discovered that my administrator account was not assigned the administrator role.
This is my hack to "wp-includes/capabilities.php"
function current_user_can( $capability ) {
$current_user = wp_get_current_user();
if ( empty( $current_user ) ) {
return false;
}
return true; // HACK to get superuser power to any logged in user
$args = array_slice( func_get_args(), 1 );
$args = array_merge( array( $capability ), $args );
return call_user_func_array( array( $current_user, 'has_cap' ), $args );
}
This allowed the Administrator Panel to appear, with access to https://example.com/wp-admin/users.php and then I could assign the role. I then unhacked the capabilities.php to ensure all users had the correct rights, now that I had "Administrator" assigned to me.
everyone. A few days ago I ported by BlogVault the WordPress multisite instance. The process went smoothly, the sites worked as needed. But I could not get into the console, allways got the error "Your browser does not support cookies, please enable them and try again". I spent several days researching and figured out that the error occurs due to an entry in the code of the page "wp_options".
The original site uses the line
define ('COOKIE_DOMAIN', strtolower (stripslashes ($ _SERVER ['HTTP_HOST'])));
but the new server uses the line
define ('COOKIE_DOMAIN', mydomain.com);"
Replacing lines of code solved the problem. Hope this help somebody)
It's maybe a late replay, but hope it will help someone else.
In my case here are steps I used to resolve the issue.
Edit the wp-config.php file from your WordPress project root and change define('WP_DEBUG', true); instead of false.
Upload the same file to the project root for the new server.
Try to log in same as previously like www.yourDomain.com/wp-admin - Hope now you are able to login the backend admin
Go to settings -> Permalinks - under common settings - choose the radio button plan then click SAVE button for a sake, then again choose day and name SAVE again, don't forget to click save, got back your domain and check your site, the inner pages should work perfectly fine.
Go back to wp-config.php and revert the value to false and upload again.
That's it.
I am not a wordpress developer but the above solution was perfectly fine for me and didn't find anywhere it's explained properly.
I have a site where I tried to fix some encoding issues by editing my wp-config.php file. The changes didn't help, so I changed it back again. Now, when I try to log in to admin, I get the dreaded "You do not have sufficient permissions" message. Unfortunately, I have no backup of the config but I am 100% sure that it looks like it did before.
I've tried this:
- Saving wp-config.php in different encodings
- Copying a fresh wp-config-sample.php, just adding my DB settings
I've found a lot of people on the web who have had this error after upgrading, migrating or for other reasons, but I haven't done one of these things, only edited the wp-config.php and then back again. There are solutions about repairing the DB, deleting plugins etc. but I'm afraid to try them in case WP decides to do some "magic" and take the whole site down. Besides, I can't see how the DB could get damaged just by editing the wp-config.php file.
Any other ideas?
Sounds like you've goofed your roles.
Note: I'm assuming you're talking about Wordpress Single-Blog Mode, not Multi
You can try this:
Set up a new database - with a different name
Rename your wp-config.php (so you don't have one)
Browse to your wordpress address
You will see the setup screen, go through the normal setup
You should be able to log in
Take a look at your new database's wp_usermeta table (the records for user #1) and compare that to your old database's wp_usermeta (records for user#1)
Make whatever changes are necessary in your old database to match the new one.
Edit your wp-config.php and switch the settings back to the old database
We managed to solve it by copying all the info in the wp_user_roles row in the wp_options table in the database from another installation where everything worked. Now it works as it should.
A question: how can this value become screwed up by editing wp-config.php?