kongondo

Jeff, Thanks for testing and reporting back. I'll file a bug report at Github later...thanks.

Did you read my post just above yours? I don't understand what you are really trying to do with your function but there's is a world of difference between the fields 'summary' and 'myselect'. The former contains text = a string. 'myselect' is a page field, so returns a page object (like I stated above). If you just echo it out, it will just show the id of the selected page. The question is, what do you want from 'myselect', i.e. which of its fields are you after. In my hint above, I gave you examples of how you can get any property or custom field of your 'myselect'. That is what you need to give your array... array('$page->myselect->title');//this is outside a function. Inside a function, that is the homework I suggested you read about

You better re-read this answer to your previous question: https://processwire.com/talk/topic/6013-difference-select-aka-dropdown-vs-page-field-type/?p=58768 Hint.... $page->myselect->title; $page->myselect->template; $page->myselect->id; $page->myselect->child->name; $page->myselect->headline;//custom field $page->myselect->othercustomfield;//custom field $page->myselect->this; $page->myselect->that; $page->myselect->that->and->and->and;//you get the picture... Here's your other homework...will the above work in a function?

As long as it's not an infinite loop.....

Actually, it seems Joe was the last poster (13 November 2013) in that thread Wanze points to

In their blog profile install, using PW2.4, could someone please confirm that they can view the option "PageAutocomplete" as one of the Inputfield field type selections in the drop down in /setup/fields/input (admin)? Although the page field called "tags" works fine when editing a "post", PageAutocomplete does not appear in the field edit screen. It also means I cannot add a field of that type. Currently, the "tags" field "appears" as a "Select". If I save the field settings, it now also disappears in the edit a "post" page. And yes, automplete is listed as installed. Thanks! Does the above even make sense? I'm having one of those days!!!

Hallo, is that you Raymond? Is it really you?

I meant the forum search facility. Like Adrian said, it's not the best....so, we normally do something like this in Google.... 3 letter word site:processwire.com or if you want just the forums 3 letter word site:processwire.com/talk And you can use all sorts of Google search methods (wild cards, "", etc..) and tools as well....

You use the forum search?

@Martijn...your holiday to the UK is long overdue then!!!

Sort of.....http://mods.pw/5n

...You are not able to change it....only moderators can....

@Adrian, Sorry, my bad. I had some white space in my code... It works fine, thanks.

