Select field type?

[pers0n]

Is there a reason select field types are in the default install for Process Wire?

I'm wanting to make a list of types of images a user can have, such as:

wallpaper, screenshot, abstract, ...

Because of this some might overlap, so I may need a multiple select (haven't decided definately yet).

[ryan]

I think what you are looking for is the Page fieldtype, which is the one used by ProcessWire for handling single and multiple selection. With this fieldtype, you can utilize selects, checkboxes, radio buttons, asmSelect, PageList select, etc.

[pers0n]

Thanks.

I read the post at: http://processwire.com/talk/index.php/topic,245.0.html to possibly use the module plugin for this and saw your reason for not having selects in processwire.

The only thing is I dont need the "select" pagetype or children to show up as pages, as I would just use it for my own custom filtering code. Right now there is no option to do this quickly, I have to select each page and child page and go into settings>status and check off "hidden" and "unpublished". If there was a option under "children" for each page to set the status for all children that would make things faster. I'm sure others would like this feature as well

---

Nevermind I notice if the pages are set to "hidden" or "unpublished" those fields wont show in the select.

I was able to set the parent as hidden and that keep the children from showing up in the sitemap though

//edited to prevent-double posting. Please use 'modify'/'edit' function in future, thank you, Adam.

[Pete]

It does take a littel while to wrap your head around it (or at least it did with me) but on a larger site I'm working on I have a "Tools" section that's hidden (I think that was possibly ryan's suggestion) and then just had different sets of pages under there that form the basis of various selects.

It doesn't feel "right" the first few times you do it, but when you think that all it actually stores in the database is a title and page ID, it's not like it's wasting space or anything (that was my initial concern) and also adds the flexibility for clients to potentially be able to reorder their own select lists or add to them etc.

It's really flexible, it just takes a little while to get your brain around the idea of thinking it's wrong

[ryan]

A side benefit, but I also really like being able to make all my select option pages use a template that displays all the pages that have that option selected. They are really useful, and search engines love these pages too (these cross references are priceless). For instance, your 'option' template might have this:

<?php
$results = $pages->find("field=$page"); // replace 'field' with field name
echo $results->render(); 

[WillMorris]

It does take a littel while to wrap your head around it (or at least it did with me) but on a larger site I'm working on I have a "Tools" section that's hidden (I think that was possibly ryan's suggestion) and then just had different sets of pages under there that form the basis of various selects. It doesn't feel "right" the first few times you do it, but when you think that all it actually stores in the database is a title and page ID, it's not like it's wasting space or anything (that was my initial concern) and also adds the flexibility for clients to potentially be able to reorder their own select lists or add to them etc. It's really flexible, it just takes a little while to get your brain around the idea of thinking it's wrong

Just a suggestion -- it would be good to add this to your tutorials list. It's an important part of what a lot of people are going to want to build.

Took me a long time to find the relevant posts in the forums. Your reasoning and solutions are great, just difficult to find and time consuming to sift through the threads.

[ryan]

I think we're going to be adding this to the planets tutorial and presenting it as a 'planet_type' variable, like another person suggested.

[WillMorris]

That's great.

Right now I'm building a simple events calendar and want to allow people to enter an event's time in 15 minute increments via a dropdown menu.

Something like...

Choose start time:

<1:00>

<1:15>

<1:30>

<1:45>

etc...

In this instance you would put a "times" section under your tools section and create a page for each time you want to use in the dropdown, correct?

[Oliver]

That’s the way it usually would be done. But this is a case were I would think about creating a time field type module which generates the select options without pages behind, as the values follow a certain pattern. For example with an option to define time format and the intervals to be shown in the select etc.

[ryan]

Pages would work just fine for this. But that's a pretty specific need and Oliver's recommendation is a good one.

If you wanted something quick 'n dirty, you might also use a small text field and spell out what I was wanting from the site editor in the field's description. During output, if the value doesn't match the expected format then you skip it or substitute a default.

[Soma]

There's actually a module for normal selects that can be configured in the field settings: http://processwire.c...-aka-drop-down/

[WillMorris]

There's actually a module for normal selects that can be configured in the field settings: http://processwire.c...-aka-drop-down/

Thanks, I did see that. It might be a better fit in this situation. I'm a little hesitant to use too many custom modules starting out (third-party or my own). In previous systems I've used, relying on too many external modules can quickly make it difficult to upgrade.

You end up having to wait until all modules are made compatible, either by you or someone else. I've found it's better to try and max out the stock options first.

[alan]

Thanks for the explanation re 'select'.

I've asked a question about the coding for selects here, in case it helps anyone else as newb as me (is there anyone as newb as me!).

[ceberlin]

My problem I have with the select that needs plenty of pages as sources is that there are so many cases in real live where you need typical standard selections, like a full standardized list of countries. Making pages for 100 countries or 300 airline codes does not sound elegant to me. 

So I am glad there is an alternative with that module. That's a good hint. (Although I also feel that I have almost too many modules running already)

[ryan]

Making pages for 100 countries or 300 airline codes does not sound elegant to me. 

…Until you do it from the API, Batcher or ImportPagesCSV.

[SiNNuT]

The creation process really isn't a problem with the tools Ryan mentioned. Especially for stuff like country lists i think it's really powerful to use pages. Easy to maintain; if a country name changes (yes, this does happen every once in a while) you just update that page and everything using it will always be in sync, be it your select options or other places you used the country pages. Maybe you would want to add some additional info, like a country flag or multilingual country names. This stuff all becomes easy and transparent if you use pages. What if later on you would also want to support regions and/or continents? Easy to implement when everything is pages.

[Martijn Geerts]

@ceberlin

Lots of modules only get activated if you want. Other modules have an early escape. (See textformatter example from Teppo's site).

Then lots of modules use hooks (so you don't need duplication in your templates & it is portable). And then there are modules like ImportPagesCSV that is needed only once most of the time. After use, just de-install them.

If you use modules wise, I don't see to much drawbacks from using them.