-1 Misguided, misses the point and outright pointless.

I will give you an F- and only because I am in a good mood right now.

All your mistakes, laid out

Mistake 1: You make core code always throw a PHP Warning

if (!empty($_SESSION['__default']))
You removed the isset($_SESSION['__default']). Therefore, if $_SESSION['__default'] is not set you throw a PHP Warning. That would be a small oversight if you were not also explicitly unsetting $_SESSION['__default'] – let alone the fact that new, non-migrated sessions will NOT have that key in the session anyway.

Mistake 2: You failed to understand the root cause of the problem

// Migrate existing session data to avoid logout on update from J < 3.4.7
As I had explicitly written in that comment "Temporary, PARTIAL, data migration of existing session data to avoid logout on update from J < 3.4.7". The important and critical bit is that this is a partial data migration. It does not migrate the entire session data which is half of the reason why 3.4.x to 3.4.7 broke your sites. By changing that line you've told me that you don't understand the core code well enough to contribute to it.

Mistake 3: You can't read the existing core code

$this->data->set('__default.registry', new Joomla\Registry\Registry);
Have you realized that $this->data is a registry object and that $this->data->set does NOT set $_SESSION['default']? Read the core code on the same file you're editing. Duh!

Why do you think 3.4.8 is broken and how to ACTUALLY work around it

I can now tell you why you think that 3.4.8 is broken: you have migrated sessions from the 3.4.x to 3.4.7 update which have not been removed by flushSessions () that you so daftly removed. This will happen if the active Super User's session is not migrated, making the if-block in lines 1593-1596 return true. Therefore you removed the code that did not run on your site, therefore not fixing the problem.

BTW, the actual problem nobody could solve is that there was no clue if 3.4.7 had migrated a users' sessions. At this point I tried to get smart about it and run the logout code only when the Super User's session is not a fresh post-3.4.7-style, non-migrated one. It works in 99% of cases but not in yours (Super User's session is brand new but other users' sessions are migrated and, therefore, broken).

Instead of removing the one bit of code that would actually fix your site and doing some other misguided changes in core code causing it to always throw PHP Warnings you can do something simple and efficient: truncate the #__sessions table manually. If you or anyone else reading this are afraid to use a database you can install the free component Admin Tools Core and use the Purge Session button to have the system do it for you. There. Everyone is logged out and when they're logged back in the problem is "magically" fixed.

THINK BEFORE YOU CODE™

@nikosdion

if (!empty($_SESSION['__default']))
You removed the isset($_SESSION['__default']). Therefore, if $_SESSION['__default'] is not set you throw a PHP Warning.

empty() doesn't throw a warning if the variable/key/whatever doesn't exist. It has an implied isset() integrated. That's the difference between empty() and using a plain boolean check (if ($_SESSION['__default'])). The latter would casue the behavior you describe.

@nikosdion I'd like to emphasize that I don't say J3.4.8 in entirely broken. I am just trying to improve it over. We all keep fixing Joomla everyday, that does not mean Joomla is broken. It's just improving.

I bear much respect for everyone like you and my other fellows at Joomla. Most of them are seniors to me and know much more than I do. Sorry, if any of my (unintentional) words sounded otherwise. I am just discussing, not fighting.

Thanks for pointing out at my mistakes. Let me address each of them.

My Mistake 1:

if (!empty($_SESSION['__default']))
You removed the isset($_SESSION['__default']). Therefore, if $_SESSION['__default'] is not set you throw a PHP Warning.

Please have a look at http://php.net/manual/en/function.empty.php

That would be a small oversight if you were not also explicitly unsetting $_SESSION['__default'] – let alone the fact that new, non-migrated sessions will NOT have that key in the session anyway.

I am unsetting the if $_SESSION['__default'] inside the if (!empty($_SESSION['__default'])) test, after making use of that old session data. So that at next execution this if test evaluates false and the course is NOT repeated.

This is required because when $migratableKeys are processed it does not unset remaining non-migratable keys at all from the old session which still contains data (unneeded though) and this would allow passing the above if test next time again.

