Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2018-07-02 13:46:56

etc
Developer
Registered: 2010-11-11
Posts: 3,069
Website

Re: Outdated page after article publication

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.


etc_[ query | search | pagination | date | tree | cache ]

Offline

#12 2018-07-02 15:16:44

mikulas
Member
From: Czech republic
Registered: 2012-03-15
Posts: 28

Re: Outdated page after article publication

Hm, output is:

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

Offline

#13 2018-07-02 15:33:03

etc
Developer
Registered: 2010-11-11
Posts: 3,069
Website

Re: Outdated page after article publication

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…


etc_[ query | search | pagination | date | tree | cache ]

Offline

#14 2018-07-03 05:47:29

mikulas
Member
From: Czech republic
Registered: 2012-03-15
Posts: 28

Re: Outdated page after article publication

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.”

Offline

#15 2018-07-03 06:51:48

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,566
Website

Re: Outdated page after article publication

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.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#16 2018-07-03 08:37:02

etc
Developer
Registered: 2010-11-11
Posts: 3,069
Website

Re: Outdated page after article publication

Bloke wrote #312819:

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.

Neither arrogant nor mistake, it’s just that TEXTPATTERN_DEFAULT_LANG constant seems to be used both as txp site language code and server locale, which are different things. Possible solutions:

  • use C instead of TEXTPATTERN_DEFAULT_LANG in safe_strftime when generating headers;
  • add 'en' => array('en', 'en_GB.UTF-8', ... , 'C') entry to $locales in Locale.php;
  • switch from gmstrftime() to gmdate() when needed.

This locale thing is always a headache :-/


etc_[ query | search | pagination | date | tree | cache ]

Offline

#17 2018-07-03 08:42:54

gaekwad
Member
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 2,421

Re: Outdated page after article publication

Bloke wrote #312819:

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.

But is it actually RPC it’s trying to contact, or a JSON file version with a number inside?

Do we poll the .com site, GitHub or somewhere else for the update server check?

Offline

#18 2018-07-03 12:57:40

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,566
Website

Re: Outdated page after article publication

etc wrote #312821:

Neither arrogant nor mistake, it’s just that TEXTPATTERN_DEFAULT_LANG constant seems to be used both as txp site language code and server locale, which are different things.

Hmm, yeah. I vote for option 2 then as it’s the least intrusive. An extra entry in the $locales array seems logical, and it should probably be there anyway.

I’ve made a v4.7.2 branch so we can funnel such changes there and merge them to dev periodically.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#19 2018-07-03 13:12:12

gaekwad
Member
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 2,421

Re: Outdated page after article publication

gaekwad wrote #312822:

But is it actually RPC it’s trying to contact, or a JSON file version with a number inside?

Answering my own question: there’s a check made against https://textpattern.io/version.json, so not GitHub and not RPC.

There appears to be a json_decode on that JSON file above, so I wonder if the server is preventing the remote access and/or decoding of the file.

Also — possibly related — the problem_connecting_update_server translation currently resides under [prefs] in the Textpack list, shouldn’t that be [diag]?

Offline

#20 2018-07-03 13:12:27

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,566
Website

Re: Outdated page after article publication

gaekwad wrote #312822:

But is it actually RPC it’s trying to contact, or a JSON file version with a number inside?

Oh, duh, yeah, it’s using the same crappy error message string for the JSON version check. That’s wrong. It should either a) display something that doesn’t refer to the RPC, or b) not bother warning you at all. Does it matter if .com can’t be reached at the moment an update check is triggered? (e.g. if you’re developing offline or .com is temporarily down).

And if it matters, does it matter that it matters?

Do we poll the .com site, GitHub or somewhere else for the update server check?

We don’t poll per se. We just check if the file exists when you visit the Diagnostics panel and read the value in the file if so. It then sets a hidden pref to say it tried with the result of the last check – which may contain that error string or the message that a new version/beta is available – and when that test took place. If you revisit the Diagnostics panel within 24 hours, it’ll just read the pref value (last received message/error) and display that. If it’s been over 24 hours since last visit, it’ll go check the server again and refresh the hidden pref message.

We may be able to improve that, perhaps by just not registering the fact the server wasn’t available for whatever reason. Thoughts?


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

Board footer

Powered by FluxBB