Fix a WordPress 413 Error Without Breaking Uploads

A failed upload can stop a site update cold. You pick a new theme, add a product image, or import a backup, then WordPress throws a message that looks far more serious than it is.

A WordPress 413 error means the server rejected a request because the file or data package was too large. The fix is usually straightforward, but it has to happen at the layer that set the limit.

Start by finding where the upload is blocked, then raise only the limit you need.

What a 413 error means on a WordPress site

HTTP status code 413 is now commonly called “Content Too Large.” You may still see the older wording, “Request Entity Too Large,” in hosting dashboards, server logs, and WordPress alerts. Both messages point to the same issue.

As MDN’s explanation of HTTP 413 puts it, the request body exceeded a size limit set by the server. That request may be a media file, ZIP file, database import, form submission, or a plugin sending data through the WordPress REST API.

The error is usually not inside WordPress

WordPress is often where you see the failure. It usually isn’t where the restriction began.

Your request may pass through several gates before it reaches WordPress:

A CDN or proxy, such as Cloudflare
Your web server, often Nginx or Apache
PHP’s upload and POST limits
A WordPress plugin, security tool, or import tool

Think of it like shipping a package through several checkpoints. The first checkpoint with a smaller box slot sends it back. Raising a limit later in the path won’t change that.

Common moments when it appears

A WordPress 413 error often shows up when you upload a large image, install a plugin ZIP, restore a backup, import WooCommerce products, or submit a form with hefty attachments.

The file size matters, but the total request size matters too. A 40 MB file can become a larger POST request once form data and upload details are added.

If a 25 MB upload fails but a 2 MB upload works, you have a size limit problem. If every upload fails, check permissions, storage space, and server errors too.

Diagnose the WordPress 413 error in the right order

Don’t start changing random settings. That approach can turn one clear issue into five unclear ones.

First, write down the failed action and the file size. Then try a smaller file. A test file just below the suspected limit, followed by one just above it, can reveal the actual ceiling fast.

What fails	Likely place to check first
Media Library image or video upload	Nginx, PHP, hosting panel
Theme or plugin ZIP upload	Nginx, PHP, WordPress file limits
Backup restoration or site migration	Host limits, PHP, migration plugin
Form attachment upload	Form plugin, PHP, web server
API request or headless upload	CDN, proxy, Nginx location rules

The browser’s developer tools and your hosting error logs can help, but you don’t need to become a server detective. Check your hosting stack first. If your site uses Cloudflare, inspect that layer before editing WordPress or PHP settings.

Look for clues in the error page

An Nginx-branded error page is a strong sign that Nginx stopped the request. A generic Cloudflare error can mean the request never reached your host. A WordPress dashboard notice that mentions maximum upload size often points toward PHP or a host-level setting.

If you’re on managed hosting, check the knowledge base or ask support which web server sits in front of PHP. One clear question saves a lot of trial and error: “What request-body limit applies to this domain, and where can it be changed?”

Confirm the current WordPress upload limit

In the WordPress dashboard, go to Media > Add New. WordPress normally displays the maximum upload file size near the uploader.

That number is useful, but it isn’t the whole story. It may show PHP’s limit while Nginx or a proxy has a lower cap. A WordPress setting can’t overrule a smaller server-level limit.

Raise the Nginx request size limit

Nginx is one of the most common sources of this problem. Its client_max_body_size directive controls the largest request body Nginx accepts. Nginx documents a default of 1m, which is far too small for many modern photos, plugin archives, and backups.

The official Nginx directive reference confirms that requests above this setting return a 413 response.

Add a sensible client_max_body_size value

For many small business WordPress sites, 64m is a practical starting point. If you routinely upload large galleries, WooCommerce imports, or backup archives, 128m may make more sense.

Add this directive in the right Nginx configuration scope:

client_max_body_size 64m; for a 64 MB request limit
client_max_body_size 128m; for a 128 MB request limit

Place it in the http, server, or relevant location block. A more narrowly scoped location rule can override a broader setting. That detail catches people out all the time.

Avoid setting client_max_body_size 0; on a production site. It removes Nginx’s body-size check entirely, which gives oversized requests an open door.

Reload Nginx after saving changes