An unset OR $_SESSION['__default'] = array(); both are fine because once migrated the necessary data, we are not going to use it anywhere. Please note we don't need to logout the user anyway (as the case of com_admin in 3.4.8) according to my proposal hence we won't be testing this value anywhere again.

My Mistake 2:

As I had explicitly written in that comment "Temporary, PARTIAL, data migration of existing session data to avoid logout on update from J < 3.4.7

You said avoid logout, and subsequently you force logout anyway. That sounds a bit misleading.

It does not migrate the entire session data which is half of the reason why 3.4.x to 3.4.7 broke your sites.

NO, NO, Not at all, this was NOT the actual reason. The reason was it completely ignored what it did NOT migrate. Some of them are vital for the CMS to function. You can at least initialize such value with respective default data which weren't / shouldn't be migrated, so that the rest of code runs fine.

BTW, the actual problem nobody could solve is that there was no clue if 3.4.7 had migrated a users' sessions.

No clue what a code did? Really! Reading the code again should give the clue.

In fact, J3.4.7 did migrate users' sessions, as you said partially. But only thing it lacked that it overlooked the non-migratable values entirely. See my note right above.

By changing that line you've told me that you don't understand the core code well enough to contribute to it.

Yes, I know my knowledge is limited, and it would remain limited always. The world's knowledge is abundant and too much for me to have it all. But I don't try to act smart about where/what I don't understand.

My Mistake 3:

Have you realized that $this->data is a registry object

Yes, why would I not know it to be a registry object. Its written in the code.

and that $this->data->set does NOT set $_SESSION['default']?

Seriously? Why would I think $this->data->set should set $_SESSION['default']

Why do I think 3.4.8 is broken...

No, I don't think so. I just say it can be better.

Logging out everyone on the site is not fair on a site with nice amount of visitors. Someone may be posting some article, some may be adding something to their Cart, some may be in between of a payment process and what not.

So, if at all possible we should try to avoid it.

Since my proposition does NOT require any flushing of sessions and the removal of flushSessions() is not going to break any B/C, I removed it.

Rest of your notes repeat itself so I'd skip it here.

Just One Question:

