Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#1 2007-09-02 14:42:59
- guiguibonbon
- Member
- Registered: 2006-02-20
- Posts: 296
status in txp:article as list
Hi there, been playing around with article status, and it looks like there’s room for a few imporvements. Mainly, it would be great if the status argument in txp:article and txp:article_custom would accept lists.
<txp:article status="3,4,5"/>or
<txp:article status="hidden,live,sticky"/>Currently this would require to do :
<txp:article status="3"/>
<txp:article/>Thereby causing twice as many queries, and not allowing to mix articles with a different status in a list.
Default would be live,sticky.
The searchsticky attribute is also something of a mystery to me. It looks as if it were some sort of quirk to allow to make certain articles not searchable by setting their status to sticky, which isn’t what status is meant for.
Also note that the documentation is incomplete : it doesn’t specify that you can use numbers, and doesn’t explain that the default behaviour is to list live and sticky articles, except in search results (which, again, makes no sense).
Last edited by guiguibonbon (2007-09-02 14:48:16)
Offline
Re: status in txp:article as list
The fact that it accepts anything other than ‘live’ and ‘sticky’ is something I’d consider a bug, but allowing a comma separated list (4 or 4,5 or 5) would be nice yes. Not going to happen in 4.0.x though.
Offline
#3 2007-09-02 17:08:52
- guiguibonbon
- Member
- Registered: 2006-02-20
- Posts: 296
Re: status in txp:article as list
The fact that it accepts anything other than ‘live’ and ‘sticky’ is something I’d consider a bug,
I’d look at it the other way around : the fact that statuses have names applied to them that actually don’t imply any particular behaviour is retarded. Let the users define how they’d like to use it. Imagine the W3C would build its website with textpattern : drafts still should appear. In my case, I’m building a front-end editor so i need drafts to be accessible.
Not going to happen in 4.0.x though.
Great. Let’s keep not going forward then, shall we. Not that I was expecting anything else.
Last edited by guiguibonbon (2007-09-02 17:12:15)
Offline
Re: status in txp:article as list
If you look at the SVN logs from the past days, you’ll see the amount of work it takes to bring 4.1 (crockery) back into sync with the 4.0.x branch…. and you want even more stuff to change in 4.0.x? The refusal to change things like this in 4.0.x is exactly what will enable us to move forward (with 4.1).
Offline
#5 2007-09-02 18:01:36
- guiguibonbon
- Member
- Registered: 2006-02-20
- Posts: 296
Re: status in txp:article as list
Yes, I’ve noticed. Perhaps that’s a sign that, as I said, it’s way too early for crockery. As I also suggested earlier, now might instead be the time to start porting some things from crockery to 4.0.x.
A few other things I’d like to bring to your attention :
- most of the new features in crockery that couldn’t be ported to 4.0.x. are rarely requested. They mostly fall in the “oh yeah why not” category, if not in the “feature-bloat” one.
- many rather simple feature-requests are not even starting to appear in crockery.
- I’m wondering when the moment will come you’ll all either acknowledge or realise that crockery won’t become 4.1 before a long long time.
Sorry for being offensive though, I know it’s not necessarily helping. But since a healthy debate about it all is persistently being avoided, I’m left with few alternatives.
Offline
Re: status in txp:article as list
guiguibonbon wrote:
- most of the new features in crockery that couldn’t be ported to 4.0.x. are rarely requested. They mostly fall in the “oh yeah why not” category, if not in the “feature-bloat” one.
Putting on my “user” hat, I wouldn’t consider nested sections or unlimited categories as feature bloat. YMMV.
Offline
#7 2007-09-03 11:46:38
- guiguibonbon
- Member
- Registered: 2006-02-20
- Posts: 296
Re: status in txp:article as list
Agreed, but plugins or workarounds do the trick for the time being. While more essential things still would need hacking in crockery (MLP for instance).
Last edited by guiguibonbon (2007-09-03 11:47:09)
Offline
Re: status in txp:article as list
guiguibonbon wrote:
Also note that the documentation is incomplete : it doesn’t specify that you can use numbers, and doesn’t explain that the default behaviour is to list
liveandstickyarticles, except in search results (which, again, makes no sense).
I think it’s the other way around. By default it just lists live articles, but when searching (only if searchsticky is set to 1) it also searches the sticky articles.
It’s true that the documentation doesn’t talk about being able to use numeric statuses, but that’s intentional, because as a TXP user you’re not expected to know the corresponding status numbers (using ‘live’ makes a lot more sense than ‘4’ in this context for most people).
Offline
#9 2007-09-03 20:20:08
- guiguibonbon
- Member
- Registered: 2006-02-20
- Posts: 296
Re: status in txp:article as list
Oh, you’re right. That’s worse than I thought : it means there’s no way to mix sticky and live articles in a list.
Take for instance that you’d like only sticky articles to show up on the front page, while you’d like them to appear amongst live ones on their section’s page. Granted, this could be achieved with categories, but still…
Offline
#10 2007-09-03 20:40:47
- guiguibonbon
- Member
- Registered: 2006-02-20
- Posts: 296
Re: status in txp:article as list
While delving a bit further in the code, I also noticed textpattern doesn’t paginate when you ask for sticky articles only : that’s odd.
edit : oh, wait, no, it makes sense since you would logically first have an article tag for stickies, then one for livies, if both went above their limit, the pagination would conflict. But in a perfect world, it should have been :
<txp:article status="4,5" sort="status, posted" limit="20"/>instead of
<txp:article status="5"/>
<txp:article/>edit 2 : now wondering what happens when you land on page 2 in the current scenario. The same stickies still show up?
Last edited by guiguibonbon (2007-09-03 20:48:21)
Offline
Re: status in txp:article as list
I’d love the option to combine list with more than one status whether as “4,5” notation or “live,sticky”, too.
In fact if I remember rightly the interleaved live and sticky list was previously normal behaviour (in 4.01/4.02? – can’t remember exactly) but was changed at a later date. Here’s the thread about the change in behaviour.
TXP Builders – finely-crafted code, design and txp
Offline
#12 2008-01-03 14:26:41
- guiguibonbon
- Member
- Registered: 2006-02-20
- Posts: 296
Re: status in txp:article as list
Sorry folks, don’t want to start YAR but I’m bumping this thread.
Ever since r1620, instead of using <txp:article sort="sticky desc"/> on article lists, you have to use :
<txp:wet_if_page>
<txp:article status="sticky" />
</txp:wet_if_page>
<txp:article />Which means : one extra plugin for something absolutely trivial, and two queries instead of one.
The argument against using status="live,sticky" is, to quote zem, that “ txp:article behaves differently depending on whether it’s displaying a sticky or live article “ which isn’t the case at all, since it all worked fine before r1620. Moreover, this whole confusion makes for contradictions in publish.php. For instance :
function doArticle($atts, $iscustom)
{
[...]
$theAtts = lAtts(array(
[...]
'status' => '4' //defaults to Live. Bye bye stickies, unless you have asked for them, and them only
),$atts, 0));Yet, a few lines further 780
$q_status = ($status ? 'and Status = '.intval($status) : 'and Status in (4,5)'); //totally useless line, since we just specifically defaulted status to 4So, my point : allow to use status="live,sticky" in the article tag and all is solved. There’s no backwards compatibility issue whatsoever, if you keep the default to 4. Sure, it all remains a bit confusing for noobs who will have to figure out how it comes their sticky article doesn’t show up.
Now, let’s get this a step further. I know you people don’t want us to display hidden articles. Know how that feels like, product-wise? Like my car disabling me to push the radiator button because it thinks it’s already warm enough. See, I might have my own reasons to want more heat. Just let me push the button already.
In other terms, let doArticle and doArticles do the txp_die magic, if they find no match to the request.
Anyway, I’m working on a patch.
Offline