Revert "Performance gain - new featured article"

[rdeutz]

PR for issue #11103

Summery of Changes

The PLT decided to revert #8576 because it is a B/C break

Testing instructions

• Apply patch
• You need a category view with articles
• Set the the secondary ordering in Articles options to „Ordering“
• Set the the secondary ordering for the menu to „Use Global“
• Create a new Article

Expected result

The new Article should be listed first in the frontend category view

[alikon]

I have tested this item ✅ successfully on ca43296

despite the loss of perfomance ;)

---

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

[ggppdk]

The Joomla release that will have this revert,

• should also include (if possible) a JTable::reorder performance fix

#11184

[alikon]

@ggppdk i'll look at #11184 more deep after the end of GSoC....
but reordering all artcicle after adding a new article is not performant by design

[Sieger66]

I have tested this item ✅ successfully on ca43296

also testet with Isis and Hathor Administrator-Template and Sticky-Ordering(negative Ordering Numbers).

---

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

[zero-24]

RTC. Thanks

---

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

[jeckodevelopment]

I have tested this item ✅ successfully on ca43296

---

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

[VasyaV01]

I have tested successfully.

[tgv604]

Tested successfully;

For the sake of performance I'd suggest shifting the ordering field instead of reordering:
UPDATE #__content SET ordering = ordering + 1 [WHERE catid = N]

Basically, the same outcome in one query instead of many.

[ggppdk]

That can be an enhancement, have thought of it, but after executing

UPDATE #__content SET ordering = ordering + 1 [WHERE catid = N]

you still need to check for unique ordering, as existing orderings (for the given category) are not guaranteed to be unique

[tgv604]

Well, here's the proper renumbering then:

UPDATE #__content AS c,
    (SELECT @rownum := @rownum + 1 AS rownum, p.id
    FROM #__content AS p, (SELECT @rownum := 0) AS r
    [WHERE p.catid = N]
    ORDER BY p.ordering ASC) AS g 
SET c.ordering = g.rownum
WHERE c.id = g.id

[ggppdk]

Similar has been proposed already, it does not work on ALL DBs, (only MySQL ?)
and there was an argument not to use DB specific code

[ggppdk]

Here it is:
#8563

[tgv604]

Whatever, I'm implementing this for myself.

[ggppdk]

@tgv604

Personally,
I am in favour of accepting the MySQL specific optimizations !

I think both #8563 and #11184 should be accepted

[jeckodevelopment]

@tgv604 and @ggppdk
this PR has been already merged, if you have further ideas about optimisation, you should open a new PR.

[mbabker]

As long as Joomla claims to support multiple database engines, accepting patches which penalize users of a certain platform with slower performance should not be acceptable. That's why I argue against switch conditionals for different queries based on the engine. Some exceptions apply, and those are pretty much all already in the code base (like the driver specific subclasses for the Smart Search indexer).

[ronaldhoek]

Tested this fix with latest official release 3.6.2 and the order of newly created articles is correct again.
Don't see any perfomanc issues for myself.

[matrix630307]

Tested with 3.6.2 and work's fine.

[matrix630307]

i hope, this change will come in short time. it is very strange with our clients for this problem!

[wilsonge]

This has already been merged and as you know we have the 3.6.3 release candidate out now. So this will come out next Tuesday

[matrix630307]

thank you - yes, i have see the message from flow... happy!