I have got a clean build (WordPress 3.9.1 running Twenty Fourteen theme).
I've installed WooCommerce plugin and added one product.
The product is a variable product with 65 variations.
When I link all variations and save, there are no issues. But editing any information such as stock quantities or price etc and hitting Update will cause the problem below.
Once I click Update, I am redirected to edit.php (the Posts page) and the changes were not saved. There is no error and everything seems to be running just fine.
Upon removing variations one by one I realised that once there's less than 50, the post updates perfectly.
I've tried increasing memory in PHP.ini, .htaccess, wp-config.php and nothing.
Any ideas at all as I'm absolutely lost on this one.
Many thanks in advance.
Michael
EDIT: In actual fact, you don't have to even attempt to change the properties of the new product. Even just trying to change this as it is will cause this issue.
We had a similar issue where we got redirected to the Wordpress posts page (/wp-admin/edit.php) instead of the post being saved. We had this issue only when the content field contained around 7.500 characters or more. Below this count the post got saved without any issues.
After trying several suggestions (even the ones listed here), it turned out there was an issue with the temp folder in PHP. After fixing the temp folder, the issue with saving the posts got solved. We stumbled upon this because when uploading a media file it gave an error message about a missing temp folder. So I guess Wordpress uses the temp folder only when the post is above a certain size (the character count I mentioned).
Hopefully this will help anyone else in the future.
I think your problem is with your shared hosting setup. Some shared hosts will add a maximum MySQL query length as a security measure. What is happening is that your host sees a huge query (because of all the variations) and drops the query entirely. Since you are doing smaller queries to add and remove variations, the issue doesn't show itself until you want to update the product as a whole.
The fix to this issue would be to contact your hosting provider and have them increase the MySQL query length to a much larger value. You may be able to adjust this yourself in the admin panel, it is usually marked as a security feature so I would start there. You could also try updating the MySQL config (usually located at /etc/mysql/my.cnf or /etc/my.cnf) file to:
[mysqld]
max_allowed_packet=32M
If you are not able to update the config then you will definitely have to contact your hosting provider.
For anyone else experiencing similar issues, be sure to check mod security with your host. My post request was flagging as a threat with their system so they turned this feature off.
I was looking for an answer to a similar problem and that is why I am posting this post, although several years have passed. I am using Wordpress 5.7.2 and Woocommerce 5.3.0.
First of all, do not limit yourself to diagnosing only at the Wordpress level. It is worth enabling PHP debugging, e.g. by entering lines in php.ini (of course, you can configure it according to your own requirements):
error_reporting = E_ALL & ~ E_NOTICE
error_log = /errors.log
log_errors = On
In my case, the following entries appeared in the debug log:
PHP Warning: PHP Startup: Unable to create temporary file, Check permissions in temporary files directory. in Unknown on line 0
PHP Warning: PHP Startup: POST data can't be buffered; all data discarded in Unknown on line 0
I compared the structure of my development environment where everything was working fine. It turned out that there was no temporary directory in the production environment (just /tmp for me). After its creation, everything started working as expected.
Related
I have been trying to import an .xml file from my old WordPress to a new one. I have the following settings in php.ini:
upload_max_filesize = 64M
post_max_size = 90M
memory_limit = 128M
But when I click on the Upload File and Import button Im getting a blank page. No errors or anything.
Anyone has any idea how to solve this? Thanks.
UPDATE:
After turning on the error display which was suggested below I was able to get the following error:
Fatal error: Class 'DOMDocument' not found in /var/www/html/wp-content/plugins/wordpress-importer/parsers.php on line 61
which I was then able to fix by installing php-xml.
This question in its original form did not provide enough information to justify actually trying to guess the solution.
Therefore I felt the most relevant answer was some general troubleshooting steps that may shed more light on a similar situation - my focus is on tips that may help in this particular situation, but since it is going to be rather lengthy anyway I do include some more general tips as well.
The OP is not actually asking for alternatives to the wordpress import / export function, but since this is a migration gone sour (plus the fact that the wordpress import / export feature leaves a lot to desire), I will try to answer Alans question regarding alternative ways to migrate wordpress between servers / locations / domains as well.
At risk of stating the obvious: This answer is going to be long!
Debugging wordpress errors in general
Step 1. Make sure you can see what goes wrong
Enable debug mode, and make sure display_errors is enabled, and an appropriate error_reporting level is defined. This is vital to any wordpress development.
Open wp-config.php and find this line:
define('WP_DEBUG', false);
Replace it with:
//Switch on wordpress' built-in debug mode
define('WP_DEBUG', true);
/**
* Just a convenient check so you can leave the next few lines unchanged
* for next time you need debugging, and just switch true/false above.
*/
if (WP_DEBUG) {
//Handle all errors regardless of error level
ini_set('error_reporting', -1);
//Display errors directly in the browser
ini_set('display_errors', 'On');
}
...if for some reason the line isn't there already, just insert it somewhere above the line saying.
/* That's all, stop editing! Happy blogging. */
This should allow you to see some more information about most (php-)errors.
Notes:
In most cases, simply setting WP_DEBUG to true will automatically enable display_errors - however I have found the above to cover some edge cases where errors where not shown in spite of WP_DEBUG being true.
On a live (production) site it may be very undesirable to display errors to every visitor, so you may want to:
enable WP_DEBUG conditionally, for example by IP: define('WP_DEBUG', $_SERVER['REMOTE_ADDR'] === '123.123.123.123'); (obviously substituting your actual IP)
log errors instead of displaying them - see the wordpress codex for more information: Debugging in WordPress
If you have low-quality or outdated plugins or themes installed you are very likely to see a lot of output from poorly written functions within those.
If you do see errors referencing one of your plugins as soon as you enable debug mode my recommendation is to either contact the plugin developer regarding the issue, or simply uninstall the plugin and find another one that satisfies your need. Plugins from developers who didn't even care to use debug mode during development are highly likely to also contain security issues and / or be sub standard with regards to future- or third-party compatibility.
Step 2. Reproduce the error
Whatever you did to make the problem happen - do it again. This should give you something to work with, for example by simply pasting it on google and see what comes up. Chances are you're not the first to experience whatever problem your are having.
If you still get no visible errors try to right click the "nothingness" and view the page source in a plaintext editor. Sometimes errors can be hidden inside an attribute, or behind an element on the screen.
You can also try to insert some intentionally broken code in wp-config.php to confirm that errors will in fact be printed. For example type this_function_surely_does_not_exist(); right after the ini_set() directives.
Some hosts restrict the use of ini_set(), so if things still aren't working, but you do not see any errors try to find out how you can set the relevant php.ini settings - it may be in your hosting providers control panel (cPanel, Plesk etc.), you may have direct access to your php.ini via FTP... or they may offer no way to set it (find a different provider at once!)
It is also possible that you cannot change the value, but errors are logged somewhere in your providers panel by default.
If you get a completely white browser window it is likely that you have a fatal error somewhere - or a configuration problem on the server itself. This is outside the scope of this answer, so if the suggestions regarding increasing limits in the next section doesn't work, try to google "WSOD" to get started.
Find actual limits and settings
Do not trust that just because you have a file called php.ini that contains a line saying memory_limit = 128M your memory limit is actually 128M. This can be set in so many different ways that the only reliable way to know is to ask php what its current memory limit is. This is true for most php.ini-settings!
To get a fair idea what your working environment looks like create a file (preferably in the root of your wordpress install) called phpinfo.php, with the following content:
<?php
//Your memory limit
echo 'memory_limit: ' . ini_get('memory_limit') . '<br>';
//Your maximum size of post-data (including file uploads)
echo 'post_max_size: ' . ini_get('post_max_size') . '<br>';
//The maximum file size for uploads
echo 'upload_max_filesize: ' . ini_get('upload_max_filesize') . '<br>';
//Maximum runtime for php scripts (in seconds)
echo 'max_execution_time: ' . ini_get('max_execution_time') . '<br>';
//Current error reporting level
echo 'error_reporting: ' . ini_get('error_reporting') . '<br>';
//Are errors displayed?
echo 'display_errors: ' . ini_get('display_errors') . '<br>';
//Will errors be logged?
echo 'log_errors: ' . ini_get('log_errors') . '<br>';
//Where will errors be logged?
echo 'error_log: ' . ini_get('error_log') . '<br>';
//What is the absolute path of this files parent folder
// = the complete path to your wordpress "root folder"
echo 'root of wordpress: ' . __DIR__ . '<br>';
/**
* If you are curious to see *a lot* of information about your environment
* then uncomment this line too:
*/
//phpinfo();
/**
* This should print whatever is in the error log, but it could potentially
* be huge, so use with caution!
*/
//echo '<pre>' . file_get_contents(ini_get('error_log')) . '</pre><br>';
You should be aware that all of the above values can be changed during execution of a script - and some (poor quality) plugins actually will. I've seen plugins try to increase the memory_limit for instance - which is all fine and dandy, except 6-7 years pass, and a plugin "increasing" the memory limit to 32MB actually messes up the installation, because nowadays 64MB is needed for a pretty basic wordpress install, and 128MB would be a more reasonable minimum for most. The problem with this is that the only way to actually know the values for sure at any given point of execution is to insert the above right at that point.
Some very common reason for errors that happen "on occasion", particularly in connection with imports or file uploads is that either memory_limit, post_max_size or upload_max_filesize is set too low - you can try to increase them using ini_set() calls in wp-config.php:
ini_set('memory_limit', '256M');
ini_set('post_max_size', '128M');
ini_set('upload_max_filesize', '64M');
Again your host may completely prevent you from affecting your limits using these functions, but may provide another way for you to set them.
If that doesn't work either, try disabling as many plugins as possible, and as a last resort switch to a default theme - but be prepared to lose widgets and a bunch of settings if things get to that.
If you're still stuck at square one ask a question on Stack Overflow, and be very verbose about exactly what you did before it all went south ;)
Cloning / Migrating / Moving or Backing up a wordpress site
There are a lot of backup / migration plugins out there. If you are inexperienced working with files, databases and the like your best bet is probably to go with one of those. I will not recommend any specific plugin as changes are too frequent and I personally always do it manually - a google search should yield plenty of relevant results though, and I'm sure many of them can get the job done in most situations.
However, if like me, you prefer to do it manually to understand (and control) the process, here is the method I use to move, rename, clone or back up wordpress installations routinely - it should work for almost any standalone installation (ie. if you're trying to move a multisite you should probably go look for another guide).
These instructions should work whether you are
migrating from one server to another - for example development to production
migrating from one domain to another
migrating from a sub-folder to the domain root (or the other way)
taking a backup (just stop half way through the process, and continue where you left off if you ever need to recreate your backup)
The basic steps are:
Get a copy of all files
Get a copy of the entire database
Do necessary corrections in files
Upload files to new server (or same if you are restoring a backup)
Load up the database on the new server
Do necessary corrections in the database
This requires that you have access to:
Your files, for example through FTP or perhaps your hosting provider has a tool that can create an archive containing all your files.
Your database, for example through phpMyAdmin or any tool that can make a complete database dump for you.
All decent hosting plans, and nearly all inexpensive shared hosting plans come with phpMyAdmin and FTP access. VPS', private servers etc. obviously comes with direct file and database access which will be even better (or at least faster).
If you do not have access to the above wherever your site is hosted, it is likely because you bought your site from someone who does not want you to move it away (usually because they designed your website for free or at a very low cost, and need you to stay with them to get back their investment). If that is the case you can try one of the many backup / migration plugins, but chances are they don't even allow you to install plugins, so you'll have to contact them and work out some agreement instead.
(if you do not have access to your database, but you do have access to your files you can install phpMyAdmin yourself - but how to do that is way outside the scope of this answer)
Note that depending on what operation you are actually doing, some steps can be skipped - which you can feel free to do once you understand the process, and why each step is (sometimes) required - but if this is your first time just start from the top and work your way through each step.
Step 1. Get a copy of all files
You'll want to get all files in the "root" of your wordpress installation. That is the folder containing wp-content, wp-admin and wp-includes plus about 15-20 files. Make sure you get hidden files too (for example the file .htaccess will likely be hidden by default if you use FTP - in some cases this file is completely irrelevant, but in others it can be essential, so just make sure you get everything)
If your hosting provider has some sort of file manager you may want to try that first. A lot of file managers offer the option to up- or download folders as a single compressed archive - which will be a lot faster than downloading all files individually.
If you have a VPS or any solution with SSH or some other form of console access, use that and navigate to the "root" of your installation, then zip everything up - something like zip -r my_wp_backup.zip . should do. Download the file using whatever means you have.
If you only have FTP access to your files, it may take a while, but you simply log in with FTP (my favorite FTP client is FileZilla, because it's easy to use, and allows several simultaneous transfers... but any client should be fine). Navigate to the "root" of wordpress and transfer all files to a local folder on your computer (don't forget to show hidden files!)
Step 2. Get a copy of the entire database
If you have access to phpMyAdmin through your provider use that - it is by far the easiest, and I have never had a problem, except with extremely special databases or extremely old versions of phpMyAdmin.
Just log in to phpMyAdmin, select your database, click export and accept the defaults (options are very different depending on the version, but the defaults should be fine for any "normal" wordpress database). This should give you either a file download with a name ending in ".sql" - or a big text-field with huge amount of text in it. If you get the latter just copy it to a regular text file on your local computer - notepad, notepad++ or any other plain text editor will work (ie. don't use word, google docs or any other rich text editor!)
If you don't have access to phpMyAdmin you can either install it (which I'm not going to describe), or you must find some other way to export the database, for example:
If you have console access this command should give you a usable dump: mysqldump -u your_database_username -p your_db_name > my_backup.sql - if you don't know the name of your database, take a look in wp-config.php (also contains your username and password if you don't know those)
If you don't have console access either go explore your providers control panel - surely they have some way to let you make a database dump.
Step 3. Do necessary corrections in files
You should now have a complete backup on your local disk.
If you are just doing a backup you're done - the files and database are ready to be uploaded to the same location, and everything will be restored to the current state.
If you are moving to a different server or a different location on the same server find out:
what your new path is (upload the phpinfo.php file above if your provider doesn't give you any clues)
what your new database username and password is
if you need a special hostname to connect to the database (localhost is sufficient in most cases, but some providers have dedicated mysql-servers that require you to connect to some other hostname)
Correct your wp-config.php file - the relevant lines are:
/** The name of the database for WordPress */
define('DB_NAME', 'your_database_name');
/** MySQL database username */
define('DB_USER', 'your_database_username');
/** MySQL database password */
define('DB_PASSWORD', 'your_database_password');
/** MySQL hostname */
define('DB_HOST', 'localhost');
Though it's rather rare some plugins do write information in files that needs to be updated, so if the absolute path of your wordpress root folder, or the absolute URL of your installation is changing in the process of migrating you should also do a complete search and replace for those:
If the old absolute path of your installation was /var/www/www.example.com/web/blog and your new absolute path is /var/www/blog.example.com/public_html then search-and-replace those throughout all files. Do not include a trailing slash!
If the old URL was http://www.example.com/blog and the new URL is going to be http://blog.example.com do a search for www.example.com/blog replacing with blog.example.com. Do not include http:// and do not include a trailing slash!
Note that if for some reason you are in a situation where you do not know your old absolute path and / or URL you can find them in the database, so do step 5 first, and look in the prefix_options table for the values siteurl (your absolute URL) and upload_path will usually contain your absolute path (plus /wp-content/uploads) - if it doesn't then there will probably be other rows in the table that can tell you what the path was, look for something that starts with /var/www or /home/something.
Step 4. Upload files to new server or new location
As in step 1 your options may vary, but the point is to get all files uploaded to whatever folder is going to be your new root. Use whatever means you have available to do so.
Do not give in to the temptation to "try" the site out after uploading files - though unlikely it can have unforeseen consequences if you visit before all steps are completed!
Step 5. Load up the database on the new server
Again, options vary:
If phpMyAdmin is available simply log in, select your database, click import and upload the file from step 2. Sometimes I even click the SQL tab instead, and just paste the entire content directly in the big text field.
If you have console access you can upload the file and run mysql -u your_database_username -p your_new_db_name < my_backup.sql
Step 6. Do necessary corrections in the database
If you're restoring a backup to the same server and location you are done.
However, if you are migrating to a different server or a different URL you need to be aware that Wordpress itself, as well as a lot of plugins writes your absolute URL in a lot (thousands) of places in the database, and your absolute path is likely to also be present in at least a couple of rows.
You also need to be aware that a lot of plugins, as well as some core wordpress functions use the php function serialize to store complex data easily in the database. That format is very sensitive to changes, so a "regular" search and replace is very (very!) likely to break everything.
Luckily there is a free tool specifically designed with this in mind. I have no affiliation, but I cannot recommend interconnect/it database search and replace enough. It is well-maintained, super user friendly, and I have never personally experienced it mess anything up.
Download it using the link above, unzip it, rename the folder to something_random_for_security and upload it to your wordpress root folder. Then go to http://blog.example.com/something_random_for_security in your browser (obviously substituting relevant parts of the URL).
You'll be presented with a neat graphical interface, and it has probably already filled in your database details for you (by reading your wp-config.php).
At the top of the screen there's a search field and a replace field. Don't mess with anything else, unless of course it actually failed to get your database information automaticall.
Like for files you need to search for:
your old absolute path and replace with your new absolute path (excluding trailing slash)
your old absolute URL and replace with your new absolute URL (excluding protocol http:// and trailing slash)
You can use the "Dry run" button first to see what will be changed, and if any obvious problems might arise - after that just click the "Live run" button and it'll chew through your entire database replacing in a serialize()-safe way where relevant.
Step 6,5 Broken permalinks
If you have moved your site from one folder to another folder (or up or down a level), then permalinks / "pretty URLs" may not work (ie. your front page is fine but everything else is one big error). This is because of the rules in that "hidden" .htaccess-file getting "confused". The fix is very simple - just visit the "Settings" -> "Permalinks" in the wordpress admin... you don't need to make any changes, the file is automatically refreshed as soon as you visit the page.
Done
Check that everything works, then go celebrate...
Your directives are in the wrong format. Try
upload_max_filesize = 64M
post_max_size = 90M
memory_limit = 128M
max_execution_time = 120
If those don't work, ask your webhost; you may not be able to make changes in php.ini.
And try running debug https://codex.wordpress.org/Debugging_in_WordPress to catch PHP errors that may point the way to the issue and solution.
The only way to find out what is causing the blank screen is check your server error log.
And also take reference from here
try this,after making the necessary changes for uploading a file in php or wordpress i.e
post_max_size = 90M
max_execution_time = 120
upload_max_filesize = 64M
memory_limit = 128M
other steps,
1)Increase the PHP memory limit via .htaccess (e.g. php_value memory_limit 64M)..
2)Increase the PHP memory limit via wp-config.php (e.g. efine(‘WP_MEMORY_LIMIT’, ’64MB’);)
finally check,
https://codex.wordpress.org/Importing_Content
These steps may help:
After showing the blank page, the page keeps running in background (you can see this in flight by refreshing the wp_posts table or wp-admin)
Inside wp-includes/deprecated.php there is a function named wp_get_http() with #set_time_limit( 60 );, change this to 0 to disable limitation.
This worked for me:
No images imported
Wordpress Tools > Export did not attach images even though settings state it to be true. The import process on the target site crashes. To fix that I installed the DeMomentSomTres Export plugin on the exporting site that forces the import process on your target site to make a connection to the export site and then pull the images over. That worked well.
No content when editing
However, when editing the imported posts, the content wysiwyg editor box appeared empty even though the text would display on the front end. Initially I thought it was a database issue. Then, I tried deactivating Classic Editor plugin and edited a post. Whaa-la the content appeared in edit mode. Next, after re-activating Classic Editor plugin, the content stuck. All good.
I got the same behavior today while exporting All Posts and Media from a client site using the usual WordPress Importer.
I tried changing the PHP.ini settings suggested in other answers, but that didn't help probably because they can't be overridden. Importer will stop showing the loading icon after 1 minute or two. No errors appeared even when I set DEBUG to true.
However, when I checked the wp-content/uploads folder I could see some of the folders and images were uploaded (check modified date) yet the execution timeout stops the importer before it can finish.
My solution was to keep importing the same file again and again until the whole thing is finally imported. This works fine because WordPress Importer won't import a Media or a Post again if it's already imported/exists.
So even if there is a timeout setting you can't change, multiple attempts will get it done unless you have huge media files exceeding max file size.
Of course, if it's a huge amount of images you should find another solution.
I've been fishing through answers to similar problems, but none seem to address the issue we currently have. To sum up what has occurred this far:
Client has a website running joomla v1.5.12 (yeah, we know it's old...)
Site was very slow so upgraded hosting package to higher specs.
Took an FTP backup of the original site beforehand and then copied it accross.
Site works on the front end as normal. Sends emails and is both cosmetically and visually sound.
However, admin pages keep showing errors in the same vein as the following:
JFolder::folder: Path is not a folder
and
Warning: Invalid argument supplied for foreach() in \\**servername**\Domains\e\sitename.com-XXXnumbersXXX\user\htdocs\libraries\joomla\language\language.php on line 712
The errors keep popping up throughout portions of the admin side of things. Trying to add or edit any new articles results in a blank screen. Editing other modules results in the above foreach() errors. The foreach() functions are being passed filepaths, but I can't figure out their values (I'm not much of a PHP dev).
Why would the front end work without any problems and only the backend areas have an issue?
Any ideas of how I should go about troubleshooting this?
Many thanks in advance,
D
Whenever I have issues with a new Joomla install I check the following things:
Are file paths set correctly?
Are the file permissions correct?
Are the tmp and log folders writable?
Is the .htaccess file set correctly?
You can find the answers to the first three at the following location:
Joomla Admin Panel > Help > System Info
Hope that helps
after updating to magento 1.8.1 it stopped saving the changes of the theme options in the system configuration… i made a backup and created 1 to 1 copy on my local machine… and by editing the theme options.. and saving!! everything is ok !!!
i can’t understand y the problem is only on the server… i mean these r the same files.. the same database… and everything is ok with the permissions… and the php version is by both 5.4… so i have no idea why it should function on my local server and not on the web server !!!
after saving… i still get the message “The configuration has been saved.” the problem is it's not being saved...
it's only about the theme options.. other Configurations can be saved normally...
so i can't understand y.. and i don't know where to look !!!
it’s driving me almost crazy
i made a screen capture to give a hint how it looks like:
http://www.youtube.com/watch?v=pBfIWXxGB64&feature=youtu.be
Nothing happens when you try to save the payment methods page. The problem is caused by the Chrome browser's auto-fill feature. Chrome will auto-fill the PayPal username/email. Click on the PayPal Payment Solutions tab, then click Configure near Express Checkout and remove the auto-filled username/password.
Now you can save the page.
Alternatively, try FireFox, Safari or Internet Explorer.
Taken from this page
This is 100% cache issue.
Clearing cache folder from magento_root/var does not clear all cache created by magento.
You need to clear cache from magento admin:
flush magento cache
and
flush cache storage
If that wont help, try to clear /tmp directory on server.
Also: if it's a theme related configuration issue, maybe after upgrade some file permissions have been changed.
I got this in my PHP log. So for me the solution was to increase the amoutn of input variables to 10000 via .htaccess file
PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini
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.
Recently I moved a website to a new server. The website was working perfectly on the shared server, but I've encountered a host of permission issues and other problems since relocating to EC2. I have changed the ownership of the /var/www/html folder to apache to allow altering altering of settings on the back end of WordPress. Strangely enough, I am able to create new posts, but when I attempt to update an existing page or create a new one, I receive a blank page. [http://example.com/wp-admin/post/php] Originally I thought it was yet another permission based issue, but after researching that doesn't appear to be the case.
Steps I've taken thus far:
1) Changed ownership of the directory to apache
2) Disabled all my plugins
3) Added : php_flag output_buffering on to .htaccess (Although I wasn't sure if it mattered where in the .htaccess file I should put that command)
From the research I've done it appears that white space after the ?> could be the cause. Anyone know how I could tell which file would have this white space? Several of my files actually do not even have the PHP close tag. One additional note, my previous server was version 5.2.17 to 5.3.20. Any other ideas?
After checking the error logs I discovered that I was missing the mbstring PHP library, which has a function that was called by one of my theme files. Once added I was able to create and alter pages on the backend of WordPress without issue.
To all the folks who get this kind of error of page not displaying must check option.
turn on error reporting if you have commented the lines in your wp-config.php
#ini_set('display_errors','Off');
and than check for error.
if it has the error like this
PHP Warning: Cannot modify header information - headers already sent by (output started at /[server info]/wp-config.php:77)
than check your wp-config.php for extra space at top and bottom of the page.remove extra line spaces even. and than re-upload the wp-config.php.
Most of time this will solve your problem.
Happy Coding!!!!
I had a similar problem and by removing extra spaces before the "< ?php" fixed the issue. Although apparently it was a different theme functions file that was causing the issue. Make sure you look at the php file referenced in the php warning. In this example, it's 'wp-config', but it could be really anything.
PHP Warning: Cannot modify header information - headers already sent by (output started at /[server info]/wp-config.php:77)
Good luck!
Basically this issue happens because you have edited the file directly on cpanel editor or other simple text editor. Just create a new .php file and paste your post.php code in that file. Now save this file and replace this new one with old post.php.