Fix the ordering of articles and featured #11139

csthomas · 2016-07-15T02:14:08Z

Pull Request for Issue #11103.

Summary of Changes

Fix the ordering of articles and do not loose performance.

Notice:
I do not know does 2147483647 is good number to be max of ordering field (look at code) across all database types?

Testing Instructions

[UPDATED]

Download and Install Joomla 3.6.0 with sample data "test", "testing" or something like that
Install com_patchtester.zip latest stable version
On backend go to Menu -> All Front End Views -> Featured Articles
In layout search for "Category Order" and change to "No Order". Article Order should be set to "Featured Article Order"
Go to /index.php/featured-articles
Back to backend and add a new article with title "Featured 1".
Set it as featured. Category could be "Uncategorised"
Go to /administrator/index.php?option=com_content&view=featured
Change select box "Sort Table by:" to "Ordering ascending"
Your new added article "Featured 1" should be at the bottom
Go to /index.php/featured-articles and try to find your article "Featured 1", should at the end
Go to /administrator/index.php?option=com_patchtester
Fetch Data
Search for "Fix the ordering of articles and featured"
Apply Patch 11139
Add next article with title "Featured 2", set as featured. Category could be "Uncategorised"
Go to /administrator/index.php?option=com_content&view=featured
Sort Table by should be "Ordering ascending"
Now "Featured 2" is on the top and "Featured 1" is the last one.
Go to /index.php/featured-articles and try to find your article "Featured 2", should at the top
Go back to /administrator/index.php?option=com_content&view=featured and reorder "Featured 1" to the first place.
Go to /index.php/featured-articles and "Featured 1" and "Featured 2" should at the top.
You can do a few more detailed test if you like to.

killoltailored · 2016-07-15T04:22:00Z

I have tested in Joomla 3.6.0 and I have follow below steps to test article ordering

First created a menu item Category List and assigned article category to it.
Then added all articles in assigned article category.
I have used drag-drop ordering functionality and changed ordering of articles but not able to see articles in proper order at front-end side.
Without applying PR created article and I can see it at the top of the article list at front end side.
With PR having same result, created new article and I can see at the top of the list.

Please correct me if doing anything wrong and provide more information to test the PR.

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

ggppdk · 2016-07-15T07:19:39Z

libraries/joomla/table/table.php

@@ -1348,14 +1386,26 @@ public function reorder($where = '')
 			throw new UnexpectedValueException(sprintf('%s does not support ordering.', get_class($this)));
 		}

+		if (in_array($this->_tbl, array('#__content', '#__content_frontpage'), true))
+		{
+			// Use big numbers only for important tables


Why have different treating for some tables ? The purpose is to fix the B/C ordering break in all tables

Because ordering number of content and frontpage on backend is not visible for users.

For test.

Go to backend module list.

Edit some module.

For modules ordering you will see number, like 1,2,3,4 in select box of ordering field.

Then replace:

if (in_array($this->_tbl, array('#__content', '#__content_frontpage'), true))

to ex:

if (1 || in_array($this->_tbl, array('#__content', '#__content_frontpage'), true))

After that go back to module list an change sorting/edit some. After ordering get big numbers you can edit module again and check ordering field.

I think that people do not want to see big numbers:)
Off course we can set some offset before display to user, but is it not too complicated?

This is why we have subclasses. JTable is supposed to be a generic class for all tables. If you need table specific behaviors they need to be in those subclasses.

I can use subclasses JTableContent, ContentTableFeatured, and ..., but I have to duplicate code for that.

May be better is to create a new method JTable::reorder_alternative($where='') and then only add to JTableContent class and others:

public function reorder($where = '') { return parent::reorder_alternative($where); }

Hello Team.
Thanks to all.
Thanks @csthomas for this: #11139 (comment)
Manually work fine and follow your detailed aswer too.
3.6.1 + Patch
Now the Joomla be fast and furious !

csthomas · 2016-07-15T09:10:43Z

@killoltailored I updated instruction. You have to use ex. Article Order in category/menu item/modules.

csthomas · 2016-07-15T10:27:52Z

I can add parameter (but better add it only in the next PR):

public function reorder($where = '', $use_big_numbers=false)

and then use it as:

if ($use_big_numbers || in_array($this->_tbl, array('#__content', '#__content_frontpage'), true))

