ProcessPageList: number of children does not account for listable

[Toutouwai]

Short description of the issue

In ProcessPageList the number of children under each parent page is indicated by a number next to the page title. However, this number does not take account of the $page->listable boolean which determines which child pages will in fact be listed under that parent.

So for example, the core Page::listable method says that a page is not listable if it isn't editable by the current user and the page is unpublished:
https://github.com/processwire/processwire/blob/c01289edb7ad650bb635e412b490e8db8fe91989/wire/modules/PagePermissions.module#L626

But because this isn't taken into account by ProcessPageList the wrong number of children can be indicated, which is confusing for the user.

Superuser:

Non-superuser:

Interestingly it is not just the two unpublished pages that result in the incorrect child count, meaning the 404 page, Admin page or Trash page must also be incorrectly included in the child count of Home, so that count will be wrong for non-superusers even on a brand new PW installation with the Blank profile.

This issue also creates a problem for anyone hooking Page::listable to set a custom listable value, which is something I do regularly. I previously raised this as part of a feature request, but now I see that an issue occurs even without custom listable values I'd consider this a bug.

Setup/Environment

• ProcessWire version: 3.0.108

[netcarver]

@Toutouwai Hi Robin. I can verify that this is reproducible in an older install as well (3.0.68)

[ryancramerdesign]

The numbers are determined before the pages are loaded via database count() calls, and are the closest it can get without actually loading all the pages and checking them individually. ProcessWire can support pretty much an infinite amount of children on any given page, and it's not practical for it to call a listable() hook on all children of a page. For non-superuser with unpublished pages, they have to examined individually before it would be known if the user has edit permission to them (and thus would be able to see them in a list). On the front-end, it's a non-issue since unpublished pages never appear in lists. The numbers indicate the the highest possible that could be listable in order to ensure that the item is at least openable.

[Toutouwai]

ProcessWire can support pretty much an infinite amount of children on any given page, and it's not practical for it to call a listable() hook on all children of a page.

Understood.

ProcessPageList gets the children number to show in the list / flyout menu in two places, here and here. Would you consider separating those into a hookable method for situations where people really want to correct the children number for the currently logged in user? Because depending on the condition that is preventing certain children from being listable it could be possible to write that as a $pages->count() query that wouldn't be much less efficient than the numChildren() method that is being used.

[netcarver]

@ryancramerdesign Just bumping this for your consideration of Robin's request. If this is still a "won't fix", should it be closed?

[reminders]

@netcarver set a reminder for Mar 2nd 2019

[ryancramerdesign]

@Toutouwai @netcarver

I've added a method here that you can hook to modify the children count in PageList.

$wire->addHookAfter('ProcessPageListRender::getNumChildren', function($event) {
  $page = $event->arguments(0);
  $selector = $event->arguments(1);
  $event->return = $page->numChildren($selector); // your implementation here
 }); 

[Toutouwai]

Much appreciated, thanks Ryan.