A changed config file does nothing until Nginx reloads. On a self-managed VPS, test the configuration first, then reload the service. Your hosting provider may handle this through a dashboard or support request.

If you have SSH access but don’t manage servers often, pause before editing a live config file. A misplaced character can take down a site. Our VPS and managed hosting customers can ask for help before a server setting becomes a late-night repair job.

Set PHP upload limits high enough

Once Nginx allows the request through, PHP still has its own rules. The two settings that matter most are upload_max_filesize and post_max_size.

PHP’s core configuration documentation states that post_max_size affects file uploads and must be larger than upload_max_filesize for larger uploads to work.

Use values that work together

If you want to allow 64 MB files, don’t set both values to 64 MB. The POST request includes more than the file itself.

A sensible example looks like this:

Set upload_max_filesize to 64M
Set post_max_size to 80M or 96M
Set memory_limit high enough for image processing and imports
Raise max_execution_time if big imports time out

For 128 MB uploads, upload_max_filesize at 128M and post_max_size at 160M or 192M gives the request breathing room. More isn’t always better. Set limits around the largest legitimate file your site needs.

Don’t rely on a theme’s functions.php file for this. Theme changes can wipe out that adjustment, and many hosts block PHP values set this way.

Change PHP limits through cPanel or your host

Many shared hosting accounts let you edit these values in cPanel through MultiPHP INI Editor, Select PHP Version, or a PHP Options screen. Menu names vary by host.

Hosting teams that manage servers through WHM can use cPanel’s MultiPHP INI Editor documentation to check the available directives. If the field is locked, that setting belongs to the hosting provider.

Look for a per-site php.ini or .user.ini file only when your host supports it. Then allow time for PHP to read the change. Some configurations cache .user.ini values for several minutes.

Check Cloudflare, Apache, and managed-host limits

A larger PHP limit won’t help when another service rejects the request first. This is where many WordPress 413 error fixes go in circles.

Check the proxy before the origin server

If your domain is proxied through Cloudflare, test whether the request reaches the host. Cloudflare product limits vary. For example, Cloudflare Pages limits set a 25 MiB maximum for an individual site asset.

That doesn’t automatically mean your WordPress Media Library is limited to 25 MiB. It does show why product-specific limits matter. The service handling the upload path sets the rule.

Temporarily pausing the proxy for a controlled test can help isolate the cause. Don’t leave security or caching services disabled longer than needed. If the upload works with the proxy off, contact the provider or adjust the relevant proxy rule.

Check Apache and host-level controls

Apache-hosted sites can have virtual-host rules, .htaccess controls, reverse proxies, or security modules that apply their own request caps. Your host may also use Nginx in front of Apache, so both layers can matter.

Managed WordPress platforms often hide raw server files for good reason. That doesn’t mean you’re stuck. Use the host panel if it exposes upload limits. Otherwise, ask support to increase the domain’s request-body limit and PHP upload settings together.

Reliable hosting should remove this kind of friction, not make it your weekend project. Our WordPress hosting, Web Hosting Plus, and VPS options give you room to grow, with support when a server setting needs a human touch.

Rule out WordPress plugins and file issues

The server is usually the culprit, but not always. Security plugins, form builders, backup tools, and migration plugins can set their own upload limits.

Test with a focused plugin check

If the server and PHP limits look right, deactivate only the plugin involved in the failing action. Then test again. For example, test a form attachment without the form plugin’s upload restriction, or check a migration tool’s documented import cap.

Don’t deactivate everything at once on a live business site. Make one change, run one test, and keep a note of the result. Calm troubleshooting wins here.

Also check available disk space. A host can allow a 128 MB upload, but WordPress may still fail while creating thumbnails or unpacking a plugin archive if the account is nearly full.

Keep security limits practical

Large request limits have a purpose. They can increase memory use, upload time, and exposure to abusive requests. Pick a ceiling that matches your real work.

A photographer may need 64 MB or 128 MB image uploads. A brochure site that only accepts logo files might need far less. Set the limit, test it, and leave the rest of your defenses in place.

Retest the upload and protect future updates

After changing any limit, clear relevant caches and retry the original action. Test the exact file that failed, then test a slightly larger file only if you need to confirm the new ceiling.