or do it in the most right way and replace it by:

if ($use_big_numbers)

Then there maybe more changes in inheritance class. (need to add additional parameter too)

mbabker · 2016-07-15T13:23:02Z

There aren't overrides of the reorder methods necessarily, but there is a JTableContent and ContentTableFeatured subclass specific for these two tables.

And without understanding the issue or if said parameter/behavior is multi-database compliant (remember Joomla is still playing the charade of supporting non-MySQL engines), I'm not commenting further on behaviors.

csthomas · 2016-07-15T13:50:45Z

There aren't overrides of the reorder methods necessarily, but there is a JTableContent and ContentTableFeatured subclass specific for these two tables.

This is good point. I will wait for more comments.

csthomas · 2016-07-18T22:25:11Z

Please take a look how it works in others models:

For others models ordering is set to 0 and is not reordered on adding.
For ex. create a new module.

If that patch should work without exceptions then above files (banner, contact, newsfeed) have to change way of adding a new item.

ggppdk · 2016-07-18T22:42:40Z

Here is an alternative:
#11184

We can

fix performance of JTable::reorder
revert the B/C break in ordering
and continue to use ordering from 0 and higher

ggppdk · 2016-07-18T22:43:27Z

And forgot to say , should work in all database servers ? someone please confirm for sqlazure

ghost · 2016-07-19T00:42:49Z

Please see test #11139 (comment)
Made a mistake here.

I have tested this item 🔴 unsuccessfully on 9a95809

What I've done.
Current staging.
Added into HEAD of ISIS index.php to see ordering values in articles list.

<style>
body  .text-area-order {
  display: inline !important;
}
</style>

1 category / 1088 articles.
Lowest ordering -24 (set by a plugin and/or override that uses old fashioned ordering or similiar).
Several articles with different ordering < 0.
Several articles with ordering 0.
Several articles with ordering from 1 to 11.

Without patch:

Added new article aaaaa.
Gets ordering 12.
Other orderings unchanged.

With patch:

Added new article bbbb.
All orderings < 0 stay unchanged.
New article gets ordering 2147482318. Whyever.
~~ALL(!!) OTHER orderings get 2147482318, too. Whyever.~~

~~From my point of view this is a fatal break of B/C while behavior before patch is a more or less acceptable break of B/C.~~
And these ordering numbers are completely intransparent. EDIT: If you don't use Drag&Drop feature but old fashioned ordering in a component.

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

ghost · 2016-07-19T01:36:48Z

I have tested this item ✅ successfully on 9a95809

@csthomas

Sorry! Made a mistake while previous test : #11139 (comment)

That's wrong there:
ALL(!!) OTHER orderings get 2147482318, too. Whyever.

Correct:
ALL OTHER orderings are > 2147482318 (1-stepwise).

But I still don't like these high ordering values ;-) .

csthomas · 2016-07-19T08:37:31Z

But I still don't like these high ordering values ;-) .
Yes it is a problem with that.

Review of solutions:

Work with reversed ordering - example of changes #11134 (currently closed) - I want to see that solution (now incomplete) on Joomla 4:

the best performance
not require reorder on each new row
break B/C for all tables except: banner, contact, newsfeed
new row always have to get ordering=max+1
require script to reorder almost all tables (which use ordering column) in user database before applied

Current PR is:

good for performance - second place,
not require reorder on each new row
almost B/C (we can not use that sort for banner, contact, newsfeed because they use max + 1 for new row)
tables with applied big ordering values always have to get ordering=min-1
worse looks for users - high ordering values

Reorder tables with single SQL query (all DBs compatible), greatly improving reorder performance #11184

good performance - third place
require reorder on each new row
full B/C
new row may get ordering=0 or ordering=max+1

back to 3.5.1 solution but surround queries loop with transaction start and commit

performance should be better than on joomla 3.5.1 but worse from above
require reorder on each new row
full B/C
new row may get ordering=0 or ordering=max+1

ghost · 2016-07-19T13:37:04Z

new row may get ordering=0 or ordering=max+1

Why not ordering=min-1 for new entries?
Ordering is a signed field. Negative values are allowed.

And only reorder table starting at 0 when field size needs it.

csthomas · 2016-07-19T13:56:10Z

Yes this also can be an option but:

negative values are treated as reserved, row with ordering=-1 is not reordered, check joomla code
personally I can change my PR to use negative values but I'm worry that somebody may be against.
I have to think about it more. Mean time I can wait for more comments.

ggppdk · 2016-07-19T15:50:07Z

Negative ordering number are sticky orderings , not subject to reordering, this is an existing feature, if we want to break, or remove this feature then it will break more sites

Now about Reorder tables with single SQL query (all DBs compatible), greatly improving reorder performance #11184

@csthomas
as you say it does not have to trigger a re-ordering on every save

it can start re-ordering at e.g 100 and thus reordering is triggered rarely and for extensions that display the ordering number it will be more user friendly

also about my PR #11184,
the SQL update cost will be very small , the cost when having e.g. 2000 records to reorder will be

PHP loop that retrieves the records inside

$rows = $this->_db->loadObjectList();

and then the PHP loop that create the update SQL query, as i would like to avoid function calls e.g.

$pk = $pk_is_int ? $row->$keyname : $this->_db->quote($row->$keyname);

as the above despite being very little cost it executed for every record

The SQL query itself will cost / should cost a lot less than the above !
and in any case SQL cost should be reduced by 99.5%-99.9% when re-ordering 2,000 records

csthomas · 2016-07-19T17:19:12Z

I'm fun of solution 1) from comment above #11139 (comment)
but it breaks B/C everywhere then maybe I have to wait for accepting that to Joomla 4.

Your solution Georgios is good, your PR does not have problems with big values,
performance is better because it use only a few query,
but

a) For content_frontpage:
My client has table #__content_frontpage with 174678 total rows.
All tables that use ordering when adding a new row is usual fast, except big one #__content_frontpage, and less #__content.

~~I see some solution: maybe use your PR or other and then:~~
~~- remove content_frontpage table from database.~~

~~#__content_frontpage.ordering move to #__content.featured column which only use 0 or 1 but can have NULL or ordering value from frontpage.~~

b) Using reorder after add a new row is weird but we may have no choice.

Why I want to remove any re-reordering when adding a new row?

[Please check my below words. I may be wrong.]

How does replication of data work in mysql myisam (usually)?

In short: it transfer every query to slave database. (not too much size)

How does replication of data work in mysql innodb?

In short: it transfer piece of changed data to slave database. (could be a lots of KB or MB)

On joomla 3.5.1, for table #__content_frontpage on each adding a new featured article, it probably transfer all or half size of the table.

Replication data for joomla is hard.
A few month ago I disabled it and now I'm not used it but I still remember this problem.

Back to your comments:

Negative ordering number are sticky orderings , not subject to reordering, this is an existing feature, if we want to break, or remove this feature then it will break more sites

Then we can not use that

it can start re-ordering at e.g 100 and thus reordering is triggered rarely and for extensions that display the ordering number it will be more user friendly

If I well understand you want to have a buffer of [1-100] for new rows and I can add first 99 without reordering, next will be with re-ordering, and next 99 without, ....
Hmm, may be

the SQL update cost will be very small , the cost when having e.g. 2000 records to reorder will be

I'm maybe alone but my client has 174678 rows.

The best way will be to not load that rows and reorder it internal in database.
No one has found a solution for sqlazure and postgresql.

ggppdk · 2016-07-19T18:42:29Z

Arguably if you use MySQL max_packet_size of 4 Mbytes, instead of default 1 MB

you can update 200,000 records 1 query (i speak of the specific update query)

or with defaults settings in my PR, you will need 18 queries as it defaults to 10000 records per query

So after my PR the sql queries are no longer the problem

with so many records the PHP execution and PHP memory needed to handle so many records become very big (as it was before my PR)

even this is slow and needs a lot of memory because it will retrieve 174000 records

$rows = $this->_db->loadObjectList();

ggppdk · 2016-07-19T19:07:24Z

@csthomas

I am not against this PR i will test this PR,

And if this PR is accepted

then i will remake my PR to be able to update all needed records in single query in reorder method

The part of my PR that uses single query for updating multiple records is an improvement that can and should be added anyway to the reorder method , (of course then my new PR will not touch article.php)

so i say let's test this PR first, it seems good !

csthomas · 2016-07-19T20:47:40Z

To get the best performance with B/C we can join our patches as you said.