What do you think the reason behind the error You are not permitted to use that link to directly access that page (#%d).?

If you have the reason, you get the solution. Forget my code. Just find this answer.

Why do we even have data migration?

Short answer: because of how the Joomla! Update works.

Joomla! Update first downloads the update ZIP file. Then it unpacks it by multiple AJAX calls to restore.php, outside the Joomla! session, replacing core files. Finally, it calls thorugh AJAX another task in com_joomlaupdate which runs Joomla!'s post-upgrade script to remove old files, update db structures etc.

This final bit happens inside the Joomla! session of the Super User. We can't let that be called without a Super User session for security reasons. If we don't perform migration of the current user's session than we can't run the post-update script, leading to other problems. Therefore Joomla! performs a partial session data migration which is only barely enough to run this script. Since we only migrate specific keys we end up with a zombie session that causes the problems you mention, as you very correctly point out.

Why not migrate all keys from the old session?

For security reasons, I'm afraid. I am aware of a way to bypass Joomla! 3.4.6's protection to inject malicious data in the session which would trigger the data migration in a way would end up replacing your session data with the injected. In short, it means that I could escalate my privileges to Super User on most sites as soon as they upgraded to 3.4.7 or later. So migrating the entire session storage is not an option.

Why do you get the "You are not permitted to use that link to directly access that page (#%d)."

It has nothing to do with the code your touched and everything to do with the default Joomla! session storage being a database table field that is 64Kb long. Before 3.4.8 it meant that you had 64Kb to write PHP serialised session data. That's enough for a bit less than 40Kb of actual data in most cases.

In 3.4.7 and later and in order to address a major PHP security issue we have to base64 the data before storing it to the database. Base64 increases the size of the data by 33%, therefore you now have around 30Kb of raw session data. If you go past this the session storage gets broken in an unpredictable way and, let's put it mildly, shit happens. I had warned about this problem five and a half years ago, in 2010, but I was told that the then imposed limit of 20Kb was enough for everybody. A couple of years later it was clear that it wasn't enough and was raised to 64Kb which is STILL not enough. I can't fix stupid, sorry. I've tried!

Anyway, since Joomla!'s MVC needs to store the ID of the item being edited in the session before editing it, a too big session storage leads to the ID not being stored. Since Joomla! can recover some but not all of the session data you are still logged in BUT the ID of the item being edited is not found in the session. Joomla!'s MVC checks that, thinks you are trying to manipulate the URL into editing something you are not supposed to and throws the aforementioned error.

Therefore the most likely sources of this problem is the size.

Regarding empty()

Indeed it won't show an error if $_SESSION is an array. Mea culpa. What I had in mind was some other developers which did crazy things like unset($_SESSION). Not joking. I have an email from someone asking me why this code no longer works. Also, extensions like that are also a reason why post-3.4.7 you might get a broken site: if you directly manipulate $_SESSION you are breaking the session storage.

BTW, $_SESSION['__default'] = array(); is a cleaner solution that lets us figure out when a session is migrated from an old session. Why? A migrated session has $_SESSION['__default'] set to an empty array. A new, post-3.4.7 session does not have $_SESSION['__default'] set at all. This trait was used to decide whether to flush user sessions.

Why flush all sessions?

Your solution works ONLY if the session has NOT been already migrated by 3.4.7. The problem we had to deal with is that a ton of 3.x sites up to and including 3.4.6 had upgrade to 3.4.7, all actively used sessions had been migrated and zombified. Yes, obviously you can tell everyone on the site –including each and every one of your visitors– to please log out and back in if they are experiencing problems with the site. However, as you eloquently put it, this "is not fair on a site with nice amount of visitors". I am speaking from experience with a site that has over 10,000 active subscribers.

There is a way to fully migrate all the partially migrated sessions but it has two drawbacks: a. it requires processing each and every session, one by one, which is currently not an option and b. by migrating all keys, blindly, we are introducing a major security issue.

For reasons of security we could not do anything except changing the way the session data is encoded and stored in the session storage (NOTE: this is typically the database, but not always – it could be APC or memcache as J! already has drivers). And for a similar reason to full migration we couldn't add fallback code in the form of if it's not set in $this->data look in $_SESSION['default'].

Therefore the only way to guarantee that people won't have frustrating problems with no apparent solution is to flush all session JUST THIS ONE TIME. This guarantees that no old, partially migrated session is left behind.

Why I say you have no idea what you're doing

This line here serves no purpose: $this->data->set('__default.registry', new Joomla\Registry\Registry);

If you're trying to create a new Registry object for $this->data this is not the way to do it. I'm trying to figure out wtf you're doing here but I can't, sorry.

I suppose that you MIGHT be trying to fix the second problem in 3.4.7, namely that the person who adapted the code from the staging branch confused bool with string and ended up in situations where $this->data was NULL. This doesn't happen after a partial session data migration, though. It happens when the Application object has not auto-start a session, i.e. in JApplicationWeb and JApplicationCli – basically anything other than JApplicationCms. This problem was already addressed in 3.4.8.

Why your solution doesn't really work

Of course what you did was the first thing we tried. However, it only works if someone has skipped 3.4.7 when upgrading a Joomla! 2.5.x to 3.4.5 (inclusive) site. That is, as long as there is no partially migrated session such a solution works. But 3.4.8 was prompted by 3.4.7 doing a partial migration in the first place!

Instead of wasting hours of our time I suggest that you simply FLUSH THE BLOODY SESSION TABLE.

Was there any point for my wasting 2 hours of my vacation time replying to you?

No.

You started 3 days ago by telling me that 3.4.8 isn't working and has to be reverted. I challenged you to provide code. I then detailed why your code is crap. You insisted. I have now explained in great detail EVERYTHING that we had to take into account those dreaded three days until Christmas Eve when instead of spending time with our families we labored over a solution that would allow all Joomla! users to have a pleasant holiday season.

And in the end of your message I read "I just say it can be better". Seriously? And to top it all, you ask ME to tell YOU why you get the "You are not permitted to use that link to directly access that page (#%d)" error message which is basic knowledge to everyone who has ever used Joomla!'s MVC, even in passing, and has everything to do with the session issue we had to fix. So, you tried to "improve" a solution to a problem you don't even understand. /headdesk

Because of @nikosdion comments regarding available session data size

yes, there are problems with session fitting into the DB and things breaking, but it is not because of J3.x default size which is mediumtext aka (16MBs minus overhead)

I did some search:

• it should not happen after 1.7.1 (look below) !!

diff_15_to_16.sql

ALTER TABLE `#__session`
 MODIFY COLUMN `data` VARCHAR(20480);

1.7.1-2011-09-15.sql

ALTER TABLE `#__session` MODIFY `data` MEDIUMTEXT;
ALTER TABLE `#__session` MODIFY `session_id` varchar(200);

aka 16MBs available for session data

but i have found some J3.x sites (upgraded from J1.5/J1.6.x/J1.7.0 ?) that still have:

`data` TEXT;

• somehow, they missed the update of: 1.7.1-2011-09-15.sql

i have to base64 and serialized data and zlib (if available) compress data so that they fit (base64 was to avoid session corruption but it is no longer needed in J3.4.7+)

i wonder if it is legal to force data to be 'mediumtext' ? since this is the intended current size

• or maybe this can be considered a bug, thus this should be re-added in an update SQL file of J3.5.x ?:

ALTER TABLE `#__session` MODIFY `data` MEDIUMTEXT;

To me it is a straightforward bug. The column type should have been MEDIUMTEXT all along. This is what I had been saying for nearly six years. FWIW in Joomla! 1.5 it was a LONGTEXT which is, indeed, an overkill. The typical session size is in the order 100-500 KiB. Therefore the correct column type is MEDIUMTEXT as you said.

I am not entirely sure why the 1.7.x update was missed. The fact is that the integrated update in 1.6 and 1.7 was not really well thought out. Joomla! Update which does work (I wrote the original version for the Joomla! 2.5 series) was only introduced in Joomla! 2.5.1.

I have just a correction to make to what you said:

i have to base64 and serialized data and zlib (if available) compress data so that they fit (base64 was to avoid session corruption but it is no longer needed in J3.4.7+)

Encoding with base64 is still required. In fact that's how 3.4.7 addresses the PHP bug. I can't go into much details in a public discussion but I can share what is already publicly known. PHP has three serialization handlers for session data: serialize, php_serialize and WDDX (optional). The default is serialize which has a broken serialization implementation that's easy to trick with certain malicious data in the session, essentially tricking PHP into using your own, crafted data instead of the real data when unserializing the session. That was the issue that hit all versions of Joomla! up to and including 3.4.5.

Joomla! 3.4.6 only addressed the zero-day attack vector used to inject malicious session data. It was a quick patch because sites were being hacked. We knew there are other potential attack vectors and I'm personally very happy that hackers were too daft to discover them (to any seasoned Joomla! developer who gets security the attack vector was sitting there in plain sight). Joomla! 3.4.7 addressed the PHP bug by not using $_SESSION directly. Instead, we are using a Registry object which we serialize ourselves and then base64 encode the serialized result. That's what goes into #_SESSION. Serializing base64 encoded data is safe as far as this PHP security issue goes. If we remove base64 encoding it is still possible to store malicious data in the session and take over the site on the next page load. Therefore you cannot remove base64 encoding.

Which brings me to my first point. Adding gzip compression to the session data is a slow, partial patch. The actual bug is that session storage is left to 64KiB when it should be 16MiB. This is an issue I first caught and commented on six years ago. The original bug was introduced under the pretense of performance. Even though I posted links to the MySQL manual and posts by the MySQL developers themselves stating that this is a misconception AND posted benchmark results with the benchmark code further corroborating that the "performance" pretense was a big hot steaming pile of cow manure I was ignored. Worse, I was told I am a bad developer and I don't understand how MySQL works even though the evidence I presented were from the actual people that at the time developed MySQL itself. Guess what? Not only I was right, again, but this issue has come back to bite us in the rear, again, after a few years.

TL;DR

The #__session table's data field should be MEDIUMTEXT. Not having it as such is a bug because of the typical usage patterns in Joomla! (lots of 3PD extensions using the session, as intended, for temporary data storage).

or maybe this can be considered a bug, thus this should be re-added in an update SQL file of J3.5.x ?:
ALTER TABLE #__session MODIFY data MEDIUMTEXT;

Good idea. PR welcome.

@nikosdion Well again!

Partial migration is fine

Since we only migrate specific keys we end up with a zombie session that causes the problems you mention, as you very correctly point out.

The only (important) key that we don't migrate is "registry" that holds userState. Perfectly alright! Don't migrate it if may cause security issues in any way. Just initialize it with blank Registry object in the new session. Everything works.

Why do you get the "You are not permitted to use that link to directly access that page (#%d)."

It has nothing to do with the code your touched and everything to do with the default Joomla! session storage being a database table field that is 64Kb long

It has everything to do with that only. Try nulling out the registry key of the JSession data on a running site. Use JFactory::getSession()->set('registry', null); and see the same shit will start again.

Anyway, since Joomla!'s MVC needs to store the ID of the item being edited in the session before editing it, a too big session storage leads to the ID not being stored.

Yes, and No. Yes that happens because of the edit_id not being stored. But storing it fails not because of the size. It fails because of missing registry key in the session.

Size of the migrated/new session

Therefore the most likely sources of this problem is the size.

Most likely? Rightly said. How can you be sure!

Let me explain.

As per you, when the session holds partial data it is too big to accommodate the edit Id. And after logout-login when it will certainly hold all the possible session data, It would be sized small and perfect so as to fit everything afterwards.

Salute to your awesome logic.

Excluding the registry key as it is never migrated, the session is just holding:

• 1 JUser instance: "user"
• 1 string (32 bytes): "session.token"
• 4 integers: "session.counter", "session.timer.start", "session.timer.last", "session.timer.now"

Is that too big?

Talking about size? Theoretically, You can never guess the size limit of JSession's data. Its only limited by the PHP max memory size allowed.

I can set the session data to even ~1GB using some code like

$app = JFactory::getApplication();
$app->setUserState('my_large_data', "PUT_SOME_ONE_GB_DATA");

However, I do understand that the size IS INDEED an issue in various other aspects. I'll take on that some other day.
Right now, What I see it is NOT affecting this particular context.

Why flush all sessions?

I have tested, 3.4.8 fails to flush all sessions.

Your solution works ONLY if the session has NOT been already migrated by 3.4.7.

Nope, my solution works even after 3.4.7. I have tested. Please test if you don't believe.
This benefits all those who have not updated to J3.4.8, that means everyone having J3.4.x (including J3.4.7) updating to this patch.

What you are not able to understand, is the most important line of this PR.

Why I say you have no idea what you're doing

This line here serves no purpose: $this->data->set('__default.registry', new Joomla\Registry\Registry);

If you're trying to create a new Registry object for $this->data this is not the way to do it. I'm trying to figure out wtf you're doing here but I can't, sorry.

Because you don't understand how Joomla\Registry\Registry works.

Here I am initializing the registry key in the new session.
This is the one line that actually fixes the issue.

Seriously? You think by doing this:

$this->data->set('__default.registry', new Joomla\Registry\Registry);

I'd be trying to achieve this?

$this->data = new Joomla\Registry\Registry;

No, they are different. Entirely different.

Your precious time

You started 3 days ago by telling me that 3.4.8 isn't working and has to be reverted. I challenged you to provide code. I then detailed why your code is crap. You insisted.

I still say stuffs need to be reverted, see the change in this very PR itself. By revert I don't mean to revert the entire version. I just mean the stuff that tries to logout the users to fix zombified sessions. Which doesn't work always anyway.

Out of THREE bugs, TWO (2nd and 3rd in the release note) were fixed perfectly in 3.4.8 but the (1st) ONE WAS NOT fixed appropriately.

And thus J3.4.8 still leaves all sessions zombified, except the current super admin (who is logged out indeed post-update).

I use the words revert and improve both, because the approach is improved by NOT requiring the user login, and reverting unnecessary parts of the code.

I have now explained in great detail EVERYTHING that we had to take into account those dreaded three days until Christmas Eve when instead of spending time with our families we labored over a solution that would allow all Joomla! users to have a pleasant holiday season.

Huh! Do you think we don't have holidays, Christmas, New Year and all? We don't invest our time on volunteer projects? See my other PR it too was on the same eve, 3-4 hours later than yours.

Are we expecting any salary out of this discussion or work?

Don't brag about what is not exclusive to you. Holidays and family is for everyone.

A code that works, does not mean its great! Don't fight for your code. Fight for Joomla!

SUMMARY

Please backtrace to the origin of an issue before you try to fix it. That I bet you didn't, else you're skilled enough (I trust you) to fix those things.

or maybe this can be considered a bug, thus this should be re-added in an update SQL file of J3.5.x ?:
ALTER TABLE #__session MODIFY data MEDIUMTEXT;

Good idea. PR welcome.

Actually, I wouldn't PR it. The only way to get into that state would be a direct upgrade from 1.5 or 1.6 directly into 3.0 without the proper schema changes. Considering the only way to upgrade from 1.5 or 1.6 directly into the 3.0 branch would be with a third party solution (using core 1.6 will only allow you to update into 1.7 which only allows updates into 2.5, and the schema change was made at 1.7 and a decision was made to remove all schema migrations for the 1.7 branch when preparing 3.0's release), I would call this a bug in the way the migrations were performed and not something critical enough for a core patch. The other option is to restore all the deleted SQL migrations from 0fc0e90 so that there is a full history of all migrations from 1.6's release forward so that the JSchemaChangeset API might determine those changes are correctly applied.

