Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: rvm_inherit 0.3
I’ve developed it based on the current 4.6-dev version. It probably also works with versions older than 4.5.7 (but please update if you’re still running older versions) because I’m not using anything special in the plugin; I just didn’t test it on older versions.
Offline
Re: rvm_inherit 0.3
candyman wrote #290982:
The only weak point (as all design not-core functions) is that all will depend on your plugin and its upgrades for the future
Front-of-house plugins like this tend to fare much better at upgrade time than admin-side ones, so there’s little need to worry. smd_if, for example, hasn’t changed drastically since 4.0.6 and still works under 4.6.x. Same with glx_if, which predates my plugin back to 4.0.0 and even into the gamma days.
The only requirement from 4.6 onwards, is that plugin tags need registering to avoid throwing a warning in Testing/Debugging modes. That’s a one-line fix for any plugin. Out of the gate, the plugins will still work without it, but one day far into the future they’ll all need registering to work, for security reasons.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: rvm_inherit 0.3
Bloke wrote #290986:
The only requirement from 4.6 onwards, is that plugin tags need registering to avoid throwing a warning in Testing/Debugging modes.
That is already included in the current plugin.
Offline
Re: rvm_inherit 0.3
I have quickly and painlessly made my error_default page match the default page design. Now it takes only 6 lines of code, so far so good.
Offline
Re: rvm_inherit 0.3
maniqui wrote #290977:
…with template inheritance, you usually avoid doing “includes” over and over again in all your templates.
That’s what I recognized immediately.
etc wrote #291020:
I have quickly and painlessly made my
error_defaultpage match thedefaultpage design. Now it takes only 6 lines of code, so far so good.
Excellent use case as a start.
Nice plugin, Ruud!
Offline
Re: rvm_inherit 0.3
I’ve experimented with rvm_inherit a couple of times, and especially like that we can do away with all the nested if… then … else … if … then … convolutions to do things like title, meta, custom canonical urls and other contextual stuff in templates by simply putting a placeholder in a parent and populating it from the context-specific child or grandchild template.
An associated question: how would one add block caching à la aks_cache to the parent or child template? And would this work?
If you’re not familiar with aks_cache, you wrap query intensive sections of code in aks_cache tags and name them either with a global name or with a context-specific name so that they no longer need processing until the cache clears or is cleared by updating the site. With the regular parsing method, it’s fairly straightforward and you can name the blocks dynamically using tags in tags to save context-specific cache blocks as they occur. But I’m not sure where to start with the back-and-forth parent-child / child-parent associations that rvm_inherit allows, and whether it would affect how rvm_inherit works?
TXP Builders – finely-crafted code, design and txp
Offline
Re: rvm_inherit 0.3
I’m glad to hear you use/like it.
In the most simple setup where you use the child template to override parts of the parent template, you would probably put the cache block in the child template inside the overriding blocks.
For all other uses, I don’t have an answer ready, but you can see what happens by watching the tag trace.
Offline
Re: rvm_inherit 0.3
Thanks for the feedback. I’ll try that out. For that simple situation I guess it makes sense to cache the the most specific case with a distinct cache id/block name…
TXP Builders – finely-crafted code, design and txp
Offline
Re: rvm_inherit 0.3
Great plugin, ruud. It cuts downs the LoC, keeping things DRY. Thanks.
A tip:
suppose you need to have some default logic (on your default, inherited template) to populate a variable. But, also, you want to be able to override that value (and so, to ignore that default logic), when needed, from the inheriting template.
Then, you could do something like this:
// _default template (inherited)
<html>
<body>
...
<txp:variable name="page-title">
<txp:section title="1" />
</txp:variable>
<txp:if_individual_article>
<txp:variable name="page-title">
<txp:title />
</txp:variable>
</txp:if_individual_article>
<h1>
<txp:rvm_block name="heading">
<txp:variable name="page-title" />
</txp:rvm_block>
</h1>
...
</body>
</html>// my_section template (inheriting)
<txp:rvm_inherit page="_default">
<txp:rvm_block name="heading">
My cool title
</txp:rvm_block>
</txp:rvm_inherit>On the “About” section (assuming its page template inherits also from the _default template), you would get this output:
// output
<html>
<body>
...
<h1>
About
</h1>
...
</body>
</html>On an individual article on the “About” section, you would get this output:
// output
<html>
<body>
...
<h1>
Some article title
</h1>
...
</body>
</html>And, finally, on the “My Section” section (where you want to override the heading text’s logic on the _default template), you would get this output:
// output
<html>
<body>
...
<h1>
My cool title
</h1>
...
</body>
</html>As you can see, in the _default template, we have some simple logic1 to define the value for the page-title variable, which is the variable that will fill in the <h1></h1>
Then, on the inheriting my_section template, we overwrite the heading block. In other words, from the inheriting template, we “get rid” of the logic used on the inherited template.
1 (basically, the logic says: default to the section’s title; if we are on an individual article, then use the article’s title).
Offline