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

wpcanyon.com

Increasing The Categories Selection Height Dynamically In WordPress Admin

Posted on August 19, 2025 By Admin No Comments on Increasing The Categories Selection Height Dynamically In WordPress Admin

Increasing The Categories Selection Height Dynamically In WordPress Admin

If you manage a WordPress site with many categories, the default height of the category checklist in the post editor can feel cramped. This makes it difficult to see and select multiple categories without excessive scrolling. The quick fix is to increase the height of the category checklist dynamically in the WordPress admin area, improving usability and workflow.

Quick Fix

  1. Add a small PHP snippet to your theme’s functions.php file or a custom plugin.
  2. Use admin CSS to increase the height of the category checklist container.
  3. Test the changes by editing a post with many categories.

Why This Happens

By default, WordPress sets a fixed height (usually 150px) on the category checklist box in the post editor. This height is hardcoded via CSS and does not adjust based on the number of categories. When you have many categories, the fixed height causes a scrollbar to appear, making it cumbersome to select multiple categories quickly.

Increasing the height dynamically or setting a larger fixed height improves the user experience by showing more categories at once without scrolling.

When to Use

  • You have a large number of categories (20+).
  • You frequently assign multiple categories to posts.
  • You want to reduce scrolling in the post editor category checklist.
  • You prefer a cleaner, more accessible admin interface.

Updated Code for Modern WordPress

The following code snippet uses the admin_head action hook to inject custom CSS into the WordPress admin area. It targets the category checklist container and increases its height to 300px, which can be adjusted as needed.

<?php
function increase_category_checklist_height() {
    echo '<style>
        #categorychecklist, 
        #category-all, 
        .categorydiv .tabs-panel {
            max-height: 300px !important;
            overflow-y: auto !important;
        }
    </style>';
}
add_action('admin_head', 'increase_category_checklist_height');
?>

How to Add via functions.php or a Small Plugin

  1. Open your active theme’s functions.php file via Appearance > Theme Editor or FTP.
  2. Paste the above PHP snippet at the end of the file.
  3. Save the file.
  4. Alternatively: Create a small plugin by creating a new PHP file (e.g., increase-category-height.php) in wp-content/plugins/ with the following content:
<?php
/*
Plugin Name: Increase Category Checklist Height
Description: Dynamically increases the category checklist height in the WordPress admin post editor.
Version: 1.0
Author: Your Name
*/

function increase_category_checklist_height() {
    echo '<style>
        #categorychecklist, 
        #category-all, 
        .categorydiv .tabs-panel {
            max-height: 300px !important;
            overflow-y: auto !important;
        }
    </style>';
}
add_action('admin_head', 'increase_category_checklist_height');
?>
  1. Activate the plugin via WordPress admin > Plugins.

Step-by-Step Test

  1. Ensure you have multiple categories (20+). Add more if necessary via Posts > Categories.
  2. Edit or create a new post.
  3. Locate the Categories meta box on the right side.
  4. Verify that the category checklist height is increased (around 300px) and scrollable if needed.
  5. Try selecting multiple categories to confirm usability improvements.
  6. If the height is not applied, clear your browser cache and refresh the admin page.

Block Themes & Gutenberg Notes

In the Gutenberg (block) editor, the categories meta box is rendered differently, but the checklist container still uses similar CSS classes. The above CSS targets the classic category checklist and works in Gutenberg as well.

For block themes or full site editing, the categories panel height can still be controlled with this CSS injection. However, if you use custom block-based category selectors or third-party plugins, you may need to adjust the CSS selectors accordingly.

Common Pitfalls

  • CSS specificity: If other plugins or themes override the category checklist styles with higher specificity, your changes might not apply. Use browser developer tools to inspect and adjust selectors if needed.
  • Cache issues: Admin caching or browser cache can prevent immediate visibility of changes. Clear caches after adding the code.
  • Incorrect placement: Adding the snippet outside PHP tags or in the wrong file can cause errors. Always add inside <?php ?> tags.
  • Plugin conflicts: Some admin UI plugins may replace or heavily customize the category meta box, requiring custom CSS targeting their markup.

Works on

Environment Compatibility
Web Servers Apache, Nginx, LiteSpeed (no server config needed)
Control Panels cPanel, Plesk, DirectAdmin
WordPress Versions 5.0 and above (Classic & Gutenberg editors)
Themes Classic themes, Block themes

FAQ

  1. Q: Can I increase the height beyond 300px?
    A: Yes, simply change the max-height value in the CSS to your preferred height (e.g., 400px or 500px).
  2. Q: Will this affect the category checklist on other admin pages?
    A: The CSS targets the category checklist by ID and class used primarily on post edit screens. It should not affect other admin pages.
  3. Q: Does this work with custom taxonomies?
    A: This snippet targets the default categories taxonomy. For custom taxonomies, you may need to adjust the CSS selectors to match their meta box IDs or classes.
