Thread

Is there any way to accomplish, roughly, this?

{exp:plugin1:method arg="{exp:plugin2:method}"}

I’ve tried a number of different approaches.

Approach 1:

{exp:plugin1:method arg="{exp:plugin2:method}"}

Result: Plugin1->method’s arg parameter value is the string, ‘{exp:plugin2:method}’, and it’s never parsed.

Approach 2:

My understanding of the parsing order suggests that this might have different results, but apparently it does not.

{preload_replace:replaced="{exp:plugin2:method}"}
{exp:plugin1:method arg="{replaced}"}

Result: The arg parameter has the same value as approach 1.

Approach 3:

First I define a snippet (snip), whose content is:

{exp:plugin2:method}

{exp:plugin1:method arg="{snip}"}

Result: Same as approaches 1 and 2.

Approach 4:

Noting that plugins are processed in the order they appear, I have even tested simply placing an instance of {exp:plugin2:method} before the {exp:plugin1:method} call. My thinking is that I could wrap this first call in a regex replacement plugin in order to suppress output, but that it would trigger Plugin2’s parsing first.

{exp:plugin2:method}
{exp:plugin1:method arg="{exp:plugin2:method}"}

Result: Plugin1->method’s arg parameter value is the temporary hash placeholder for Plugin2->method’s output (MD5 I believe) that the Template class reserves until later.

Is there any way to do this? Am I missing something totally obvious?

I am afraid that’s not a feasible approach. Your best option would be to combine the code of the two plugins into a single add-on, or otherwise use some PHP.

In practice this means it’s impossible to use a third-party plugin to populate parameters of a first-party module. Something as simple as passing an entry_id to the channel module.

This seems severely limiting to me, and I don’t think duplicating first-party modules or requiring PHP in templates should be the answer.

Well, you can nest plugins, like so:

{exp:foo}
  {exp:bar my_foo="{my_foo}"}
{/exp:foo}

where {my_foo} would be created by exp:foo. There are some examples of this in the docs.

You’re right. I guess that’s the workaround I’ll go for. But it would be nice to not have to do that. For anyone interested, I added this to my plugin’s constructor:

if(($tagdata = $this->EE->TMPL->tagdata) !== false && trim($tagdata) !== '') {
    // Cache public methods (class needs a static $public_methods declaration)
    if(!isset(self::$public_methods)) {
        self::$public_methods = array();
        $methods = get_class_methods($this);
        foreach($methods as $method) {
            if($method == get_class($this) || $method == '__construct') {
                continue;
            }
            $reflection = new ReflectionMethod(get_class($this), $method);
            if($reflection->isPublic()) {
                self::$public_methods[] = $method;
            }
        }

        self::$public_methods = implode('|', self::$public_methods);
    }

    $tagdata = preg_replace_callback('/\{(' . self::$public_methods . ')\}/',
        array($this, 'tagdata_callback'), $tagdata);
    $this->return_data = $tagdata;
}

And this callback method:

private function tagdata_callback($matches) {
    $method = $matches[1];
    return $this->$method();
}

Note that in order for this to work at all, the outer plugin needs to be parse=“inward”.

Edit: And due to relying on Reflection, it won’t work in PHP4. For that, you can maintain a manual list of public methods.

Thanks for sharing your solution with us. Please start a new thread as needed.