Tag: .htaccess

Increase upload_max_filesize (Uploaded file exceeds the upload_max_filesize directive)

Posted on By Admin No Comments on Increase upload_max_filesize (Uploaded file exceeds the upload_max_filesize directive)

Increase upload_max_filesize (Uploaded file exceeds the upload_max_filesize directive)

If you encounter the error “Uploaded file exceeds the upload_max_filesize directive” in WordPress, it means your server’s PHP configuration limits the maximum file size you can upload. This often blocks you from uploading large media files or plugins. The quick fix is to increase the upload_max_filesize value in your PHP settings.

Quick Fix

  1. Edit your php.ini file (or create one if it doesn’t exist) and add or update this line: 
    upload_max_filesize = 64M
  2. Also increase post_max_size to the same or larger value: 
    post_max_size = 64M
  3. Restart your web server (Apache, Nginx, LiteSpeed) to apply changes.
  4. Verify the new limits in WordPress by going to Media > Add New or using a PHP info plugin.

Why this happens

PHP has built-in limits on file upload sizes to prevent server overload and abuse. The upload_max_filesize directive controls the maximum size of an uploaded file, while post_max_size controls the maximum size of POST data allowed. If your file exceeds these limits, PHP rejects the upload and WordPress shows the error.

By default, many hosting providers set these values low (e.g., 2MB or 8MB) to conserve resources. To upload larger files, you must increase these limits manually.

Step-by-step

1. For Apache or LiteSpeed servers

  1. Locate your php.ini file. Common locations:
    • /etc/php/7.x/apache2/php.ini
    • /usr/local/lib/php.ini
    • Use phpinfo() to find the loaded config file.
  2. Edit the php.ini file and update or add: 
    upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 128M
max_execution_time = 300
max_input_time = 300
  3. Save the file and restart Apache or LiteSpeed: 
    sudo systemctl restart apache2
# or for LiteSpeed
sudo systemctl restart lsws
  4. Check changes with a PHP info file or WordPress media uploader.

2. For Nginx servers

  1. Edit your PHP-FPM php.ini file (location similar to Apache).
  2. Update the same directives as above: 
    upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 128M
max_execution_time = 300
max_input_time = 300
  3. Edit your Nginx site configuration file (e.g., /etc/nginx/sites-available/example.com) and add or update: 
    client_max_body_size 64M;
  4. Restart PHP-FPM and Nginx: 
    sudo systemctl restart php7.x-fpm
sudo systemctl restart nginx
  5. Verify upload limits in WordPress.

3. Using cPanel

  1. Log in to your cPanel dashboard.
  2. Go to MultiPHP INI Editor under the Software section.
  3. Select your domain from the dropdown.
  4. Set upload_max_filesize and post_max_size to your desired values (e.g., 64M).
  5. Save the changes.
  6. Check your WordPress upload limits.

4. Using Plesk

  1. Log in to Plesk.
  2. Go to Domains > example.com > PHP Settings.
  3. Find upload_max_filesize and post_max_size and increase their values.
  4. Save the settings.
  5. Test upload limits in WordPress.

Works on

Server Control Panel Notes
Apache cPanel, Plesk, Manual Requires php.ini edit and server restart
Nginx cPanel, Plesk, Manual Requires php.ini and nginx.conf edits + restarts
LiteSpeed cPanel, Manual Similar to Apache, restart LiteSpeed after changes

FAQ

  1. Q: I increased upload_max_filesize but still get the error. Why?

    A: You must also increase post_max_size and ensure your web server (Nginx or Apache) allows larger uploads (e.g., client_max_body_size in Nginx). Restart your server after changes.

  2. Q: Can I increase upload limits via .htaccess?

    A: Only on Apache servers with PHP running as an Apache module. Add these lines to your .htaccess:

    php_value upload_max_filesize 64M
php_value post_max_size 64M
  3. Q: How do I check current upload limits?

    A: Use a PHP info plugin in WordPress or create a phpinfo.php file with:

    <?php phpinfo(); ?>

    Then open it in your browser and look for upload_max_filesize

…
Fixes & Errors

Block bad bots with .htaccess (copy/paste rules)

Posted on By Admin No Comments on Block bad bots with .htaccess (copy/paste rules)

Block Bad Bots with .htaccess (Copy/Paste Rules)

If your WordPress site is suffering from unwanted traffic caused by bad bots—scraping content, spamming forms, or consuming server resources—you can block them efficiently using .htaccess rules. This tutorial provides quick, copy-paste-ready .htaccess snippets to block common bad bots and protect your site.