If PLT guys can agree with me about change/reverse ordering in the future joomla 4 and always use max+1 for a new row - this break B/C (example from #11134 applied on current 3.6).
Then I will close my PR and will accept your only.

If joomla not planing to use above in the future then we could join our patches.

If only your will be merged then privately I will still use my current below patch (mysql only).

diff --git a/libraries/joomla/table/table.php b/libraries/joomla/table/table.php
index 121dbf2..c317bb0 100644
--- a/libraries/joomla/table/table.php
+++ b/libraries/joomla/table/table.php
@@ -1378,6 +1378,36 @@ abstract class JTable extends JObject implements JObservableInterface, JTableInt
                        throw new UnexpectedValueException(sprintf('%s does not support ordering.', get_class($this)));
                }

+               /* Speed up patch for mysql - start */
+               if (in_array($this->_tbl, ['#__content', '#__content_frontpage'], true))
+               {
+                       $select = 'SELECT @a := @a - 1 FROM (SELECT @a := 2147483647)';
+                       $dir = 'DESC';
+               }
+               else
+               {
+                       $select = 'SELECT @a := @a + 1 FROM (SELECT @a := 0)';
+                       $dir = 'ASC';
+               }
+
+               $query = $this->_db->getQuery(true)
+                       ->update($this->_tbl)
+                       ->set('ordering = (' . $select . ' s)')
+                       ->where('ordering >= 0')
+                       ->order("ordering $dir");
+
+               // Setup the extra where and ordering clause data.
+               if ($where)
+               {
+                       $query->where($where);
+               }
+
+               $this->_db->setQuery($query);
+               $this->_db->execute();
+
+               return true;
+               /* Speed up patch for mysql - end */
+
                $k = $this->_tbl_key;

                // Get the primary keys and ordering values for the selection.

ggppdk · 2016-07-19T21:01:48Z

I think test and accept this PR first

then apply a new PR for avoiding multiple queries in table reorder

(because JTable reorder performance improvement involves a new query that should be indepedently accepted and make sure it is good for ALL database cases)

csthomas · 2016-07-19T21:45:06Z

If others thing the same then should I change line?:

if (in_array($this->_tbl, array('#__content', '#__content_frontpage'), true))

and use subclasses JTableContent and ContentTableFeatured as suggested by @mbabker.
How to prevent the repetition of code of reoreder method?

mbabker · 2016-07-19T21:56:53Z

Unfortunately you can't cleanly. You either make a new method in JTable
which seems a bit awkward for a specialized alternative behavior, bump us
to PHP 5.4 and use traits, or accept the duplication in subclasses, which
there's already a bunch of in Joomla.

On Tuesday, July 19, 2016, Tomasz Narloch notifications@github.com wrote:

If others thing the same then should I change line:

if (in_array($this->_tbl, array('#__content', '#__content_frontpage'), true))

and use subclasses JTableContent and ContentTableFeatured as suggested by
@mbabker https://github.com/mbabker.
How to prevent the repetition of code of reoreder method?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11139 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfocVe0Q0rWh04KNnDN4Si5qACKVljks5qXUVkgaJpZM4JNBDj
.

csthomas · 2016-07-20T08:52:16Z

I want to apply one of two options:

add method reorder_alternative (you can suggest better name) to JTable and in subclasses add method:

    public function reorder($where = '')
    {
        return parent::reorder_alternative($where);
    }

add parameter to JTable::reorder like:

public function reorder($where = '', $alternative=false)

but this option has one drawback for subclasses that has defined reorder:

$ php -a
Interactive mode enabled

php > error_reporting(-1);
php > class JTable { function reorder($where='', $alternative = false) { return $where;}}
php > class JTableContent extends JTable { function reorder($where='') { return $where;}}
PHP Strict Standards:  Declaration of JTableContent::reorder() should be compatible with JTable::reorder($where = '', $alternative = false) in php shell code on line 1

Then I think I should take 1).
I do not want to duplicate the code too much because @ggppdk will have too many place to patch.
I can't bump you to PHP 5.4 because IMHO it should me merged in 3.6.1

ggppdk · 2016-07-20T09:16:00Z

libraries/joomla/table/table.php

+				{
+					$ordering = $i + 1;
+				}
+


Joomla PHP coding standards allow using

$ordering = $extra_order ? ($last - $i - 1) : ($i + 1);

parenthesis are for readabilty

Thanks, but if I choose reorder_alternative($where); then above won't be needed.

