Integriti (Pvt) Ltd.

Category: staffingResources

  • Fixing Page-Specific Errors in Avada Builder Caused by Yoast SEO Conflicts

    Error Overview

    ‍
    While editing a specific WordPress page with Avada Builder and Avada theme, some users see the dreaded message: This error often stems from a conflict between the Avada theme and the Yoast SEO plugin—typically triggered only on certain pages. The issue was reproducible only in the staging environment and on a page with the Avada text element.

    What Caused It

    • A custom provider filter page had been deleted and restored from stage
    • The frontend displayed fine, but editing in Avada Builder crashed the backend
    • The error occurred only on one specific page (not site-wide) in the WordPress admin panel

    Diagnosis & Discovery

    • Disabling Yoast resolved the issue—confirming a plugin conflict
    • Since Yoast SEO plugin couldn’t be removed globally, a page-specific solution was needed
    • The error occurred only when editing a post with a certain ID in the WordPress admin

    Smart Workaround

    ‍
    To avoid disabling Yoast across the WordPress site, we built a lightweight PHP snippet to temporarily deactivate it only when editing that specific post:

    php

    CopyEdit

    if (is_admin() && isset($_GET[‘post’]) && $_GET[‘post’] == 204 && $_GET[‘action’] === ‘edit’) {
    add_filter(‘option_active_plugins’, function ($plugins) {
    $yoast = ‘wordpress-seo/wp-seo.php’;
    if (($key = array_search($yoast, $plugins)) !== false) {
    unset($plugins[$key]);
    }
    return $plugins;
    }, 1);
    }

    This allowed the Avada Builder to load cleanly—without compromising Yoast SEO functionality site-wide.

    Final Fix & Result

    • Avada Builder now works smoothly on the affected page
    • Yoast remains active and configured for the rest of the site
    • Caching was cleared (theme, plugin, server) to complete the patch
    • No SEO settings were lost or reset

    Seeing Critical Errors in Your WordPress Admin?
    Let Integriti Studio help isolate plugin conflicts and apply precise, risk-free solutions that keep your website running smoothly.

    ‍

  • Fixing Post Order Display Issues in Toolset Views

    Issue Overview

    You reorder posts in the WordPress dashboard using drag-and-drop, manual values, or a custom post type order. But on the front end, Toolset Views sometimes renders posts in a different sort order—or seemingly random. This often happens when Toolset Views doesn’t use the menu_order field in its display logic or when a shortcode parameter overrides the intended sort.

    What We Found

    ✅ Menu Order Set Correctly

    In the backend, post order values were saved correctly using drag-and-drop and post order settings for custom post types.

    ⚙️ View Settings Misconfigured

    The Toolset View responsible for rendering the custom post type template or archive was still ordering by post date instead of post order (menu_order).

    Filters Overriding Order

    Some Views had shortcode parameters or custom filters that unintentionally overrode the Toolset sort order, affecting frontend display and dashboard hierarchy.

    Possible Theme Interference

    In a few WordPress sites, pre_get_posts or theme functions altered the expected order in templates or the front end, affecting navigation and grid display.

    What We Did

    Updated the Toolset View

    Changed the View’s “Ordering” setting to use Post order (menu_order) to control sort order.

    Tested Frontend Output

    Verified that the new order reflected exactly as defined in the backend, including dropdowns, grids, and archive pages.

    Disabled Interfering Filters

    Temporarily disabled theme or plugin filters to confirm Toolset functionality and avoid bugs affecting search results or post type integration.

    Offered WP_Query Fallback

    Provided an optional custom query snippet for clients preferring full control over ascendant or descendant order on pages where the view is used.

    Final Outcome

    Post ordering now matches the intended backend sequence, giving the client full control over layout hierarchy—essential for team directories, service lists, resource grids, and front-end design consistency.

    Need Better Visual Control?

    At Integriti Studio, we help you fine-tune WordPress plugins like Toolset to reflect exactly what you want—no guesswork, no chaos.

    Get Expert Help →

    ‍

  • Fixing Redirects from Outdated ACF Links in WordPress

    The Problem

    Some post links were pointing to the site’s former domain—despite everything appearing up to date. These weren’t hardcoded URLs, but rather relationship fields powered by ACF and advanced custom fields, embedded throughout templates, field groups, custom layouts, and the WordPress dashboard. Even old WordPress URLs in wp_postmeta or site URL settings could cause redirect issues and 404 errors.

    What We Found

    ACF Relationship Data

    ‍
    The broken links came from ACF’s relationship fields, which were still referencing the old URL, old site, or old WordPress domain within serialized postmeta data. Parts that ACF stores in a serialize format meant that standard search-replace or PHPMyAdmin edits wouldn’t work—doing so can break the permalink structure, permalinks, internal links, or corrupt values in wp_options or db tables.

    Serialized Structure

    ‍
    Since WordPress stores complex field data in a serialized format, standard search-and-replace techniques won’t work—doing so can break the structure and corrupt values.

    How We Fixed It

    1. Backed Up the Database
    Always the first step—ensuring a recovery point via staging, dev, or backup before making mass changes.

    2. Used a Safe Replace Tool

    We installed the Better Search Replace plugin, redirection plugin, or replace plugin and enabled the option for serialized data handling to fix WordPress redirects and URLs within ACF fields.

    3. Ran a Dry Test

    Before committing changes, a test run confirmed how many entries, post IDs, or old URLs would be affected.

    4. Replaced the Old Domain
    With confidence, we replaced the outdated domain, old URL, or old WordPress address in the necessary database tables, especially wp_postmeta and wp_options table, and verified rewrite rules or permalink structure updates.

    5. Cleared All Caches
    After replacement, we cleared all site cache, browser cache, or wp-admin cache to reflect the changes immediately.

    The Result

    No more unexpected redirects, 301 redirects, or issues with new URLs. Relationship links now point to the correct domain, existing site URLs, or new field references, and ACF fields behave as expected across the WordPress site.

    Having redirect headaches after a domain change?
    Reach out to Integriti Studio — we’ll help clean up legacy data the right way.

    ‍

  • Fixing WordPress Backend Errors Caused by Weglot & WP Rocket Conflict

    The Problem: Editor Fails When Weglot Is Active

    Did your WordPress site started throwing fatal PHP errors, white screen of death, or screen of death when users tried to edit or update pages with Weglot enabled? While deactivating the plugin temporarily you resolved the issue but it wasn’t a long-term solution. Server logs pointed to a conflict in the way Weglot handled output buffering — and caching behavior from WP Rocket made it worse. This type of plugin conflict occurs when two or more WordPress plugins or a plugin and theme clash on a site.

    What is the Issue?

    • Plugin Overlap: Both Weglot and WP Rocket were trying to manage script execution, especially during backend AJAX calls in the WordPress admin panel.
    • Memory Pressure: Multiple backup plugin and optimization plugins were running at once, pushing server memory limits and causing performance issues.
    • Intermittent Fixes: Disabling “Load JavaScript Deferred” in WP Rocket helped in staging site, but not consistently on the live WordPress website.
    • Admin Load Failures: These conflicts were breaking editing screens, translation switchers, and page loading in the WordPress admin area.

    ️ Step-by-Step Fix

    Step 1: Test Plugin Conflicts

    Temporarily deactivate all plugins including WP Rocket and replace it with a new plugin like better plugin compatibility control to test performance without caching conflicts and complex WordPress plugin issues.

    Step 2: Review Server Logs

    Check for PHP error, memory exhaustion, and MySQL activity that might amplify plugin and theme conflicts in WordPress.

    Step 3: Apply a Safe Code Patch

    A snippet provided by Weglot disables translation during certain admin actions. This resolved backend access issues without affecting frontend translation and ensured every WordPress user could work correctly.

    Step 4: Roll It Out

    Test changes on staging site first, then deploy to live WordPress site after verifying stability, page loading, and editing access.

    ✅ Final Result

    After applying the patch and replacing the caching tool, the site’s WordPress admin dashboard and WordPress installation returned to full functionality. Editors could now update content, switch languages, and work without backend crashes. This prevents WordPress plugin conflicts in the future, keeps your WordPress site running smoothly, and avoids plugin problems like plugin conflict occurs when two or more WordPress plugins overlap.

    What You Should Know

    • Plugin Conflicts Happen: Even the best tools can clash, especially when both handle JavaScript or caching.
    • Always Test in Staging: Use a safe environment before applying fixes to your live site.
    • Reach Out to Plugin Support: Don’t troubleshoot alone—vendor support can offer solutions like patches or filters.
    • Don’t Ignore Logs: Server logs and error messages are your best friend when tracking down deeper PHP conflicts.

    Having issues with plugin compatibility or broken admin panels?

    ‍

  • Fixing “Connection Lost” Alerts in WordPress Classic Editor

    What Was Happening?

    Site editors were constantly seeing a “Connection Lost” message when working on WooCommerce orders, custom post types, and standard posts in the WordPress dashboard. Naturally, this raised alarms—especially when it seemed to suggest failed saves, document settings not saving, or connectivity issues in the admin area.

    But here’s the thing:

    • ✔️ Orders were saving fine.
    • ✔️ No data was actually lost.
    • ❗ The error was just… stuck.

    After digging in, we discovered that this wasn’t a connectivity issue—it was a cosmetic one, triggered by outdated plugins, PHP version inconsistencies, lazy load scripts, enqueue styles in the editor, and custom code affecting post types and the classic editor.

    What We Fixed

    ✅ 1. Outdated Plugins

    We updated plugins in the staging site and ensured compatibility with minimum WordPress version requirements. Once they were current, the connection lost error stopped appearing—clearly a compatibility glitch with plugins like Elementor or other WordPress plugin conflicts was at play.

    ✅ 2. Sticky Notices from Custom CSS

    A forgotten custom CSS snippet in functions.php forced all admin notifications to stay visible—including the outdated “Connection Lost” alert. We cleaned it up and restored normal notice behavior in the WordPress admin area.

    ✅ 3. Extensive Testing

    We validated edits on posts, pages, orders, and custom post types—no data loss, and no misleading alerts. Admins could now work without distraction or false warnings. We also checked page load, CSS files, JS files, and development mode performance.

    ✅ 4. Client Reassurance

    We explained the situation to the client—ensuring they knew everything was saving properly all along, and no backend issue or plugin conflict was putting data at risk.

    ✅ The Outcome?

    A smoother editing experience in the WordPress dashboard, no scary warnings, improved editor accessibility, and fewer distractions for the team. Classic editor, Gutenberg editor, and Elementor integration now function correctly, with saved settings and improved performance.

    Not every WordPress bug is what it seems.

    ‍

  • Fixing “Invalid Product” Errors from Upsell Plugin Conflicts in WooCommerce

    Issue Overview

    A WooCommerce store using WooCommerce’s variable products and product attributes saw sitewide cart failures after a plugin update. Users couldn’t add any WooCommerce product to their cart—each attempt triggered an “Invalid product” or fatal error. This occurred despite no changes to WooCommerce product data, metadata, or SKU settings.

    What We Found

    JavaScript conflicts

    DevTools and activity logs showed errors tied to modal popups triggered by the “Add to Cart” button and AJAX requests in the dashboard.

    Plugin interference

    The issue traced back to two plugins:

    • WooCommerce Upsell Popup
    • WooCommerce Upsell Popup PRO
    Staging validation

    Disabling these plugins restored normal cart functionality instantly across the WooCommerce store and WordPress site.

    How We Fixed It

    ✅ Disabled upsell plugins

    Both upsell extensions were deactivated to restore cart functionality and resolve plugin conflicts.

    ✅ Communication

    Clients were informed that upsells and upsell features were temporarily disabled to allow seamless purchases.

    ✅ Isolated the root cause

    The plugin tried fetching or loading a removed WooCommerce product, blocking the entire cart, checkout, or product query flow.

    ✅ Planned next steps

    Options included updating, replacing the plugin, using a CSV file for product import/export, or adjusting WooCommerce settings to avoid similar future compatibility issues with plugins or themes.

    Result

    Cart and checkout functionality, including default WooCommerce product types, variable products, and product categories, was fully restored within hours. Sales resumed, plugin conflicts were diagnosed and resolved, and a safe path was created for upsells reactivation, third-party plugin adjustments, or custom web development solutions.

    Experiencing errors with WooCommerce add-to-cart or upsell plugins?

    Integriti Studio can help you troubleshoot and resolve plugin conflicts without compromising your sales.

    ‍

  • How We Fixed News Post Imports in WordPress (And Prevented Broken Links)

    Issue Background

    During the migration of a legacy WordPress site to a new environment, two major problems appeared after the first import:

    ➡️ Duplicate Featured Images:

    ‍
    Multiple news posts ended up displaying the same featured image, hurting visual consistency across the WordPress site and dashboards.

    ➡️ Broken External Links:

    A custom “external link” field triggered errors if the URL wasn’t perfectly formatted with https://, causing broken links, broken URLs, and broken outgoing links that frustrated users and led to 404 errors.

    Both issues made the new site look unprofessional, broke user trust, and created numerous broken links across content for broken pages and posts.

    Diagnosis

    ‍
    We ran a detailed audit of the import scripts, custom fields setup, and plugins like ACF and Better Search Replace:

    ✔️ Duplicate images came from a scraping tool that didn’t handle similar metadata properly—often assigning one featured image to multiple posts.

    ✔️ Broken external links traced back to strict URL validation rules rejecting plain text or incomplete URLs in the external link field, which could lead to broken links on your WordPress site and broken internal links in posts.

    Resolution Steps

    ‍

    1️⃣ Refining the Import Script

    ‍
    Rebuilt the import process to fetch individual featured images for each post, guaranteeing unique images across the WordPress website and ensuring the site was free of broken links.

    2️⃣ Image Optimization

    ‍
    Manually resized and compressed oversized featured images to reduce page load times and improve site performance.

    3️⃣ Fixing the External Link Field

    ‍
    Converted the external link field from strict URL validation to plain text, avoiding broken URLs, broken outgoing links, and bad links, while keeping flexibility for editors.

    4️⃣ Conditional Logic for Display

    ‍
    External links now open in new tabs as outbound links, while internal posts remain native, providing proper internal linking and a seamless user experience.

    Final Outcome

    ‍
    With custom coding, content clean-up, plugin configuration, and thoughtful UI handling, the chaotic import became a polished news archive. Every post now displays correctly, links work across the site, and broken links were fixed or removed. Using tools like a broken link checker plugin, Better Search Replace, or plugin like Broken Link Checker made it easy to find and fix dozens of links, keeping your WordPress site free of broken links and ready for search engines.

    ‍

  • How to Add Categories or Tags Below Posts in WordPress Templates

    Issue Overview

    One WordPress site wanted to show taxonomy tags, category and tag, or custom taxonomies (like “News” or “Topics”) beneath each blog post, single post, or custom post type. But every time a developer tried to edit the WordPress theme via the WordPress dashboard, the changes failed—or worse, broke the template file or custom template.

    Key problems included:

    • Theme templates didn’t show tags by default
    • Theme editor caused errors or wiped files
    • Posts were properly tagged—but tags weren’t visible on the front end

    Fixing the Issue

    Access files securely

    Use an FTP client, WP admin, or your host’s file manager instead of the WordPress editor. Navigate to: /wp-content/themes/your-wordpress theme/

    Find the right template

    For blog posts: single.php, content-single.php, or /template-parts/content-single.php. For custom post types like News: Look for single-news.php or template logic in functions.php. Check category page templates or archive page templates if needed.

    ️ Insert taxonomy code

    Add this snippet where you want the tags or categories to appear—usually after the_content():

    php

    CopyEdit

    <div class=”post-taxonomies”>
    <?php the_terms( get_the_ID(), ‘category’, ‘Filed under: ‘, ‘, ‘ ); ?>
    <?php the_terms( get_the_ID(), ‘post_tag’, ‘Tags: ‘, ‘, ‘ ); ?>
    </div>

    Tip: Change ‘category’ or ‘post_tag’ to your own custom taxonomy slug if needed.

    Style and test

    Add simple CSS or use your theme’s Customizer to align the new section visually with your layout. Confirm that terms display cleanly on single post pages, category pages, tag pages, or custom page templates. This helps display posts, related posts, or show a list of posts of a particular category.

    Final Result

    Your blog posts block, single post, or news posts now include visible categories, tags, or category assigned information—boosting internal linking, search visibility, taxonomy functionality, and UX without the need for extra plugins. Published posts are assigned properly, and you can create a new post, add a new category, or add tags using a WordPress plugin if needed.

    Need help modifying your WordPress theme safely?

    At Integriti Studio, we fine-tune WordPress templates to support dynamic content, smart taxonomies, and better engagement across your site.

    ‍

  • Blocking Spam: Smarter Ways to Secure WordPress Forms

    This guide walks you through real-world anti-spam tactics you can use right now—especially if you’re using WordPress form plugins on a dedicated WordPress site or WordPress website.

    What’s Really Causing the Spam?

    Most WordPress forms come with the basics, but not real protection or built-in spam features. A site owner came to us after noticing an uptick in spam submissions, spam entries, and form spam in WordPress—and it turned out their contact form, registration form, and other WordPress form plugins had no active modern anti-spam protection at all.

    That’s like leaving your front door wide open to spam bots, automated spam, or spammers using IP addresses, email addresses, and common spam patterns.

    Here’s How to Stop It

    Add Google reCAPTCHA

    One of the best spam prevention and anti-spam features to block bots.

    • Works with all major form plugins
    • Choose v3 (invisible) or v2 (checkbox)
    • Add your site keys in form settings
    • Activate across all important forms
    Use Akismet Anti-Spam

    A powerful anti-spam plugin that filters out spam automatically.

    • Integrates with Gravity Forms, WPForms, and Ninja Forms
    • Requires an API key (easy to set up)
    • Just toggle it on inside your form settings
    Enable Honeypot Protection

    Bots will fall into this trap—users won’t even know it’s there.

    • Available in most form plugins
    • Add it with one click from form settings
    • No CAPTCHA required for users

    Use Conditional Logic for Filtering

    Advanced but powerful.

    • Block submissions with certain keywords, flagged as spam, fake domains, or odd behavior
    • Examples:
      → Block if the message contains “viagra”
      → Hide the submit button if the email ends in .ru
    • Available in Pro versions of most form builders

    The Results?

    After applying these simple tweaks:

    • Spam dropped drastically
    • Real users had zero friction
    • Forms stayed clean, fast, and accessible

    Want to lock down your WordPress forms—without frustrating your users?

    ‍