Leaderboard

Click the little icon above the top right of your last image. Looks like a list icon. Once the images are displayed in a list you should see a recycle bin icon.

MultiValue Textformatter for ProcessWire Set flexible data structures in "key = value1, value2, ..." format to use as variable groups in templates. Great for general site settings, social links, menus, etc. Converts contents of textarea field "social_links" from this: @ url ::: title ::: target Facebook = https://facebook.com/mycompany ::: Follow us on Facebook ::: _blank Linkedin = https://www.linkedin.com/mycompany ::: NULL ::: _blank Email = #contact ::: Contact to an object to be used like this: echo $page->social_links->facebook->title // result: "Follow us on Facebook" echo $page->social_links->email->title // result: "Contact" Putting it together: <ul> <?php foreach($page->social_links as $item) { ?> <li> <a href="<?php echo $item->url; ?>" target="<?php echo $item->target; ?>" title="<?php echo $item->title; ?>"> <?php // name is the original key echo $item->name; ?> </a> </li> <?php } ?> </ul> Syntax: @ header1 ::: header2 ::: header3 Key = value ::: value ::: value [ ::: ...] Another key = value ::: value [...] More info: Modules directory GitHub Feedbacks and suggestions are welcome.

If you're using this you shouldn't implement ConfigurableModule. It's detecting the Config options without the interface.

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.

Hello all, I am using part of a PW install as a backend for a RESTful API. Everytime a client consumes the API, a session is started. The RESTful approach is sessionless per definition and I would like to avoid sessions, if possible, for performance reasons. When I look at the open sessions while only one client is getting or putting data through my REST API, I can see that there are quite a few (over 50) sessions open from that client. The project is at a testing stage right now and I'm afraid that once 50 or 100 clients are connected, the sessions will put a big load on the server. Is it advisable at all to try and avoid sessions? How would I go about killing sessions or, even better, connect to my API endpoints without starting a session in the first place?

Just wanted to post it here for others that might look for an example. I'm currently working on importing a Site to PW2.1. Following code I figured is needed to create pages using the Bootstraped API: <?php include(./index.php) // bootstrap PW $p = new Page(); // create new page object $p->template = 'page'; // set template $p->parent = wire('pages')->get('/about/'); // set the parent $p->name = 'mynewpage_url'; // give it a name used in the url for the page $p->title = 'My New Page'; // set page title (not neccessary but recommended) // added by Ryan: save page in preparation for adding files (#1) $p->save(); // populate fields $p->image = 'path/to/image.jpg'; // populate a single image field (#2) $p->images->add('path/to/image1.jpg'); // add multiple to images field $p->save(); // testing echo 'id: '.$p->id.'<br/>'; echo 'path: '.$p->path; Note: in PW 3 with multi-instance support adding new Objects https://processwire.com/blog/posts/processwire-2.6.21-upgrades-comments-more-on-pw-3.x/#more-updates-on-processwire-3.0 [Edit by Ryan #1] Added first $p->save(); [Edit by Ryan #2] Changed $p->image('...') to $p->image = '...';

Hi, I do know that this topic is nor really directly PW related, but yet it's about a well known CMS, releasing these days a major update, and I rarely or never saw such a step-back for a software in terms of "Backend Design and UX". Meanwhile, before even the EE v2, ExpressionEngine was great CMS, the first one I knew (back in times) Custom-Fields centric, and with a well designed AdminZone, focused on the content, and so. The EE2 Admin was designed by Veerle Peters from duoh.com and was close to perfect on some points. --- Enough introduction As a EE dev' I downloaded and installed the EE3 Beta, waiting to the wow-effect and some amazing improvements, but the reaction was more like "Is that a joke?" : *LOGIN page* *DASHBOARD* *PUBLISH* In the end, the bonus track. Responsive? Nope! Well, well, what can I say ? ... Long live ProcessWire

A lot of my clients know what they are doing and they know that a 404 page can be important to direct people to other pages of their website within the content. I think there should be a setting to enable the 404 page to be visible in the page tree for roles other than the superuser. Using the permissions scheme and allowing editing for say the template related to a 404 page has no effect.

WirePdf's $pdf->mpdf doesn't return the mpdf instance for me and a quick look through the code seems to confirm that.

