[#43669] - Incorrect UCM Asset Tracking
- New
- Medium
- Build: 4.4-dev
- # 43669
Steps to reproduce the issue
- Create Joomla article
- Add Tag
Expected result
- A) New row (e.g. id 43) in database table
#__assetswith namecom_content.article.X(X = id of article) created. - B) New row (e.g. id 44) in database table
#__assetswith name#__ucm_content.X(X = id of article) created. - C) In database table
#__contenta new row withidX (article id) is created andasset_idhas row value of A (e.g. id 43) - D) In database table
#__ucm_contenta new row withcore_content_idX (article ID) is created andasset_idhas row value of B (e.g. id 44)
Actual result
- A) New row (e.g. id 43) in database table
#__assetswith namecom_content.article.X(X = id of article) created. - B) New row (e.g. id 44) in database table
#__assetswith name#__ucm_content.X(X = id of article) created. - C) In database table
#__contenta new row withidX (article id) is created andasset_idhas row value of A (e.g. id 43) - D) In database table
#__ucm_contenta new row withcore_content_idX (article ID) is created andasset_idhas row value of A (e.g. id 43)
So the new row in #__content and #__ucm_content both link to the same asset_id and the #__ucm_content.X asset has no relation in other tables. This is not correct.
Additional comments
This behavior is introduced with PR #39165 which sets the flag $this->_trackAssets = false; for the UCM content table. This indeed reduces useless assets rows. However this change did not take into account the fact that a new UCM content row is created when tags are added.
The incorrect asset_id store is also mentioned in the comment of the PR: #39165 (comment)
As long as data is created in the #__ucm_content the $this->_trackAssets = false; should be removed. Or the asset_id in #__ucm_content should not be set at all and the column can be removed as the asset for #__ucm_content does nothing.
joomla-cms-bot
- | Labels |
Added:
No Code Attached Yet
|
||
rdeutz
- | Labels |
Added:
bug
|
||
I also tested this just now in Joomla 6.0 and can't replicate it.
Create article
- New database row in
#__contentis created withidA andasset_idB - New database row in
#__assetsis created withidB and namecom_content.article.A
So direct relation between content and asset.
All good.
Create article with a new tag
- New database row in
#__contentis created withidA andasset_idB - New database row in
#__assetsis created withidB and namecom_content.article.A - New database row in
#__ucm_contentis created withasset_idB
In this situation we have row in #__content and #__ucm_content with the same value B for asset_id, so referring to the same asset row in #__assets. However, the asset name refers to the article, not the ucm_content.
Create article with a new tag, with _trackAssets (old behavior)
Restore the old behavior by changing public_html/libraries/src/Table/CoreContent.php , modify $this->_trackAssets = false into $this->_trackAssets = true
- New database row in
#__contentis created withidA andasset_idB - New database row in
#__assetsis created withidB and namecom_content.article.A - New database row in
#__ucm_contentis created withasset_idC - New database row in
#__assetsis created withidD and name#__ucm_content.C
In this situation we have two new assets rows, one for the content and one for the ucm_content. Each with their own direct relation between content and asset.
So since $this->_trackAssets is set to false the ucm_content rows refers to the asset_id of the article (as no "own" asset is created).
While I agree tracking assets for ucm_content only clutters the assets table, the ucm_content created should not be linked to a content asset ID. Instead the asset_id should not be set as there is no asset linked.
Ok, I understand what you mean, but I disagree with you here. In the end, the whole ucm table is supposed to be removed soon, so I wouldn't change this anymore...
The issue was not created just yet 😉 Removing ucm is very nice, for when is this scheduled?
It also won't solve it for existing sites with corrupted data at the moment.
I would have loved to have removed this in 6.0, but the decision was made against this. Now probably in 7.0.
I am struggling to replicate this in joomla 6 @sanderpotjer