Today, when upgrading to wp2.7, I encountered the first server 500 internal server error, and then I waited... The database connection and PhpMyAdmin are working fine... There is no problem with the database. I tested uploading a static page test.html, and it displayed correctly. There is no problem with Apache. I tested uploading test.php with phpinfo();? The 500 internal server error did not disappear, and it continued to display... The problem arose, mainly with PHP. I searched the internet and suspected it was a phpcms issue. I checked the directory permissions and changed the permissions of all files under the wp root directory to 700. Refresh phpCMS... Wait... Test test.php?... Passed. Reopen... Everything is OK.
I believe that experienced WP users have encountered similar problems. There are also many requests for help online. Novices often directly perform the following steps: 1. Backup data 2. Reinstall 3. Restore data. Or they seek help from major forums and then wait. Today, I also experienced the first strike of WP, but luckily, I have encountered it many times before when using boblog+free virtual hosting. Please pay attention to the free virtual hosting mentioned here, which will be explained below. Okay, enough nonsense.
First, let's understand PHPCMS (PHP Content Management System). You can refer to http://baike.baidu.com/view/110598.htm for more information. In simple terms, PHPCMS is a software that provides underlying support and management for various PHP applications (blogs, forums, online stores, SNS) in terms of system management. In other words, if a server hosts multiple blog systems, such as 20 WordPress, unified management is definitely needed. Many current virtual hosts are in this situation, where the server allows the allocation of server resources into multiple independent parts for independent management by multiple users. However, once independent management is implemented, some users will definitely make specific settings for their independent parts. However, these settings do not meet the management needs of CMS, such as directory permission management. This is where the problem arises. CMS disables user permissions, but the user's independent system still requests these permissions from CMS. If the request is successful, there is no problem. Once it fails, CMS may take action against the user's unauthorized operation, such as disabling functionality. In WP, it is very likely that CMS cancels the PHP support for the user's directory, which will make the user depressed. Without PHP, what is WP? This is followed by the 500 internal server error in the WP system.
Most domestic virtual hosts are managed using CMS. Most paid hosts have relatively relaxed user permission management and generally do not have significant restrictions. Therefore, there are many WP and BoBlog instances. However, some domestic virtual hosts have stricter restrictions on user permissions and limit user operations. Therefore, many users of these hosts cannot install WP at all, or they successfully install it and suddenly encounter errors such as internal server error one day, and then seek help from administrators to solve the problem. If there is a solution, it's fine. If not, they can only cry and reinstall. I am just an unlucky example.
After analyzing the problem, let's talk about how to solve the 500 internal server error. Let's not talk about the reasons. It's just that you don't have server authorization permissions (usually rewrite), but your WP requires such permissions, such as directory deletion, renaming, or file movement, etc. My problem today is that I forgot to change the permissions to 700 before uploading. 700 is the UNIX/LINUX file permission, which can be referred to as Linux/UNIX File Permission Management. It means that except for the owner, who has all permissions, no other users have the permission to modify or delete. The purpose is to give the owner the maximum permission. Now, the specific problem we are facing is that if your directory is not set like this or you don't modify the permissions, and you try to delete it with WP, the result will definitely be insufficient permissions. However, for the purpose of protecting other users' files, CMS will consider it as an unauthorized operation and may take certain measures, such as disabling your script parsing permissions (PHP is one of them). This is a significant way to disable WP parsing, and then the dreaded 500 internal server error appears!
The solution is that you must ensure that your hosting provider gives you sufficient permissions, at least rewrite. Most domestic paid hosts can provide this, but it may not be the case for free hosts. After all, they are free, and some restrictions are necessary, just like restricting your web traffic. I use Meicheng VPS (ChinaNet Telecom Data Center) + Xirang virtual hosting (dual-line) as a backup. There should be no problem with VPS permissions, and Xirang's hosting also supports rewrite+overwrite, so there is no problem with permissions.
The problem must lie in the user's own settings for file and directory permissions. If you use a LINUX host and your system is Windows, and you upload via FTP, there is no problem as long as the files on your computer are not set to read-only. The server will default to setting your FTP account as the file owner with the highest permission: 7. At the same time, the server's Apache management group user (usually) also sets the file permissions to 7. In this way, as long as there is no restriction on your server, you can modify the local file properties (cancel read-only) and then upload again to solve the problem. Then remember to contact the administrator and reset your permissions. Be sure to contact the administrator because they have the highest permissions and can help you modify the disabled script parsing. Then the problem can be solved. The service quality of most domestic hosting providers is still good, and it can be resolved within half an hour. Otherwise, you can consider changing hosts. Free hosts are relatively slower, after all, they are free.
Now let's talk about uploading to a UNIX/Linux host on a Linux system. I believe that users who have used it have had this experience. If you upload a file to a server using FTP without specific settings on the server, the permission settings of the file will be preserved. This is called a permission array in the operating system, which facilitates file management between two terminals (your host and the server). For example, if there is a file set to 700 on my host, it will be 700 on the host. Okay, there is no problem with 700. What if the permission setting is very low? The problem arises. The file will retain the permission setting when it reaches the server. Then we use WP to perform some rewrite operations, such as modifying the directory structure. I don't need to say it, right? 500 internal server error is the most common error in CMS+WP. Cry. Friends using free hosts, send an email to the administrator and then just wait. If it is a foreign host, just continue crying. I don't know when it will be resolved. I have used the free host provided by yahoo.com before. After sending the email (the time is not good, 9 am in the morning), it took a full 20 hours for the administrator to reply and fix it. If your website has 1000 IPs per day, the loss goes without saying.
Therefore, Linux users, please remember to sudo before uploading and change all file permissions to 777, at least 700. Then upload. Otherwise, one day, the internal server error will come to you suddenly. Virtual host users must contact the administrator as soon as possible to lift the PHP ban. Don't be foolish and back up, reinstall, and restore. It's not worth it. I have encountered it many times when using free space.
If you are using VPS or higher, you can directly go to your CMS backend, modify the disabled part of your blog, reset CMS, and the problem will be solved within 1 minute.
Finally, through the explanation of this practical process, I would like to remind all bloggers: Remember, what is most important for LINUX hosts? Permissions! Before uploading, be sure to modify file permissions.
If any readers have any questions or if there are any issues with this article, please leave a comment. Welcome to reproduce, modify, and publish this article under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License. Please indicate the author's source when reproducing, thank you, CG.