if_custom_field gets a search makeover

Bloke · 2010-03-05 16:14:56

Changeset r3325 introduces the ability to do more with custom fields. As well as the attribute val now being deprecated and being replaced with value, you can now perform different types of search using the new match attribute:

match="exact": the default, and the same as before, i.e. value must exactly match the contents of the CF
match="any": given value="rod, jane, freddy" the tag checks if any of the given values occur anywhere in the custom field
match="all": given value="rod, jane, freddy" the tag checks if all of the values occur somewhere in the custom field
match="pattern": allows you to specify a regular expression in your value attribute to match the custom field against. Sky’s the limit here, e.g. value="<a href=""http://site.com/.*"">.*</a>" would return true if the custom field contained an anchor tag to some resource on your site

Remember that there’s no intrinsic concept of lists inside a custom field. This has implications for testing so, for example, if your custom field contained the string:

zippy | (jane)t | (freddy) | george | (rod)ney

then both the above ‘all’ and ‘any’ tests will return true because the character sequences appear within the entire custom field contents, as indicated in parenthesized bold.

To counter this, you may specify the separator argument, which will then treat the custom field as a list of items delimited by the given separator character. Once you have done that:

the ‘all’ test above will fail, because each item is considered its own entity and therefore rod != rodney and jane != janet (though freddy == freddy)
the ‘any’ test will still pass because freddy is one of the items in the list

This change allows you to do all manner of clever tricks with custom fields and means that delimited lists of things created by glz_custom_fields or sed_pcf (or of course, manually by yourself), can be tested with the native tag if you wish. If you need to step outside the bounds of this, you’ll still need a plugin like rah_repeat, sed_pcf or smd_each for example.

So, treat your custom fields to some native conditional magic and see where it can take your sites.

Last edited by Bloke (2010-03-05 16:20:46)

maniqui · 2010-03-05 16:39:15

This is so smd_!
Great work, Stef! Thank you.

Bloke · 2010-03-06 00:16:56

maniqui wrote:

This is so smd_!

Hehe, it’s actually so artagesw. Sam added the match all/any thing to the site search feature, which is brilliant for front-of-house article searches; I just wondered what would happen if this idea was extended to custom fields. Having to always do exact matches in custom fields seems a bit limiting when they are essentially fields that you can choose to store any type of data (up to 255 chars) that you like.

So now, if you want to use them to store lists of things or want to find if someone has set a custom field’s value to one of a number of things, or find if a CF begins with certain characters, you can do so. The pattern matching was a logical extension for the sake of 4 extra lines of code and really opens it up so you can use if_custom_field to take action if a particular CF has data in a particular format, and perhaps return some default message if not.

I hope it turns out to be useful for enabling you to use custom fields in ever more innovative ways.

artagesw · 2010-03-06 01:25:49

Nice!

the_ghost · 2010-03-06 07:40:04

I’ve just made a little editing to Wiki
Am I right with this statement?

NB: Attribute “val” would be changed to “value” in releases next to 4.2.0

And should we add new attr to wiki now or it’s better to wait untill next release?

pieman · 2010-03-06 09:31:30

Great work Sam & Stef – this is ace news.

Bloke · 2010-03-06 16:40:08

the_ghost wrote:

should we add new attr to wiki now or it’s better to wait untill next release?

Thanks for the adjustment. Good to warn people. I made a start writing the new parts for Textbook the other day and hid the new stuff in HTML comments. I’ll do the if_custom_field tag too at some point.

Generally it’s best to wait until release before updating the documentation because it can get confusing if the wiki refers to two versions simultaneously (yeah yeah, a lot of the pages are outdated and still refer to version 4.0.x *sigh* one day!) Any changes for future tags go in the Tags in development article. I’ve made a start there too: feel free to dive in if you wish…

Bloke · 2010-03-08 10:20:02

Regarding the separator attribute — which defines the separator used in the contents of your custom_field — ruud pointed out that it might make sense to set it to comma by default. That’s kind of appealing, but I thought I’d present both sides of the coin here and see what you all thought.

The separator is currently only employed if you use match="any" or match="all"; since I decided that match="pattern" (and of course match="exact") would always apply to the custom field as a whole entity. Whether this is a good idea or not remains to be seen!

The implication of setting separator="," by default is that if you use any/all matching, your chosen custom field will automatically be divided at any comma character and your any/all list applied to each part. If you know your custom field is going to contain a list of things, that’s perfect and saves you having to set it by hand; but if it happened to contain the string Nothing to see here, please disperse then each word in your list would first be checked against Nothing to see here and then against please disperse. If you wanted to override this behaviour back to testing the whole string, you’d have to override the default comma with separator="".

I think glz_custom_fields uses the pipe separator for items like checkboxes and select list values in its custom fields, so if you need to test individual elements from that plugin, you’ll need to change the separator anyway.

So what’s the consensus here:

Opt-in: Leave it as it is so you must declare to the tag that you intend to treat your custom field as a list, otherwise it’s treated as a whole string
Opt-out: Have it automatically treated as a list if you decide to set match="any" or match="all". Restore the current behaviour with separator=""
Curve-ball: ditch the separator altogether and force all match tests to be compared against the whole string (implies less flexibility, no direct compatibility with glz_cf, likely more complicated test values required to avoid matches in the middle of other strings, but potentially less confusing for the novice)

Cast your votes, please…

Last edited by Bloke (2010-03-08 10:20:52)

uli · 2010-03-08 12:00:44

I donate my 2¢ to the #1 option and opt for opt-in which is also nice to novices (who tend to disregard additional parameters) but offers the possibility to use the separator of choice.

Textpattern CMS

Textpattern CMS support forum

#1 2010-03-05 16:14:56

if_custom_field gets a search makeover

#2 2010-03-05 16:39:15

Re: if_custom_field gets a search makeover

#3 2010-03-06 00:16:56

Re: if_custom_field gets a search makeover

#4 2010-03-06 01:25:49

Re: if_custom_field gets a search makeover

#5 2010-03-06 07:40:04

Re: if_custom_field gets a search makeover

#6 2010-03-06 09:31:30

Re: if_custom_field gets a search makeover

#7 2010-03-06 16:40:08

Re: if_custom_field gets a search makeover

#8 2010-03-08 10:20:02

Re: if_custom_field gets a search makeover

#9 2010-03-08 12:00:44

Re: if_custom_field gets a search makeover

Board footer