Fix “Something went wrong with processing current custom view” in Magento 2

If you have opened your Magento 2 Sales Order Grid and been blocked by this message:

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

You are dealing with one of two completely different problems that share an almost identical error message. Applying the wrong fix wastes time and in some cases makes things worse.

This post covers how to tell them apart and fix both.

Diagnose First: Which Problem Do You Have?

Before doing anything else, open your Magento logs and run one query.

Check the logs:

tail -50 var/log/exception.log
tail -50 var/log/system.log

Then run this in your database:

SELECT * FROM ui_bookmark
WHERE namespace = 'sales_order_grid'
ORDER BY updated_at DESC
LIMIT 5;

Fix A: The SQL Alias Bug

What Is Happening

Magento’s sales_order_grid uses main_table as the SQL alias for its primary table. Some third-party extensions — most commonly payment modules including Braintree — hook into the order grid collection and incorrectly prepend this alias a second time when building their SQL clauses.

This produces invalid SQL fragments like:

main_table.main_table.status

or:

`main_table`.`main_table`.created_at

MySQL cannot resolve these column references and throws:

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

Magento catches this exception, resets your grid filters, and shows the generic “something went wrong” message — which is why the actual SQL error is only visible in the logs, not on screen.

What Causes It

The bug originates from a module that hooks into:

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

These modules try to add joins or WHERE conditions to the grid collection but incorrectly build their SQL using the table alias rather than the table name, resulting in the duplicated main_table.main_table prefix.

This is not a Magento core bug. It is a third-party module implementation error.

The Fix: FixBraintreeWhereClause Module

The fastest safe resolution is the 0stoya/btfix module, which intercepts the grid collection after Magento builds the SQL, detects the malformed alias patterns, and rewrites them to the correct form before execution.

It catches:

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

And rewrites them to:

• `main_table`.field
• main_table.field

Installation:

composer require 0stoya/btfix
bin/magento setup:upgrade
bin/magento cache:flush

No configuration required. The fix applies automatically to the WHERE, ORDER BY, and HAVING clauses of the order grid collection.

Compatibility: Magento 2.3.x through 2.4.8-p1. Works with Braintree, PayPal, Adyen, Klarna, and any other module producing this pattern.

The Proper Long-Term Fix

The module is a safe and immediate workaround, but it does not fix the underlying module bug. The correct long-term resolution is to update the offending third-party extension to a version that generates correct SQL, or to patch its collection plugin directly.

To identify which module is responsible:

grep -r "main_table" vendor/*/magento-*/Plugin/ --include="*.php" | grep -i "order\|grid\|collection"

Or check which modules have observers or plugins on Magento\Sales\Model\ResourceModel\Order\Grid\Collection:

grep -r "Order\\\\Grid\\\\Collection" vendor/ --include="*.xml" -l

Once identified, check whether the extension vendor has released an update addressing this. If not, the btfix module keeps your grid functional while you evaluate alternatives.

Fix B: The ui_bookmark Corruption

What Is Happening

This is a different problem that produces the same error message. No SQL alias bug is involved.

Magento stores each admin user’s grid configuration — column visibility, applied filters, sort order, pagination — in the ui_bookmark database table. Each combination of user, grid namespace, and state identifier gets a row.

When this stored configuration becomes corrupted or contains references to columns or filters that no longer exist (often after a Magento upgrade, extension change, or database migration), loading the grid fails because Magento cannot reconstruct the stored view state. It resets the filters and shows the “something went wrong” error.

The distinguishing characteristic: there is no SQL error in your exception log. The error appears consistently on page load, and temporarily disappears after clearing the ui_bookmark table — but returns the next time that admin user loads the grid, because the corrupted row gets recreated.

Fix B1: Clear the specific user’s bookmark (safest)

First, find the affected admin user’s ID:

SELECT user_id, username FROM admin_user WHERE username = 'your_username';

Then delete just their order grid bookmark:

DELETE FROM ui_bookmark
WHERE namespace = 'sales_order_grid'
AND identifier = 'current'
AND user_id = YOUR_USER_ID;

This removes only the corrupted view state for that user. Other users and other grids are unaffected. The user will need to reconfigure their column preferences, but nothing is lost permanently.

Fix B2: Clear all bookmarks for the order grid

If multiple admin users are affected:

DELETE FROM ui_bookmark WHERE namespace = 'sales_order_grid';

Fix B3: Truncate the entire ui_bookmark table

If the error is appearing across multiple grids (products, customers, orders) for multiple users:

TRUNCATE ui_bookmark;

Why Does It Keep Coming Back?

If the error returns after clearing ui_bookmark, something is regenerating the corrupted row. Common causes:

A Magento upgrade left orphaned column references. An extension that added custom columns to the order grid was removed or updated, but the stored grid configuration still references those columns. The fix is to ensure all active extensions match your Magento version.

A database migration introduced corrupt JSON. If your ui_bookmark table was migrated from an older Magento instance (for example, using Magmi or a custom import), the JSON in the config column may be malformed. Check the config value:

SELECT config FROM ui_bookmark
WHERE namespace = 'sales_order_grid'
AND identifier = 'current'
AND user_id = YOUR_USER_ID;

If the JSON is malformed or references non-existent columns, delete the row. Magento will recreate it correctly on next grid load.

An extension is writing a bad bookmark on every grid load. This is less common but possible. Check your exception log immediately after loading the order grid — if a module is throwing an exception during grid render and then writing a fallback state that happens to be corrupted, you will see evidence of it there.

Quick Reference: Which Fix to Use

Frequently Asked Questions

Does the btfix module only fix Braintree? No. It fixes the main_table.main_table alias pattern regardless of which module generates it. Braintree is the most common culprit but any extension with this bug in its collection plugin will be fixed.

Is truncating ui_bookmark safe on a live store? Yes — it only removes saved grid preferences. No order data, product data, or customer data is affected. Admin users will need to reconfigure their column visibility preferences, but nothing operationally significant is lost.

Will clearing ui_bookmark fix the SQL alias bug? No. These are separate problems. If your issue is the SQL alias bug, clearing ui_bookmark will not help — the grid will continue to fail on every load because the underlying SQL is still malformed.

Should I update the offending payment module? Yes, as a long-term step. The btfix module is a safe workaround, but the root cause is a bug in the third-party extension. Check whether an updated version is available from your extension vendor.

My error says “processing the default view” not “processing current custom view” — is this the same? The wording varies slightly between Magento versions but the underlying causes are identical. Both error strings point to the same two root causes covered in this post.

If your order grid is breaking as part of broader platform instability — repeated deployment issues, extension conflicts, or upgrade problems — the underlying issue is usually accumulated technical debt rather than an isolated bug. Our Magento technical audit covers extension conflict analysis, grid and collection issues, and a prioritised action plan. For hands-on resolution, see our Magento support retainers or Magento project rescue.