https://www.own-mailbox.com/ https://www.kickstarter.com/projects/1547898916/own-mailbox-the-first-100-confidential-mailbox

Updated to version 1.1.0 on GitHub: fixed wrong return if header rows were present fixed extra items when looping over a field moved TFMultiValue and TFMultiValueRow classes to separate files

Uncheck "Use parent's values if empty?" and a whole new world appears.

I looked everywhere for that button I guess you can't pick your answer as best. Thanks!

Hi @ArtArmstrong - thanks for your efforts with this and for sharing here. Just in case you missed it, the PW core now has FieldtypeOptions (http://processwire.com/blog/posts/new-options-fieldtype-processwire-2.5.17/) which is an enhanced version of FieldtypeSelect which works with InputfieldRadios, InputfieldChecboxes, InputfieldSelect, InputfieldAsmSelect, etc. Perhaps there is still an advantage to your module - I'd be curious to hear more. Thanks again!

you can use it in several scenarios: Progressive Enhancement of forms: Return json for inline form validation (using the same url for the "good old form roundtrip action" and json_encoded responses: $response = array( error => true, status => 'unsubmitted', msg => 'no valid form data given' ); do { if ($_SERVER['REQUEST_METHOD'] != 'POST') break; $response['status'] = 'submitted'; if(!$someValidator->validate($_POST)) break; // more validation logic here... $response['error'] = false; } while (false); if( $config->ajax ) { if (!headers_sent()) { header('Content-type: text/json'); header('Content-type: application/json'); } echo json_encode($response); return; } Rendering different templates when urls are accessed via ajax: $template = $config->ajax ? "ui/projects_ajax.php" : "ui/projects.php"; $content = wireRenderFile( $template, array( "title"=>$title, "CategoryData"=>$pages->find("/categories/,include=hidden"), "PageData"=>$page )); ... we use this technique here (in combination with pushstate/history.js): http://www.accom.kg/ - If templates are accessed via ajax they are rendered without footer and header. This way we only load the necessary parts to be displayed. If the user (or google) visits the "real" page, navigation and footer are rendered. Redirecting users that accidentally visit some api endpoint that should only be used via ajax: if( !$config->ajax ) { $session->redirect('/'); } // API-LOGIC HERE. .... plus a billion other examples

Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.

How is re-saving a problem? set_time_limit(0);// in a template $books = $pages->find("template=book"); foreach ($books as $book) { $book->of(false); $book->save(array("quiet" => true)); echo "<p>Saved : $book->title</p>" } echo "<p>Done!</p>";

And further ___buildForm recieves and returns a $form (InputfieldForm) object and not a page. So you have to do like: $form = $event->return; to get the form To get the page ProcessPageEdit is currently editing, you can use the getPage() method that you find in ProcessPageEdit #1128 $page = $event->object->getPage(); $event->object in the hook represents the module you hook into, that would be the ProcessPageEdit.module. Hope that makes sense and helps. And not it's not that trivial even for long time users.

Hi Joe. A simple search via google (processwire.com hide settings tab) found my thread a while ago: http://processwire.com/talk/topic/3159-hide-settings-tab-in-page-edition/ Here's another example doing it differently: // in a autoload module like HelloWorld.module public function init(){ $this->addHookAfter("ProcessPageEdit::buildForm", $this, "buildFormHook"); } public function buildFormHook(HookEvent $event){ // get page edited by ProcessPageEdit $page = $event->object->getPage(); // conditions if(wire("user")->hasRole("superuser")) return; if($page->id == 1039) { // the form InputfieldWrapper returned by ProcessPageEdit::buildForm() $form = $event->return; // find the desired InputfieldWrapper's and remove them from the form $fieldset = $form->find("id=ProcessPageEditSettings")->first(); $form->remove($fieldset); $fieldset = $form->find("id=ProcessPageEditDelete")->first(); $form->remove($fieldset); } } This works fine in PW.

You can hook before Fieldgroups::save or Templates::save. public function init() { $fieldgroups->addHookBefore('Fieldgroups::save', $this, 'addProcessField'); } public function addProcessField(HookEvent $event) { $fieldgroup = $event->arguments[0]; if(!$fieldgroup->hasField('process')) $fieldgroup->add('process'); }