Tested. Works! Could it be made possible to see changes made to display as well?

@losedk hmmm can you enlighten me a bit? what is this all referring to?

The third column. Shows if a module is shown on the particular page, not on the page or on all pages.

@losedk That was a good idea! I think now is complete

All good! I was just going to write if you could remove the logging, but you beat me to it :)

@losedk I am thinking that from a UX perspective also the checkbox for hiding stuff is not perfect. A button will be nicer

What about something like this?

One button is enough I think:

Yeah agree. But do we do that any place else? The show/hide is widely used and known to the users

@losedk Probably you are right here, the yes/no is a better fit and is the joomla way...

It is the joomla way for settings, not for filters! Doesn't seem to be a standard for filters!

@sovainfo any better suggestion? And I don't agree with you, since users know the show/hide button as a filter from the showon function

The problem for me right now is access levels, and here is what more is needed to get it to production level:
A call to #__usergroups to get an array of id and title
Convert php array to js
some logic to assign the right title to the id from the modal.

Any help is welcome!

Wouldn't mind any of the flavours for filters.

• Filter on the left
• Filter as search tool
• Filter on the right (with ordering and pagelimit) Don't think administrators know about the showon function. Don't think you should confuse filters with settings.

Now everything should nicely reflect any changes on the modal. Missing one string for access level…

Preview:

@dgt41 I think you should change something in the "Hide Unassigned Modules" button: once you have clicked it (and unassigned modules are hidden) it continues to say "Hide Unassigned Modules", while the wording should be "Show Unassigned Modules".

Personally I don't have anything against the other solution (Yes/No radio buttons) and I'll probably prefer it...

... I also think this will go nicely along with your #4661 and my #5087!

@smanzi @losedk @sovainfo I think I am done here, can you give it a go?

Preview:

@dgt41 I'm happy! Successful test :)

@test works!

@test success!

Now, I know I'm being a douchebag with this, but... it doesn't perfectly works with one of my favorite extensions: Peter van Westen's (NoNumber) "Advanced Module Manager". The modal opens and everything is OK (I can make any modification I want), but they are not reflected into to the "calling" page.

Beside this (that is obviously not "required") everything is OK!

Thanks!

@smanzi Sergio I am sorry for that. The main work here is done in the modules component, maybe you can invite Peter to take a look at the code, and why not include it in the Advanced Module Manager. After all it’s GPL ????

Good idea! Will do!!

Consider it bad UI design compared to other filter implementations.

@sovainfo I thought this was the winning one...

actually... doing right now:

@nonumber Peter, sorry for calling you in, but can you give a look at this and see if anything can be done for a smoother integration with "Advanced Module Manager"?

@dgt41 Not to me, but I only point out the inconsistency. When overruled, no problem. It is not going to be the first mistake, won't be the last.

@sovainfo
I think you can wait for this to be merged (it has a lot of hard work behind, I guess) and then propose what you think can be a better design...

@smanzi Not sure how this affects Advanced Module Manager. This only concerns the module item assignments, which should be same for core module manager and AMM.

@nonumber
with this PR when you makes modification to a module (through the modal available in menu management) this modification is immediatly reflected in what is displayed in module manager: position / assigned

This doesn't happens when the default module management is Advanced Module Manager...

@nonumber Some insights: There was nothing changed in the way modules or menus store their respective data. All I did was in the menu/views/item pass the current menu id, and the list of all the view levels and in modules/views/modal add some js to compare the data and do some changes in the parent window (the menu item).
Nothing that will break B/C here

But I guess @smanzi is asking if you can do the same in AMM...

@sovainfo you are not being overruled. Could you come up with some sort of idea? If you aren't pleased with the outcome

I keep changes to core com_modules in sync with AMM. So as soon as this is released, I will add the necessary changes to AMM too.

@nonumber that's perfect! Thanks!

@dgt41 the usage of the bootstrap modal.... you want to keep that separate? I guess yes...

@smanzi I guess that will be 3.5. There is a PR from @phproberto and @wilsonge bringing lot of functionality to layouts that has to be merged first. Then is your PR that brings some sanity to bootstrap modals. And then I have to update/redo my PRs to accommodate these changes. Also the point here is to bring every modal to BS and as we speak this ain’t possible (without breaking B/C: the mootools modal got a css script, BS is depending on the template, change it now and see how many sites will break on the front end). With layouts this will pass very easily...
3.4 is almost beta (i guess) so I guess couple of months won’t hurt that much

no, it wont hurt. And yes, it does makes sense to treat all the modals at the same time... thanks!

Moving to RTC as we have successful tests by @losedk, @smanzi and @waader Thanks @dgt41

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

