[#28809] - Define fields for the joomla.edit.global layout in the view.html.php files
- Closed
- 26 Apr 2020
- Medium
- Build: staging
- # 28809
- Diff
- degobbis:fixStaticGlobalEditFields
- Pending Hound Hound is busy sniffing around... Details
User tests: Successful: Unsuccessful:
Summary of Changes
Define fields for the joomla.edit.global layout in the view.html.php files and not hardcoded it to the edit view of the extension.
cc: @zero-24
Testing Instructions
- Install staging
- Go to one listed edit view in the backend
- Check the global fields layout on the right hand side
- Apply patch
- Check again, still be the same
List of backendviews
- com_banners/views/banner/
- com_banners/views/client/
- com_categories/views/category/
- com_contact/views/contact/
- com_content/views/article/
- com_fields/views/field/
- com_fields/views/group/
- com_finder/views/filter/
- com_menus/views/item/
- com_modules/views/module/
- com_newsfeeds/views/newsfeed/
- com_plugins/views/plugin/
- com_tags/views/tag/
- com_templates/views/style/
B/C statement
This PR is fully B/C as you can still choose to override the fields list from the edit view and the global layout.
Expected result
Nothing hardcoded in the edit view anymore but still the same fields in the output
Actual result
Right now we hardcode the fields for the global layout in the edit fields and they can not be extended by extensions.
Documentation Changes Required
That should be documented but do you have any pointers where to look? Maybe we write a new docs page about it.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_banners com_categories com_contact com_content com_fields com_finder com_menus com_modules com_newsfeeds com_plugins com_tags com_templates Templates (admin) |
Doesn't look like a good solution. Why the use of user state?
Do you have better proposal?
Changing the XML file would be better
Changing the XML file would be better
There is no XML file and that would break B/C too. Maybe this can be done in 4.x ;)
The change here is intended to be fully B/C so we can ship it with 3.x
Get rid of all hardcoded fields and render based on form structure, i.e. fieldset by fieldset.
Get rid of all hardcoded fields and render based on form structure, i.e. fieldset by fieldset.
that's what I mean thanks sharky
@SharkyKZ @HLeithner would you agree to merge that here and let us move the cleaup and xml stuff to 4.0 as this is breaking b/c really fast.
This PR would introduce a new way which is basically the wrong way to do it so no I would not merge this in any joomla version.
Our joomla.edit layouts are not intended to be extended by plugins instead only by definition in view, I think that's a thing which should be solved conceptional in J4.
Would you mind merging it without the extension via the Session. So that we move the code out of the edit View to the view html?
I don't see a real reason for this, because the original definition of the field is in the layout it self. At least at the moment. What would be the benefit if we move it?
I wouldn't change any architectural things around those layouts anymore in J3.
For J4 I would love to see the possibility for more flexible layouts which can be used by 3rd party component.
We are working on a secret feature for joomla ;-)
But we for joomla 3 we found an workaround with changing the core.
Thx. for the feedback.
Closing while we found an workaround for our usecase.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-04-26 20:05:14 |
| Closed_By | ⇒ | degobbis | |
| Labels |
Added:
?
|
||
Doesn't look like a good solution. Why the use of user state?