Leaderboard

The Save-to-Pages feature is now available in the current version of Form Builder (0.1.4) posted in the Form Builder support forum this morning. It hasn't had a lot of testing yet, but I believe this feature is ready for people to use so long as you test things out adequately after configuring them, and let me know of any issues or concerns you find. To use it, you click "Save to ProcessWire Pages" on the Actions tab of any form. A fieldset will appear asking you to select a template to use for new pages. Hit save, then go back to this screen. More options will now appear, like this: From there, you choose the parent where pages will be created and setup what fields in Form Builder will populate the Page fields. You also get to choose whether you want the pages to be created manually or automatically. If automatically, then you can set whether they should be published or unpublished. Automatic pages are created at the time the form is submitted. Manual pages are created by you checking a box on the entries screen. Here's what that looks like: You click the checkboxes for any of the entries you want to create pages from and then click the "Send Checked to Pages" button at the bottom. The pages are created immediately. Note the "Page" column in the screenshot above. If an entry has already been sent to a page, then this column will be populated with the ID of the page. If you click on it, it'll take you to that page. Should you re-send one of those to a page, then it will update the existing page rather than creating a new one.

Hello. I moved from WP to ProcessWire recently and am busy trying to figure out how to do things in PW, such as backing up a site. For my WP clients, I've always used an extensive, easy to use premium plugin, not depending on the host (hostgator or bluehost) to keep everything up to date. So my question is, what is the accepted best way to back up a PW site to make sure that the whole thing can be retrieved and reinstalled in case something goes horribly wrong? Thank you. Aaron

