Why is there no $page->isPublished() method?

[bfncs]

Hello everyone,

looking at the API docs I just noticed, that in the class Page there is a method isHidden() but no method isPublished(). As I understand it, the proper way to to get the published status would be:

$isPublished = !($page->is(Page::statusUnpublished));

Since I'm ok with that, I think it is a little incoherent to have a convenience method for the first but not for the latter. Or did I miss something here?

P.S.: What I want to do is to show some infos in the frontend to the content editors like whether the page is hidden or published. Just looked strange in my code so far.

[apeisa]

Usually I use: $page->viewable()

It is little different, since it does access checking etc.

I think there isn't isPublished() by historical reasons - we didn't have "published/unpublished" status at some point.

Hidden is different from published: hidden pages can be viewable, but by default they are excluded from find(), children() etc selectors.

[bfncs]

Hi apeisa,

thanks for the quick answer!

The hint with $page->viewable() is very much appreciated, I didn't think of using it for this because I thought, it was only concerned with access rights management and not with the page status itself. Very good to know for a lot of use cases.

Still, this doesn't really cover my use case, because I want to explicitly echo both statusses for unpublished and hidden. I'm just going with something like this now:

echo $page->is(Page::statusHidden) ? 'hidden' : 'not hidden';
echo $page->is(Page::statusUnpublished) ? 'not published' : 'published';

I'm totally fine with it. I just had it with $page->isHidden() before which looked strange and made me feel like I missed something at some point.

So, not really a need to change, just a little incoherence here. On the other hand, to make it coherent it would need to either provice a convenience method for all statuses (which seems a little over the top) or to omit them all (which breaks backwards compability). It seems the best way would be to leave everything as it is.

[Soma]

Did you know the cheatsheet already: http://processwire.com/api/cheatsheet Not in relation to your question, just so.

What apeisa said. Also the statuses is a bitmask, not that I understand it well, but it's like making visible and hidden both a status, which doesn't make sense it's either hidden or not, then it's visible. I'm not sure this makes sense. And only Ryan would be able to share some light, why it is how it is.

[bfncs]

Thanks for pointing this out, Soma. The cheatsheet is already constantly open as a pinned tab in my browser since I startet working with Pw. Really helpful stuff!

I did get that the statuses are bit fields and this also makes a lot of sense since they are performant and saving memory. There are good explanations on how this works on Wikpedia:

• Bit field
  
• Bit mask
  

[...] but it's like making visible and hidden both a status, which doesn't make sense it's either hidden or not, then it's visible.

In practice this just works like having an array of bool vars for all of the possible statuses, so you're right, it's impossible to have it hidden and not hidden at the same time. A bool is excatly one bit of information, but because it's not efficient to adress your memory bitwise, it will take up a lot more bits in the computer memory (just looked it up: this is actually defined by your PHP source and usually one byte). The bitfield works like an array so you can stuff multiple single bits of information in the space that one integer value takes in memory and to evaluate single bits of information from it, you use the bitwise AND operator with a bitmask to select it.

[Joss]

I personally think the Cheatsheet should be made into a nice tea-towel that I can frame on the wall.

Just a bit on docs - the ideal (for me, at any rate) would be to have the cheat sheet, complete with its short hand explanations (which are good!) and then a link to a longer explanation and real-world example or two.

If anyone ever writes one anything for any of the items on the Cheatsheet, stick it on the wiki, or send it to me and I will stick it on.

.... we didn't have "published/unpublished" status at some point.

That must have been fun! (And potentially a bit of a shock for the unwitting....)

Joss

[apeisa]

Just a bit on docs - the ideal (for me, at any rate) would be to have the cheat sheet, complete with its short hand explanations (which are good!) and then a link to a longer explanation and real-world example or two.

That is a brilliant idea!

I think that and full featured "build your first website" -tutorial should be main focus on documentation side at the moment.

[bfncs]

