User tests: Successful: Unsuccessful:
The compare view of the versions shows for categories not the id, it shows the name. This is possible because we have a lookup table definition. This PR add the definition for tags so that we can show tag names instead of tag ids.
This is not easy to test fully:
XOR
However you did it, after it you must create some versions of (articles, contact, something that has tags and versioning)
| Status | New | ⇒ | Pending |
| Category | ⇒ | SQL Administration com_admin Postgresql |
| Title |
|
||||||
| Title |
|
||||||
| Labels |
Added:
PR-6.0-dev
|
||
It seems the information added here with an update SQL is also missing for new installations in files installation/sql/<db type>/supports.sql, or am I missing something?
| Category | SQL Administration com_admin Postgresql | ⇒ | SQL Administration com_admin Postgresql Installation |
I have tested this item ✅ successfully on 00a02f2
I've tested updating from 5.4-dev to the custom update URL of this PR with MySQL and PostgreSQL, and I've also tested new installation with both database types.
The PR does what it shall do.
On PostgreSQL there is an issue with a wrong unique index for which I will make soon a PR.
But that's not related to this PR or the changes in 6.0-dev in general.
Hint for other testers:
If you check the content_history_options values on the #__content_types before and after an update to this PR, you will see that there are more differences than just the new element being added to the displayLookup array.
The ordering of the properties of the objects in that array will change, especially on MySQL or MariaDB, and also the odering of other properties in the content_history_options, and the double backslashes in the formFile property will be changed to single backslashes.
The reason for that is the json normalisation which is made by the json functions used in the update SQL script.
This makes the comparison harder, but the changes are ok. The order of properties in json objects doesn't matter, and the double backslashes in strings which refer to paths are also not really needed.
@brianteeman Could you test this one here?
If you delete a tag in the tags component then its not recreated when you restore a previous version of the article that has that tag but I suppose thats to be expected
I have tested this item ✅ successfully on 00a02f2
If you delete a tag in the tags component then its not recreated when you restore a previous version of the article that has that tag but I suppose thats to be expected
@brianteeman Good find, and I would also assume it is expected.
| Status | Pending | ⇒ | Ready to Commit |
RTC
| Labels |
Added:
RTC
|
||
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2025-10-11 13:01:38 |
| Closed_By | ⇒ | Bodge-IT |
Thank you for you time on this @rdeutz and thanks to @brianteeman and @richard67 for tests
Does this also work for 3rd party extensions?