[#47676] - [6.2][AI] Add dialog for selecting module positions
- Pending
- Medium
- Build: 6.2-dev
- # 47676
- Diff
- LadySolveig:6.2/feat/module-position-select-dialog
User tests: Successful: Unsuccessful:
Pull Request resolves #47582.
- I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.
Summary of Changes
Currently, the module position field only provides a Choices.js input. This PR adds a browse button to the position field that opens a modal dialog showing all available positions grouped by template and additional type active positions — enriched with the template names — and custom positions (if defined before), with a live search filter.
The picker is built on a new generic joomla-field-modal-select web component (media_source/system/js/fields/joomla-field-modal-select.w-c.es6.js) that wraps any field element and a button, opens a JoomlaDialog iframe, and writes the selected value back via postMessage. This makes it easy to add modal-browse behaviour to other fields in the future without writing custom JavaScript.
Testing Instructions
Important
This PR includes compiled JavaScript assets. Use the prebuilt packages or run npm ci to compile the assets before testing.
- Open the Joomla administrator backend and go to Content → Site Modules.
- Create a new module or open an existing one.
- On the Module tab, locate the Position field — it should now show a search icon button next to the Choices.js input.
- Click the search button: a dialog titled "Select a Position" should open showing positions grouped by template and Active Positions + Custom Positions (if defined).
- Type in the search box to filter positions; verify that groups with no matching items are hidden and a "no results" message appears when nothing matches.
- Click any position entry: the dialog should close and the position field should be populated with the selected value.
- Verify that the
changeevent fires correctly. - Repeat steps 2–6 for an Administrator Module to verify that the positions list reflects the right positions.
- Edit the module position via dialog in frontend.
Actual result BEFORE applying this Pull Request
The module position field only has a type-ahead input.
Expected result AFTER applying this Pull Request
A browse button appears next to the position type-ahead. Clicking it opens a searchable modal listing all positions grouped by template. Selecting a position closes the modal and populates the field automatically.
module-positions.mp4
Link to documentations
Please select:
-
Documentation link for guide.joomla.org:
-
No documentation changes for guide.joomla.org needed
-
Pull Request link for manual.joomla.org: [WIP]joomla/Manual#619
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_modules Language & Strings JavaScript |
| Labels |
Added:
Language Change
PR-6.2-dev
|
||
| Category | Administration com_modules Language & Strings JavaScript | ⇒ | Administration com_modules Language & Strings Front End JavaScript |
Hello,
this is an interesting addition. From what I can see, the modal provides largely the same functionality as the existing Choices.js type-ahead field, just presented in a modal interface. However, I did notice one notable difference:
- Current behavior (without PR): When typing in the search box, group titles (like "Active Positions," "Cassiopeia," etc.) disappear entirely. The filtered options appear correctly, but without any group headers.
- PR behavior (as shown in video): The modal preserves group titles during filtering, hiding entire groups that have no matches instead of just removing the headers.
Unfortunately, I couldn't test if the module works correctly as I have been ran into npm packages issue on my windows.
When running npm install on the PR branch, the build fails with:
ERR_UNSUPPORTED_ESM_URL_SCHEME Received protocol 'd:'
This appears to be a Windows path handling issue with ES Modules in the build script. The error occurs when the build script tries to process Windows drive letters (like D:). For reference:
- npm install works perfectly on the default Joomla 6 branch
- The issue only appears on the PR branch
I don't know if it's just my installation or something Windows-related, but it's broken on my setup.
This also results in the compiled joomla-field-modal-select web component not being built, causing:
There is no "webcomponent.field-modal-select" asset of a "script" type in the registry.
Would you be able to look into Windows compatibility for the build script?
Hello,
this is an interesting addition. From what I can see, the modal provides largely the same functionality as the existing Choices.js type-ahead field, just presented in a modal interface. However, I did notice one notable difference:
- Current behavior (without PR): When typing in the search box, group titles (like "Active Positions," "Cassiopeia," etc.) disappear entirely. The filtered options appear correctly, but without any group headers.
- PR behavior (as shown in video): The modal preserves group titles during filtering, hiding entire groups that have no matches instead of just removing the headers.
Unfortunately, I couldn't test if the module works correctly as I have been ran into npm packages issue on my windows.
When running npm install on the PR branch, the build fails with:
ERR_UNSUPPORTED_ESM_URL_SCHEME Received protocol 'd:'
This appears to be a Windows path handling issue with ES Modules in the build script. The error occurs when the build script tries to process Windows drive letters (like D:).
I don't know if it's just my installation or something Windows-related, but it's broken on my setup.
This also results in the compiled joomla-field-modal-select web component not being built, causing:
There is no "webcomponent.field-modal-select" asset of a "script" type in the registry.
Would you be able to look into Windows compatibility for the build script?
@CSGoat0 Could you please check whether you still encounter the issue on a fresh 6.2-dev branch? The last merged PR on that branch was the update to the build scripts. Unfortunately, I don’t have a Windows machine to hand at the moment.
If the issue persists on a fresh branch, a detailed bug report by opening an Issue would be helpfuf. If not, please do let me know here.
Thanks a lot.
@CSGoat0 Could you please check whether you still encounter the issue on a fresh 6.2-dev branch? The last merged PR on that branch was the update to the build scripts. Unfortunately, I don’t have a Windows machine to hand at the moment.
If the issue persists on a fresh branch, a detailed bug report by opening an Issue would be helpfuf. If not, please do let me know here. Thanks a lot.
Hello, it seems like you are right.
On a fresh 6.2 branch after fetching npm ci doesn't work and return the same error.
When using npm install it returns the same error but it installs the other dependencies.
On 5.4, there is no issues with either npm ci or npm install.
but i don't know if it's related to the last commit, it could be older issue i don't know.
Why not give 6.1-dev a try and then feel free to open an issue with whatever you find?
That should, however, be a separate issue from this PR. :)
Thank you for your feedback.
If you’d like to try out this PR regardless, you can find the build package here.
https://artifacts.joomla.org/drone/joomla/joomla-cms/6.2-dev/47676/downloads/92977/
I appreciate the effort but the problem can be faced in any select field using groups not just module positions. A probably much lower maintenance solution would be to replaces choices.js with tom select which natively supports option groups the way we want it on search. See the example https://tom-select.js.org/examples/optgroups/
That’s a perfectly valid point. It’s just been annoying me for a while that things get so confusing with templates that have lots of module positions, so Rolf was preaching to the converted. The universally usable web component was just the icing on the cake. I can make good use of both anyway.
That’s a perfectly valid point. It’s just been annoying me for a while that things get so confusing with templates that have lots of module positions, so @dautrich was preaching to the converted. The universally usable web component was just the icing on the cake. I can make good use of both anyway.
That’s a perfectly valid point. It’s just been annoying me for a while that things get so confusing with templates that have lots of module positions, so @dautrich was banging on an open doors with me. The universally usable web component was just the icing on the cake. I can make good use of both anyway.
@LadySolveig it annoys me too but not just for the module positions even if thats the only place you can see this problem in core joomla
@brianteeman I’ve had a quick look at the link, looks good at first glance. I don’t quite understand the context yet. For me, this would be a new PR. It’s just that it particularly annoys me in this specific spot - I didn’t say I don’t see it in other places. Everyone just has their own irritating things It’s not up to me to decide whether this is helpful for others. I’m just making the offer.
@brianteeman I’ve had a quick look at the link, looks good at first glance. I don’t quite understand the context yet. For me, this would be a new PR. It’s just that it particularly annoys me in this specific spot - I didn’t say I don’t see the problem in other places. Everyone just has their own irritating things It’s not up to me to decide whether this is helpful for others. I’m just making the offer.
I have tested this item ✅ successfully on 0db3224
Installed a commercial frontend template (J51_Skylar_J6) and a free one (Nature).
Set Cassiopeia Extended to default.
Everything works as described.
Repeated the tests for the backen. No issues either
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47676.
I have tested this item ✅ successfully on 0db3224
Installed a commercial frontend template (J51_Skylar_J6) and a free one (Nature).
Set Cassiopeia Extended to default.
Everything works as described.
Repeated the tests for the backen. No issues either
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47676.
I have tested this item ✅ successfully on 0db3224
Installed a commercial frontend template (J51_Skylar_J6) and a free one (Nature).
Set Cassiopeia Extended to default.
Everything works as described.
Repeated the tests for the backend. No issues either
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47676.
Sorry but this fails some basic accessibility and needs very careful review
@brianteeman could you explain the accessibility issues?
Hello,
this is an interesting addition. From what I can see, the modal provides largely the same functionality as the existing Choices.js type-ahead field, just presented in a modal interface. However, I did notice one notable difference:
Unfortunately, I couldn't test if the module works correctly as I have been ran into npm packages issue on my windows.
When running npm install on the PR branch, the build fails with:
ERR_UNSUPPORTED_ESM_URL_SCHEME Received protocol 'd:'This appears to be a Windows path handling issue with ES Modules in the build script. The error occurs when the build script tries to process Windows drive letters (like D:). For reference:
I don't know if it's just my installation or something Windows-related, but it's broken on my setup.
This also results in the compiled joomla-field-modal-select web component not being built, causing:
There is no "webcomponent.field-modal-select" asset of a "script" type in the registry.Would you be able to look into Windows compatibility for the build script?