Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#1 2014-04-03 18:51:31
- worths1
- Member
- Registered: 2005-03-08
- Posts: 18
More flexible publication status
I love the flexibility of Textpattern. Non-programmers (like me) can tailor a pretty refined set-up.
After a little bit of a break, I’m digging in again. Unless I have missed a change in 4.5, I think the publication status is the same as in prior versions. I have a couple of requests. (They are alternatives to each other).
The easier one: Drop the “sticky” status. It could just as well be a category, and I think it would be easier to use that way, at least as I use them. (BTW, does anyone use a “sticky” category instead of the publication status?)
The harder one: During setup, let us name and define the publication statuses we need. Require a minimum of two, one unpublished and one published, but allow us to name more than one of each type. For example, I could create “Draft (unpublished),” “Private (published)”, and “Public (published),” and then via a plug-in limit viewing of private articles to those who have logged in. (Of course, the default could be the existing five, if you wanted).
Offline
Re: More flexible publication status
worths1 wrote #280046:
The easier one: Drop the “sticky” status.
It is a bit strange, but it can be handy so I don’t think we’ll be ditching it. Plus it saves using up a category, which are currently limited.
let us name and define the publication statuses we need.
Status levels are very ingrained in Txp’s inner workflow unfortunately so altering them is non-trivial. They can be renamed at will of course (via the wet_babble plugin, for example) but you won’t get away from the fact that only two of them can be displayed on the public-facing site. Well, the ‘non-live’ articles can be previewed, but you don’t want to go around hacking that.
A short admin-side plugin can easily hide any unused status levels, the remainder you can rename as I mentioned above. But to effect an operational change will require a little bit of cunning. In this case I’d propose removing Hidden and Pending which leaves you with:
- Draft, which works as now.
- Public (a.k.a. Live), which works as now.
- Sticky which you could re-engineer for private use by installing the rvm_privileged plugin and wrapping it around a
<txp:article status="sticky" />
tag. Only logged-in users will see the sticky ones, which you can rename via wet_babble to ‘Private’.
How’s that?
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
#3 2014-04-04 01:06:29
- worths1
- Member
- Registered: 2005-03-08
- Posts: 18
Re: More flexible publication status
Thanks for that. I will give it a go.
I continue to wonder whether, longer term, you might still consider tearing out some of the hard-wired parts in exchange for something general. To at least one untutored mind, a Textpattern article needs an id, a title, a body, a creation date, a section and publication status. The rest — custom fields, categories, excerpt, et al. == could be customizable fields. But I’m sure I’m suggesting too much. Ignorance of the innards is bliss . . . or maybe it’s just ignorance, plain and simple.
Last edited by worths1 (2014-04-04 01:08:21)
Offline
Re: More flexible publication status
worths1 wrote #280054:
I continue to wonder whether, longer term, you might still consider tearing out some of the hard-wired parts in exchange for something general.
Never say never. As long as we enforce the concept of at least one “published state” and one “non-published state” then, in theory, anything else could be customisable / extensible.
At the moment, Pending doesn’t have much meaning attached to it. To be able to hook that into a classical draft-approve-publish workflow where relevant people are notified when an article is marked Pending so it can be edited/approved for publication would be great. That’s probably plugin territory (in fact,m there might be one already), along with the ability to define your own status codes and do things with them.
But for any of that to happen, the core’s current reliance on “anything greater than 4 (live) means a published state” would need altering in favour of more explicit checks for actual status levels. One day…
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
Re: More flexible publication status
Hey, I use ‘sticky’ status on articles all the time for various tasks, can’t drop that.
I agree the ‘pending’ status is pointless though, unless a proper drafting revision and approval system is put in place one day.
Offline
Re: More flexible publication status
philwareham wrote #280067:
I use ‘sticky’ status on articles all the time for various tasks, can’t drop that.
I do to. It ain’t going anywhere any time soon.
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
#7 2014-04-05 00:48:28
- worths1
- Member
- Registered: 2005-03-08
- Posts: 18
Re: More flexible publication status
I use “sticky” too, and I don’t dismiss it as a concept. It is no less logical to treat it as a setting outside of publication status, though. It might even be useful to retain the “sticky” setting in an article someone needs to temporarily hide.
A related issue, and this may be picking a speck off a nit, are multiple article tags. I think the article tag should be processed exactly once on a TXP page. I suppose there are ways to accomplish that — I haven’t tried hard enough — but the only way I know to create a TXP page that can publish either sticky or live articles is to pair two article tags, one for each status setting. There may be valid reasons for this set-up, but from my limited vantage it appears to be a quirk.
Offline
Re: More flexible publication status
I always thought that “sticky” meant that an article / story would always remain at the top of the list. That it would always remain first in a list of many. But in text pattern i don’t know what it’s used for.
…. texted postive
Offline
#9 2014-04-05 04:17:33
- worths1
- Member
- Registered: 2005-03-08
- Posts: 18
Re: More flexible publication status
bici, that’s essentially how I use it but it’s more flexible than that
I use it when someone points their browser to certain sections. “/index.php?s=about” pulls the list of articles in the “About” section, but I always want to serve up the same one article even if there are more recent articles in that section. By making the preferred article “sticky” and using the tag <txp:article status=“sticky” limit=“1” listform=“single_article” />, I get what I want. (BTW, double check my syntax, I’m working off memory.)
I’m going to try what Stef suggested and use “sticky” for private articles. I hope I can keep the same functionality by using a custom field to assign a sticky faux-status. I think it should work, but I live in the land of guess and check. We will see.
Offline
Re: More flexible publication status
ah ha! i didn’t realize that i had to use a special tag to enforce “stickiness”
<txp:article status=“sticky” limit=“1” listform=“single_article” />
…. texted postive
Offline
Re: More flexible publication status
Bloke wrote #280052:
I’d propose removing Hidden and Pending which leaves you with:
- Draft, which works as now.
- Public (a.k.a. Live), which works as now.
- Sticky which you could re-engineer for private use by installing the rvm_privileged plugin and wrapping it around a
<txp:article status="sticky" />
tag. Only logged-in users will see the sticky ones, which you can rename via wet_babble to ‘Private’.
How’s that?
Agreed – we never use Hidden or Pending. Taking two pointless options off admin makes sense, with or without the sticky re-engineering.
Last edited by towndock (2014-04-05 12:46:10)
Offline
Re: More flexible publication status
I also use hidden, or rather some of my clients do when an article becomes obsolete (sometimes content has to be removed to meet legal regulations). So I’d want that (or something equivalent) to stay.
Offline