Can you have a look at the travis error please @PhilETaylor https://travis-ci.org/joomla/joomla-cms/jobs/106000956#L1105

PHP Fatal error: Call to a member function close() on a non-object in /home/travis/build/joomla/joomla-cms/libraries/joomla/application/web.php on line 564

Already fixed all travis errors.

https://travis-ci.org/joomla/joomla-cms/builds/106002715

Thanks - it completed while I was posting

You still need to call $this->close() after $this->session->close(). $this->close() is a wrapper around exit() and the session's close method is just shutting down the session; this is going to result in some very unexpected behaviors being triggered.

Thanks @mbabker Ive added that now,

Tested now with memcache, files, and database session handlers as active and no regression/issues found.

OK, sorry... following protocol now. I would like to test @PhilETaylor's fix. Can somebody walk me through that? I am totally new to this and don't have much time.

Wait. Better yet, can I test it on someone else's server? ... from the initial install?

@durian808 https://docs.joomla.org/Testing_Joomla!_patches

Thanks, got the ZIP. I will install on my server and do the identical test as I did on the SiteGround server.

I have tested this patch (com_patchtester) on our Joomla test environment on a multi language site (gwsdev2.work) and all works as expected. I am unable to produce any errors while doing my utmost best to blow the frontend up

• PHP 5.6
• Memcache
• fcgi
• MySQL 5.5 - MariaDB
• Suhosin
• gzip enabled

So this works as expected for me

@gwsdesk can you report your browser as well please? just so I can keep a watch on those incase one is caching more than it should

Tested in Firefox & Chrome as usual. Will test in "mighty Edge" as well
and post back

On 2/1/2016 3:09 PM, Phil Taylor wrote:

@gwsdesk https://github.com/gwsdesk can you report your browser as
well please? just so I can keep a watch on those incase one is caching
more than it should

—
Reply to this email directly or view it on GitHub
#9035 (comment).

I can confirm I cannot break it in "Edge" as well.... Did my best but for me this PR is RTC

Where can I see which files were changed for this fix? Thanks.

https://github.com/joomla/joomla-cms/pull/9035/files

Can this file by itself be dropped into J3.4.8?

@durian808 yes, just be careful with the file permissions. It's way easier to use the patch tester (does that for you)
Grab it: https://github.com/joomla-extensions/patchtester/releases and install it in any website. Then apply any patch you want

Seriously, I have asked you previously "can you read" Here you go again:
https://docs.joomla.org/Testing_Joomla%21_patches Now in the middle of
that page is a link to "com_Patchtester" You install that and you can
apply and restore from patches. If you want a fruitful participation why
don't you follow the links posted now I think 6 x to you?

On 2/2/2016 3:22 AM, durian808 wrote:

Can this file by itself be dropped into J3.4.8?

—
Reply to this email directly or view it on GitHub
#9035 (comment).

@gwsdesk where I come from we say "take a chill pill". Imagine that I am not part of your clique group that is constantly dealing with this UI here and all its wonderful tools. I just want to get in, run a test on the fix in the same environment as the failure occurred, and be done with this. I have a great deal many other things on my plate – way too many – I don't have time to learn these ropes. Seriously.

Well mate, just for others to learn.... Michael Babker created this
utmost handy patchtester to allow just to do what you wnat....Get in,
activate the patch, test and get over it... If you do not use the
com_patchtester youu would have to copy all raw code and replace the
actual files on the server for testing, safe those first before doing
so, test, remove the patch and reinsert the originals.... Who is wasting
time?

Cheers

On 2/2/2016 9:49 AM, durian808 wrote:

@gwsdesk https://github.com/gwsdesk where I come from we say "take a
chill pill". Imagine that I am not part of your clique group that is
constantly dealing with this UI here and all its wonderful tools. I
just want to get in, run a test on the fix in the same environment as
the failure occurred, and be done with this. I have a great deal many
other things on my plate – way too many – I don't have time to learn
these ropes. Seriously.

—
Reply to this email directly or view it on GitHub
#9035 (comment).

@gwsdesk good on @mbabker ... you have great tools here. I'm not saying I won't delve deeper and start using the tool(s), I'm just in my flow right now and juggling a lot of things. According to @dgt41 in this case I can drop in the one file. If my testing shows things are fixed, I'll be on my way for now. Otherwise, deeper down the rabbit hole.

