Skip to content
  • Quick Ref
  • Contact
  • About
wpcanyon.com

wpcanyon.com

Category: Fixes & Errors

413 Request Entity Too Large on media upload (Nginx/Apache)

Posted on August 19, 2025August 19, 2025 By Admin No Comments on 413 Request Entity Too Large on media upload (Nginx/Apache)

413 Request Entity Too Large on Media Upload (Nginx/Apache)

If you encounter the 413 Request Entity Too Large error when uploading media files to WordPress, it means your server is rejecting files that exceed its configured size limits. This is a common issue that can be quickly fixed by adjusting server settings.

Quick Fix

  1. For Nginx, increase the client_max_body_size directive.
  2. For Apache, increase the LimitRequestBody directive.
  3. Restart or reload your web server to apply changes.

Why This Happens

Web servers limit the size of HTTP request bodies to protect against resource exhaustion and abuse. When uploading large files, if the file size exceeds these limits, the server responds with a 413 error, blocking the upload. WordPress itself also has upload size limits, but this error originates from the web server before WordPress processes the file.

Step-by-step Fix per Server

1. Fix for Nginx

The client_max_body_size directive controls the maximum allowed size of the client request body, which includes file uploads.

  1. Open your Nginx configuration file. This is usually located at:
    • /etc/nginx/nginx.conf
    • or inside your site-specific config in /etc/nginx/sites-available/
  2. Find the http, server, or location block where you want to set the limit.
  3. Add or update the directive, for example to allow 64MB uploads:
client_max_body_size 64M;
  1. Save the file and test the configuration:
sudo nginx -t
  1. If the test is successful, reload Nginx:
sudo systemctl reload nginx

2. Fix for Apache

Apache uses the LimitRequestBody directive to limit the size of the HTTP request body.

  1. Open your Apache configuration file or your site’s .htaccess file. Common locations:
    • /etc/apache2/apache2.conf or /etc/httpd/conf/httpd.conf
    • Or inside your site root’s .htaccess
  2. Add or update the directive inside the appropriate context (e.g., <Directory> or globally):
LimitRequestBody 67108864

This example sets the limit to 64MB (64 * 1024 * 1024 bytes).

  1. Save the file.
  2. Restart Apache to apply changes:
sudo systemctl restart apache2
# or on CentOS/RHEL
sudo systemctl restart httpd

3. Verify WordPress PHP Upload Limits

Even after adjusting server limits, PHP settings can restrict upload size. Check and update these values in your php.ini or via your hosting control panel:

upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 128M

Restart PHP-FPM or your web server if needed.

Works on

Server Control Panel Applicable Directives
Nginx cPanel, CloudPanel, Plesk, Custom client_max_body_size
Apache cPanel, CloudPanel, Plesk, Custom LimitRequestBody, php.ini upload limits

FAQ

Q: How do I know if the 413 error is caused by Nginx or Apache?
A: Check your server stack. If you use Nginx as a reverse proxy in front of Apache, both may have limits. Start by increasing Nginx’s client_max_body_size. If only Apache is used, adjust LimitRequestBody.
Q: Can I set these limits in WordPress instead?
A: WordPress settings like upload_max_filesize and post_max_size in PHP control upload limits, but the 413 error is a server-level rejection. You must increase server limits first.
Q: What if I don’t have access to the server config files?
A: Contact your hosting provider to increase upload size limits or use their control panel if available. Some hosts allow changing PHP and server limits via cPanel or Plesk interfaces.
Q: Will increasing these limits affect server security?
A: Larger limits allow bigger uploads but can increase resource usage and risk of abuse. Set limits according to your site’s needs and monitor server performance.
Q: After changing the limits, the error persists. What else can I check?
Clear your browser cache, restart your web server and PHP services, and verify PHP upload limits. Also, check for any reverse proxies or firewalls that might impose their own limits.
…
Fixes & Errors

cURL error 60: SSL certificate problem in WordPress

Posted on August 19, 2025August 19, 2025 By Admin No Comments on cURL error 60: SSL certificate problem in WordPress

cURL error 60: SSL certificate problem in WordPress

