Peter Falkenberg Brown

Dear Ryan, Also, am I correct in thinking that deleted user accounts do not go into the trash? I using the same type of API call to check for duplicate user names and emails. Thanks, Peter

Dear Ryan, I've been searching for the syntax for find()->first() and couldn't find it. I noted that your code above is: $check_field_dupe = $pages->find( "id!=$current_page_id, $field_name=$field_value, include=hidden, check_access=0" ); ... even though you mentioned find()->first(). I searched through the wire directory and couldn't find that usage. Does your find() line above, with the hidden and check_access params, not include the trash? If so, that would work, I think. Or if there's a param like "not isTrash()" that would be good too. On your second example [!$check_field_dupe->isTrash()] -- I would think that if there were more than one page returned, in the array, that we'd have to use a loop to check if each was in the trash. Is that correct? I guess you're also confirming that the textunique field does indeed require additional API code, unlike the email field, for example. Thanks for your help, Peter

Hi Antti, Yes, I guess that's the issue. I have to do some deep study of OOP. The Great and Mysterious OOP. Peter

Dear Ryan, Thanks, that makes sense; to keep the code clean. When I tried to integrate your suggestion into my form processing code (listed at the very top of this post), it didn't work. Specifically: # if ( $field_value instanceof PageArray ) # this didn't work if ( is_array( $field_value ) ) { foreach( $input->post->$field_name as $pid ) { $new_page->$field->add( (int) $pid ); } } whereas the "is_array" method did work. Once again, I'm grabbing field values like this: $field_value = $input->post->$field_name; In the case of Page type fields, I didn't use sanitize, since they were the result of dropdowns, etc. Do you think that the "is_array" method is solid enough, and is there something I'm missing with the "instanceof PageArray" method? Thanks, Peter

Dear Ryan, Another update. My code worked above, against normal pages. That is, the code check for dupes worked against "non-deleted" pages. However, after saving a value that was not a dupe in non-deleted pages, the value was still erased by the text-unique field, after saving with the API call. I discovered that the conflicting value still existed in a page in the Trash. So, 'textunique' is included pages in the Trash, which should not happen, in my opinion. Yours, Peter

Dear Ryan, I added this code to my php file that saves the values, and it worked. Is there a different and better way to interact with textunique fields, via the API, or is the following code a good option? if ( $field->type == 'FieldtypeTextUnique' ) { $field_value = $sanitizer->text($input->post->$field_name); $check_field_dupe = ''; $check_field_dupe = $pages->get( "id!=$current_page_id,$field_name=$field_value" ); if ( $check_field_dupe->id ) { $field_value_error = 'yes'; $field_error_text .= "<span class='error_text'> '$field_value' is not available.<br> Please try something different. </span><br> "; } } Thanks, Peter

Dear Ryan, As a follow up, the textunique field does catch the duplicate value when one uses the admin interface. Peter

Dear Ryan, I'm using TextUnique on a field called 'account_name', and process that field through the API. I don't check for duplicate values in the code, because I figured that the field type would throw an error. However, instead of an error, the field value is set to blank whenever a duplicate value is typed in, and the user hits save. Does the uniqueness check require special API code as well? Thanks, Peter

Dear Soma, This is really helpful. Thanks! So, based on what you wrote, it seems that this code worked with the form: if ( is_array( $field_value ) ) { foreach( $input->post->$field_name as $pid ) { $new_page->$field->add( (int) $pid ); } } because the add method was appropriate because the field was a multi. In other words, that code didn't click in when the field was a single (i.e. no array). Your comment about the Page and PageArrays was especially helpful: "Single: it will only be a value of type page and page have no method add, multiple: will be a PageArray. PageArrays have the method add() to add pages, but also the field recognizes just ID's set to it, and it will save the entry and the others already saved or doublicates remain untouched." I'm wondering -- since this line: // and also this (which seems to append db entry) guess makes sense? $new_page->account_status = 1023; seems to work for BOTH cases, would you consider it a proper PW way to use that type of code for both single and multi fields? I believe that you imply above that one could even do this on a multi field, with the values (pages) getting appended one after the other: $new_page->account_status = 1023; $new_page->account_status = 1024: $new_page->account_status = 1025: This way, one doesn't have to test whether it's a single or multi field. Thanks so much for your help! Peter

