Custom PHP code selector

[blynx]

Hej,

i am trying to build a custom PHP code selector to get all pages using a user template for a site using multiple templates for users.

Here are my two non-working approaches:

/**
 * A
 */
return function() {
$template_ids = implode("|", $config->userTemplateIDs);
return $pages->find("template=$template_ids, include=all");
};


/**
 * B
 */
return $pages->find("template=".implode("|", $config->userTemplateIDs).", include=all");

Maybe I am thinking too complicated and I miss something here - basically I need a Page Field which can select from all users with all the different user templates ...
uhm - has anyone an idea how this might work?

Also in general - has anyone an idea what is actually possible with this custom php code selector? I guess it is somewhat restrained?

Thanks!
Steffen

EDIT:

I guess that I can't access $config?

[Martijn Geerts]

I think that context can't access the $config variable. You could try wire('config')...

What else: I'm not fully 100% sure that "template="..." would work you could also try "template.id="...".

[LostKobrakai]

The custom php code is executes as part of InputfieldPage and therefore all api variables are accessable as $this->… . Only $pages as $page are available as local variables.

[blynx]

Yes!

Thanks @LostKobrakai, thats it - should've tried that one too ...
@Martijn Geerts, yep - I also tried wire('config') but that didn't work either – and I was not sure about `template=` vs. `template.id=`, too ... both work though

PS:

Is there actually some kind of summarized documentation of where which variables are scoped and why? Like to get to know some underlying concepts of processwire? Or a forums thread where things like that are explained more thoroughly?

[LostKobrakai]

There are basically four different environments to talk about.

1. TemplateFile
   TemplateFile is core class, which does include your template files, but does also power things like $page->render(), wireRenderFile(), wireIncludeFile() and others. This class will automatically make all API Variables available as local variables. Meaning all those included files can directly use $pages, $page, … . It won't work inside any functions defined in those files, because of the way PHP does scope variables.
2. Classes extending Wire
   Every class, which is extending the Wire class will have access to API variables via $this->pages, $this->page, if the properties or __get() are not overwritten. Also there's $this->wire('pages'), which is less likely to be overwritten (even some core classes need to use $this->wire()).
3. Anonymous functions
   There are some methods in the processwire code, which accept anonymous functions as parameters (e.g. WireCache). Those anonymous functions can retrieve api variables as parameters, even though I'm not sure how exactly this is working or if that's often used.
4. Everywhere else
   Outside of wire classes, template files and special anonymous functions there's the wire() function, which is basically the same as $this->wire() in wire classes, but as a global function, which is accessable anywhere after pw is started.
   With PW 3.0 and multi-instance this is the option to avoid.

Places, which technically are number 2, but it may not be apparent to everybody:

Custom PHP code for fields like FieldtypePage or FieldtypeMarkup:
As those PHP code is evaluated/run inside those (input)field classes there's (besides manually available local api variables) always the option to use $this->pages or $this->wire('pages').

All those template files included by the TemplateFile class:
For the same reason as above there's not only $pages available in those template files, but also $this->pages, $this->wire('pages').

[Yannick Albert]

On 11. August 2016 at 8:47 PM, LostKobrakai said:

Everywhere else
[...]

With PW 3.0 and multi-instance this is the option to avoid.

Great overview, Benjamin!

Have you any reference on this or could you explain why we should avoid wire(). What's the best way to go, using $this?

[LostKobrakai]

It's because all other options are aware of their instance (e.g. a page of instance1 will get the configs of instance1), whereas the global wire function does not have state and therefore does only ever return the "primary" instance, which is simply the first one ever instantiated.

Edit: Maybe 'avoid' it to hard, but one needs to be aware that the function is not aware of additional instances. Especially in hooks or alike, where people are currently often using wire() one should rather use $event->wire() so the hook is not prone to using a different instance than intended.

[Robin S]

29 minutes ago, LostKobrakai said:

It's because all other options are aware of their instance (e.g. a page of instance1 will get the configs of instance1), whereas the global wire function does not have state and therefore does only ever return the "primary" instance, which is simply the first one ever instantiated.

Thanks for the explanations. Is there an instance-aware way to get API variables in function scope?

[LostKobrakai]

There isn't one, other than passing the instance into the function as parameter. But really a class is way better in handling this kind of state. 

<?php namespace ProcessWire;

class Helpers extends Wire{
	
	public function getGlobalSeo()
	{
		return $this->wire('pages')->get('/')->seo;
	}
}

In the init.php

$helpers = $this->wire(new Helpers); // Wire the instance into the helpers class
$this->wire('helpers', $helpers); // Add as api variable

In your templates

$seo = $helpers->getGlobalSeo();
…