Quick Fix: Block Bad Bots in .htaccess

  1. Access your WordPress site’s root directory via FTP or hosting file manager.
  2. Open or create the .htaccess file in the root folder.
  3. Copy and paste the provided bad bot blocking rules into the .htaccess file.
  4. Save the file and test your site to ensure it works correctly.

Why This Happens

Bad bots are automated scripts that crawl websites for malicious purposes such as scraping content, spamming, brute forcing login pages, or overloading servers. Unlike good bots (like Googlebot), bad bots ignore robots.txt rules and can cause:

  • High server load and slow site performance
  • Security vulnerabilities through brute force or injection attacks
  • Content theft and SEO penalties

Blocking these bots at the server level using .htaccess is an effective way to reduce unwanted traffic before it reaches WordPress.

Requirements

  • Apache web server with mod_rewrite enabled
  • Access to your site’s root .htaccess file
  • Basic knowledge of FTP or hosting file manager
  • Backup of your current .htaccess file before editing

Step-by-step: Block Bad Bots with .htaccess

  1. Backup your current .htaccess file. Always keep a copy before making changes.
  2. Access your site’s root directory. Use FTP or your hosting control panel’s file manager.
  3. Open the .htaccess file. If it doesn’t exist, create a new plain text file named .htaccess.
  4. Paste the following code at the top of the file, before WordPress rules:
# BEGIN Block Bad Bots
<IfModule mod_rewrite.c>
RewriteEngine On

# Block bad bots by User-Agent
RewriteCond %{HTTP_USER_AGENT} ^.*(AhrefsBot|SemrushBot|MJ12bot|BLEXBot|DotBot|Screaming Frog|YandexBot|Exabot|Ezooms|Sogou).* [NC]
RewriteRule .* - [F,L]

# Block bad bots by Referer (optional)
# RewriteCond %{HTTP_REFERER} ^.*(spamdomain1.com|spamdomain2.net).* [NC]
# RewriteRule .* - [F,L]

</IfModule>
# END Block Bad Bots
  1. Save the file. Upload it back if using FTP.
  2. Test your site. Visit your site to ensure it loads correctly.
  3. Verify blocking. Use online tools or curl commands to simulate bad bot User-Agents and confirm they receive a 403 Forbidden response.

Common Pitfalls

  • Placing rules after WordPress block: Always add bad bot rules before the WordPress section in .htaccess to ensure they take effect.
  • Typos in User-Agent names: User-Agent strings are case-insensitive but must be spelled correctly to match.
  • Blocking legitimate bots: Avoid blocking well-known good bots like Googlebot or Bingbot to prevent SEO issues.
  • Server without mod_rewrite: These rules require Apache’s mod_rewrite module; they won’t work on Nginx or if mod_rewrite is disabled.
  • Overblocking: Be cautious with broad patterns to avoid blocking real users or services.

Works on

Server Compatibility
Apache Fully compatible with mod_rewrite enabled
Nginx Not compatible (requires different config)
LiteSpeed Compatible (supports Apache .htaccess rules)
cPanel / Plesk Compatible (access .htaccess via file manager or FTP)

FAQ

Q1: How do I find out which bots are bad?
A: You can check your server logs or use analytics tools to identify suspicious User-Agent strings. Common bad bots include AhrefsBot, SemrushBot, MJ12bot, and others known for scraping or spamming.
Q2: Can I block bad bots using plugins instead of .htaccess?
A: Yes, there are WordPress plugins that block bad bots, but .htaccess blocking is faster and reduces server load by stopping requests early.
Q3: What if I accidentally block a good bot?
A: Remove or adjust the User-Agent pattern from the .htaccess file and test again. Always verify User-Agent strings before blocking.
Q4: Will blocking bad bots improve my SEO?
A: Indirectly yes. Blocking bad bots reduces server load and prevents content scraping, which can protect your SEO rankings.
Q5: Can I block bots by IP instead of User-Agent?
A: Yes, but IP addresses can change frequently. Blocking by User-Agent is more flexible for bad bots that identify themselves.
…
Speed & Security

Serve WebP in WordPress (with safe JPEG/PNG fallbacks)

Posted on By Admin No Comments on Serve WebP in WordPress (with safe JPEG/PNG fallbacks)

Serve WebP in WordPress (with safe JPEG/PNG fallbacks)

Serving WebP images in WordPress improves site speed and reduces bandwidth by delivering smaller, optimized images. However, not all browsers support WebP, so it’s essential to provide safe JPEG/PNG fallbacks. This tutorial shows you how to configure your WordPress site to serve WebP images with fallback support using .htaccess rules.

