Comparisons in custom_field matching in article(_custom)?

jakob · 2016-12-02 09:32:07

Currently we can use customfieldname="value" as an attribute for txp:article and txp:article_custom. At present, this is an exact match, but if I recall correctly (can’t find it off-hand), there’s been some discussion on making this a bit more intelligent with multiple matching.

Would it be possible/feasible to introduce comparative operators to this, too? I’m thinking greater than / less than and newer/older/equals date comparisons.

Here’s just one possible use case: a typical situation for simple events lists is the publishing of an event with a start date and end date. As notification is usually posted long in advance of the start date, the in-built posted and expired dates are of limited use. Up to now, I’ve always used a pair of custom-fields in YYYY-MM-DD format and compared against NOW() using smd_query to execute a custom query.

Is this something article(_custom) could do in future? Or can it do that already but I’m not aware how?

etc · 2016-12-02 14:33:17

jakob wrote #303117:

Would it be possible/feasible to introduce comparative operators to this, too? I’m thinking greater than / less than and newer/older/equals date comparisons.

Here’s just one possible use case: a typical situation for simple events lists is the publishing of an event with a start date and end date. As notification is usually posted long in advance of the start date, the in-built posted and expired dates are of limited use. Up to now, I’ve always used a pair of custom-fields in YYYY-MM-DD format and compared against NOW() using smd_query to execute a custom query.

Is this something article(_custom) could do in future?

Yes we could! :-) The question is mainly syntactic: how to detect the comparison operator the user needs? We can not just define global operator attribute, since it would be applied to all custom fields, which is not always desirable. So we need to be able to detect the comparison operator from the fields value. For date fields (like Posted) it’s easy: something like

month="2016-10...2016-12-24"

could do (and would suffice in your case). But how to do it for arbitrary custom fields, given that they can contain ... or any other separator?

Or can it do that already but I’m not aware how?

If you set global $prefs['sql_now_posted'] = time() + 1000000; the forthcoming articles “posted” before this time will be output too (untested, though).

jakob · 2016-12-02 14:47:43

How about simply some keywords for standard comparisons and some simple operators?

For time/date comparisons maybe the same terms used in the time attribute, e.g. customfieldname="past", …="future", …="now" (IIRC php is clever enough to detect various date formats?)
For numeric comparisons …=">10", …="<0", …="!2" etc.
Possibly some other operator keywords in the form …="operator|value" such as those Stef has for smd_if where relevant to an article query.

I guess what’s possible / the proper notation is partly determined by what’s possible in an SQL query…

etc · 2016-12-02 15:00:33

Dunno. Few times I’ve been said “it’s not clear enough for Textpattern”. Is my_field=">10" or my_field=">|10" clear enough… poll?

etc · 2016-12-02 15:04:16

BTW, shouldn’t <txp:article month="2016-01" time="future" /> output post 2016-01 articles? Currently it outputs future articles with past publication date, i.e. nothing.

jakob · 2016-12-02 20:11:27

etc wrote #303129:

BTW, shouldn’t <txp:article month="2016-01" time="future" /> output post 2016-01 articles? Currently it outputs future articles with past publication date, i.e. nothing.

Sounds kind of logical to me (that you get no output) given that the two statements conflict.

etc · 2016-12-02 21:45:59

jakob wrote #303134:

Sounds kind of logical to me (that you get no output) given that the two statements conflict.

Yes, it’s logical, but I wonder how these attributes (month and time) combination could ever be useful. And wouldn’t it be better to consider <txp:article month="2016-01" time="future" /> as articles published after 2016-01?

etc · 2016-12-03 10:48:46

Actually, in 4.6 <txp:article /> has match attribute, currently underexploited. We could supercharge it with match="some_field:<, another_field:!=" pairs.

jakob · 2016-12-04 12:08:11

etc wrote #303136:

Yes, it’s logical, but I wonder how these attributes (month and time) combination could ever be useful. And wouldn’t it be better to consider <txp:article month="2016-01" time="future" /> as articles published after 2016-01?

Agreed, there’s certainly an argument for extending the month/year filter to output “older than” or “newer than” articles in combination with time="future" and time="past".

etc wrote #303137:

Actually, in 4.6 <txp:article /> has match attribute, currently underexploited. We could supercharge it with match="some_field:<, another_field:!=" pairs.

I think that was what I couldn’t remember in my initial post because it’s not in the docs. That would be an option too.

