User tests: Successful: Unsuccessful:
Pull Request for Issue #33692.
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.
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_modules |
Ah, no. The fix is not this simple. I will see if I can find a solution
Close this for now. When I come up with a solution, I will re-open.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-05-11 05:32:33 |
Closed_By | ⇒ | joomdonation | |
Labels |
Added:
?
|
Status | Closed | ⇒ | New |
Closed_Date | 2021-05-11 05:32:33 | ⇒ | |
Closed_By | joomdonation | ⇒ |
Status | New | ⇒ | Pending |
@sandramay0905 Could you please give it another try?
I have tested this item
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
Unfortunately, the context is hard coded in some places. These would have to be adapted with this solution.
One is here, for example:
If this is not changed, the following can happen:
@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?
I have tested this item
I confirm that switching back and forth between Site and Administrator gives independent module lists.
@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:
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?
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.
@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.
I have tested this item
Confirmed that it works and step 4 works.
I have tested this item
Status | Pending | ⇒ | Ready to Commit |
Thanks @ceford and @sandramay0905 for testing.
Thanks astrid for finding possible issues.
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 !
@Stuartemk I don't understand your comment. Is this something related to this PR ?
@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.
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
@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');
Nothing else than what I have said.
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:
?
|
Thank you!
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.