Author: admin

Issue Overview

You reorder posts in the dashboard using drag-and-drop or manual values. But on the front end, they still appear in a different order—or seemingly random. This often happens when Toolset Views doesn’t use the menu_order field in its display logic.

What We Found

✅ Menu Order Set Correctly

In the admin, post order values were saved correctly using drag-and-drop.

⚙️ View Settings Misconfigured

The Toolset View responsible for rendering the CPT was still ordering by post date.

Filters Overriding Order

Some Views had shortcode parameters or custom filters that unintentionally overrode sorting logic.

Possible Theme Interference

In a few cases, pre_get_posts or theme functions altered the expected order.

What We Did

Updated the Toolset View

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

Tested Frontend Output

Verified that the new order reflected exactly as defined in the backend.

Disabled Interfering Filters

Temporarily disabled theme or plugin filters to confirm Toolset behavior.

Offered WP_Query Fallback

Provided an optional custom query snippet for clients preferring full control.

Final Outcome

Post ordering now matches the intended backend sequence, giving the client full control over layout hierarchy—essential for team directories, service lists, or resource grids.

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 →

‍

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, embedded throughout templates and custom layouts.

What We Found

ACF Relationship Data

‍
The broken links came from ACF’s relationship fields, which were still referencing the old domain within serialized postmeta data.

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 before making mass changes.

2. Used a Safe Replace Tool
We installed the Better Search Replace plugin and enabled the option for serialized data handling.

3. Ran a Dry Test
Before committing changes, a test run confirmed how many entries would be affected.

4. Replaced the Old Domain
With confidence, we replaced the outdated domain in the necessary database tables (especially wp_postmeta).

5. Cleared All Caches
After replacement, we cleared all site and browser caches to reflect the changes immediately.

The Result

No more unexpected redirects. Relationship links now point to the correct domain, and ACF fields behave as expected across the site.

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

‍

The Problem: Editor Fails When Weglot Is Active

Did your WordPress site started throwing fatal PHP errors 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 made it worse.

What is the Issue?

• Plugin Overlap: Both Weglot and WP Rocket were trying to manage script execution, especially during backend AJAX calls.

• Memory Pressure: Multiple backup and optimization plugins were running at once, pushing server memory limits.

• Intermittent Fixes: Disabling “Load JavaScript Deferred” in WP Rocket helped in staging, but not consistently on the live site.

• Admin Load Failures: These conflicts were breaking editing screens and translation switchers in the dashboard.

️ Step-by-Step Fix

Step 1: Test Plugin Conflicts

Temporarily deactivate WP Rocket and replace it with Autoptimize to test performance without caching conflicts.

Step 2: Review Server Logs

Check for memory exhaustion and MySQL activity that might amplify plugin issues.

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.

Step 4: Roll It Out

Test changes in staging first, then deploy to live after verifying stability and editing access.

✅ Final Result

After applying the patch and replacing the caching tool, the site’s admin dashboard returned to full functionality. Editors could now update content, switch languages, and work without backend crashes.

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?

‍

What Was Happening?

Site editors were constantly seeing a “Connection Lost” message when working on WooCommerce orders and standard posts. Naturally, this raised alarms—especially when it seemed to suggest failed saves or connectivity issues.

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 plugin behavior and custom code.

What We Fixed

✅ 1. Outdated Plugins

We updated plugins in the staging environment. Once they were current, the issue stopped appearing—clearly a compatibility glitch was at play.

✅ 2. Sticky Notices from Custom CSS

A forgotten 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.

✅ 3. Extensive Testing

We validated edits on posts, pages, and orders—no data loss, and no misleading alerts. Admins could now work without distraction or false warnings.

✅ 4. Client Reassurance

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

✅ The Outcome?

A smoother editing experience, no scary warnings, and fewer distractions for the team.

Not every WordPress bug is what it seems.

‍

Issue Overview

