How to Use PHP-FPM with cPanel

PHP performance is an enduring issue for web hosts. PHP is the most widely used server programming language on the web by a big margin. The most popular content management systems and ecommerce applications are written in PHP, including WordPress®, Joomla, Drupal, Magento®, and dozens more. 

The ultra-fast PHP-FPM accelerates PHP execution on busy web servers, making it a valuable tool in the fight against slow sites and resource-constrained servers. 

This article takes a deep dive into how PHP-FPM works and explains how to deploy and configure it with cPanel & WHM. 

What is PHP-FPM?

PHP-FPM is an alternative PHP implementation that makes busy web applications faster while helping system administrators to control resource consumption on their server. 

A PHP implementation, also known as the runtime, interprets and executes code.  Traditional runtimes such as Apache’s mod_PHP do their work within the web server. That approach has advantages, but each connection consumes a chunk of the server’s resources for as long as it lasts. If there are too many concurrent connections, the server may run out of resources like memory altogether, impacting the performance of every site it hosts. 

PHP-FPM does things differently: it operates outside of the web server and uses a pool of worker processes to execute code. The workers are ready and waiting when a request comes in, and you can control how many workers are in the pool so they can’t multiply until they consume all the server’s RAM and processor time. 

It works like this:

  • Apache sends code to PHP-FPM over a high-speed binary interface called FastCGI.
  • A  supervisor process chooses a worker process from the pool and gives it the code. 
  • The worker executes the code, and the result is sent back to Apache, which sends it to the web browser. 
  • Once the worker is done, it returns to the pool to await another chunk of code to execute. 

If there are too many concurrent connections, some might have to wait for a free worker, but they will never consume all of the server’s resources. On a busy web server, worker pools are faster and more efficient than other strategies. 

Getting Started with PHP-FPM in CentOS and EasyApache

It is straightforward to activate and configure PHP-FPM in cPanel & WHM. You can choose which domains use it and set configuration variables that influence its behavior. 

The first step is to turn it on in the System PHP-FPM settings in WHM’s MutliPHP Manager. 

When you click Turn On, WHM makes PHP-FPM available, but it doesn’t activate it for all domains automatically. You can force all accounts on the server to use PHP-FPM by clicking Convert All Accounts to PHP-FPM. 

Alternatively, you can activate PHP-FPM for individual domains in the table at the bottom of this page. To turn it on for several domains at once, select them in the table and choose On in the drop-down menu. 

Configuring PHP-FPM in cPanel

Once you have activated PHP-FPM, you can configure both the system defaults and the settings for individual domains in MultiPHP Manager. 

Click the System PHP-FPM Configuration tab. 

In this section, there are three pool settings you can change. These are the default values that are applied to domain pools. 

  • Max Requests: The number of requests each worker process should execute before it restarts itself. This setting is useful for working around memory leaks. The default of 20  is acceptable for most web hosting scenarios, but you may want to increase it to between 40 and 60 on servers with heavy traffic.
  • Process Idle Timeout: How long an idle worker process will wait before shutting down. Idle processes consume resources, so we don’t want too many hanging around, but we don’t want to kill them too soon because it takes a while to start new ones. The default of 10 (seconds) may be too low for a busy server. 
  • Max Children: The maximum number of worker processes in each pool.  The default is 5. 

Many factors affect the optimal values for these settings, including the code your server runs and the amount of RAM it has. We wrote PHP-FPM Performance Tuning Basics to help you decide on the correct values for your server. 

Underneath the pool options are PHP INI directives. We surface several of the most useful in the interface, and you can find more information about them in PHP’s Runtime Configuration documentation. We’ll show you how to add other directives in the next section. 

In addition to system-wide configuration, you can also configure individual domains in the WHM interface. 

In the table at the bottom of MutliPHP Manager, click Edit PHP-FPM at the end of the domain’s row. The options that appear are identical to those in the system-wide configuration interface. 

How the cPanel PHP-FPM Module Works

Although the WHM interface contains the most useful configuration options, there are many more in the documentation. To add or modify them, you will need to edit configuration files on the server’s command line or in the cPanel & WHM File Manager. 

The two most important system-wide configuration files are:

  • /var/cpanel/ApachePHPFPM/system.yaml
  • /var/cpanel/ApachePHPFPM/system_pool_defaults.yaml

WHM doesn’t create these files because the system doesn’t need them, but you can create them yourself and add directives to override the defaults. 

