adrian

Hi everyone - being new to PW I have had a few struggles working with the API. As an example, I was just trying to figure out how to get the Input field type (ie Checkboxes, Radios, AsmSelect etc) for a field. I couldn't find what I needed in the cheatsheet and was just about to give up and ask here, but it ocurred to me to look at the name of the select field within the admin where you actually choose the Input field type. It is named: "inputfield" which of course means you can simply do: $field->inputfield but I had tried $field->inputfieldtype and $field->InputFieldType which of course don't work. I think I'll be using this approach a lot for figuring things out from now on, but I though it might actually be helpful to put "inputfield" in parentheses after the title in the admin panel e.g Input field type ($field->inputfield) or something like that - kind of a contextual cheatsheet. Not sure if others think this would be useful

Thanks teppo - that helps a lot. This works: $inputfield = $question->getInputfield($page); $options_parent_id = $inputfield->parent_id; $options_parent = $pages->get($options_parent_id); $options = $options_parent->children(); foreach($options as $option){ But I have to admit to not understanding why I can't replace: $options_parent_id = $inputfield->parent_id; with: $options_parent = $inputfield->parent; and skip the next line altogether. Why do I need to get the id first and then get the page from that? Not sure if there is a more efficient way to do this.

Hi everyone, I am having trouble figuring out how to get the "Parent of selectable page(s)" so that I can do a foreach on the children. This is for a front end form template that builds the form from the fields in a 'questions' template. Right now I have something like this which works great for text fields. $questions = $page->fields foreach($questions as $question){ if($question->name != 'title'){ $field = $modules->get("InputfieldText"); $field->label = $question->label; $field->attr('id+name',$question->name); } } I am not sure if I need to change 'InputfieldText' to work with a 'Page' field type or not. But the real problem is figuring out how to get the parent of the selectable pages for $question. I know this is probably very easy. Thanks

Thanks for that tip Ryan - that might come in handy for sure. At the moment I end up having to delete the field and re-create it, which of course means deleting it from any templates that use it (otherwise I get: This field may not be deleted because it is in use by one or more templates.), re-create the field with the new type, and add it back to the template again. I completely understand the data loss issues and in reality I really shouldn't have to change between numeric and text field types very often during the design phase (if I have my act together from the start), so I guess it's no big deal.

Well in my case I am not sure. I am running APC, but it is quite possible that because I didn't see $field->tags in the documentation I assumed it wasn't possible. I thought I did try it, but possibly not - being in the learning phase of something new it is easy to get confused at times I now know that all? the elements in the data fields are available, eg $field->columnWidth. I guess these are all missing from the docs because they are still only in the dev version?

Thanks for the Flourish suggestion - I did recently see something about it, but hadn't investigated yet - looks like it could come in quite handy. I know it's been said before, but the community on this forum really is about the best I've ever experienced. I am looking forward to being able to give something back very soon.

Good tip, thank you - I think at one point I was actually wanting the user's name assigned to $u, rather than their id, but turns out I am not using that now anyways, so $user-> works a treat. Although come to think of it, there would still have been no need for the "$users->get" - not sure why I used it

Sorry Ryan - I could have sworn I tried that - there must have been something else amiss in my code at the time. $field->tag works fine and gives me a great way to use that field for metadata. Thank you

Soma - thank you - that was the problem - I guess I hadn't paid close enough attention to the "Dereference in API as" options. Switching to "Single page (Page) or empty page (NullPage) when none selected" and then removing the first() from my code seems to have things sorted. I was actually confused by the need for first() - now I know why so thanks

Good point - I guess I initially chose float because decimal and double were not supported. I have often used text fields for numeric values in the past and made use of PHP without problems. I have only rarely used float in the past, but thought they must have been more useful than I thought since since it is the only numeric (other than integer) that is offered in PW. Anyway, happy to use text, but I still think there is a bug with displaying float decimal places in the admin.

Hi Wanze, I am using this to get the name of the custom organization field in the user template: $u = $users->get($user->name); $organization = $u->organization->first()->name; Let me know if there is anything else I can provide.

Good point, but I wonder whether this behaviour could be overridden during development, perhaps by enabling any field type changes when: $config->advanced = true;

I have set up a custom field in the user template to record the user's organization. This is a page field select. If I change the selected item and then save the change appears to stick, but when I query the value with the api in my template page code, it always returns the old value. BUT, if I select the blank entry (at the top of the select list), save it, then select the entry I really want and then save again, it sticks and returns the proper value via the API. I have done this several times now and always the same. Let me know if I can provide any additional info to help debug this one.

Just wondering if I am missing something, but is there a reason I can't change a field type that is set to 'text' to anything numeric? It was originally set to float, but due to some rounding issues I couldn't resolve, I thought I'd try text. Now the option to change back is no longer available. Thanks

I am having some problems with this also, on the dev version. I can't seem to get a float to show a consistent number of decimal places. Some fields seem ok, but others get rounded to no decimal places, even though the full number is stored in the db.

I think there is a bug that exists when you change a field's type. The contents of the data field in the 'fields' db table is deleted. Most importantly (for me at least), is the tags.

Yeah, that is exactly what I need - "field metadata". I am thinking it would be a great addition to PW if it were possible to set up custom metadata fields. Really just a another field in addition to tags that accepted an array of objects would do the trick. Anyway, the tags field is working fine for now.

Well it turns out you can access the tags really easily: $field->data['tags'] and I think this will do exactly what I need. I know this is not the intended usage of the tags (I realize it's just meant to help keep the admin side of things clean), but I think it might be the best option for me in this case. I have used the Page field in a couple of cases already and it has worked a treat, but unless I am not seeing all the possibilities, I am not sure how it will work for me in this case. For the sake of clarifying my needs, here is some code to show what I am trying to do: $questions = $pages->get('/modules/local-overview/questions/')->fields; $form = $modules->get("InputfieldForm"); $form->action = "./"; $form->method = "post"; $form->attr("id+name",'subscribe-form'); foreach($questions as $question){ $qn = $question->name; $field = $modules->get("InputfieldText"); $field->label = $question->label . ' (' . $question->data['tags'] . ')'; $field->attr('id+name',$qn); $field->columnWidth = 50; $field->value = $answers->$qn; $form->append($field); } This would do the trick so long as I only have one tag listed for the field. I will refine this a little better, but it is doing the trick to tell the front end user what units to use when filling out the form. Obviously I could have the template file write out each question manually and enter the units at the end of the label, but I think this approach makes life easier. Would there be a way to use Page field in this case that I am missing? Thanks again

Thanks for the quick reply. When editing a field, under the advanced tab there is a 'Tags' field. I was hoping to be able to use this for a purpose that perhaps it is not designed for, hence the need to access this from one of my template files. Perhaps there is a better approach to my problem. I have several fields which users need to fill out in either metric or imperial units based on their country. I was hoping to use the tags field to define the possible unit options (eg km vs miles, liters vs gallons etc). Then in my template file logic I would tell them the unit to use based on determining their country and the options for that parameter. Hope that makes sense

Basically I am wanting to access all the tags (either as a string or array) for a field. Not sure if this is possible, but it would be something simple like: $field->tags Based on what I see here: http://processwire.com/api/variables/fields/ I don't think it is possible, but maybe someone knows of another way I might easily be able to access these. Thanks

Hi everyone - still very new to PW, but I am coming up against this decision too. First just let me say how awesome I think the pages model works for the structure of a typical website, but when it comes to a web app (the distinction between a site and an app is often vague in my mind), I am wondering if perhaps it wouldn't be better to go with a custom database table to store user submitted data and use SQL (which I am comfortable with). I do feel at times like the PW pages model and API it is making things more cumbersome when it comes to data querying and manipulation (but quite possibly this is just my inexperience with it still). The database is starting to fill up with so many tables - maybe this really isn't something I should be concerned about, it just feels inefficient - seems like there must be lots of joins going on to pull all this data together. I am certainly no database guru, so maybe this is fine, but are there any guidelines/use examples as to when it might be more appropriate to go with custom tables? Thanks

Thanks Ryan - sounds like you are on it Yeah, I figured they weren't a replacement for pages when dealing with lots of entries. Definitely a great option to have in the arsenal though and I think they will be much friendlier for the client with those couple of enhancements.

Hi everyone - only a couple of days in PW so far, but loving it. Just wondering if there might be a way to name the headers of the collapsible repeaters in the page edit view and also have them collapsed by default. I don't think this is what woop is asking for. What I am trying to achieve is a personnel directory and as it stands, it becomes difficult to edit - once you get a lot of entries you end up with a lot of scrolling. If it was possible to set them to be collapsed to start with and then use values from one or more of the fields (ideally I'd like to concat first_name and last_name) as the title for the header bar. I know it is possible to adjust the visibility for the field to "collapsed ...", but this collapses the entire repeater field, rather than the individual items. I am thinking that I might actually be bette off going back to parent>child approach I had originally set up as I think the repeater approach will become a little unwieldy when there are lots of entries. Anyone have any suggestions - am I missing some obvious setting? Thanks