? ? Pending

User tests: Successful: Unsuccessful:

avatar joomdonation
joomdonation
11 May 2021

Pull Request for Issue #33692.

Summary of Changes

Currently, we use same session key for Admin and Site modules filter options value, thus causes unexpected behavior. One of the issue is #33692

There are other issues, too. For example, if you are on Site Modules and select a module position filter, then switch to Administrator, you won't see any modules... (because the system remember that site position, but of course, backend modules have different positions list. Same for module filter and menu item filter.

Testing Instructions

  1. Look at the issue #33692 , confirm that the issue happens (you would need to have a multilingual website to confirm the issue)
  2. Apply patch, confirm that the issue sorted.
  3. Try to filter modules by position, by module types and make sure it is still working as expected, nothing should be broken
  4. From Modules Management screen, choose a module position. Then press New button in toolbar, confirm that that module position is pre-selected on New module screen.
avatar joomdonation joomdonation - open - 11 May 2021
avatar joomdonation joomdonation - change - 11 May 2021
Status New Pending
avatar joomla-cms-bot joomla-cms-bot - change - 11 May 2021
Category Administration com_modules
avatar joomdonation joomdonation - change - 11 May 2021
The description was changed
avatar joomdonation joomdonation - edited - 11 May 2021
avatar sandramay0905 sandramay0905 - test_item - 11 May 2021 - Tested unsuccessfully
avatar sandramay0905
sandramay0905 - comment - 11 May 2021

I have tested this item ? unsuccessfully on 16f40f9

Test using patchtester got same behaviour with and without pr. Test filter on language and position.


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/33763.

avatar joomdonation
joomdonation - comment - 11 May 2021

Ah, no. The fix is not this simple. I will see if I can find a solution

avatar joomdonation
joomdonation - comment - 11 May 2021

Close this for now. When I come up with a solution, I will re-open.

avatar joomdonation joomdonation - close - 11 May 2021
avatar joomdonation joomdonation - change - 11 May 2021
Status Pending Closed
Closed_Date 0000-00-00 00:00:00 2021-05-11 05:32:33
Closed_By joomdonation
Labels Added: ?
avatar joomdonation joomdonation - change - 11 May 2021
Status Closed New
Closed_Date 2021-05-11 05:32:33
Closed_By joomdonation
avatar joomdonation joomdonation - change - 11 May 2021
Status New Pending
avatar joomdonation joomdonation - reopen - 11 May 2021
avatar joomdonation
joomdonation - comment - 11 May 2021

@sandramay0905 Could you please give it another try?

f449246 11 May 2021 avatar joomdonation CS
avatar sandramay0905 sandramay0905 - test_item - 11 May 2021 - Tested successfully
avatar sandramay0905
sandramay0905 - comment - 11 May 2021

I have tested this item successfully on f449246

Test Filters Site: Language, Position and combination > Admin display of modules is not effected.

Enabled on Admin language filtering: Filter on Persian and in site on english > works.

Thanks @joomdonation


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/33763.

avatar astridx
astridx - comment - 11 May 2021

Unfortunately, the context is hard coded in some places. These would have to be adapted with this solution.

One is here, for example:

$position = $app->getUserState('com_modules.modules.filter.position');

If this is not changed, the following can happen:

  1. Make a new installaiton and filter modules

1

  1. Move a module that is the only one on its position to another position.
    2

  2. After moving you see no module in the list.
    3

avatar joomdonation
joomdonation - comment - 11 May 2021

@astridx Do you know if there are other places affected by this change? I ask because you tried to fix this issue before, so you have more experience and could help.

99911e6 11 May 2021 avatar joomdonation Typo
avatar joomdonation
joomdonation - comment - 11 May 2021

@astridx Unless I'm mistaken, I think the issue you are talking about happens before this PR:

Something like (quick draft code, clean up needed)

$app = Factory::getApplication();

$position = $app->getUserState('com_modules.modules.' . $clientId . '.filter.position');

if ($position)
{
	$found = false;

	// Add active position here
	foreach ($options as $option)
	{
		if ($option->value ===$position)
		{
			$found = true;
			break;
		}
	}

	if (!$found)
	{
		$options[] = \JHtml::_('select.option', $position, $position);
	}
}

How do you think about it?

avatar ceford ceford - test_item - 12 May 2021 - Tested successfully
avatar ceford
ceford - comment - 12 May 2021

I have tested this item successfully on ca23363

I confirm that switching back and forth between Site and Administrator gives independent module lists.


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/33763.

avatar astridx
astridx - comment - 12 May 2021

@astridx Unless I'm mistaken, I think the issue you are talking about happens before this PR:

