Field set to unique in table

[kongondo]

@Peter,

Isn't that what selectors are about? Including and excluding things? If I am getting results that include things I don't want, I have various options to exclude them. PW provides various means to exclude them by very finely tuned selectors - name, parent, child, etc...I would add the trash check; it's simple and effective and will give me the peace of mind that trashed pages will not be returned ...then again, this is just my 2 cts.

[Peter Falkenberg Brown]

Dear Kongondo,

I'm fine with including a trash check. This thread has simply been a process (no pun intended) of clarifying the usage and documentation on the behavior of get().

I think the documentation (even on the wonderful cheatsheet) should state something like:

* get() never looks in the trash unless:

a) you use include=all, or

b) your only selector is looking for a page id

Then we won't get tripped up by assuming otherwise.

But now I'm wondering if a find(id=$id) will also look in the trash.

I'm *loving* ProcessWire: don't get me wrong. It's a joy to use.
 

Thanks to all...

Peter

[kongondo]

Yeah, maybe as a footnote I suppose? 

I was never in doubt about your love for ProcessWire  

[Soma]

You make it complicated where it isn't. I agree it can be confusing if you're not experienced working with PW, but it's as Ryan said we hardly ever need to think about it.

But I have to agree with Peter that Ryan mentioned something above which add to the confusion of the confusion even more in that it isn't exactly true or not including all infos (which seems natural to him or us)

$pages->get() or $pages->find() are not going to include pages in the trash unless you specify an "include=all" or one of the high status levels. $pages->get() is different from $pages->find() in these respects: $pages->get() only ever returns 1 page. $pages->get() bypasses access control and will include hidden pages. You don't need to specify "include=all" to $pages->get(); unless you want to retrieve an unpublished page or a page from the trash. If there are times when you want a $pages->get() that performs exactly like $pages->find(), except only returning one page, you can do this:

This is not really the case:

echo $pages->get(1733) . "<br>";
echo $pages->find("id=1733")->first(). "<br>";

Will both return pages from the trash! Event the find. No include=all needed.

 

BUT, what what Ryan maybe wanted to say there is that when using get or find with a selector like a usual:

$page->get("template=basic-page, isactive=1");

or a

$pages->find("template=basic-page, selected_page=1002") 

... will never return a page from the trash, unless you add a "include=all"! 

 

A $pages->get(1733) is much like saying "SELECT * from pages where pages_id = 1733", will return the page no matter what. So is a find("id=1733")->first();

 

It feels kinda natural and after using PW API for some time you'll never ask again. But have to agree it can be confusing for people... wait till you start coding modules where there's also no outputformatting and not access aware!

 

If you have some case where you really want to make sure you don't want a page from the trash, just add a check like ryan showed above, or add a status selector.

[Peter Falkenberg Brown]

Dear Soma,

I appreciate your input; thanks.

To summarize then, I believe that you're stating that both get() and find() return items from the trash when the only selector is the page id?

Is it thus correct that with all other types of queries, those functions do not access the trash unless include=all is specified?

I think that the real issue here is that the trash is seen by many (or maybe just me?) as a walled-off area of "deleted" records that will never be accessed by regular code statements. In my opinion it makes programming much easier to think that the trashed items are in a protected silo that you have to make special effort to access.

Based on that concept, one can program away, confident that no matter what one's syntax, the trash will not be accessed, unless specifically requested.

I think that's *much* cleaner, in terms of design and real-world usage.

Ryan, what do you think?

Yours,

Peter

[Soma]

Maybe you want to inform the user that the page actually has been deleted and you would anyway use:

$p = $pages->get(1001);
if($p->isTrash()) {
    $wire->error("This page has been deleted by " . $users->get($p->modified_users_id));
} else {
     ...
}

YOu don't have to check the if the user is in the trash because users can't be trashed, but maybe he also got deleted...

Building a webapp as it sounds you're doing there's actually quite a lot of scenarios you got to cover. THe issue is kinda made by you but I get what you're saying and it's a valid consideration. WIth the possibility that Ryan says different and think it's a good idea... I think I'm not sure if changing it will break backward compatibility, even maybe rare. But I think it really doesn't matter that much and don't see how it would change much. I think you're the first even questioning this (not that it says something bad about it)

edit: damn wrong button, had to finish the post first sorry

Another example maybe more real world

$p = $pages->get(1001);
if(!$p->id) {
    $wire->error("Sorry, this page has been deleted already!");
    return false;
} else if($p->isTrash()) {
    $wire->error("This page has been trashed by " . $users->get($p->modified_users_id));
    return false;
} else {
     ...
}

