Can't confirm.

Setting both Menus as stated above.

• In Menu "Blog and Tags" Articles are shown using Tag.
• In Menu "Blog without Tags" Articles are shown if they have a Tag or not. So setting Tag to "None" means "ignore if a Tag is set or not". Try: Set in Menu a not used Tag > no Article is shown.

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/18138.}

I can confirm.

Same exact problem after updating from 3.7.5 to 3.8.0.

This should be fixed ASAP as it renders category blog with tag filtering useless.

@Hurmeli can you make a Pull Request? This is needed as first Step to fix ASAP.

The fix is not valid as it means this value cannot be passed through the model state but only through the request data (so it breaks other programmatic uses of the model, i.e. in modules). By default, this particular state value is set from the request data in the same way for this model, so that alone is not the problem.

Category views use the category model on the frontend, and the category model uses the articles model to load data. The category model uses a manner to populate this state value that also uses the active user session. So the fix that is needed is to expand the state keys in a way that allows for multiple active contexts. And this isn't a problem isolated to this particular view or configuration.

I have not tested, line 117 in populateState, replace:
$value = $this->getUserStateFromRequest($this->context . '.filter.tag', 'filter_tag', 0, 'int');
by
$value = $app->input->getInt('filter_tag', 0);

No. Again, that removes being able to programmatically set the user state outside the model and forces the value to only be readable from the request. Additionally, some state values are stored to the session so that when you navigate away from a filtered view you return with the same set of filters active.

Again, the problem is not the fact that the state is in use. The problem is in the fact there is not enough uniqueness between state keys for the behavior to work consistently.

	protected function populateState($ordering = null, $direction = null)
	{
		$app = JFactory::getApplication('site');
		$pk  = $app->input->getInt('id');

		$this->setState('category.id', $pk);

		//$value = $this->getUserStateFromRequest($this->context . '.filter.tag', 'filter_tag', 0, 'int');
		$value = $app->input->getInt('filter_tag', 0);
		$this->setState('filter.tag', $value);

IMO for programmatically set we use ignore_request that do not call populateState in category model

@franz-wohlkoenig

I'm not aware of any fix. I was simply confirming that the problem exists.

Right, for programatic configuration you would pass that flag. But for the default behavior when state is autopopulated, you are breaking more than you are fixing IMO by removing the ability to read and persist the value with the session, and again to fix that requires that the key that is used be more unique than what is basically right now com_content.category.filter.tag. We have the PK a few lines above that, it is not hard to change the key to basically be com_content.category.filter.$pk.tag so that the persisted filter states do not apply to everything using the model but only to that specific category ID. If you look later in the function, we are already doing this type of filtering with the menu item ID.

OK, you solution is better. It looks like a search form that should remember the last searched fields per category.

I can also confirm this problem occurs in version 3.8.1.

@qoolman21 @Hurmeli @danielmreck You can test patch at #18248

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/18138

closed as having Pull Request #18248