How to Raise the WordPress Upload File Size Limit

A 2 MB upload cap can stop a simple image update in its tracks. That small number is your WordPress upload limit, and it can turn a five-minute task into a frustrating support ticket.

Your WordPress upload file size limit is usually set by your hosting environment and PHP settings, not by WordPress itself. The good news is that you can often raise it in a few minutes without touching anything risky.

At ZADiC, we believe hosting should remove roadblocks, not create them. Start by finding the setting that is actually holding your site back.

What Sets the WordPress Upload File Size Limit

WordPress shows the upload limit, but it doesn’t always control it. Think of it like a doorway with several locks. Raising one lock won’t help if another one stays closed.

Check the number WordPress reports

Open your WordPress dashboard and go to Media > Add New. Near the upload area, WordPress displays the maximum file size it currently accepts.

Write that number down before changing anything. If it says 8 MB and you need to upload a 25 MB product video, you know the cap is the problem. If it says 64 MB but your file still fails, something else is getting in the way.

You can also check Tools > Site Health > Info > Server for PHP details. The WordPress community troubleshooting guidance shows why upload limits vary so much between hosts and server setups.

Find the layer that owns the limit

Most WordPress upload problems come from one of these places:

PHP limits set by your hosting account or server.
A Multisite network cap set by the network administrator.
Web server rules such as Apache, Nginx, or LiteSpeed settings.
A security layer that blocks a large request before WordPress sees it.

The reported WordPress upload limit is the visible result. Your hosting configuration is often the source. Make a current backup before editing settings, then change one method at a time.

Match the PHP Settings That Control Uploads

PHP controls how large an uploaded file can be and how long the server gives it to finish. One setting alone isn’t enough.

Use values that work together

These settings should be sized as a group. For a 64 MB file upload target, this is a sensible starting point:

PHP setting	What it controls	Starting value
`upload_max_filesize`	Maximum size of one uploaded file	`64M`
`post_max_size`	Total size of the upload request	`72M`
`memory_limit`	Memory PHP can use during processing	`128M`
`max_execution_time`	Time PHP can run before timing out	`300`

The post_max_size value needs to be larger than upload_max_filesize. File data, form fields, and request overhead all count toward that total.

Raising upload_max_filesize to 64M won’t help if post_max_size remains 32M. The smaller rule still blocks the upload.

Pick a limit your site can support

Don’t set every value to 1 GB because it feels safer. A larger cap lets users send larger files, but it doesn’t add server memory, disk space, or upload speed.

Set the limit around the files you need to upload. A site importing large theme packages may need 64 MB or 128 MB. A site that only adds compressed images may need far less.

A bigger WordPress upload limit should solve a real need. It shouldn’t open the door wider than necessary.

Raise the WordPress Upload Limit in cPanel

For many shared hosting accounts, cPanel is the cleanest place to make this change. You don’t need a plugin, and you don’t need to edit WordPress core files.

Change PHP values in MultiPHP INI Editor

Inside cPanel, look for MultiPHP INI Editor. Some hosts use a slightly different name, but the purpose is the same: it lets you adjust PHP settings for a domain.

Open MultiPHP INI Editor and select the domain running WordPress.
Find upload_max_filesize, post_max_size, memory_limit, and max_execution_time.
Enter matching values, such as 64M, 72M, 128M, and 300.
Save the changes, wait a few minutes, then return to Media > Add New to confirm the new limit.

If you manage several domains, make sure you select the right one. Changing the limit for a parked domain won’t help the live WordPress site.

Get hosting support when controls are locked

Some shared hosting plans lock PHP values at the server level. In that case, pasting random code snippets into WordPress can create more trouble than progress.

Our ZADiC WordPress hosting options pair cPanel access with one-click setup, backups, security services, and 24/7 human support. If your business depends on larger media files, migrations, or product assets, you need a hosting team that can check the real server limit and help fix it.

Use a Configuration File When cPanel Isn’t Available

A configuration file can work well when your host permits local PHP overrides. It can also be the right option when cPanel doesn’t expose the setting you need.

Try a `.user.ini` file first

Open your hosting File Manager and locate the WordPress root folder. This is the folder containing wp-config.php, wp-admin, wp-content, and wp-includes.

Create or edit a file named .user.ini. For a 64 MB upload target, add upload_max_filesize = 64M, post_max_size = 72M, memory_limit = 128M, and max_execution_time = 300.

Some servers take several minutes to read a changed .user.ini file. Check the Media screen again after waiting, then test with a real file below the new cap.

A helpful comparison of .user.ini and .htaccess upload methods explains why the right file depends on the server running your site.

Use `.htaccess` with care

The .htaccess method is for Apache-based hosting that allows PHP directives in that file. Nginx doesn’t read .htaccess, and some hosts block these changes even on Apache.

A bad line in .htaccess can trigger a 500 server error. Back up the file first. If the site errors after your edit, remove the added lines and use cPanel or hosting support instead.

We don’t recommend relying on wp-config.php as your first choice. Many hosts disable PHP overrides from WordPress files, so the change may do nothing.

Adjust Multisite Upload Caps Separately

WordPress Multisite adds one more rule to the mix. You can raise PHP limits and still hit a smaller network-wide upload cap.

Check Network Admin settings

Go to My Sites > Network Admin > Settings > Network Settings. Find the Upload Settings area and look for Max upload file size.

This field uses kilobytes. For a 64 MB limit, enter 65536. Save the setting, then test from a subsite dashboard.

The network setting can’t override a lower PHP limit. PHP still needs to allow at least the same file size, with enough room in post_max_size for the full request.

The Multisite upload cap overview is useful if the network setting and server setting don’t match.

Keep the policy practical

Network administrators should set limits based on what member sites truly need. A portfolio network may need higher image limits. A network with many casual contributors may need tighter controls.

File size isn’t the only rule. WordPress can restrict file types, while your hosting account can still run out of available storage. A higher upload cap doesn’t remove those limits.

Fix Upload Errors That Aren’t Size Problems

Sometimes you raise the limit and the upload still fails. That’s your signal to read the error instead of raising every number again.

Match the error to the likely cause

Common upload failures point to different layers:

An HTTP 413 error often points to a web server, proxy, or security rule.
A 500 error after editing configuration files usually means the server rejected a directive.
A message naming the maximum file size points back to PHP or Multisite settings.
An upload that starts but fails later may involve a timeout, low disk space, or an unstable connection.

Check your hosting error logs if they’re available. The exact error message can save hours of guesswork.

Know when better hosting is the answer

A larger limit doesn’t make a crowded server faster. Bulk imports, WordPress backup restores, high-resolution media libraries, and large WooCommerce catalogs need more than a bigger number in PHP.

That is where a hosting upgrade can make sense. Our managed Web Hosting Plus and VPS plans give growing sites more room to handle demanding work, while our support team can help you choose the right path.

A bigger plan isn’t a shortcut around every issue. It does give your site more breathing room when large files are part of the job.

Keep Larger Uploads Safe and Sensible

Larger uploads are useful, but they should stay controlled. A 500 MB file can fill storage quickly, slow down backups, and create a long failure if the connection drops near the end.

Set limits around real file needs

Use the smallest practical cap for your workflow. A site importing full WordPress backups needs a different allowance than a brochure site with a few image galleries.

Review who can upload files, too. Limit administrator access, keep WordPress updated, and use security monitoring to catch suspicious activity before it becomes a bigger problem.

Treat uploads and backups differently

An uploaded file is not a backup. Before changing PHP settings or importing a large archive, confirm that you have a recent backup you can restore.

For public video, a dedicated video platform can be a smarter fit than filling the WordPress Media Library with huge files. Your website stays lighter, and visitors get a better viewing experience.

A Better Upload Experience Starts With the Right Limit

That frustrating 2 MB message isn’t a WordPress dead end. Check the displayed cap, match the PHP settings, and adjust the hosting or Multisite rule that is actually blocking the file.

The right WordPress upload limit is large enough for your work and sensible for your server. With dependable hosting behind it, uploads stop feeling like a fight and get back to being a routine part of running your site.

Submit a Comment Cancel reply

What's New?