If you encounter cURL error 60 in WordPress, it means your site is having trouble verifying the SSL certificate of a remote server. This error commonly appears when WordPress tries to communicate with external APIs or update services over HTTPS. The quick fix involves updating the CA certificates on your server or configuring WordPress to bypass strict SSL verification.

Quick Fix

  1. Download the latest cacert.pem file from the official cURL website.
  2. Upload the cacert.pem file to your server, preferably in a secure directory.
  3. Edit your php.ini file to point to the new CA bundle by adding or updating curl.cainfo and openssl.cafile directives.
  4. Restart your web server or PHP-FPM service to apply changes.
  5. Test your WordPress site again to confirm the error is resolved.

Why this happens

The cURL error 60 occurs because cURL, the library WordPress uses for HTTP requests, cannot verify the SSL certificate of the remote server. This usually happens when the CA (Certificate Authority) bundle on your server is outdated or missing. Without a valid CA bundle, cURL cannot confirm the authenticity of the SSL certificate, leading to the error.

Common scenarios include:

  • Outdated or missing CA certificates on your server.
  • Custom PHP installations without proper SSL configuration.
  • WordPress running on local or development environments with self-signed certificates.
  • Firewall or proxy servers interfering with SSL verification.

Step-by-step

1. Download the latest CA certificate bundle

Get the latest cacert.pem file from the official cURL website:

wget https://curl.se/ca/cacert.pem -O /path/to/your/cacert.pem

2. Upload the CA bundle to your server

Place the cacert.pem file in a secure directory on your server, for example:

/etc/ssl/certs/cacert.pem

3. Configure PHP to use the new CA bundle

Edit your php.ini file. The location of this file depends on your server setup. Common locations include /etc/php/7.x/apache2/php.ini or /etc/php/7.x/fpm/php.ini.

Add or update these lines:


curl.cainfo = "/etc/ssl/certs/cacert.pem"
openssl.cafile = "/etc/ssl/certs/cacert.pem"

4. Restart your web server or PHP service

Apply the changes by restarting your web server or PHP-FPM:

# For Apache
sudo systemctl restart apache2

# For Nginx with PHP-FPM
sudo systemctl restart php7.x-fpm
sudo systemctl restart nginx

5. Verify the fix in WordPress

Try performing the action that caused the error, such as updating plugins or themes, or connecting to an external API. The cURL error 60 should no longer appear.

Works on

Environment Notes
Apache Works by updating PHP’s php.ini and restarting Apache
Nginx + PHP-FPM Requires restarting PHP-FPM and Nginx after updating php.ini
LiteSpeed Update php.ini and restart LiteSpeed service
cPanel / Plesk Use the control panel’s PHP configuration editor or edit php.ini manually

FAQ

Q: Can I disable SSL verification to fix cURL error 60?
A: Disabling SSL verification is not recommended as it compromises security. Only use this as a temporary workaround in development environments.
Q: How do I find the location of my php.ini file?
A: Create a PHP file with <?php phpinfo(); ?> and access it via browser. Look for “Loaded Configuration File” to find the path.
Q: What if I don’t have access to php.ini?
A: Contact your hosting provider to update the CA certificates or configure PHP settings for you.
Q: Does this fix work for self-signed certificates?
A: No. Self-signed certificates require adding the certificate to your trusted CA bundle or disabling verification (not recommended).
Q: Will updating WordPress or plugins fix this error?
A: Not usually. This error is related to server configuration, not WordPress core or plugins.
…
Fixes & Errors

Fix ‘The link you followed has expired’ (WordPress uploads)

Posted on August 19, 2025August 19, 2025 By Admin No Comments on Fix ‘The link you followed has expired’ (WordPress uploads)

Fix ‘The link you followed has expired’ (WordPress uploads)

If you encounter the error message “The link you followed has expired” when uploading media or themes in WordPress, it usually means your server’s PHP settings are too low to handle the upload. This guide provides a quick fix to resolve this issue by increasing the PHP limits that control upload size and script execution time.