@Adrian....I am getting unknown selector operator errors with your code (even when I match the ' and ". ) Btw, I have always had problems using these constant statuses within selectors; I can never seem to recall (or find) the right syntax. You are right, they are much easier to read than status numbers!

Try this...quick and dirty...works for me...could be better/smarter/other ways... $articles = $pages->find('template=articles, parent.status!=2049'); 2049 = unpublished status...

There's something called variable scope within a function....Basically, a function is a closed container and is not aware of its surroundings...It only knows the things within it. Hence, you need to show it the outside world. To do that, you need to use some sort of global variable...something that is powerful enough to see the 'outside' from 'within'....that thing in PW is wire So, you can either use: wire('pages')->get();//as a function/method //or $wire->pages->get();//as a variable The same issue of scope arises when dealing with modules/class or bootstrapping PW... By the way, you don't want to be echoing within a function....use return instead (at the end)...before that...you can save stuff that you will want to output in a variable...e.g. $out = ''; //do more stuff...then we add to $out.. $out.= 'this is my cool stuff'; //do more stuff, then append to $out. $out.= 'this is even better man!'; return $out;//you can also do return $out . $another variable . $foo . $bar, etc.. //Call your function and it will output what you return-ed in the function...

Google (the web, not just this forums) "capturing form input html php" Read this http://processwire.com/api/variables/input/ This http://processwire.com/api/variables/sanitizer/ As well as Wanze's post above about passwords...

Isn't that the normal practice globally? Also, define details? Some choose to send passwords and user names. Others just send user names and ask user to confirm their email address, blah blah... Spammers can be people or bots. If the former, you decide whether you check uniqueness by email or other method...As for the latter, search forums (or the internet) for "honeypot" in relation to forms ....there's other stuff out there too to help with spammers, some less effective (and/or more annoying!) than others.. Take your pick from these...http://processwire.com/api/variables/sanitizer/ . If nothing suits you there, you can roll your own Regex. You could should also start with client-side validation with some jQuery magic; no need allowing a user to submit a form with an invalid user name (or any other invalid input). BUT THIS IS no replacement for server-side validation! You must do that, e.g using your PHP and/or PW API stuff - e.g. $sanitizer....

Adding to Wanze's code... $username = $sanitizer->pageName($input->post->username); $u = $users->get($username); if ($u->id) { $message = "Sorry, that username is already taken..."; } else { $u->addRole('frontend-editor'); $u->save(); } Assumes you already have that role available

find will find many (or even all!) things if they exist unless you limit it. This will put a strain on your servers and PHP may even timeout. get, will only get one thing...so, less resource hungry. The general rule is that when using find, you need to use limit=xx. You can always paginate your results if you need more to be fetched. But, if you are sure that the number of children will not grow, and that you have a set reasonable number of children, then you can avoid the limit

Using pages for selects: that's your most powerful relational database right there! It gives you access to the whole Page Object or Page Objects that are selected (hence everything about them)...you can even go farther down the rabbit hole...and find out more information about other relations that those selected pages have (other than their relation to the page that has the page field) - their parents, children, etc...This is a very powerful PW feature yet Ryan has implemented it as a very simple, user-friendly and elegant solution... I have never used Select AKA Dropdown - so, no comment...but, horses for courses...

Help setting up a way to ask for a credit card first, then process the card for the payment, then post the page. This is probably the trickier one. I have no idea about credit card processing but there have been posts in the forums about processing payments, e.g. using paypal...Others can chip (no pun intended!) in here... I have re-read your post and see payment will be made via paypal. From what I have read in the forums (and I agree with that approach), if you can avoid it, do not handle, take or store credit card details on your site. There are "cheaper" payment gateways that can handle that for you....or redirect users to paypal. Let them deal with the security issues. Anyway, I don't know much about this area so search and/or wait for other responses Help redirecting the user to the newly created page after they have submitted the data through the form builder form. The potential issue with this is when two or more pages have been created at the same time. Creating a page via API is easy though. Redirecting is also easy: $session->redirect($url). I don't know how you are creating your pages but one way to grab the page created by "this particular visitor" is: You could get the sanitized name of the page and save that to a variable as you save the page. If the name has not been rejected, then use that name and the template of that page to grab the newly created page and use that as the $url variable in the $session method..e.g. something like....$pages->get("name=$name, template=my-template"); where $name is the sanitized value you saved in this variable before you saved the page [but only proceed with redirecting the user to the new page if one was actually created! So, you will have to check for a page id. If no id exist, the page was not created and you need to tell the user that]. You don't want to use title to get the new page since titles don't have to be unique. There could be other ways of doing it (using cookies and all that...) but the above is probably simpler...Others here will have better ideas ;-) Automatically create a user and password and assign it to the newly created page. I am not sure about creating a password. Why not ask the user to create their own password when registering? Then, save the page but as unpublished which you will then publish after you receive payment. In this case, there is no need to redirect the user to their newly created page. It is of no use to them anyway until they have made a payment they won't be able to log in. So, I would take them to a "thank you" page, awaiting confirmation and payment, blah blah message.... Creating a user is easy. Have a look at the API docs: http://processwire.com/api/variables/user/ Just my 2p

Thanks Ryan! The grouping feature is really cool!

Oh oh...This boy is on fire!!!! Good job @Horst!

Oops, in my example, I had commented out //require_once('Googl.class.php'); This is because I had the Class already in my template file...Don't forget to uncomment yours! ...if you do, PHP will tell you anyway...