I personally think the Cheatsheet should be made into a nice tea-towel that I can frame on the wall.

Just a bit on docs - the ideal (for me, at any rate) would be to have the cheat sheet, complete with its short hand explanations (which are good!) and then a link to a longer explanation and real-world example or two.

I think that and full featured "build your first website" -tutorial should be main focus on documentation side at the moment.

That's not very creative, but: 3x +1

[Martijn Geerts]

I have printed the cheatsheet on large paper & sticked to the wall . tnx Soma

(I wish I could create a large PDF from it & let it print very large)

[Joss]

I have printed the cheatsheet on large paper & sticked to the wall . tnx Soma

(I wish I could create a large PDF from it & let it print very large)

Collage perhaps?

Anyone with a kid doing art needs a project???

On a slightly less zany note, maybe not a bad idea to redo it as a series of nicely laid out and branded PDF pages that people can print out.

I still find the old fashioned type of manual (you know, the one with that paper stuff and pretty covers) the best thing to use for most things. After a while, even in the biggest manual, you can instinctively find the right page just by how much the corners have turned up. Hell, in a really trusted and well used manual you can find things by smell and coffee stains alone!

I have yet to find ANY software based system that can replicate that level of super-personalised interactivity.

Joss

[Joss]

I think that and full featured "build your first website" -tutorial should be main focus on documentation side at the moment.

Which begs the question, which sort of website?

From the planets tutorial you can see how to create a basic sort of website, but what if you want to add a gallery, or create a contact form, what about meta data?

There are a lot of variations and it would be difficult to guess someone's priorities. So, how about this?

Stage One

So, you start with a fairly agnostic site with a header and footer - incredibly simple framework with a masthead banner, menubar and common footer with text and a logo in it. Dump the side bar for the moment - it is a distraction. So you would want to cover getting rid of stuff you dont need.

Also, do some housework like change the name of the admin page, add a couple of very useful modules (crop image, module manager,repeater, etc) iand update the JQuery for the front end of the site.

Next create a site settings template (without file) and page combination for site name, site meta keywords and description and a top banner image and demonstrate how to pull that data into your header and footer.

And then you edit the home page information just to make sure it works.

That is the intro.

Stage Two - well, lots of stage twos

After that you can fork out with child articles. Each one can cover one scenario: news page, contact form, team page, Flexslider show, and so on. Each one must fit into the site created with stage one and must not conflict with the other child articles.

That way, users can find their own route through this based on their own priorities rather than having to wade to the bit they are interested in.

As an offshoot, it would also make clear some good ideas about how to manage a site as it becomes more complicated by getting the planning at the beginning right.

This is a good way of getting some new website people in before they go and weld themselves to Droolapress (see what I did there?) while saying to more experienced users, "we know what your most common tasks are, so here they are, ready to go."

Joss

[Soma]

And all because theres no pagePublished? :-P

I thinks sounds like a cool concept. One thing pops to mind. There is so many ways to archive one thing you can hardly cover all, and youd have to make sure they are seen as one way to do it, practices and examples. Not set to stone that people think that's it exactly. This is where it can get complicated. At the end it is important to understand the consequences a certain approach may has and what needs to be accomplished. Since you do also all of the front end coding and there's even more variation that can happen there, there will be a lot of the non coders lost and a lot of assistance is needed. For me PW got me started thinking a lot more before doing something and a lot comes from trying out different things, adding some fun and think about structures.

What i'm trying to say is maybe PW is more a way of thinking living breathing rather than 'this is the way...'

Im excited to see it's growing thanks so muchos Joss!

[Soma]

What i also forgot to add ( my brain ) is i would have problems where to draw the line between php and pw mb just throw in some php manual links here and there.

[diogo]

Soma, PW is flexible to that point. You can tell people one simple way to achieve something, and they will discover with time that there is plenty more beyond that. This is what happens already with the default install.

[Joss]

Soma,

