[#20615] - Tag Filter is permanently remembered even when removed
- Closed
- 13 Mar 2020
- Medium
- Build: staging
- # 20615
Steps to reproduce the issue
- Create a Category Blog Menu Item
- Click on that Menu Item on frontend
- Go to the address bar, and manually append a filter by Tag to the URL: ?filter_tag[0]=5 (where "5" can be any ID of tag, even a non-existent one).
- You will now get the category filtered by tag (might have no results if no item with that tag). All good so far.
- Now remove the paramater from the URL, or simply click on that Menu Item again to go back to the "clean" URL.
Expected result
I expect the ?filter_tag[0]= to not be remembered by the browser when you remove the paramater. I expect to see the default list of items with no filter.
Actual result
The browser will keep/remember the filtered view despite the URL being back to the being without the ?filter_tag[0]=5. No matter how many times you try to revisit the Menu Item, the filter tag will always be remembered by your browser and you will see the list of items filtered by the tag that you had before.
System information (as much as possible)
Joomla 3.8.8
Additional comments
I tried the same thing with other paramaters, like ?limitstart or ?limit, and they are correctly NOT remembered by the browser, when you remove the paramater, the view goes back to the original default full list of items.
This filter by tag seems to be the only paramater causing this bug where the filter is remembered even when removed.
| Labels |
Added:
?
|
||
Blog layout should not use user state for tag filtering. Users have no way to unset the filter, unlike in List layout.
User state should be used to remember filter states so that when you navigate away (think an edit action) you come back to things in the same state.
What #18248 addressed was the user state keys were not unique enough to the context.
The fix is not to remove user state here. The fix is to ensure that the session keys that are used have enough uniqueness between views/layouts to prevent the issue from happening in the first place.
Now, with that said...
If different layouts in a view don't support the same filter types (which looks to be the case with the com_content category view, the blog layout doesn't have filters and the default layout does), there is not much that can be done here to keep the filters from applying across layouts without either hardcoding a list of layouts into the model (bad idea) or having the model become aware of what layout is being processed (which also isn't efficient because it further couples our MVC layer to HTML page specific things).
franz-wohlkoenig
- | Status | New | ⇒ | Discussion |
| Category | ⇒ | com_tags |
In my opinion there is no point to remember the filter/user state for this. If the menu item has a filter by tag, by staying in that menu item with your edit actions, you will return to that same filter anyway.
The filter by tag is a Menu Setting, not a front-end user choice, so there is no point in keeping the user state, it's not a user state to begin with.
And the way it is now obviously breaks functionallity.
The only way to accomplish what you are saying is to create a new view.
The category view in com_content has two layouts, "default" and "blog". You're reporting issues with the blog layout. That layout doesn't include any filters in the frontend UI by default, the default layout does, and some of the filters are configurable through the backend (i.e. menu items).
The only difference in the two layouts is the rendered markup. Otherwise, it's all going through the same MVC code. The filters are supported by the models in use here, whether you're using URL manipulation or a form on the frontend the filters are applied and the state remembered.
Yes, this is problematic for the blog layout, because it doesn't have filters on the frontend in our default layouts (and nothing stops anyone from adding them in their own override or alternative layout based on the blog layout). No, the solution cannot be removing the use of user state, because then you're going to break functionality for the default layout (or any alternative layout based on the default layout).
Oh - I understand, the tag filter is part of the same filters also used in the category default layout, just not displayed in the frontend in the category blog. I see what you mean now. Hmm, that's not easy to fix then I guess.
Wait... This brought something to mind... I think this is the reason why a "filter_tag[0]=" when no tags selected was introduced in 3.8.2 maybe? It was then removed in 3.8.3 with #18981 and I was in favor of removing it because it would add an ugly "?filter_tag[0]" to category blog URLs when there were no tags selected.
But at the same time, now that I think about it, having that forced "?filter_tag[0]" on category blog with no tags selected, made sure to avoid this problem when switching to the category page with no filter, because it reset the filter to no tags filtered... Maybe this was the reason why it was implemented to begin with? Hmm...
EDIT: I confirm, found the discussion about this: #18234
Maybe a solution would be to re-implement the "NONE" tag feature by default, but WITHOUT visually appending "?filter_tag[0]" in the URL? I noticed that when filtering in the category default layout, filters do NOT get appended to the URL but still work and are still remembered. Is there a way to do the same thing?
No, the solution cannot be removing the use of user state, because then you're going to break functionality for the default layout (or any alternative layout based on the default layout).
Remove from blog only? This is already done for limit https://github.com/joomla/joomla-cms/blob/staging/components/com_content/models/category.php#L190.
We shouldn't hardcode a list of layouts in the model as I hinted at before (it creates a tighter coupling between the model processing the data and the presentation layer).
If you really want to do it "right" with our architecture, that line needs to be a configurable model state value that the view could configure before querying the data.
| Labels |
Added:
J3 Issue
|
||
| Status | Discussion | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-03-13 21:39:58 |
| Closed_By | ⇒ | jwaisner |
| Closed_Date | 2020-03-13 21:39:58 | ⇒ | 2020-03-13 21:39:59 |
| Closed_By | jwaisner | ⇒ | joomla-cms-bot |
Set to "closed" on behalf of @jwaisner by The JTracker Application at issues.joomla.org/joomla-cms/20615
This discussion has ran its course. With no replies indicating this is a bug or feature request this is closed.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20615.
afaict the filter is being set in a cookie