[#23432] - [4.0] Refactoring Joomla History feature to get away from UCM
- Closed
- 1 Apr 2020
- Medium
- Build: 4.0-dev
- # 23432
- Diff
- Hackwar:j4history
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
- Success continuous-integration/drone/pr the build was successful Details
- Success continuous-integration/appveyor/pr AppVeyor build succeeded Details
User tests: Successful: Unsuccessful:
I've been messing around with tagging and the longer I messed around with it, the more I came to the conclusion that we have to get rid of the UCM idea now. UCM is not something that will be coming in the Joomla 3.x or 4.x series and the code that we have in the system that references this right now is horrible. Thus this PR tries to remove the references to the UCM from the history feature of Joomla and remove what I consider a bad design decision.
What did I do?
I changed the name of the history table from #__ucm_history to #__history, dropped the ucm_type_id column and changed the ucm_item_id column 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.
Is this a good change?
Good question. This resulted from work on the tagging feature, which is absolutely horrible in its current state. Looking at tagging and history, both features can be very easily implemented without any special relation to the UCM concept and you can actually even simplify the code of both features. The benefit for the history feature is rather small and would only make sense if we also refactor tagging (which I'm striving to do next) and then dropping the whole UCM concept in 4.0, too. The UCM (base) concept how it is in Joomla right now is a complete failure and we should drop it asap. Maybe a UCM is a good idea, but it will not come in 3.x or 4.x and thus we should not forcibly push features to somehow connect to this in some way and make extension development more difficult.
Status
This PR is ready for testing. There are still a few things that feel strange, mainly pushing a ContentHistoryHelper object into the table object. Right now this is also to gather feedback. I already got one more critical response and would like to see if we can find a good solution in the end. A possibility would also be to add an interface that signals history-capabilities instead of relying on a magic attribute... In the end, this should make code easier for us and the feature easier to implement for component devs.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | SQL Administration com_admin com_content com_contenthistory Installation Layout Libraries Front End Plugins |
| Labels |
Added:
?
|
||
| Category | SQL Administration com_admin com_content com_contenthistory Installation Layout Libraries Front End Plugins | ⇒ | SQL Administration com_admin Postgresql com_content com_contenthistory Installation Layout Libraries Front End Plugins |
A possibility that @wilsonge explained to me that could be achieved with the ucm table and the new workflow would be the ability to preview content that was not the current published version. Currently for example if you have edit own permission and the content item has been published then you can make any changes you want to the content item without the need for approval. As explained to me by @wilsonge it would be possible now for the original version of the content item to remain published while a new version went through the workflow approval process. I would hate for that possibility to be lost by any changes here.
@brianteeman I wouldn't know how this change would prevent that. I don't think that whatever it is that we are nameing UCM would be involved in such a feature.
I was "programatically" adding some tags to a new Joomla website with thousands of articles and I was surprised to find out about this UCM stuff which made my job a lot more harder than in the old Joomla versions. UCM makes Joomla even more incredibly bloated than it already was. I used to alter even the old Joomla database tables because there were too many useless fields and to simplify the queries and now I meet this whole new UCM stuff which make the old Joomla versions look really light in comparison. I was really disappointed to find another big mostly useless stuff in Joomla and if I wasn't too advanced with my project, I would have definetly picked up another framework or downgraded to the latest UCM-free Joomla.
@dezea A UCM-free Joomla would be 2.5, which I think doesn't run on PHP7. Since tags and history are more or less the only things that have anything to do with UCM, I actually don't really understand your frustration here. As hopefully is apparent, UCM isn't really something that is liked or has lots of support. Since this is just about versioning and not tags and because the maintainers know all the arguments around UCM very well and are the ones that have to make the final decision on this, I would rather not devolve this into a flamewar about the cons of UCM, etc.
@Hackwar I think that for this type of stuff which can have quite a performance impact on large data sets, a switch toggle so the user can choose if he wants to use UCM or not should be a must. There will be extra php code, but that runs faster than the extra mysql queries required to store and retrieve data which I guess most people don't need/ignore.
| Category | SQL Administration com_admin com_content com_contenthistory Installation Layout Libraries Front End Plugins Postgresql | ⇒ | SQL Administration com_admin Postgresql com_categories com_content com_contenthistory Installation Layout Libraries Front End Plugins |
I've been thinking about the versioning further and if I'm doing the changes that I did, I might as well do it right. I hope that this is now easier to understand, better to maintain and more flexible.
To make a standard component like com_content keep a history of its content items, you now have to do the following:
- On your item controller, use the VersionableControllerTrait
- On your item model, use the VersionableModelTrait
- On your items table, implement the VersionableTableInterface
- Add the versions button to your item edit view
- Add the obscure data that you have to add to the contenttypes table
- Add the component parameters to your component
Most of the logic has moved to the versionable behavior plugin. To enable the feature, the main important part is the VersionableTableInterface. That is what controls if the behavior plugin reacts on that table object or not. For data handling, there is the Versioning class (formerly ContentHistoryHelper) in the background. While a lot of logic was mixed in this class, this has now been separated into the "right" places and this class is only meant to do get, store and delete.
The changes here provide an easy way to implement the versioning in a standard component. More complex components can override that behavior in several ways, by not using the different classes and ultimately only use the Versioning class directly to store their data. They can then use the com_contenthistory component to display differences and restore old versions.
I consider this an improvement, but also not really finished. We need to find solutions for the contenttypes data that I hinted at above. I have no idea what needs to be set in that table and all that. That is not really obvious to the casual developer and we have to improve on that. We also should look into com_contenthistory further to support more complex data structures and improve on the comparison function. I also did not apply this new system to all the existing components.
Waddaya think?
The point that I wanted to make above is: The versioning thus isn't tied directly to a table object.
| Category | SQL Administration com_admin com_content com_contenthistory Installation Layout Libraries Front End Plugins Postgresql com_categories | ⇒ | SQL Administration com_admin Postgresql com_banners com_categories com_contact com_content com_contenthistory com_newsfeeds com_tags com_users |
I've added the code for the rest of the components.
My biggest question here would be the migration path. Can a 3rd party extension support both ways (old and new) or does Joomla (3.10 or 4.x) support both ways? One of the two ways (preferrably the latter) must be possible.
I would strongly suggest to not support the old system in 4.0. With quite some effort, we could backport the new classes to 3.10, so that you can switch this over in 3.10 and not do this in 4.0.
As said, either way has to work.
Otherwise you face a hard B/C break which to my knowledge we managed to prevent so far.
BTW: In the VersionableTableInterface I'm defining a getTypeAlias() method. This could also be used for other similar features like tagging. I would still keep this in this interface and then create a similar interface for tagging later on with the same signature. I don't want to simply rely on these magic attributes and all that stuff. In the previous comment I listed 6 steps which you have to take to add versioning to your component. If we find a solution for that fifth step, the total documentation wouldn't be a lot longer than this for this feature and as a developer you should be able to understand how all of this fits together. I can't say the same about the current system, both in terms of code and documentation.
@Bakual A solution to run the same code on both versions would be to backport the VersionableTableInterface and empty traits to 3.10. As a component developer you would then already let your table class implement that interface and use those empty traits in your model and controller. In 3.10, it would still use the old code and behavior and whatnot and in 4.0, it would automatically move over to the new system. Would that be acceptable?
HI.
I don't know if it's the right place to write it but the great new workflow component should integrate or at least communicate with the updated or refactored versioning system.
We should be able at least to control who is allowed to see and edit versions which is not the case right now. From a publishing point of view versionning is connected to the workflow.
thanks
I'm open for everything, but for now I'd rather have this approved for now and then we still can improve this later, especially with the traits now in place.
OK, should I open an issue then ?
Feel free to do so.
I fear that this will have to be deferred to 5.0, but I don't want to close this simply, mostly because then it would be forgotten... Please keep this open.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-04-01 18:33:49 |
| Closed_By | ⇒ | wilsonge |
I updated this PR and did a few fixes, so this would be ready for testing. A point of criticism was, that I joined 2 numeric keys into a text key. However I think it is easier to read and I doubt a bit that it makes a difference in terms of performance for the lookup. Most importantly though, there is no point in time where we are going to read anything else than a direct key match. The history feature does not require that we retrieve all versions of a component, but always just the versions for a component item.