A WooCommerce store saw sitewide cart failures after a plugin update. Users couldn’t add any product to their cart—each attempt triggered an “Invalid product” error. This occurred despite no changes to product settings.

What We Found

JavaScript conflicts

DevTools showed errors tied to modal popups triggered by the “Add to Cart” button.

Plugin interference

The issue traced back to two plugins:

• WooCommerce Upsell Popup

• WooCommerce Upsell Popup PRO

Staging validation

Disabling these plugins restored normal cart behavior instantly.

How We Fixed It

✅ Disabled upsell plugins

Both upsell extensions were turned off to restore cart functionality across the site.

✅ Communication

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

✅ Isolated the root cause

The plugin tried loading a removed upsell product, blocking the entire cart flow.

✅ Planned next steps

Options included updating or replacing the plugin—or adjusting settings to avoid similar future conflicts.

Result

Cart and checkout functionality was fully restored within hours. Sales resumed, and a safe path was created for upsell reactivation or alternative 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.

‍

Issue Background

During the migration of a legacy website to a new WordPress 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.

➡️ Broken External Links:

‍
A custom “external link” field triggered errors if the URL wasn’t perfectly formatted with https://, breaking functionality and frustrating users.

Both issues made the new site look unprofessional and broke user trust.

Diagnosis

‍
We ran a detailed audit of the import scripts and custom fields setup:

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

✔️ The broken links traced back to a URL validation rule rejecting plain text or incomplete URLs in the “external link” field.

Resolution Steps

‍

1️⃣ Refining the Import Script

‍
We rebuilt the import process to fetch individual featured images for each post, guaranteeing unique images across the site.

2️⃣ Image Optimization

‍
We manually resized and compressed any oversized featured images to reduce load times and improve site performance.

3️⃣ Fixing the External Link Field

‍
By converting the external link field from strict URL validation to plain text, we eliminated errors while keeping flexibility for editors.

4️⃣ Conditional Logic for Display

‍
Now, external links open in new tabs and behave as outbound references. Regular posts stay native to the site for a seamless experience.

Final Outcome

‍
With custom coding, content clean-up, and thoughtful UI handling, we transformed the chaotic import into a polished news archive. Every post now displays properly, links behave reliably, and the whole system works the way it should.

‍

Issue Overview

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

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 or your host’s file manager instead of the WordPress editor. Navigate to:
/wp-content/themes/your-theme/

Find the right template

For blog posts: single.php, content-single.php, or /template-parts/content-single.php
For custom types like News: Look for single-news.php or template logic in functions.php

️ 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.

Final Result

Your blog or news posts now include visible categories and tags—boosting internal linking, search visibility, and UX without the need for extra plugins.

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.

‍

What Was Going Wrong

A client’s contact form emails included a link to a key application page. But users reported that the link either broke or redirected incorrectly. The email was being sent using WP Mail SMTP and SendGrid.

Root Cause

Link Rewriting by SendGrid

‍
SendGrid was rewriting the original URLs to go through their tracking domain (to measure clicks), but those rewritten links weren’t working.

️ DNS or Tracking Misconfig

‍
The click tracking subdomain hadn’t been fully set up in SendGrid’s dashboard — or the DNS wasn’t resolving properly.

Steps to Fix It

1. Check the Setup

‍
Go to your WordPress WP Mail SMTP settings and confirm that SendGrid is the active mailer.

2. Review Click Tracking Settings

‍
In SendGrid:

• Go to Settings > Tracking

• Look at the domain listed under click tracking

• Make sure the proper CNAME DNS record is set up and active

3. Test the Links

‍
Send yourself a test email. Inspect the source of the email to see the rewritten URLs. Try clicking them — if they fail, it’s definitely a SendGrid redirect issue.

4. Disable Click Tracking (if needed)

‍
To restore working links instantly, you can disable SendGrid’s click tracking feature. This stops the URL rewriting and keeps your links clean.

5. Clean Up the Template

‍
While testing, make sure your email templates are free of broken links or unnecessary tracking codes.

