Backend publish index table sorting not reacting (opcache related)

[jurajkapsz]

Affected Symphony version(s) : 2.7.7
PHP version(s) : 7
OS(es) : Ubuntu / Chrome, Firefox

Note
I think this is an older issue, so it should be present also on older Symphony versions like 2.6 and maybe even older / PHP 5.x .

Issue
When toggling sort order of a publish index table by clicking on a column's name, e.g. basic text field column type (asc desc toggling or changing column etc.), it takes two or three clicks to activate the sort, the first clicks doing like nothing.

Expected
Sort order should be activated on first click.

[cylkee]

I get this too.

Affected Symphony version(s) : 2.6.3-11, 2.7.7
PHP version(s) : 5.6.x
OS(es) : Windows 10, Firefox

[nitriques]

Would you have op_cache enabled by any chance ?

[jurajkapsz]

Would you have op_cache enabled by any chance?

Yes. Yay, good old op_cache again?

[cylkee]

Would you have op_cache enabled by any chance ?

Yes. Is that good or bad for Symphony, or should it not matter?

[cylkee]

In case it helps, sorting columns in the Authors page works for me every time and the browser address bar changes with parameters, e.g. from /symphony/system/authors/ to /symphony/system/authors/?sort=last_seen&order=asc. The Publish pages do not add parameters to the address bar when eventually sorted on any given column, however I can see that the underlying link does have parameters, e.g.

<th scope="col" id="field-2" class="field-input">
	<a href="?sort=2&amp;order=asc" title="Sort by ascending title"><span>Title</span></a>
</th>

[michael-e]

Let me explain OPcache a little bit. Generally, it's a very good thing, because it keeps the compiled version of PHP files in a cache — so it not only saves time reading the file next time, but compiling the file as well. The only thing needed for this to work is to check the original file's modification time every time the compiled version is needed. And that is a very, very "cheap" process compared to reading and compiling it. So PHP runs faster.

Unfortunately, somebody thought that it should even be better than that. A file's modification time shouldn't be checked on each and every request, but there should be a few seconds between the mtime checks at least. The opcache.revalidate_freq was implemented, with a default value of 2 (seconds).

Now this means that even if a PHP file changes, it may take up to 2 seconds for this to take effect (depending on when it was requested for the last time). For high-traffic (!) systems this may be a good thing and further improve performance, because it saves a lot of modification time checks in the filesystem.

But it comes at a price: When the PHP app writes PHP files itself (like Symphony writing to config.php, for example), these changes may not be reflected immediately (unless the app would drop the OPcache). This can be very confusing for the user.

For Symphony (unless you have really high traffic) I suggest to set opcache.revalidate_freq to 0. (If you are on shared hosting, you may ask your provider how to do it.) This will not mean that the cache does not work, it just means that the modification time is checked for each file request. (In my eyes this would have been a much better default value, because it causes less headache. The "super pro" users will touch those settings anyway.)

Regarding your issue: Without having tested anything (so from the top of my head), I am rather sure that the effect is caused by OPcache.

[cylkee]

Hmm, I wonder why the sorting of Publish pages is being stored in config.php. Does that mean if Author Alice sorts a Publish page on another column, Author Bob would see that Publish page sorted on that column the next time he loads the page? If so, would it be better all round if sorting preferences were stored in browser cookies?

[michael-e]

Does that mean if Author Alice sorts a Publish page on another column, Author Bob would see that Publish page sorted on that column the next time he loads the page?

Yes.

If so, would it be better all round if sorting preferences were stored in browser cookies?

I'd prefer to see it stored in the user's session, or in the database, or — best IMHO — not stored at all. (Pagination could still retain the sorting by passing a request parameter between pages, as long as you don't leave the index page). But "permanent sorting" has always irritated me. Anyway, changing the behaviour is out of scope for Symphony 2.7. — no features, fixes only!

Maybe @nitriques finds the time to tell us how this is supposed to work in Symphony 3 or later. (I admit that I have not watched/followed the development closely.)

[cylkee]

I'd prefer to see it stored in the user's session, or in the database, or — best IMHO — not stored at all.

I'd not thought of that. I agree.

[nitriques]

@michael-e Thanks for the explanation, very nice!

We will remove it from the config that's for sure! But we would need to be able to configure a default sort, and then use a author-based one.

[cylkee]

So, is this not being treated as a bug, but as a PHP configuration issue?

[cylkee]

For Symphony (unless you have really high traffic) I suggest to set opcache.revalidate_freq to 0.

@michael-e I did this and the behaviour has been mitigated as you suggested. Also, maybe the Order Entries extension will now work for me.

I wondered however if opcache.blacklist_filename could be used instead to simply isolate config.php but whatever I tried with that did not work.

[michael-e]

Well, that might work as well, I never tried. But I don't think that you will see any measurable advantage (compared to revalidating).

[jurajkapsz]

Thanks @michael-e for the excellent explanation before. I became a friend with opcache after that, I mean it. Besides that, @cylkee , I recently just tried to turn off opcache within my latest websites updates, and those sites performs with no noticeable setback.
I asume, it further depends on traffic volume etc., but I wanted to say, that I find it as a perfect option also to just turn the opcache off, as a trait if you will for having an easygoing backend.