touch /var/cpanel/ApachePHPFPM/system.yaml
touch /var/cpanel/ApachePHPFPM/system_pool_defaults.yaml

You may also have to create the directory with:

mkdir -p /var/cpanel/ApachePHPFPM/

In these files, enter only directives that differ from and override the system directives. For example, if you wanted to change the emergency_restart_threshold directive from the default of 0, the system_pool_defaults.yaml file would look like this:

The three dashes at the top of the file (———) are part of the YAML markup language and must be present. The configuration file won’t work without them. 

In the PHP documentation, you will find directives formatted with periods (.) and other symbols; syslog.facility, for example. When adding directives to configuration files, these symbols must be replaced with an underscore (_). For example, instead of syslog.facility, use syslog_facility. 

You can learn more about configuring the cPanel PHP-FPM module in Configuration Values of PHP-FPM and PHP-FPM Code and FileSystem Layout for EasyApache 4. 

Creating User Pools in PHP-FPM

Finally, we’ll look at manually creating and configuring domain-specific user pools in PHP-FPM. These are the worker pools used by sites hosted on your server’s domains. 

The PHP-FPM module creates a worker pool for a domain if it finds a configuration file in:

/var/cpanel/userdata/[user]/[domain].php_fpm.yaml

Replace [user] and [domain] with the relevant values for your server.  You can create this file or activate PHP-FPM for a domain in WHM and it will be created automatically. 

At a minimum, the file must contain the following information:

As with the system files, you can add directives to configure the user pools. After creating or editing the .yaml file, run the following command:

/scripts/php_fpm_config --rebuild

The script adds directives to Apache’s config file and restarts PHP-FPM, after which the new pool will be up and running. You can find more information about creating user pools in PHP-FPM User Pools.

Easy PHP-FPM Configuration with cPanel & WHM

PHP-FPM gives busy web servers a huge performance boost. Just as important, it helps web hosts to make the most of limited server resources, reducing the cost of providing an excellent hosting experience to clients and their users.

With cPanel & WHM, PHP-FPM can be activated in seconds and configured in an intuitive interface. If you need to dig deeper into PHP directives, our module makes building custom configurations for the runtime and worker pools straightforward. 

As always, if you have any feedback or comments, please let us know. We are here to help in the best ways we can. You’ll find us on Discord, the cPanel forums, and Reddit.

Dealing with Zoom Fatigue and Burn Out in 2020

We have all experienced the effects of mental fatigue after a long work week, and feelings of burnout near the end of a large scale project. 2020 has only amplified these effects with daily Zoom meetings and a lack of separation of work and home life. Many of us are stuck at home juggling our time between working in a spare closet (a.k.a. the home office), running a home school from the dining room table, and then ordering a double at the late-night bar and grill in the kitchen. Today, it’s easier than ever to become distracted and burned out on a daily basis.  

What can we do to break the spell of the new normal and regain focus and serenity? This article will look at why video conference meetings are mentally draining and how we can fight fatigue and burn out.

The Rise of Zoom:

Virtual meetings are nothing new for most business professionals, but never before have businesses relied on virtual platforms as much as they have this year.   

Zoom Stock Yahoo Finance

Zoom has become the big winner in 2020. Zoom’s mobile app has climbed to the top free downloaded app position in the Apple® App Store. The company’s second-quarter earnings put Zoom’s market cap at more than $129 billion and made them larger than IBM and AMD. A windfall for the company and a new normal for its customers, users are spending upwards of 20 hours per week staring into laptop screens on Zoom-based meetings and calls, creating a new set of issues revolving around “Zoom Fatigue.”

Effects of Zoom Fatigue:

“Zoom Fatigue” happens because of the way our brains process video conferencing information. When we are in regular face-to-face meetings, we observe each other in a single surrounding and focus our attention on the person speaking. In the virtual realm, our minds are overloaded with information coming from multiple places. Our attention becomes hyper-focused on the way we look, who is speaking, people’s expressions, our surroundings, their surroundings, and the list goes on and on. After a full day of stimuli, it’s no surprise everyone seems to end the day with little more than a blank stare.

How to Combat Zoom Fatigue:

The effects of Zoom Fatigue can be overwhelming, but never fear, we have collected essential tips that can help keep your Zoom Fatigue to a minimum.

  • Traditional forms of communication:  For the past decade, businesses have made a push to video conference software like Skype, GoToMeeting, and now Zoom. Video meetings have become our go-to source, and we have forgotten how we did conference calls just a decade ago. Use old-fashioned conference calls with the Zoom call-in number for discussions that don’t require face-to-face or a presentation. 
  • Use Alternate Communication Methods: Could the meeting have been handled via instant message or email? Is it another meeting about meetings? During our current COVID world, we have seen more than enough meetings that could have been an email. Limiting your face-to-face screen time is always a win in the new normal.
  • Reduce Visual Overload:  Staring at a group of co-workers on a screen can seem mind-numbing, but in all actuality, this can result in visual overload. Research has shown that when we are on screen with others, we focus on our face and expression for most of the meeting. Add to that the “Hollywood Squares Effect” of Zoom, and there is a lot to process. It’s natural to want to see yourself and everyone on the call, but limiting yourself to speaker view in Zoom will allow you to focus on the person speaking. Hiding or Turning your camera off can also help to regain focus. There are several options to hide your camera view during a call, from turning the video feed off in the video settings to hiding yourself from view in Zoom.  
  • Block out work time and breaks:  Keeping in constant communication with teams and managers has proven to be complicated in this new normal. There are only so many hours in a day, and when you add in all the meetings, it might be hard to find the time to complete your daily tasks. Skipping lunch or breaks is not the answer to being more productive. Taking a break after a long Zoom meeting can help you reset your attention and focus. Research shows that shifting between tasks continually without breaks can cost as much as 40% of someone’s productivity. As the saying goes, “work smarter, not harder,” make sure to take time to rest after a virtual meeting by leaving your workspace for a few minutes to get a glass of water, take a short walk outdoors, or relax. Also, try to ask for 25-minute or 55-minute meetings, so there is time allocated to have a visual rest, bio break, drink of water, or a simple stand-and-stretch.
  • Avoid multi-channel work: When you are in a face-to-face meeting with someone, are you usually using Slack® , browsing websites, or taking a phone call, all while the person is speaking? Hopefully not, because that would be just plain rude. So why do we feel this type of multi-tasking is acceptable while in Zoom and video conferences? Think about how many meetings you’ve been that someone says, “Can you repeat that? I was answering someone in Slack.” Honestly, if you don’t have time to attend the meeting, then reschedule it. To keep from getting burned out and suffering from Zoom Fatigue, make sure to close any needed work tabs in your browser and turn off notifications in your messaging app when you are in a video conference.

As we continue to evolve business in the new normal, it’s essential to focus on productivity and mental health. We at cPanel expect to see future benefits from the challenges and lessons we have learned while dealing with a global pandemic in 2020. 

As always, if you have any feedback or comments, please let us know. We are here to help in the best ways we can. You’ll find us on Discord, the cPanel forums, and Reddit.

Disk IO Errors: Troubleshooting on Linux Servers

Disk IO errors  (input/output) issues are a common cause of poor performance on web hosting servers. Hard drives have speed limits, and if software tries to read or write too much data too quickly, applications and users are forced to wait. To put it another way, storage devices can be a bottleneck that stops the server from reaching its full performance potential. 

Disk IO is not the only cause of slow servers, so in this article, we’ll explain how to use Linux IO stats to identify disk IO issues and how to diagnose and fix servers with storage bottlenecks. 

What Are the Symptoms of Disk IO Errors?

Because disk IO is so important to server performance, it can manifest in many different ways:

  • Increased website latency: sites hosted on the server take longer to load than expected. 
  • High server load: excessive IO can cause other components, including the CPU, to work harder. You can learn more about measuring server load in Troubleshooting High Server Loads.
  • You receive a chkservd notification: cPanel & WHM’s built-in chkservd monitoring tool will alert you if a service is unavailable. 
  • Slow email delivery and webmail interfaces: Email software needs to read data from and write data to the hard drives. 
  • Slow cPanel & WHM interfaces: Many cPanel & WHM features rely on fast hard drive or database access. 

If you observe any of these, high IO loads might be the culprit, but how do you know it’s a storage bottleneck rather than a problem with the network or processor?

Is Disk IO the Cause of Poor Performance?

From the user’s perspective, an IO bottleneck might look just like network latency, among other problems. It’s prudent to make sure that the server’s storage is the real culprit so we don’t waste time and money fixing the wrong problem.

We’ll need to use diagnostic tools on the server’s command line, so log in with SSH. 

First, let’s see if the CPU is waiting for disk operations to complete. Type “top” and press enter. This launches the top tool, which shows server statistics and a list of running processes. The wa metric shows IO-wait, the amount of time the CPU spends waiting for IO completion represented as a percentage. 

