I’ve been developing a site with EE and I had to override the built-in URL format early on because it is too simplistic to meet my needs. My understanding was that by using various parameters of the weblog:entries tag (e.g. dynamic, url_title) and the various ways of extracting segments of the URL, I could pass the data I need in a URL format of my design and specifically tell weblog:entries what to retrieve. That’s worked somewhat, but I’ve encountered a number of problems. I’m now realizing that a couple of techniques I’ve been relying on are really not documented (unless I just can’t find where they’re documented) and I need to find out what the status of those features is.
1) Parameter values from plugins.
I can’t seem to find any reference to this in the documentation. I’m talking about something like the following.
{exp:weblog:entries dynamic="off" url_title="{exp:my_plugin:my_method my_param='my_value'}"}(See also #3, below.)
Is that a supported feature? An undocumented or experimental feature? It’s not nothing, because in at least some cases it works, and when doing that, turning on template debugging reveals this output: “Plugin in Parameter, Processing Plugin First”
2) A possible alternative (less clean and intuitive than #1, in my opinion) I see to doing that, is this:
{exp:my_plugin:my_method parse="inward"}
{exp:weblog:entries url_title="{my_var}"}{entry_id}{/exp:weblog:entries}
{/exp:my_plugin:my_method}The idea being that my_plugin::my_method() provides the value for my_var using methods like Template::swap_var_single(). Is that a supported feature? The Template Class documentation seems to only talk about using that feature with modules. Plugins are not mentioned outside of the introduction. Quotes from the rest of the page:
“When the Template class calls a module, the Template class makes availale to the module class the parameters, variables, and content of the tag currently being processed.”
Under the heading “Data Within Tag Pairs”
“Except in rare cases, a module will have both an opening and closing tag.”
“Module code in template. The tag data is everything from the end of the opening tag to the beginning of the closing tag, basically the HTML and tag variables.”
Example code of “A module calling and using the tag data.”
“Before calling the module for the ExpressionEngine tag, the Template class parses out all of the variables contain in the tag’s data…”
Etc.
Also, the Using Plugins documentation mentions nesting plugin tags, but doesn’t mention nesting module tags (e.g. {exp:weblog:entries}) within plugin tags.
3) Use of parse=“inward” with tags, e.g. {exp:weblog:entries}
Use of the parse=“inward” parameter is only documented for plugins, but it has an effect when used with {exp:weblog:entries}. In fact, it’s necessary to make the plugin-as-parameter-value behavior described in #1 work.
{!-- Doesn't work --}
{exp:weblog:entries dynamic="off" url_title="{exp:my_plugin:my_method}"}{entry_id}{/exp:weblog:entries}
{!-- Does --}
{exp:weblog:entries dynamic="off" url_title="{exp:my_plugin:my_method}" parse="inward"}{entry_id}{/exp:weblog:entries}
Is that behavior intentional / unintentional / supported / unsupported / experimental / planned / ???
Is there some documentation of the relative parse order of module / plugin tags? Are module tags allowed to be nested within plugin tags?