I was building a WordPress site, and I came across a symptom where I could access it normally immediately after installation, but when I logged in from the login page, the screen went blank and I couldn't log in, so I thought I'd leave a memorandum on how to solve it.
The above case study was posted on Codex, but there was no corresponding cause or solution, so I checked the error logs.
[code light="true"] PHP Fatal error: Call to undefined function get_option() in /var/www/html/wp-admin/admin.php on line 32, referer: http://***/wp-login.php[/code] and It is out. The error says that the get_option function is not defined in the main body of the admin screen admin.php. By the way, the version of WordPress installed is 3.4.1 (the latest as of August 29, 2012).
This time, when I checked the function on the manual site, I found that get_option() is defined in wp-includes/functions.php. So, when I followed the source of wp-admin/admin.php, I found that wp-load.php was required on line 30_once. In wp-load.php, load.php is required to _once on line 48, followed by wp_load_translations_early() is called.
In the function of wp_load_translations_early defined in line 668 of load.php, the functions.php is require_once, so it may have been returned before this include process... I thought and investigated.
However, no matter how much I try to var_dump variables, I don't know... Hmm, I'm in trouble.
──So, when I looked up the Internet to see if there were any similar symptoms, I found it.
The original English version of the WordPress forum had a solution for people who were addicted to the same error.
Well, if I had been looking for it online from the beginning, I wouldn't have had a hard time...
//wordpress.org/support/topic/wp-301-apc-314-php-533-white-wp-adnmin-page
It seems that a PHP accelerator called APC (Alternative PHP Cache) is doing badly.
APC itself is an accelerator module that caches compiled PHP files and makes PHP run faster, and it seems to be so great that there is a difference in perceived speed even in the default installation state. In the first place, it seems that the problem is not that the APC is bad, but that the APC settings are not optimized for WordPress.
So, when I checked the build server (CentOS 5), APC was indeed installed. To verify APC information,
[code lang="shell" light="true"]ln -s /usr/share/pear/apc.php /var/www/html/apc.php[/code] … If you create a symbolic link in the document root and access it, the APC version is 3.1.9 (by the way, the PHP version is 5.3.16).
**Now, here are the steps on how to solve it. **
- First, open the APC configuration file (/etc/php.d/apc.ini) and turn off the apc.include_once_override setting.
[code lang="php" light="true"]apc.include_once_override=0[/code] - If the above configuration file is not in php.d,
[code lang="shell" light="true"]echo "extension=apc.so" > /etc/php.d/apc.ini[/code] and add the setting in 1. - Restart Apache.
[code lang="shell" light="true"]apachectl graceful[/code] or [code lang="shell" light="true"]service httpd restart[/code]
You can now successfully log in to your WordPress admin.
WordPress behavior varies depending on the installation environment... It was a case study that made me feel again.
If you find yourself in a similar situation next time, you should first check the installation status of APC...