How do make a selectbox fieldtype with static values?

[alkahest]

This seems really simple but I'm missing it: How do I create a fieldtype that's just a select box with a set of hardcoded values?

Like:

-- Choose --

- Red

- Blue

- Green

I don't want to create pages for each select option using the Page field type.

[kongondo]

I am assuming you want this for the admin and not the front end?     Here you go: http://processwire.com/talk/topic/201-fieldtype-select-aka-drop-down/

[alkahest]

Ah, I see that this module's approach isn't relational...

So I guess, since I'm already hiding branches of the tree from the client user role, what I'll do is just make a page called "colors" with its children being each "color" object. Then I'll hide that page and the children from the home tree [like so: http://processwire.com/talk/topic/4154-first-steps-to-making-new-admin-tabs/], this way the client role can't get at that part of the site except when choosing the children to associate with other pages.

[Pete]

That's the best way to go about it - you can then take it further if you ever need to by doing searched on pages with a certain colour etc. Might not be that likely in your case, but if it was for a clothing website for example then something that lets the user filter by red clothes if it's their favourite colour might be desirable.

Sometimes it can feel a little overkill to do it this way, but it always leaves you with future possibilities rather than just static values

[Soma]

Not to mention you can also make it easily multi-language. One of the reason it's a clever system.

[Pete]

Not to mention you can also make it easily multi-language. One of the reason it's a clever system.

I always forget about that - another good reason!

[alkahest]

PW continues to surprise me with its simple goodness.

[MatthewSchenker]

Greetings,

The idea of selects being pages -- at first -- seems odd, because other CMSs have simpler ways to do it.  But the first time you need to have multi-dimensional elements as selects, you realize how terrific this is.

Just a simple example...

In one of my recent projects, admins create store pages and add the location by selecting a US state.  They need to see the full name of the states in the select box.  I also needed to create a search that allowed visitors to find those stores by entering any or all of the state name.  But, I also needed to display state abbreviations in store listing pages.  Using ProcessWire selects, I just created "state" pages with the title field, as well as an "abbreviation" field, then used those pages to populate the select.  The person creating the page doesn't even know the abbreviations are there.  They just know that when they select the full state name, magically, the proper abbreviation shows up in the listings pages.

You could go many levels down (or up) from there!

Thanks,

Matthew

[alkahest]

Yes, that makes sense.

My only gripe has to do with presentation to the user in the admin; while right now I have the ability to slice off irrelevant/non-navigable parts of the main tree so that client user roles can't see it (like these colors in this case, which are not part of the hierarchy of the site in the client's mind), PW doesn't provide a built-in way to do that. From what I've read around the forum, there's no real hook to stop certain parts of the tree from rendering; I have to pop them out of the JSON per soma's technique.

[Martijn Geerts]

Settings You can store in the admin. (/processwire/

if you create a structure like this:

/Processwire/Settings/  <- hide from menu & enable guest access ( will show open lock )
            /Settings/color/
                     /color/red/
                     /color/blue/
                     /color/green/
            /Settings/position/
                     /position/top/
                     /position/left/
                     /position/right/

Then the editors won't see anything in the tree.

And you can query for your color or position.

[diogo]

@alkahest, as always the built-in way to do things in PW is the simplest possible:

create a new page "selects" under admin (like this it will be automatically hidden from the editors), and create any new selectors and it's options under it.

edit: Martijn was faster

[Soma]

Actually you don't have to use page for everything, usually it's ok, but I myself use the static select for defining a color. Depends what the select really is for but if it's just for a setting you'll never use anywhere as pages really it's ok too. I setup a color select and the value is also the css class name so it's as easy as:

<?php echo "class='$page->color';?>

Also for status setting where you possibly need more than just a checkbox it can make sense to use a static select. 

So as a rule I try to think ahead what that select really is used for that makes it easy to decide. Even the color select can make sense to have dynamic as you maybe gonna change the value or something and then you're happy to just edit the value on the page and done. Otherwise you'd have to run a little script (easy too) to change already saved values in DB for pages.

[Soma]

BTW, you can also you repeater to fill a page field select. They're also just pages at the end and I've done exactly that in a complex setup. Together with the custom php code you can define in the field settings you can do some pretty elegant magic happening. For example filling the select depending on the hierarchy or template you are editing the field.

[alkahest]

Settings You can store in the admin. (/processwire/

if you create a structure like this:

/Processwire/Settings/  <- hide from menu & enable guest access ( will show open lock )
            /Settings/color/
                     /color/red/
                     /color/blue/
                     /color/green/
            /Settings/position/
                     /position/top/
                     /position/left/
                     /position/right/

Then the editors won't see anything in the tree.

And you can query for your color or position.

Wow, I really like this approach.

[kongondo]

Wow, I really like this approach.

Ahem, ahem     

....You can even "hide" pages as children of "Admin" and that by default will limit access to them...E.g., create a settings page under Admin and throw stuff there

http://processwire.com/talk/topic/4137-exclude-pages-from-pages-field-type-using-pagelistselect

[alkahest]

I don't think this approach would work in that situation, though, because in the case I was describing over there, I still want the client role to be able to add children in the admin, just not from the home tree. If the sectioned-off tree were under the admin, the client role wouldn't be able to access it, right? Or am I missing something?

[Martijn Geerts]

Check this field under ADMIN /  SETUP /  FIELDS / tab input

[x] Allow new pages to be created from field

[Soma]

and install the autocomplete inputfield for page field for even more awe.

[Martijn Geerts]

Alway s forget about that , nice one Soma.

[kongondo]

I don't think this approach would work in that situation, though, because in the case I was describing over there, I still want the client role to be able to add children in the admin, just not from the home tree. If the sectioned-off tree were under the admin, the client role wouldn't be able to access it, right? Or am I missing something?

Sorry wasn't clear. What I meant was that you can add pages (e.g. settings) under Admin - hence, out of reach of clients