New Options Fieldtype (ProcessWire 2.5.17)

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()->title and $page->countries->title product 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

  • Pjotr

    Pjotr

    • 5 years ago
    • 63
    Yes! Nice. Can’t wait to try this.
  • Ryan

    Ryan

    • 5 years ago
    • 83
    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.

    • Teppo

      Teppo

      • 5 years ago
      • 43
      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 :)

  • Teppo

    Teppo

    • 5 years ago
    • 53
    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 :)

    • Sevarf2

      Sevarf2

      • 5 years ago
      • 53
      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...
    • Hani

      Hani

      • 5 years ago
      • 43
      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!
    • chrizzz

      chrizzz

      • 5 years ago
      • 43
      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 :)

    • kixe

      kixe

      • 3 years ago
      • 00
      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.

     

    Twitter updates

    • ProcessWire 3.0.142 has a lot of updates but the biggest is the addition of custom fields support for file and image fields. In this post, we take a closer look at that, and also outline all of the new features in the just-released FormBuilder v40— More
      11 October 2019
    • This week’s dev branch version brings you improvements to ProcessWire’s input->cookie API variable, plus it adds the ability to modify system URLs and paths at runtime. This post also includes some examples to demonstrate just how useful this can be— More
      20 September 2019
    • New post: This week we’ll take a look at a new version of FormBuilder that's on the way (with a screencast), as well as the latest version of the core: ProcessWire 3.0.140— More
      6 September 2019

    Latest news

    • ProcessWire Weekly #283
      The 283rd issue of ProcessWire Weekly introduces ProcessWire 3.0.142 and FormBuilder v40, highlights some conference content, and features a new weekly poll continuing with the #processwireworks theme. Read on!
      Weekly.pw / 12 October 2019
    • ProcessWire 3.0.142 core updates
      This latest version of the core on the dev branch has a lot of updates, bnd the biggest is the addition of custom fields support for file and image fields. In this post, we take a closer look and also outline all of the new features in the just-released FormBuilder v40.
      Blog / 11 October 2019
    • Subscribe to weekly ProcessWire news

    “Indeed, if ProcessWire can be considered as a CMS in its own right, it also offers all the advantages of a CMF (Content Management Framework). Unlike other solutions, the programmer is not forced to follow the proposed model and can integrate his/her ways of doing things.” —Guy Verville, Spiria Digital Inc.