Quick Fix: Serve WebP with JPEG/PNG Fallbacks via .htaccess

  1. Generate WebP versions of your images (using a plugin or external tool).
  2. Upload WebP images alongside original JPEG/PNG files in your WordPress uploads folder.
  3. Add the provided .htaccess code snippet to your WordPress root directory.
  4. Test your site in different browsers to confirm WebP images load where supported, and JPEG/PNG fallback loads otherwise.

Why This Happens

WebP is a modern image format offering superior compression compared to JPEG and PNG, resulting in faster page loads. However, older browsers or some niche browsers do not support WebP. Without fallback images, unsupported browsers will fail to display images, breaking your site’s appearance.

WordPress by default does not serve WebP images automatically or provide fallbacks. You must configure your server to detect browser support and serve the appropriate image format. Using .htaccess rewrite rules on Apache servers is a common and efficient method to achieve this without changing your theme or plugins.

Requirements

  • Apache web server with mod_rewrite enabled.
  • Access to your WordPress root directory to edit or add a .htaccess file.
  • WebP versions of your images stored alongside original JPEG/PNG files.
  • Basic familiarity with FTP or file manager to upload files and edit .htaccess.

Step-by-step: Serve WebP with JPEG/PNG Fallbacks in WordPress

  1. Create WebP images: Use a plugin like Imagify, EWWW Image Optimizer, or an external tool to generate WebP versions of your JPEG/PNG images. Ensure WebP files are saved in the same folder as the originals.
  2. Backup your current .htaccess file: Before making changes, download a copy of your existing .htaccess file from your WordPress root directory.
  3. Edit your .htaccess file: Add the following code snippet near the top of your .htaccess file, before the WordPress rules block:
# Serve WebP images with JPEG/PNG fallback
<IfModule mod_rewrite.c>
  RewriteEngine On

  # Check if browser supports WebP
  RewriteCond %{HTTP_ACCEPT} image/webp

  # Check if WebP version of the requested image exists
  RewriteCond %{REQUEST_FILENAME}.webp -f

  # Serve WebP image instead
  RewriteRule ^(wp-content/.+.(jpe?g|png))$ $1.webp [T=image/webp,E=accept:1]
</IfModule>

# Add correct content type for WebP images
<IfModule mod_headers.c>
  <FilesMatch ".webp$">
    Header set Content-Type "image/webp"
  </FilesMatch>
</IfModule>

# Ensure WebP images are served with proper caching
<IfModule mod_expires.c>
  ExpiresByType image/webp "access plus 1 month"
</IfModule>
  1. Save and upload the updated .htaccess file.
  2. Clear your site and browser cache.
  3. Test your site: Open your website in a WebP-supporting browser (Chrome, Firefox, Edge) and verify images are served as WebP (use browser developer tools → Network tab → check image content-type). Then test in a non-WebP browser (Safari older versions, IE) to confirm JPEG/PNG images load instead.

Common Pitfalls

  • WebP files missing: The rewrite rule only works if the WebP version exists. Make sure WebP images are generated and uploaded correctly.
  • mod_rewrite not enabled: The rules require Apache’s mod_rewrite module. Confirm it is enabled on your server.
  • Incorrect .htaccess placement: The .htaccess file must be in your WordPress root directory (where wp-config.php is located).
  • Conflicts with other plugins: Some caching or image optimization plugins may conflict with manual .htaccess rules. Test carefully and disable conflicting plugins if needed.
  • Browser caching: Old cached images may prevent you from seeing changes immediately. Clear cache or test in incognito mode.

Works on

Server Compatibility
Apache Fully supported (with mod_rewrite enabled)
Nginx Not applicable (use Nginx config instead)
LiteSpeed Compatible with Apache .htaccess rules
cPanel / Plesk Supported (edit .htaccess via file manager or FTP)

FAQ

Q: How do I generate WebP images for my existing WordPress media library?
A: Use plugins like Imagify or EWWW Image Optimizer that automatically convert and save WebP versions of your images in the uploads folder.
Q: Will this method slow down my website?
A: No. The rewrite rules are efficient and only redirect requests if a WebP version exists and the browser supports it, improving load times by serving smaller images.
Q: What if my server uses
…
Speed & Security

Block bad bots in .htaccess (copy/paste)

Posted on By Admin No Comments on Block bad bots in .htaccess (copy/paste)

Block Bad Bots in .htaccess (Copy/Paste)

If your WordPress site is suffering from unwanted traffic caused by bad bots—such as scrapers, spammers, or malicious crawlers—you can block them efficiently using your .htaccess file. This quick fix not only denies access to known bad bots but also rate limits requests to reduce server load and improve site security.