mbabker · 2016-07-20T12:08:28Z

We aren't creating a new global behavior though so I don't think it's necessarily important to create any form of "alternative" method in the base table class. We're talking about two tables here, you're going to have to live with a little code duplication for a bit. If it were applied to all tables it'd be another story but right now that's not the case. If you are determined to integrate this directly into the base reorder method then it must be done in a way that does not target specific table names (otherwise it is ONLY appropriate to place this in the table specific subclasses). Whether that be with method parameters or class variables is to be determined.

Nothing in the core dev strategy forbids adding new parameters to methods. Yes, it introduces strict standard warnings to subclasses which override the method, but that's a side effect of making changes. Otherwise by that argument you could say that the only way core could add parameters to methods is by introducing new methods which just creates API bloat. We aren't talking about a method defined in an interface so big deal if you slip a strict standard message into someone's code.

csthomas · 2016-07-20T12:31:24Z

Then I will add parameter to JTable::reorder like:

public function reorder($where = '', $alternative=false)

and I will remove hardcoded table names

then I will add to JTableContent and ContentTableFeatured method:

    public function reorder($where = '', $alternative=true)
    {
        return parent::reorder($where, $alternative);
    }

csthomas · 2016-08-01T22:39:32Z

I have added simpler and more detailed test instruction #11139 (comment)

Sieger66 · 2016-08-03T17:12:17Z

I have tested this item ✅ successfully on 1d2beb0

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

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

ggppdk · 2016-08-03T21:49:51Z

I have tested this item ✅ successfully on 1d2beb0

Works,

fixes B/C break (articles and featured articles get ordering number lower than existing = B/C fix)
does not** trigger re-orderings on new article creation
does not** trigger re-orderings on new article creation that are featured
no problems with drag and drop re-orderings

(**) re-ordering happens only once, the very first time that the new code is used (which is the expected behaviour)

Tested with isis and hathor,
article manager and featured manager

I did a code review too ! looks good
I am sorry for late testing !! this should have been in J3.6.1 , but too late now