WordPressHow to Raise the WordPress Upload File Size LimitA 2 MB upload cap can stop a simple image update in its tracks. That small number is your WordPress upload limit, and it can turn a five-minute task into a frustrating support ticket. Your WordPress upload file size limit is usually set by your hosting environment and PHP settings, not by WordPress itself. The good news is that you can often raise it in a few minutes without touching anything risky. At ZADiC, we believe hosting should remove roadblocks, not create them. Start by finding the setting that is actually holding your site back. What Sets the WordPress Upload File Size Limit WordPress shows the upload limit, but it doesn’t always control it. Think of it like a doorway with several locks. Raising one lock won’t help if another one stays closed. Check the number WordPress reports Open your WordPress dashboard and go to Media > Add New. Near the upload area, WordPress displays the maximum file size it currently accepts. Write that number down before changing anything. If it says 8 MB and you need to upload a 25 MB product video, you know the cap is the problem. If it says 64 MB but your file still fails, something else is getting in the way. You can also check Tools > Site Health > Info > Server for PHP details. The WordPress community troubleshooting guidance shows why upload limits vary so much between hosts and server setups. Find the layer that owns the limit Most WordPress upload problems come from one of these places: PHP limits set by your hosting account or server. A Multisite network cap set by the network administrator. Web server rules such as Apache, Nginx, or LiteSpeed settings. A security layer that blocks a large request before WordPress sees it. The reported WordPress upload limit is the visible result. Your hosting configuration is often the source. Make a current backup before editing settings, then change one method at a time. Match the PHP Settings That Control Uploads PHP controls how large an uploaded file can be and how long the server gives it to finish. One setting alone isn’t enough. Use values that work together These settings should be sized as a group. For a 64 MB file upload target, this is a sensible starting point: PHP settingWhat it controlsStarting valueupload_max_filesizeMaximum size of one uploaded file64Mpost_max_sizeTotal size of the upload request72Mmemory_limitMemory PHP can use during processing128Mmax_execution_timeTime PHP can run before timing out300 The post_max_size value needs to be larger than upload_max_filesize. File data, form fields, and request overhead all count toward that total. Raising upload_max_filesize to 64M won’t help if post_max_size remains 32M. The smaller rule still blocks the upload. Pick a limit your site can support Don’t set every value to 1 GB because it feels safer. A larger cap lets users send larger files, but it doesn’t add server memory, disk space, or upload speed. Set the limit around the files you need to upload. A site importing large theme packages may need 64 MB or 128 MB. A site that only adds compressed images may need far less. A bigger WordPress upload limit should solve a real need. It shouldn’t open the door wider than necessary. Raise the WordPress Upload Limit in cPanel For many shared hosting accounts, cPanel is the cleanest place to make this change. You don’t need a plugin, and you don’t need to edit WordPress core files. Change PHP values in MultiPHP INI Editor Inside cPanel, look for MultiPHP INI Editor. Some hosts use a slightly different name, but the purpose is the same: it lets you adjust PHP settings for a domain. Open MultiPHP INI Editor and select the domain running WordPress. Find upload_max_filesize, post_max_size, memory_limit, and max_execution_time. Enter matching values, such as 64M, 72M, 128M, and 300. Save the changes, wait a few minutes, then return to Media > Add New to confirm the new limit. If you manage several domains, make sure you select the right one. Changing the limit for a parked domain won’t help the live WordPress site. Get hosting support when controls are locked Some shared hosting plans lock PHP values at the server level. In that case, pasting random code snippets into WordPress can create more trouble than progress. Our ZADiC WordPress hosting options pair cPanel access with one-click setup, backups, security services, and 24/7 human support. If your business depends on larger media files, migrations, or product assets, you need a hosting team that can check the real server limit and help fix it. Use a Configuration File When cPanel Isn’t Available A configuration file can work well when your host permits local PHP overrides. It can also be the right option when cPanel doesn’t expose the setting you need. Try a .user.ini file first Open your hosting File Manager and locate the WordPress root folder. This is the folder containing wp-config.php, wp-admin, wp-content, and wp-includes. Create or edit a file named .user.ini. For a 64 MB upload target, add upload_max_filesize = 64M, post_max_size = 72M, memory_limit = 128M, and max_execution_time = 300. Some servers take several minutes to read a changed .user.ini file. Check the Media screen again after waiting, then test with a real file below the new cap. A helpful comparison of .user.ini and .htaccess upload methods explains why the right file depends on the server running your site. Use .htaccess with care The .htaccess method is for Apache-based hosting that allows PHP directives in that file. Nginx doesn’t read .htaccess, and some hosts block these changes even on Apache. A bad line in .htaccess can trigger a 500 server error. Back up the file first. If the site errors after your edit, remove the added lines and use cPanel or hosting support instead. We don’t recommend relying on wp-config.php as your first choice. Many hosts disable PHP overrides from WordPress files, so the change may do nothing. Adjust Multisite Upload Caps Separately WordPress Multisite adds one more rule to the mix. You can raise PHP limits and still hit a smaller network-wide upload cap. Check Network Admin settings Go to My Sites > Network Admin > Settings > Network Settings. Find the Upload Settings area and look for Max upload file size. This field uses kilobytes. For a 64 MB limit, enter 65536. Save the setting, then test from a subsite dashboard. The network setting can’t override a lower PHP limit. PHP still needs to allow at least the same file size, with enough room in post_max_size for the full request. The Multisite upload cap overview is useful if the network setting and server setting don’t match. Keep the policy practical Network administrators should set limits based on what member sites truly need. A portfolio network may need higher image limits. A network with many casual contributors may need tighter controls. File size isn’t the only rule. WordPress can restrict file types, while your hosting account can still run out of available storage. A higher upload cap doesn’t remove those limits. Fix Upload Errors That Aren’t Size Problems Sometimes you raise the limit and the upload still fails. That’s your signal to read the error instead of raising every number again. Match the error to the likely cause Common upload failures point to different layers: An HTTP 413 error often points to a web server, proxy, or security rule. A 500 error after editing configuration files usually means the server rejected a directive. A message naming the maximum file size points back to PHP or Multisite settings. An upload that starts but fails later may involve a timeout, low disk space, or an unstable connection. Check your hosting error logs if they’re available. The exact error message can save hours of guesswork. Know when better hosting is the answer A larger limit doesn’t make a crowded server faster. Bulk imports, WordPress backup restores, high-resolution media libraries, and large WooCommerce catalogs need more than a bigger number in PHP. That is where a hosting upgrade can make sense. Our managed Web Hosting Plus and VPS plans give growing sites more room to handle demanding work, while our support team can help you choose the right path. A bigger plan isn’t a shortcut around every issue. It does give your site more breathing room when large files are part of the job. Keep Larger Uploads Safe and Sensible Larger uploads are useful, but they should stay controlled. A 500 MB file can fill storage quickly, slow down backups, and create a long failure if the connection drops near the end. Set limits around real file needs Use the smallest practical cap for your workflow. A site importing full WordPress backups needs a different allowance than a brochure site with a few image galleries. Review who can upload files, too. Limit administrator access, keep WordPress updated, and use security monitoring to catch suspicious activity before it becomes a bigger problem. Treat uploads and backups differently An uploaded file is not a backup. Before changing PHP settings or importing a large archive, confirm that you have a recent backup you can restore. For public video, a dedicated video platform can be a smarter fit than filling the WordPress Media Library with huge files. Your website stays lighter, and visitors get a better viewing experience. A Better Upload Experience Starts With the Right Limit That frustrating 2 MB message isn’t a WordPress dead end. Check the displayed cap, match the PHP settings, and adjust the hosting or Multisite rule that is actually blocking the file. The right WordPress upload limit is large enough for your work and sensible for your server. With dependable hosting behind it, uploads stop feeling like a fight and get back to being a routine part of running your site. [...]
Read more...
WordPressWordPress Maximum Execution Time: Fix Timeouts SafelyA 30-second cutoff can stop an update, backup, import, or page process right when it matters most. That doesn’t mean WordPress is broken. It means a PHP task ran longer than your server currently allows. The WordPress maximum execution time is a server setting, not a magic WordPress switch. Raise it with care, test the change, and fix the slow task behind the timeout whenever possible. Here is how to give legitimate jobs more room without leaving your site exposed to slow scripts and wasted server resources. Know What the Time Limit Actually Controls PHP runs WordPress. When a PHP script reaches its time limit, the server stops it to protect resources for the rest of the account and other sites on the server. PHP commonly defaults to 30 seconds. The exact limit depends on your host, PHP version, account plan, and server configuration. Watch for the right timeout message A timeout can show up as a blank screen, a failed plugin update, a stalled import, or an error message such as “Maximum execution time of 30 seconds exceeded.” Check the details before changing anything. In WordPress, the Site Health screen can show server information and PHP settings that help confirm what your site is using. A slow page alone doesn’t prove you have an execution time problem. High memory use, database errors, a stalled API request, and overloaded hosting can look similar at first. Don’t confuse time limits with memory limits Execution time controls how long a script can run. PHP memory limits control how much memory it can use while running. A large image import may need more memory. A backup plugin that waits on thousands of files may need more time. Sometimes it needs both, but raising every limit at once makes the real issue harder to find. A higher PHP time limit gives a valid task more breathing room. It does not make a slow plugin, damaged database table, or failing external service run faster. Choose a WordPress Maximum Execution Time That Fits the Job There is no universal best number. A normal page request shouldn’t run for five minutes. A one-time migration may need more than 30 seconds. We recommend making the smallest change that lets the job finish, then checking that it stays stable. Start with a measured increase For a plugin update, a medium-sized product import, or a planned backup, 120 seconds is often a sensible first step. If you are moving a large site or importing a substantial media library, 300 seconds may be reasonable for the short term. Use this as a practical guide: Site taskSensible starting pointWhat to do nextNormal page requests30 secondsLeave the default in place unless errors prove otherwise.Plugin or theme updates60 to 120 secondsUpdate one item at a time and check the site afterward.Product, post, or media imports120 to 300 secondsUse smaller batches when the import tool allows it.Full-site migrations300 secondsReturn to a lower setting after the move completes. The smaller limit is usually the healthier choice for visitor-facing requests. Long-running scripts can tie up PHP workers, especially on shared hosting. Avoid unlimited time on live websites PHP supports a zero value for no execution limit in some environments. Don’t use it for public WordPress requests. An unlimited script can hang on a broken connection, a plugin bug, or an external service that never replies. Instead, give the task a clear ceiling and investigate anything that still can’t complete. Use Your Hosting Control Panel First The safest way to increase the WordPress maximum execution time is through your hosting account’s PHP settings. This changes the value where it belongs, at the PHP level, without editing WordPress core files. Many cPanel accounts include MultiPHP INI Editor. Other hosts offer a PHP Settings, PHP Selector, or similar tool. Change the setting in cPanel MultiPHP INI Editor In cPanel, open MultiPHP INI Editor under Software. Choose the domain, find max_execution_time, enter the value you need, and apply the change. Basic Mode is the easy route. It is built for common PHP settings, and it reduces the chance of placing a directive in the wrong file. Before you save, confirm you selected the correct domain. Add-on domains, subdomains, and staging sites can use different PHP settings. Check which PHP version is active A setting can appear to save but not affect your site if it applies to another PHP version or directory. Check the PHP version assigned to the domain, then confirm the time limit in Site Health or your host’s PHP information page. WordPress also runs better on supported PHP releases. The official PHP update guidance from WordPress explains why current PHP versions improve performance and security. If your panel blocks the change, don’t force it through random file edits. Your provider may have an account-level cap for stability and security. Ask support to raise the limit for the specific job, then ask what value they recommend for your plan. Use File or Code Changes Only When Necessary Some hosts do not offer a PHP settings panel. Others allow a per-site configuration file. These options can work, but they need a little more care. Make a fresh backup before editing server files. One misplaced character can produce a 500 error. Add the setting to the right PHP configuration file Depending on the host’s PHP handler, the active file may be php.ini or .user.ini. The directive itself is simple: max_execution_time = 300. The hard part is knowing which file your server reads. Some hosts use a file in the site root. Others apply settings higher in the account. cPanel can also generate PHP configuration through different files based on its setup. Create or edit only the file your host documents. Then wait for the configuration refresh if your host uses .user.ini, as changes are not always immediate. Keep WordPress core and wp-config.php clean Don’t edit WordPress core files. Updates replace them, and the change will disappear. You may see advice that suggests adding set_time_limit(300); or ini_set('max_execution_time', '300'); inside wp-config.php. It may work on some hosts, but it is not the most reliable fix. Hosts can block runtime overrides, and a site-wide code change can affect more requests than intended. If a developer needs extra time for one custom process, a small custom plugin or must-use plugin is a better home for that code. Keep the change limited to the task that needs it. Fix the Slow Task Behind the Error A timeout is often a symptom. Raise the limit for a legitimate heavy job, then look at why it needs so much time. This is where a few minutes of checking can save hours of repeated failed imports and backups. Look for plugin and theme conflicts Start by identifying the action that triggers the error. Is it a backup plugin? A page builder update? A WooCommerce import? A security scan? Temporarily deactivate non-essential plugins, then retry the same task. If the error disappears, reactivate plugins one at a time until you find the conflict. A current WordPress version, updated plugins, and a supported PHP release help reduce these problems. The WordPress hosting requirements are a useful reference when checking whether your server environment is keeping pace. Break large jobs into smaller pieces Large imports often fail because they try to process too much at once. Reduce the import batch size. Upload media in groups. Run a database cleanup in stages. Backup jobs need the same common sense. Exclude old archives, cache folders, and files that do not belong in a website backup. Store backup copies away from the live site when your backup tool supports it. We have seen a 300-second setting hide the real problem for weeks. A smaller batch or a better-maintained plugin often solves it without leaving PHP open longer than needed. Test the Change Without Guesswork Don’t raise a value, hope for the best, and walk away. Test the exact job that failed, then check the site afterward. A clean test gives you a clear answer. The task either completes, fails with a different message, or still reaches the limit. Follow a simple, safe test process First, back up the site. Next, change only max_execution_time, not memory limits, upload limits, and PHP versions all at once. Run the failed action once. If it completes, check the front end, WordPress admin area, and any affected orders, posts, or files. Then review your error log for fresh warnings. If it still fails, don’t keep adding time in 300-second jumps. The error log may point to a plugin function, exhausted memory, a database issue, or a remote connection that needs attention. Put the setting back when the job is done A one-time site migration does not require a permanent five-minute execution window. Return the setting to a lower value after the work is complete, especially on shared hosting. Keep a note of what changed, why it changed, and when. That small record makes future troubleshooting much easier for you, your developer, and hosting support. When a Hosting Upgrade Is the Better Fix Sometimes the time limit is not the real bottleneck. A growing WooCommerce store, busy membership site, or content-heavy business website may have outgrown a basic hosting account. More execution time cannot compensate for too few PHP workers, limited CPU resources, slow storage, or a server under strain. It only lets one request wait longer. Look for hosting that keeps control in your hands You should be able to access PHP settings, use current PHP versions, restore backups, add SSL, and reach a real support team when something goes sideways. That is why we built our WordPress hosting around practical control and less technical stress. You get the room to grow, the tools to protect your site, and human help when a server setting needs a second look. Choose hosting that supports your work instead of making every update feel like a gamble. Final Thoughts The right WordPress maximum execution time is the lowest setting that lets a valid task finish without disrupting the rest of your site. Use your hosting panel first, test one change at a time, and treat repeated timeouts as a reason to inspect the task itself. A healthy site is not one that runs forever. It is one that runs reliably, finishes important work, and stays ready for the next customer. [...]
Read more...
WordPressHow to Find Slow WordPress Queries with Query MonitorA slow WordPress page often has a database problem hiding behind a polished design. When we troubleshoot slow WordPress queries, Query Monitor shows which request is taking time, who triggered it, and whether a plugin or theme is responsible. You don’t need to guess, deactivate every plugin at random, or move to a more expensive server before checking the evidence. With a few focused tests, you can find the bottleneck and choose the right fix. Why Slow WordPress Queries Matter Every WordPress page load can trigger database queries. WordPress uses them to retrieve posts, products, settings, users, menus, custom fields, and plugin data. Most queries finish quickly. Problems appear when one query takes too long, when a plugin sends the same query repeatedly, or when dozens of small queries add up to a noticeable delay. The result is familiar: Pages take longer to open. The WordPress admin feels sluggish. WooCommerce product and checkout pages lag. Visitors wait before seeing useful content. Search engines and performance tools report a high time to first byte. A slow query isn’t always the only problem. Large images, third-party scripts, PHP errors, and limited hosting resources can also slow a site. Query Monitor helps us separate those issues instead of treating every performance problem as a database problem. A query that takes 20 milliseconds once may not matter. The same query repeated 200 times can become the reason a page feels slow. The first step is to test the page where visitors feel the delay. Don’t check only the homepage. Look at search results, contact forms, WooCommerce products, cart pages, and any page connected to a recent plugin change. Prepare the Site Before Testing Query Monitor is a diagnostic tool, not a permanent speed solution. It collects detailed information during each request, so we recommend using it on a staging site whenever possible. Use a safe testing environment If your host provides staging, create a copy of the website before installing diagnostic plugins or changing database settings. A staging site gives you space to test plugin conflicts without affecting customers. If staging isn’t available, take a current backup first. Avoid testing during a busy sales period, and don’t make live changes based on one result. We also recommend opening the site in a private browser window for visitor-facing tests. Then compare it with a logged-in administrator session. WordPress can load different content, caching rules, and toolbar data for each user type. Test the exact slow page Choose one page that consistently loads slowly. Record what happens before installing Query Monitor: Note the page URL and approximate load time. Test it two or three times. Check whether the problem happens on desktop, mobile, or both. Test another page that loads normally. Record whether the delay happens before content appears or during the final visual loading. This comparison gives you a baseline. If every page is slow, hosting or a site-wide plugin may be involved. If only the shop, form, or search page is slow, start with the features used there. Install and Open Query Monitor Query Monitor is a free WordPress debugging plugin. You can install it through the WordPress dashboard, or review the project files in the Query Monitor project repository. From WordPress, go to Plugins > Add New. Search for “Query Monitor,” check that the plugin is from John Blackbourn, then install and activate it. The plugin supports modern WordPress sites and requires PHP 7.4 or later. If your website runs an older PHP version, ask your host to update it after checking theme and plugin compatibility. Once activated, open the slow page while logged in as an administrator. Query Monitor adds a panel to the WordPress admin toolbar. Select its entry to view information about that request. The panel may appear at the bottom of the page or open through the toolbar, depending on the site setup and WordPress admin bar. The official Query Monitor usage guide covers the main panels and filtering options. Keep the test focused. Open one page at a time, wait for it to finish loading, and read the results before moving to another URL. That makes it easier to connect a query to a page feature. How to Find slow WordPress queries in Query Monitor Open the Query Monitor panel and choose Queries. This area shows the SQL queries WordPress ran during the current page request. The main table can include: The SQL statement. The query type, such as SELECT, INSERT, UPDATE, or DELETE. The function that called the query. The plugin, theme, or WordPress component responsible. The number of rows returned or changed. The execution time. Any database error message. The WP VIP Query Monitor reference also explains how query details can show the query, caller, and execution time. Those three details usually give us the fastest route to the cause. Start with the Slow Queries panel Query Monitor includes a Slow Queries panel that filters out faster requests and highlights queries that cross its slow-time threshold. If the panel contains a query, sort or review it by execution time. Look for statements that take noticeably longer than the others. A query returning a large number of rows may also deserve attention, especially on a search, archive, or store page. An empty Slow Queries panel doesn’t prove that the database is healthy. The threshold may not catch a collection of medium-speed queries. Open the full Queries panel and look for repetition, high totals, and database errors. Check totals, not only the biggest number Suppose one query takes 90 milliseconds. That may be worth investigating, but 30 separate queries taking 15 milliseconds each could create a larger delay. Query Monitor groups queries by caller and query type. Review the total time spent by each group, not only the slowest individual line. A plugin that adds many small queries to every page can create more damage than one isolated query on a special page. Duplicate queries are another warning sign. If the same SQL statement appears again and again, check why it repeats. Some repetition is normal, but excessive duplication can point to a plugin setting, an inefficient theme function, or missing object caching. Trace the Query Back to a Plugin or Theme A database query is only the symptom. The caller and component tell you where to investigate next. Use Queries by Component Open Queries by Component to see how much database work comes from WordPress core, your active theme, and each plugin. If one plugin accounts for most of the query time, test that plugin first. The result doesn’t automatically mean the plugin is poorly built. A plugin may need extra queries on a product filter, membership page, or reporting screen. The useful question is whether those queries run on pages that don’t need the feature. For example, a booking plugin shouldn’t load its full availability data on a basic About page. A form plugin shouldn’t query every form on every front-end request. Plugin settings, conditional loading, or a recent update may change that behavior. Read the caller and call stack The caller shows the PHP function that requested the SQL. The full call stack provides more context. Look for recognizable names: A plugin folder name often points to the responsible plugin. A theme function may identify a custom template or feature. WP_Query can indicate a post, archive, or custom content query. WooCommerce functions often appear on product, cart, and checkout requests. WordPress core functions may still be triggered by a plugin or theme hook. A core function in the caller column isn’t always the real culprit. Plugins often ask WordPress to run a query through standard functions. Follow the stack until you see the code or component that initiated the request. Don’t edit the SQL directly. Query Monitor shows what happened, but it doesn’t rewrite the underlying plugin logic safely. Separate Database Delays from Other Bottlenecks Query Monitor collects more than SQL data. Use the other panels before deciding that slow WordPress queries are the main issue. Check HTTP API calls A page can wait for an external service, such as a payment provider, email platform, analytics tool, map service, or product feed. These requests can delay the server response even when the database queries are quick. Open the HTTP API Calls panel and check the request time. A third-party call that takes several seconds deserves attention. You may be able to disable the integration, load it later, reduce its frequency, or contact the provider. If the service is required for checkout or account features, test it carefully on staging before changing it. Review PHP errors and hooks Warnings, notices, and fatal errors can add work or prevent caching from working correctly. Check the PHP Errors panel for messages that appear on the slow page. The Hooks and Actions panel can also help when a theme or plugin attaches heavy functions to common WordPress hooks. A function running on every page load has a wider effect than one that runs only on a special page. For a practical performance walkthrough that combines Query Monitor with other checks, see this Query Monitor optimization guide. Compare server response time If Query Monitor shows fast queries, few PHP errors, and no slow HTTP calls, the hosting environment may need attention. Limited PHP workers, high server load, outdated PHP, low memory, or a busy shared server can all affect time to first byte. Run the same page test at different times. Compare a cached page with an uncached request, if your caching system allows it. A site that slows down only during busy periods may need more hosting resources rather than a plugin change. Fix the Cause and Test Again Once you know which component is responsible, make one change at a time. That keeps the result clear. Start with updates for WordPress core, the active theme, and the plugin connected to the slow request. Developers often fix query problems in later releases, but read the changelog and test updates on staging first. If a plugin is responsible, review its settings before removing it. Look for options related to logging, reports, search, related products, database tables, scheduled tasks, or loading features site-wide. For a plugin conflict, deactivate the suspected plugin on staging and test the same page. If the page improves, reactivate other plugins one by one until the delay returns. That points to the responsible feature without turning the live site into a guessing exercise. Database cleanup can help when tables contain years of expired transients, revisions, logs, or abandoned records. Always back up first. Database optimization and index changes should be handled by someone who understands the site schema, especially on WooCommerce or membership websites. Persistent object caching can also reduce repeated database work. Page caching helps with complete public pages, while object caching stores repeated results used during PHP requests. The right cache depends on the site and hosting setup. After every change, retest: The original slow page. A normal page. A logged-out visitor view. Any related form, product, cart, or account feature. Query time, page response time, and visible errors. If the database is still slow after plugin and theme checks, the server may not have enough room for the website’s current traffic. Our ZADiC WordPress hosting plans give small businesses a simpler place to run WordPress, with one-click setup, free SSL on many plans, backups, security monitoring, and 24/7 human support. For busier websites, managed Hosting Plus or VPS hosting can provide a better fit than staying on an overloaded entry-level plan. Keep Query Monitor as a Diagnostic Tool Query Monitor is useful during troubleshooting, but it doesn’t belong on every production site forever. Once you’ve identified and fixed the issue, deactivate it unless you still need it for development. Keep a record of the original query time, the change you made, and the result after testing. That simple habit helps you recognize future problems faster. Run another review after major plugin updates, a theme redesign, a WooCommerce change, or a hosting migration. Performance problems often arrive with a new feature, not because WordPress suddenly changed on its own. A clean monitoring routine can be simple: Check the page that visitors say feels slow. Review slow and duplicate queries. Identify the responsible component. Check HTTP calls and PHP errors. Change one thing. Test the result again. That process gives you useful evidence before you spend money or remove a feature customers rely on. Conclusion Query Monitor turns a vague complaint, “WordPress is slow,” into a practical investigation. The slow WordPress queries panel shows the requests worth checking, while callers and components point toward the plugin, theme, or feature behind them. Start with the exact slow page, test safely, review total query time, and separate database work from external calls and hosting delays. When the application is clean but the server still struggles, reliable WordPress hosting can give your site the support and resources it needs to keep moving. [...]
Read more...
WordPressHow to Configure Redis Object Caching for WordPressRedis object caching can make a WordPress site feel faster without changing its design or rebuilding every page. It stores frequently used database results in memory, so WordPress doesn’t need to repeat the same work on every request. When visitors, customers, or logged-in users notice delays, the problem often sits behind the page. Redis helps reduce that repeated database work. The setup is straightforward when your hosting account has the right Redis service, PHP client, and connection details. Let’s start with what it changes. What Redis object caching changes WordPress uses an object cache to store temporary data such as database query results, settings, menu data, and other values created during a request. By default, much of that cache disappears when the request ends. A persistent Redis cache keeps those objects available for later requests. The result is less repeated work for PHP and MySQL, especially on sites with busy plugins or dynamic content. Object cache is not page cache These two caching systems work at different levels. A page cache stores finished HTML pages. When a visitor requests the same page, the server can return that saved page instead of running WordPress again. An object cache stores smaller pieces of WordPress data. WordPress can reuse those pieces while building a page, processing an AJAX request, loading the dashboard, or handling a logged-in session. That difference matters. Redis won’t replace a page cache, image optimization, a content delivery network, or good hosting. It adds another layer that helps WordPress handle repeated database tasks. WordPress core includes the WP_Object_Cache class, but persistent storage needs a compatible plugin and a working Redis server. The WP_CACHE constant alone doesn’t create persistent Redis caching. Where the improvement shows Redis object caching becomes more useful as a site grows more complex. WooCommerce stores product, cart, session, and user data. Membership sites process account details and restricted content. Large publishing sites often run several plugins that request the same settings and database values. You may notice better response times in: WooCommerce product and checkout workflows. WordPress admin screens for logged-in users. Membership dashboards and account pages. Search, filtering, and AJAX-powered features. Sites with many plugins and frequent database activity. A small brochure site may see a smaller improvement. That doesn’t make Redis useless, but it means other changes, such as better hosting or image compression, may deliver more value first. Check whether hosting supports Redis Before installing a plugin, check the server. A WordPress plugin can’t connect to Redis if Redis isn’t running somewhere your site can reach. You need three pieces: A Redis service, either on the same server or on a private remote server. A PHP client such as PhpRedis, Predis, or Relay. Connection details, including the host, port, password, or Unix socket path. Hosting setupWhat to confirmTypical next stepManaged WordPress hostingRedis availability and provider instructionsEnable the host-supported object cachecPanel or shared hostingRedis service, PHP extension, and socket detailsAsk the host for the exact configurationVPS hostingRedis service, firewall rules, PHP client, and memory limitsInstall and secure Redis before connecting WordPress On a VPS, Redis may need to be installed, secured, and limited to local or private connections. On shared hosting, you may not have permission to install it yourself. If your current plan doesn’t provide Redis, ZADiC’s WordPress hosting, managed Web Hosting Plus, and VPS options give you different levels of control. Our support team can help identify the setup that fits your traffic, plugins, and technical comfort. You shouldn’t have to guess which server settings belong in wp-config.php. Custom WordPress stacks need extra care. Sites using Bedrock or Trellis can follow environment-specific approaches, such as the setup discussed in this Bedrock and Trellis Redis guide. Prepare WordPress before configuration A few minutes of preparation can prevent a messy cache problem later. Redis stores data generated by WordPress, so the site should be stable before you add another caching layer. Back up the site and test changes Create a current backup of your files and database. If your host provides automatic backups, confirm that the latest backup completed successfully. A staging site is even better. Install Redis there first, test the checkout and login flows, then apply the same settings to production. This matters for WooCommerce, membership plugins, multilingual sites, and custom themes. Update WordPress, your active theme, and important plugins before testing. An outdated plugin may create errors that look like a Redis problem. Check for existing object-cache files Look inside wp-content for object-cache.php. This file is the WordPress drop-in that connects the normal object-cache system to a persistent backend. Only one object-cache drop-in should control the site. If your host already installed Object Cache Pro or another Redis integration, don’t install a second object-cache system on top of it. Two competing drop-ins can create confusing connection errors and unpredictable cache behavior. Keep your Redis credentials private. The wp-config.php file contains sensitive settings, so don’t commit it to a public repository or paste passwords into an open support forum. Install the Redis Object Cache plugin The free Redis Object Cache plugin is a common option for WordPress sites. As of August 2026, its WordPress.org listing requires WordPress 4.6 or newer and PHP 5.6 or newer. Those are minimum requirements, not a recommendation to run old software. Use the current PHP version your host supports. Use the WordPress admin In your WordPress dashboard: Open Plugins > Add New Plugin. Search for Redis Object Cache. Install the plugin published by Till Kruss. Activate it. Open Settings > Redis. Select Enable Object Cache. If Redis is already available and the connection values are correct, the plugin should create or activate wp-content/object-cache.php. Don’t stop at plugin activation. Installing the plugin only gives WordPress the connector. The Redis service still needs to be running, reachable, and configured for your account. Use WP-CLI on managed hosting or a VPS WP-CLI is faster when you manage several sites or work from the server terminal. From the WordPress installation directory, run: wp plugin install redis-cache --activate wp redis enable The wp redis enable command activates the object-cache drop-in. If another drop-in already exists, don’t overwrite it without checking which caching system your host uses. The --force option can overwrite an existing object-cache.php, so use it only when you’re certain the current file should be replaced. For more command details and advanced Redis support, the plugin’s Redis Object Cache repository is a useful reference. Managed WordPress providers may install a different plugin, such as Object Cache Pro, automatically. Follow the provider’s instructions instead of forcing the free plugin into a host-managed setup. Add the right Redis connection settings Most setup problems come from using the wrong connection details. Redis may run locally on port 6379, through a private hostname, on a custom port, or through a Unix socket. Your hosting provider should give you the exact values. Never assume that 127.0.0.1 is correct. Configure a TCP connection For a local or private network connection, the settings may look like this: define( 'WP_REDIS_HOST', '127.0.0.1' ); define( 'WP_REDIS_PORT', 6379 ); define( 'WP_CACHE_KEY_SALT', 'example.com:' ); The host can be a private IP address or a hostname. The port may be different from the standard Redis port. If authentication is required, your provider may also give you a password or another authentication setting. A cache key salt gives the site a unique prefix. This is important when multiple WordPress sites share one Redis service. Use a different salt for each site, such as example.com: and store.example.com:. Otherwise, one site could collide with another site’s cached keys. Place these definitions in wp-config.php before the line that says WordPress stops editing. Use the values supplied by your host, not the sample values above. Configure a Unix socket Some cPanel-style environments expose Redis through a local socket instead of a TCP port. In that case, the configuration may look like this: define( 'WP_REDIS_SCHEME', 'unix' ); define( 'WP_REDIS_PATH', '/home/username/redis/redis.sock' ); define( 'WP_CACHE_KEY_SALT', 'example.com:' ); The socket path is unique to the hosting account. A single missing character can cause a connection failure, so copy it carefully. Unix sockets can work well when Redis runs on the same server. They aren’t appropriate when Redis is hosted on a separate machine. Ask your provider which connection method your plan uses before adding either configuration. Confirm that persistent caching is active A successful plugin installation doesn’t prove that WordPress is using Redis. Check the connection before measuring performance. Check the plugin and Site Health Return to Settings > Redis. The status should show a successful connection, usually with details about the Redis client and connection. If the page reports that Redis is disabled or unreachable, fix that first. WordPress Site Health can also report whether a persistent object cache is available. Open Tools > Site Health and review the status and information panels. You can also check whether wp-content/object-cache.php exists. Without that drop-in, WordPress may continue working normally, but the object cache won’t persist between requests. A green plugin screen means WordPress reached Redis. It doesn’t automatically mean every performance problem has been fixed. On the command line, wp redis enable is the standard activation command for supported Redis integrations. If you need to remove the drop-in while troubleshooting, wp redis disable is safer than deleting files at random. Measure the right things Test the site before and after activation. Compare similar pages under similar conditions, and test while logged out as well as logged in. Look at: Time to first byte. Server response time. Database query time. Admin page loading speed. WooCommerce cart and checkout behavior. Error logs and PHP warnings. Clear any page cache before each comparison. Otherwise, a saved HTML page may hide whether Redis made a difference. Redis may improve server response time without making a large visual change. That is normal. It reduces repeated backend work, not the size of images or JavaScript files delivered to the browser. Fix common Redis setup problems Most Redis errors have a short list of likely causes. Check the connection details before changing unrelated plugins. Connection refused or unavailable A “connection refused” message usually means Redis isn’t running, the host or port is wrong, or a firewall blocks the connection. On a VPS, check the Redis service and its binding rules. Redis shouldn’t be exposed publicly with an open firewall port. A missing PHP client can create a different error. Ask your host whether PhpRedis, Predis, or Relay is available for the PHP version assigned to your domain. If the plugin reports authentication errors, request fresh credentials from the provider. Don’t keep guessing passwords or ports. Stale data or plugin conflicts Redis object caching can hold an old value until WordPress or a plugin updates it. Use the plugin’s flush option after major configuration changes, theme updates, imports, or database migrations. Be careful on production sites. Flushing Redis removes cached objects for every site sharing that database unless the host separates them. A site-specific cache salt helps prevent collisions, but it doesn’t make a shared flush harmless. Multilingual sites need extra testing. WPML provides Redis caching guidance for multilingual WordPress, including checks for language-specific content and cache behavior. If a site becomes unstable after enabling Redis, disable the object cache temporarily and review the logs. A host-provided cache and a manually installed cache plugin may both be trying to manage the same drop-in. Know what Redis cannot fix Redis is one part of a fast WordPress setup. It won’t repair slow third-party APIs, oversized images, bloated plugins, poor database indexes, weak PHP resources, or an overloaded server. A practical performance stack may include: Reliable WordPress hosting with enough CPU and memory. A full-page cache for public pages. Redis for repeated object and database data. Modern PHP and a suitable PHP memory limit. Compressed images and fewer heavy scripts. Backups, SSL, security monitoring, and regular updates. Hosting quality affects every layer. If Redis keeps disconnecting or your server lacks memory, changing WordPress settings won’t solve the root problem. ZADiC helps small businesses choose between standard WordPress hosting, managed Web Hosting Plus, and VPS hosting without forcing every site owner to become a server administrator. With backups, security services, and 24/7 human support available, you can focus on your website while we help with the technical foundation. Conclusion Redis object caching gives WordPress a persistent memory layer for frequently used data. The setup works best when your hosting provider supplies a reachable Redis service, a supported PHP client, and clear connection details. Install one compatible object-cache plugin, use a unique cache salt, verify object-cache.php, and test real pages before and after activation. If your current hosting doesn’t provide the access Redis needs, choosing a managed Web Hosting Plus or VPS plan can be a simpler path to reliable performance. [...]
Read more...
WordPressCheck WordPress PHP Extensions Before Installing PluginsOne missing PHP module can stop a plugin before you ever reach its settings page. Before installing, we check the PHP extensions loaded by the same PHP version serving the website. That quick step can prevent failed updates, broken image tools, database errors, and frustrating white screens. You don’t need to be a server administrator when your host offers active support for unclear requirements. We can check the basics inside WordPress, confirm the exact PHP extensions with phpinfo(), or review them in cPanel to verify PHP compatibility. Let’s start with what matters most. Key Takeaways Check the PHP version and extensions used by the live website before installing a plugin, rather than relying on the command-line version or account default. Use WordPress Site Health for a broad server check, then confirm exact loaded modules with phpinfo(), cPanel, or the correct command-line PHP binary. Compare the plugin’s required PHP version and extensions with your active runtime, paying close attention to modules such as curl, mbstring, zip, imagick, gd, mysqli, and openssl. If an extension is missing, save the error message, confirm the domain’s PHP handler, and ask your hosting provider or plugin developer for an approved solution. Test important pages and connected services after installation, especially when using image processing, object caching, payment, email, or other integrations. Why Check PHP Extensions Before Installing a Plugin? PHP powers WordPress core. PHP extensions are add-on components that give the engine extra abilities, such as connecting to a MySQL database, processing images, reading XML, or making secure connections to other websites. Plugins depend on the same server environment. If a required component is missing, it can affect PHP compatibility, prevent activation, or break a specific feature. Plugin requirements live on the server Plugin documentation may list PHP extensions and requirements such as: PHP 8.2 or newer The mbstring extension for UTF-8 text handling The zip extension for package installation and updates The curl extension for external API requests imagick or gd for image processing Installing the plugin first and checking later is like buying a printer before checking whether your computer has the right connection. Sometimes it works. Sometimes you’re left troubleshooting a problem that was easy to prevent. PHP version comes first The PHP version and its extensions work together, so their combination affects PHP compatibility. Check the PHP version assigned to your domain in your hosting environment. A plugin tested on PHP 8.3 may behave differently on PHP 8.4, especially if it uses older PHP functions. WordPress.org’s current requirements page recommends PHP 8.3 or greater for WordPress. Check your current runtime before adding a plugin, then review the developer’s notes for plugin compatibility and known conflicts. Newer isn’t always better when a plugin hasn’t caught up. Test major PHP changes on a staging site to confirm PHP compatibility, especially before moving to PHP 8.4. Keep a backup, apply security updates, and update WordPress, themes, and plugins before changing the server version. If requirements remain unclear, ask the plugin developer or host whether the plugin has active support for your environment. WordPress PHP extensions to check first The WordPress Hosting Handbook’s server environment guide separates PHP extensions into required, recommended, and cache-related groups. The listed PHP modules are loaded by a particular runtime. Treat this list as a baseline, then check the plugin’s supported environment and stated PHP version requirement for PHP compatibility. CategoryExtensions to checkMain purposeRequiredjson, mysqli or mysqlnd, curlData processing, MySQL database connections, database interactions, and remote requestsRecommendeddom, exif, fileinfo, hash, igbinary, imagick, intl, mbstring, openssl, pcre, xml, zipText, images, uploads, updates, security, and external dataCache-relatedapcu, memcached, OPcache, redisBytecode and object caching, with Redis and Memcached used only when configured Required extensions don’t mean every checkbox The database requirement is usually satisfied by mysqli or mysqlnd. These PHP extensions don’t normally need to be installed together just because they appear in different setup guides. The json extension is bundled with PHP 8.0 and newer, so it may not appear as a separate option in your hosting panel. curl handles remote requests, including connections used by updates, APIs, and some integrations. If one of these required extensions is missing, stop before installing the plugin. Ask your host to confirm the PHP handler assigned to your domain. Recommended PHP extensions depend on your plugins The recommended PHP extensions depend on each plugin’s features and integrations. Imagick supports advanced image processing and PDF thumbnails. The GD Library (gd) offers basic processing as an alternative. mbstring helps plugins work with international text, while intl supports locale and formatting functions. Extensions such as simplexml, xmlreader, zlib, iconv, filter, bcmath, ftp, ssh2, and sockets are often feature-specific, while others act as fallback extensions. Match each extension to the plugin or feature that needs it. Start With WordPress Site Health WordPress gives you a useful first check with Site Health without leaving the dashboard. Find the server details Log in to WordPress and open Tools > Site Health > Info. Expand the Server section to review details such as: The active PHP version The web server PHP memory limits Maximum upload size Maximum post size Maximum input variables The Database section can also reveal connection details and the database software in use. These checks help you compare your site’s server environment with the plugin’s installation requirements. Know what Site Health cannot show Site Health is a good starting point, but it may not display every loaded PHP extensions. This provides a broad PHP compatibility check, not a complete runtime inventory. If the plugin names a particular module, confirm it with phpinfo() or the hosting control panel. Use this dashboard check to confirm the broad environment first. Then use a more direct method for the exact module list. If the results remain unclear, your host’s active support team can confirm the exact runtime. Two minutes here can save an hour of guessing. Use phpinfo() to See the Active Web Modules A phpinfo() page reports the PHP runtime used by the web server. That distinction matters for PHP compatibility because the PHP version in your hosting panel may not match the command-line version on the same account. Create a temporary check page Create a temporary PHP file in your website’s document root with <?php phpinfo(); ?> inside it. Name it something difficult to guess, such as server-check.php, then open that file in your browser. If your hosting panel shows PHP 8.4, confirm that the page reports the same runtime before testing a plugin. Search the page for Loaded Modules to see the active PHP modules and loaded PHP extensions. You can also search for individual PHP extensions, such as curl, dom, Imagick, mbstring, mysqli, openssl, and zip. The page shows the PHP version, loaded extensions, configuration values, and active server settings. For official details, see PHP’s phpinfo() documentation. If it conflicts with your hosting panel, contact your host for active support before checking plugin requirements. Delete the file as soon as you’re finished. A public phpinfo() page exposes configuration details that visitors don’t need to see. Review Extensions in cPanel cPanel is often the quickest option when your host gives you PHP version control. Its interface exposes PHP extensions for the selected domain. The wording varies between hosting providers. Check the correct domain and runtime Select the domain where you plan to install the plugin, since it may use a different runtime than the account default. Confirm the plugin’s PHP compatibility and match its extension list to the runtime serving the site. A PHP 8.4 list may not apply to a site using another version. Review the PHP extensions listed for that domain, including modules such as: curl dom fileinfo imagick (Imagick) or gd (GD Library) intl mbstring mysqli or mysqlnd openssl xml zip Select only the modules your WordPress installation or plugin needs, then save the changes. Clear any server or WordPress cache before testing again. If the plugin depends on object caching, also verify the host’s documented Redis or Memcached setup. cPanel’s PHP extension documentation explains where administrators can locate and install PHP versions or extensions. In a shared hosting environment, you may see the modules but lack permission to change them, so your provider’s active support team may need to enable one. If you want simple server control without managing a full VPS, our cPanel hosting for WordPress offers a familiar dashboard for website, email, database, and PHP management, plus active support. Check Extensions From the Command Line SSH access makes extension checks quick and repeatable. Run: php -v This confirms the PHP version used by the command line. Then run: php -m This lists loaded PHP modules and shows the PHP extensions available to the command line. To filter common WordPress requirements from those PHP extensions, use: php -m | grep -Ei 'curl|dom|fileinfo|imagick|intl|mbstring|mysqli|mysqlnd|openssl|xml|zip' You can also inspect the active configuration files with: php --ini Watch for a PHP runtime mismatch The command-line PHP version may not match the PHP runtime used by Apache, Nginx, or PHP-FPM on the web server. A web server can show mysqli in php -m while the site reports that a MySQL database extension is missing or uses different object caching settings. That is why we compare command-line results with phpinfo() or the hosting panel for accurate PHP compatibility checks. Always trust the runtime serving the domain, not a different PHP binary on the account. On some managed servers, versioned commands such as ea-php83 for PHP 8.3 or ea-php84 for PHP 8.4 replace php. Ask your hosting provider’s active support team for the correct versioned command instead of guessing. Match the Plugin’s Requirements Before Installation Checking the server’s PHP extensions is only half the job. Read the plugin’s installation requirements, then compare its required extensions with the actual runtime to confirm PHP compatibility. An image optimization plugin may need Imagick or gd for image processing. A multilingual tool may depend on mbstring and intl. A plugin that connects to a payment, email, shipping, or CRM service may need curl and openssl. Check the plugin’s PHP support Look for three details in the plugin documentation: The minimum PHP version and whether the plugin supports PHP 8.3 or PHP 8.4. The extensions it requires or recommends, plus notes about PHP compatibility. Any known conflicts with other plugins, themes, or server settings that could affect plugin compatibility. Don’t rely only on the WordPress plugin directory description. Visit the developer’s installation guide and changelog when the plugin handles payments, membership accounts, customer data, or important site functions. If the requirements remain unclear, contact the developer through an active support channel or ticket system before installing. Test performance-related modules correctly PHP extensions can affect speed, but adding more modules doesn’t automatically make a website faster. OPcache can reduce repeated PHP compilation. Redis and Memcached can support object caching. The image library and GD affect how images are created and resized. Those tools need correct server and plugin configuration. Configure them deliberately for performance and security. Misconfigured object caching can create stale pages or interfere with carts, forms, and logged-in sessions. After installing a plugin, test the homepage, contact forms, login page, checkout, media library, and any connected service. Check error logs if something feels wrong. If problems continue, ask your host’s active support team to review the runtime and logs. What to Do When an Extension Is Missing Don’t force the installation when a needed module isn’t available. For better error handling, save the exact error message and check the logs. Record the domain and PHP version, then contact your host with a clear request. Ask your host which PHP extensions are active for the PHP release serving your domain. Your host’s active support team can identify the active handler and explain whether the missing PHP extensions can be enabled. If you need Imagick, intl, or zip, ask whether the module can be enabled. You can also ask whether the plugin has an approved alternative with better PHP compatibility. VPS owners can usually install server packages, but the package depends on the operating system and PHP installation. Your hosting environment matters, so active support can confirm the package when shared hosting or cPanel limits access. Back up first, make changes during a quiet period, and test performance and security afterward. If you don’t want to manage PHP modules, updates, backups, and security settings yourself, our managed WordPress hosting handles much of that server work for you. Plans include automatic backups, security updates, SSL, and 24/7 active support. Frequently Asked Questions How can I check which PHP extensions WordPress is using? Start with Tools > Site Health > Info to review your site’s PHP version and server details. For the complete list of active modules, use a temporary phpinfo() page or check the PHP extensions for the correct domain and runtime in cPanel. Is php -m enough to verify WordPress PHP extensions? Not always, because php -m usually reports the command-line PHP runtime. Compare its results with phpinfo() or your hosting panel to confirm the extensions loaded by the web server serving your domain. Which PHP extensions should I check before installing a plugin? Common requirements include curl, dom, fileinfo, mbstring, mysqli or mysqlnd, openssl, xml, and zip. Image plugins may need imagick or gd, while plugins using object caching may require a configured Redis or Memcached service. What should I do if a required PHP extension is missing? Do not force the installation; save the exact error message and record the domain and PHP version. Ask your hosting provider whether the module can be enabled for the PHP runtime serving your site, or contact the plugin developer about an approved alternative. Can installing more PHP extensions make my WordPress site faster? Not automatically, since performance extensions need proper server and plugin configuration. OPcache, Redis, Memcached, and image libraries can help in the right setup, but misconfigured caching may cause stale content or interfere with forms, carts, and logged-in sessions. Install Plugins With Confidence A safe plugin install starts before the upload button. Check the PHP version and inspect the PHP extensions loaded by the live website. Compare them with the plugin’s requirements, then test important pages after activation. The right server configuration gives WordPress and its plugins the tools they need. A suitable host provides a clear place to review settings and reliable backups when changes go wrong. It may also offer configured services such as object caching and active support when a server setting gets in the way. [...]
Read more...
WordPressWordPress Site Health: Fix Problems FasterA red warning in your WordPress dashboard can make a small problem feel much bigger. The good news? The tool provides a health check before you change plugins, edit server files, or contact your host. We use the Site Health tool to separate urgent issues from useful improvements, collect the technical details support teams need, and trace failures back to PHP, SSL, REST API, or hosting settings. Start with the site health status view, then use the information screen for answers, not a complete site performance audit. How WordPress Site Health sorts your next move WordPress added Site Health in version 5.2 to help site owners spot problems without opening a server terminal. You can find the Site Health tool in your WordPress dashboard under Tools > Site Health. The screen has two main tabs, Status and Info. They work together, but they have different jobs. Start with the Status tab Status shows your site’s site health status and serves as your first health check. It checks the site and groups results into: critical issues, which can affect security, stability, updates, or important WordPress functions. recommended improvements, which may not break the site today but can make it safer or easier to maintain. Good results, which need no action. Open each result and read the details before changing anything. Site Health may flag an outdated PHP version, disabled automatic updates, failed background updates, an active debug mode, missing PHP modules, blocked HTTP requests, or an expired SSL certificate. Before making changes, check whether debug mode is active and review the update settings. It can also recommend removing inactive plugins and inactive themes. Those items may not be loading on the front end, but old files still belong to the website and can create security and maintenance problems. Fix the highest-risk item first Don’t chase the number of green results. Start with the critical issues and fix the problem that can cause the most damage. An outdated server runtime deserves attention before a minor recommendation about housekeeping. A failed loopback request matters more when scheduled tasks or plugin editing are already failing. If the site is public but the REST API is blocked, your editor, forms, integrations, or mobile tools may stop working. The official Site Health documentation explains where the screen lives and what information it reports. We recommend opening the details for every critical issue, copying the exact message, and recording when it appeared. A green Site Health screen means WordPress found no listed problems. It doesn’t promise fast pages, perfect uptime, or strong hosting resources. Use Site Health Info for faster support The Info tab is where troubleshooting gets practical. Status tells you that something is wrong. Info helps you show support staff what the website is running on. Read the server details, not only the summary Open Tools > Site Health > Info to view Site Health Info, then expand each section. You’ll find details about WordPress, the active theme, plugins, inactive themes, the server, database, PHP, media handling, and filesystem permissions. Pay close attention to: The PHP version and memory limit. The WordPress version and the database version. The web server and operating system. The active theme and plugin list. Whether GD or Imagick handles image processing. HTTPS settings and WordPress URL values. API endpoints and loopback-related information. This data can explain why one website works while another site on the same account fails. A plugin may need more memory, or GD and Imagick may differ in media handling. File uploads can expose that issue, and the server may reject outbound requests. These details document the initial health check and give support useful evidence. Copy the Site Health information to your hosting provider. Remove passwords, keys, tokens, and private details before sharing it publicly. Give support the details that matter A support request that says “WordPress is broken” starts slowly. A request that includes the failed test, PHP version, error code, active plugins, and approximate time can move much faster. We usually send: The exact Site Health warning. The affected URL, if it’s safe to share. The steps that caused the error. The timestamp and timezone of the failure. A copy of relevant Site Health Info. Any recent plugin, theme, PHP, DNS, or hosting changes. Ask your hosting provider to review PHP and web server logs, error logging, firewall events, cron activity, and outbound request rules. Site Health points to the problem, while server logs often reveal the line that caused it. Fix PHP and plugin warnings before they grow Many Site Health warnings point to software that needs attention. Treat them as maintenance signals, not background noise. Move to a supported PHP version PHP runs WordPress, themes, and plugins. An outdated PHP version can create compatibility problems, reduce performance, and leave the server exposed to security vulnerabilities. As of 2026, WordPress recommends PHP 8.3 or later. The WordPress requirements page says WordPress can still run on PHP 7.4 or newer, but older PHP releases have reached official end of life. The WordPress PHP requirements explain the security concern clearly. The Hosting Team recommends PHP 8.4 or later for production environments. WordPress 6.8 and later fully support PHP 8.4, while WordPress 6.9 and later fully support PHP 8.5, according to the current PHP support clarification. Before changing PHP: Create a current backup. Update WordPress, the theme, and plugins. Check whether important plugins support the target version. Test the change on staging when possible. Change PHP through your hosting panel or ask support to do it. Test the homepage, login, forms, checkout, media handling, and admin editor. If the site shows a fatal error after the change, switch back to the previous PHP version or use WordPress Recovery Mode. Then identify the plugin or theme that needs an update. Remove software you don’t use Inactive themes and plugins are easy to ignore. They shouldn’t stay forever. Delete inactive plugins you no longer need, rather than leaving them inactive. Keep one default WordPress theme available for recovery, but remove other unused themes after confirming they aren’t needed for a child theme setup or rollback. Before deleting or changing a parent theme, verify whether an active child theme depends on it. Take a backup first. Then remove one item at a time and test the site. If a warning returns after cleanup, check whether a management plugin, host tool, or deployment process is reinstalling the files. Repair HTTPS and REST API checks A secure connection and reliable communication between WordPress components support more than visitor trust. They also affect editing, forms, integrations, and communication between site components. Check the SSL certificate and site URLs An SSL certificate allows your site to load through HTTPS. Site Health can flag certificate and HTTPS problems when the certificate is missing, expired, mismatched, or incorrectly configured. Start by opening the site in a private browser window. Check the SSL certificate, then review the homepage, login page, contact forms, and a few image URLs. Look for certificate warnings, redirects between HTTP and HTTPS, or a browser message showing that the page contains insecure content. Inside Settings > General, confirm that both the WordPress Address and Site Address use https://. Don’t change those fields without a backup if you’re unsure. A wrong URL can lock you out of the dashboard. Mixed content often comes from old image URLs, theme settings, page builders, CDN files, or plugin options. Our guide to fixing mixed content errors covers the places those old HTTP links often hide. If certificate renewal or installation keeps failing, a managed option can remove the guesswork. ZADiC’s managed SSL service is built for site owners who want certificate management handled with their hosting setup. Investigate REST API failures The REST API lets WordPress components and approved services exchange data. The block editor, plugin integrations, forms, and external tools may depend on it. Open the Site Health warning and record the response code: A 401 or 403 often points to authentication, a firewall, a security plugin, or server rules. A 404 can indicate rewrite or permalink problems. A 500 usually requires checking PHP or server logs. A timeout can point to resource limits, DNS, outbound request blocks, or a slow plugin. The WordPress Site Health REST API reference documents Site Health test records, including the loopback-request test. That detail helps developers and hosts work from the same technical language. Solve a failed loopback request step by step A loopback request is WordPress asking the same site to respond. WordPress uses loopbacks for tasks such as starting a new WP-Cron instance and editing a plugin or theme. That makes a failed loopback more serious than a harmless dashboard warning. Backups may be delayed, scheduled events may not run, and plugin or theme editing can fail. Check the site from the outside Begin with a practical health check by confirming that the site loads normally over HTTPS. Check the homepage, login page, and a simple public post from a different network if possible. Next, identify anything that could block WordPress from reaching itself: Maintenance mode or password protection. Basic authentication on the whole site. A firewall or security plugin blocking the server IP. A CDN or WAF rule challenging server requests. Broken DNS records. An SSL mismatch or bad redirect. A server rule that blocks wp-cron.php or WordPress REST requests. Don’t disable every security tool at once. Test one change at a time, preferably on staging, and turn protection back on after the test. The WP_Site_Health class reference describes loopbacks as WordPress querying itself. Use that simple model for a troubleshooting sequence across the server layers. Know when the host must step in If the site loads for visitors but loopbacks fail, the hosting account may be blocking server-to-server requests. Ask your provider to test a request from the server back to the site and review firewall, DNS, SSL, cURL, and cron logs, including relevant error logging. Send the exact Site Health message, timestamp, domain, response code, and recent changes. Ask whether outbound HTTP requests are allowed and whether the server can resolve the domain to the correct address. If the same warning returns after every plugin fix, stop repeating the plugin fix. The server, firewall, DNS, or hosting account may be the real problem. Choose hosting that prevents repeat warnings Site Health is a diagnostic tool, not a replacement for dependable hosting. If your site repeatedly reports old PHP, failed loopbacks, weak resources, SSL problems, or update failures, ask your hosting provider to review the environment. For a small business site, reliable WordPress hosting should include a current PHP version, automatic backups, SSL, monitoring for security vulnerabilities, and support that can inspect server logs. ZADiC WordPress hosting plans include automatic setup, backups, automatic updates, free SSL on many plans, and 24/7 human support. If you don’t want to manage server settings yourself, managed WordPress hosting can handle more routine maintenance, PHP setup, caching, security, and backup work. That gives you fewer warnings to chase and more time to run the business. For sites that have outgrown shared resources, stronger hosting may be the better fix. Our guide to speeding up WordPress explains when cleaner server resources, caching, CDN support, or a VPS may improve site performance more than another optimization plugin. Frequently Asked Questions Where can I find WordPress Site Health? You can find it in the WordPress dashboard under Tools > Site Health. The Status tab checks for problems, while the Info tab shows the technical details support teams may need. Does a green Site Health result mean my site is performing well? No. A green result means WordPress found no listed Site Health problems, but it doesn’t guarantee fast pages, perfect uptime, or strong hosting resources. What should I fix first in Site Health? Start with critical issues that could affect security, stability, updates, or important WordPress functions. Fix the highest-risk problem first, such as outdated PHP, failed loopbacks, blocked REST API requests, or SSL errors. When should I contact my hosting provider? Contact your host when the warning points to PHP, DNS, SSL, firewall rules, server logs, cron activity, or blocked outbound requests. Include the exact message, response code, timestamp, recent changes, and relevant Site Health Info so support can investigate faster. Conclusion WordPress Site Health turns a vague “something is wrong” feeling into a practical troubleshooting path. Start with Status, fix critical issues first, use Info to collect evidence, and involve your host when problems reach PHP, DNS, SSL, firewalls, or server logs. We’ve found that the fastest fixes come from matching each warning to the right layer. Update WordPress software when the issue is inside WordPress. Improve hosting when the same server-level problems keep returning. [...]
Read more...
WordPressFix WordPress “failed to open stream” Errors FastA WordPress site can look completely broken when one PHP file is missing, unreadable, or referenced incorrectly. The “failed to open stream” error message names the path PHP tried to access, making it our fastest diagnostic clue. We don’t start by reinstalling WordPress or changing random permissions. We identify the file path first, then check whether PHP can access it or whether the PHP version may cause a compatibility issue. We also don’t edit wp-config.php unless the error points to it. A resulting fatal error can stop the site or dashboard from loading. Key Takeaways Copy the complete “failed to open stream” message and identify the exact file path before changing anything. Check whether the named file is missing, incorrectly referenced, unreadable, or affected by a PHP version mismatch. Use debug logging, FTP, cPanel, or phpMyAdmin to repair plugins, themes, WordPress core files, paths, permissions, and ownership when the dashboard is unavailable. Avoid risky fixes such as setting permissions to 777 or editing wp-config.php unless the error specifically points to it. Keep current backups of site files and the database, and test updates, migrations, PHP changes, and permission changes before applying them to production. What the “failed to open stream” Error Really Means PHP uses functions such as include, require, and fopen to open files. The require function stops execution when its file is unavailable, while the include function reports a warning and continues when possible. A stream is the connection PHP tries to create with that file. When PHP can’t create it, WordPress reports a “failed to open stream” error. You may see an error like Warning: require(...): Failed to open stream, followed by Fatal error: Uncaught Error. This error message identifies an access problem. The fatal error stops the rest of the request. The warning points to the cause, while the fatal error prevents WordPress from continuing. The wording for a missing file doesn’t always mean the file was deleted. The full file path is usually the main clue, so copy the complete error string before troubleshooting. The path may be wrong, the server may use another folder, or a PHP version mismatch may change application behavior. Read the final part of the error message Start at the end of the file path. Look for the plugin, theme, WordPress core folder, vendor directory, or wp-config.php named there. For example, a path containing /wp-content/plugins/example-plugin/ points us toward a plugin problem. A path containing /wp-content/themes/ suggests a theme issue. A path under /vendor/ usually points to Composer-managed dependency files in the vendor folder or a custom PHP application. The error message’s ending gives us another useful clue: Error endingLikely causeFirst checkNo such file or directoryMissing file or incorrect pathConfirm the full path and filenamePermission deniedFile ownership or permissionsCheck access for the web serverIs a directoryCode expects a file but finds a folderReview the filename and pathFailed opening requiredrequire could not load the fileRepair the missing dependency The PHP include manual explains how PHP resolves included files. That matters when a relative path works on one server but fails after a migration. Also confirm the PHP version used by the site when comparing behavior across servers. Find the Exact File Before Changing Anything Guessing creates more problems. A failed to open stream error can lead to a fatal error, so change one thing at a time, starting with the exact file named in the error. A failed update, server migration, deleted plugin, incomplete upload, or changed PHP path can trigger the problem. Write down what changed before the site failed, including whether the host changed the web server’s PHP version. That detail often points straight to the cause. Turn on the WordPress debug log safely If you can access wp-config.php, open it through cPanel, FTP, or SSH. Edit wp-config.php to enable logging privately, without displaying errors to visitors. The constants belong in wp-config.php; add these lines before the comment that says That's all, stop editing: define( 'WP_DEBUG', true ); define( 'WP_DEBUG_DISPLAY', false ); define( 'WP_DEBUG_LOG', true ); If these constants already exist in wp-config.php, edit their values instead of adding duplicates. WordPress normally writes the error log to wp-content/debug.log. You can also set a custom writable path, such as define( 'WP_DEBUG_LOG', '/tmp/wp-errors.log' );. Visit the broken page or repeat the action that caused the error message. Before editing any files, copy the complete error string and note its timestamp. Then open the error log through cPanel File Manager, FTP, or another file transfer method, and read the newest entries. WordPress documents this process in its guide to debugging WordPress errors. After reviewing the log, remove the temporary settings from wp-config.php and turn off debug mode. Debug logs can contain passwords, file paths, and other private details. Protect wp-config.php from public access, and don’t leave debugging active longer than needed. Check the file and the recent changes Use File Manager or FTP to inspect the exact file path named in the error. Check all of these details: Does the file exist with the same spelling and capitalization? Is the path pointing to the current domain folder? Did a plugin or theme update stop partway through? Did the error begin after moving to a new host, and does the current PHP version match the environment that previously worked? Does the file have a zero-byte size or look incomplete? Can the web server user read the file? If the file exists but PHP still reports “no such file or directory,” inspect the parent folders and verify each part of the file path. A single incorrect directory name can break the whole path. Server logs can also reveal failures that happen during cron jobs or background requests, so analyzing server logs for SEO issues can help when the browser shows very little. Restore Missing WordPress Files Without the Dashboard A fatal error can remove access to /wp-admin/, but the dashboard isn’t required for every failed to open stream repair. Hosting control panels, FTP, and phpMyAdmin provide other recovery routes. Before replacing files, create a backup if you can. Back up wp-config.php before any FTP or cPanel file transfer. This gives you a safe return point if the first fix doesn’t work. Disable a plugin through FTP or cPanel If the error identifies a plugin, open wp-content and rename the plugins folder to plugins.off. WordPress will stop loading the plugin files, which often restores the site and admin area. If the site comes back, rename the folder to plugins again. Then rename individual plugin folders one at a time until you find the one causing the failure. Update, replace, or remove that plugin only after confirming the source. Don’t delete the whole plugin folder as a first move. Renaming preserves the files and gives us a quick rollback. Repair a theme or WordPress core file When the active theme is missing or damaged, rename its folder. WordPress may then switch to an installed default theme while keeping the theme files available. If it doesn’t, use phpMyAdmin to inspect the site’s options table and check that the template and stylesheet values match an installed theme folder. Change those values only when you know the correct theme directory. Before uploading replacement files, confirm the PHP version and choose a package supported by that environment. For damaged WordPress core files, upload a fresh copy of the matching WordPress version. Replace the core folders and files, but leave wp-config.php and .htaccess untouched during the replacement. If the reported location identifies wp-config.php, restore or inspect it instead. Afterward, run integrity checks, such as a checksum or equivalent verification, on the WordPress core files. Use phpMyAdmin to confirm database access after the file repair. If you have a clean restore point, cPanel website backup restoration can be safer than manually rebuilding a broken installation. Restore the site files and database together when both changed around the same time. After restoration, confirm the site runs on the expected PHP version. Fix WordPress File Paths and Permissions Many failed to open stream errors appear after a hosting move. Code may still point to an old location, even when the file exists. Others happen because the file is present but PHP cannot read it. Replace hardcoded paths with WordPress constants A hardcoded file path can survive a server migration, then fail when the account name, domain folder, or server changes. WordPress provides path constants that follow the current installation. Inside WordPress-loaded code, use: require_once ABSPATH . 'wp-load.php'; $file = WP_CONTENT_DIR . '/uploads/example.txt'; require_once __DIR__ . '/includes/helpers.php'; ABSPATH and WP_CONTENT_DIR are path constants. ABSPATH points to the WordPress installation directory. WP_CONTENT_DIR points to the content folder on the server. Together, they produce an absolute path, not a web address. These path constants are for filesystem access, not browser URLs. For a browser URL, use the relevant URL constant instead. In a plugin, __DIR__ is often the safest way to reference a file stored beside the current PHP file. It avoids assumptions about the working directory. Verify the constructed file path with file_exists() before opening it when an optional file shouldn’t stop the entire request. After the move, test path-related code with the site’s current PHP version. Confirm the repaired code runs on the current PHP version before deploying it. Set safe permissions and correct ownership WordPress documentation generally recommends 644 or 640 for files and 755 or 750 for directories. See the official guide to WordPress file permissions before changing access settings. A typical setup looks like this: ItemCommon settingRegular PHP, CSS, and image files644WordPress directories755wp-config.phpMore restrictive, where supportedDebug logWritable only when logging is active Keep wp-config.php more restrictive where supported. Don’t alter wp-config.php unless the reported path points to it. Don’t change file permissions to 777 to make the error disappear. It grants far more access than WordPress needs and can create a security problem. Permissions aren’t the whole story. A file set to 644 can still fail when it belongs to the wrong server user or group. If PHP reports Permission denied, ask your host to correct ownership rather than applying broad recursive permission changes. Handle Custom PHP, MVC, and Laravel Paths The same “failed to open stream” error appears outside WordPress too. In a custom MVC structure or Laravel app, the error message points to the same first step: identify the exact path PHP tried to open. Stop relying on fragile relative paths A relative path may work when a file loads directly, then fail through another controller, cron job, or command line process. PHP’s working directory isn’t always the folder you expect, so check the web runtime’s PHP version when entry points differ. Use path constants to build a stable file path instead: __DIR__ . '/config/database.php' dirname(__DIR__) . '/vendor/autoload.php' $_SERVER can build an absolute path during a normal web request, such as $_SERVER . '/includes/file.php'. The document root isn’t dependable for CLI scripts, queue workers, or cron jobs because those processes may not provide the same server variable. A defined application base directory is safer, and Laravel or custom MVC applications shouldn’t assume WordPress’s wp-config.php conventions. Check Composer dependencies in Laravel If the error names a missing PHP file under vendor, Laravel is trying to load a Composer dependency that isn’t present or readable. Common causes include an incomplete deployment, a missing vendor folder, a mismatch between composer.lock and uploaded files, or incorrect ownership. Run integrity checks on the lock file, autoload mappings, and uploaded deployment files. Check the deployment directory and the deployment CLI’s PHP version, then confirm production matches the required PHP version. Then run the deployment’s normal Composer install process using the server’s supported PHP version. Don’t copy one random file into the vendor folder; Composer manages related files and autoload mappings together. The require function produces a fatal error when its target can’t load. The include function usually raises a warning and allows execution to continue. Use require for files the application can’t operate without, and include for genuinely optional files. Either function still needs a valid, readable path. Prevent Future PHP File Access Problems A good repair fixes the immediate file problem. A good hosting setup makes recovery faster next time. Keep WordPress core files, plugin files, theme files, the PHP version, and server software updated. Test major changes in a staging environment when your plan supports it. Check compatibility with your PHP version before production updates. Remove plugins and themes you no longer use, because unused files create security risks. Backups should include both site files and the database, with a copy of wp-config.php. Automatic daily copies, on-demand restore points, malware scans, integrity checks, SSL, and human support turn a long emergency into a short recovery. Export the database through phpMyAdmin when needed, and protect wp-config.php because it contains database credentials and other sensitive configuration. After migrations or changes involving file permissions, verify wp-config.php and test the site. Our WordPress hosting with automatic backups includes tools built for that kind of protection. If you need a simple control panel for files, databases, backups, and one-click WordPress setup, compare cPanel WordPress hosting. When traffic, memory needs, or technical demands grow, managed hosting can take routine updates and monitoring off your plate. The cheapest fix is often the one you can complete without rebuilding the site. Keep a clean backup before updates, migrations, and permission changes. Frequently Asked Questions What does “failed to open stream” mean in WordPress? It means PHP could not open a file that WordPress or another PHP application tried to load. The file may be missing, referenced by an incorrect path, unreadable because of permissions, or affected by a PHP compatibility issue. How do I find which file is causing the error? Read the complete error message and copy the full path named after require, include, or fopen. The folder usually identifies whether the problem involves a plugin, theme, WordPress core, vendor dependency, or wp-config.php. Can I fix the error if I cannot access WordPress admin? Yes. Use FTP or cPanel to rename the suspected plugin or theme folder, restore missing files, or inspect permissions. phpMyAdmin can also help switch to an installed theme when a damaged active theme prevents the site from loading. Should I set WordPress file permissions to 777? No. WordPress generally uses 644 or 640 for files and 755 or 750 for directories, depending on the server setup. If the error says Permission denied, incorrect ownership may be the real cause, so ask the host to correct it instead of applying broad permissions. Why does the error happen after moving hosts or updating PHP? A migration can leave hardcoded paths pointing to the old server location, while an update can expose incompatible code or missing dependencies. Check the current PHP version, verify the complete file path, and replace fragile paths with constants such as ABSPATH, WP_CONTENT_DIR, or __DIR__ where appropriate. Conclusion A WordPress failed to open stream error usually means the location is wrong, the file is missing, or PHP can’t access it. Read the complete error message, enable logging, inspect the named file, then repair only the affected component, location, or permission. You don’t need to panic when the dashboard disappears. FTP, cPanel, and phpMyAdmin, along with reliable backups and responsive hosting support, offer practical recovery options. Protect wp-config.php and confirm the site’s PHP version before making changes. Most cases are repairable, not a fatal error, so one missing file doesn’t have to become a lost weekend. [...]
Read more...

