I can't replicate this. Edit article once, save/close, then reopen same article. Editor loads as normal.

What editor are you using (that may make the difference in your case as compared to mine) I'm using JCE 2.6.1

Can you update PHP to a later version 5.6 or 7.x?

When finished to editing an article or a module if I will go to edit again doesn't works
i 've tested and I've got the same error both in localhost and in the production server.

do you use the same .htaccess file in both localhost and production server ?
it sounds like a caching problem,

if you check the checkbox of the row,
and then go to the top of the page and click the edit button,
then does editing work ?

@AMurray2016 I will try to make a video so you can see the error.

@ggppdk Cache in the Joomla backend? I have APC User Cache enabled but the Joomla system cache is used in the backend also?

@AMurray2016 and @ggppdk Please check the video with the error: https://alebak.me/c4719aa6-7143-4e48-y7e6-630c1e7d4e7e.webm

Cache in the Joomla backend?

Your website is most probably, sending HTTP headers that say to your browser that it is permitted to cache the redirection occuring by the edit links (read the links below)

This has been discussed extensively here, you should have searched
the joomla forums and this tracker before opening a new issue

#8757
#10753

Read the above and ... examine your htaccess file ...

Besides fixing the (non-supported configuration) in your .htaccess file,

A workaround is this:

If you check the checkbox of the row,
and then go to the top of the page and click the edit button
then the editting should work

Besides what is written in the above links, i have nothing more to say, (except repeating what is mentioned in them)

I don't understand the bug but this is my htaccess file:

##
# @package    Joomla
# @copyright  Copyright (C) 2005 - 2015 Open Source Matters. All rights reserved.
# @license    GNU General Public License version 2 or later; see LICENSE.txt
##

##
# READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE!
#
# The line just below this section: 'Options +FollowSymLinks' may cause problems
# with some server configurations.  It is required for use of mod_rewrite, but may already
# be set by your server administrator in a way that disallows changing it in
# your .htaccess file.  If using it causes your server to error out, comment it out (add # to
# beginning of line), reload your site in your browser and test your sef url's.  If they work,
# it has been set by your server administrator and you do not need it set here.
##

## No directory listings
IndexIgnore *

## Can be commented out if causes errors, see notes above.
Options +FollowSymlinks
Options -Indexes

## Mod_rewrite in use.

RewriteEngine On

## Begin - Rewrite rules to block out some common exploits.
# If you experience problems on your site block out the operations listed below
# This attempts to block the most common type of exploit `attempts` to Joomla!
#
# Block out any script trying to base64_encode data within the URL.
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
# Block out any script that includes a <script> tag in URL.
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL.
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL.
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root homepage
RewriteRule .* index.php [F]
#
## End - Rewrite rules to block out some common exploits.

## Begin - Custom redirects
#
# If you need to redirect some pages, or set a canonical non-www to
# www redirect (or vice versa), place that code here. Ensure those
# redirects use the correct RewriteRule syntax and the [R=301,L] flags.
#
## End - Custom redirects

##
# Uncomment following line if your webserver's URL
# is not directly related to physical file paths.
# Update Your Joomla! Directory (just / for root).
##

# RewriteBase /

## Begin - Joomla! core SEF Section.
#
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
#
# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]
#
## End - Joomla! core SEF Section.

<IfModule mod_expires.c>
  FileETag MTime Size
  AddOutputFilterByType DEFLATE text/plain text/html text/xml text/css application/xml application/xhtml+xml application/rss+xml application/javascript application/x-javascript
  ExpiresActive On
  ExpiresDefault "access plus 1 seconds"
  ExpiresByType text/html "access plus 600 seconds"
  ExpiresByType text/css "access plus 604800 seconds"
  ExpiresByType text/javascript "access plus 216000 seconds"
  ExpiresByType application/xhtml+xml "access plus 600 seconds"
  ExpiresByType application/javascript "access plus 216000 seconds"
  ExpiresByType application/x-javascript "access plus 216000 seconds"
  ExpiresByType image/x-icon "access plus 2592000 seconds"
  ExpiresByType image/jpeg "access plus 2592000 seconds"
  ExpiresByType image/png "access plus 2592000 seconds"
  ExpiresByType image/gif "access plus 2592000 seconds"
  ExpiresByType application/x-font-woff "access plus 2592000 seconds"
</IfModule>

The website had worked correctly with Joomla 3.6.4

ExpiresByType text/html "access plus 600 seconds"

Read the above line, do you know what it does ?
I copy paste from #10753

Your case is "CASE 2"

CASE 1: The initial "edit-task", failed to update session properly, due to race-conditions
CASE 2: The initial "edit-task", was never called because the HTTP request was cached by the browser for any reason

You would better remove all the "IfModule mod_expires.c" block:

<IfModule mod_expires.c>
...
</IfModule>

The website had worked correctly with Joomla 3.6.4

If it did, then you did not have the "IfModule mod_expires.c" block in your .htaccess file

