Article status for maintenance mode, returns HTTP status

phiw13 · 2021-12-25 06:06:35

gaekwad wrote #332304:

Also interesting – I had considered 3** responses, but a 307 implies a redirect target is involved, and if there’s >1 articles going to a generic “be right back” page, that could be a mess to untangle. I suppose if it’s temporary then any sensible crawler would know this and stop back later, especially if I set a header to check back at a given time.

ref 410

yes, i know, but that was the one way I could get to work “easily”, in the sense of:

the site owner/manager can handle most of it
the user will encounter a reasonable message about the “story” being sought (it is coming back, hold on a moment… via a <txp:if_article_id />)
for the back-end caretaker (me) reasonably easy to implement and flip back once the issue are solve.
the search-engine where really of only secondary (eh… less and lower) importance

307 headers (a redirect to a temporary holding page – “this article will be back soon message” – covering the 3 or 4 articles that needed edit) would have been better in my case but i could not implement it, or get it to work, in an easy way — an easy to understand and handle way for stake holders — within Textpattern.

Maybe I should prepare some code snippets to have ready in case I need to implement something similar again. Of cours something similar won’t happen and the issue then will need some other approach.

gaekwad · 2021-12-25 14:47:30

Thanks, phiw13 – I think we’re largely of the same opinion overall, I’m grateful for your take on things, much appreciated.

Bloke · 2021-12-25 14:58:47

So can we figure out a workflow / page / form / article / custom field approach that would make a 307 doable?

gaekwad · 2021-12-25 15:28:04

Bloke wrote #332315:

So can we figure out a workflow / page / form / article / custom field approach that would make a 307 doable?

Knowing this place, all of the above.

Least work would be to hack together an article form, I think. I’ve got a few ideas but need to build a dev server to test on, so bear with me.

jakob · 2021-12-25 16:21:02

Bloke wrote #332315:

So can we figure out a workflow / page / form / article / custom field approach that would make a 307 doable?

I liked Pete‘s override form solution but if it’s not possible to return a 307 mid-page perhaps a logical txp-like solution would be simply a new status type such as „suspended“ with status=0 and a corresponding error_307 page template?

Bloke · 2021-12-25 16:36:05

jakob wrote #332317:

if it’s not possible to return a 307 mid-page

I fear not but you can always flip page/form logic around so one form contains the entire page content from HTML onward, which calls other forms in. Or the page template calls a form right at the top to deliver the header. Then override forms could be used to swap stuff in and out.

perhaps a logical txp-like solution would be simply a new status type such as „suspended“ with status=0 and a corresponding error_307 page template?

That’d be intriguing. I think the statuses are extensible via callback. Can’t remember if its in core yet or a branch, or just in my head!

etc · 2021-12-25 17:16:52

Bloke wrote #332315:

So can we figure out a workflow / page / form / article / custom field approach that would make a 307 doable?

The easiest way could be

<txp:txp_die status="307" url='redirect url here' />

jakob wrote #332317:

if it’s not possible to return a 307 mid-page

It should be possible, parsing is done before the headers are sent. Just try (even in an article)

<txp:header name="Location" value='new url' />
<txp:header name value="307 Temporary Redirect" />

phiw13 · 2021-12-26 09:00:40

etc wrote #332320:

It should be possible, parsing is done before the headers are sent. Just try (even in an article)
<snip />

I think I tried that and it did not work, but I might remember wrong, or/and there were other limitations that made this not a viable option. Memory is a little fuzzy. Must try this again.

jakob wrote #332317:

[…] a logical txp-like solution would be simply a new status type such as „suspended“ with status=0 and a corresponding error_307 page template?

I like that idea :-) Friendly to the contents managers as well. I could even imagine the error_307 page pulling in a <txp:article /> that the contents managers can easily edit depending on the needs of the day.

gaekwad · 2021-12-26 12:31:36

jakob wrote #332317:

[…] perhaps a logical txp-like solution would be simply a new status type such as „suspended“ with status=0 and a corresponding error_307 page template?

This is (largely) what I had in my head, with the caveat that article page stuff is sacred so we must tread carefully.

Or not, if we want to forge forward, perhaps.

etc · 2021-12-26 13:59:30

jakob wrote #332317:

a logical txp-like solution would be simply a new status type such as „suspended“ with status=0 and a corresponding error_307 page template?

Isn’t pending status about the same? I have never really understood (except semantics) why txp needs 3 ‘hidden’ statuses.

phiw13 wrote #332323:

I think I tried that and it did not work

It works for me.

gaekwad · 2021-12-26 14:19:20

etc wrote #332325:

Isn’t pending status about the same?

My read on pending is that the article is ready but needs to be approved by an appropriately powerful user.

I have never really understood (except semantics) why txp needs 3 ‘hidden’ statuses.

+1. I wonder if we’re missing some of the visibility on this stuff since – anecdotally at least – a large proportion of regulars here are likely the sole tenant in a Textpattern instance, i.e. there is no hierarchy / approval workflow for content.

Bloke · 2021-12-26 14:40:22

gaekwad wrote #332326:

there is no hierarchy / approval workflow for content.

Precisely. Hence the status-mods branch which was my attempt at grouping the status values into “published” and “unpublished”, and allowing plugins to more easily augment/change these designations. We currently have a sort of hierarchy insofar as >=4 is “on the site”. But the other status values are a bit nebulous.

The plan was to alter all our internal code so it checks for the status value being in one of the groups rather than greater than or less than a predefined constants.

That’s all good. The second piece of the puzzle I’ve yet to reconcile is how to make some kind of signalling when the status changes. The simplest would be a callback when the article is saved (or multiedit change status is actioned) passing old status, new status, and perhaps an indicator of whether that status is “higher” than it was (or maybe leave that to plugin authors). That would allow people to take action to signal people when something changes. The branch is about 95% complete.

Textpattern CMS

Textpattern CMS support forum

#13 2021-12-25 06:06:35

Re: Article status for maintenance mode, returns HTTP status

gaekwad wrote #332304:

#14 2021-12-25 14:47:30

Re: Article status for maintenance mode, returns HTTP status

#15 2021-12-25 14:58:47

Re: Article status for maintenance mode, returns HTTP status

#16 2021-12-25 15:28:04

Re: Article status for maintenance mode, returns HTTP status

Bloke wrote #332315:

#17 2021-12-25 16:21:02

Re: Article status for maintenance mode, returns HTTP status

Bloke wrote #332315:

#18 2021-12-25 16:36:05

Re: Article status for maintenance mode, returns HTTP status

jakob wrote #332317:

#19 2021-12-25 17:16:52

Re: Article status for maintenance mode, returns HTTP status

Bloke wrote #332315:

jakob wrote #332317:

#20 2021-12-26 09:00:40

Re: Article status for maintenance mode, returns HTTP status

etc wrote #332320:

jakob wrote #332317:

#21 2021-12-26 12:31:36

Re: Article status for maintenance mode, returns HTTP status

jakob wrote #332317:

#22 2021-12-26 13:59:30

Re: Article status for maintenance mode, returns HTTP status

jakob wrote #332317:

phiw13 wrote #332323:

#23 2021-12-26 14:19:20

Re: Article status for maintenance mode, returns HTTP status

etc wrote #332325:

#24 2021-12-26 14:40:22

Re: Article status for maintenance mode, returns HTTP status

gaekwad wrote #332326:

Board footer