Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

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

Re: Outdated page after article publication

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.

Online

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

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

Re: Outdated page after article publication

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.


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

Offline

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

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

Re: Outdated page after article publication

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?


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

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

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

Re: Outdated page after article publication

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!


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

#25 2018-07-03 14:44:15

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

Re: Outdated page after article publication

Bloke wrote #312834:

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.

Ah, yes – now I remember. Thanks for the reminder!

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.

Exactly what I was getting at, but you explained far more clearly than I did.

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?

I don’t know, honestly. This small spate of errors relating to problems connecting may just be a flash in the pan and can be easily managed now we’ve pinned down a few reasons why it could be happening. A doc would be far less work overall.

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.

Yes. And with some hosting changes we could find out the sweet spot with any rate limiter. The server overhead of RPC was, I suspect, far greater than this JSON route, and we can remedy that at the hosting end.

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?

Personally, I don’t think it’s a big deal. A niggle, with solutions for some/many/most people. Tag it with a 4.37 milestone!

Online

#26 2018-07-03 14:47:37

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

Re: Outdated page after article publication

Bloke wrote #312835:

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!

You don’t know what you miss! Done 1 in dev, let’s see.


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

Offline

#27 2019-01-12 09:43:57

Gallex
Member
Registered: 2006-10-08
Posts: 1,129

Re: Outdated page after article publication

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

as i experience the same problem for many years now and not only with articles – with forms, template and css pages as well. browser keeps the outdated data in it’s cache and to be sure, i need to clean it constantly.
i would like to know your opinion – do i have the same problem, can i do something about it?

i put below all the data you asked from mikulas.

- Site language: estonian User language: british english

- beginning of page template:
<!doctype html>
<html lang=”<txp:lang />” dir=”<txp:text item=“lang_dir” />”>

- Redbot information

- <txp:php>echo safe_strftime('rfc822');</txp:php> :
L, 12 jaan 2019 09:22:08 GMT

- <txp:php>echo safe_strftime('rfc822', get_lastmod(), 1);</txp:php> :
L, 12 jaan 2019 05:45:00 GMT

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

Fatal error: Uncaught exception 'Exception' with message 'Vigane argument' in 
/home/bs3215/domains/linnuvaatleja.ee/public_html/textpattern/vendors/Textpattern/L10n/Locale.php:195 Stack trace: #0 
/home/bs3215/domains/linnuvaatleja.ee/public_html/textpattern/publish/taghandlers.php(4248) : eval()'d code(1): Textpattern\L10n\Locale->setLocale(6, 
'en') #1 /home/bs3215/domains/linnuvaatleja.ee/public_html/textpattern/publish/taghandlers.php(4248): eval() #2 [internal function]: php(Array, 'echo 
Txp::get('...') #3 /home/bs3215/domains/linnuvaatleja.ee/public_html/textpattern/vendors/Textpattern/Tag/Registry.php(116): call_user_func('php', Array, 
'echo Txp::get('...') #4 /home/bs3215/domains/linnuvaatleja.ee/public_html/textpattern/lib/txplib_publish.php(547): Textpattern\Tag\Registry-
>process('php', Array, 'echo Txp::get('...') #5 /home/bs3215/domains/linnuvaatleja.ee/public_html/textpattern/lib/txplib_publish.php(471): 
processTags('php', '', 'echo Txp::get('...') #6 /home/bs3215/domains/linnuvaatleja.ee/public_html/textpatter in 
/home/bs3215/domains/linnuvaatleja.ee/public_html/textpattern/vendors/Textpattern/L10n/Locale.php on line 195

etc: The problem seems to be that en locale is not available on your server (which is rare)

do i have the same problem? actually i experience the same problem almost in every my site and in different host provider

Offline

#28 2019-01-12 10:43:56

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

Re: Outdated page after article publication

Try to update to 4.7.2, a tentative fix seems to be post-4.7.1.


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

Offline

#29 2019-01-12 12:11:55

Gallex
Member
Registered: 2006-10-08
Posts: 1,129

Re: Outdated page after article publication

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

it still displays:

Fatal error: Uncaught exception 'Exception' with message 'Vigane argument' in 
/home/bs3215/domains/linnuvaatleja.ee/public_html/textpattern/vendors/Textpattern/L10n/Locale.php:196 Stack trace: #0 
/home/bs3215/domains/linnuvaatleja.ee/public_html/textpattern/publish/taghandlers.php(4398) : eval()'d code(1): Textpattern\L10n\Locale->setLocale(6, 
'en') #1 /home/bs3215/domains/linnuvaatleja.ee/public_html/textpattern/publish/taghandlers.php(4398): eval() #2 [internal function]: php(Array, 'echo 
Txp::get('...') #3 /home/bs3215/domains/linnuvaatleja.ee/public_html/textpattern/vendors/Textpattern/Tag/Registry.php(116): call_user_func('php', Array, 
'echo Txp::get('...') #4 /home/bs3215/domains/linnuvaatleja.ee/public_html/textpattern/lib/txplib_publish.php(542): Textpattern\Tag\Registry-
>process('php', Array, 'echo Txp::get('...') #5 /home/bs3215/domains/linnuvaatleja.ee/public_html/textpattern/lib/txplib_publish.php(466): 
processTags('php', '', 'echo Txp::get('...') #6 /home/bs3215/domains/linnuvaatleja.ee/public_html/textpatter in 
/home/bs3215/domains/linnuvaatleja.ee/public_html/textpattern/vendors/Textpattern/L10n/Locale.php on line 196

Offline

#30 2019-01-12 12:23:24

Gallex
Member
Registered: 2006-10-08
Posts: 1,129

Re: Outdated page after article publication

and in site which runs PHP 7.2.1 and other host provider:

Fatal error: Uncaught Exception: invalid_argument: locale in 
/data01/virt77212/domeenid/www.koortikartul.ee/htdocs/textpattern/vendors/Textpattern/L10n/Locale.php:196 Stack trace: #0 
/data01/virt77212/domeenid/www.koortikartul.ee/htdocs/textpattern/publish/taghandlers.php(4398) : 
eval()'d code(1): Textpattern\L10n\Locale->setLocale(6, 'en') #1 
/data01/virt77212/domeenid/www.koortikartul.ee/htdocs/textpattern/publish/taghandlers.php(4398): 
eval() #2 [internal function]: php(Array, 'echo Txp::get('...') #3 
/data01/virt77212/domeenid/www.koortikartul.ee/htdocs/textpattern/vendors/Textpattern/Tag/Registry.p
hp(116): call_user_func('php', Array, 'echo Txp::get('...') #4 
/data01/virt77212/domeenid/www.koortikartul.ee/htdocs/textpattern/lib/txplib_publish.php(542):
Textpattern\Tag\Registry->process('php', Array, 'echo Txp::get('...') #5 
/data01/virt77212/domeenid/www.koortikartul.ee/htdocs/textpattern/lib/txplib_publish.php(466): 
processTags('php', '', 'echo Txp::get('...') #6 /data01/virt77212/domeenid/www.koortikartul.ee/htdocs in 
/data01/virt77212/domeenid/www.koortikartul.ee/htdocs/textpattern/vendors/Textpattern/L10n/Locale.p
hp on line 196

Last edited by Gallex (2019-01-12 12:37:51)

Offline

Board footer

Powered by FluxBB