I would make it two parameters, one for the $ordering and a second for the $direction.
Also the parent::populateState() method already does some verification on the ordering and direction values, so we don't need to take care of that and can just pass the parameter to the parent function, making this even simpler.

Imho it could be done with just a few additional lines of code:

$params = $app->getParams();
$ordering = $params->get('admin_ordering', 'a.title');
$direction = $params->get('admin_dir', 'asc');
parent::populateState($ordering, $direction);

Also this PR misses the language strings for the new tab if you really want to add one.

Should i close this commit, redo the code to fit advice and ideas, and commit again?

In fact, i have added only one param for 2 reasons:

• make it simpler for user (only one option to set)
• because it is similar to list field to order articles in front-end.

So in case of 2 params, as it could be nice to add this for categories too, we could have this :

$params = $app->getParams();
$ordering = $params->get('admin_articles_ordering', 'a.title');
$direction = $params->get('admin_articles_dir', 'asc');
parent::populateState($ordering, $direction);

And one for categories (but maybe not so useful, excepted an ordering by language)

$params = $app->getParams();
$ordering = $params->get('admin_categories_ordering', 'a.title');
$direction = $params->get('admin_categories_dir', 'asc');
parent::populateState($ordering, $direction);

In fact, i have chosen one field to use the same strings of language already existing for options, and using the same values : rdate, date, rtitle, title....

About language strings, of course they're currently missing for tab title and desc, and for field otpion label and desc. The question is if others agree in a new tab only for admin params, or not. If no new tab, in which tab could it be added ?

Thanks for your advice and recommendation! They're welcome!
Cyril

Should i close this commit, redo the code to fit advice and ideas, and commit again?

You could just update this branch, the PR will automatically reflect the changes.

In fact, i have added only one param for 2 reasons:

• make it simpler for user (only one option to set)
• because it is similar to list field to order articles in front-end.

It may be a personal thing, but I find it easier to have two small list instead of a doubled single one.
As for the frontend, I don't like it there neither. but it's hard to change existing code if nothing really is broken

In fact, i have chosen one field to use the same strings of language already existing for options, and using the same values : rdate, date, rtitle, title....

With two fields, you don't need additional language strings neither. The asc and desc is in global language file already. And the columns are available as well since we use them for the table header.

And one for categories (but maybe not so useful, excepted an ordering by language)

The category ordering could be a bit more difficult to achieve because the categories view comes from com_categories and you would have to read the params from com_content. I don't think it's worth the effort there.

About language strings, of course they're currently missing for tab title and desc, and for field otpion label and desc. The question is if others agree in a new tab only for admin params, or not. If no new tab, in which tab could it be added ?

Just add the language strings. If it turns out that they are not needed, you can always remove them again.
I'm not convinced yet myself that the parameters justify a new tab, but I don't know where to put it otherwise Open for ideas as well.

Sorry to be late to answer, having some problem with my internet connexion since one week!
Today seems okay, but waiting for technician to come tomorrow...

So, after your comments on this, i have change files to not use an option in config (so, no new tab, nor field option to set in config)
Options are in hidden fields.

I have added an updating of params in view html, but maybe not the best way to actually add it. (could be in API)
So, in this new version (must be enhanced i think if members have more skill than me, but could be a starting point) is added a "button" just next list ordering filter.
A click on it update params, and so register a default ordering (maybe a floppy icon better than pin one, but no floppy icon in Joomla core!)

In /layouts/joomla/searchtools/default/list.php i've added a condition to display this button only on articles list, but, by adding the same code to other lists, you can have this button working for all!

So, ideas of enhancement of it are really welcome ! And it opens way of reflexion on settings default filters directly by registering current filter set.

Best Regards,
Cyril

Sounds more complicate than adding new params. Also I'm not sure if it's savy to add a button which would affect other users as well. The user could think it only affects the default order for himself.
The button and function would also need some ACL checks. The same that is used to show the options button.

I've just added an ACL control to display only for users with core.admin access.
(and transfert model file articles i've forgotten just before)
And will see about adding an individual setting for each user (possible to be added by using user ID)

Thanks!

3552 files changed? That's a bit much

I had just a bug with my local software SourceTree and all is down!

Arff... i don't know how to get it back!

I'd revert the wrong commits and force push the branch. Or just do a new PR. Sometimes that's easier

I did a new PR... #2808

Thanks for your help!
(i'm trying to understand the process, and hope not to do an other error when adding soon a new PR for an other issue...)
i cross the fingers!