[4.0] Refactoring Content Versioning#29217
Conversation
| $jform = $input->get('jform', array(), 'array'); | ||
| $versionNote = ''; | ||
|
|
||
| if ($aliasParts[0] && ComponentHelper::getParams($aliasParts[0])->get('save_history', 0)) | ||
| if (isset($jform['version_note'])) |
There was a problem hiding this comment.
Any way not to hardcode control group and fields? This looks like the opposite of:
Instead of using magic fields/attributes, the support of versioning is clearly signaled by interfaces
There was a problem hiding this comment.
I've taken a lot of existing code and didn't rewrite everything. If you have a better solution, I'm all ears.
There was a problem hiding this comment.
Not at the moment. But would be great to stop relying on input. This breaks when editing items programmatically.
There was a problem hiding this comment.
Ahh this is a good point. By now having this in a plugin is it going to cause issues with the API?
There was a problem hiding this comment.
Considering the time pressure, can we fix this in another PR and merge this one for the time being?
Co-authored-by: SharkyKZ <sharkykz@gmail.com>
|
All fixed. Can we merge this now? Given the current time pressure. ;-) |
Co-authored-by: Harald Leithner <leithner@itronic.at>
Co-authored-by: Harald Leithner <leithner@itronic.at>
|
Thanks! |
This is a redo of #23432.
The content versioning in Joomla is a rather obscure feature. Parts of it run/are available for every extension that uses the base classes, others you have to specifically add to your code. There isn't really a way to not use that system. It is also tied into the UCM system and is unnecessarily complex. This PR tries to improve on that in a few ways. This does not claim to be the perfect solution (there is a lot of stuff to do in the future), but it is hopefully a step around the backwards compatibility issues that we would have if we want to work on this in 4.1 or later.
What does this PR do?
What did I do?
I changed the name of the history table from
#__ucm_historyto#__history, dropped theucm_type_idcolumn and changed theucm_item_idcolumn to a varchar and changed how it is used. That column now contains keys of the type<component>.<type>.<id>, which is also what is used everywhere to identify the content item to edit. By this, you don't need to read the content types table first to get the right item type ID. But more importantly for me, you can now look into the table and read what type of data a row is. I consider that a better solution for debugging and better than a composite key out of 2 columns.Status
This PR is ready for testing. However, while migrating this code to the current 4.0-dev, several bugs in the 4.0-dev codebase have surfaced, which need to be fixed beforehand. I will report back here regarding those bugs.
How to test