In that case, I think you'd want to hook before InputfieldPageName::render and adjust set the value attribute. I haven't tried this, but think this would work: public function init() { $this->addHookBefore('InputfieldPageName::render', $this, 'hookRender'); } public function hookRender(HookEvent $event) { // if process isn't ProcessPageAdd, exit now if($this->process != 'ProcessPageAdd') return; // if the GET var 'parent_id' isn't the one we want, exit now if($this->input->get->parent_id != $the_parent_id_you_want) return; $inputfield = $event->object; // if the input already has a populated value, exit now if(strlen($inputfield->attr('value'))) return; // if we made it here, populate the value attribute $inputfield->attr('value', 'the-page-name-you-want'); }

I think the best hook might be Pages::setupNew. That function gets a new $page (before its been saved) as the 1 argument. If the page doesn't have a name yet, then that function creates one. So it's the perfect spot for you to assign a name. public function init() { $this->pages->addHookBefore('setupNew', $this, 'hookSetupNew'); } public function hookSetupNew(HookEvent $event) { $page = $event->arguments[0]; if($page->parent->id == $the_parent_you_want) { $page->name = 'the-page-name-you-want'; } }

To continue from where Arjen left - I would probably create two new templates: files & file Files would get only one (hidden) page (/files/) and maybe not template file at all. No need for other fields than title either. Then file-template would get file-field, image-field for thumbnail and maybe textfield for extended summary (if needed). Then the "special glue" is to create page-field called: "files". Allow it to choose multiple pages and give it nice inputfield (asmSelect probably best here). Then configure it to have pages under your /files/ page. Then add this files-field to your "content" template and you are ready to go! On template level it would work like this (content.php): // Loop the pages you have chosen in your files-page reference field foreach($page->files as $p) { // And then echo the stuff those pages have in their fields echo "<a href='{$p->file->url}'>$p->title</a>"; } PS: The files template is not necessary at all, but it will allow you to set /files/ page to have children with only file-template. This will keep your content clean in the long run, and also it will hold a nice place if you want to extend and offer some "file search" or something like that.

It the files differ per page you can create a repeater field with the fields you mentioned above. If you want the files to be 'selectable', so you can use the same file on multiple pages a seperate tree with it's own template would be my way to go. You can use the Page fieldtype to connect the page/sidebar to the download. Basicly you use a page as a download. This might seem strange, but it's a bit how ProcessWire works. Pages are not always pages in the context of the web, but more as objects or nodes.

Here is one. After I saw this, I decided to also build my small icon with css ➔ http://diogoo.com/ I love it

The InputfieldSelect does support optgroups (for your self generated selects), but InputfieldPage doesn't use them. So to do what you are wanting there, you'd probably need to make something custom. To make option groups with InputfieldSelect, do them like this: $select = $modules->get('InputfieldSelect'); $select->attr('name', 'name_of_select'); $select->addOption('My option group', array('Option A', 'Option B', 'Option C')); $select->addOption('Another option group', array('Option 1', 'Option 2', 'Option 3')); $select->attr('value', 'Option B'); // example // render here, or add to an InputfieldWrapper/InputfieldForm/InputfieldFieldset echo $select->render(); Another route that you could use now would be to just title your selectable pages in a manner that reflects the group, i.e. "Course: Edition A" rather than just "Edition A".

All fields need to function in the same namespace, so if we did something like this, it would be just for visual benefit in the admin. But I still think it would be worthwhile.

So far I didn’t look into the roles security model, my security model is more basic, with myself as the superuser on one side, and Internet end-users on the other side By the way, with current version 2.2.9, even tough I’m superuser, I can assign an unpublished page to a PageField, but then it is not displayed as being assigned. Logically, I was presuming that on the backend side (ie. roles > guest), a status of published vs unpublished would have no impact in terms of who has the permission to do what -> ok it seems I was wrong. Notwithstanding backend issues, one of the main purposes of the unpublished status is that pages are… unpublished, so they can’t be accessed at their URL by the “anonymous” end-users, nor with pages->find, $pages->get, ... This is something the hidden status doesn’t provide : you mentioned it in previous posts, and I just verified, that a hidden page can still be accessed by its URL, and by $pages->get. So using hidden instead of unpublished doesn’t sound good to me, for obvious security/disclosure reasons. Same goes for using a checkbox : ok, but is there a solution for preventing end-users access to these pages, equivalent to unpublished ? Maybe performing a test (eg. if($page->viewable()) ) everywhere in the code before displaying anything? I don’t know why I’m not a big fan of this approach… which would mean reimplementing “unpublished” feature by hand. Well, in my case I can cope with a workflow where I first publish the pages (which happen to be less sensitive) which are going to be referenced inside unpublished pages (which are more sensitive), so I’ll do this way. But I think it’s a worthwhile discussion Ok, I add to my TODO list “learn more about Processwire RBAC model” Update : I’ve just read the RBAC model API introduction, and I think I have another option : The Work-In-Progress stuff could take place in a /WIP directory tree, which would have no guest access. From my lazy-cron, when publish_date field is met for pages in /WIP, then move the relevant pages from /WIP to the relevant locations in /Live-Content, which is the main tree with guest access. In order to be automated inside a lazon-cron, it's more complex and more rigid than just switching a status flag, but I suppose it should work. Still, it would be great if “unpublished” status behaviour could be made more convenient and useful, as per my arguments

He means the field management in the settings view. I totally second that

Thanks Ryan, I was hoping to transition to using Google Calendar as a way to manage all our calendars (and there are a lot). I tested it some today, and Google Calendar isn't going to provide all the functionality we need. However, it is well suited for some of our more specialized calendars that are essentially a list of dates — in which case this module will be perfect.

Out of the interest, I compared few of the most popular/promising responsive frameworks. Gotta say that those big boys (foundation and tw bootstrap) are huge. Kube 20.4kb Skeleton 8.8kb + 1.7kb + 9.6kb ~ 20kb Foundation 85kb Twitter Bootstrap 115kb (without minification and gzip) Then I took a look at few responsive sites we have build from scratch and the amount of css was between 10kb ~ 50kb. Usually less than 20kb. Of course lot of the code from the frameworks can be removed per project basis, but that adds management overhead. Reason for this "study" was that I am looking for best possible starting point. I am thinking going for simple responsive grid / column system and some very basic typography settings, but pretty much with that. I am not keen adding 100kb CSS just for starters. I am not only worried about loading time, but about performance of mobile browsers to handle that all (specially with older/cheaper devices).

That's correct that the 1% is taken out and substituted as left margins instead. This is for all columns except for the first in a row. I've actually been planning to switch to width classes rather than the inline styles that are used now. The primary reason is just to be able to support breakpoints with responsive layouts. For instance, if you've got a screen width under 600 px or something like that, you might want to cancel the floating behavior of all widths less than 100%, and instead just make them take up a full row. We can do that if we're using classes, but not if we're using inline styles. @interrobang: Check the markup settings in the Form Builder module settings. This may let you add the extra wrappers you want. Also want to mention that just because Zurb Foundation or Bootstrap (or another) provide some form features and grids doesn't mean that you have to use them with Form Builder. I personally think you are a lot better off with Form Builder's defaults than you are with those of Foundation or Bootstrap. Those frameworks are just trying to cover common form needs for the masses, but Form Builder goes well beyond this. As soon as you start letting a general purpose CSS framework take over your form styling needs, you are then limiting Form Builder's output capabilities to those of your framework. Though if you are dealing with fairly basic forms (primarily text fields) and simple needs, then there's also no harm in using a CSS framework for form styling either. But I think you will be happier if you give this control to Form Builder rather than [insert CSS framework here].

There is actually a reason for every bit of markup that appears in ProcessWire's generated forms, whether from the admin, Form Builder or elsewhere (they are all using the same Inputfields system). Once you start removing things from it, you likewise remove some feature, capability or customizability from it. In some cases, you might even remove the possibility of supporting certain types of inputs. That may be difficult to appreciate if you only look at it from the markup side, because it might be different from your own markup when making your own forms. Most notably, we have more wrapper elements and class names present than you would usually need in a standard HTML form. But these are not standard HTML forms, and you should avoid looking at it as such. ProcessWire forms have to cover more terrain than a typical web form. The Form Builder has to provide the capability of accommodating any type of layout, theme, or input (known and unknown, whether regular HTML or JS-based) with a common markup. Once you really start pushing Form Builder or ProcessWire forms, I think you can start to appreciate what the markup brings. Creating a form is the primarily purpose of what a form builder is for. When you are creating your own form markup, then you are the form builder. So my advice is that when you want to use Form Builder, let it do what it is designed to do and it will perform beautifully for you. On the other hand, when outputting a specific markup is more important than the result, then don't use any kind of form builder. A form builder is by nature a markup generating tool aimed at giving you really powerful forms quickly. And ProcessWire Form Builder is an expert at what it does. But you have to trust it and let it do its job. I've been both developing and using Form Builder for several months now, and strongly feel it is 100%. That's why I've moved it from beta to stable this last week. It is the most comprehensive and complete module ever built for ProcessWire (at least of those that I've built), including the core modules. Like mentioned above, you do have to use it in the way it is designed to be used and in the way it recommends. If you come across any issues or bugs that lead you to think some part is not 100%, then just let me know what it is -- I fix things very quickly. But I am not aware of any issues at present. At least, it is 100% stable with all the forms I am using it on at present.

Just added that optional options array to the size() function, so it should appear in the core this week. Currently you can specify: quality (1-100), upscaling (boolean), cropping (boolean). The position stuff will be added later. $image->size($width, $height, $options); You can also choose a default set of options and specify them in your /site/config.php: $config->imageSizerOptions = array( 'upscaling' => true, 'cropping' => true, 'quality' => 90, );