Now I'm not sure I understand you correctly. Without this PR, the error described in #33763 (comment) does not occur, right?

@astridx Do you know if there are other places affected by this change?

I don't know Joomla well. I searched for "com_modules.modules" and found this place:

$filters = (array) $app->getUserState('com_modules.modules.filter');

But I don't know how important this is and I don't know if there are other places where the context might be put together with variables?

avatar joomdonation
joomdonation - comment - 13 May 2021

Now I'm not sure I understand you correctly. Without this PR, the error described in #33763 (comment) does not occur, right?

Actually, that error happens because this PR. I explained the issue and proposed the solution in my earlier comment #33763 (comment). But I don't want to include that in this PR. I can make a new PR for that if needed.

I don't know Joomla well. I searched for "com_modules.modules" and found this place:

=> That's not affected by the PR. It uses to auto-populate data when you create new module base on data from filter. For example, if you choose a Position in Modules Management page, that will be default position when you press New button to create a new module. That still works after this PR.

avatar joomdonation
joomdonation - comment - 13 May 2021

@astridx Thinking more about the issue you described, I think after moving the modules to new position, we should set the position filter to that new position. That would be best solution, I think

avatar joomdonation
joomdonation - comment - 13 May 2021

But I don't know how important this is and I don't know if there are other places that might be put together with variables?

Actually, that is affected by this PR and fixed by this comment d47154e

avatar joomdonation joomdonation - change - 13 May 2021
The description was changed
avatar joomdonation joomdonation - edited - 13 May 2021
avatar joomdonation
joomdonation - comment - 13 May 2021

@sandramay0905 @ceford Could you please help testing it again? There is a new commit which auto-populate data for New Module base on data from filter (step #4 in testing instructions). Compare to your previous test, that new step is needed.

The issue which @astridx mentioned is independent with this PR and I will make a new PR to fix it after this one merged (because the new code will depend on this PR)

Thanks.

avatar ceford ceford - test_item - 13 May 2021 - Tested successfully
avatar ceford
ceford - comment - 13 May 2021

I have tested this item successfully on d47154e

Confirmed that it works and step 4 works.


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/33763.

avatar sandramay0905 sandramay0905 - test_item - 13 May 2021 - Tested successfully
avatar sandramay0905
sandramay0905 - comment - 13 May 2021

I have tested this item successfully on d47154e


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/33763.

avatar joomdonation joomdonation - change - 13 May 2021
Status Pending Ready to Commit
avatar joomdonation
joomdonation - comment - 13 May 2021

Thanks @ceford and @sandramay0905 for testing.


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/33763.

avatar sonnemondundsterne
sonnemondundsterne - comment - 13 May 2021

Thanks astrid for finding possible issues.

avatar Stuartemk
Stuartemk - comment - 13 May 2021

It is assumed that (array) should no longer be used, instead it should be [], there are many (array) in the whole Joomla 4 cms and they are still adding more, perhaps there is something that I do not know and justify the use of (array). Please tell me if I am in error and if not, change all the (array) to [] or at least not continue with that obsolete practice.
They are doing a great job !

avatar joomdonation
joomdonation - comment - 13 May 2021

@Stuartemk I don't understand your comment. Is this something related to this PR ?

avatar richard67
richard67 - comment - 13 May 2021

@Stuartemk Maybe you mix up type cast (array) $somevariable and array creation array(1,2,3)? Only the latter is replaced by short array syntax [1,2,3] in J4, but here in the diff of this PR I only see a type cast to array, and that's something completely different.

avatar Stuartemk
Stuartemk - comment - 13 May 2021

Maybe I'm confused, but I think this should be changed to be 100% compatible with php8 I think so, but I can be wrong

$filters = (array) $app->getUserState('com_modules.modules.' . $clientId . '.filter');

for this

$filters = [ ] $app->getUserState('com_modules.modules.' . $clientId . '.filter');

Regards

avatar joomdonation
joomdonation - comment - 13 May 2021

@Stuartemk No, it's not valid syntax. For type casting, we will still have to use the original code:

$filters = (array) $app->getUserState('com_modules.modules.' . $clientId . '.filter');
avatar richard67
richard67 - comment - 13 May 2021

Nothing else than what I have said.

avatar Quy Quy - change - 13 May 2021
Status Ready to Commit Fixed in Code Base
Closed_Date 0000-00-00 00:00:00 2021-05-13 18:52:58
Closed_By Quy
Labels Added: ?
avatar Quy Quy - close - 13 May 2021
avatar Quy Quy - merge - 13 May 2021
avatar Quy
Quy - comment - 13 May 2021

Thank you!

Add a Comment

Login with GitHub to post a comment