article_custom, custom_field attribute that accepts multiple values.

mrdale · 2015-06-08 19:08:21

<txp:article_custom limit="15" my_custom_field="this|that|the other" form="myform" />

returns articles that have “this” or “that” or “the other” in my_custom_field

<txp:article_custom limit="15" my_custom_field="(this|that|the other)AND(sheepway)" form="myform" />

returns articles that have “this” or “that” or “the other” as well as “sheepway” in my_custom_field

This would save a lot of shenannigans with <txp:if_custom_field /> while returning the correct number of articles prefiltered.

Your thoughts?

GugUser · 2015-06-08 19:41:01

With <txp:if_custom_field> inside you can select / match many things, included through regular expressions. Look here.

mrdale · 2015-06-08 21:06:38

GugUser wrote #291432:

With <txp:if_custom_field> inside you can select / match many things, included through regular expressions. Look here.

Correct, and I’ve been doing this for years, but when you filter articles this way you are not able to reliably use <txp:if_first_article / > or <txp:if_last_article / >

Bloke · 2015-06-09 09:29:48

mrdale wrote #291435:

but when you filter articles this way you are not able to reliably use <txp:if_first_article / > or <txp:if_last_article / >

And automatic article counts get messed up so you have to keep a count of which ones you’ve extracted. It also means limit and offset don’t work because you might only pull out 8 “matching” records from your desired limit="10" article set.

This means you need to (sometimes substantially) increase the limit beyond what you need so you have enough of an article pool to ensure you meet the number of required results. offset is even more tricky as you need to manually figure out when you’ve reached the start point.

With regards the original proposal, it’s interesting. Might need to revise the syntax a bit to make it more usable but I’ll keep this in mind when I get back to unlimited custom fields. Things are changing, see. Custom fields will no longer just be created using a semi-useless title with the ability to corrupt your website: they’ll have:

a name, which in regular expression parlance must conform to [a-z][a-z0-9_]*.
a title, which can be any text you like (as it is now). Crucially though, this is NOT stored in the table any more. Behind the scenes it maintains a Textpack string in the current language, prefixed with (at the moment) cf_, enabling the custom field titles to be translated.
an internal ID for backwards compatibility and immutability (custom_1, custom_2, etc).

The ramifications are that I plan to permit you to interchange your_field_name="blah" and custom_N="blah" in <txp:article_custom> tags if you so desire, although the numbered approach will be discouraged as it’s less flexible, especially when migrating/merging one system to another or during backup/restore into an already populated DB. We both know aaaallll about this :-)

The tough part is how to manage upgrades and how to handle sorting and tag attributes cleanly. Currently, you need to know the custom field’s ID to do sorting which is not ideal if we’re making the IDs a secondary citizen over the name. Using sort="your_field_name" would be great if the SQL pulled out the custom fields as virtual columns, each with the name of the field. Except there’s nothing to stop you using title as the name and we’re then back to square one. This also applies to article_custom attributes. If you called your CF excerpted, for example, it’ll clash with the built-in attribute if you try to filter by it.

So ideally the virtual columns need prefixing (cf_) in the SQL result set. Except this has a knock-on effect which requires the admin to know this fact so they can use sort="cf_your_field_name" or <txp:article_custom cf_your_field_name="blah" />. One way I’m considering is to add the cf_ prefix to the interface when you create the fields, as a visual clue that you need to use it everywhere. So in ASCII-art the box would look like:

Field name: cf_ |_________________|

Not exactly pretty, and a bit horrible when using the built-in functions to render input widgets so I’d rather not do this.

Alternatives are to do some kind of field aliasing, perhaps assuming that any attribute that does not have a direct analogue with a built-in column should have cf_ prepended to it and be automatically treated as a custom field. Or outlaw any field names that are the same as any existing columns.

To do either of those effectively and with minimal coding overhead (i.e. having to keep the custom field no-go-list in sync with any future table or tag changes, or test the existing table column names) across all content types is no mean achievement and is the main reason I’ve ripped up the implementation three times already and started over. Still not there…

Incidentally, if anyone has any thoughts on how to make all this workable, I’m open to discussion, either in the forum or offline via email.

etc · 2015-06-09 16:33:41

mrdale wrote #291428:

<txp:article_custom limit="15" my_custom_field="(this|that|the other)AND(sheepway)" form="myform" />

returns articles that have “this” or “that” or “the other” as well as “sheepway” in my_custom_field

Actually, that’s exactly how etc_search works: (this,that,other) sheepway is transformed in (this OR that OR other) AND sheepway. Works for any field, any table, any separator, plus pagination.

mrdale · 2015-06-09 22:02:28

@etc… Yeah, I know, I really need to grok etc query once and for all, that is definitely the be all and end all of swiss army knives

@bloke. Very cool stuff to look forward to. Do you see expanded article filtering for article_custom dovetailing nicely with the new CF data footprint?

etc · 2015-06-10 07:03:02

mrdale wrote #291464:

@etc… Yeah, I know, I really need to grok etc query once and for all, that is definitely the be all and end all of swiss army knives

That’s all very fine, but what about my post?

Bloke · 2015-06-10 10:52:47

mrdale wrote #291464:

Do you see expanded article filtering for article_custom dovetailing nicely with the new CF data footprint?

I’d like it to do so, yes. That’s certainly the plan. Just gotta find a way to do it.

Textpattern CMS

Textpattern CMS support forum

#1 2015-06-08 19:08:21