Outdated page after article publication

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.

etc · 2018-07-03 08:37:02

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 :-/

gaekwad · 2018-07-03 08:42:54

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?

Bloke · 2018-07-03 12:57:40

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.

gaekwad · 2018-07-03 13:12:12

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]?

Bloke · 2018-07-03 13:12:27

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?

gaekwad · 2018-07-03 13:28:39

Bloke wrote #312831:

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

For most people, I would wager it’s a non-issue. That said, a couple of considerations from Cap’n Edgecase McGee (me):

I’d be interested to see the effect of limiting that check to once per 24 hours, and whether that could be made shorter or even removed. I don’t have stats, but serving a ~80 byte file tens of thousands of times a day is pretty trivial and low effort on a good web server running a cookie-less domain.
Some kind of log may perhaps be useful in Full Fat Diagnostics mode or in a debug log elsewhere. The function grabs the JSON, decodes it, sets some variables, checks the variables, and then does stuff depending on the variable. If it bails out, then it shows a message (as designed), but there’s no real insight as to why it didn’t work.
From a UX point of view, I find the idea of a ‘check for updates now’ workflow somewhat appealing and reassuring. Perhaps with a modal, a Publisher (admin) can run a check on version.json and optionally see the verbose output:

Connecting to update server: SUCCESS
Checking update status: SUCCESS
Available version: 4.7.1
Installed version: 4.7.1
Update available: FALSE

The risk there might be the assumption that an automated installer is available, which currently isn’t true, so expectations should be managed there.

etc · 2018-07-03 13:59:16

Bloke wrote #312828:

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 agree it seems logical, but leave the decision with you. Nevertheless, this would not suffice if TEXTPATTERN_DEFAULT_LANG is set to something else. It looks like RCF822 date format explicitly requires English, so I would vote for 1 or 3.

It’s strange that the problem has not appeared before, though.

Bloke · 2018-07-03 14:33:37

gaekwad wrote #312832:

whether that [update check rate limit] could be made shorter or even removed.

True, it was only to be kind to our hoster and the RPC server, which would often flake out at release time when thousands of people downloaded a new version and ran updates at once.

I don’t see any reason to check more often than once a day given our current release cycle, but we could probably reduce that check to every few hours without too much impact. Especially since it only performs the check on the Diagnostics panel, which isn’t everyone’s go-to tab.

That would also mean that if you do re-establish the network connection or find whatever was the blockage, you aren’t shown the slightly confusing, stale message “unable to connect” that is read from prefs for the next 24 hours.

Some kind of log… no real insight as to why it didn’t work.

We don’t currently have any logs, besides what you see in Diagnostics. Three primary reasons the check would fail:

You’re offline. You’d know this, one would hope.
The server is offline. Might be a temporary glitch/routing/DNS issue. Should resolve next time a check is performed.
The hoster has prevented remote reading of resources (forbidding allow_url_fopen is the main one). In this case, it’s a “permanent” error as there’s nothing we can do in code, besides report it.

At the moment we treat these all the same: “connection failed”. Should we be more clever and do more fine-grained checks here and report accordingly? Implies more strings. Worth it?

‘check for updates now’ workflow

That would indeed be nice. So it’d auto-check (perhaps) as it does now but if you then figured out why a no-connection issue arose, you wouldn’t have to wait for the timeout before checking again as you could trigger the check manually.

But, as you say, to what end? The only thing it does is offer a link to the website so you can download it. No auto-unpack or auto-install (yet). Nothing a visit to the textpattern.com home page can’t do (assuming that’s on their radar in the first place).

Playing devil’s advocate, is it worth pursuing for the minimal current gains, or is this something we could revisit if/when we ever have an automated remote installation process?

Bloke · 2018-07-03 14:35:12

etc wrote #312833:

this would not suffice if TEXTPATTERN_DEFAULT_LANG is set to something else.

Ah, right. In which case, I agree 1 or 3 is a better option. I have no strong opinion either way. Being English, locales and languages are not my forte!

Textpattern CMS

Textpattern CMS support forum

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

Re: Outdated page after article publication

mikulas wrote #312809:

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

Re: Outdated page after article publication

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

Re: Outdated page after article publication

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

Re: Outdated page after article publication

Bloke wrote #312819:

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

Re: Outdated page after article publication

Bloke wrote #312819:

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

Re: Outdated page after article publication

etc wrote #312821:

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

Re: Outdated page after article publication

gaekwad wrote #312822:

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

Re: Outdated page after article publication

gaekwad wrote #312822:

#21 2018-07-03 13:28:39

Re: Outdated page after article publication

Bloke wrote #312831:

#22 2018-07-03 13:59:16

Re: Outdated page after article publication

Bloke wrote #312828:

#23 2018-07-03 14:33:37

Re: Outdated page after article publication

gaekwad wrote #312832:

#24 2018-07-03 14:35:12

Re: Outdated page after article publication

etc wrote #312833:

Board footer