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.

Textpattern CMS

Textpattern CMS support forum

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