Trouble finding, updating unpublished pages

[evanmcd]

Hi,

I've been working on this for a bit, and am stuck. Hoping one of the fine minds here can help out

I want to use the API to find a page that may be published or not, then update it or create it as needed. The first issue is finding a page whose status might be either published or not.

I've tried:

$my_page = $pages->get("name=".$_POST['email'].", status=published|unpublished");

and

$my_page = wire("pages")->get("name=".$_POST['email'].", status=unpublished|published");

Both of which seem to find only published pages.

The second issue is that if I find and try to update an unpublished page (by just using status=unpublished) I get an error when I save() the page, saying that one of my fields (an Image field) doesn't exist (even though I know it does exist).

Does anyone have any idea what might be going on?

Thanks.

[Soma]

I'm not getting what exactly you want to archive with published or not. Every page ist published or not. There isn't more. Are you trying to check if it exists or not?

Edit: ah there's no "published" I think, only "unpublished" so try "status!=unpublished, status=unpublished"

[evanmcd]

Am I wrong in my assumption that the API excludes unpublished pages by default? Maybe there's some other reason why get call wasn't finding my unpublished page, if that's the case.

[apeisa]

Unpublished are excluded by default. Just add "include=all" to have hidden and unpublished to show up also.

http://processwire.com/api/cheatsheet/ (advanced mode).

EDIT: remember though that selectors doesn't check access after that. Even the pages where user doesn't have view access are included.

[Soma]

apeisa is right, I just checked my dashboard module. i'm getting old

as for acces, isn't the "check_access=1" what you mean, to only include accessable pages?

[apeisa]

Yes, that is default. But include all is kind of opposite and I don't know which one is stronger...

[evanmcd]

OK, thanks guys. So this is what ended up working for me. The other issue (field doesn't exist) seemed to have to do with the fact that I had another page, using a different template that had the same name. Adding the template filter fixes that.

$my_page = $pages->get("template=template-photo, name=".$_POST['email'].", include=all");

Thanks!

[ryan]

Evan, make sure you sanitize $_POST['email'] before putting it into the selector. Since you are dealing with a page name, I recommend this:

$name = $sanitizer->pageName($input->post->email); 
$my_page = $pages->get("template=template-photo, name=$name, include=all"); 

Yes, that is default. But include all is kind of opposite and I don't know which one is stronger...

"check_access=0" will cause it to include pages that the user doesn't have permission to view as a result of access control. It's what you'd want to use if you wanted to (for example) generate public listings for pages, but only full members could view the whole page. In that fashion, you could have the page appear in lists to everyone, even if only the members could view it. The non-members could get a login page when they click on it.

"check_access=0" won't cause unpublished or hidden pages to be included.

Whereas "include=all" will include everything regardless of access, publish or hidden state.

Any function that returns a PageArray (like $pages->find or $page->children) will have this access checking enabled by default, unless you turn it off with include=all.

But functions that return a single page (like $pages->get) don't check for access/status since they are returning a pre-determined (by you) item and quantity, and aren't likely to be used for making navigation.

[apeisa]

Thanks Ryan. What I was wondering was if you have both: "include=all, check_access=1" - it will include hidden and unpublished pages but would it still check access?

[ryan]

What I was wondering was if you have both: "include=all, check_access=1" - it will include hidden and unpublished pages but would it still check access?

I don't think it will. Once that "include=all" appears in there, that pretty much overrides anything else you might set in there.

I think it would probably be unusual to ask PW to check access and include unpublished pages, but a potential need might involve including 'hidden' (but not unpublished) pages and disabling access checks. So in that case, you'd do: include=hidden, check_access=0

[Soma]

I think it would probably be unusual to ask PW to check access and include unpublished pages, but a potential need might involve including 'hidden' (but not unpublished) pages and disabling access checks. So in that case, you'd do: include=hidden, check_access=0

What if I have a dashboard I want to list pages the user has access and are unpublished?

Edit: Ah, is check_access checking only for if a page is "viewable" or not by the current user? So it doesn't check if a page is editable?

I got it working in my dashboard "unpublished pages" widget to list all pages and I'm additionally checking in the foreach loop if the page is editable and output it with a link or not. But drawback is that I can't use pagination or limit=10 with this technique when I don't output the not editable pages in the loop. Is there any solution to this problem?

[ryan]

What if I have a dashboard I want to list pages the user has access and are unpublished?

check_access just refers to view access, and this is assumed if you omit check_access. So the only reason to ever use check_access is if you want to include pages the user doesn't have access to view, due to access control settings. To list the pages you mentioned, you'd just use "status=unpublished".

But drawback is that I can't use pagination or limit=10 with this technique when I don't output the not editable pages in the loop. Is there any solution to this problem?

If $user->isSuperuser() then don't bother performing any checks, because they will have access.

You could cycle through the templates, see which ones are defining access, and of those, which ones have editRoles that are consistent with the users roles. Then include those templates in your $pages->find() selector. But this leaves out those pages that inherit their access. That's because that access is inherited through the hierarchy at runtime, so not possible to determine without actually loading the page and following it's inheritance path. As a result, this is a complex question to which there isn't a simple answer... at least not one I can think of yet.

[ceberlin]

check_access, include ...shouldn't they go into the offiicial documentation? - I think they are pretty important!