WordPress and the Shared Hosting Environment
WordPress officially recommends a dedicated hosting environment. To quote,
Just like flowers need the right environment to grow, WordPress works best when it’s in a rich hosting environment.
Not required, but recommended for better security
Hosting is more secure when PHP applications, like WordPress, are run using your account’s username instead of the server’s default shared username. The most common way nowadays for hosting companies to do this is using suPHP. Just ask your potential host if they run suPHP or something similar.
However, these recommendations are not mandatory. And WordPress will also work in a shared hosting environment, which is the most economical of all hosting environments. The question is, what limitations will a WordPress installion face in a shared hosting environment, versus a dedicated environment?
The following are some of the limitations your WordPress installation will face in a shared hosting environment (that uses shared IP hosting).
Inability to update WordPress and WordPress plugins through the Dashboard
In a shared hosting environment, PHP is run by the web server, and not the FTP account holder (you). In other words, you don’t have “suPHP.” When you click on the links to update WordPress (or WordPress plugins) through the Dashboard, you will be prompted for your FTP credentials. But no matter how many times you enter them, the update won’t proceed. Your only option to update WordPress and WordPress plugins is through an FTP program, or by running Subversion scripts in a terminal (provided, you installed WordPress and its plugins via Subversion).
Possible issues with Chron Jobs
In some shared hosting environments, the website only exists when it is accessed. Therefore, scheduling your WordPress installation to perform different tasks at certain times may not work as planned. The tasks may be completed in a sudden flurry when some random user accesses the website.
HTTPS Security cannot be implemented
In a shared hosting envronment that uses shared IP hosting, HTTPS security cannot be implemented to secure the login page, the contact form and the admin area. This is because HTTPS requires a dedicated IP address, and your website’s IP address is usually assigned from a pool of IP addresses whenever it is accessed. However, the login credentials can be hashed using the Chap Secure login plugin.
Dynamic Plugins generate Garbage Files
Some plugins that serve dynamic content (such as the QR Code Widget that creates QR code images for pages) may generate tonnes of garbage files. This is usually because these plugins were designed to be used with PHP running as the FTP account holder (suPHP). Fortunately, you will always find a substitute plugin that will do the job.
“PHP out of memory” Errors
Sharing the server side PHP process means rationing PHP resources across different WordPress installations. Usually, a shared hosting environment will provide you with sufficient PHP memory. But some plugins like WordPress Backup to DropBox currently require 64 MB of PHP memory, which exceeds the quota of some shared hosting environments. The good news is that some shared hosting environments allow you to purchase additional memory. The bad news is that you will only find out your plugin’s memory requirement through trial and error. WordPress plugins do not list memory usage in their specifications beforehand.
Possible Issues with Caching
Shared Hosting environments sometimes run their own caching processes (usually Squid) to reduce bandwidth costs. These can sometimes conflict with your WordPress caching plugins. I strongly recommend Quick Cache for Caching WordPress in a shared hosting environment. Quick Cache has a special setting for shared hosting environments. Keep mind though, that some shared hosting environments may limit some extra features of Quick Cache as well. For example, Quick Cache can work faster with GZIP compression enabled. But this requires a module on the Apache sever to be turned on (mod_deflate). But many shared hosting environments disable this module because it consumes a lot of server side resources.
Inability to Enable certain PHP modules
Every now and then, you may come across a quirky plugin that would work better of certain PHP settings are customized. But in a shared hosting environment that shares the same PHP installation, it is not possible to customize the PHP configuration. You would rarely need to do so, but be warned.
The Redeeming Factor
Despite all of the above, WordPress continues to thrive in the shared hosting environment. And unless you are building a dot com startup, the costs of dedicated hosting are unjustified. While you continue to customize your WordPress installation to the shared hosting environment, It is important to develop an understanding of its limitations, which are sparsely documented.
This article is just wrong.
For a start, a “rich hosting” environment is totally different to a dedicated server (in a lot of ways they are, in fact opposites).
Your statements about not being able to update via FTP are also wrong – in fact the whole reason you are asked to give FTP credentials to the server is so it can make a “loop back” connection to update the website as your user rather then the web user.
Although the most common practice is to have 1 HTTPS cert per IP address, it is practical to bypass this using SNI – although browser support for this is limited (but if you are using it for login auth purposes this may well be an acceptable compromise, as it works with almost all new browsers)
Caching websites in the manor you described is actually reverse caching. It does not save bandwidth, it reduces page load times and CPU overhead at the expense of accuracy of statistics in some cases (like not always recording image hits). This should not affect hit counts or user views statistics, although it might affect images recorded as being downloaded from the server. It can also be used to balance resources and provide better performance and fault tolerance, so in some cases is might be better then a dedicated server.
You seem to have a misunderstanding of what SuPHP is (and that is how I found this site). SuPHP is a mechanism to “harden” shared hosting sites against various attacks on other users on the shared host. It is an alternative to MPM-ITK or MTP-Peruser (for example), done at the PHP rather then container level – and works by creating an environment “owned” by the correct user rather then the shared user.
(Also, minor thing, you may want to edit Chron to Cron in your post).