[5.4] Fix storing data in #__ucm_base

[Hackwar]

Pull Request resolves #47609.

• I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.

Summary of Changes

The PR #44910 deprecated the UCM code, but broke storing the data in the #__ucm_base table. This PR reverts this change and fixes the problem.

Testing Instructions

Create an article and assign a tag to it. Click on save, wait for the page to reload and click on save again.

Actual result BEFORE applying this Pull Request

In the #__ucm_content table, for each click on save, a new entry is created in the table. No entry for the item is generated in #__ucm_base.

Expected result AFTER applying this Pull Request

An entry is created in #__ucm_base for the item and the corresponding entry in #__ucm_content is only updated, no duplicates are created.

Link to documentations

Please select:

• Documentation link for guide.joomla.org:

• No documentation changes for guide.joomla.org needed

• Pull Request link for manual.joomla.org:

• No documentation changes for manual.joomla.org needed

[krishnagandhicode]

I have tested this item ✅ successfully on 8c07a71

Before patch :

After patch:

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47664.}

[CSGoat0]

I have tested this item ✅ successfully on 8c07a71.
I have screenshots I will provide in a different comment because I cannot upload them on the tracker as I have 2 issues when I try to upload them:

1- the opacity is set to 0, I could solve that.
2- when clicking Start upload I get this error: Error Empty file upload result. Unfortunately, I couldn't solve that.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47664.}

[CSGoat0]

-----------------------------------------------

ucm_id stopped at 7.

[CSGoat0]

I have tested this item ✅ successfully on 8c07a71

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47664.}

[sertlan]

Tested it successfully: no duplicates are created in ucm_content table after saving an article again, corresponding row is updated.

[BeginnerJoomlaCom]

@sertlan Please mark your test as successfully at https://issues.joomla.org/tracker/joomla-cms/47664

[krishnagandhicode]

@sertlan Please mark your test as successfully at https://issues.joomla.org/tracker/joomla-cms/47664

Well this PR already has 2 Successful human Tests using issue tracker which is enough to get it RTCed (some maintainer will add the RTC tag as soon as they look into this PR)

Well more testing is always good - but as @sertlan already reported it here about their Successful test - after 2 human Successful test via joomla issue tracker It's not really needed for them to mark it using Issue tracker.

Thanks.

[sertlan]

I have tested this item ✅ successfully on 8c07a71

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47664.}

[BeginnerJoomlaCom]

It's not really needed for them to mark it using Issue tracker

@krishnagandhicode please think also about less experienced users.

[richard67]

RTC

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47664.}

[sertlan]

Is it safe to delete duplicates in ucm_content table with this SQL query?

DELETE FROM `[prefix]_ucm_content` 
WHERE core_type_alias = 'com_content.article' 
AND core_content_id NOT IN (
    SELECT max_id FROM (
        SELECT MAX(core_content_id) as max_id 
        FROM `[prefix]_ucm_content` 
        WHERE core_type_alias = 'com_content.article' 
        GROUP BY core_content_item_id
    ) as tmp
);

[richard67]

Is it safe to delete duplicates in ucm_content table with this SQL query?

DELETE FROM `[prefix]_ucm_content` 
WHERE core_type_alias = 'com_content.article' 
AND core_content_id NOT IN (
    SELECT max_id FROM (
        SELECT MAX(core_content_id) as max_id 
        FROM `[prefix]_ucm_content` 
        WHERE core_type_alias = 'com_content.article' 
        GROUP BY core_content_item_id
    ) as tmp
);

No. The query is wrong. On MySQL 8 in strict mode you will get an SQL error because you are using a group by but the column by which you are grouping is not part of the select statement.

[sertlan]

No. The query is wrong. On MySQL 8 in strict mode you will get an SQL error

For me (MariaDB 10.6.17) this SQL query works.

But is it safe to delete duplicates in ucm_content table?

[richard67]

No. The query is wrong. On MySQL 8 in strict mode you will get an SQL error

For me (MariaDB 10.6.17) this SQL query works.

As said, try it on MySQL 8 or PostgreSQL and you will get an SQL error.

[muhme]

I have tested this item 🔴 unsuccessfully on 779a9ca

Starting final test before merge using JBT

• Tested with MariaDB 11.8.6
• Before the PR
  • If a tag is assigned to an article, only one ucm_content entry is created
  • Every time an article is saved, another duplicate ucm_content entry is created
• After applying PR with Patch Tester
  • One ucm_base and one ucm_content entry is created for assigning a tag
  • No duplicate entries anymore on editing the article
  • When the tag assignment is deleted, the ucm_content entry is also deleted; the ucm_base entry remains
  • ❌ Trying to assign the tag a second time silently fails, article is saved, but the tag is missing
    • This may be related to the ucm_base entry, if this is deleted manually, the article tag assignment is working again

      ---

      _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47664.}

[muhme]

back to pending

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47664.}

[sertlan]

When the tag assignment is deleted, the ucm_content entry is also deleted; the ucm_base entry remains
Trying to assign the tag a second time silently fails, article is saved, but the tag is missing
This may be related to the ucm_base entry, if this is deleted manually, the article tag assignment is working again

Tested it. Unfortunately, it is.