You are not logged in.
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="exact": the default, and the same as before, i.e.
valuemust exactly match the contents of the CF
value="rod, jane, freddy"the tag checks if any of the given values occur anywhere in the custom field
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
valueattribute 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:
rod != rodneyand
jane != janet(though
freddy == freddy)
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)
This is so
Great work, Stef! Thank you.
La música ideas portará y siempre continuará
This is so
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.
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?
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…
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="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
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:
match="all". Restore the current behaviour with
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)
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.