Leaderboard

Just wanted to share what I recently used to create forms in modules and in frontend using the API and Inputfield modules PW provides and uses on its own. I think many newcomers or also advanced user aren't aware what is already possible in templates with some simple and flexible code. Learning this can greatly help in any aspect when you develop with PW. It's not as easy and powerful as FormBuilder but a great example of what can be archieved within PW. Really? Tell me more The output markup generated with something like echo $form->render(); will be a like the one you get with FormBuilder or admin forms in backend. It's what PW is made of. Now since 2.2.5~ somewhere, the "required" option is possible for all fields (previous not) and that makes it easier a lot for validation and also it renders inline errors already nicely (due to Ryan FormBuilder yah!). For example the Password inputfield already provides two field to confirm the password and will validate it. De- and encryption method also exists. Or you can also use columns width setting for a field, which was added not so long ago. Some fields like Asm MultiSelect would require to also include their css and js to work but haven't tried. Also file uploads isn't there, but maybe at some point there will be more options. It would be still possible to code your own uploader when the form is submitted. Validation? If you understand a little more how PW works with forms and inputfields you can simply add you own validation, do hooks and lots of magic with very easy code to read and maintain. You can also use the processInput($input->post) method of a form that PW uses itself to validate a form. So getting to see if there was any errors is simply checking for $form->getErrors();. Also the $form->processInput($input->post) will prevent CSRF attacks and the form will append a hidden field automaticly. It's also worth noting that processInput() will work also with an array (key=>value) of data it doesn't have to be the one from $input->post. Styling? It works well if you take your own CSS or just pick the inputfields.css from the templates-admin folder as a start. Also the CSS file from the wire/modules/InputfieldRadios module can be helpful to add. And that's it. It's not very hard to get it display nicely. Here an code example of a simple form. <?php $out = ''; // create a new form field (also field wrapper) $form = $modules->get("InputfieldForm"); $form->action = "./"; $form->method = "post"; $form->attr("id+name",'subscribe-form'); // create a text input $field = $modules->get("InputfieldText"); $field->label = "Name"; $field->attr('id+name','name'); $field->required = 1; $form->append($field); // append the field to the form // create email field $field = $modules->get("InputfieldEmail"); $field->label = "E-Mail"; $field->attr('id+name','email'); $field->required = 1; $form->append($field); // append the field // you get the idea $field = $modules->get("InputfieldPassword"); $field->label = "Passwort"; $field->attr("id+name","pass"); $field->required = 1; $form->append($field); // oh a submit button! $submit = $modules->get("InputfieldSubmit"); $submit->attr("value","Subscribe"); $submit->attr("id+name","submit"); $form->append($submit); // form was submitted so we process the form if($input->post->submit) { // user submitted the form, process it and check for errors $form->processInput($input->post); // here is a good point for extra/custom validation and manipulate fields $email = $form->get("email"); if($email && (strpos($email->value,'@hotmail') !== FALSE)){ // attach an error to the field // and it will get displayed along the field $email->error("Sorry we don't accept hotmail addresses for now."); } if($form->getErrors()) { // the form is processed and populated // but contains errors $out .= $form->render(); } else { // do with the form what you like, create and save it as page // or send emails. to get the values you can use // $email = $form->get("email")->value; // $name = $form->get("name")->value; // $pass = $form->get("pass")->value; // // to sanitize input // $name = $sanitizer->text($input->post->name); // $email = $sanitizer->email($form->get("email")->value); $out .= "<p>Thanks! Your submission was successful."; } } else { // render out form without processing $out .= $form->render(); } include("./head.inc"); echo $out; include("./foot.inc"); Here the code snippet as gist github: https://gist.github.com/4027908 Maybe there's something I'm not aware of yet, so if there something to still care about just let me know. Maybe some example of hooks could be appended here too. Thanks Edit March 2017: This code still works in PW2.8 and PW3.