Dear Teppo, In the first example, with the $field_value input coming from a form post, I iterate over an array of field names, getting $field_name from that array. In the second example, the user has filled out a form, and the code in the first example parses most of the ordinary fields. Then, after that has been done, prior to saving the new page, I need to set the values on a small group of 'admin' type fields, like account_status. Account status is of FieldtypePage, (a single select dropdown). I'm trying to set the field to one of the values ('Trial'), which of course has a page ID. So, since I already know the field name, and the value, I just have to figure out the code to set the value. I want to be able to do the same thing for multi-selects or multi-checkboxes as well. I thought I had to add those values, using the $field->add function, as I did with the 1st example which process user form post input, but then I ran into that error. I'm sure I'm missing something obvious to an OOP expert, but I haven't figured it out yet. This whole thing is a front-end app for members, where they will add, edit and delete pages, all through the API in custom php files. I've got most things working... I'm just stuck on this little point, at the moment. I'm deliberately not using the form API, because I'm using HTML templates with field tags, and then replacing them with values or input fields. Yours, Peter

Dear Teppo, I haven't tried that, but I already know the name of the field, so with your example, I could write: $new_page->account_status->add( (int) $field_value_id ); I'm wondering why the code works when the values are coming from a form post.... Also, the error message was: "Call to a member function add() on a non-object...". Yours, Peter

Hi Folks, I've brought my front-end app to the point where I'm successfully adding single and multi-type FieldtypePage items to a new page, from input via a form, using this type of code (thanks, Soma, for your tips on this): $field_value = $input->post->$field_name; ... # set field values if ( is_array( $field_value ) ) { foreach( $input->post->$field_name as $pid ) { $new_page->$field->add( (int) $pid ); } } else { $new_page->set("$field_name", "$field_value"); } It works like a charm with single selects, radio buttons, multi-selects, multi-checkboxes, etc. However, in my app, I need to specifically set some field values (like drop down status fields, etc) that the user doesn't interact with. I tried this code, but got an error: "Call to a member function add() on a non-object...". $field = $fields->get("account_status"); # Trial = 1102 $selectors = "parent=/elements/custom_selects/account_status/," . "select_value=Trial," . "include=all"; $field_value_id = $pages->get("$selectors")->id; $new_page->account_status = $field_value_id; ## (THIS CODE WORKED) # $new_page->$field->add( (int) $field_value_id ); ## (THIS CODE DID NOT WORK) The odd thing is that the first block of code works, from a form, for that same field (a single select). I'd like to be able to programmatically set both single and multi-select fields, not via a form, for fields on a new page, or even on an existing page. Things like adding 4 or 5 checkbox values to a multi-checkbox field, etc. I'm sure that my lack of knowledge about PHP OOP is getting in the way, which I plan to rectify. But until then, any tips would be most appreciated. Thanks! Peter

