Fix the “Something went wrong” Order Grid Error in Magento 2

If you are trying to access your Sales Order Grid and are blocked by this red error message:

“Something went wrong with processing current custom view and filters have been reset to its original state”

You are likely dealing with a broken SQL alias in a third-party module.

Screenshot: The “Something went wrong” Error

While the screen says “Something went wrong,” your var/log/exception.log or system.log will reveal the true culprit:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'main_table.main_table.created_at'

or contains weird SQL fragments such as:

`main_table`.`main_table`.created_at

you’ve likely hit a bug created by a payment or reporting extension (often Braintree). This post explains the problem and provides a safe module that fixes the issue automatically.

🧨 The Issue: main_table.main_table in the Order Grid

Magento’s sales_order_grid uses main_table as the alias for its primary table.

Some extensions incorrectly build SQL by prepending the alias twice. This produces invalid SQL like:

main_table.main_table.status

or:

`main_table`.`main_table`.created_at

This results in MySQL errors:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'main_table.main_table.created_at'

The symptoms:

• The Sales → Orders grid fails to load
• Search, filters, and sorting break
• Admin users see a generic “Something went wrong” screen

🔍 Root Cause

The issue originates from a module that hooks into:

Magento\Sales\Model\ResourceModel\Order\Grid\Collection

These modules try to add joins or filters but incorrectly generate SQL aliases, resulting in duplicated prefixes like main_table.main_table.

This is not caused by Magento core — it’s a common 3rd-party module bug.

✅ The Solution: Clean the SQL Before Execution

The FixBraintreeWhereClause module patches this safely and automatically.

It works by:

1. Intercepting the order grid collection after Magento builds the SQL

2. Inspecting key SQL parts (starting with the WHERE clause)

3. Detecting broken patterns:

   • `main_table`.`main_table`.field
   • main_table.main_table.field

4. Rewriting them to:

   • `main_table`.field
   • main_table.field

📦 Installation

Install the module via Composer:

composer require 0stoya/btfix

Then enable and refresh Magento:

bin/magento setup:upgrade
bin/magento cache:flush

You’re done. No configuration required — the fix applies automatically.

🚀 What Exactly Does the Module Fix?

The module runs a very small plugin after the grid collection loads. It looks for invalid parts in:

• WHERE
• (optional) ORDER BY
• (optional) HAVING

It replaces malformed patterns like:

main_table.main_table.status

with the correct:

main_table.status

This means:

• No grid overrides
• No plugins on filter methods
• No conflicts with other extensions
• Fully safe across Magento 2.3 and 2.4 versions

🛠 Extend or Adjust the Fix

If you want to extend the cleaning to more SQL parts:

$partsToClean = ['where', 'order', 'having'];

If another extension uses a different alias, you can add additional rules.

This makes the module flexible without touching vendor code.

🧪 Compatibility

✔ Magento 2.3.x ✔ Magento 2.4.x ✔ Fully compatible with Magento 2.4.8-p1 ✔ Works with Braintree, PayPal, Adyen, Klarna, and custom payment modules ✔ No core overrides ✔ No performance impact

🤝 When You Should Use This Module

Install this module if:

• Your Magento Sales Order Grid is broken
• You see SQLSTATE 42S22 errors mentioning main_table.main_table
• You recently updated or installed a payment/reporting module
• You want a fast, safe fix that doesn’t touch core code

If you run a busy store, you may also want to audit your payment extensions — this type of SQL bug is often a sign of deeper issues.

For professional help stabilising or refactoring your Magento modules, check our Magento development services.

❓ FAQ

Does this only fix Braintree issues?

No. It fixes any module that incorrectly generates main_table.main_table aliases.

Is it safe for production?

Yes. The module only cleans SQL fragments right before execution and does not modify business logic or customer-facing features.

Will it fix other grids?

Out of the box, it focuses on the Sales Order Grid. You can extend it, but keeping the scope tight ensures long-term stability.

Do I still need to update the offending module?

Long-term, yes. But this module gives you a clean, immediate workaround without touching vendor code.