If the upload still fails, review the order again: proxy first, web server second, PHP third, WordPress tools last. The smallest active limit always wins.

Before importing a large backup or product catalog, confirm available storage, PHP memory, and timeout settings. Upload size is only one part of a successful big job.

Final Thoughts

A WordPress 413 error isn’t a mystery inside WordPress. It’s a request-size limit, and the fix is finding the first layer that says no.

Set practical Nginx and PHP limits, check any proxy in front of your site, and test one change at a time. Once the limits match the work your site needs to do, uploads stop being a roadblock and go back to being routine.

Submit a Comment Cancel reply

What's New?

WordPressFix a WordPress 413 Error Without Breaking UploadsA failed upload can stop a site update cold. You pick a new theme, add a product image, or import a backup, then WordPress throws a message that looks far more serious than it is. A WordPress 413 error means the server rejected a request because the file or data package was too large. The fix is usually straightforward, but it has to happen at the layer that set the limit. Start by finding where the upload is blocked, then raise only the limit you need. What a 413 error means on a WordPress site HTTP status code 413 is now commonly called “Content Too Large.” You may still see the older wording, “Request Entity Too Large,” in hosting dashboards, server logs, and WordPress alerts. Both messages point to the same issue. As MDN’s explanation of HTTP 413 puts it, the request body exceeded a size limit set by the server. That request may be a media file, ZIP file, database import, form submission, or a plugin sending data through the WordPress REST API. The error is usually not inside WordPress WordPress is often where you see the failure. It usually isn’t where the restriction began. Your request may pass through several gates before it reaches WordPress: A CDN or proxy, such as Cloudflare Your web server, often Nginx or Apache PHP’s upload and POST limits A WordPress plugin, security tool, or import tool Think of it like shipping a package through several checkpoints. The first checkpoint with a smaller box slot sends it back. Raising a limit later in the path won’t change that. Common moments when it appears A WordPress 413 error often shows up when you upload a large image, install a plugin ZIP, restore a backup, import WooCommerce products, or submit a form with hefty attachments. The file size matters, but the total request size matters too. A 40 MB file can become a larger POST request once form data and upload details are added. If a 25 MB upload fails but a 2 MB upload works, you have a size limit problem. If every upload fails, check permissions, storage space, and server errors too. Diagnose the WordPress 413 error in the right order Don’t start changing random settings. That approach can turn one clear issue into five unclear ones. First, write down the failed action and the file size. Then try a smaller file. A test file just below the suspected limit, followed by one just above it, can reveal the actual ceiling fast. What failsLikely place to check firstMedia Library image or video uploadNginx, PHP, hosting panelTheme or plugin ZIP uploadNginx, PHP, WordPress file limitsBackup restoration or site migrationHost limits, PHP, migration pluginForm attachment uploadForm plugin, PHP, web serverAPI request or headless uploadCDN, proxy, Nginx location rules The browser’s developer tools and your hosting error logs can help, but you don’t need to become a server detective. Check your hosting stack first. If your site uses Cloudflare, inspect that layer before editing WordPress or PHP settings. Look for clues in the error page An Nginx-branded error page is a strong sign that Nginx stopped the request. A generic Cloudflare error can mean the request never reached your host. A WordPress dashboard notice that mentions maximum upload size often points toward PHP or a host-level setting. If you’re on managed hosting, check the knowledge base or ask support which web server sits in front of PHP. One clear question saves a lot of trial and error: “What request-body limit applies to this domain, and where can it be changed?” Confirm the current WordPress upload limit In the WordPress dashboard, go to Media > Add New. WordPress normally displays the maximum upload file size near the uploader. That number is useful, but it isn’t the whole story. It may show PHP’s limit while Nginx or a proxy has a lower cap. A WordPress setting can’t overrule a smaller server-level limit. Raise the Nginx request size limit Nginx is one of the most common sources of this problem. Its client_max_body_size directive controls the largest request body Nginx accepts. Nginx documents a default of 1m, which is far too small for many modern photos, plugin archives, and backups. The official Nginx directive reference confirms that requests above this setting return a 413 response. Add a sensible client_max_body_size value For many small business WordPress sites, 64m is a practical starting point. If you routinely upload large galleries, WooCommerce imports, or backup archives, 128m may make more sense. Add this directive in the right Nginx configuration scope: client_max_body_size 64m; for a 64 MB request limit client_max_body_size 128m; for a 128 MB request limit Place it in the http, server, or relevant location block. A more narrowly scoped location rule can override a broader setting. That detail catches people out all the time. Avoid setting client_max_body_size 0; on a production site. It removes Nginx’s body-size check entirely, which gives oversized requests an open door. Reload Nginx after saving changes A changed config file does nothing until Nginx reloads. On a self-managed VPS, test the configuration first, then reload the service. Your hosting provider may handle this through a dashboard or support request. If you have SSH access but don’t manage servers often, pause before editing a live config file. A misplaced character can take down a site. Our VPS and managed hosting customers can ask for help before a server setting becomes a late-night repair job. Set PHP upload limits high enough Once Nginx allows the request through, PHP still has its own rules. The two settings that matter most are upload_max_filesize and post_max_size. PHP’s core configuration documentation states that post_max_size affects file uploads and must be larger than upload_max_filesize for larger uploads to work. Use values that work together If you want to allow 64 MB files, don’t set both values to 64 MB. The POST request includes more than the file itself. A sensible example looks like this: Set upload_max_filesize to 64M Set post_max_size to 80M or 96M Set memory_limit high enough for image processing and imports Raise max_execution_time if big imports time out For 128 MB uploads, upload_max_filesize at 128M and post_max_size at 160M or 192M gives the request breathing room. More isn’t always better. Set limits around the largest legitimate file your site needs. Don’t rely on a theme’s functions.php file for this. Theme changes can wipe out that adjustment, and many hosts block PHP values set this way. Change PHP limits through cPanel or your host Many shared hosting accounts let you edit these values in cPanel through MultiPHP INI Editor, Select PHP Version, or a PHP Options screen. Menu names vary by host. Hosting teams that manage servers through WHM can use cPanel’s MultiPHP INI Editor documentation to check the available directives. If the field is locked, that setting belongs to the hosting provider. Look for a per-site php.ini or .user.ini file only when your host supports it. Then allow time for PHP to read the change. Some configurations cache .user.ini values for several minutes. Check Cloudflare, Apache, and managed-host limits A larger PHP limit won’t help when another service rejects the request first. This is where many WordPress 413 error fixes go in circles. Check the proxy before the origin server If your domain is proxied through Cloudflare, test whether the request reaches the host. Cloudflare product limits vary. For example, Cloudflare Pages limits set a 25 MiB maximum for an individual site asset. That doesn’t automatically mean your WordPress Media Library is limited to 25 MiB. It does show why product-specific limits matter. The service handling the upload path sets the rule. Temporarily pausing the proxy for a controlled test can help isolate the cause. Don’t leave security or caching services disabled longer than needed. If the upload works with the proxy off, contact the provider or adjust the relevant proxy rule. Check Apache and host-level controls Apache-hosted sites can have virtual-host rules, .htaccess controls, reverse proxies, or security modules that apply their own request caps. Your host may also use Nginx in front of Apache, so both layers can matter. Managed WordPress platforms often hide raw server files for good reason. That doesn’t mean you’re stuck. Use the host panel if it exposes upload limits. Otherwise, ask support to increase the domain’s request-body limit and PHP upload settings together. Reliable hosting should remove this kind of friction, not make it your weekend project. Our WordPress hosting, Web Hosting Plus, and VPS options give you room to grow, with support when a server setting needs a human touch. Rule out WordPress plugins and file issues The server is usually the culprit, but not always. Security plugins, form builders, backup tools, and migration plugins can set their own upload limits. Test with a focused plugin check If the server and PHP limits look right, deactivate only the plugin involved in the failing action. Then test again. For example, test a form attachment without the form plugin’s upload restriction, or check a migration tool’s documented import cap. Don’t deactivate everything at once on a live business site. Make one change, run one test, and keep a note of the result. Calm troubleshooting wins here. Also check available disk space. A host can allow a 128 MB upload, but WordPress may still fail while creating thumbnails or unpacking a plugin archive if the account is nearly full. Keep security limits practical Large request limits have a purpose. They can increase memory use, upload time, and exposure to abusive requests. Pick a ceiling that matches your real work. A photographer may need 64 MB or 128 MB image uploads. A brochure site that only accepts logo files might need far less. Set the limit, test it, and leave the rest of your defenses in place. Retest the upload and protect future updates After changing any limit, clear relevant caches and retry the original action. Test the exact file that failed, then test a slightly larger file only if you need to confirm the new ceiling. If the upload still fails, review the order again: proxy first, web server second, PHP third, WordPress tools last. The smallest active limit always wins. Before importing a large backup or product catalog, confirm available storage, PHP memory, and timeout settings. Upload size is only one part of a successful big job. Final Thoughts A WordPress 413 error isn’t a mystery inside WordPress. It’s a request-size limit, and the fix is finding the first layer that says no. Set practical Nginx and PHP limits, check any proxy in front of your site, and test one change at a time. Once the limits match the work your site needs to do, uploads stop being a roadblock and go back to being routine. [...]
Read more...
WordPressFix a WordPress Plugin Update Permission Error FastNothing ruins a quick maintenance task like clicking “Update now” and seeing “Could not create directory” instead. A plugin update permission error isn’t usually a plugin problem. It’s WordPress telling you it can’t write where it needs to write. The good news? Most cases come down to file ownership, folder permissions, or the way your hosting account handles WordPress files. You don’t need to guess, and you definitely don’t need to make every file public to fix it. Start with the message in front of you, then work through the server checks in the right order. Fix the Plugin Update Permission Error by Reading Its Wording WordPress uses its filesystem to download, unpack, replace, and clean up plugin files. If one part of that chain fails, the wording gives you a useful clue. “Could not create directory” often points to permissions, ownership, storage space, or an unwritable wp-content/upgrade folder. “Installation failed” can mean the update download completed but WordPress couldn’t replace the old plugin files. An FTP credentials prompt is a hosting clue If WordPress suddenly asks for FTP credentials, it can’t write directly through PHP. That doesn’t mean you should enter random login details and hope for the best. The server may require FTP access, or WordPress may be configured to use it even though direct file access should work. In our experience, that prompt is one of the clearest signs that the hosting setup needs attention. A missing update option is a different problem If you don’t see an update button at all, check the WordPress account first. Plugin updates require the right capability. On a standard site, an Administrator can normally manage plugins. On a Multisite network, only a Super Admin can update them. WordPress explains these permissions in its roles and capabilities documentation. Fix the account access issue before touching server files. Protect the Site Before Changing Server Settings A plugin update replaces live files. If the update failed halfway through, the plugin folder may contain an incomplete version. That’s why a backup comes first. Take a full backup of your WordPress files and database. Record the plugin name, installed version, and exact error message. Then pause bulk or scheduled updates until the problem is fixed. WordPress also recommends making a backup before core changes in its official update guidance. The same common-sense rule applies to plugins. A backup is more than a safety net for a bad update. It gives you a clean version to compare against if a plugin folder has been partially replaced. Don’t set folders to 777 as a quick fix. It can make files writable, but it also opens a security hole. A secure fix solves the access issue without turning your website into an open door. Check WordPress Access and Available Storage Sometimes the error looks like a permissions problem because WordPress can’t finish creating a temporary directory. The file permission values may be fine. The account may simply be out of room. Use Site Health for a quick filesystem check In the WordPress dashboard, go to Tools > Site Health, then open the Info tab. Look for the Filesystem Permissions section. WordPress reports whether it can write to the directories it needs. Its Site Health documentation explains what that section checks. Pay close attention to wp-content, wp-content/plugins, wp-content/themes, and wp-content/upgrade. A red or failed result gives you a solid starting point. It also gives hosting support something concrete to investigate. Check disk quota and temporary files Open cPanel and look at the account’s disk usage. A full account can stop WordPress from unpacking an update, even when plugin folders appear writable. Old backups, email attachments, cache files, and abandoned staging copies can fill space fast. Remove only files you recognize. If you aren’t certain what a folder does, ask support before deleting it. Correct File Permissions and Ownership This is where many people get stuck. Permissions and ownership are related, but they aren’t the same thing. Permissions control what a file can do. Ownership controls which server user gets to do it. You can have a 755 folder that still blocks WordPress because the wrong user owns it. Start with conventional permission values On many cPanel and Linux hosting accounts, folders use 755 and files use 644. Your wp-config.php file may use tighter settings such as 640 or 600, depending on the server. Check these WordPress paths first: wp-content wp-content/plugins wp-content/upgrade The individual folder for the plugin that won’t update Avoid running a recursive permission change across the entire account. That can alter files that need different settings and create a larger mess than the original plugin update permission error. File ownership is often the real issue Ownership problems often appear after a migration, restore, manual FTP upload, or server move. For example, plugin files might belong to root, an old server user, or a different account than the PHP process uses. The website visitor won’t see that mismatch. WordPress will. It tries to replace a file, the server refuses, and the update stops. If cPanel lets you view ownership, compare the affected plugin folder with a working folder nearby. If it doesn’t, send hosting support the exact path and error. Ask them to confirm that the WordPress document root and PHP process have the correct owner and group. Set the Right WordPress Filesystem Method WordPress needs a valid method for writing files. When PHP can write as the correct hosting user, direct access is usually the cleanest path. When it can’t, WordPress may request FTP credentials. Check wp-config.php for forced FTP settings Open wp-config.php in cPanel File Manager and search for FS_METHOD. A line such as define('FS_METHOD', 'ftpext'); forces WordPress to use FTP. That setting can cause repeated credential prompts or failed updates when no valid FTP details are available. If your host confirms that WordPress should have direct write access, use: define('FS_METHOD', 'direct'); Add it above the line that says /* That's all, stop editing! Happy publishing. */. Setting FS_METHOD to direct doesn’t repair bad ownership. It only tells WordPress which route to use when the server already allows direct writes. Don’t force direct access on a managed platform that blocks it. The setting won’t override server rules, and it can leave you with the same error plus more confusion. Use approved FTP access when direct writes are blocked Some hosting environments require FTP or another controlled filesystem method. In that case, use the credentials and connection details supplied by the host. Make sure the FTP account points to the right WordPress document root. A valid login that opens the wrong folder won’t help. Never paste credentials into public notes, unsecured chat messages, or a plugin support forum. Retry the Update Without Adding More Damage Once access, space, ownership, and filesystem settings are corrected, retry one plugin update. Don’t launch ten updates at once. A single test gives you a clean answer. Use cPanel to inspect the affected plugin folder In cPanel File Manager, open your site’s document root, often public_html, then go to wp-content/plugins. Compare the problem plugin’s folder with a working plugin folder. Look for an empty folder, an oddly named temporary directory, or a plugin directory with a different modification date after the failed update. Check wp-content/upgrade too. Remove only abandoned temporary update files after you have a backup. If the update completes, test the site, open the plugin’s settings page, and clear any caching plugin or server cache. A successful update should not leave a broken front end behind. Reinstall a clean plugin copy if the update stopped midway If plugin files are incomplete, download a clean ZIP from the plugin developer or the official WordPress directory. Then use Plugins > Add New > Upload Plugin to install the clean copy after permissions are fixed. WordPress covers this process in its plugin management instructions. Don’t install ZIP files from unknown download sites. A permission error is frustrating, but malware is worse. If ownership can’t be changed in cPanel, stop there. That’s a server-level repair, not a reason to keep changing random settings. Choose Hosting That Makes Updates Less Stressful A healthy WordPress setup shouldn’t turn routine updates into a server investigation. Your hosting should give you useful controls, safe backups, clear file access, and real people when a server setting needs repair. At ZADiC, our WordPress hosting and Web Hosting Plus plans are built for small business owners who want less technical stress. You get cPanel access, security monitoring, backups, SSL options, and 24/7 human support when a file ownership issue isn’t something you should be fixing alone. Keep updates small and regular Update plugins one or two at a time, especially on a busy site. Check the site after major plugin updates, and keep inactive plugins removed. Use the same trusted account for file uploads whenever possible. Random FTP accounts, old migration tools, and manual server changes are common ways ownership gets out of sync. Treat repeated errors as a hosting warning One failed update can happen. Repeated permission failures are different. They often point to a hosting configuration that doesn’t match the way WordPress needs to work. We recommend fixing the cause, not living with FTP prompts, failed updates, or risky 777 permissions. Your website needs a hosting foundation that supports growth without making routine care feel like a gamble. A Working Update Button Starts With Healthy File Access A plugin update permission error is usually solvable once you separate account access, available storage, file permissions, ownership, and filesystem settings. Start small, keep a backup close, and test one update after each fix. The right permission values matter, but ownership often decides whether WordPress can act on them. When your host gives WordPress the access it needs, plugin updates go back to what they should be, quick maintenance instead of a stressful repair. [...]
Read more...
WordPressFix the WordPress Missing Stylesheet Error FastA theme upload can stop cold with one blunt message: “The package could not be installed. The theme is missing the style.css stylesheet.” The WordPress missing stylesheet error looks technical, but it usually comes down to one simple issue, you uploaded the wrong ZIP file. Your site isn’t broken. Your hosting probably isn’t broken either. WordPress simply can’t find the file that tells it, “Yes, this is a theme.” Let’s get the right package in place and get your new design live. What the error is actually telling you WordPress needs a theme’s main stylesheet, named style.css, to identify and load that theme. It is more than a file full of colors and fonts. Its header tells WordPress the theme’s name, version, author, and other basic details. When you upload a ZIP through Appearance > Themes, WordPress unpacks it and looks for that file in the right location. If it can’t find it, the installation stops. WordPress is checking the ZIP structure A valid theme package should open to one main theme folder. Inside that folder, style.css should be easy to find. Most themes also include folders and files such as: functions.php templates assets theme.json Screenshot images and language files The exact file mix changes between classic and block themes. Still, the stylesheet must be where WordPress expects it. The WordPress theme file structure explains how theme folders and required files fit together. If style.css is buried inside a second folder or a separate ZIP file, WordPress has no usable theme package to install. Your host usually isn’t the cause We’ve seen people clear caches, change PHP versions, and deactivate plugins after this message appears. Those steps won’t fix a bad theme archive. The WordPress missing stylesheet error happens during the upload check. It isn’t a speed issue, a database issue, or a sign that your website has been hacked. Start with the file you selected. That is almost always where the fix is. How to fix the WordPress missing stylesheet error The fastest fix is to locate the installable theme ZIP. Marketplace downloads often include more than the theme itself. You may receive documentation, licensing files, sample content, PSD files, child themes, and plugins in one large download. That full bundle is useful to keep. It is not the file you upload through WordPress. Find the installable theme ZIP Download folders from ThemeForest, Envato Elements, and independent theme shops often have two choices: “All files and documentation” “Installable WordPress file only” Choose the installable WordPress file when it is available. Envato confirms in its stylesheet error support guide that uploading the wrong download package causes this exact problem. If you already have the larger download, unzip it on your computer. Look for another ZIP named after the theme. That inner ZIP is often the one WordPress needs. For example, an outer download might contain a documentation folder, license text, demo content, and theme-name.zip. Upload theme-name.zip, not the outer package. Check the folder before trying again Open the ZIP you plan to upload. The first theme folder inside should contain style.css. A clean layout looks like this in plain terms: theme-name first, then style.css, functions.php, and theme folders inside it. A problem layout adds extra layers, such as download-folder > documentation > theme-name > style.css. If the stylesheet sits inside an extra folder, extract the package. Find the actual theme folder, then compress that folder into a new ZIP. Do not compress the whole download directory. Also check the file name. It must be style.css, all lowercase. A file named style.CSS, stylesheet.css, or style.css.txt won’t pass WordPress’ theme check. Upload the corrected theme package Once you have the right ZIP, installing it takes less than a minute. No file editing required. Use the Theme screen in WordPress Follow this order: Sign in to your WordPress dashboard. Go to Appearance > Themes > Add New. Select Upload Theme and choose the installable ZIP. Click Install Now, then activate the theme after WordPress confirms the installation. WordPress documents the same theme upload process for ZIP-based theme installs. If the upload works but the website looks different than the demo, don’t panic. Many premium themes need a separate demo-content import or companion plugin. That is a setup step, not a stylesheet error. Don’t upload a plugin as a theme This mix-up is common with page builders, sliders, security tools, and theme add-ons. A plugin ZIP belongs under Plugins > Add New, not Appearance > Themes. A premium theme may include both a theme ZIP and a required plugin ZIP. Install the theme first through the Themes screen. Then install its required plugins through the Plugins screen or the theme’s setup wizard. Most WordPress missing stylesheet error reports come from one of these two mistakes: a full download bundle or a plugin archive uploaded as a theme. Fix a child theme with the right headers Child themes need a little extra care. They let you customize a parent theme without losing changes when the parent updates. Smart move, but only when the child theme points to its parent correctly. Every child theme needs its own style.css A child theme requires a style.css file in its own folder. That stylesheet needs a theme name and a Template field. The Template value must match the parent theme’s folder name, not its display name. For example, an Astra child theme normally uses Template: astra because the parent theme folder is named astra. The official WordPress child theme guidance calls style.css the one file a child theme must have. One missing line can stop the installation. Install the parent theme first WordPress can’t run a child theme without its parent. Install and keep the parent theme in Appearance > Themes before uploading the child theme. Then check these three items: The child theme folder contains style.css. The Template value matches the parent folder name exactly. The parent theme is installed, even if it isn’t active. Avoid the old habit of importing a parent stylesheet with @import unless the theme developer tells you to use it. Modern child themes usually load parent styles through functions.php. If you bought the child theme, use the developer’s current installation instructions rather than an old forum snippet. Use cPanel when the dashboard upload fails Sometimes the correct ZIP still won’t upload because of a server upload limit, a timeout, or a sluggish dashboard session. In that case, cPanel File Manager gives you a direct route. Install the theme through File Manager Before changing files on a live site, make a backup or create a restore point. Then follow these steps: Open File Manager in cPanel. Go to public_html/wp-content/themes/. If WordPress is in a subfolder, open that site’s matching wp-content/themes/ directory. Upload the installable theme ZIP. Extract it and confirm the path ends with themes/theme-name/style.css. Return to Appearance > Themes in WordPress and activate the new theme. The final path matters. If it ends with themes/theme-name/theme-name/style.css, the theme is nested too deeply. Move the inner folder up one level, then refresh the Themes page. We recommend easy-to-manage cPanel web hosting for site owners who want access to files when WordPress is unavailable. It turns a stressful dead end into a fix you can handle in minutes. Check the download if activation still fails If the theme installs but won’t activate, download a fresh copy from the original seller. A partial or damaged ZIP can unpack without installing cleanly. Also check the theme’s current PHP and WordPress requirements. A theme that needs a newer PHP version may install but throw a different error when activated. Keep the original error message and take a screenshot before contacting the seller or host. Clear details get a faster answer. Never delete your active live theme as a quick test. Keep a backup and a default WordPress theme available first. Prevent theme problems before they interrupt business A working website needs boring reliability. That means using a simple process before each theme change, not crossing your fingers after the upload button is pressed. Test major theme changes off the live site Use a staging site when you are changing themes, importing demos, or installing a child theme. You can check menus, forms, mobile pages, and plugins without putting your public site at risk. Keep the original installable ZIP in a clearly labeled folder. Save the purchase receipt, license key, and setup notes with it. When an update arrives months later, you won’t have to guess which file belongs where. Avoid nulled or pirated themes. They often arrive with altered files, outdated code, or malware. A low upfront price can become an expensive cleanup job. Choose hosting built for easy recovery A host can’t fix an incorrect ZIP file. It can make every other part of recovery easier. For business websites, we recommend managed WordPress hosting when you want backups, updates, security checks, and real support without the usual server chores. If a theme test goes sideways, a recent backup and a one-click restore can save hours. Good hosting also gives you room to build. Faster pages, SSL protection, file access, and support all matter when your website is part of how you sell. Fix the file today, then give the site a stronger foundation for tomorrow. A clean ZIP solves the problem The WordPress missing stylesheet error is usually not a major repair. It is WordPress telling you that the ZIP does not contain a usable theme in the right place. Find the installable theme archive, check that style.css sits in the main theme folder, and upload it through the proper screen. For child themes, match the parent folder name exactly. A theme installation should be quick, predictable, and low-stress. With the right file and reliable hosting behind you, it can be. [...]
Read more...
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...