Dear Ryan and Soma, Thank you both for your help. Soma, I *thought* I had looked at your "derefAsPage" suggestion, but I must have done it wrong, because now it works, with both single and multiple and empty values. if( $field->derefAsPage == 0) { # is array $field_value = ''; $total_pages = count( $page->$field_name ); $count = 0; foreach( $page->$field_name as $field_value_element ) { $count++; if ( $count < $total_pages ) { $field_value .= $field_value_element->select_value . '<br>'; } else { $field_value .= $field_value_element->select_value; } } } else { $field_value = $page->$field_name->select_value; } I must have missed something, but now it all seems good. Thank you both!!! Peter

Dear Ryan, The two fields that are having problems are set to type "Page" and "Multiple pages (PageArray)", and then "Checkboxes" and "SelectMultiple", respectively. When they have more than one value, they display them correctly. When there's only one value, the code didn't work, so I had to modify it, thus: # $field_value = $page->$field_name->select_value; $field_id = $page->$field_name; $field_value = $pages->get("$field_id")->select_value; I just checked the settings, as you mentioned, and they seem fine. Best regards, Peter

Hello All, I've been developing some generic routines in include files, to display and edit various types of fields. This question relates to my code to display the fields on a page (i.e. "view mode", not "edit mode"). I loop through an array of field names, grab the values, and then replace tags in templates. I'm doing it this way because I'm building a front-end user app with many tables (field sets), and want to be able to reuse the code. I've decided to use four types of Page fields for front-end display: Single Selects, Radio fields, Mutliple Checkboxes and Multiple Selects. The issue I ran into was with Multiple Checkboxes and Multiple Selects when the field stored only ONE value. The code didn't work as I expected. I created a work around, but I'm not sure why the first method didn't work, and I'm not sure if I'm doing it the right way. Here's the code that runs against each of the field names, for a page. I've marked the question lines in red. if ( $field->type == 'FieldtypePage' ) { # process four of the input types: # single select, radio, checkboxes, multiple select # InputfieldCheckboxes # InputfieldSelectMultiple # IS THIS THE BEST WAY TO TEST FOR MULTIPLE VALUES? if ( count($page->$field_name) > 1 ) { $field_value = ''; foreach( $page->$field_name as $field_value_element ) { $field_value .= $field_value_element->select_value . '<br>'; } } else { # THE LINE BELOW DIDN'T WORK WHEN THE CHECKBOXES AND MULTI-SELECTS ONLY HAD ONE VALUE # (It worked fine for the single select and radio fields) # $field_value = $page->$field_name->select_value; # ... so I get the ID of the page, and then do a get on the "select_value" field. $field_id = $page->$field_name; $field_value = $pages->get("$field_id")->select_value; } } elseif ( $field->type == 'FieldtypeCheckbox' ) { $field_value = ( $page->$field_name == 1 ) ? "Yes" : "No"; } elseif ( $field->type == 'FieldtypeFloat' ) { $field_value = money_format('%i', $page->$field_name); } elseif ( $field->type == 'FieldtypeTextarea' ) { $field_value = str_replace("\n", "<br>", $page->$field_name); } else { $field_value = $page->$field_name; } Is my work around above, with the ID and the get, the only way? I would have expected the first method to work. Also, what do you think about the other elseif statements below the Page Field section? Does this block of code seem reasonable as a method, to parse through various types of fields, and then get and format the values correctly? Thanks! Peter

Dear Soma, Thank you very much for your tips. I'll examine the multiple field test. Based on your suggestions above, I tested some code, and was able to replace the entire code block above (the second block dealing with the modified input fields), with these lines: $field_edit = $inputfields->get("$field_name"); $field_edit->processInput( $input->post ); $field_edit_value = $field_error_text . $field_edit->render(); $field_template = str_replace($field_tag, $field_edit_value, $field_template); These lines seem to work for all types of fields, as far as I can tell, so I don't need the if statements I was using for the multiple value fields. Kudos once again to the power of ProcessWire! (Thanks, Ryan!) Just curious, Soma. You said that because you were picky, you wouldn't use the method I'm using above. Could you elaborate? I'm eager to learn how various programmers would do things. (Like they say in Perl, "there's more than one way to do it.") Thanks again! Peter

Dear Soma, Thank you for your response. After I figured out that "checkboxes" was not a PW function word, and that it was pseudo code, to be replaced by the actual field object name, , I got it to work with a loop through all the fields in my custom field array. This modified code seems to work fine. The page saves, with the edits captured. The routines below are done during *updates*, not adding new records. Feedback would be lovely. #.......................................................... $field = $fields->get("$field_name"); ... I do some things, here, before setting the field values below... #.......................................................... # set field values if ( $field->inputfield == 'InputfieldCheckboxes' or $field->inputfield == 'InputfieldSelectMultiple' ) { $page->$field->removeAll(); foreach( $input->post->$field_name as $pid ) { $page->$field->add( (int) $pid ); } } else { $page->set("$field_name", "$field_value"); } #.......................................................... One question is: is there a system var that one can use to test for any type of multiple input fields, rather than having to create a set of tests for all the different types of multiples? Like, "$field->inputfield is of a 'multiple' type"? * Do you think the code above is correct and done in the "PW" way? * My next question is that I'm stuck on the routines to create the editable input fields based on the user selecting, or deselecting one or more of the multiple options. I've gotten the "single value" fields to correctly capture the user input, and then display the modified fields again, in an "error" version of the edit page (based on a method that Ryan suggested) - http://processwire.com/talk/topic/407-processing-contact-forms/?p=3208. My primary difference, and one of the reasons that I'm working on this method of creating forms, rather than using the $form method that others have mentioned, is that I'm replacing template tags in an html file, with the field values at run time, for a custom look and feel. I'm also doing a lot of pre and post processing, all done within the page's template.php file, and a variety of included code files. I found that using this method removes any necessity to use hooks. Here's my code for the multiple value fields, to create new input fields to "re-edit". I'm missing something. Not sure what. The screens come back with the original values still selected. #.......................................................... # assemble input fields again, based on user's new values # to bring user back to revised edit screen $field_edit = $inputfields->get("$field_name"); if ( $field->inputfield == 'InputfieldCheckboxes' ) { # multiple checkboxes; modify user input checks foreach( $page->$field_name as $field_value_element ) { foreach( $input->post->$field_name as $pid ) { if ( $pid == $field_value_element ) { $field_edit->attr('checked', 'checked' ); } else { $field_edit->attr('checked', '' ); } } } } elseif ( $field->inputfield == 'InputfieldSelectMultiple' ) { # multiple selects; modify user input selections foreach( $page->$field_name as $field_value_element ) { foreach( $input->post->$field_name as $pid ) { if ( $pid == $field_value_element ) { $field_edit->attr('selected', 'selected' ); } else { $field_edit->attr('selected', '' ); } } } } else { # The single value field types work fine $field_edit->attr("value", $field_value); if ( $field->type == 'FieldtypeCheckbox' ) { $field_edit->attr('checked', $field_value == '1' ? 'checked' : ''); } } $field_edit_value = $field_error_text . $field_edit->render(); $field_template = str_replace($field_tag, $field_edit_value, $field_template); #.......................................................... Thanks very much for your help, and anyone else's help, too! Peter

Dear Ryan and All, I've been making great progress on my form system (which I will run by you all in this post when I think it's done, to get your feedback). For now, I'm stumped on how to save multi-checkbox fields via the api (or multi-select fields, for that matter). I've figured out how to display them and edit them, but when I check off one and hit Update, I haven't figured out the syntax. I know it passes an array, and in Perl, I would parse through the array by hand. But with PW, after looking at the data tables for the fields, I see that a checkbox field with multiple options will have zero or more rows attached to the page. Thus, when I click them off or on, it seems like I'm adding or deleting rows from that checkbox field table. Is there a PW way to do this, that I'm missing? Of course, $page->set("$field_name", "$field_value"); didn't work. The checkbox field in question is all set up as type page, and works perfectly in the admin. Also, I'm assuming that: $field_value = $sanitizer->text($input->post->$field_name); won't work. Thanks for anyone's help. Peter