Great tutorial Soma! This is the best summary of using PW's Inputfields that I've seen. I noticed you did $field->attr('id+name', 'email') so just wanted to explain what that is for those that may be unsure of the syntax. That syntax is basically saying to set the 'id' and 'name' attribute to have the 'email'. While every field needs a 'name' attribute (like in HTML) the 'id' attribute is optional… if you don't assign an id attribute, PW will make one up. If you intend to custom style a field with CSS or target it from javascript, then it's best to assign your own 'id' attribute. Otherwise, it doesn't matter. // this… $field->attr('id+name', 'email'); // …is the same as: $field->attr('id', 'email'); $field->attr('name', 'email'); // …as is this (direct reference): $field->id = 'email'; $field->name = 'email'; The advantage of using the attr() function over direct reference is that attr() can't ever collide with other Inputfield properties that might have the same name as a field attribute. It's basically your way of saying "this should definitely be an HTML attribute and not anything else." For recognized attributes like 'name' or 'value' it doesn't matter what syntax you use because an Inputfield already knows 'name' and 'value' are standard HTML attributes. But if you needed to add a custom attribute like "data-something", well then you'd definitely want to use the attr() method of setting. That attr() method should only be used for things that would actually be HTML attributes of the <input>, because they will literally end up there. So if you do an $field->attr('label', 'Hello'); you'll end up with an <input label='Hello'> in the markup, which is obviously not something that you want. That's why you assign a non-attribute property like 'label' or 'description' directly, like: $field->label = 'Something'; Last note about $attr() is that it can be used for both setting and getting attributes: $field->attr('value', 'something'); echo "The field's value is: " . $field->attr('value'); // same as: $field->value = 'something'; echo "The field's value is $field->value"; To extend your example, lets say that you wanted the 'email' and 'password' fields in a fieldset titled "About You". You would create the fieldset, and then add/append the fields to the $fieldset rather than the $form. Then you'd add the $fieldset to the $form: $fieldset = $modules->get('InputfieldFieldset'); $fieldset->label = 'About You'; $field = $modules->get("InputfieldEmail"); $field->label = "E-Mail"; $field->attr('id+name','email'); $field->required = 1; $fieldset->append($field); // append the field $field = $modules->get("InputfieldPassword"); $field->label = "Password"; $field->attr("id+name","pass"); $field->required = 1; $fieldset->append($field); $form->append($fieldset); Or lets say that you wanted those 'email' and 'password' fields to be each in their own column so that are next to each other horizontally rather than vertically. You would assign the 'columnWidth' property to both the email and password fields. In this case, we'd give them both a value of 50 to say that we want them to be a 50% width column: $field->columnWidth = 50; To jump out of tutorial mode and into idea mode: lately I've been thinking that PW should have a YAML to Inputfields conversion tool in the core (something that would be pretty easy to build), so that one could define a form like this: And create it like this (where $yaml is the string above above): $form = $modules->get('InputfieldForm'); $form->load($yaml); echo $form->render();

This is the most likely case. My memory has never been great... I'm almost as old as VI itself, heh. But I'm looking forward to giving this debug combo a try.

Hi, I have created a post-like structure like this: Page: Posts Page: Category Posts has a field called "category" which is derived from the Category page's children - these children simply have a title field e.g. ("Events", "News" etc) I would like to filter the children of Posts based on this field, something like this: $posts = $pages->get('/posts/')->children("category=events"); However category is a number, in my case Events is the number 1014. Obviously I want to filter by a string instead. How can I do this? Thanks in advance for your help! /////////////////////////////////////// Apologies, after I wrote this I saw a related page at the bottom. Here is the solution for completeness: http://processwire.c...a-selector-tag/ $category = $pages->get("/category/events/"); $posts = $pages->get('/posts/')->children("category=$category"); Nice and easy

For those interested in text editors: http://net.tutsplus.com/articles/news/perfect-workflow-in-sublime-text-free-course/ Pretty neat for those looking into Sublime Text.

I see that Ryan is about to become the first forum member to pass the "one thousand and one" thank-you's (likes) so I'd just like to take the opportunity (seeing as we are in the Pub) to raise my glass and say a big "Thank You" for the effort he keeps putting into PW, the site and the forum. Whilst I'm at it, I'll raise my glass to the others who contribute regularly too.

This is just a tiny, one-line tweak - but it really makes a huge difference in terms of ease and speed in working with the Page List. I've added this to my admin theme, but I really think this belongs in the core. in "ProcessPageList/ProcessPageList.css": /** * When an item is open, this style ensures that the PageListActions become visible * */ .PageList .PageListItemOpen > ul.PageListActions, .PageListItem:hover > ul.PageListActions, /* <-- add this line! */ .PageListSelectHeader .PageListActions { display: inline !important; } You now have direct access to "new", "edit", etc. - just by hovering over an item in the Page List. Give it a try - you will most likely never want to go back!

