This is nasty bug, maybe a 3.8.2 milestone ?

I have tested this item ✅ successfully on caf8b82

@ggppdk i guess this PR works only for com_content (not joomla-extensions/weblinks#368)

@laoneo

i guess this PR works only for com_content (not joomla-extensions/weblinks#368)

@franz-wohlkoenig

This PR is a valid fix for all classes that extend ModelAdmin and face this issue,
I have tested just now with weblinks 3.7.0-beta1 and it is working

I have tested this item ✅ successfully on caf8b82

but i'm afraid we still have some issues about classname and TagsObserver

old $tagsObserver = $table->getObserverOfClass('\JTableObserverTags');
new $tagsObserver = $table->getObserverOfClass('Joomla\CMS\Table\Observer\Tags');

that is supposed to be fixed by #17739

@alikon is this PR ready for RTC?

i would say yes cause it fix a big issue
but i suspect that there is still some issue with #18328 (comment) under the hood

so i'm afraid we need some feedback from mantainers
perhaps setting RTC gain more priority

@alikon

yes it was supposed to have been fixed, as you said above,
but it seems that fix was incomplete

foreach (JLoader::getDeprecatedAliases() as $alias)

https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/observer/updater.php#L63

will return 'jtableobservertags' which is not equal to 'JTableObserverTags'

thus this does not work

$this->table->getObserverOfClass('\JTableObserverTags');

(the slash is not the issue, lowercase comparison to uppercase is the issue)

@ggppdk maybe this one #17834 unvalidate #17739

The fixing of loading of classes via alias, regardless of letter case of the alias
will not effect this PR, and it should be done seperately of this PR

In this PR we just use the full qualified name of the class

This PR can be RTC

RTC after two successful tests.

@mbabker , @wilsonge

This is an important bug-fix of issues (of not uncommon usage) resulting in data loss (tags deleted)
please review for adding J3.8.2 milestone, and maybe reviewing the PR too

see brianteeman comment here also saying that this is urgent,
#18317 (comment)

aka if this, can be fixed properly then it should be in J3.8.2 ?

Added 3 new member variables and documented them,

but now this needs retesting !, no longer RTC !

Status in Issue Tracker back on "Pending".

Are the three new global member variables used on other places as well or only for batch? If not then for me this can lead to confusion to have global member variables which are used only for a set of operations.

@laoneo

Are the three new global member variables used on other places as well or only for batch? If not then for me this can lead to confusion to have global member variables which are used only for a set of operations.

They are used for batch*() and for saveorder(), should i add this at the comments above their definitions ?

please note that
-- these are not new they already existed before this PR
-- their usage is now documented, before it was not

So if I call first batch* and then saveorder will it still work?

So if I call first batch* and then saveorder will it still work?

Yes all methods call batchInit() to populate the re-usable member variables

please note that the code regarding populating

$this->table
$this->type
$this->tagsObserver

existed before this PR,
just because same code was repeated 5 times, i moved it to seperate method

question
these member variables were not documeted before

now i have renamed $this->batchSet to $this->batchInitialized
and removed $this->user and $this->tableClassName

is it a B/C break , should i restore them ?

May be you can use $this->table === null instead variable $this->batchInitialized === null?

now i have renamed $this->batchSet to $this->batchInitialized
and removed $this->user and $this->tableClassName

is it a B/C break , should i restore them ?

They have not been documented, I do not think so

May be you can use $this->table === null instead variable $this->batchInitialized === null?

yes my thought too,

just if some derived class decides to set $this->table in the constructor, then initBatch will not initialize the other member variables because $this->table === null will not be true

should i do this change ?

is it a B/C break , should i restore them ?

If they have been not private then it can be counted as a BC break.

$this->user was used by protected function checkCategoryId(). As there can be more batch methods in subclasses then all old variables probably has to stay initialised as before, some of them could be mark as deprecated.

3rd party component may use one of that variable which is not documented above.
Does Joomla support B/C for such variables?

$this->foo when not declared on a class object is treated as a public variable. So, there is a case to be made that removing the use of undeclared class variables counts as a B/C break because the variables were implicitly created through certain code paths.

i ll add them back , exactly as before ))

I have restored class member variables, now it should be B/C
Now it can be re-tested

I have this issue. (Please forgive my ignorance) How do I take part in a test ?

@Patrickbmccabe please mark your Test as successfully:

• open Issue Tracker
• Login with your github-Account
• Click on blue "Test this"-Button above Authors-Picture
• mark your Test as successfully
• hit "submit test result"

Done i restored 1 more local variable as member property (as pointed out by @csthomas )

I retested too
Ready to be tested again

@Puckmeister
@franz-wohlkoenig
@rgblogs
@Pilotnik
@Fuchsritter
@cybersalt
@AndySDH
@Shazrina1994

you had reported having issues with the tags being lost

maybe you can test this PR

I have tested this item ✅ successfully on 88fec66

Darg-and-Drop-Reordering works also as Batch-Action; Test on Articles.

Thanks @ggppdk

I have tested this item ✅ successfully on 88fec66

Tested #18317, #18086 and #18057

RTC after two successful tests.

It's OK now. Thanks.

I would love to test this, but I am but a humble user, one of thousands, probably tens or even hundreds of thousands who uses Joomla to manage web sites. It may be 'fixed' for geeks, but for us lesser mortals it remains a MAJOR bug until an update appears in the update channel. Does anyone know when we might expect this?

I agree with Barraclm, I would love to give my time amd effort to this, but it is beyond my ability. This bug has caused major issue for a Library website I had created 100's of tags for.

@barraclm https://github.com/joomla/joomla-cms/milestones - there you find expected Release Date.
@Patrickbmccabe https://docs.joomla.org/Bug_Tracking_Process - Information about Bug tracking using Patchtester.

Thank you Franz. That is very helpful.