[docs] Diagnostics panel

Bloke · 2015-10-01 12:10:04

Destry wrote #295294:

db_server_time etc

As far as I’m aware they’re staying. Given Txp’s somewhat lacklustre time management feature set at present, these values help us iron out article display issues due to server timezone / configuration mismatches.

Server TZ / Time zone… Redundant?

Possibly, yes. I think the first one is the “new” objecty way of getting the info, and the other is the legacy value read straight from prefs. The first string has the ‘TZ’ part of the string hard-coded (yuck) so we could combine them like this:

Time zone: <new way of getting TX info> (gmtoffset)

Perhaps when the date/time thing in core is fully resolved we can revisit this.

From a logical standpoint, [DST values] should be in the reverse order

Yeah, makes more sense, regardless that the auto-adjust thing is a legacy hack and will probably be shot, come the date/time revolution alluded to above. I’ll swap them over for now.

Note the suggested edits. Once the order is corrected, the context will be clear.

A lang string issue. Throw rocks there.

Destry · 2015-10-01 12:58:30

I’m starting to fall out of the Diagnostics panel context, sorry, but I don’t have the Preferences doc started yet. ;)

1) But this would require a code poke (and I’ll throw rock at textpacks repo):

Permalink title-like-this (instead of TitleLikeThis)?

A bit confusing, I’m sure. This would be better as a radio button, for example:

Permalink title pattern   
           ⚪️ Hyphenated (title-like-this)
           ⚪️ Intercapped (TitleLikeThis)

I’d default “hyphenated”, if that’s an issue, but the emoji wouldn’t work.

2) And this, definitely trivial but a tenet in form design nonetheless, could need a code poke too…

Logs expire after how many days?

The associated field might only be sized for one or two characters? Three at most? Currently the data box is ginormous.

Last edited by Destry (2015-10-01 13:10:27)

wet · 2015-10-01 14:29:54

Bloke wrote #295296:

Yeah, makes more sense, regardless that the auto-adjust thing is a legacy hack and will probably be shot, come the date/time revolution alluded to above. I’ll swap them over for now.

I beg to differ.

wet · 2015-10-01 14:37:12

Bloke wrote #295296:

The first string has the ‘TZ’ part of the string hard-coded (yuck)

This relates to the the technical background of the diagnostic output. It is not an arbitrary abbreviation.

In POSIX systems, a user can specify the time zone by means of the TZ environment variable.
www.gnu.org/software/libc/manual/html_node/TZ-Variable.html#TZ-Variable

wet · 2015-10-01 15:07:09

Destry wrote #295294:

2) Another observation:

Server TZ: Europe/Paris

Time zone: Europe/Paris (3600)

Redundant?

Not really. In fact, it helps to determine time-zone related problems.

An example:

textpattern.com runs on a server which has this diagnostics output:

Server TZ: UTC
Time zone: Europe/London (0)

Which we would read a such:

UTC is the default server timezone. It is determined according to a well-defined order of preferences.
In the application we have set a preference to use the “Europe/London” time zone to calculate times. Per this setting we calculate time with an offset of 0 (zero) minutes. We can easily set this preference to any other timezone which is supported by the particular version of PHP we are using. This will not affect the server’s default time zone settings a bit yet it will affect the time offset in minutes we are shown in brackets.

By inspecting this offset value we are able to determine if time-specific problems might stem from a wrong or outdated time zone database a.k.a. Olsen database.

Background: Timezone offsets are not stable over time, so the server’s time zone database might get stale if a server is not properly managed. E.g., the elderly among you might remember that DST in central Europe used to start a bit later and end a bit earlier than nowadays just a few years ago.

Bloke · 2015-10-01 15:23:57

Meh, shows what I know. Based on the gradual migration of Txp internals over to PHP DateTime objects and finding a way to fix the dates in Textpattern to either a) store a timezone along with the date, or b) store all dates in a well-known date system such as UTC, I figured that all the DST malarky would go away because PHP could handle it on our behalf.