Quick Fix

  1. Increase the upload_max_filesize and post_max_size values in your PHP configuration.
  2. Increase the max_execution_time and max_input_time values to allow longer script processing.
  3. Restart your web server or PHP service to apply changes.

Why this happens

This error occurs because WordPress relies on PHP settings to manage file uploads and script execution. When you upload a file that exceeds the limits set by upload_max_filesize or post_max_size, or if the upload process takes longer than max_execution_time or max_input_time, PHP stops the process and WordPress shows this error.

Common default PHP limits are often too low for larger media files or themes, especially on shared hosting environments. Adjusting these values allows WordPress to handle bigger uploads and longer processing times.

Step-by-step

1. Locate your PHP configuration file (php.ini)

Find the php.ini file on your server. Its location depends on your hosting environment:

  • On many Linux systems: /etc/php/7.x/apache2/php.ini or /etc/php/7.x/fpm/php.ini
  • On cPanel servers: Use the MultiPHP INI Editor or check public_html/php.ini
  • On local setups: Check your PHP installation folder

2. Edit the php.ini file

Open the php.ini file with a text editor and update or add the following lines:

upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

Explanation:

  • upload_max_filesize: Maximum allowed size for uploaded files.
  • post_max_size: Maximum size of POST data allowed.
  • max_execution_time: Maximum time in seconds a script is allowed to run.
  • max_input_time: Maximum time in seconds a script is allowed to parse input data.
  • memory_limit: Maximum amount of memory a script may consume.

3. Restart your web server or PHP service

After saving the changes, restart your web server or PHP service to apply the new settings.

  • For Apache:
  • sudo systemctl restart apache2
  • For Nginx with PHP-FPM:
  • sudo systemctl restart php7.x-fpm
    sudo systemctl restart nginx

4. Verify changes

Create a phpinfo.php file in your WordPress root directory with the following content:

<?php
phpinfo();
?>