[Soma]

Sorry had to finish my post first... so that's why I'm posting this so you see it.

[Peter Falkenberg Brown]

Dear Soma,

Thanks for those examples. They're certainly options, to tell the user that a page is in the trash.

> I think you're the first even questioning this (not that it says something bad about it)

I've heard that before, more than once.

If Ryan is open to modifying the behavior of get() and find() when id params are used, and if it doesn't

break backward compatibility, I'd vote for that.

The only backward compatibility thing that I could think of would be if someone had coded something

like "get($id)" and *wanted* to find items in the trash.

Having get() and find() skip the trash unless specified would indeed break the code in the above scenario.

But how many coders actually *code* an app to look in the trash? It's the kind of thing that might be done

by hand, via the admin interface.

When it comes right down to it, with a web app like mine, I'll be running a script every night

(probably) that deletes the trash anyway.

Yours,

Peter

[SiNNuT]

Peter,

There's certainly nothing wrong with it but why do you use this form for internet forum postings? Seems a bit redundant and overly polite to be honest.

Dear Soma,

- snip -

Yours,

Peter

[Soma]

Then why have a trash at all? You might swell just delete pages and not trash them in the first place. I'd vote for no because I want to get the page when using get(id). It's not searching.

[Peter Falkenberg Brown]

Dear SiNNut,

> There's certainly nothing wrong with it but why do you use this form for internet forum postings? Seems a bit redundant and overly polite to be honest.

That's a question I've never been asked!