Seems I’m very wrong so I’ll keep quiet on this issue from now on. Sorry folks!

Destry · 2015-10-01 15:43:02

@wet: Your input is invaluable. Thank you. It helps to produce accurate docs.

@Bloke: Don’t wander off, your perspectives are extremely helpful. I guess we all learn from these deep dives. Heck, I’m learning more than I need/want to, but someone’s got to write these docs properly. ;)

michaelkpate · 2015-10-01 16:25:51

As far as Timezone settings:

Server TZ: America/Los_Angeles
Server local time: 2015-10-01 09:23:10
Time zone: America/New_York (-18000)

patetech.info is hosted by Dreamhost and obviously I am nowhere near there.

Destry · 2015-10-01 17:45:11

I’m still playing catch-up with the thread, and currently cooking dinner. So before anyone hangs me about what’s in the doc at the moment, please bear with me until I get to the ‘that’s a wrap’ stage for this particular page.

In the meantime, in addition to the great background information about server tech and time management, it would be even more helpful — or at least quicker — to just tell me what might be a good descriptor to add in each case where you see they are horribly wrong. Ya.

Destry · 2015-10-05 08:15:10

Using an updated install of 4.5.7 with language strings updated as well… I’m having problems identifying some diagnostic messages when cross-referencing the txp_diag.php file and the ‘txp_lang’ table. This is not my comfort zone by any means. I could use some help.

Referring to the yellow warnings and red errors in the doc

Warnings (yellow):

path_to_site_missing (Bloke says he sees this name in his ‘txp_lang’ table. I don’t see it in mine, and my language strings are updated. Because I don’t see it, I can’t provide the actual ‘data’ value, or description.)
warn_mail_unavailable (Again, I don’t see this in my ‘txp_lang’ table, but this may be a bug because Bloke says it’s not being pulled down to local DB table, and Pete says it is in RPC. Regardless, I still need to know what the ‘data’ value is to update the actual message here, and give a description. Can anyone say?)
Everywhere you see a [todo:explanation] needs a short explanation about why the warning might be appearing. Please offer one. Otherwise I’m just guessing, badly.

Errors (red):

[todo:explanation] Same deal… help me out.

Warning? Error?:

This one is left out of the doc page until further clarification.

path_not_doc_root (This was apparently scraped from the txp_diag.php file and is in the ’txp_lang’ table, but does not have a ‘data’ value, nor does Bloke find the item in the textpack at all. Phased out? A code thing to clean up?)

Destry · 2015-10-05 08:18:20

michaelkpate wrote #295245:

Is that an error in the Docs or in the Code?

Thanks. That was a typo. Probably missed the “Y” when copy/pasting. ;)

The message, as corrected, is pulled directly from the ‘txp_lang’ table.

Textpattern CMS

Textpattern CMS support forum

#13 2015-10-01 12:10:04

Re: [docs] Diagnostics panel

Destry wrote #295294:

#14 2015-10-01 12:58:30

Re: [docs] Diagnostics panel

#15 2015-10-01 14:29:54

Re: [docs] Diagnostics panel

Bloke wrote #295296:

#16 2015-10-01 14:37:12

Re: [docs] Diagnostics panel

Bloke wrote #295296:

#17 2015-10-01 15:07:09

Re: [docs] Diagnostics panel

Destry wrote #295294:

#18 2015-10-01 15:23:57

Re: [docs] Diagnostics panel

#19 2015-10-01 15:43:02

Re: [docs] Diagnostics panel

#20 2015-10-01 16:25:51

Re: [docs] Diagnostics panel

#21 2015-10-01 17:45:11

Re: [docs] Diagnostics panel

#22 2015-10-05 08:15:10

Re: [docs] Diagnostics panel

#23 2015-10-05 08:18:20

Re: [docs] Diagnostics panel

michaelkpate wrote #295245:

Board footer