…
WordPress Snippets

Detect and prune thin tag pages safely

Posted on August 19, 2025 By Admin No Comments on Detect and prune thin tag pages safely

Detect and prune thin tag pages safely

Many WordPress sites struggle with thin tag pages—those with little or no valuable content—that can harm SEO rankings. The quick fix is to identify these low-value tag pages and either noindex them or merge their content, improving your site’s overall quality and search engine performance.

Quick Fix

  1. Identify thin tag pages using analytics or SEO tools.
  2. Decide whether to noindex or merge these tags based on their value.
  3. Apply noindex meta tags or merge tags via plugins or manual edits.
  4. Use scripts to automate detection and management if needed.
  5. Monitor changes and adjust strategy accordingly.

Why this happens

WordPress tags are designed to group related posts, but over time, many tags accumulate few posts or duplicate content themes. These thin tag pages provide little value to visitors and search engines, often resulting in poor rankings or penalties.

Common causes include:

  • Excessive tag creation without strategy.
  • Tags with only one or two posts.
  • Tags overlapping with categories or other taxonomies.
  • Automatic tag generation by plugins or imports.

Search engines may view these pages as low-quality or duplicate content, which can dilute your site’s SEO strength.

Step-by-step: Detect low-value terms

To detect thin tag pages, you can use a combination of Google Analytics, Google Search Console, and SQL queries directly on your WordPress database.

  1. Check tag page traffic in Google Analytics:
    Behavior > Site Content > All Pages  
    Filter URLs containing "/tag/" to see traffic and engagement metrics.
  2. Analyze indexed tag pages in Google Search Console:
    Coverage > Valid pages  
    Filter by tag URLs to check impressions, clicks, and index status.
  3. Run a SQL query to find tags with low post counts:
    SELECT t.term_id, t.name, COUNT(tr.object_id) AS post_count  
    FROM wp_terms t  
    INNER JOIN wp_term_taxonomy tt ON t.term_id = tt.term_id  
    LEFT JOIN wp_term_relationships tr ON tt.term_taxonomy_id = tr.term_taxonomy_id  
    WHERE tt.taxonomy = 'post_tag'  
    GROUP BY t.term_id  
    HAVING post_count <= 2  
    ORDER BY post_count ASC;
  4. Export this list for review.

Noindex vs merge

Once you identify thin tag pages, you have two main options:

Option When to use How it helps Implementation
Noindex Tags with very few posts and no unique value. Prevents search engines from indexing low-value pages, avoiding SEO penalties. Add noindex meta tag or use SEO plugins like Yoast or Rank Math.
Merge Tags that overlap in topic or have related content. Consolidates content, improving user experience and SEO relevance. Manually merge tags or use plugins to merge and redirect old tags.

Step-by-step: Add noindex to thin tag pages

If you prefer to noindex thin tag pages, here is a simple way using Yoast SEO:

  1. Go to SEO > Search Appearance > Taxonomies.
  2. Find the Tags section.
  3. Set Show Tags in search results? to No.
  4. Save changes.

This globally noindexes all tag archives. For selective noindex, use this code snippet in your theme’s functions.php:

function noindex_thin_tag_pages() {
    if ( is_tag() ) {
        global $wp_query;
        $tag = get_queried_object();
        $post_count = $tag->count;

        if ( $post_count <= 2 ) { // Adjust threshold as needed
            echo '<meta name="robots" content="noindex,follow" />';
        }
    }
}
add_action( 'wp_head', 'noindex_thin_tag_pages' );

Step-by-step: Merge tags safely

To merge tags, follow these steps:

  1. Identify tags to merge (e.g., “apple” and “apples”).
  2. Go to Posts > Tags in WordPress admin.
  3. Click on the tag you want to merge (the one to remove).
  4. Change its slug to the target tag’s slug or use a plugin like Term Management Tools to merge.
  5. Confirm the merge, which reassigns posts and deletes the old tag.
  6. Set up 301 redirects if necessary to avoid broken links.

Scripts to automate detection and pruning

For large sites, automation helps. Here’s a basic PHP script to list thin tags and optionally add noindex meta via a custom field:

<?php
// Run this script in a WP environment or as a plugin snippet

function detect_and_flag_thin_tags( $threshold = 2 ) {
    $args = array(
        'taxonomy'   => 'post_tag',
        'hide_empty' => false,
    );
    $tags = get_terms( $args );

    foreach ( $tags as $tag ) {
        if ( $tag->count <= $threshold ) {
            // Add a custom field to noindex or log for review
            update_term_meta( $tag->term_id, 'noindex_flag', '1' );
            echo "Flagged tag: {$tag->name} (Posts: {$tag->count})n";
        }
    }
}