You would better remove all the "IfModule mod_expires.c" block:

Are there any way to the Joomla backend to skip the htaccess rules? The "mod_expires.c" module is a suggest for best performance by Google Pagespeed and Varvy Pagespeed

Are there any way to the Joomla backend to skip the htaccess rules?

This is a general question not specific to Joomla
it is appropriate for some forum or for the Joomla forums, not the Joomla issue tracker
you can also search the web to find an answer

To answer your question:
-- try to create (if it does not exist already) an .htaccess file in the administrator folder
and add to it:

<IfModule mod_expires.c>
# disable mod_expires effects for this directory
ExpiresActive off
</IfModule>

Note for pages / links the browser has already cached,

• it will not work, try to relogin or to clear browser cache

This is a general question not specific to Joomla
it is appropriate for some forum or for the Joomla forums, not the Joomla issue tracker
you can also search the web to find an answer

I know that the ask is general but my suggestion for Joomla Developer team is the backend should skip any cache system (by server, by headers, by op-code, distributed or any other way of caching). The backend should be lean, it's a very dynamic environment. [Idea]

If Joomla tries to add a .htaccess file to the administrator folder

It will overwrite the file for web-sites that already have it
but ok it can be added if it does not exist already

Then if it exists, maybe it can try to do some searching into .htaccess
and check if an IfModule mod_expires.c block exists already
and if it is not found, then add it,

maybe

You can suggest it, and see what responses you will get

In your case you do not need it,
now, you already know how to add it !

As far as i can see the htaccess direction is a wild goose chase - this is a bug in joomla and its happend in the last 2-3 versions across articles, modules, plugins etc.

The if check on modules in apache thats processed in htaccess happens in Apache - not in joomla - its not relevant at all by the looks of it.

@ggppdk I can resolve adding a htaccess file in administrator directory. Thanks for your suggest.

Curiously the website mentioned was working correctly from Joomla 3.0.x with the mod_expires.c block in the htaccess file.

Could it be that Joomla should distribute a htaccess.txt into administrator directory also?

As far as i can see the htaccess direction is a wild goose chase

no no, nothing like that, i do not know about something in last 2-3 versions but for sure the ifmodule mod_expires.c block causes exactly the behaviour describe in this issue above

<IfModule mod_expires.c>
...
  ExpiresByType text/html "access plus 600 seconds"
...
</IfModule>

A dozen or more people have replicated the behaviour, (myself included)
and the behaviour is 100% explainable:

1. the edit links point to the edit task, that calculates ACL and adds the result to session data
2. if access is granted a redirection occurs going to the view to display the form, which reads the ACL result from the session data

The mod_expires directive causes the browser to go directly to the VIEW that displays the form,
and because after 1st EDIT operation you close the form close, the ACL data had been removed from SESSION, so the view of course does not find them

@ronnikc

If you read these you will understand / know more
#8757
#10753

Only way for previous Joomla versions to work is if :

• either module edit links were direct links to view ?? and the view also did the ACL calculation
• or module edit links were somehow "POSTed" (like the edit toolbar button causes form to be POSTed) thus browser did not cache the redirection

but i know nothing about the above 2 cases

My point was it's not the source of the problem - but a symptom.

Been running mod expires in every site for years without problems until some recent release (tbh i dont recall exactly which version) and since then the problem is there but in some cases sporadically and unreplicable and in others replicable.

Those replicable has all been in Chrome too - It would seem there might be 2 issues at play.

and since then the problem is there but in some cases sporadically and unreplicable

• this is another case , it is due to RACE conditons of 2 updates of user session data happening close together and last one to write to session, discards the ACL calculation of the other,

e.g. quickily clicking to edit 10 modules with middle click, do quickly it and you will see it will happen almost of sure, e.g. 5 out of 10 edits failing

Those replicable has all been in Chrome too

• yes chrome is more aggresive to decide to cache the redirection, you can find this in the issue discussion i suggested reading, i don't remember when chrome decides, but it is exactly because it caches the redirection,

find a site that it occurs repeatedly, open the browser console of chrome go to the network tab and see the redirection is cached

quickily clicking to edit 10 modules with middle click, do quickly it and you will see it will happen almost of sure, e.g. 5 out of 10 edits failing

We can disable the button when clicked, so no more clicks will be accepted (childish solution, but easy way out of this)

We can disable the button when clicked

I meant the edit links not the edit button at the toolbar,
(it is difficult to mark a checkbox and click the edit button fast enough)

but i guess your suggestion applies to the edit links too, e.g. disable clicks on other edit links 1 second when an edit link is clicked ...

@alebak
Can you remove the "[Urgent Joomla 3.6.5]" from the title,

there is nothing urgent about this,
also no evidence given it is specific to J3.6.5

In fact it can even be considered "duplicate" report and be closed ...

Are you using a CDN? I have noticed this type of issue before when using a CDN I.e. Cloudflare.