IO-wait is one of a series of processor activity figures in the %CPU row. It also includes:

  • us: time spent on user processes.
  • sy: time spent on system processes. 
  • id: idle time.

On the single-CPU server in the example images, these are straightforward to understand. Our server’s CPU spends 59 percent of its time waiting for IO input instead of processing data.  An IO-wait above 1 may indicate the server’s hard drives are struggling to supply the processor with data. 

On multi-core and multi-processor servers, it’s a little more complex. Because top adds the CPU utilization figures for all cores, they can exceed 100 percent. As a rule, if the IO-wait percentage is bigger than 1 when divided by the number of CPU cores, then the processor must wait before it can process data. For example, on a 4-core system with a wa of 10 percent, the IO-wait is around 2.5, so the processors are forced to wait. 

IO-wait times don’t always mean there is an IO bottleneck, but it is a valuable clue, especially when it correlates with observed performance issues. To discover the cause, we need to investigate further with vmstat, which shows statistics for IO, CPU, and memory activity, among others. 

vmstat 1 10

We’re asking vmstat to show us ten readings at one-second intervals. The first line shows average IO stats since the last reboot, and the subsequent lines show real-time statistics.

We are interested in the io column, which is divided into input and output. It shows that large amounts of data were written to a storage device throughout the test period. Compared to the average loads in the first row, the IO system is being seriously stressed. 

Next, we want to know which hard drive is under load. To find out, we can use iostat. 

iostat -md

The -m option tells iostat to display statistics in megabytes per second, and -d says we’re interested in device utilization. 

The device called vda is writing 730 MB of data each second. Whether that’s a problem depends on the capabilities of the server and the device, but with the observed performance degradation and large IO wait times, it’s reasonable to conclude that excessive disk IO on vda is the cause of our issues. 

There is one other piece of information that could help us narrow things down: the mount point of the vda device. The mount point is the directory on the server’s filesystem the device is connected to. You can find it with the lsblk command.

We can see that vda has one partition called vda1 and that it’s mounted on the root of the filesystem (/).  On this server, that information is not particularly helpful; it only has one mounted device. However, on a server with several storage devices, lsblk can help you to figure out where the data is being written and which application is writing it. 

How To Fix Disk IO Issues

Once you have identified the affected drive, there are several approaches you can take to mitigate disk IO issues.

For example, you may want to try changing a few settings to see if performance improves before you upgrade hard drives or memory. Three hard drive configuration settings you should try changing first are:

1. Turn on write caching

2. Turn on direct memory access

3. Upgrade Server Hardware

Here’s how to do that:

Turn on Write Caching

Write caching collects data for multiple writes in a RAM cache before writing them permanently to the drive. Because it reduces the number of hard drive writes, it can improve performance in some scenarios. 

Write caching can cause data loss if the server’s power is cut before the cache is written to the disk. Don’t activate write caching if you want to minimize the risk of data loss. 

The hdparm utility can turn write caching on and off. It may not be installed by default on your server, but you can install it from CentOS’s core repository with:

yum install hdparm

The following command turns write caching on:

hdparm -W1 /dev/sda

To turn write caching off, use:

hdparm -W0 /dev/sda

Turn on Direct Memory Access

Direct Memory Access (DMA) allows the server’s components to access its RAM directly, without going via the CPU.  It can significantly increase hard drive performance in some scenarios. 

To enable DMA, run the following command, replacing /dev/hda with your hard drive:

hdparm -d1 /dev/hda

You can turn DMA off with:

hdparm -d0 /dev/hda

DMA isn’t available on all servers and, with virtual servers in particular, you may not be able to modify hard drive settings.

Upgrade Server Hardware

If configuration tweaks don’t solve your IO issues, it’s time to think about upgrading, replacing, or reorganizing the server’s hardware. 

  • Upgrade the hard drive: If the drive is slow, consider upgrading to a faster spinning disk drive or a solid state drive (SSD) that can better cope with the IO load. 
  • Split the application load between hard disks: Add hard drives and divide the IO load between them. You may also want to consider giving the operating system’s root filesystem its own drive, so that the operating system and cPanel & WHM don’t have to compete with user applications.
  • Increase the server’s memory: If applications can cache more data in RAM, they will not need to read from and write to the filesystem as often.  For some applications, an in-memory cache such as Memcached or Varnish may improve performance while reducing disk IO. 
  • Check the RAID array hardware: A malfunctioning RAID controller can degrade IO performance. 

