What happened?

Every time an article with at least one tag is saved, a new row is inserted into #__ucm_content instead of updating the existing one. Articles that have never had a tag assigned never get any row at all in #__ucm_content. Over time, this leaves dozens of orphaned rows per article, causing an unbounded database data leak.

Version

5.4

Expected result

Only a single entry should be updated or maintained in the #__ucm_content table for that specific article ID and type alias. Repeatedly saving an article should not accumulate duplicate rows.

Actual result

An unbounded data leak occurs. On every single save cycle, a brand new duplicate row with a new core_content_id is inserted into #__ucm_content while the deprecated #__ucm_base table remains empty.

System Information

• Joomla! Version: 5.4.8
• PHP Version: 8.2.4
• Database: MySQL (Local dev)
• Web Server: Apache

Additional Comments

Root cause found (traced via MySQL general query log during a live save)

libraries/src/Helper/TagsHelper.php::postStoreProcess() (marked @deprecated 5.3 will be removed in 7.0) looks up the existing core_content_id via:

\(query =\)db->getQuery(true)
    ->select(\$db->quoteName('ucm_id'))
    ->from(\$db->quoteName('#__ucm_base'))
    ->where([...]);
\$primaryId = \(db->loadResult();\)result = \(coreContentTable->load(\)primaryId);

However, libraries/src/Table/CoreContent.php::storeUcmBase() — the method responsible for keeping #__ucm_base populated — is also marked @deprecated 5.4.0 will be removed in 7.0 without replacement, and is never called from CoreContent::store() anymore. So #__ucm_base never receives new rows, postStoreProcess() always fails to find a matching ucm_id, $coreContentTable->load(null) resets to a fresh record, and the next store() call performs an INSERT instead of an UPDATE.

Impact

• Table bloat in #__ucm_content (in our case, 76 of 429 articles had 2–20 duplicate rows each after normal editorial use over ~1.5 years).
• Tag associations still resolve correctly against the most recent row, so it's not user-facing today, but it's an unbounded data leak.

Suggested fix direction

Since both deprecated methods are slated for removal in 7.0 "without replacement," it would help to know whether the intended replacement mechanism (post-UCM) already avoids this duplication, or whether postStoreProcess() should stop relying on #__ucm_base in the interim (e.g., look up the existing row directly via core_content_item_id + core_type_alias on #__ucm_content instead of the now-dead #__ucm_base index).

Happy to provide the full query log capture if useful.