PrevProcessWire core updates (2.5.16)
Blank versus 0, Configurable URL segments from template settings, and more… More
30 January 2015 by Ryan Cramer 8 Comments
Selectable Options in ProcessWire
Many people new to ProcessWire initially think that we don't have any kind of selectable options fields. But then they discover the Page Fieldtype, and then realize that not only do we have selectable options, we've got them on steroids!
Despite that, the fact remains that this is one area where ProcessWire is completely unique (relative to other CMSs out there), and thus it may take awhile before people "get" it. I've always worried that someone evaluating PW might overlook this, and move-on before they really understand the power of what PW offers in this area.
Then there's also the aspect that pages are sometimes overkill for all selectable-option needs. Granted, there's no harm in it, and I'd rather be over-prepared than under-prepared. But using pages for selectable options does require a certain level of understanding and planning, and perhaps a little more time, than people always have.
Given these factors, something that's been on my @todo for a long time has been to create a new fieldtype that provides selectable options, outside of using pages. But I didn't want to skimp on building it the right way, and building it the right way takes time. It means storing references to options rather than the options themselves, in a database normalized way, while still making it possible to query the text of those options from selectors.
Introducing FieldtypeOptions
This week I'm glad to introduce the new FieldtypeOptions module, which provides a neat alternative to pages for selectable options in ProcessWire. Here are a few highlights:
- Provides selectable options in a normalized, scalable way. If you edit or rename an existing option, the change is reflected in all existing selections. If an option is deleted, all usages and references are likewise deleted.
- Supports input from any module that extends InputfieldSelect, including single and multi-value inputs. This includes numerous core and 3rd party Inputfield modules. In the core, this includes Select, Select Multiple, Checkboxes, Radios, and AsmSelect.
- Options are exceptionally easy to define. If you want to create a Options field with 200 selectable countries, just copy and paste a list of countries from a page like this (titles only) or this (values and titles), and paste them into the field. Save, and you are done.
- Options are multi-language. If you have LanguageSupport installed (with LanguageSupportFields), your options definition gets a tab for each language.
- Options are sortable per-page, when supported by the Inputfield (like AsmSelect).
- Supports pre-selected options when combined with "required" status.
- Each option contains a "title", but can also optionally have an independent "value" that goes with it.
- Accessed from the API in the same way as pages.
- Unlike pages, the same API code can apply to either single or multi-value selections. To put it simply,
$page->countries->first()->titleand$page->countries->titleproduct the same result. Meaning, properties of the first item can be accessed directly from array value. - All option deletions are confirmed.
- Options can be managed from the admin, but also from the API (as you would expect in PW).
If this sounds interesting to you, please see the new documentation page for the Options Fieldtype. Since this is brand new, and only on the dev branch (PW 2.5.17+) please consider it beta… use it for sites in development, but not yet for live or production sites. Please let me know how it works for you.
Comments
NextProcessWire core updates (2.5.18)
6 February 2015 3
Field editor now lets you target templates, optimization to field cloning, and numerous updates to sessions. More
Pjotr
Yes! Nice. Can’t wait to try this.
Reply
Ryan
The question is an easy one when talking about forms that get submitted once, but not so easy when talking about forms that edit existing pages and will continue to do so indefinitely in the future. That's why you see in initial value support in many Inputfields that doesn't apply when used in a page/field context. Meaning, you see the option when using an Inputfield in FormBuilder, but not when using the same Inputfield for editing a page field.
When it comes to this FieldtypeOptions module, initial value support (pre-selected options) needs "required" status for the Inputfield because it has to have some way to know when to populate the initial value. It knows to populate the initial value when there is no selection present. There isn't any other straightforward way for it to make that determination, unless we limit the feature only to newly created pages.
If the user were to de-select everything so that no options are selected, then the initial value would once again get populated the next time they edited the page. That's why we only support initial values if "required" status is active, as it prevents the possibility of the user de-selecting all options and assuming it will stay that way.
There is an easy way around it though. Create an option to represent "no selection", likely your first option. If the user literally wants no selection, they would select that, and still meet the "required" status of the field. From there you can have any pre-selected option(s) you want. Since you as the site developer put that option there, you can likewise know when to act–or not act–upon it in your output code.
Reply
Teppo
Makes sense, thanks for the explanation Ryan!
I've implemented "checked by default" fields before, but admittedly that has required jumping through some hoops, and such solutions probably don't belong to any core features. The "no selection" method you mentioned is how we usually approach this, but in some cases it can sound downright confusing. It depends a lot on the context, really.
Note that I'm not worried about myself here at all. I can handle negative selections just fine. It's just that explaining to end users any choice that obviously isn't the most logical one from the UI/UX point of view can feel rather awkward :)
Reply
Teppo
Does "supports pre-selected options when combined with "required" status" mean that, if I wanted to have one option selected by default, the field would always require at least one value checked/selected?
Asking, because for me/us a very typical use case is something like a checkbox which is checked by default but can be unchecked by the user. Would be really nice to see native support for this :)
Reply
Sevarf2
That's exactly what I was dreaming for! In the past years I used pages for categories, typologies and so on... This field fits perfectly for this...
Reply
Hani
YES! This is going to be beautiful! This is going to be such a great replacement for the very simple module I built ages ago, Fieldtype: Select (AKA Drop Down), which has very limited functionality. It seems like that module got some good use by others, but this will be the go-to module for that functionality now since it offers so much more as well. Thanks for your work on this, Ryan!
Reply
chrizzz
yay! This sounds like the solution I am searching at the moment for. When it'll me in the production version? :D
Thanks Ryan for implementing this. I'll try it as soon as possible :)
Reply
kixe
Ryan said:
To put it simply, $page->countries->first()->title and $page->countries->title product the same result. Meaning, properties of the first item can be accessed directly from array value.
Unlikely $page->get() method doesn't return expected results.
$page->get('countries.title') return array instead of string
$page->get('countries.first.title') return array too
Am I missing something? If not, would be nice to have consistence here and access to the properties via dot syntax too.
Reply