Disk IO bottlenecks can be tricky to diagnose, but the process we’ve outlined here will help you to quickly determine whether you have an IO problem, which drives are affected, and what you can do to improve your server’s performance. 

As always, if you have any feedback or comments, please let us know. We are here to help in the best ways we can. You’ll find us on Discord, the cPanel forums, and Reddit.

Server Housekeeping with cPanel

Servers are your virtual home and, just like your real home, they can become cluttered with unwanted junk.  In the case of servers, it’s not trash but data you have to kick to the curb every once in a while. 

Without a regular clear out, data accumulates until it fills the server’s storage devices. Servers need to be able to write data to their hard drives. When there’s no space to store new stuff, the performance takes a hit and some software will stop working altogether. 

We recommend that you keep at least 10 percent of the server’s storage free, which means you will occasionally have to check disk space and find unused data to delete. In this article, we show you how to do just that with cPanel and the disk management tools on your Linux® server. 

How to Manage your Hard Drive Space in cPanel

There are a couple of prerequisites you should know about before we explain how to manage hard drive space. 

  • You need to be able to log in as the root user to manage files outside of your home directory. While any user can manage their own files, only the root user can monitor and delete files owned by other users.
  •  You will need to log in to your server using SSH to run file management commands. 

When you’re concerned about disk space, WHM’s Disk Usage tool should be your first destination. It checks Linux disk space and displays the results in an intuitive interface. You will find it under System Health in the WHM sidebar menu. 

Disk Usage shows a list of storage devices, their sizes, and how full they are. The number of devices and their names differ depending on the configuration of the server, but if they are more than 90% full, you should delete old data. 

In the above image, we see that one of the hard drives on this server is dangerously full. To find out which files are causing the problem, we log in with SSH and use the command line to investigate. 

Check Disk Command

First, we’ll use the df tool to check disk space on the server’s hard drives. It provides more or less the same information as Disk Usage, but it’s helpful if you want to start your investigation on the command line instead of in WHM.

 Run the command:

df -h

The -h flag tells df to use human-readable units instead of spitting out confusing byte counts. The output looks something like this:

You can ignore the tmpfs devices; they’re virtual disks stored in memory and may not be present on your server. We’ve underlined the interesting entry: the disk named /dev/vda1, which is mounted on the root (/) of the filesystem,  is 92 percent full. 

Now we have verified that a disk is nearly full, we have to find out which files are responsible. For that, we use du:

du -sh /*

The -s option produces a summary of the data so we can more easily identify large files and directories. As before, -h tells du to output sensible units. 

At the end of the command is a file argument. In the last step, we found the overfull drive was mounted on “/”, so that’s where we start our search. The * means everything inside the / directory. 

Here’s a section of the output from du. 

As you can see, the /var directory consumes 40 GB, dwarfing the amount of data in the other directories. So, we run du again on /var. 

 It’s difficult to spot the largest files when there are lots of them, so we’ll use sort to print big files first and head to grab the top 10. 

du -sh /var/* | sort -rh | head -n 10

We’ve found the culprit! There is an enormous 39GB file in /var. 

Now we have to decide whether we can safely delete it or not. Deleting a file is irreversible, so you should do some research to verify that it doesn’t contain data that matters to your or the server. 

We know that it’s safe to remove /var/largefile.log, so we can delete it with the rm command:

rm -f /var/largefile.log

If you want to delete a directory of files, use this command instead:

rm -rf /var/largedirectory

The -f option means “force”. It tells rm to delete files without asking permission first. The -r option means “recursive,” and it makes rm delete everything inside a directory. 

If we go back to WHM’s Disk Usage page, we see that the device is no longer full, and the problems caused by the lack of storage space have been resolved. 

Disk space problems are rarely caused by a single large file. In reality, you’ll be dealing with lots of smaller files, but you can use the same process of identification and deletion with cPanel and the command line to find and remove any quantity of unwanted data. 

As always, if you have any feedback or comments, please let us know. We are here to help in the best ways we can. You’ll find us on Discord, the cPanel forums, and Reddit.

How to Monitor PHP Error Logs in WordPress and cPanel

PHP error logs are one of the most useful tools for diagnosing web hosting issues. It’s often difficult to find the cause of unexpected behavior in WordPress® and other PHP applications. PHP error logs, including WordPress logs,  can help you to spot problems and identify the offending plugin, theme, or custom code. 

In this article, we describe what PHP error logs are and why they’re useful, before explaining how to use cPanel & WHM to activate and configure both WordPress logs and the PHP runtime’s logging functionality.  

What is a PHP Error Log?

A PHP error log lists warnings and error messages, which are generated by the language runtime and saved to a file. WordPress is written in PHP, so it handles WordPress’s error messages and logging. 

Errors occur for lots of reasons. A line of code might have a typo in it, or the code might be fine, but something unexpected happens when it’s executed. Either way, the developers want to let you know, so they write code to log a message to a file. Error logs are a time-ordered list of these messages. 

Error logs are incredibly useful for figuring out why WordPress isn’t behaving as you think it should. If it’s consuming excessive server resources, a plugin is broken, or pages don’t load, the logs can tell you why. If you’re in a “White Screen of Death” situation where WordPress isn’t working at all, the logs might be the only way to see what’s going on under the hood.

How to Monitor WordPress Logs in cPanel

Before you can troubleshoot with logs, you’ll need to tell WordPress or PHP to start logging. Error logs are off by default because logging consumes server resources.  They can also be a security risk if the wrong person sees them; logs sometimes have clues about potential vulnerabilities. 

We’re going to look at two approaches to configuring error logging in cPanel. They are:

  • Activating WordPress logging via the wp-config file. 
  • Activating PHP logging via the php.ini file. 

Both can be done quickly in cPanel & WHM. 

WordPress Error Logs with Wpconfig.php

The wp-config.php file contains WordPress’s configuration, and, with a couple of lines of code, you can turn on debugging mode and tell WordPress to write errors to a log. 

First, fire up cPanel’s File Manager, which you will find in the main page’s Files section. 

Your WordPress site is probably in the root or a subdirectory of public_html, although it might be somewhere else if your server has a non-standard configuration.

Click on the directory containing the site and find the wp-config.php file in the right-hand pane. Select it and click Edit in the menu bar. 

The file opens in cPanel’s text editor. Scroll down to the line that reads: 

/* That's all, stop editing! Happy blogging. */

Add the following code above that line and then click Save:

define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

We’re telling WordPress to turn on debugging mode and output error messages to the log file. We also tell it not to display errors in the interface, because that’s not a good look for a production website. 

WordPress will now write error messages to a file called error.log in the wp-content directory, which is in the root directory of your WordPress site. 

You can use the cPanel File Manager and text editor to open this file and see the error messages. The most recent messages are at the bottom of the file. They tell you the type of error and which code triggered it, allowing you to track down the plugin or theme file responsible. 

When you have diagnosed the problem, be sure to delete the logging code you added to the configuration file. The error file will keep growing and will eventually consume a large chunk of your disk allocation. 

How To Log PHP Errors Beyond WordPress

The method outlined above is great if you want to manage logging through WordPress, but what if you want to log errors for other content management systems and applications? 

To achieve widespread logging, you can add code to the php.ini file, which you can edit in cPanel’s MultiPHP INI Editor. You will only be able to edit this file if your web hosting environment allows it. 

Select the Editor tab and then a location in the dropdown menu. cPanel displays the existing configuration file, which may be blank. 

Add the following to the text entry field and click Save

log_errors = true
error_log = /home/user1/logs/error.log
display_startup_errors = false
display_errors = false
html_errors = false
error_reporting = E_ALL
log_errors_max_len = 0

These directives tell the runtime to log errors to the file designated with error_log, which you should change to your preferred location. We’ve turned off startup errors because they are rarely relevant for debugging misbehaving applications. We also instruct PHP not to display errors in web pages because we don’t want users to see them. 

Click Save, and PHP will start to log errors to the file you chose. You can access the log via the cPanel File Manager or by logging in with SSH. 

The php.ini directives we used are suitable for most web servers, but you can use many other directives to configure PHP. To learn more, take a look at the list of php.ini directives in the language’s documentation and our MultiPHP INI Editor documentation.

Once you have used the logs to figure out your issue’s source, remove the code you just added or change the log_errors value to false to deactivate logging.

Efficient Issue Resolution with PHP Error Logs and cPanel

Logs are an enormously useful tool for diagnosing and fixing unexpected behavior in WordPress sites and other web applications. With cPanel & WHM, it’s straightforward to activate and deactivate logging, reducing the time you spend hunting down elusive issues. 

As always, if you have any feedback or comments, please let us know. We are here to help in the best ways we can. You’ll find us on Discord, the cPanel forums, and Reddit.