I just encountered the error while working on a client's site, just after enabling a plugin and clicking save.

The plugin now shows as locked.

The client's site is hosted in the Rackspace cloud.

On the same site as my last comment, I got the error on the front end this time. Right after I logged into the front end, first time I clicked on the edit icon on an article, I got the error.

This is what it looks like on their template:

I clicked the edit icon again and there was no problem.

The above 2 comments are informational, indicating that perhaps the error is not as rare as thought, since I have seen it twice today working on a client's J3.4.8 site.

I was going to test the PR code on my server, but my revised plan now is to first test on my latest SiteGround demo site by dropping in the one changed file. I will first retest to make sure the error is still occurring on that site, then drop in the changed file, then retest. I will report my findings here.

It seems only you can replicate this issue almost on demand - I have still not managed to get the issue once throughout my testing.

I see you are using firefox, what exact version and what firefox extensions do you have installed?

*You CANNOT make changes to the source code running on a .joomla.com domain - SiteGround are running a MODIFIED JOOMLA CODE BASE and HIGHLY CACHED version of Joomla in their commercial service on the *.joomla.com domains - you have no access to install extensions or to modify the source code.

Cross posting: http://joomla.stackexchange.com/questions/15096/joomla-random-lack-of-access-permission?newsletter=1&nlcode=532014%7c3fdf

The error was not appearing when my browser extension « Cache Killer » was activated and the same thing was going on with the mode debug

It seems only you can replicate this issue almost on demand - I have still not managed to get the issue once throughout my testing.

Odd, isn't it. Well, I'm not lying, so what do you think this means? Yes, I saw the error on the SiteGround demo, and then just today twice on a client's site running in the Rackspace cloud.

I see you are using firefox, what exact version and what firefox extensions do you have installed?

FF 43.0.4 on Mac. No extensions that should affect this. I'll try in Chrome w/ no extensions.

You CANNOT make changes to the source code running on a *.joomla.com domain - SiteGround are running a MODIFIED JOOMLA CODE BASE and HIGHLY CACHED version of Joomla in their commercial service on the *.joomla.com domains - you have no access to install extensions or to modify the source code

Yes, you can modify the code through Cpanel. What do you mean modified code base... what's modified? The core? That seems very strange. It's Joomla 3.4.8. What do you mean, highly cached?

You cannot modify the files on a free joomla.com domain demo site provided by siteground. Period. If you have since upgraded and paid for the service then I believe you can.

Their code is modified to remove access to all kinds of features like the ability to install extensions, templates and access to Global Configuration Tabs is restricted, their SGJCache plugin is installed by default, and their infrastructure has many layers of caching previously with Varnish but more recently with Nginx. Progressive Caching layer in Joomla is also enabled by default which is different to a standard Joomla ootb experience. You also cannot see or modify the .htaccess file.

(which is why that entire "demo" options sucks so much) --> just some
personal opinion

On 2/3/2016 3:00 PM, Phil Taylor wrote:

You cannot modify the files on a free joomla.com domain demo site
provided by siteground. Period. If you have since upgraded and paid
for the service then I believe you can.

Their code is modified to remove access to all kinds of features like
the ability to install extensions, templates and access to Global
Configuration Tabs is restricted, their SGJCache plugin is installed
by default, and their infrastructure has many layers of caching
previously with Varnish but more recently with Nginx. Progressive
Caching layer in Joomla is also enabled by default which is different
to a standard Joomla ootb experience. You also cannot see or modify
the .htaccess file.

—
Reply to this email directly or view it on GitHub
#9035 (comment).

You cannot modify the files on a free joomla.com domain demo site provided by siteground. Period. If you have since upgraded and paid for the service then I believe you can.

Yeah you can, and you can set file permissions, too. Free site. Using the Cpanel File Manager ... rename, copy, whatever you want. I just did it.

Their code is modified to remove access to all kinds of features like the ability to install extensions, templates and access to Global Configuration Tabs is restricted, their SGJCache plugin is installed by default, and their infrastructure has many layers of caching previously with Varnish but more recently with Nginx. Progressive Caching layer in Joomla is also enabled by default which is different to a standard Joomla ootb experience.

Hmmm, well. Too bad they are even associated with Joomla. BUT... whatever shit they are running, it DOES precipitate the problem. If the error happens on a production site in the Rackspace cloud, it's a real problem. I don't care what "crap web host" we are dealing with... people in the real world are seeing this error, that's the key.