In terms of whether or not a separator should be used, I guess having a separator is more consistent, and not having one for simple cases (e.g. …=">10" is more immediately readable. There is, of course, the problem that a separator between (sub-)parameters may occur, for whatever reason, in the value of a custom_field. Stef uses an additional param_delim attribute to reassign that where necessary in his plugins but that adds a further attribute…

Nevertheless, I would welcome the idea of supercharging txp:article(_custom) without losing the basic simplicity it already has. The ability to …

compare against values (greater/less, true/false, older/newer)
match one or more values
define combinations of additional match conditions (category1 and category2 being an old favourite)

… would make it much more powerful. And even if the notation is slightly more complex than at present, it would still be much easier than writing one’s own (potentially less safe) queries in smd_query / etc_query and co.

etc · 2016-12-05 13:07:36

Ok, I would then suggest that we consider month as starting point and enhance month and time with other human-readable (and PHP understandable) values like +3 weeks. Then

<txp:article_custom month="now" time="+3 weeks" />

would output the articles with Posted between now and now +3 weeks. Does this make sense?

For other custom fields we should take into the account the future (4.8?) unlimited cf, unless someone (not me) has already a clear idea of it.

Bloke · 2016-12-05 13:27:31

etc wrote #303158:

Ok, I would then suggest that we consider month as starting point and enhance month and time with other human-readable (and PHP understandable) values like +3 weeks.

I like this. It should also be backwards compatible, because both month and time have been mutually exclusive so far.

For other custom fields we should take into the account the future (4.8?) unlimited cf, unless someone (not me) has already a clear idea of it.

I had a clear idea, once. It evaporated over six months of hacking core to get it to work. Now it’s more of a thought-slush. If the themes merge was tough, the custom-fields branch is going to break me!

The plan is that custom field names will no longer permit spaces. They’ll be “dumbed down” like we do with article titles so they can all be used as tag attributes in <txp:article_custom> and (hopefully) in tags for other content types. Use of custom_N will be supported but not encouraged. thisarticle is gonna be beefed up so that better l10n of strings is possible. I’d also like the cf names to be namespaced so they don’t clash with core globals.

Anything that relates to global attributes, etc will be supported by virtue of them being processed as regular tag attributes. Not sure how it affects this use case, but since each custom field has a type and one such type is ‘date’, well, we could conceivably use the same mechanism for such attributes.

GugUser · 2016-12-05 15:11:23

Bloke wrote #303161:

The plan is that custom field names will no longer permit spaces.

Although it’s out of topic: In this case it would be helpful if the custom fields had names and titles, similar to the sections. The names for the intern parsing and the titles for the backend interface.

Bloke · 2016-12-05 15:13:43

GugUser wrote #303171:

it would be helpful if the custom fields had names and titles, similar to the sections.

Nope. Names only. Titles are deferred to gTxt('my-custom-field-name') so they can be rendered in different languages, on both front- and admin-side.

Should be that way in the Sections panel, fwiw, but we have to live with it how it is.

GugUser · 2016-12-05 15:29:46

Bloke wrote #303172:

Titles are deferred to gTxt('my-custom-field-name') so they can be rendered in different languages, on both front- and admin-side.

Have I lost the overview in the discussion? How would that work?

Bloke · 2016-12-05 15:51:38

GugUser wrote #303174:

Have I lost the overview in the discussion?

I dunno. But it works that way on the admin side now. Try it out. Call one of your custom fields hr then visit the Write panel. You’ll see the custom field title horizontal rule. That’s gTxt() in action¹.

If you add your custom field name to the txp_lang table it’ll use it (ymmv if you use spaces).

Currently you can’t output the custom field’s title on the public site because there’s no mechanism to do so. But in future, the <txp:custom_field> tag will have the ability to not only render the value of the custom field, but its meta data too (name, title, type, etc). If you elect to output its title, it will run the name through gTxt() and display it. Thus if you don’t have a translation it’ll show the custom-field-name instead.

The upshot is that you’ll be able to define a custom field called book-title and then define its name as:

Titre de livre (in fr)
Buchtitel (in de)
…

People with their admin side set to one of those two languages will see the appropriate label. If the public site is set to one of those languages you’ll be able to output the label in the public-side’s language too.

I haven’t figured out how best to administer this yet — probably as part of the multi-lingual stuff in future versions. The implementation I have right now has a Title field when you define a custom field but it stores it in the current language only. That needs fixing when I merge the latest codebase into the branch. Uhh, somehow.

Does that help?

¹ Kudos to gaekwad for finding this: I never noticed until he pointed it out to me last month!

Last edited by Bloke (2016-12-05 16:08:06)

Textpattern CMS support forum

#1 2016-12-02 09:32:07