Get previous parent for trashed page

[LostKobrakai]

I know that trashed pages keep the prev. parent in their name, so it can be restored later, but is there a api way to get that value without restoring the page? E.g. still getting the (parent) event a reservation was part of, even if the reservation time elapsed.

[Mike Rockett]

I'm actually after something ever so slightly similar: need to check if a Page was trashed based on the request URI as part of the 404 monitor I'm building. I understand kixe had a problem with this - code is still commented out.

It appears to be quite a mission, the way I see it, and so I wonder if there would be a possibility for Ryan to include the original path for each trashed Page. Or is there a simple method I can use that I'm just not seeing?

[LostKobrakai]

All the information is included in the trashed page's name. Otherwise there wouldn't be the option to restore trashed pages with the click of a button. It's just, that there's not a nice api present around that.

[Mike Rockett]

All the information is included in the trashed page's name. Otherwise there wouldn't be the option to restore trashed pages with the click of a button. It's just, that there's not a nice api present around that.

Yeah, that's the issue I'm facing. Guess I'll just have to work with that for now. In fact, I completely understand now why it's done this way. If I trash a page a page, then trash its parent, and then restore the first page, it keeps it in the trash, only underneath its parent. So will dig into the code to see exactly how to extract the information needed.

[Mike Rockett]

Magical. $pages->restore($page, false) does the trick. Needs PW 2.6.5, but I don't think that's a problem at all.

Edit: Although, this seems to save the restored status, but leaves it in the trash...

[LostKobrakai]

I'm not sure if it's meant to be used like that. But you can certainly strip out the data parsing to get the data you need.

[Mike Rockett]

I was using a recursive loop and then started trashing without saving before recursing, which gave me unexpected results. So now, its restore without saving, recurse, trash without saving. Haven't tested it on bigger nests in the trash - will do that now.

Preferably, I'd like to rely on the method being used in the core. If it were to change, I don't want the module to break. Seemingly, this works at the moment.

For reference, I'm doing this right now:

// Let's see if the page was trashed
if ($trash = $this->pages->get($this->config->trashPageID)) {
    $trashed = [];
    $listChildren = function ($page) use (&$trashed, &$listChildren) {
        // If not the trash page itself, restore the page without saving it
        // so we can get its actual path.
        // Then add its path and ID to the trashed pages array.
        if ($page->id !== $this->config->trashPageID) {
            $this->pages->restore($page, false);
            $trashed[] = [trim($page->path, '/'), $page->id];
        }
        // Do the same for all its children
        if ($page->numChildren) {
            foreach ($page->children('include=all') as $child) {
                $listChildren($child);
            }
        }
        // Again, if not the trash page itself, then trash it without saving
        // to restore its original trashed state.
        if ($page->id !== $this->config->trashPageID) {
            $this->pages->trash($page, false);
        }
    }; $listChildren($trash);

    // Check to see if what we're requesting is actually in the trash.
    // if so, set the reason and break out.
    foreach ($trashed as $page) {
        if ($page[0] === $request->request) {
            $reason = self::ReasonPageTrashed;
            break;
        }
    }
}

Look okay?

Edited January 7, 2016 by Mike Rockett

[LostKobrakai]

If it's working it's ok. If you want to rely on core functionality I'd rather ask Ryan to extract the regex parsing to a separate function so it's useable by us as well. 

[Mike Rockett]

If it's working it's ok. If you want to rely on core functionality I'd rather ask Ryan to extract the regex parsing to a separate function so it's useable by us as well. 

Have run a slightly larger test, and it seems to be okay - the methods appear to do the exact opposite thing, so it balances out.

Thing is, it isn't done only via regex - by actually re-assigning trashed pages to their original parents, I'm able to get their full paths. So only working with the regex side of things won't actually get me anywhere... Unless I'm missing a good way to do that.

[LostKobrakai]

Yeah, for nested pages in the trash this might be easier, but you could always construct the path manually as well. I'm just not so keen on actually changing anything of the trashed status without actually needing to change it. 

[Mike Rockett]

Perhaps I chose this route as constructing anything manually got my brain in a twist. Sticking with this for now, but will attempt a reconstruction a little down the line. I do agree that it is the better way to go.