You also cannot see or modify the .htaccess file.

Affirmative on that one.

I can't see the error on the SiteGround server tonight ... wee hours Chicago time where the server is. I'm sensing this is server load related, as was suggested. I will try again when it's mid day Chicago.

Yeah you can, and you can set file permissions, too. Free site. Using the Cpanel File Manager ... rename, copy, whatever you want. I just did it.

You are wrong. You do not get a cPanel interface with a free *joomla.com domain until you upgrade and pay.

Guys you are confusing the free for life hosted version at *.joomla.com
(what Phil described) and the 90 day demoversion at *.demojoomla.org (what
durian described)

On 3 February 2016 at 08:13, durian808 notifications@github.com wrote:

You cannot modify the files on a free joomla.com domain demo site
provided by siteground. Period. If you have since upgraded and paid for the
service then I believe you can.

Yeah you can, and you can set file permissions, too. Free site. Using the
Cpanel File Manager ... rename, copy, whatever you want. I just did it.

Their code is modified to remove access to all kinds of features like the
ability to install extensions, templates and access to Global Configuration
Tabs is restricted, their SGJCache plugin is installed by default, and
their infrastructure has many layers of caching previously with Varnish but
more recently with Nginx. Progressive Caching layer in Joomla is also
enabled by default which is different to a standard Joomla ootb experience.

Hmmm, well. Too bad they are even associated with Joomla. BUT... whatever
shit they are running, it DOES precipitate the problem. If the error
happens on a production site in the Rackspace cloud, it's a real problem. I
don't care what "crap web host" we are dealing with... people in the real
world are seeing this error, that's the key.

You also cannot see or modify the .htaccess file.

Affirmative on that one.

—
Reply to this email directly or view it on GitHub
#9035 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I'm not confused.

My demo is at demojoomla.com.

@brianteeman that makes more sense. Thanks... utter confusion.

So what he said about the caching, etc., ... all not true about demojoomla.com? I thought he knew I was talking about SiteGround?

They are both provided by Siteground!

I cannot create a demojoomla.org account as in creating one I get SSL issues today - probably a bug as they rolled out LetsEncrypt the other day...

http://screenshot.myjoomla.io/0H0Y0h2y0Y2z

OK gents, have a good one. zzzzzzzzzzzz

I cannot create a demojoomla.org account as in creating one I get SSL issues today - probably a bug as they rolled out LetsEncrypt the other day...

I saw that too... fiddle w/ the URL methinks.

The SSL issue you had should now be resolved - please let me know if not

"SSL Cipher Suite RC4 had to be added to apache, as the new version of Google Chrome requires it."

Google Chrome demands that SSLv3 and RC4 are REMOVED, not ADDED!
https://googleonlinesecurity.blogspot.co.uk/2015/09/disabling-sslv3-and-rc4.html
http://venturebeat.com/2015/09/01/google-microsoft-and-mozilla-will-drop-rc4-support-in-chrome-edge-ie-and-firefox-next-year/

The problem was that the Siteground Server used RC4 suites and older protocols and SSLv3 - which are insecure and from early 2016 modern browsers will not connect to it. SSLv3 is also obsolete and insecure

ala:

The result after their changes is slightly better - but still on a B grade. The server still uses common DH primes, has weak key exchange and supports RC4 with older ciphers :-(

But none of this is related to the problem this PR is addressing :-)

The problem with the SSL is now resolved, its still only a B Grade, but then its only a demo site..

I'm only quoting what they said
On 3 Feb 2016 10:12 am, "Phil Taylor" notifications@github.com wrote:

Google Chrome demands that SSLv3 and RC4 are REMOVED, not ADDED!

https://googleonlinesecurity.blogspot.co.uk/2015/09/disabling-sslv3-and-rc4.html

http://venturebeat.com/2015/09/01/google-microsoft-and-mozilla-will-drop-rc4-support-in-chrome-edge-ie-and-firefox-next-year/

The problem was that the Siteground Server used RC4 suites and older
protocols and SSLv3 - which are insecure and from early 2016 modern
browsers will not connect to it. SSLv3 is also obsolete and insecure

