Problem when extending process modules

[apeisa]

I am gonna build simple module that will add role filters and maybe a user search to help manage hundreds and more users through PW-admin. My first idea was to extend current ProcessUser module to create a new process, but stumbled on the very first step. This is my module (or part of it, but that is the part that is causing problems):

<?php
class ProcessUserExtended extends ProcessUser {

static public function getModuleInfo() {
return array(
'title' => __('Users extended', __FILE__), // getModuleInfo title
'version' => 100,
'summary' => __('Extended view for user management', __FILE__), // getModuleInfo summary
'permanent' => false,
'permission' => 'user-admin',
);
}

public function ___execute() {
$out = '';
foreach(wire('roles') as $role) {
$out .= $role->name . " ";
}
return $out . $this->renderList();
}
}

And running it gives me this error:

Method Pages::getTemplate does not exist or is not callable in this context

I have other options also (like hooking), but I would like to understand why this happens?

[nik]

Looks like ProcessPageType derived modules are a bit special. In ProcessPageType::init() $this->pages is initialized to whatever is found from the fuel with the page name. Page name being 'users' or 'roles' or 'permissions' works nicely as those keys exist in the fuel. There is a fallback to plain Pages object on the next line, but that works only so far, as you've noted. ProcessPageType::renderList() doesn't check if $this->pages is of type PagesType as is done in init(), but just tries to call getTemplate (which is defined in PagesType class). And as plain Pages object isn't of PagesType, this fails.

But even though I found what happens, I'm not sure why is it so. Ryan may be the only one to say whether it's something to be fixed in ProcessPageType::renderList() for instance or is this just The Wrong Way To Go in the first place. I'd say there's just a little fix needed in the beginning of ProcessPageType::renderList() but it could be something else as well.

If you want to take this road before someone's able to give you more definitive answers, you can proceed by renaming your page to 'users' (obviously not under access then, but setup for example) - that'll do the trick. And I mean *name*, title doesn't matter.

[Pete]

Just a quick note to say that whilst I have little idea about the technicalities of the difficulties you're having, I'm following this topics closely as I was seriously considering using PW for an intranet and the type of functionality you're talking about Antti would remove one large obstacle from my way

[apeisa]

Thanks Nik! I do understand it now. I am happy how it turned out (I thought that my humble understanding of OO-programming was all wrong...).

Actually how I was thinking of building this in first place would be that installing the module would change the process on current /users/ page, so it would actually work very nicely. I think why it is that way is to scope the pages to just the relevant ones - but it actually might be a good idea to be less strict with that.

Pete: I am soon gonna import 40 000+ users into processwire, so some improvements are definitely coming to that area

[Pete]

40,000+? Wow, and I was just thinking of using it with 50

[apeisa]

Pete: Well, it doesn't work that well after 100 user, so improvements are definitely required with tens of thousands users.

[apeisa]

Now that I got first obstacle tackled with Nik's help, I hit another. It seems that renderList() function isn't hookable and also it doesn't allow any modifications to it's selector (https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPageType/ProcessPageType.module#L100). Would it be a bad idea to take that selector part to it's own hookable method, so I wouldn't need to duplicate the whole renderList() method?

[ryan]

I'm happy to make any changes/improvements that you need to this module. As you can see, this module was designed for a narrower context without too many features, but now is a good time to broaden it, and I think it'll adapt easily. For starters, why don't we move renderList() to be renderList($selector) and the "limit=25, status<statusMax" can be moved to executeList, like this:

public function ___executeList() {
 return $this->renderList("limit=25, status<" . Page::statusMax); 
}

That way you can just override executeList. Does this solve what you need for that?

Also, I've run out of time today so didn't have a chance to take a closer look at the other issue you mentioned, but if you can let me know of any specific changes I can make the same ones here.

[apeisa]

I'm happy to make any changes/improvements that you need to this module. As you can see, this module was designed for a narrower context without too many features, but now is a good time to broaden it, and I think it'll adapt easily. For starters, why don't we move renderList() to be renderList($selector) and the "limit=25, status<statusMax" can be moved to executeList, like this:

public function ___executeList() {
return $this->renderList("limit=25, status<" . Page::statusMax);
}

That way you can just override executeList. Does this solve what you need for that?

Also, I've run out of time today so didn't have a chance to take a closer look at the other issue you mentioned, but if you can let me know of any specific changes I can make the same ones here.

Oh yes, that would be a perfect solution! I make that change already on my code, so I can keep the ball rolling.

[ryan]

Oh yes, that would be a perfect solution! I make that change already on my code, so I can keep the ball rolling.

This is updated in the dev branch now too.