alt. pageclass not honored by pagestype classes

[LostKobrakai]

When extending the User class with an custom one $users is stil loading pages as User objects.

[LostKobrakai]

This can be circumvented by using $users->setPageClass($templates->get("user")->pageClass); in site/ready.php. But it still works only for an single class, but not for multiple ones, if alternative user templates are used.

[LostKobrakai]

Ok found one issue with that. It's not going to work for the current user obj wire('user') out of the box:

$users->setPageClass($templates->get("user")->pageClass);
$uid = $user->id;
$pages->uncache($user);
wire('user', $users->get($uid));

[ryancramerdesign]

Since User objects are managed by a PagesType class, and a PagesType class is designed just for an object of a specific class, that's what specifies the object type (rather than the template). So it's not currently designed for using different types of objects for something like User. Though it's likely possible and I can look into it further. Have you considered extending the User object with hooks instead?

[LostKobrakai]

I have, but it has ended in unmaintainable bulks of hooking functions
and I'm also using static functions. I'm now leaving pw's classes
untouched and just use own classes, where additional domain logic is stored.

Since User objects are managed by a PagesType class, and a PagesType
class is designed just for an object of a specific class, that's what
specifies the object type (rather than the template). So it's not
currently designed for using different types of objects for something
like User. Though it's likely possible and I can look into it further.
Have you considered extending the User object with hooks instead?

—
Reply to this email directly or view it on GitHub
#1412 (comment).

[LostKobrakai]

I can certainly see you point with the PagesType class managing (currently) only a single type of page, but when using an alternative user template one might also want to use an alternative class for it (can prevent a damn lot of switch/ifelse statements). Additionally $users is a deep part of the processwire api, so I wouldn't want (and maybe even couldn't) add my own custom implementation.

[ghost]

Do you know of any downsides when overwriting getPageClass in the Users template to return an empty string? This results in PagesLoader autodetecting the page class:

...
'pageClass' => '',  // blank = auto detect
...

[LostKobrakai]

Depends on how you mean to overwrite that part.

[ghost]

I added

    public function getPageClass() {
        return '';
    }

to the Users class to overwrite the following from PagesType

    public function getPageClass() {
        if($this->pageClass) return $this->pageClass;
        if($this->template && $this->template->pageClass) return $this->template->pageClass;
        return 'Page';
    }

[LostKobrakai]

Changing core classes directly is considered bad practice, because it'll break with the next update you're doing. Rather use the code I posted above and just set the pageClass to an empty string.

[ghost]

Yes, that's right. But would adding this to the core break anything? Because if not, I'd like to create a pull request...

[LostKobrakai]

You certainly could, but Ryan does not use pull-requests, therefore it'll probably have as much effect as giving this issue some attention. He already stated above that it was not intended to work that way initially.

Also even if it wouldn't break anything, as long as there are only 2 people voting for a change (which you can do on your own) it's hardly a important topic.

[valieand]

Can not find where to vote for a change, but I'm +1.