How to Raise the WordPress Upload File Size Limit

What Sets the WordPress Upload File Size Limit

Check the number WordPress reports

Find the layer that owns the limit

Match the PHP Settings That Control Uploads

Use values that work together

Pick a limit your site can support

Raise the WordPress Upload Limit in cPanel

Change PHP values in MultiPHP INI Editor

Get hosting support when controls are locked

Use a Configuration File When cPanel Isn’t Available

Try a `.user.ini` file first

Use `.htaccess` with care

Adjust Multisite Upload Caps Separately

Check Network Admin settings

Keep the policy practical

Fix Upload Errors That Aren’t Size Problems

Match the error to the likely cause

Know when better hosting is the answer

Keep Larger Uploads Safe and Sensible

Set limits around real file needs

Treat uploads and backups differently

A Better Upload Experience Starts With the Right Limit

Submit a Comment Cancel reply

Who we are

Comments

Media

Cookies

Embedded content from other websites

Who we share your data with

How long we retain your data

What rights you have over your data

Where your data is sent

How to Raise the WordPress Upload File Size Limit

What Sets the WordPress Upload File Size Limit

Check the number WordPress reports

Find the layer that owns the limit

Match the PHP Settings That Control Uploads

Use values that work together

Pick a limit your site can support

Raise the WordPress Upload Limit in cPanel

Change PHP values in MultiPHP INI Editor

Get hosting support when controls are locked

Use a Configuration File When cPanel Isn’t Available

Try a .user.ini file first

Use .htaccess with care

Adjust Multisite Upload Caps Separately

Check Network Admin settings

Keep the policy practical

Fix Upload Errors That Aren’t Size Problems

Match the error to the likely cause

Know when better hosting is the answer

Keep Larger Uploads Safe and Sensible

Set limits around real file needs

Treat uploads and backups differently

A Better Upload Experience Starts With the Right Limit

Submit a Comment Cancel reply

Who we are

Comments

Media

Cookies

Embedded content from other websites

Who we share your data with

How long we retain your data

What rights you have over your data

Where your data is sent

Try a `.user.ini` file first

Use `.htaccess` with care