Error: This page may not be placed in the trash

[rastographics]

I'm trying to delete a page from the API in a front-end template and processwire refuses. 

I've never had this happen before. I can delete the pages fine from the backend. 

Here is my very simple code:

if($input->post->delete == 'delete'){
    $registration = $page->parent->url;
    bd($page->status(),"Check page status"); //This equals 1
    $page->trash();
    $session->redirect($registration);
}

This error comes up:

A search on the forum turns up only one other topic in which the user discovered they had a typo that was causing the issue. I also looked at page status and template options mentioned in that post, but they do not appear to be the problem.

Beating my head against this one for a couple days...any ideas?

[rastographics]

UPDATE: I noticed I can trash these pages through the api as long as do it from other pages. In other words, it is impossible to trash the current page.

I found this github issue where someone pointed out that the behavior changed in this commit to not allow current page to be deleted. This only happens on PW installs that happened after a hard-coded date, so maybe why not many people run into this? I didn't see behavior (current page cannot be deleted) documented in the $pages or $page api.

In the code of the commit, there are clear error messages returned.

Here is the message for trying to delete the current page:

"it is the current page being viewed, try \$pages->trash() instead";

But that message does not show in my case. 

Also, I'm not trying to DELETE the page, but TRASH it. I tried using $pages->trash($page) instead of $page->trash() but still I get the same error.

This seems like it should be a common behavior...have a Trash button on the edit page for some resource, that posts back to the page and the page is trashed, then redirecting to a different page.

The Admin dashboard operates this way to trash pages. What am I missing?

[BitPoet]

Just now, rastographics said:

What am I missing?

I'd say, not much, just that the the "current" page in the dashboard is the page "/processwire/page/edit", not the page actually being edited, that's why trashing in the backend works.

Your analysis is otherwise spot on, I was about to write the same. I'd suggest to raise another, more specific, issue on github. I don't see any reason not to trash the current page if the very next step is a redirect.

[szabesz]

1 hour ago, BitPoet said:

I don't see any reason not to trash the current page if the very next step is a redirect.

I also wanted to do this and was surprised that this is not possible so I had to code around this.

[szabesz]

1 hour ago, BitPoet said:

I'd suggest to raise another, more specific, issue on github.

Also, anyone in need for a fix for this, please give a thumbs-up at the GitHub issue so that Ryan can see how "popular" (or rather: unpopular) this issue is. 

[rastographics]

I made a new issue that is more specific. The issue is not limited to superuser. It is more specific in that the trashable() method is calling deleteable() which checks if page is the current page.

https://github.com/processwire/processwire-issues/issues/1693

I think that trashable() should not be checking if page is the current page.

[bernhard]

While I don't see any problems in making it work as you expect here is a quick and easy workaround:

$wire->page = $pages->get(1);
$page->trash();
$session->redirect(...);

 

[rastographics]

4 hours ago, bernhard said:

While I don't see any problems in making it work as you expect here is a quick and easy workaround:

$wire->page = $pages->get(1);
$page->trash();
$session->redirect(...);

 

Unfortunately I just tried that code and it does not work. Because trash() checks isDeletable() which checks if the page to delete is the current page, this code does not get around that situation.

It will only work on processwire installations that were installed before the hardcoded date in 2019 when the core was changed.