(Of course, I'm well aware that my method of salutation is now "old-fashioned.")

So, let's see. I'll be 59 in two weeks, and have been a writer for a long, long time.

I still remember when people wrote letters on *gasp* -- *paper*...

Pop Quiz: what is "whiteout"?

From "Dear Sir", "Dear Friend" and "Dear Billy Bob", to "Hi", and then not even "Hi",

there has been a rapid Net-driven descent into what I feel is a far more impersonal method

of communication.

I don't want to become an anachronism in the Internet age, but I feel that with

the massive change in communication that has even reached the point of using shorthand

for words, such as 'u' for 'you', the beauty of language and the importance of courtesy

are in danger of being discarded.

You see it on TV all the time. Someone will be talking on the phone and then hang up without

saying, "Bye." I always think, "Those lazy script writers are destroying etiquette."

Digging deeper, it's not just courtesy and etiquette that are important, but the underlying qualities

of personal care, respect, kindness and compassion that are communicated between people.

Thus, I'm holding out as long as I can, treating email and forum posts the way I would a letter,

working hard to put my finger in a dike that will probably give way anyway.

I do agree that one liners might not need the whole "Dear" and "Yours" thing, but for notes of

any length, I still like them.

I hope being overly polite is not rude.

Yours,

Peter

[Peter Falkenberg Brown]

Dear Soma,

> Then why have a trash at all? You might swell just delete pages and not trash them in the first place. I'd vote for no because I want to get the page when using get(id).

> It's not searching.

I think the trash is very important. I'm just suggesting that it should exist in a programmatic silo.

But... I'm the new guy, so I respectfully rest my case.

I'm glad that the details could be clarified, and will now simply add a param to not look in the trash.

Yours,

Peter

[apeisa]

The only backward compatibility thing that I could think of would be if someone had coded something

like "get($id)" and *wanted* to find items in the trash.

That is exactly the thing I am doing with Trashman: https://github.com/apeisa/Trashman/blob/master/ProcessTrashman.module#L124

I understand both "sides" of the discussion - both opinions are valid so it is matter of having one way and stick with it

[Peter Falkenberg Brown]

Dear Antti,

I understand. Sounds like there's too much potential to disturb legacy code.

I think I may create a var that contains a query to skip the trash, e.g.

$skip_trash       = "parent!=$config->trashPageID";
 

and then add $skip_trash to many, or all, of my gets and finds, just for peace of mind.

In terms of the above query, since the trash can contain subsections, and thus 'trash'

is not the parent of every page in the trash, do you think the query should be:

$skip_trash       = "rootParent!=/trash/"

in order to make sure that all trash pages are correctly identified?

Peter

[Peter Falkenberg Brown]

Dear Antti and Soma and All,

I created a variable:

$skiptrash           = "has_parent!=$config->trashPageID";
 

Then, in my query, I use:

$check_page    = $pages->get("id=$some_page_id, $skiptrash");
 

It seems to work, and I'm under the impression that one can use

has_parent != ID

to say that the page does not have the trash id anywhere in the trash tree.

Thus, it's explicitly stating not to check in the trash.

Is there a better way to put this into a query, or will this do the trick?

I understand Soma's recommendation to check the status of the found page after the query,

but I'd like to skip the trash in the query itself.

Yours,

Peter

[diogo]

I'm not sure if it's more efficient, but your variable could be also:

$skiptrash = "parent!=7";

[Soma]

Any selector added to the id=id will work except include=all. It doesn't really matter what as it will ignore anything in trash anyway.

(1001 is in trash)

"id=1001" // will return the page if exists, bypassing a find "search"

"id=1001,status=" // will search and return the page if exists, except if in trash

"id=1001,status>".Page::statusTrash // ditto, even though the status says only pages in trash

"id=1001,parent=" // ditto

"id=1001,template=" // ditto

"id=1001,parent=7" // ditto

"id=1001,has_parent!=7" // ditto

As Ryan stated get and find searches will never return pages from the trash. 

As soon as there's another selector found, it will do a pagefinder search and exclude trash and others that are not accessible by the user.

So apart from it doesn't matter you could add a:

",status<" . Page::statusTrash

Instead of the variable to add to all those get(id), you could create a function to search for a id exluding trash.

// at the beginning of you template output, or something like _init.php
$pages->addHook("getPage", null, "getPageNotTrash");

function getPageNotTrash($event){
  $id = (int) $event->arguments(0);
  $event->return = wire("pages")->get("id=$id,status<" . Page::statusTrash);
}

// in your templates use
echo $pages->getPage(1733)->title . "<br>";

But I'm still with my code previous, to check for if the page is in trash and trow an error.

[Soma]

Thinking about that you seem to have your app mainly working under "/members/". Why not just add that?

$pages->get("/members/")->get("id=1733");

$members = $pages->get("/members/");
$members->get("id=1322");

And you don't have to care about trash.

[Peter Falkenberg Brown]

Dear Diogo and Soma,

Diogo, this line:

$skiptrash = "parent!=7";

doesn't take into account that in the trash, you can have grandchildren records, so the parent

might not be /trash/, which is why I used has_parent!=.

Although the syntax of has_parent!= seems confusing to me, since has_parent= looks for a

specific page in the ancestral tree, whereas != could mean that it has any non-trash parent,

rather than the fact that the trash page does not exist. The boolean logic with the wording of

'has_parent!=' is muddy, to me.

Soma, your comments above are very helpful, and those are some great ideas.

Kind of like Perl: "there's more than one way to do it."

At least to me, this discussion has been very helpful because it exactly clarifies

the behavior of get() and find() in a way that was not clear to me before.

Perhaps a brief note about the behavioral change of get() and find(), when only

an id query is passed, could be added to your wonderful Cheat Sheet.

Thanks once again!

Peter

[kongondo]

Peter,

I think what Diogo meant to say is that this:

$skip_trash = "has_parent!=$config->trashPageID";

could probably be (more efficiently?) replaced by this:

$skip_trash = "has_parent!=7";

Unless Ryan has one crazy morning, the ID of trash will always be 7

<aside>Peter, any reason why you don't take advantage of the forum's inbuilt code highlighter? </aside>

[apeisa]

Kongondo, I don't think that is wise optimization to make. Although trash page id is not likely to change (at least on site on production, but might be different between site profiles etc), there is no real speed gains and doing that way you should at least comment what id=7 is.

[Peter Falkenberg Brown]

Dear Kongondo,
 
I agree with Antti, that codewise, it's safer to not assume that the ID of the trash will always be 7.
 
And... you asked,
 

Peter, any reason why you don't take advantage of the forum's inbuilt code highlighter?

 
Because:

$ignorance != $bliss;

I just didn't even notice that there little icon. Zowie.

I thought that icon meant, "go into HTML mode".

One learns something every day, and thus draws closer to coding bliss.

Peter

[kongondo]

You learn something new everyday...thanks Antti and Peter

[Missariella]

*Kick*

 

Is this module valid for the latest version of processwire (3.0.96)

If not are there known alternatives?

 

Thank you

 

[pwfans]

On 4/3/2018 at 11:41 PM, Missariella said:

*Kick*

 

Is this module valid for the latest version of processwire (3.0.96)

If not are there known alternatives?

 

Thank you

 

Just install it on 3.0.98, so far didn't found any problem .. yet.