ala:
[image: screen shot 2016-02-03 at 10 06 05]
https://cloud.githubusercontent.com/assets/400092/12779080/0c951034-ca5e-11e5-8450-72bf3ec133c7.png

The result after their changes is slightly better - but still on a B
grade. The server still uses common DH primes, has weak key exchange and
supports RC4 with older ciphers :-(
[image: screen shot 2016-02-03 at 10 09 47]
https://cloud.githubusercontent.com/assets/400092/12779127/4928ab28-ca5e-11e5-89f4-20af4d953d47.png

But none of this is related to the problem this PR is addressing :-)

The problem with the SSL is now resolved, its still only a B Grade, but
then its only a demo site..

—
Reply to this email directly or view it on GitHub
#9035 (comment).

@PhilETaylor I got the emails, but your comments aren't here? Did you delete them?

I just replicated this issue on a client site

One of those days... I have had this exact issue on THREE customer sites today, when I have not seen it on a customer site for a long time.

Looking at the report at StackOverflow as well ... about the ExpiresDefault setting in .htaccess - 2 out of 3 of these sites had this setting - and as soon as I busted the cache or removed that in the .htaccess this issue was resolved - the setting was added to the .htaccess by @nikosdion Admin Tools Professional .htaccess maker.

# Default expiration: 1 hour after request
ExpiresDefault "now plus 1 hour"

On the third site I saw duplicated Expires headers (WTF!)

Good work, man. FYI, I have seen it on site(s) w/out the ExpiresDefault in the .htaccess. I will try to test on the SiteGround server again today.

from my experiences today this looks more like a browser caching issue than a session race condition... but this PR should fix both

So, in the case of the front end editing anomaly, are you saying that – in the error case – what the browser is showing after we hit edit icon is a cached version of the editor screen and content window? Wow, that's bad! I need to run... will check back later.

I tested just now on my 2nd demo site on SiteGround. Time of testing was between 7:00pm and 7:45pm SiteGround server time (Chicago). The results were very bad.

First, I was able to recreate the error very quickly. Then I inserted the one changed file from this pull request, libraries/joomla/application/web.php. Once the file was inserted, I started testing again and soon saw that the article content was not saved properly – the content that was shown on subsequent edit requests was not the same content as shown in the category view. And then the 403 error came shortly after that, more than once. Then I attempted to log out and back in but got repeated "Invalid token" that I was not able to clear by flushing the browser cache or by clearing cookies. The only way I could clear this condition was to register another user. I was going to log in as the new user, but found that I could now log in as the original user. Now I did some more testing and found that once the 403 error had occurred, every subsequent attempt to click the edit button resulted in another 403 error – the situation was worse. This subsided if I waited long enough. Lastly, to make sure I was indeed executing the new code in web.php, I inserted code to output a runtime exception just inside the redirect function... It was executed. One more thing to report – I turned off the browser's content cache (FF) and still got the 403 error. I also tested with Chrome... still got the 403 error.

I still think the resource (article) should be locked, as I was saying in #9013... "...one edit request on top of an unfinished one, causing session data corruption, followed by a 403 error because Joomla gives up." If the previous edit has not been completed (content saved), and the same user is clicking the edit button again, they should get a message indicating "Previous save not completed yet. Please retry." While a lock exists on the article, a read-only status could be read to indicate "save in progress" or "open for editing". For the later, the message to the user would be "Article already checked out (not saved)," and the user would then be warned that edits could have been lost and to "click here" to edit the article again (thereby losing those edits). Note that this is already the behavior of Joomla – if the editing session is lost by virtue of losing the browser tab or window, a subsequent click on the edit icon reloads the last saved content. With my suggestions here, at least the user is given feedback as to what's going on and prevented from opening an article when a save operation has not yet completed.

Do we now re-open #9013?

Just curious ... have you tried making a copy of your site and moving it
to a different server and testing there?

I used to have a couple siteground accounts that really got messed up. I
moved them to a different server and they had no problems. As noted
elsewhere (and my personal experience), Siteground servers are 'tweeked'
and they may be 'contributing' to the issues.

On 2/5/2016 8:20 PM, durian808 wrote:

I tested just now on my 2nd demo site on SiteGround. Time of testing
was between 7:00pm and 7:45pm SiteGround server time (Chicago). The
results were very bad.