I'd like to request a quick look at my proposition and do the needful. Because, If this PR is correct, this is more useful if done the earliest possible.

Nope, my solution works even after 3.4.7. I have tested. Please test if you don't believe.
Because we had already tried something like that and it did not work I don't believe you. This works splendidly on a fresh 3.4.7 site or a 3.4.6 to 3.4.7 site that has had the Super User session expired and the Super User logged back in.

Please keep in mind that the use case I told you about is a 3.0.0 to 3.4.5 site upgraded to 3.4.6 and then to 3.4.7. All users have now partially migrated sessions. Your solution only addresses sessions that have NOT been already migrated. Do remember that for various reasons (session timeout, for example) a session may not be expired between subsequent releases of Joomla!.

Furthermore you have still not told me what this line is supposed to do: $this->data->set('__default.registry', new Joomla\Registry\Registry);.

Not to mention that you are the only person reporting a still broken session after the update to 3.4.8. Considering how I've tested on PHP 5.3, 5.4, 5.5 and 5.6, on different MySQL and PostgreSQL versions, with straight up 3.4.7, upgraded 3.4.6 to 3.4.7 and a 3.4.5 to 3.4.6 to 3.4.7 site I have very serious doubts about both your methodology and your perception of what is being "broken". In fact, the error message you get means that the ID of the item you are trying to edit is not saved in the session. This makes no sense since, at this point, you have already been logged out and then logged back in. The only reasonable, high-level explanations are:

• You already have two IDs of items being edited in the current session (MOST COMMON REASON). That's another thing I've been crying foul about since 2010, so spare me the crap talk about fighting for Joomla!. I've been doing it for a very, VERY long time. Joomla!'s now "legacy" MVC only allows you to set two IDs of items to be edited in the session. If you try editing more than this many items at once (also means: if you press the browser Back button in an edit page) you end up with no more items being editable and the dreaded message. Of course that has nothing to do with this PR and everything to do with how Joomla! 1.6.0-ALPHA2 and all later versions (almost a hundred of them, released in 5 1/2 years) work.
• The session isn't read correctly. If you're using PHP 7, yes, it does happen in the 3.4.x branch.
• The session isn't written properly. Are you sure you're using UTF-8 encoding for your db tables? Is the data field a MEDIUMTEXT or is it stuck to a VARCHAR(20000) or anything else? Does PHP have a writeable session path?
• Have you disabled base64_encode and base64_decode?
• Have you enabled the mbstring extension for PHP? Basically do what developers do: debug. Don't ask me what this error message means. If you are so confident in your ability to fix low level core issues you'd better know EXACTLY how Joomla! works and what you're doing. How do you think I learned how Joomla! works? Not through epiphany, just plain old XDebug and stepping through the code as it executes. Step the code when you click on an edit link. Does it store the ID in the database? If not, why? When the edit task fires does it read the ID? If not, is the ID stored in the session? If not, why? Give me a detailed analysis of what is going on on your site and how to reproduce it. Then we can discuss seriously.

