Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
if_custom_field gets a search makeover
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.valuemust exactly match the contents of the CFmatch="any": givenvalue="rod, jane, freddy"the tag checks if any of the given values occur anywhere in the custom fieldmatch="all": givenvalue="rod, jane, freddy"the tag checks if all of the values occur somewhere in the custom fieldmatch="pattern": allows you to specify a regular expression in yourvalueattribute 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 != rodneyandjane != janet(thoughfreddy == freddy) - the ‘any’ test will still pass because
freddyis 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)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: if_custom_field gets a search makeover
This is so smd_!
Great work, Stef! Thank you.
Offline
Re: if_custom_field gets a search makeover
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.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Offline
Re: if_custom_field gets a search makeover
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?
Providing help in hacking ATM! Come to courses and don’t forget to bring us notebook and hammer! What for notebook? What a kind of hacker you are without notebok?
Offline
Re: if_custom_field gets a search makeover
Great work Sam & Stef – this is ace news.
Offline
Re: if_custom_field gets a search makeover
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…
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: if_custom_field gets a search makeover
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"ormatch="all". Restore the current behaviour withseparator="" - Curve-ball: ditch the
separatoraltogether 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)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
#9 2010-03-08 12:00:44
- uli
- Moderator
- From: Cologne
- Registered: 2006-08-15
- Posts: 4,306
Re: if_custom_field gets a search makeover
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.
In bad weather I never leave home without wet_plugout, smd_where_used and adi_form_links
Offline