Jump to content

Custom PHP code selector


blynx
 Share

Recommended Posts

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?

Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

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').

  • Like 10
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

  • Like 4
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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();

 

  • Like 4
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...