(some people will be disappointed, ok i don't know how many have seen the B/C break in J3.6.0 regarding the orderings, but i guess with the release J3.6.1 even more people will notice)

After this is merged i will update my PR for JTable::reorder() performance

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

Sieger66 · 2016-08-04T10:56:59Z

(**) re-ordering happens only once, the very first time that the new code is used

and re-ordering happens if an feturead article drop to the end of the ordering (for example to the ordering-number: 2147483647 or 2147483646 )

ggppdk · 2016-08-04T12:24:49Z

and re-ordering happens if an feturead article drop to the end of the ordering (for example to the ordering-number: 2147483647 or 2147483646 )

yes of course,

but comment refers to re-ordering no-longer being triggered

at new article creation which before was re-ordering all items of the category or all featured items resulting in thousands of SQl update queries

and that is the purpose of using large ordering numbers

csthomas · 2016-08-04T17:50:05Z

Now we have enough tests success.
What milestone/tag should I write in code:

 * @since  3.6.1

What is required to RTC?

andrepereiradasilva · 2016-08-04T17:53:43Z

@since __DEPLOY_VERSION__

the __DEPLOY_VERSION__ string is replaced when the maintainers use bump.php script.

See https://github.com/joomla/joomla-cms/blob/staging/build/bump.php#L319

csthomas · 2016-08-05T07:21:21Z

Thanks to all of you for your help.

Can I ask for RTC?

rdeutz · 2016-08-07T10:01:33Z

I have tested this, it works and it does what is says it would do. I must say I don't like the patch only for one reason, the big numbers in ordering. I always thought that giving a new article max+1 as ordering would be the right thing to do and it feels as we are trying to fix the problem we got with fixing a problem. I don't have a solution yet but I would like to have some more time to think about it, so I will set this to needs review and bring it into the PLT for a discussion.

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

csthomas · 2016-08-07T17:43:36Z

My PR has only one advantage against #11475 or #11134: it is B/C.

If there will be a solution for B/C of above PRs (ordering=(max+1) then it will be more natural to use.

rdeutz · 2016-08-08T06:01:54Z

@csthomas #11475 was never meant to be a fix for the B/C break

csthomas · 2016-08-08T09:02:47Z

I know, your PR #11475 only add ability to sort/use on frontend reversed ordering and not change too much.

The problem as you know is different approach (for ordering) in <= 3.5.1 and >= 3.6.0 for articles and featured.

You want to help users who has 3.6 but who cares about users with 3.5.1 and older.

I think that you (PLT guys) should first decide which way we go:

new ordering=MAX+1 or "old ordering=0 with call reorder or this PR ordering=MIN-1

If you decide to go a new way then some conversion ordering (for J3.5.1 and lower) should be added.
Also there are a group of users who upgrade to J3.6 and now manually reorder new articles to first position.

rdeutz · 2016-08-09T07:48:32Z

What would you think about a "reverse ordering" button in the category manager? It would allow people to reverse the ordering, if needed and we could go with the simpler max+1 approach.

ggppdk · 2016-08-09T08:35:17Z

@rdeutz

That button will decrease the re-configuration labour a lot,
for all sites that now use "ordering"

and you are right it should be in category manager, because if you add it to article manager and it works on current page, it will make a mess

i see csthomas says:

If you decide to go a new way then some conversion ordering (for J3.5.1 and lower) should be added.

which i agree it would have been nice,
if it was even more automated, e.g. on new Joomla upgrade

all ordering number will get reversed without user action,
also the "order" parameters in all configuration places, become from "ordering" "reverse ordering"

but i think it will be much more work to do the above , and also a quite "tricky" and maybe a risk of breaking things ?

so i would vote to go for the button in category manager

rdeutz · 2016-08-09T10:21:15Z

ok, I will try to make a PR today

rdeutz · 2016-08-09T11:41:18Z

please check #11529, it is not a real fix for the B/C break but a way to go around it

Sieger66 · 2016-08-21T22:52:37Z

i see csthomas says:

Only minus is large numbers in ordering column (which J3.6 does not display now).

This is not correct because numbers in ordering column was also display in
Hathor-Admin-Template and for example Isis-Template-Override:
#11200 (comment)
and maybe other extensions(3rd party) who use the numbers in ordering column ??

csthomas · 2016-08-22T09:29:47Z

I admit this is a problem, it depends on template.
I only checked the default template.

If we want to display large numbers as more human (lower numbers) then changes in template may be needed, but that break B/C for 3rd party templates.

This PR does not have many followers and probably won't be merged.
Then we have to wait for J4 for reverse ordering and use MAX+1.

csthomas · 2016-08-22T09:38:49Z

Off course we can still work on #11184 which is full B/C.

rdeutz · 2016-08-22T20:20:01Z

Because we reverted #8576 this can be closed, thanks to all for working on this issue

csthomas · 2016-08-22T20:31:21Z

After joomla reverted #8576 then this PR does not fix the bug but still can fix performance problem.
How? Because that PR does not need to use reorder method on adding a new article.

If there is no followers then it can be closed.

ggppdk · 2016-08-22T21:02:27Z

I agree that this PR is useful regardless of reverting #8576

also this PR can be changed to reorder records starting at 100 instead of: 2147483644

thus re-order (on new records) will be triggered 1 every 100 new records (e.g. articles)
it will also be made display-friendly for the cases that the ordering number is displayed, as the main objection for this PR was the use of high numbers ?

it will good for performance to test and accept

both this PR and PR Reorder tables with single SQL query (all DBs compatible), greatly improving reorder performance #11184,

as the will both give performance benefits, that are needed regardless of reverting #8576

please re-open

csthomas · 2016-12-08T11:54:43Z

For everybody interested in improving performance of creating new articles I have prepared a next PR at #12839.

joomla-cms-bot added the PR-staging label Jul 15, 2016

csthomas mentioned this pull request Jul 15, 2016

New articles are created with last possible "ordering" #11103

Closed

ggppdk reviewed Jul 15, 2016
View reviewed changes

csthomas mentioned this pull request Jul 15, 2016

Work with reversed ordering - example of changes #11134

Closed

ghost mentioned this pull request Jul 19, 2016

Reorder tables with single SQL query (all DBs compatible), greatly improving reorder performance #11184

Closed

ggppdk reviewed Jul 20, 2016
View reviewed changes

csthomas force-pushed the fixorder2 branch from befa5b6 to c5fdca1 Compare August 5, 2016 07:10

ggppdk mentioned this pull request Aug 5, 2016

Reverse ordering #11475

Merged

csthomas mentioned this pull request Aug 10, 2016

add flip ordering batch process to category manager #11529

Merged

Sieger66 mentioned this pull request Aug 10, 2016

Articles Not Showing Up Since 3.6.0 Upgrade, Still Broken Under 3.6.2 #11536

Closed

Fix the ordering of articles and featured

f40d445

csthomas force-pushed the fixorder2 branch from c5fdca1 to f40d445 Compare August 15, 2016 23:23

rdeutz closed this Aug 22, 2016

Fix the ordering of articles and featured #11139

Fix the ordering of articles and featured #11139

Conversation

csthomas commented Jul 15, 2016 • edited by rdeutz

Summary of Changes

Testing Instructions

killoltailored commented Jul 15, 2016

ggppdk Jul 15, 2016

Choose a reason for hiding this comment

csthomas Jul 15, 2016 • edited

Choose a reason for hiding this comment

mbabker Jul 15, 2016

Choose a reason for hiding this comment

csthomas Jul 15, 2016

Choose a reason for hiding this comment

xupacabra Aug 4, 2016

Choose a reason for hiding this comment

csthomas commented Jul 15, 2016

csthomas commented Jul 15, 2016

mbabker commented Jul 15, 2016

csthomas commented Jul 15, 2016

csthomas commented Jul 18, 2016

ggppdk commented Jul 18, 2016

ggppdk commented Jul 18, 2016

ghost commented Jul 19, 2016 • edited by ghost

Without patch:

With patch:

ghost commented Jul 19, 2016 • edited by ghost

csthomas commented Jul 19, 2016

ghost commented Jul 19, 2016

csthomas commented Jul 19, 2016 • edited

ggppdk commented Jul 19, 2016 • edited

csthomas commented Jul 19, 2016 • edited

ggppdk commented Jul 19, 2016 • edited

ggppdk commented Jul 19, 2016 • edited

csthomas commented Jul 19, 2016

ggppdk commented Jul 19, 2016

csthomas commented Jul 19, 2016 • edited

mbabker commented Jul 19, 2016

csthomas commented Jul 20, 2016 • edited

ggppdk Jul 20, 2016

Choose a reason for hiding this comment

csthomas Jul 20, 2016

Choose a reason for hiding this comment

mbabker commented Jul 20, 2016

csthomas commented Jul 20, 2016

csthomas commented Aug 1, 2016

Sieger66 commented Aug 3, 2016 • edited

ggppdk commented Aug 3, 2016 • edited

Sieger66 commented Aug 4, 2016 • edited

ggppdk commented Aug 4, 2016

csthomas commented Aug 4, 2016

andrepereiradasilva commented Aug 4, 2016 • edited

csthomas commented Aug 5, 2016

rdeutz commented Aug 7, 2016

csthomas commented Aug 7, 2016

rdeutz commented Aug 8, 2016

csthomas commented Aug 8, 2016

rdeutz commented Aug 9, 2016

ggppdk commented Aug 9, 2016 • edited

rdeutz commented Aug 9, 2016

rdeutz commented Aug 9, 2016

Sieger66 commented Aug 21, 2016 • edited

csthomas commented Aug 22, 2016

csthomas commented Aug 22, 2016

rdeutz commented Aug 22, 2016

csthomas commented Aug 22, 2016

ggppdk commented Aug 22, 2016

csthomas commented Dec 8, 2016

csthomas commented Jul 15, 2016 •

edited by rdeutz

csthomas Jul 15, 2016 •

edited

ghost commented Jul 19, 2016 •

edited by ghost

ghost commented Jul 19, 2016 •

edited by ghost

csthomas commented Jul 19, 2016 •

edited

ggppdk commented Jul 19, 2016 •

edited

csthomas commented Jul 19, 2016 •

edited

ggppdk commented Jul 19, 2016 •

edited

ggppdk commented Jul 19, 2016 •

edited

csthomas commented Jul 19, 2016 •

edited

csthomas commented Jul 20, 2016 •

edited

Sieger66 commented Aug 3, 2016 •

edited

ggppdk commented Aug 3, 2016 •

edited

Sieger66 commented Aug 4, 2016 •

edited

andrepereiradasilva commented Aug 4, 2016 •

edited

ggppdk commented Aug 9, 2016 •

edited

Sieger66 commented Aug 21, 2016 •

edited