I am unable to replicate the reported bug

@brianteeman

@adarshdubey03 thanks I was looking in the wrong place

I have tested this item ✅ successfully on 02779d9

I have tested this item ✅ successfully on 02779d9

I have tested this item ✅ successfully on 02779d9

I have tested this item ✅ successfully on 02779d9

RTC

RTC

Hi,

thanks for your PR.

I have one suggestion, it would be better to have this a bit more flexible, instead of a true/false parameter, add an array of fieldnames which should not be reset on clear.

@HLeithner Done :)

Please retest with the requested change. Thanks.

@adarshdubey03 an update to your testing instructions after your last changes would be nice that would reflect at least two different test cases. Thank you!

Test Case 2:
Change line 84 in administrator/components/com_content/tmpl/articles/default.php to

echo LayoutHelper::render('joomla.searchtools.default', ['view' => $this, 'options' => ['selectorFieldName' => 'featured', 'fieldsToPreserveOnClear' => ['filter[published]', 'filter[access][]']]]);

Set the two filters that should be preserved in articles list view and also a few others.

✅ Filter Access and Filter Publish are preserved, all other filters have been reset.

I have tested this item ✅ successfully on b2eb452

I think this should be documented. I’m not sure whether it would be sufficient in the migration notes, but I haven’t found a suitable section in the manual at short notice either.

I have tested this item ✅ successfully on b2eb452

I think this should be documented. I’m not sure whether it would be sufficient in the migration notes, but I haven’t found a suitable section in the manual at short notice either.

I have tested this item ✅ successfully on b2eb452

I think this should be documented. I’m not sure whether it would be sufficient in the migration notes, but I haven’t found a suitable section in the manual at short notice either. Any idea @HLeithner

I have tested this item ✅ successfully on b2eb452

I have tested this item ✅ successfully on b2eb452

RTC

RTC

Setting RTC (ready to commit) as the PR has 2 successful human tests and seems ok to me by review.

However, I'm not sure if 6.1-dev is the right target branch.

@HLeithner @tecpromotion What do you think?

However, I'm not sure if 6.1-dev is the right target branch.

The behaviour this PR fixes was introduced by #47352 "[5.4] Reset selector filters when clearing
SearchTools filters" (d2bce5b6dc, 2026-03-11) — the commit that added
.js-stools-container-selector to the clear condition. That commit is in 5.4-dev and shipped in
Joomla 5.4.4, so this is a live regression in released 5.4, not a 6.1-only issue.

I reproduced it on a stock 5.4.9-dev instance: Content → Workflows → set Status filter → Clear →
500 "Extension not set." Identical to 6.1.

So 5.4-dev is the natural target. The one argument for 6.1 is that the PR adds a new public
option (fieldsToPreserveOnClear) to the searchtools layout/JS, and new API in a patch release is
unusual. If that is the blocker, the two clean ways forward are:

• merge as-is into 5.4-dev — the option is additive and defaults to [], so it is fully b/c; or
• fix 5.4 minimally (revert the selector part of #47352) and land the opt-in option in 6.1.

Either way, 5.4 should not keep shipping a 500 on a button click. @richard67 — that is my answer to
your branch question.

The one argument for 6.1 is that the PR adds a new public
option (fieldsToPreserveOnClear) to the searchtools layout/JS, and new API in a patch release is
unusual.

It will be a patch release in 6.1-dev as well as in 5.4-dev. Only in 6.2-dev or 6.3-dev or 7.0-dev it would not be a patch release yet.

The one argument for 6.1 is that the PR adds a new public
option (fieldsToPreserveOnClear) to the searchtools layout/JS, and new API in a patch release is
unusual.

@tecpromotion It will be a patch release in 6.1-dev as well as in 5.4-dev. Only in 6.2-dev or 6.3-dev or 7.0-dev it would not be a patch release yet.

I've tried to rebase this PR to 5.4-dev, but that did not work well. It seems to be in general not easy to rebase from an upper to the lower branch.

So I have created PR #48468 for 5.4-dev, which is equal to this one here and keeps the commit history, so @adarshdubey03 will be mentioned as co-author in the commit when that other PR gets merged (and release managers do it right).

Thanks a lot @adarshdubey03 for your work, @QuyTon and @HLeithner for reviews, and @LadySolveig and @brianteeman for testing.

As the differences in the modified files between 5.4-dev and 6.1-dev have no impact on the changes made by this PR, the successful human tests for this PR can still be considered as valid.

Closing in favour of #48468.