The Result

Once click tracking was disabled, links worked perfectly again. The autoresponder email now routes users where they’re supposed to go — helping the client avoid lost leads.

Trouble with your WordPress emails or SMTP setup?
Let Integriti Studio handle it — from mailer configs to link integrity.

‍

The Problem

On a WordPress site powered by CPTs, a recently re-published listing failed to appear in specific filtered views and search queries, despite being publicly accessible on its individual page. This often happens when:

• Key custom fields that power filters are left empty

• Query logic relies on future-dated schedules

• Filters are stacked in a way that excludes incomplete records

• Cache or replication delays skew the frontend display

What We Found

To isolate the issue, our team at Integriti Studio reviewed the content setup and filtering logic:

✅ Custom Field Checks

One required field—used by the filter system to group CPTs—was empty. Because the query expected a value, this post was silently skipped in results.

✅ Filter Query Debugging

The PHP behind the filter logic was relying on meta_query conditions that excluded empty fields. The logic also compared scheduling dates, which can block visibility if not configured properly.

✅ Display Context Audit

The post was missing from filtered lists but appeared on its standalone page and in some unfiltered queries. This inconsistency confirmed that the filtering code—not post status—was to blame.

How We Fixed It

1. Populated Required Fields

We ensured the post had a valid value in the “all centers” field so it would be picked up by filters expecting that key.

2. Adjusted Conditional Logic

Updated the template to include posts if they met either a valid future date condition or an appropriate assignment like location.

3. Ordered Output Clearly

Added a fallback orderby parameter to maintain predictable sorting (like alphabetical order), improving both UX and debugging clarity.

4. Cleared Caches and Retested

Purged all plugin, server, and object caches. Then tested the result in:

• Global site search

• Filter-based listings

• CPT archives

• Location-based views

The Result

The entry now displays as expected across all views. This fix ensures future posts won’t fall through the cracks due to incomplete fields or overly strict filters—keeping directories complete and user journeys smooth.

Struggling with CPT Search and Filters?

We help WordPress sites avoid broken listings and patchy search results with clean, scalable logic.

Get in touch with Integriti Studio — and make every listing count.

‍

What’s the Issue?

Variable products are supposed to display a price range (e.g., $9.99 – $49.99) on category pages. But sometimes, especially with Algolia-powered search, only the lowest price appears. This happens when the min_price and max_price values aren’t being synced properly between WooCommerce and Algolia.

Other symptoms might include:

• Missing or incorrect sale prices

• Price formatting errors (like $108.5 instead of $108.50)

• Products showing $0.00 due to stale or invalid data

How to Fix It

1. Update Your Algolia Index

Make sure min_price and max_price fields are being pushed to Algolia during product indexing. If they’re missing, category pages won’t be able to display the range.

Use bulk update methods like wp_update_post() or admin batch edits to trigger a full sync.

2. Fix the Price Template Logic

Edit your WooCommerce theme or builder templates so that:

• The full price range displays when min and max values differ

• Sale prices are shown clearly with correct formatting

• Single-price products don’t show ranges unnecessarily

• Decimal formatting stays consistent at two places

3. Improve Sale Price Sync

WooCommerce sometimes fails to notify Algolia when scheduled sales go live. Include sale_start_date and sale_end_date in the product index and modify your frontend logic to account for these dates instead of relying on default sale status.

4. Handle the Edge Cases

Look out for older product entries or database irregularities. Add logic to handle:

• Missing price values

• Outdated variations

• Incorrect formatting caused by import or plugin issues

Clear all cache layers once the fixes are implemented to ensure changes appear live.

✅ What You’ll Achieve

After fixing the indexing and display logic:

• Your category pages will accurately reflect price ranges and sales

• Customers won’t get confused by misleading pricing

• Algolia and WooCommerce will stay properly synced—automatically

Need help cleaning up your price logic or syncing search with WooCommerce?

‍