Dear Soma, I really appreciate your help. Thank you! I do believe that your advice has made a few of my little grey cells go ding! My form seems to be working now. I'm using an array of field names (stored in $field_array) that has fewer fields than the page, so I only create the vars necessary for the form. This is my code, as of now (condensed): $field_template = file_get_contents('./member_account_fields.html'); $page->setOutputFormatting(false); $inputfields = $page->getInputfields(); foreach ( $field_array as $field_name ) { $field_tag = ':!:' . $field_name . ':!:'; $field = $inputfields->get("$field_name"); $field_value = $field->render(); $field_template = str_replace($field_tag, $field_value, $field_template); } $out .= " <form action='$full_page_url' method='POST'><br> <input type='hidden' name='a_' value='u'><br> $field_template <input type='submit' name='submit' value='Update Account Data'> </form> $cancel_form "; I think the fact that I can loop through an array of field names, and get all the fields, in their editable format, with the correct values, including Page type fields, with just these two lines: $field = $inputfields->get("$field_name"); $field_value = $field->render(); is really, really cool. (Ryan, I join with many others in saying, you've done a great job with ProcessWire! You can be proud. ) Soma, and Adrian and Matthew, thanks very much for your help! (Of course, if I've missed something above, or done it incorrectly, please feel free to send me hunting for more little grey cells.) Peter

Hi Soma, Your answer lead me to this line of code, which worked: $fields = $page->getInputfields(); $f = $fields->get("account_type")->getInputField($page, null); $f->attr("value",$page->account_type); $account_type_field = $f->render(); After doing that, $account_type_field contained this code: <select id="Inputfield_account_type" name="account_type"><option value=''></option> <option value='1106'>trial</option> <option value='1107'>paid</option> <option selected='selected' value='1108'>complimentary</option> </select> which was exactly what I wanted. It contains not only the select options but also the value of the drop down that had been stored. Thanks for all the tips, everyone! ProcessWire rocks. Peter

Dear Soma, Thanks for your answer. I certainly don't want to waste your time, which you've already given so generously on this forum. I understand where you're coming from, because I'm a long time coder myself -- I just don't know OOP yet. I'm fine with digging through the core code, as you said that you did. I was simply curious where you found your answers, and you answered that (by digging through the core code). I'm sure one day, PW will have a huge reference section and examples of how to do everything. Who knows, maybe I'll be a contributor to that as well. Thanks for your efforts, and I'll keep digging. Best regards, Peter

Dear Soma, Thanks very, very much for your code sample. Looks like we're getting closer. I added this to my page template php file: $f = $fields->get("account_type")->getInputField($page, null); $f->attr("value",$page->account_type); $account_type_field = $f->render(); I got this error: Error: Call to a member function get() on a non-object (line 93... Line 93 is this line: $f = $fields->get("account_type")->getInputField($page, null); I'm running this inside a typical php file, where I'm able to successfully pull values from $page, e.g. $e_account_name = $page->account_name; Does the variable "$page" inside the getInputField function need to be something else, or initialized in some other way? About the method of building forms: the main reason I've been exploring this is so that I can use an html template with tags, to customize the look and feel of the form. Also, I think it's a useful thing to be able to do: to render a field in all it's admin / edit version glory. By the way, Soma, where did you learn the above code? Did you pull it out of the admin scripts? I want to do as much investigation on my own as I can, but the documentation about this is sparse, especially for a non-OOP person like me. Thanks! Peter

Dear Adrian, Thanks... I'm hoping to be able to assemble all of that into the $inputfield variable. It seems from your code higher up, that there's a PW function that grabs off the "assembled" components of the field and preps them, and then appends them to the form. If it could be placed into a variable instead, that would be great. For example: $var = " <select name=xyz> <option value=123>123 <option value=456 selected>456 </select> "; without having to do all the coding. It seems that PW is doing that in some cases, so I'm hoping to borrow those functions. Anyone have an idea? Ryan? Thanks, Peter

Dear Adrian, Thanks... I didn't mean the ProForm. I meant that I wanted to just grab the fields and their formats without initializing a form through the PW API. The append function lays out the form in an inflexible way. For example, I might like to have 4 columns, etc. In my example above, I use a get to obtain the value of a text field. I'm hoping that there's a similar function to obtain the final values and formats of the more complex fields, like a select list, without any dependence on the core form function. Thanks, Peter

Dear Adrian, Thanks. I had actually read that page a couple of times, but noted that the method to get the field seemed to be dependent upon the form module: $form = $modules->get('InputfieldForm'); and used the line: $form->append($f); to append the fields to the form. I'd like to grab each field, in it's complete format, and place it in a variable that I can then replace a tag with, so that I can create a custom look and feel with the form. Do you know how I could get each field value, with all of the attendant attributes / html code etc? This would also need to apply to the page type select lists. Thanks! Peter