@zero-24 @brianteeman Not yet RTC, there is a dispute on the button style and there is some code logic that is still buggy (display is not gracefully follows the changes)
Sorry about that!

Just to interfere:
It shouldn't be:
Hide Unassigned Modules: Show / Hide
But:
Display Unassigned Modules: Show / Hide

Also check the description: "Hide all unassigned modules" => (something like) "Select whether to show or hide all unassigned modules"

Also the language string keys should reflect this. So not HIDE_UNASSIGNED but DISPLAY_UNASSIGNED_MODULES

... or just:

Unassigned Modules: Show/Hide

Agree with @smanzi on leaving out the show. It is very inconsistently used within Joomla configuration. Suggest to standardize to a format: <subject> Show(green) Hide(red), that is without the verb in the subject and the buttons in the order mentioned.

Maybe you can leave out the change to the filter completely and introduce a proper filter in separate PR. That filter should have the search field and ordering option and page limit.

Ageed.

Are we OK with this?

Also check the description: "Hide all unassigned modules" => (something like) "Select whether to show or hide all unassigned modules"

So the new stings are:
COM_MENUS_HEADING_LEVELS="View level"
COM_MENUS_HEADING_POSITION="Position"
COM_MENUS_ITEM_FIELD_HIDE_UNASSIGNED_DESC="Shows or hides all unassigned modules"
COM_MENUS_ITEM_FIELD_HIDE_UNASSIGNED_LABEL="Unassigned Modules"

COM_MENUS_ITEM_FIELD_HIDE_UNASSIGNED_DESC="Shows or hide modules unassigned to this menu item"

Too late!

@smanzi do a refresh on this page ????

Fixed last glitches?

Should be ok for now. There is a todo for this: Get the actual menus in Module Assignment for the two cases
1. Only on the pages selected
2. On all pages except those selected

This has to be done with javascript in the iframe. There is a javascript file that is already loaded in the page and all we need is a call to the relative function, but didn’t had the time to test it (too many servers broken in one day)
Anyone feeling adventurous? https://github.com/joomla/joomla-cms/blob/staging/media/jui/js/treeselectmenu.jquery.js

don't look at me!

... was thinking: if you save (no need to close) the menu item, it refreshes the status even for those edge cases. Now I'm going to say a silly thing, but... can't you "simulate" a save? Just do the refresh part of it?

(probably you will loose edits done in other tabs...)

We could do a refresh

location.reload();

BUT you are inside a form and is not a good idea, as data might exists and will be lost.
Also saving is another think to do, but then edge case: form doesn’t validate, what do you do?

Correct. Must be done "the hard way". No simple solution/shortcuts...

The best way to go here is Ajaxify this part of the page...

OH YES!!

When the com_menus is about for major redesign I will ask for that ????

Looks like mainly working here. Glitch when changing between display or not: columns jump.

@infograf768 You mean when switching between show/hide unassigned modules? I don't see that... can you post two snapshots (Before/After)?

@dgt41 I can't help you on this (too difficult for me) but I was thinking this: would it be easier for you just to check if the module being edited is enabled for the current menu item (i.e. checking if it is enabled for: "All pages" / Related checkbox in "Only selected" / !"No pages" / !Related checkbox in "All except")? You will miss the possibility to display the "All" and "None" status and just have a boolean for this menu item, but I think this will be more than enough in this context...

@smanzi Thanks I am almost there...

Beware that Hannes is editing one of the same files you are editing in PR #5317...

@smanzi Can you try to break it?
Test case:
Module Assignment for the two cases
1. Only on the pages selected (select current menu: yes/no, select all, select none)
2. On all pages except those selected (select current menu: yes/no, select all, select none)

I'm a specialist at breaking things... let me try!

... able to break it for the "All except selected pages"...
Beside that it's OK!

example:

• start with a module assigned to another menu item (you have "No")
• change it to "All except selected" and check none (a brain-dead way to say "on all pages"...): you still have "No"

@smanzi wtf? I thought I tested every possible combination…
Anyways seems easy fix…

I told you I'm good at breaking things!

@smanzi Not anymore ???? Can you try it one more time to confirm that all cases are covered?

hold-on...

... I have the same issue as above...

@smanzi Are you sure?

skype...

No, sorry, seems to be OK!!!

One more test is needed here, anyone (@sovainfo @losedk @zero-24 @infograf768 @waader ) got some time?

@dgt41 now it is PERFECT!
@test success confirmed!

Tested successfully, thank you for the improvement!

Several good tests, I'll set it to RTC.

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

Folks, this needs a bit more:
The module title, access and position are not translatable
No need for a JText there

Chnaged to pending

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

@infograf768 Sorry about that…
Now should be fine:

Thanks! Merged.