[#23577] - [4.1] Parameters for Module Chromes
- Fixed in Code Base
- 9 Nov 2021
- Medium
- Build: 4.0-dev
- # 23577
- Diff
- Bakual:ChromeParams
- Success Download Prebuilt packages are available for download. Details
- Failure continuous-integration/drone/pr Build is failing Details
- Success continuous-integration/appveyor/pr AppVeyor build succeeded Details
User tests: Successful: Unsuccessful:
This isn't ready to be used yet as it needs some discussion first.
Summary of Changes
All it does is looking in the chrome jlayout folders for XML files and loading them into the module edit form.
Testing Instructions
Create an XML in a chrome folder and put some fields into it. As an example create the file templates/cassiopeia/html/layouts/chromes/params.xml and put the following content into it:
<?xml version="1.0" encoding="utf-8"?>
<form>
<fields name="params">
<fieldset
name="advanced">
<field
name="cassiopeia_test"
type="text"
label="Test Field Cassiopeia"
showon="style:Cassiopeia-card"
/>
</fieldset>
</fields>
</form>
Expected result
The defined parameter should be available in the module edit form.
Since the example has a showon defined, it will only show up if you have selected the module style "card" from Cassiopeia.
Documentation Changes Required
Obviously.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_modules Templates (admin) Layout Libraries Front End Templates (site) |
What happens if the module style is left on inherited. Currently the custom chrome parameters aren't shown the way the showon is written. Would that be acceptable?
Tricky. I guess this means that to show the parameters, a user has to select the chrome from the list, even thou the selected chrome is the same as the inherited. Seems incorrect but not sure how to work around it.
Seems incorrect but not sure how to work around it.
Yep, I have the same feeling. Imho we can either show all possible parameters, only the default ones or none. We have no way of knowing which is the inherited style, and it may even change when the active template changes.
Personally, I would lean towards displaying none. Assuming that can be enforced and the template dev can't override it by simply not setting the 'showon'.
franz-wohlkoenig
- | Title |
|
||||||
| Title |
|
||||||
Yep, definitively interested, but certainly not in the comins week or two. Maybe later I can fix it,
Since it's an RFC, I would be interested in more opinions on the matter anyway.
| Category | Administration com_modules Templates (admin) Layout Libraries Front End Templates (site) | ⇒ | Administration com_modules Layout Front End Templates (site) |
| Category | Administration com_modules Layout Front End Templates (site) | ⇒ | Administration com_modules |
Fixed the conflicts (they were coming from the now merged other PR). Adjusted the PR description.
I have tested this item
Thank you for adding Parameters for Module Chromes
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/23577.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/23577.
| Category | Administration com_modules | ⇒ | Unit Tests Administration com_modules com_users Language & Strings Libraries Front End Plugins |
| Labels |
Added:
?
?
|
||
| Category | Administration com_modules Unit Tests com_users Language & Strings Libraries Front End Plugins | ⇒ | Unit Tests Repository Administration com_admin SQL Postgresql MS SQL com_associations com_categories com_config |
| Labels |
Added:
?
Removed: ? |
||
| Category | Administration Unit Tests Repository com_admin SQL Postgresql MS SQL com_associations com_categories com_config | ⇒ | Administration com_modules |
PR is rebased on 4.1-dev now. Code has not changed.
| Title |
|
||||||
| Labels |
Added:
?
Removed: ? ? ? ? |
||
Removed the use of JForm in favor of Form
Now skipping a template if there is no chrome folder in it (was giving an warning message before)
I like this feature, and it works as described.
As it is a new feature, and documentation is needed, we could do a reordering of the fields, so that it is better understandable?
At least move the field module style at the end, so it is together with newly pluggend in params? @Bakual
That's a good idea. I moved the style parameter to the end so it's next to the chrome parameters.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/23577.
I have tested this item
Field shows up and works and parameter is stored in the DB.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/23577.
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/23577.
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-11-09 14:14:58 |
| Closed_By | ⇒ | bembelimen | |
| Labels |
Added:
?
|
||
Thx
@Bakual I just noticed that language strings is the params.xml are not working. In your example you use hard coded language strings. It would be nice if language strings can be added so the parameters become Multilingual. Maybe add a new PR. Ping me if you need someone to test
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/23577.
Language strings work. I actually just used the feature this week. Did you put the language strings into the templates template_name.sys.ini language file? Because I think only that one is loaded.
@ciar4n mentioned in #23570 (comment) the fact that the way it is done here means template devs need to play nice. The showon would be essential and I also think the prefixed field name.
There are some other thoughts which are needed here. Some that come to mind:
inherited. Currently the custom chrome parameters aren't shown the way the showon is written. Would that be acceptable?