if_title and if_body tags

philwareham · 2015-02-03 10:34:06

Following a discussion with Pete Cooper about the fact that Textpattern articles can legitimately be posted without body content or indeed title content, I think we need the following tags to be consistent with other functionality:

<txp:if_title> and <txp:if_body>

This is even more relevant once Stef complete’s the extended custom field support, because it’s quite feasible that some articles won’t need a title or body, rather they would just contain custom content.

Thoughts?

Bloke · 2015-02-03 11:17:55

philwareham wrote #287996:

<txp:if_title>

Although Txp allows you to store a post without title (and complains), it’s not accessible from the front end via URL (try it). But <txp:article_custom> can get at it and you could be using it for control purposes or as a special “hidden” article that contains meta data only. Arguably there may need to be some way to conditionally display “Untitled” like is done on the Articles panel, though it’s edge case stuff. More tangible problems arise when using it like this, which renders an empty anchor:

<a href="<txp:permlink />" itemprop="url">
   <txp:title />
</a>

However, there is an undocumented trick, owing to the fact that custom fields are not validated as solely “custom”:

<txp:if_custom_field name="Title">
   <a href="<txp:permlink />" itemprop="url">
      <txp:title />
   </a>
<txp:else />
   Untitled
</txp:if_custom_field>

I used this the other day as it happened, because my Title field contained HTML markup and there’s no core way to turn off escaping in that field. So instead of using <txp:title /> I used <txp:custom_field name="Title" escape="" /> :-)

Same goes for Body, btw, although that is more tricky given that some (older?) versions of Textile store an empty <p></p> tag even if there’s no content.

tl;dr: I’ve no problem adding them if there are no other objections.

colak · 2015-02-03 13:07:42

Hi Stef, Phil,

I guess the undocumented features should become official and treat all fields like custom_fields unless of course there is a programming glitch that I we can not foresee.

Bloke · 2015-02-03 13:28:44

colak wrote #287999:

I guess the undocumented features should become official

Since it’s merely a by-product of the way Txp’s internals work and there’s no guarantee that Txp will continue to work that way in future, documenting it officially might be unwise.

But I’m in no hurry to change this situation (even after custom fields are revamped), because it doesn’t harm anything and provides flexibility that would otherwise require a plugin.

Most of the time nobody needs to know about it because core tags cater for most situations. Plus, there’s an argument that documenting such a “feature” might confuse newcomers. But if it’s just adding a note to the custom_field and if_custom_field pages, then maybe there’s scope to document it anyway and we’ll worry about undocumenting it again if someone comes up with a very good reason why we shouldn’t treat all publicly exposed article fields as custom fields.

colak · 2015-02-03 14:17:14

Bloke wrote #288000:

Since it’s merely a by-product of the way Txp’s internals work and there’s no guarantee that Txp will continue to work that way in future, documenting it officially might be unwise.

Understood. It was said many times, but I just had this wishful thinking that maybe these features could remain as part of the core especially if custom_field could be abbreviated to cf. Something like <txp:if_cf name="cfname" type="article"><txp:cf name="cfname" /></txp:if_cf>. Quick and easy to write and it could be expanded to <txp:if_cf name="cfname" type="image"><txp:cf name="cfname" /></txp:if_cf>… depending on the tab.

Bloke · 2015-02-03 14:23:20

colak wrote #288002:

Understood. It was said many times, but I just had this wishful thinking that maybe these features could remain as part of the core.

Oh, I want them to remain. But since it’s undocumented (in the code) then one day somebody might come along and say “hey, this line of code means that anyone can access article data from the custom_field tags” and close the loophole. I keep meaning to document it in the code to make it appear intentional so it doesn’t get removed by an over-zealous dev/patcher; I’ll try and remember to do that.

On some level, officially documenting it in the wiki might protect the feature for future generations, so if you want to put a stake in the ground and document it, you may get your wish :-)

Bloke · 2015-02-03 14:27:01

colak wrote #288002:

Something like <txp:if_cf name="cfname" type="article"><txp:cf name="cfname" /></txp:if_cf>.

That’s what I’m aiming for (of sorts), except the type is implicit depending on context. Thus you don’t need to specify it inside, say, a <txp:article> tag unless you want to refer to a field in a different context.

colak · 2015-02-03 15:58:40

Bloke wrote #288004:

That’s what I’m aiming for (of sorts), except the type is implicit depending on context. Thus you don’t need to specify it inside, say, a <txp:article> tag unless you want to refer to a field in a different context.

What was it that Julian Clary used to say back in the 80s?… I’m moist with anticipation!!!

michaelkpate · 2015-02-03 18:15:56

colak wrote #288005:

What was it that Julian Clary used to say back in the 80s?… I’m moist with anticipation!!!

http://www.youtube.com/watch?v=wlwnbcxBuzI

Textpattern CMS

Textpattern CMS support forum

#1 2015-02-03 10:34:06