Quick Fix: Deny Bad Bots & Rate Limit in .htaccess

  1. Open your WordPress root directory and locate the .htaccess file.
  2. Backup the .htaccess file before making changes.
  3. Copy and paste the following code at the top of your .htaccess file:
# Block Bad Bots by User-Agent
SetEnvIfNoCase User-Agent "AhrefsBot" bad_bot
SetEnvIfNoCase User-Agent "SemrushBot" bad_bot
SetEnvIfNoCase User-Agent "MJ12bot" bad_bot
SetEnvIfNoCase User-Agent "DotBot" bad_bot
SetEnvIfNoCase User-Agent "BLEXBot" bad_bot
SetEnvIfNoCase User-Agent "YandexBot" bad_bot

Order Allow,Deny
Allow from all
Deny from env=bad_bot

# Rate limiting: Limit excessive requests per IP

  SetEnvIf Remote_Addr "^.*$" RATE_LIMIT
  
    SetOutputFilter RATE_LIMIT
    SetEnv rate-limit 400
  


# Alternative rate limiting using mod_reqtimeout (Apache 2.2.15+)

  RequestReadTimeout header=20-40,minrate=500
  1. Save the file and upload it back to your server if editing locally.
  2. Test your site to ensure it loads correctly and bad bots are blocked.

Why This Happens

Bad bots can cause multiple issues for WordPress sites:

  • Server overload: Excessive requests from bots can consume bandwidth and CPU, slowing down your site.
  • Security risks: Some bots scan for vulnerabilities or attempt brute force attacks.
  • SEO damage: Scrapers can steal your content, harming your search engine rankings.

Blocking bad bots at the .htaccess level prevents them from reaching your WordPress application, reducing resource usage and improving overall site performance and security.

Step-by-Step: How to Block Bad Bots in .htaccess

  1. Access your WordPress root directory: Use FTP, SFTP, or your hosting control panel’s file manager to navigate to the folder where WordPress is installed. This folder contains the wp-config.php and .htaccess files.
  2. Backup your current .htaccess file: Before making any changes, download a copy of your existing .htaccess file to your local machine. This ensures you can restore it if something goes wrong.
  3. Edit the .htaccess file: Open the .htaccess file in a plain text editor.
  4. Add bad bot blocking rules: Insert the following code at the very top of the file, before any WordPress rules:
# Block Bad Bots by User-Agent
SetEnvIfNoCase User-Agent "AhrefsBot" bad_bot
SetEnvIfNoCase User-Agent "SemrushBot" bad_bot
SetEnvIfNoCase User-Agent "MJ12bot" bad_bot
SetEnvIfNoCase User-Agent "DotBot" bad_bot
SetEnvIfNoCase User-Agent "BLEXBot" bad_bot
SetEnvIfNoCase User-Agent "YandexBot" bad_bot

Order Allow,Deny
Allow from all
Deny from env=bad_bot

This code uses SetEnvIfNoCase to detect bad bots by their user-agent strings and denies them access.

  1. Add rate limiting rules: To prevent excessive requests from any IP address, add the following code below the bot blocking rules:
# Rate limiting: Limit excessive requests per IP

  SetEnvIf Remote_Addr "^.*$" RATE_LIMIT
  
    SetOutputFilter RATE_LIMIT
    SetEnv rate-limit 400
  


# Alternative rate limiting using mod_reqtimeout (Apache 2.2.15+)

  RequestReadTimeout header=20-40,minrate=500

This limits the bandwidth and request rate to protect your server from overload.

  1. Save and upload the file: If editing locally, upload the modified .htaccess file back to your server, overwriting the existing one.
  2. Test your website: Visit your site in a browser to ensure it loads normally. Use online tools or command line to simulate bad bot user-agents and confirm they are blocked.

Testing Your Bad Bot Blocking

  • Browser test: Your site should load normally for regular browsers.
  • Command line test: Use curl to simulate a bad bot user-agent:
curl -A "AhrefsBot" -I https://yourdomain.com/

The response should be 403 Forbidden or similar, indicating the bot is blocked.

  • Check server logs: Review your Apache error or access logs to verify that requests from bad bots are denied.

Works On

Server Software Notes
Apache Fully supported; requires mod_setenvif, mod_authz_host, and optionally mod_ratelimit or mod_reqtimeout
Nginx Does not use .htaccess; configure in server block instead
LiteSpeed Supports .htaccess rules similar to Apache
cPanel / Ples
…
Speed & Security