Outdated page after article publication

mikulas · 2018-06-30 18:05:13

I have moved my site on the server with PHP 7.1 version in order to upgrade site to textpattern 4.7.1. Everything works well, but I have noticed suddenly, that the page keeps outdated version after publication of a new article and I must reload the page every time manually.
Settings “Send Last-Modified header” is set to yes and I´m afraid this is what´s not working.
Can advice me anybody, what configuration must be on server? What must be turned on for immediate changes on the page?
Thanks a lot. (I´m sorry for my czEnglish.)

Diagnostic info:

Textpattern version: 4.7.1 (e4c580b0c6085893e75ffc61b1b89844)
Last update: 2018-06-29 21:15:41/2018-06-29 21:13:35
Textpattern path: __TXP-ROOT/textpattern
Article URL pattern: messy
Production status: live
PHP version: 7.1.18
GD Graphics Library: bundled (2.1.0 compatible); Supported formats: GIF, JPEG, PNG.
Server timezone: Europe/Prague
Server local time: 2018-06-30 19:40:44
Daylight Saving Time enabled?: 1
Automatically adjust Daylight Saving Time setting?: 1
Time zone (GMT offset in seconds): Europe/Prague (3600)
MySQL: 5.5.56-MariaDB (MariaDB Server) 
Database server time: 2018-06-30 19:40:44
Database server time offset: 0 s
Database server timezone: SYSTEM
Database session timezone: SYSTEM
Locale: cs_CZ.UTF-8
Site / Admin language: cs / cs
Web server: Apache
PHP server API: cgi-fcgi
RFC 2616 headers: 0
Server OS: Linux 3.10.0-862.3.3.el7.x86_64
Admin-side theme: hive 4.7.1
Pre-flight check: 
------------------------
problem_connecting_update_server
The following PHP functions (which may be necessary to run Textpattern) are disabled on your server: phpinfo, symlink, pfsockopen, syslog, define_syslog_variables, openlog, closelog, disk_free_space, diskfreespace, disk_total_space.

etc · 2018-07-01 14:48:35

Everything seems to work fine on the demo site, please test. To see what happens in your case we’d need to inspect request/response headers. Mind providing an URL?

colak · 2018-07-01 15:11:51

Did you force refresh the browser or empty the cache?

mikulas · 2018-07-01 16:20:27

To see what happens in your case we’d need to inspect request/response headers.

I’m trying to get some information at redbot.org

   HTTP/1.1 200 OK
    Date: Sun, 01 Jul 2018 16:05:14 GMT
    Server: Apache
    ETag: "1djhuk7"
    Set-Cookie: adi_mobile_viewport=%3F%2C%3F%2C%3F; path=/
    Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT
    Keep-Alive: timeout=5, max=100
    Connection: Keep-Alive
    Transfer-Encoding: chunked
    Content-Type: text/html; charset=utf-8

colak · 2018-07-01 16:28:51

This is interesting!

Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT

etc · 2018-07-02 11:22:27

colak wrote #312789:

This is interesting!

Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT...

Yep, that’s weird, ETag looks correct nonetheless. @mikulas, could you test this code in some hidden article (with Textile disabled):

<txp:php>echo safe_strftime('rfc822');</txp:php>

It should output the current GM time.

gaekwad · 2018-07-02 11:32:34

Hmm, also another instance of problem_connecting_update_server in the diagnostics – did we figure out why that appears?

mikulas · 2018-07-02 12:08:32

The result is correct date: Po, 02 čec 2018 12:02:16 GMT

etc · 2018-07-02 12:17:14

mikulas wrote #312804:

The result is correct date: Po, 02 čec 2018 12:02:16 GMT

Hmm.. and this one?

<txp:php>echo safe_strftime('rfc822', get_lastmod(), 1);</txp:php>

Edit: by any chance, have you modified TEXTPATTERN_DEFAULT_LANG constant in some way? Test

<txp:php>echo TEXTPATTERN_DEFAULT_LANG;</txp:php>

Last edited by etc (2018-07-02 12:29:02)

mikulas · 2018-07-02 12:43:49

Hm.. and this one?
<txp:php>echo safe_strftime(‘rfc822’, get_lastmod(), 1);</txp:php>

Po, 02 čec 2018 12:11:36 GMT

etc · 2018-07-02 13:46:56

A possible explanation: Last-Modified header must use English abbreviations, but the site language is cs in your case. This is fine per se, since txp switches to TEXTPATTERN_DEFAULT_LANG when generating this header, and TEXTPATTERN_DEFAULT_LANG is en by default (unless defined otherwise in config.php). The problem seems to be that en locale is not available on your server (which is rare), thus the generated Po, 02 čec 2018 12:11:36 GMT header is invalid. To check, try

<txp:php>echo Txp::get('\Textpattern\L10n\Locale')->setLocale(LC_ALL, 'en')->getLocale();</txp:php>

it should output en.

mikulas · 2018-07-02 15:16:44

Hm, output is:

Fatal error: Uncaught exception ‘Exception’ with message ‘Neplatný argument’ in

etc · 2018-07-02 15:33:03

mikulas wrote #312809:

Hm, output is:

Fatal error: Uncaught exception ‘Exception’ with message ‘Neplatný argument’ in

Yes, that’s what I feared. Actually, that’s what I get on my live server too, so the problem of missing en locale is not so uncommon. In this case txp uses the site language to output Last-Modified header, and I’m not sure every browser can translate it. We should patch it somehow (use C locale, perhaps), though I don’t understand why date headers in French seem ok, but not in Czech. Mystery…

mikulas · 2018-07-03 05:47:29

Problem partly solved. I created a new database, made a new installation of Textpattern 4.7.0 and refilled the database tables. Articles publishing works well now.
But what’s strange, there is still diagnostic message “problem_connecting_update_server”.
In addition, I found out: when I add a new user and he clicks on password confirmation, he gets an error message
“Password reset security token is invalid.”

Bloke · 2018-07-03 06:51:48

Thanks for sleuthing this, you guys. Perhaps arrogantly assuming en exists is a mistake, but I’m not sure how to defend against it sensibly. Ideas welcome.

And that ‘cannot connect update server’ is baffling too. With the removal of RPC in 4.7, it shouldn’t even be trying to reach it. Hmmm.

Textpattern CMS

Textpattern CMS support forum

#1 2018-06-30 18:05:13