textpattern
Conditional tag to check Textpattern version
Is your feature request related to a problem?
Nope
What is the feature?
It may be handy to have a new tag that works in a kind of similar fashion to our if_plugin tag - in that if the Textpattern version is x or higher then execute the enclosed code.
That way we could provide some level of backwards compatibility in themes - i.e. if I've bolted in some code that only works with Textpattern 4.10 but isn't essential to the general functions of the theme, we can still provide that theme for Textpattern 4.9.
Think of it as a kind of 'progressive enhancement for Textpattern themes'.
Obviously I've not thought this through whatsoever 😀 so please feel free to provide opinions!
This is a fab idea.
How about we consider a tag that exposes system info instead? A bit like <txp:page_url> that outputs key system metadata such as version, PHP/MySQL version, SSL capability, or even a tag that can output key stuff from the txp_prefs table? That then means that any of this info is fair game for <txp:evaluate> or <txp:variable> or short codes and <txp:else /> so you can test them in any way you see fit.
I'm just thinking that our conditional tags really are quite numerous already. Heck, I'd consider a general-purpose <txp:if type="article_image"> tag, rather than <txp:if_article_image> but appreciate it's less readable. And having dedicated tags does allow <if::article_image> which is much neater in complex pages and aids debugging.
Anyway. Maybe if we consider a tag pair: one to output system info for your own processing/testing/display, and one conditional to test it? That way we get the best of both worlds. I don't think there's an inherent security concern here, as the tag usage is down to the site admin/designer to gauge which bits of it they use. We can always make up an allow-list of things we permit people to grab, like we do with <txp:page_url />.
If we go with the ability to access pref values, we'd need to be careful not to expose per-user prefs to anyone, so global prefs only would be accessible - again, maybe some sort of permitted subset (plus plugin global prefs). But I can definitely see value in taking decisions based on some (global) prefs.
OK, I'm not sure what extra stuff in prefs table would be of use (to me personally) but sounds interesting. I'll put a tentative 4.9 tag on the issue for further discussion.
Meanwhile, it's quite easy to make nameless if_plugin tag check core version.
Cool. There may not be any value in prefs. It just struck me as something that might be handy since the installed Txp version is stored there anyway so we'd need to nip in there to find out (unless we chose to interrogate the txp_version variable in code instead).
We already expose a lot of the paths and stuff that are in prefs via the <txp:page_url /> tag so a lot of that isn't necessary, but a few nuggets of niceness might include:
- tempdir/plugin_cache_dir
- file_max_upload_size
- email charset
- permlink date format
- locale
- timezone/offset/dst
- version
- production_status
- permlink_mode (global and/or for "this section")
Nothing else holds much value to the front end, although if employing front-end tags in a plugin dashboard tab, well, the other info in the prefs table starts to have intrinsic value if it could be exposed; even per-user prefs for the logged-in user might be handy to expose. Dunno.
I know all this info is available with a single line of PHP, but having it available in a tag does give non-programmers a chance at doing cool stuff that would otherwise only be open to plugin authors.
EDIT: <txp:if_production_status not status="live"> would be a boon for debugging purposes when wrapped with <txp:if_logged_in> :)
Meanwhile, it's quite easy to make nameless
if_plugintag check core version.
I reeeeally like that. But it kinda feels dirty.
I initially thought about an additional attribute on <txp:hide> would suffice for my basic requirement - but that doesn't give the option of using <txp:else /> I think.
For example:
<txp:hide version="4.8.5"> stuff </txp:hide>
That also gives the impression to me that you are hiding stuff for Textpattern 4.8.5, which is the opposite of what it really does (I want it to show for Textpattern 4.8.5 or higher, not hide it). Hmmm.
I reeeeally like that. But it kinda feels dirty.
Yep, unless we call it Easter egg. I'm sure there are some already...
... Or maybe a tag to extract pref table content by keys (with a <txp:else /> condition)?
Oooh, Easter comes early. Thanks, Oleg. We can look into a tag to check pref conditionals if we think it's appropriate in the next version.
Can we close this now the easter egg has landed or do we intend to do this in an official capacity somehow?
@Bloke - has your view changed since https://github.com/textpattern/textpattern/commit/1e42e0e9ce2693120ce0c1a252b89812318e8038#commitcomment-48081073 (i.e. proper tag in 4.9)?
I still think the hack is dirty, but handy as an undocumented (or one day documented?) feature.
I'd like a core tag for it, but adding another conditional just for this seems a little frivolous. So I'd rather it was put to better use as more general-purpose conditional - perhaps as outlined in the 'safely grab prefs values' proposal above. Assuming that has value and can be done without exposing user settings to anyone bar the logged-in user if used on an admin dashboard panel.
Tweaked issue title to reflect revised scope in https://github.com/textpattern/textpattern/issues/1651#issuecomment-852394276
If it's only for few prefs, we can hard-code them as <txp:if_request type="system" name="version" />. I don't really see more than this.
Though version needs to be handled via version_compare() function, unlike other data. I'm actually fine with <txp:if_plugin /> hack. We could alias it to a new <txp:if_version /> tag, if the name matters. Dunno
The if_plugin hack is fine. Nice feature. And it kind of fits there, tbh. If the others in the set listed above can be made part of if_request as you mentioned, that would work just fine.