Since you only gave me nothing but an error message to go by and nobody but you was ever able to reproduce the alleged issue I gave you the most likely explanation. So instead of telling me that I don't know how Joomla! works, I would recommend that you get your self-righteous ass on your chair and debug the code. IS THAT CLEAR, DOUCHECANOE? I'm not the one who knows nothing about how to backtrace an error message to core code, remember? It's YOU who are asking ME to debug an issue that nobody else besides YOU can reproduce and I did try in earnest. Excuse me for not being a psychic or not having hacked into your site to debug where this issue has only ever happened. I thought you said you're a developer, so where's YOUR analysis of the issue? It's easy playing peanut gallery. All it tells me about you is that you don't know the slightest bit about how Joomla! works, you moron.

I'm not the one who has STILL not answered WTF is that __default.registry crap supposed to do. It's you. All you told me is that it saves a new Registry object. No shit, Sherlock! Anyone who's used PHP for more than a week can tell you that, you idiot. What is the purpose of that? You have not answered because you do not understand your own code. You simply aped a line patterned on the code above, perhaps because you saw something in a session of your old site (and yeah, I know exactly what it is supposed to do, I looked it up). I know exactly why your wrong code fixes the issue you have because I CAN read the code. I will give you a few hints since you are too daft to figure it out yourself. Search for the error message in the administrator/language folder. Get the lang key and search for it in the administrator directory. What does that method do in that if-block? Which global application method does it call? What does that method do? Can it possibly be linked with the key you are NOT migrating because of something I wrote in the long list above BECAUSE I ACTUALLY DO UNDERSTAND HOW JOOMLA! WORKS? Hm, now that we know why it "works" we can understand why your solution is wrong (spoiler alert: it does not migrate data) and why it's useless (spoiler alert: JApplicationWeb::loadSession already does that for you). So this very line makes me wonder if your issue is actually a broken / not updated copy of Joomla!. Which would explain why you think you need to reset __default.registry and why you're the only person who has ever reported this issue.

Finally, I want to tell you to shove your self-righteous rant about who's fighting for Joomla! right up where the sun won't shine. You can ask anyone around here how much time I've spent on Joomla! the last ten years and the twelve days between the 0-day vulnerability's discovery and 3.4.8. Do learn to shut the heck up and start doing some actual development instead of whining like a dog.

One more thing: your PR is still the same useless crap it was last week and you are still the same moron you were last week. Now go debug some code and make sure that when you half-brained sloth come back here have PROPER detailed instructions on reproducing the issue, like I've done in all my PRs the last two years. Fair enough, or your pea-sized brain finds it hard to process that information?

I am closing and locking this here before the "contenace" get's totally lost, I further more don't see the issue that get's solved with this patch, the 3.4.8 update is behind us.