Article status for maintenance mode, returns HTTP status

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.

phiw13 · 2021-12-27 00:00:38

etc wrote #332325:

Isn’t pending status about the same?

I agree with Pete here. pending means the draft (text) is ready but need some approval – second pair of eyes, some layout and design work, etc.

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

I don’t remember, the hidden status makes the article 404 from the public side, right? Perhaps it could be repositioned to make it a 307 with appropriate error page?

etc · 2024-01-31 16:34:59

phiw13 wrote #332330:

I agree with Pete here. pending means the draft (text) is ready but need some approval – second pair of eyes, some layout and design work, etc.

Security-wise, should not we then disallow low privs users from pending articles modification?

phiw13 · 2024-02-01 00:40:05

etc wrote #336533:

Security-wise, should not we then disallow low privs users from pending articles modification?

Probably yes? The designer should be allowed to do some work if needed and the top-level users can either sent the article back for editing (draft) or approve for publishing.

etc · 2024-02-01 09:18:12

phiw13 wrote #336537:

Probably yes? The designer should be allowed to do some work if needed and the top-level users can either sent the article back for editing (draft) or approve for publishing.

Yes, that would give pending status some sense. We would also not sandbox these articles full preview, considering them as approved.

Textpattern CMS support forum

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

#25 2021-12-27 00:00:38

Re: Article status for maintenance mode, returns HTTP status

etc wrote #332325:

#26 2024-01-31 16:34:59

Re: Article status for maintenance mode, returns HTTP status

phiw13 wrote #332330:

#27 2024-02-01 00:40:05

Re: Article status for maintenance mode, returns HTTP status

etc wrote #336533:

#28 2024-02-01 09:18:12

Re: Article status for maintenance mode, returns HTTP status

phiw13 wrote #336537:

Board footer