First, I was able to recreate the error very quickly. Then I inserted
the one changed file from this pull request,
libraries/joomla/application/web.php. Once the file was inserted, I
started testing again and soon saw that the article content was not
saved properly – the content that was shown on subsequent edit
requests was not the same content as shown in the category view. And
then the 403 error came shortly after that, more than once. Then I
attempted to log out and back in but got repeated "Invalid token" that
I was not able to clear by flushing the browser cache or by clearing
cookies. The only way I could clear this condition was to register
another user. I was going to log in as the new user, but found that I
could now log in as the original user. Now I did some more testing and
found that once the 403 error had occurred, every subsequent attempt
to click the edit button resulted in another 403 error – the situation
was worse. This subsided if I waited long enough. Lastly, to make sure
I was indeed executing the new code in web.php, I inserted code to
output a runtime exception just inside the redirect function... It was
executed. One more thing to report – I turned off the browser's
content cache (FF) and still got the 403 error. I also tested with
Chrome... still got the 403 error.

I still think the resource (article) should be locked, as I was saying
in #9013 #9013... "...one
edit request on top of an unfinished one, causing session data
corruption, followed by a 403 error because Joomla gives up." If the
previous edit has not been completed (content saved), and the same
user is clicking the edit button again, they should get a message
indicating "Previous save not completed yet. Please retry." While a
lock exists on the article, a read-only status could be read to
indicate "save in progress" or "open for editing". For the later, the
message to the user would be "Article already checked out (not
saved)," and the user would then be warned that edits could have been
lost and to "click here" to edit the article again (thereby losing
those edits). Note that this is already the behavior of Joomla – if
the editing session is lost by virtue of losing the browser tab or
window, a subsequent click on the edit icon reloads the last saved
content. With my suggestions here, at least the user is given feedback
as to what's going on and prevented from opening an article when a
save operation has not yet completed.

Do we now re-open #9013
#9013?

—
Reply to this email directly or view it on GitHub
#9035 (comment).

@cpaschen we are trying to reproduce the problem and I have found that my SiteGround demo is a reliable way to do that. People are seeing this error in a variety of environments, but it is often very difficult to reproduce and therefor very difficult to test and try potential fixes. Both myself and @PhilETaylor have seen the issue come up recently on our client's servers. The one I observed was in the Rackspace cloud. Anyway, we are trying to flush it out and test it, not avoid it.

I have more changes/code to add but cannot this week due to exams - I have another approach to tackle the cache/expires issue

Sent from my iPhone

On 6 Feb 2016, at 21:28, durian808 notifications@github.com wrote:

@cpaschen we are trying to reproduce the problem and I have found that my SiteGround demo is a reliable way to do that. People are seeing this error in a variety of environments, but it is often very difficult to reproduce and therefor very difficult to test and try potential fixes. Both myself and @PhilETaylor have seen the issue come up recently on our client's servers. The one I observed was in the Rackspace cloud. Anyway, we are trying to flush it out and test it, not avoid it.

—
Reply to this email directly or view it on GitHub.

@PhilETaylor wrote:

Looking at the report at StackOverflow as well ... about the ExpiresDefault setting in .htaccess - 2 out of 3 of these sites had this setting - and as soon as I busted the cache or removed that in the .htaccess this issue was resolved - the setting was added to the .htaccess by @nikosdion Admin Tools Professional .htaccess maker.

I just tested again on the SiteGround demo, using the default .htaccess (yes it let me write to this file). I still got the error.

I also just did a test where I waited a full 10 seconds before hitting the edit button again. I was able to get the failure after about 4 attempts, each waiting a full 10 seconds before hitting the edit button. I think something else is happening – it's not simply that the previous edit session has not completed. I don't think there's any way, normally, where that operation could take 10 seconds. I think it's time for me to start putting debug output in the code.

@durian808 @PhilETaylor Any news on this one? I can give someone access for testing this issue. I myself I am not able to fix it. :/

@PhilETaylor Any progress on the new approach?

There are several other PRs that attempt to address this issue, @brianteeman (the issue master!) might be able to recall their exact PR numbers...

Sorry @PhilETaylor @roland-d I'm not sure which or you mean and obviously even if I did I wouldn't know if they used the other approach you alleged to

This problem has been talked to death - but there is a PR so all the duplicate issues raised should be pointed towards #10753 and closed...

#9145 (comment)

Closed as PR #10753 has been raised, this issue is also a duplicate of millions of others.