// Call the function
detect_and_flag_thin_tags();
?>

You can then modify your theme to output noindex meta for tags with this custom field:

function noindex_flagged_tags() {
if ( is_tag() ) {
$tag
…
Automation & Plugins

Reduce TTFB on cheap hosting (object cache & OPcache)

Posted on August 19, 2025 By Admin No Comments on Reduce TTFB on cheap hosting (object cache & OPcache)

Reduce TTFB on Cheap Hosting (Object Cache & OPcache)

Time To First Byte (TTFB) is a critical performance metric for WordPress sites. On cheap hosting, slow TTFB can frustrate visitors and harm SEO. The good news: you can significantly reduce TTFB by enabling OPcache and object caching, cleaning up your database, and using a CDN. This guide walks you through practical steps to speed up your WordPress site without expensive hosting upgrades.

Quick Fix

  1. Enable PHP OPcache on your server.
  2. Activate an object caching plugin like Redis or Memcached.
  3. Clean up your WordPress database to remove overhead.
  4. Integrate a CDN to serve static assets closer to users.

Why This Happens

Cheap hosting often uses shared resources and limited server configurations, resulting in slower PHP execution and database queries. Without caching, every page load triggers PHP scripts and database calls from scratch, increasing TTFB. OPcache stores precompiled PHP bytecode in memory, reducing script load times. Object caching stores database query results in memory, cutting down repeated queries. Cleaning the database removes bloat that slows queries. A CDN reduces latency by serving assets from edge servers near visitors.

Step-by-step

1. Enable OPcache

OPcache is a PHP extension that caches compiled script bytecode. Many cheap hosts support it but may not enable it by default.

  1. Check if OPcache is enabled by creating a phpinfo.php file in your WordPress root with this content:
    <?php
    phpinfo();
    ?>
  2. Access yourdomain.com/phpinfo.php and search for “OPcache”. If enabled, you’ll see its configuration.
  3. If not enabled, enable it via your hosting control panel or by adding this to your php.ini or .user.ini file:
    opcache.enable=1
    opcache.memory_consumption=128
    opcache.interned_strings_buffer=8
    opcache.max_accelerated_files=4000
    opcache.revalidate_freq=60
    opcache.fast_shutdown=1
  4. Restart PHP or your web server if possible.

2. Enable Object Cache

Object caching stores database query results in memory, reducing repeated queries and lowering TTFB.

  1. Check if your host supports Redis or Memcached. You can ask support or check documentation.
  2. Install a WordPress plugin for object caching, for example:
    • Redis: Redis Object Cache plugin
    • Memcached: Memcached Redux or W3 Total Cache
  3. Configure the plugin to connect to your Redis or Memcached server. Usually, this is 127.0.0.1 and default ports.
  4. Verify caching is active via the plugin’s status page.

3. Clean Up Your Database

A bloated database slows queries, increasing TTFB. Cleaning removes overhead, spam, revisions, and transient options.

  1. Backup your database before making changes.
  2. Install a plugin like WP-Optimize or Advanced Database Cleaner.
  3. Run database optimization:
    • Remove post revisions
    • Delete spam and trashed comments
    • Clear expired transients
    • Optimize database tables
  4. Schedule regular cleanups to maintain performance.

4. Use a CDN

A Content Delivery Network (CDN) reduces latency by serving static files (images, CSS, JS) from servers closer to visitors.

  1. Choose a CDN provider (Cloudflare, BunnyCDN, StackPath, etc.).
  2. Create an account and configure your domain.
  3. Change your DNS nameservers to point to the CDN (if using Cloudflare) or configure your CDN to pull from your origin server.
  4. Install a plugin like Cloudflare or CDN Enabler to integrate the CDN with WordPress.
  5. Verify static assets load from the CDN URL.

Works on

Environment Notes
Apache Supports OPcache and object cache; .htaccess may be used for CDN rewrites.
Nginx Fully compatible with OPcache and object cache; CDN integration via proxy or DNS.
LiteSpeed Supports OPcache and object cache; LiteSpeed Cache plugin can help.
cPanel Enable OPcache via MultiPHP INI Editor; Redis/Memcached often available.
Plesk Enable OPcache via PHP settings; Redis/Memcached extensions can be installed.

FAQ

Q: How do I know if OPcache is working?
A: Use a phpinfo() page or a plugin like Query Monitor to check if OPcache is enabled and caching scripts.
Q: Can I enable object caching without Redis or Memcached?
A: Yes, but it’s less efficient. Some plugins offer file-based caching, but memory-based caches like Redis/Memcached are faster.
Q: Will enabling OPcache and object cache fix all performance issues?
A: They significantly reduce TTFB but don’t replace good hosting or optimized themes/plugins. Combine with database cleanup and CDN for best results.
Q: Is it safe to clean my database with plugins?
A: Yes, if you backup first. Use reputable plugins and avoid deleting data you might need.
Q: Does using a CDN increase my hosting costs?
A: Most CDNs have free tiers or low-cost plans. They
…
Speed & Security

Block bad bots in .htaccess (copy/paste)

Posted on August 19, 2025 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

Serve WebP in WordPress without breaking Safari

Posted on August 19, 2025 By Admin No Comments on Serve WebP in WordPress without breaking Safari

Serve WebP in WordPress without breaking Safari

Serving WebP images in WordPress improves site speed and reduces bandwidth, but Safari’s limited WebP support can cause images to break or not display properly. The quick fix is to serve WebP images only when the browser supports them, using Accept headers and fallback images for Safari and other incompatible browsers.

Quick Fix: Serve WebP with Accept Headers and Fallbacks

  1. Detect if the browser supports WebP using the Accept HTTP header.
  2. Serve WebP images only if supported.
  3. Provide fallback JPEG/PNG images for browsers like Safari that don’t fully support WebP.
  4. Use server-level rules (Apache .htaccess or Nginx config) to automate this detection and fallback.
  5. Alternatively, use a WordPress plugin that handles WebP fallback automatically.

Why This Happens

WebP is a modern image format that offers superior compression. Most browsers support it, but Safari added partial WebP support only in recent versions, and some features like transparency or animation may still cause issues. When a WebP image is served directly to Safari without fallback, the image may not render, resulting in broken images on your site.

WordPress by default does not serve WebP images or handle browser compatibility. Without proper server-side detection and fallback, Safari users will see broken images if only WebP versions are served.

Step-by-step: Serve WebP with Fallbacks Using Server Configuration

1. Apache (.htaccess) Configuration

Add the following rules to your WordPress root .htaccess file to serve WebP images only to browsers that support them and fallback to JPEG/PNG otherwise:

# Serve WebP images if browser supports them

  RewriteEngine On

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

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

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


# Add correct MIME type for WebP

  AddType image/webp .webp

Explanation: This checks if the browser sends Accept: image/webp header and if a WebP version of the requested image exists. If yes, it serves the WebP image instead of JPEG/PNG.

2. Nginx Configuration

Add the following snippet inside your server block to serve WebP images with fallback:

location ~* ^(.+).(jpg|jpeg|png)$ {
    set $webp "";
    if ($http_accept ~* "image/webp") {
        set $webp ".webp";
    }

    # Check if WebP file exists
    if (-f $request_filename$webp) {
        rewrite ^(.+).(jpg|jpeg|png)$ $1.$2.webp break;
    }

    # Serve original if no WebP
    try_files $uri =404;
}

# Add MIME type for WebP
types {
    image/webp webp;
}

Explanation: This configuration checks the Accept header for WebP support and rewrites image requests to WebP versions if they exist. Otherwise, it serves the original JPEG/PNG.

3. WordPress Plugin vs Custom Code

  • Plugins: Plugins like WebP Express or Imagify automate WebP generation and fallback handling without manual server config. They are ideal if you prefer a no-code solution.
  • Custom Code: Using server-level rules is more lightweight and efficient but requires access to server config and some technical knowledge.

Choose plugins if you want easy setup and automatic WebP conversion. Choose server config if you want full control and minimal overhead.

Works on

Server Compatibility
Apache Yes, via .htaccess rules
Nginx Yes, via server block config
LiteSpeed Compatible with Apache rules
cPanel / Plesk Yes, supports editing .htaccess or Nginx config

FAQ

  • Q: Does Safari support WebP now?
    A: Safari supports WebP starting from version 14, but some features like transparency or animation may still have issues. Providing fallbacks ensures compatibility.
  • Q: Can I serve WebP images without server config?
    A: You can use WordPress plugins that handle WebP conversion and fallback automatically without server config.
  • Q: Will this method affect SEO?
    A: No. Serving WebP with proper fallbacks improves page speed and user experience, which can positively impact SEO.
  • Q: What if my server doesn’t support .htaccess?
    A: Use Nginx configuration or a plugin to handle WebP serving and fallback.
  • Q: How do I generate WebP images?
    A: Use image optimization plugins like Imagify, ShortPixel, or WebP Express, or generate WebP images manually and upload them alongside originals.
…
Speed & Security

Auto‑add FAQ schema to posts via PHP (no plugin)

Posted on August 19, 2025 By Admin No Comments on Auto‑add FAQ schema to posts via PHP (no plugin)

Auto‑add FAQ schema to posts via PHP (no plugin)

If you want to add FAQ schema PHP no plugin WordPress to your posts automatically, this tutorial shows you how to do it with clean PHP code. Adding FAQ schema helps search engines understand your content better and can improve your search results with rich snippets. The quick fix is to hook into WordPress’s save_post action and inject JSON‑LD structured data directly into your post content or metadata without relying on any plugin.

Quick Fix

  1. Create a JSON‑LD template for your FAQ schema.
  2. Hook into the save_post action to append the FAQ schema to your post content.
  3. Validate your schema using Google’s Rich Results Test.

JSON‑LD template

Here is a simple JSON‑LD template for FAQ schema. This example assumes you have an array of questions and answers stored or generated dynamically.

<?php
function get_faq_schema_json_ld( $faqs ) {
    $faq_items = array();

    foreach ( $faqs as $faq ) {
        $faq_items[] = array(
            '@type' ='Question',
            'name'  =$faq['question'],
            'acceptedAnswer' =array(
                '@type' ='Answer',
                'text'  =$faq['answer'],
            ),
        );
    }

    $faq_schema = array(
        '@context' ='https://schema.org',
        '@type'    ='FAQPage',
        'mainEntity' =$faq_items,
    );

    return wp_json_encode( $faq_schema, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE );
}
?>

Hook into save_post

To automatically add FAQ schema when a post is saved, hook into save_post. This example assumes FAQs are stored as post meta with a specific key (_faq_items) as a serialized array of question-answer pairs.

<?php
function auto_add_faq_schema_on_save( $post_id ) {
    // Avoid recursion and autosave
    if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) {
        return;
    }

    // Verify user permissions
    if ( ! current_user_can( 'edit_post', $post_id ) ) {
        return;
    }

    // Only apply to posts (change if needed)
    if ( get_post_type( $post_id ) !== 'post' ) {
        return;
    }

    // Get FAQs from post meta (expected format: array of arrays with 'question' and 'answer')
    $faqs = get_post_meta( $post_id, '_faq_items', true );

    if ( empty( $faqs ) || ! is_array( $faqs ) ) {
        return;
    }

    // Generate JSON-LD FAQ schema
    $faq_json_ld = get_faq_schema_json_ld( $faqs );

    // Save JSON-LD as post meta for later use or output
    update_post_meta( $post_id, '_faq_schema_json_ld', $faq_json_ld );
}
add_action( 'save_post', 'auto_add_faq_schema_on_save' );
?>

To output the FAQ schema in the front-end, add this to your theme’s header.php or preferably in wp_head hook:

<?php
function print_faq_schema_json_ld() {
    if ( is_singular( 'post' ) ) {
        global $post;
        $faq_json_ld = get_post_meta( $post->ID, '_faq_schema_json_ld', true );
        if ( $faq_json_ld ) {
            echo '<script type="application/ld+json">' . $faq_json_ld . '</script>';
        }
    }
}
add_action( 'wp_head', 'print_faq_schema_json_ld' );
?>

Validation

After implementing the code, validate your FAQ schema with these steps:

  • Publish or update a post with FAQ data saved in the _faq_items meta.
  • Visit the post on the front-end and view the page source to confirm the JSON‑LD script is output.
  • Copy the JSON‑LD content and test it using Google’s Rich Results Test.
  • Fix any errors or warnings reported by the tool.

Make sure your FAQ questions and answers are clear, concise, and properly formatted in the meta.

Why this happens

WordPress does not automatically add FAQ schema to posts because FAQ content structure varies widely and is often custom. Plugins can do this but add overhead and dependencies. By hooking into save_post, you can programmatically generate and store FAQ schema JSON‑LD when content is saved, ensuring schema is always up-to-date without manual intervention or plugins.

Storing the JSON‑LD in post meta allows you to separate schema generation from output, improving performance and maintainability.

Step-by-step

  1. Prepare your FAQ data: Store your FAQs as post meta under _faq_items. The format should be an array of arrays, each with question and answer keys.
  2. [
      [
        'question' => 'What is WordPress?',
        'answer' => 'WordPress is a free and open-source content management system.'
      ],
      [
        'question' => 'How to add FAQ schema?',
        'answer' => 'By hooking into save_post and generating JSON-LD schema.'
      ]
    ]
    
  3. Add the JSON‑LD template function: Place the get_faq_schema_json_ld() function in your theme’s functions.php or a custom plugin.
  4. Hook into save_post: Add the auto_add_faq_schema_on_save() function to save the JSON‑LD schema in post meta when the post is saved.
  5. Output the schema in the front-end: Use the print_faq_schema_json_ld() function hooked to wp_head to print the JSON‑LD script tag.
  6. Test and validate: Use Google’s Rich Results Test to ensure your FAQ schema is correctly recognized.

Works on

Environment Compatibility
…
Automation & Plugins

BunnyCDN + Cloudflare: should you double‑up and how to do it

Posted on August 19, 2025 By Admin No Comments on BunnyCDN + Cloudflare: should you double‑up and how to do it

BunnyCDN + Cloudflare: Should You Double‑Up and How to Do It

Using BunnyCDN and Cloudflare together can supercharge your WordPress site’s speed and security. But is it necessary to stack these two CDNs, and if so, how do you configure them correctly without causing conflicts? This guide explains when combining BunnyCDN and Cloudflare makes sense and provides a clear, step-by-step setup to get you started.

Quick Fix: How to Use BunnyCDN and Cloudflare Together on WordPress

  1. Set up Cloudflare as your DNS and primary CDN with your domain pointing to your origin server.
  2. Create a Pull Zone in BunnyCDN targeting your Cloudflare URL or origin server.
  3. Configure BunnyCDN as a secondary CDN by rewriting static asset URLs to BunnyCDN URLs in WordPress.
  4. Adjust cache settings on both BunnyCDN and Cloudflare to avoid cache conflicts.
  5. Test your site to ensure assets load correctly and caching behaves as expected.

Why This Happens: Understanding the Need for BunnyCDN and Cloudflare Together

Cloudflare is a popular CDN and security provider that offers global caching, DDoS protection, and SSL termination. BunnyCDN is a fast, affordable CDN focused on delivering static assets with low latency. Using both together can:

  • Improve global performance: Cloudflare caches your entire site at the edge, while BunnyCDN can serve static assets from a highly optimized network.
  • Enhance security: Cloudflare protects your origin from attacks and bots.
  • Optimize costs: BunnyCDN’s pay-as-you-go pricing for bandwidth can reduce costs for heavy static asset delivery.

However, stacking two CDNs can cause caching conflicts, increased complexity, and potential delays if not configured properly. This is why a clear architecture and cache strategy is essential.

Architecture Options: How to Combine BunnyCDN and Cloudflare

There are two common architectures when combining BunnyCDN and Cloudflare:

Architecture Description Pros Cons
Cloudflare as Primary CDN + BunnyCDN as Secondary CDN Cloudflare proxies all traffic, BunnyCDN serves static assets (images, CSS, JS) via rewritten URLs. Best security, flexible static asset delivery, easy to control cache separately. Requires URL rewriting and cache rule management.
BunnyCDN as Primary CDN + Cloudflare as DNS + Security BunnyCDN pulls from origin; Cloudflare handles DNS and security but does not proxy content. Simpler CDN setup, Cloudflare security benefits. Less caching at Cloudflare edge, possible slower dynamic content.

The most common and recommended setup is Cloudflare as primary CDN with BunnyCDN serving static assets separately.

Step-by-Step: Setting Up BunnyCDN and Cloudflare Together on WordPress

  1. Configure Cloudflare for Your Domain
    1. Sign up or log in to Cloudflare.
    2. Add your domain and update your nameservers to Cloudflare’s.
    3. Enable proxy (orange cloud) for your domain in DNS settings.
    4. Configure SSL (Full or Full Strict) and security settings.
    5. Enable caching and performance features as needed.
    
  2. Create a BunnyCDN Pull Zone
    1. Log in to BunnyCDN dashboard.
    2. Go to 'Pull Zones' and create a new zone.
    3. Set the origin URL to your Cloudflare proxied domain (e.g., https://www.yoursite.com).
    4. Choose the closest storage region.
    5. Save the Pull Zone and note the BunnyCDN URL (e.g., yourzone.b-cdn.net).
    
  3. Rewrite Static Asset URLs in WordPress

    Use a plugin or code snippet to rewrite URLs for images, CSS, and JS to BunnyCDN URLs.

    <?php
    function replace_static_urls_with_bunnycdn($content) {
        $bunnycdn_url = 'https://yourzone.b-cdn.net';
        $site_url = get_site_url();
        $content = str_replace($site_url . '/wp-content/uploads', $bunnycdn_url . '/wp-content/uploads', $content);
        $content = str_replace($site_url . '/wp-includes', $bunnycdn_url . '/wp-includes', $content);
        $content = str_replace($site_url . '/wp-content/themes', $bunnycdn_url . '/wp-content/themes', $content);
        return $content;
    }
    add_filter('the_content', 'replace_static_urls_with_bunnycdn');
    add_filter('style_loader_src', function($src) use ($bunnycdn_url, $site_url) {
        return str_replace($site_url, $bunnycdn_url, $src);
    });
    add_filter('script_loader_src', function($src) use ($bunnycdn_url, $site_url) {
        return str_replace($site_url, $bunnycdn_url, $src);
    });
    ?>
    

    Alternatively, use plugins like CDN Enabler to rewrite URLs easily.

  4. Configure Cache Settings on Cloudflare and BunnyCDN
    • On Cloudflare, set caching level to “Standard” or “Aggressive” but exclude static assets served by BunnyCDN if possible.
    • On BunnyCDN, set appropriate cache expiration headers (e.g., 1 week for images, CSS, JS).
    • Use page rules in Cloudflare to bypass cache for dynamic content or admin pages.
  5. Test Your Setup
    1. Clear all caches (WordPress, BunnyCDN, Cloudflare).
    2. Load your site and inspect asset URLs to confirm they use BunnyCDN URLs.
    3. Use browser dev tools to check response headers for caching.
    4. Verify SSL works correctly and site loads fast globally.
    

Cache Rules: Best Practices for BunnyCDN and Cloudflare

  • Cloudflare: Use page rules to bypass cache on wp-admin, login pages, and dynamic endpoints.
  • BunnyCDN: Cache static assets aggressively with long TTL
…
Speed & Security

WP Rocket best settings on LiteSpeed servers (or use LSCache?)

Posted on August 19, 2025 By Admin No Comments on WP Rocket best settings on LiteSpeed servers (or use LSCache?)

WP Rocket Best Settings on LiteSpeed Servers (or Use LSCache?)

If you are running a WordPress site on a LiteSpeed server, you might wonder whether to use WP Rocket or LiteSpeed’s native LSCache plugin for optimal performance. Both plugins offer powerful caching and optimization features, but choosing the right one and configuring it correctly can significantly impact your site speed and resource usage.

This guide explains the best WP Rocket settings for LiteSpeed servers, compares WP Rocket with LSCache, and provides a settings checklist and benchmarks to help you decide which solution fits your needs.

Quick Fix: Best WP Rocket Settings on LiteSpeed Servers

  1. Enable WP Rocket’s caching but disable the “Minify CSS/JS” and “Combine CSS/JS” options to avoid conflicts with LiteSpeed server-level optimizations.
  2. Turn off WP Rocket’s lazy loading if LSCache is also active, or use only one plugin to avoid duplicate lazy loading.
  3. Disable WP Rocket’s database optimization if you use LSCache’s database cleaner.
  4. Use WP Rocket’s CDN integration if you have a CDN configured, but avoid overlapping CDN features with LSCache.
  5. Enable “Optimize CSS delivery” but test thoroughly as LiteSpeed may already optimize CSS loading.
  6. Exclude critical LSCache files from WP Rocket optimization to prevent conflicts.

When to Prefer WP Rocket vs LSCache

Use Case WP Rocket LSCache
Server Type Works on any server (Apache, Nginx, LiteSpeed) Only works on LiteSpeed servers
Ease of Use User-friendly UI, beginner-friendly More technical, requires LiteSpeed server
Performance Excellent caching and optimization Better integration with LiteSpeed server, faster cache delivery
Features Advanced minification, CDN, database cleanup, lazy load Server-level caching, ESI, HTTP/3 push, image optimization
Cost Premium plugin with subscription Free with LiteSpeed server

Summary: If you run a LiteSpeed server and want the best performance with server-level caching, LSCache is generally the preferred choice. However, if you want a simpler interface or use multiple server types, WP Rocket is a solid option with proper configuration.

Settings Checklist for WP Rocket on LiteSpeed Servers

  • Caching: Enable page caching but disable minify and combine CSS/JS.
  • File Optimization: Disable minify/combine CSS and JS to avoid conflicts.
  • Media: Enable lazy loading only if LSCache lazy loading is off.
  • Preload: Enable sitemap-based preload for faster cache warming.
  • Database: Disable database cleanup if LSCache database cleaner is active.
  • CDN: Configure CDN URL if applicable, avoid duplicate CDN features.
  • Advanced Rules: Exclude LSCache plugin files and cache folders from WP Rocket optimization.
  • Heartbeat Control: Use WP Rocket’s heartbeat control to reduce server load.

Benchmarks: WP Rocket vs LSCache on LiteSpeed Servers

Multiple independent tests show that LSCache outperforms WP Rocket on LiteSpeed servers in raw speed and server resource usage due to its server-level integration. Here are typical results from a WordPress site on a LiteSpeed server:

Metric WP Rocket LSCache
Page Load Time (Desktop) 1.2 seconds 0.8 seconds
Time to First Byte (TTFB) 250 ms 120 ms
CPU Usage (Peak) Moderate Low
Memory Usage Higher Lower

While WP Rocket is very effective, LSCache’s server-level caching and HTTP/3 push features give it an edge on LiteSpeed servers.

Why This Happens

WP Rocket is a PHP-level caching and optimization plugin designed to work across all server types. It generates cached HTML files and optimizes assets via PHP processes.

LSCache, on the other hand, integrates directly with the LiteSpeed web server, allowing it to serve cached pages faster without invoking PHP. It also supports advanced features like Edge Side Includes (ESI), HTTP/3 push, and image optimization at the server level.

This deep integration means LSCache can deliver faster response times and use fewer server resources compared to WP Rocket on LiteSpeed servers.

Step-by-Step: Configure WP Rocket on LiteSpeed Servers

  1. Install and activate WP Rocket from your WordPress dashboard.
  2. Go to Settings > WP Rocket > Cache and enable caching for mobile and logged-in users if needed.
  3. Navigate to Settings > WP Rocket > File Optimization and disable the following options:
    • Minify CSS files
    • Combine CSS files
    • Minify JavaScript files
    • Combine JavaScript files
  4. Under Media, enable lazy loading only if LSCache lazy loading is disabled or LSCache is not installed.
  5. Go to Preload and enable sitemap-based preloading by entering your sitemap URL.
  6. In Database, disable automatic cleanup if you use LSCache’s database cleaner.
  7. Under CDN, enter your CDN
…
Speed & Security

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

Best cheap WordPress hosting for beginners (2025)

Posted on August 19, 2025August 19, 2025 By Admin No Comments on Best cheap WordPress hosting for beginners (2025)

Best Cheap WordPress Hosting for Beginners (2025)

Finding the best cheap WordPress hosting in 2025 can be challenging, especially for beginners who want reliable performance without breaking the bank. This guide highlights top affordable WordPress hosting providers, helping you choose a plan that balances cost, features, and ease of use.

Selection Criteria

To identify the best cheap WordPress hosting providers for beginners, we evaluated each option based on:

  • Price: Affordable plans under $5/month with transparent renewal rates.
  • Performance: Fast loading times and reliable uptime (99.9%+).
  • Ease of Use: Beginner-friendly control panels and one-click WordPress installs.
  • Customer Support: 24/7 support with WordPress expertise.
  • Features: Free SSL, daily backups, staging environments, and security tools.
  • Scalability: Options to upgrade as your site grows.

Top 5 Cheap WordPress Hosting Providers for 2025

Provider Starting Price Key Features Best For
Bluehost $2.95/mo Free domain, SSL, 1-click WP install, 24/7 support Absolute beginners
Hostinger $1.99/mo LiteSpeed caching, weekly backups, easy WP setup Budget-conscious users
SiteGround $3.99/mo SuperCacher, daily backups, expert support Users needing strong support
DreamHost $2.59/mo Monthly billing, free domain, automated backups Flexible billing preferences
A2 Hosting $2.99/mo Turbo servers, free SSL, anytime money-back Speed-focused beginners

Pros and Cons of Each Provider

Bluehost

  • Pros: Officially recommended by WordPress.org, easy setup, free domain for 1 year.
  • Cons: Renewal rates are higher, limited backups on basic plan.

Hostinger

  • Pros: Lowest entry price, LiteSpeed servers for speed, weekly backups.
  • Cons: No phone support, limited data centers.

SiteGround

  • Pros: Excellent customer support, daily backups, advanced caching.
  • Cons: Higher price point, limited storage on entry plan.

DreamHost

  • Pros: Month-to-month plans, free domain privacy, automated backups.
  • Cons: No cPanel, slower support response at times.

A2 Hosting

  • Pros: Turbo servers for faster speeds, anytime money-back guarantee.
  • Cons: Turbo plans cost more, interface can be complex for beginners.

Who Is This Hosting For?

These cheap WordPress hosting options are ideal for:

  • Beginners: Easy WordPress installation and beginner-friendly dashboards.
  • Bloggers and Small Businesses: Reliable uptime and decent performance on a budget.
  • Budget-Conscious Users: Affordable plans with essential features included.
  • Users Planning to Scale: Providers offering easy upgrades as your site grows.

FAQ

  1. Is cheap WordPress hosting reliable?

    Yes, many budget hosts offer reliable uptime and performance suitable for small to medium websites. However, very low-cost plans may have limitations in resources and support.

  2. Can I upgrade my hosting plan later?

    Most providers allow easy upgrades to higher-tier plans or VPS hosting as your site traffic grows.

  3. Do these hosts include free SSL certificates?

    Yes, all the listed providers include free SSL certificates to secure your website.

  4. Is customer support available 24/7?

    Bluehost, Hostinger, SiteGround, and A2 Hosting offer 24/7 support. DreamHost support hours are slightly limited but still responsive.

  5. Can I use these hosts for WooCommerce stores?

    Yes, these providers support WooCommerce, but for larger stores, consider plans with more resources.

Works On

These hosting providers support both Apache and Nginx web servers, work well with cPanel or custom control panels, and are compatible with popular management platforms like cPanel, Plesk, and proprietary dashboards.…

Comparisons

Posts pagination

Previous 1 … 7 8 9 10 Next

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