Articles
linardsmanymoods.com 12/8/2024 cpanel apache handlers add application/x-httpd-ea-php74___lsphp .php .php7 .phtml remove 8.2 version this speeds up the initial time to load on bluehost — background: https://alxwntr.com/bluehost-is-slow-and-heres-how-to-fix-it/ I recently built a new WordPress website for a client. They decided to maintain their own web host account as they have been using Bluehost for a number of years. I didn’t think this would be a problem until we finally launched the website and found that it took approximately 30 seconds to load each page! The exact same website loads instantly within my staging server hosted at SiteGround so I know that the issue is not with the website itself, but likely instead something with Bluehost and their server configuration. It turns out that there’s a known issue within Bluehost which causes a very high ‘Time to First Byte’ (TTFB). This is the measurement of time that it takes for the user’s web browser to acquire the first byte of data from the server before it can begin to load the resources from the web page itself. This issue appears to be caused by the PHP handler that is set within the Apache .htaccess file, which is specific to cPanel’s EasyApache 4 PHP implementation. It tells the website to use php 8.2 when loading php files, which are required for WordPress to function. That’s right. Simply changing this to PHP v7.4 is all that it takes to fix this. I can’t imagine why but I am certain that it does. There’s a caveat to this suggested fix. It appears that Bluehost has an automated process in place which will periodically append the initial PHP 8.2 code to your htaccess file. If this happens then the issue will begin to occur again and you’ll need to repeat this process.
WordPress core and many plugins are dependent on a scheduling system to perform time-based tasks. Scheduled tasks can be run in two ways: WP-Cron System cron WP-Cron: Pros: WordPress keeps user in WordPress (familiar) environment. API is much simpler to set up. WP-Cron puts tasks into queue to run at next opportunity (next page load.) i.e. task scheduled for 2 pm doesn't run due to no page activity at 2 PM but will run eventually, on next page load. System cron doesn't queue tasks. If task doesn't run at scheduled time no repeat runs will be attempted. Access to system cron may not be available through host provider. Eg. host is using shared infrastructure and denies access to system cron for security reasons. nb: pretty sure there is a workaround for this. Cron config allocatd per user, located in user home, runs system cron using user's config under restricted permissions. WordPress API is much simpler to set up and keeps user within WordPress environment. System cron on the other hand involves going to command line level (leaving WordPress environ.), and having familiarity with cron params and format used in setting up scheduled tasks. Cons: Page load dependent. Wp-Cron triggers scheduled tasks only on a page load. Eg. Task is set up to run at 2 pm but has page activity occurs until until 5 pm so task runs at 5 PM. WP-Cron, in the meanwhile, throws an error to indicate scheduled tasks did not run. System cron not as user friendly as WP-Cron. System cron config is done at CLI level by editing a cron config file. Must use cron params in correct format to set up triggered tasks.