I agree - and however a manual is laid out the point must be made that there are alternatives, without listing so many that it becomes like wading through treacle made of skinned cats.

Umm ... one metaphor too many, me thinks.

[Soma]

I'm just seeing it there's this sidebar boxes, really nice!

[Joss]

Specially designed just for you

[Soma]

Joss, that's exactly my green!

I think it would ne nice to have $pages->isPublished()? Also not biggy to add and make it coherent.

$page->viewable() will

- return false also if there's not temlplate file found for it.

- It will return true even if published, but the user has edit rights.

There's

$page->isTrash()

$page->isNew()

$page->isLoaded()

$page->isChanged()

$page->isHidden()

why not

$page->isPublished()

[bfncs]

Hi there again,

wow, this thread really wandered of to some completely different topic that is more interesting though.

I like the aim for publishing more and better tutorials for Pw, this should really be done! Why don't we open a new forum thread for this (but in which subforum?), make a roadmap for possible tutorials where everyone can volunteer to write one? While still being new here, I'd definitely contribute, and it looks like some of you would like to give back this way, too.

If this turns out, that we can get a decent amount of tutorials, these might be published outside of the forums afterwards, to make them more accessible. It would also be nice to work on something like a guideline for tutorials to make them coherent. What do you think about this?

On the topic this thread was about originally, I can only repeat that imho Page::isPublished() would make sense, but I'm also completely ok with not doing it if the risk of entering a slippery slope of more and more convenience wrapper methods that trash up the API is too high here.

[Joss]

I know it is meant to be bad forum etiquette, but I like threads that wander everywhere.

I know it makes them hell to search and difficult to keep track of, but they reflect how people think in real life, how they communicate - and that is fun!

Back to the subject, having isPublished would be a useful test to have floating around. To expand on that, I wonder what the possibility is of expanding states and the resulting checks in a custom way?

For instance, if you create a very complex news site with proper newsroom style editorial control, an article could have a lot of states - draft, in editorial consultation, submitted to desk, returned to author, notated for editing, submitted for copy, marked as approved for publication, in pre-pub editing, published, archived, rejected, referred to legal .... it can get interesting!

Obviously, for 99.9% of the time, you don't want all those cluttering up the system, but some might like to add states in their own installation/site profile. Perhaps these can all be handled by a module which would allow a bit more versatility ....

Joss

[Soma]

Joss that's a nice list of states, just create them using page field reference and you can have as much as you want. But you'd also have to fill them with functionality or they will be just skinned cats

[Joss]

Well, that got my dog's attention! She prefers the contents to the skin as well.

[bfncs]

No offence intended, it's just funny how this thread evolved.

I'm still thinking that it might make sense to start a new thread if some people want to put some shared effort in producing nice tutorials - still don't know where to open it though.

To expand on that, I wonder what the possibility is of expanding states and the resulting checks in a custom way?

For instance, if you create a very complex news site with proper newsroom style editorial control, an article could have a lot of states - draft, in editorial consultation, submitted to desk, returned to author, notated for editing, submitted for copy, marked as approved for publication, in pre-pub editing, published, archived, rejected, referred to legal .... it can get interesting!

Obviously, for 99.9% of the time, you don't want all those cluttering up the system, but some might like to add states in their own installation/site profile. Perhaps these can all be handled by a module which would allow a bit more versatility ....

Hm, just wondering what the benefit of a multitude of system states opposed to fields would be? I mean: what would you be able to do with system states, that you can't do with normal fields?

Edit: oh, sorry... I completely overlooked the second page ;-)

[Joss]

No offence intended, it's just funny how this thread evolved.

I'm still thinking that it might make sense to start a new thread if some people want to put some shared effort in producing nice tutorials - still don't know where to open it though.

If in doubt, go down the pub - worked for me for years till my liver pointed out a few rather obvious problems with the theory.

[Soma]

There already is this place called wiki.processwire.com.