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

Textpattern CMS

Textpattern CMS support forum

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