Thanks for your reply. I have now managed to get the datePicker working. I am still struggling with the style since even though I put the link to the stylesheet, it doesn't seem to work... Anyway, I'll look closer later... Looks like I have to link to several stylesheets... (I told you I'm no professional developper...) Just a quick note : you wrote : wire/core/Inputfield/InputfieldDatetime/InputfieldDatetime.js . I found the file in wire/modules/Inputfield... Anyway. Thanks again.

Hack no good, tool better: foreach($templates as $t){ if($t->name == "admin") continue; $t->slashUrls = 0; $t->save(); } Done.

I think it is totally appropriate to have some conventions and not configuration for everything. Trailing slashes are - in my opinion - a good convention.

This is a field that requires additional stuff thats why it doesn't work. It would work if you include jQuery UI (with js and css) and to init the datepicker to the input you either do it by yourself with a js script or you can use the wire/modules/Inputfield/InputfieldDatetime/InputfieldDatetime.js. Depending on the jQuery UI theme you include, your form elements will get also styled. But you can roll your own or overwrite some stuff. Not sure what the best way would be for you but there are several.

One thing we could do is make the field creation step be directly on the fields list page, like in Form Builder. I think this would be a nice optimization and would be pretty simple to do.

To make it even shorter, you can also do this (specify path to category): $posts = $pages->find("parent=/posts/, category=/category/events/"); Or this (specify title of category): $posts = $pages->find("parent=/posts/, category.title=Events"); To take it further, you could replace "title" above with any field present on the category template and match based on that. But I think 'title' or 'name' are probably the most common ones. If your 'category' field only exists on your posts, then technically, you could leave out the "parent=" part. Though a more specific selector tends to scale better than a less specific one (like if you re-use your category field in another template). So I do think it's worthwhile to keep it, or use $pages->get('/posts/')->children('...') like in your example. In PW 2.3 (dev branch), you can now do this as well, which would be the shortest possible alternative: $posts = $pages->find("category=events"); The above is matching the page's name field. Since there is no slash in the value "events", it assumes you are talking about the page's name rather than path or ID.

Good work Teppo ! Sometimes when we ask customers to tell what browser they're using for the admin, the respond with "windows" Thank you for making this module !

@netcarver and @diogo: thanks. Too easy actually. Works fine here. I tested links with or without classes, with or without titles, with or without images and all seem to work fine. I think it's way more readable than Markdown. It's humane. From my experience people (including developers and designers) coming from wysiwyg editors seem to be scared at first seeing Markdown or Textile. When it comes to learning, Textile is easier adopted than Markdown and by most even prefered over wysiwyg editors. So indeed it's really great to have Netcarver here!

Ryan, I'm happy to take over maintenance of those two modules once the next version of textile is released. Lets stick with the status quo until then.

Definitely, I think this would be a good thing to do. I'd like to see (and create) more profiles (whether free or commercial). This is one area where we don't have much to offer yet, but it's so easy to do, so I think I'm going to have to dedicate some time to this once 2.3 is out.

Well said Matthew, the end result of PW website is really up to you, not what the system comes up with. That being said, I have been thinking a lot about building our own "starting profile" (we kind of have one already, but that is not well build). Something more "out of the box" for our clients. That thinking also has some merits - especially if there are lots of sites and multiple people working (also on different areas, like customer support, developing, sales etc). More feature packed default site is easier to demo and sell, easier to maintain if there is lots of similar sites, easier to provide support (technical and helpdesk), easier to write instructions etc... What I am doing (hopefully this year) is to build site profile where would be the most common needs baked in already. What that would mean in our case (we build websites for Finnish associations) are: News section Events section Contact section Few different "basic-page" layouts Blog (maybe) FAQ-section (maybe) Tiny "intranet" section (maybe) Frontpage highlights Few editor roles Some useful modules already installed (redirects, adminbar, link helpers, admin helpers) Using more robust template approach Responsive by default I hope that it won't take too long that we start to see more and more community driven "starting profiles" like Ryan's Blog profile. There could be things like General CMS profile (kind of what I am doing - although not sure if it will be general enough to share it) and E-commerce site (kind of what here is coming) etc..

Greetings, Just wanted to say thanks for this discussion. I'm still new to ProcessWire, and I had a similar question. The fact that such a discussion can take place here so naturally is one of the many reasons I find ProcessWire so good. What you are all discussing here is what one could call "good general practices" for deploying any site. However, in other CMSs, when you ask such a question, you get the general information then you have to go further and say, "OK, now how do I do this in [name] CMS?" With ProcessWire, what I really like is that the answer is simply the answer, and not "Here's how you need to do it in ProcessWire." This principle seems to extend all the way through ProcessWire -- from templates to JQuery, and more. It's one of the principles that I find very appealing about the system Thanks, Matthew

The TextformatterVideoEmbed module has been updated to support responsive embed codes. To enable, grab the latest version (v1.0.4) go to the module configuration screen and check the responsive box. Now when your videos are embedded, they will be output in a width-flexible format that adjusts to the container.