Access it via your browser (e.g., https://yourdomain.com/phpinfo.php) and confirm the new values for upload_max_filesize, post_max_size, max_execution_time, and max_input_time.

5. Remove the phpinfo.php file

For security reasons, delete the phpinfo.php file after verification.

Alternative: Using .htaccess (Apache only)

If you cannot access the php.ini file, you can try adding these lines to your WordPress root .htaccess file:

php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300
php_value max_input_time 300
php_value memory_limit 256M

Note: This method only works if your server allows overriding PHP settings via .htaccess. It does not work on Nginx or LiteSpeed servers.

Works on

Server Type Supported Method
Apache (cPanel, Plesk) php.ini, .htaccess
Nginx php.ini (no .htaccess support)
LiteSpeed php.ini (may support .htaccess depending on configuration)
Shared Hosting php.ini (via control panel or MultiPHP INI Editor)

FAQ

Q1: I increased the limits but still get the error. What else can I try?
Check your theme or plugin conflicts by disabling them temporarily. Also, verify your hosting provider does not enforce hard limits beyond your control.
Q2: Can I increase these limits via wp-config.php?
No, PHP upload and execution limits must be set in the server’s PHP configuration or .htaccess (Apache only). wp-config.php cannot modify these settings.
Q3: What if I don’t have access to php.ini or .htaccess?
Contact your hosting provider to increase the PHP limits or use their control panel tools like MultiPHP INI Editor.
Q4: Is it safe to increase these limits?
Yes, but avoid setting excessively high values as they can affect server performance or security. Use reasonable limits based on your needs.
Q5: How do I know the current PHP upload limits?
Create and access a phpinfo.php file with <?php phpinfo(); ?> and look for <
…
Fixes & Errors

WordPress stuck in maintenance mode: how to fix safely

Posted on August 18, 2025August 19, 2025 By Admin No Comments on WordPress stuck in maintenance mode: how to fix safely

WordPress stuck in maintenance mode: how to fix safely

When updating WordPress core, themes, or plugins, you might encounter the dreaded message: “Briefly unavailable for scheduled maintenance. Check back in a minute.” Sometimes, this message never goes away, leaving your site stuck in maintenance mode. The quick fix is to safely delete the .maintenance file from your WordPress root directory. This article explains why this happens and provides a step-by-step guide to resolve it without risking your site.

Quick Fix: Delete the .maintenance file

  1. Access your WordPress site files via FTP, SFTP, or SSH.
  2. Navigate to the root directory of your WordPress installation (where wp-config.php lives).
  3. Locate the file named .maintenance.
  4. Delete the .maintenance file.
  5. Reload your website in the browser; it should now load normally.

Why this happens

WordPress automatically creates a hidden file named .maintenance in the root directory when you start an update process. This file triggers the maintenance mode message to visitors. Normally, WordPress deletes this file once the update completes successfully.

However, if the update process is interrupted — due to server timeout, plugin conflicts, or manual termination — the .maintenance file remains, causing your site to stay in maintenance mode indefinitely.

Because the file is hidden (due to the leading dot), it’s easy to overlook, especially if you’re browsing files with a default file manager that doesn’t show hidden files.

Step-by-step guide to fix and rollback

  1. Backup your site
    Before making any changes, create a full backup of your WordPress files and database. This ensures you can restore your site if anything goes wrong.
  2. Access your site files
    Use an FTP client (like FileZilla), your hosting control panel’s file manager, or SSH to connect to your server.
  3. Locate and delete the .maintenance file
    Navigate to the root WordPress directory. Make sure hidden files are visible. Find and delete the .maintenance file.
  4. Check your site
    Refresh your website in a browser. It should load normally without the maintenance message.
  5. Verify updates
    Login to your WordPress admin dashboard and check if the updates completed successfully. If some updates failed, try updating those plugins/themes again.
  6. Rollback if necessary
    If the update caused issues, use your backup to restore the previous working state. Alternatively, use a plugin like WP Rollback to revert individual plugins or themes.

Deleting .maintenance via SSH

cd /path/to/your/wordpress/root
rm .maintenance

Deleting .maintenance via FTP

  • Connect with your FTP client.
  • Enable viewing hidden files (usually a setting like “Show hidden files”).
  • Navigate to the WordPress root folder.
  • Right-click the .maintenance file and delete it.

Works on

Environment Notes
Apache Standard WordPress hosting; file access via FTP/SSH works the same.
Nginx Same fix applies; no difference in maintenance file handling.
LiteSpeed Compatible; maintenance file method is identical.
cPanel Use File Manager or FTP to delete .maintenance.
Plesk Use File Manager or SSH to remove the file.

FAQ

Q: What if I don’t see the .maintenance file?
A: Ensure your FTP client or file manager shows hidden files. The file starts with a dot and is hidden by default.
Q: Can I just wait for WordPress to exit maintenance mode?
A: Normally yes, but if the update was interrupted, WordPress won’t remove the file automatically, so manual deletion is required.
Q: Is it safe to delete the .maintenance file?
A: Yes, deleting this file only disables maintenance mode. It does not affect your site’s data or files.
Q: How can I prevent this from happening again?
A: Avoid interrupting updates, ensure your server timeout settings are sufficient, and update plugins/themes one at a time if possible.
Q: My site is still broken after deleting .maintenance. What now?
Check for incomplete updates or plugin/theme conflicts. Restore from backup if necessary and try updating components individually.
…
Fixes & Errors

HTTP image upload errors: HTTP error / 500 / 503 in Media Library

Posted on August 18, 2025August 19, 2025 By Admin No Comments on HTTP image upload errors: HTTP error / 500 / 503 in Media Library

HTTP image upload errors: HTTP error / 500 / 503 in Media Library

When uploading images to the WordPress Media Library, encountering errors like “HTTP error,” “500 Internal Server Error,” or “503 Service Unavailable” can be frustrating. These errors prevent successful uploads and disrupt your workflow. The quick fix usually involves switching the editor or increasing server resources to handle the upload process smoothly.

Quick Fix

  1. Switch the WordPress editor from Gutenberg to Classic Editor or vice versa and try uploading again.
  2. Increase PHP memory limit and max upload size in your server configuration.
  3. Temporarily disable plugins that might interfere with uploads, especially security or optimization plugins.
  4. Check file permissions on the wp-content/uploads directory and correct them if necessary.
  5. Clear your browser cache and try a different browser to rule out client-side issues.

Why This Happens

These HTTP errors during image uploads are typically caused by server-side limitations or conflicts within WordPress. Common reasons include:

  • Insufficient PHP memory limit: WordPress needs enough memory to process image uploads and generate thumbnails.
  • File size limits: Server settings may restrict the maximum upload file size or post size.
  • Timeouts: Slow server response or large files can cause timeouts, triggering 500 or 503 errors.
  • Plugin conflicts: Security, caching, or optimization plugins can block or interfere with uploads.
  • Incorrect file permissions: The uploads folder must be writable by the web server user.
  • Server configuration: Misconfigured .htaccess, Nginx rules, or mod_security can block uploads.

Step-by-step Fix per Host

1. Increase PHP Memory and Upload Limits

Add or update the following directives in your php.ini or .user.ini file:

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
max_input_time = 300

If you don’t have access to php.ini, add this to your wp-config.php:

define('WP_MEMORY_LIMIT', '256M');

2. Adjust .htaccess for Apache Hosts

Add these lines to your .htaccess file in the WordPress root directory:

php_value memory_limit 256M
php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300
php_value max_input_time 300

3. Configure Nginx Servers

Add or update these directives in your Nginx server block configuration:

client_max_body_size 64M;
fastcgi_read_timeout 300;

Then reload Nginx:

sudo systemctl reload nginx

4. Fix File Permissions

Set correct permissions for the uploads folder:

cd /path/to/wordpress/wp-content
chmod 755 uploads
chown -R www-data:www-data uploads

Replace www-data with your web server user if different.

5. Disable Conflicting Plugins

Temporarily deactivate all plugins:

wp plugin deactivate --all

Try uploading an image again. If it works, reactivate plugins one by one to identify the culprit.

6. Switch WordPress Editor

If you are using the Gutenberg block editor, install and activate the Classic Editor plugin:

wp plugin install classic-editor --activate

Try uploading again. Sometimes the editor can cause upload issues.

Works on

Web Server Control Panel Notes
Apache cPanel, Plesk, DirectAdmin Use .htaccess to set PHP limits
Nginx cPanel, Plesk, Custom VPS Adjust Nginx config and reload service
LiteSpeed cPanel, DirectAdmin Supports Apache directives in .htaccess

FAQ

Q: Why do I get a generic “HTTP error” when uploading images?
A: This is often caused by server resource limits, plugin conflicts, or file permission issues. Follow the quick fixes to isolate the problem.
Q: How do I check my current PHP memory limit?
A: Create a phpinfo.php file with <?php phpinfo(); ?> and access it via browser. Look for memory_limit.
Q: Can large image dimensions cause upload errors?
A: Yes, very large images require more memory and processing time. Resize images before uploading or increase server limits.
Q: Is switching editors a permanent fix?
A: Switching editors is a troubleshooting step. It can help identify if the block editor is causing issues but is not always a permanent solution.
Q: What if none of these fixes work?
A: Contact your hosting provider to check server logs and confirm no server-level restrictions or firewall rules block uploads.
…
Fixes & Errors

Posts pagination

Previous 1 2

Recent Posts

  • Top WordPress Themes for Blogs in 2025
  • WordPress Admin Panel Trick: Adding ID Field to the Posts Listing
  • Solution previous_posts_link and next_posts_link Not Working
  • Show Top Commentators in WordPress Without a Plugin
  • How to Style Admin Comments in WordPress

Recent Comments

    Archives

    • August 2025

    Categories

    • Admin & Blocks
    • Admin & UI
    • Automation
    • Automation & Plugins
    • Comments
    • Comparisons
    • Database & Revisions
    • Developer Snippets
    • Fixes & Errors
    • Media & Thumbnails
    • Queries & Pagination
    • Security
    • Speed & Security
    • Tips & Tricks
    • WooCommerce How‑tos
    • WordPress Snippets
    • WordPress Themes
    • Terms & Conditions
    • Affiliate Disclosure

    Copyright © 2025 wpcanyon.com.

    Powered by PressBook WordPress theme