ryan

Agree with you. I'm planning to use the same purchase options as Gravity Forms, which does include a Developer license with use on unlimited sites.

Thanks for finding this, I have updated the code. Most likely it's been there since the beginning, as there haven't been any recent changes to the code in question. It can be challenging dragging a page to be the first child of another, and might take a couple tries. Keep at it and you'll get there. Admittedly I struggled with getting all the movements right on this action in particular, and found we might be pushing the limits of what jQuery UI draggable/droppable was wanting to do. I'm not sure how to improve that particular action, and it might take someone looking at it that is better with Javascript than me. One alternative is to edit the page you want to move and change the parent from its settings tab.

Loaded fast for me … felt the same speed as any other fast site. There is a nice plugin for Firefox called YSlow (or something like that) that can help with debugging this stuff. But I'm not convinced Google is right about the load time.

I've done something like this before and just ended repurposing the image description field to store the external link URL. But if you want to be able to have both a description and a link, then you would put both your description and URL in the field, and just be consistent with how you put in the URL so that you can easily parse it out at runtime. For example, lets say you decided that you would always put in your description first, and follow it with the text "@http://domain.com/" (using the '@' to indicate to yourself it's a URL), so a full description might look like: Then you might parse it out at runtime like this: foreach($page->photo as $image) { $description = $image->description; if(strpos($description, '@') !== false) { list($description, $link) = explode('@', $description); } else { $link = ''; } $out = "<img src='{$image->url}' alt='$description'>"; if($link) $out = "<a href='$link'>$out</a>"; echo $out; }

Yes, this will definitely be coming if the Form Builder is sustainable. Unlike other Inputfields, the File/Image Inputfields in ProcessWire require a $page to operate. I'll have to build custom file Inputfields for use with the Form Builder. However, the bigger issue is just the security. Anything that lets a user (especially an anonymous user) upload a file to a server is a huge security consideration and a lot of responsibility. I'll probably spend a month just on developing that and ensuring that it's absolutely bulletproof. I don't want to hold up the rest of the Form Builder just for file support, so decided to tackle it after the product is out there and confirmed I can afford to take the time off my regular job to really build it well. Because of the environment of this input (anonymous, public facing) the approach just has to be very different from the file inputs in PW's admin. We actually do support rich text, but indirectly. It wants you to specify what page and field to pull the success text from. So basically you would create a "thank you" page in ProcessWire and populate the body field with everything you need. Then in the Form Builder, enter "/path/to/page/:body" for your success text. However, there's a better option: Use the success redirect option instead. That way it redirects to your success page which can contain whatever you want. When using the frame-based embed options, this is preferable to having the Form Builder output any success message for you. That's because Form Builder is running from a template that may not be consistent with your site's type styles. So you can get around that just by doing a success redirect. To use the redirect option, just specify the /path/to/page/ in your success text (and nothing more). Good idea, I'll look into this and plan to implement.

Anything in TinyMCE text is pretty much raw HTML, so I've tried not to introduce any other factors into that in order to ensure the portability of the content. However, the PageLinkAbstractor module (soon to be replaced by LinkMonitor) does convert them to/from page ID references, so that links don't get broken when you move a site to another subdir or move an individual page. The disadvantage of PageLinkAbstractor/LinkMonitor is that because the link data is then abstracted, your content is no longer portable. If you ever uninstall the module, any links it has abstracted will then be broken. There's also a small amount of overhead associated with converting links to/from abstractions on the fly, but I think it's a worthwhile compromise for most. You might also want to look at the PagePathHistory module (included with the PW core). This keeps track of page moves and maintains redirects when a page is accessed at an old URL.

Thats's very similar to what I usually do. I usually just have a $selector variable and then keep appending to that one: $selector = "parent=catalogo/productos/, limit=50, id>1"; if($area_alias) $selector .= ", catalog_product_area=$area_page"; if($tipo_name) $selector .= ", catalog_product_type=$type_page"; $matches = $pages->find($selector); Not that this is preferable to what you are doing, just an alternate way of the same thing.

When possible, use IDs (integers) for referring to pages in forms. Then your sanitization is as simple as this: $area_alias = (int) $input->get->area; There's a problem with this code segment: $area_alias = $sanitizer->text($input->get->area); Someone could inject more selectors into the string by specifying it in the URL for area_alias. The text() sanitizer isn't meant to sanitize strings for use in a selector. Instead, you'd want to use the selectorValue sanitizer: $area_alias = $sanitizer->selectorValue($input->get->area); But like mentioned at the beginning, I prefer to use integers (IDs) for anything referencing pages, since it makes the sanitization simple and bulletproof.

Great site! I like that WordPress vs. ProcessWire article they have too.

Once we've got the ability to publish to pages (coming soon), this might be a good use case for the Form Builder. However, I did something very similar here (http://modules.processwire.com/add/) and opted to go the route of making my own form and creating/updating pages using the API. It's easy enough to do in ProcessWire, and maximizes the control you have over it. I see the Form Builder is something ideal for collecting data. But when your needs are as much about application/user logic and publishing, as they are about the form itself, then this is not as much of a use case for the form builder. I'd hard for me to imagine a web host that wouldn't have a workable PHP mail() function... I've never come across a case where it didn't work as it should. But also know you are right about this, and there are hosts out there that for whatever reason can't send mail (which seems like a seriously disabled hosting service). So I think it's a good idea to add an alternative way fo sending mail. Though should also mention that the Form Builder saves everything in it's database, and the email part is optional. But I will put this on my list, to support alternatives on the email side. The Form Builder doesn't use Fieldtypes, just Inputfields. All Inputfields are supported by the Form Builder, except for: File, Image, Repeater, Password, PageListSelect, PageListSelectMultiple, PageAutocomplete, TinyMCE. The Page inputfield IS supported (as of yesterday) with Select, SelectMultiple, Checkboxes, Radios, and AsmSelect. These four inputs can also be used on their own (where you specify the options, like you saw in the video). It depends. You have control over the wrapper markup around the inputs. You don't have markup control of the inputs themselves. Even though you have control over the wrapper markup, it's going to be preferable for most not to change it. That's because the auto-generated nature of it means that it can provide you with theming support, collapsible fields, fieldset groups, column width, and inline error messages. If you provide your own markup, you may lose some or all of these capabilities. This is something I'm also very interested in adding, but probably won't be in the initial release version. However, we will have the ability to carbon-copy post the data to another URL, so this will enable much integration potential. For instance, I'm using this aspect to integrate with Salesforce.

Great sites Joshua. I have to admit though I'd be a little afraid of a dentist named "Shackleton":

I think that selling point may apply to CMSs that have their API as part of the template engine (Expression Engine?). Most CMSs that use template engines don't have a particularly nice or simple PHP API, and so the template engine is not just a template engine… it's the public API too. In those systems, it's not really even a question because you have to use the template engine if you want to use the system without being an expert on its code. PHP itself makes a good template engine. In our case, trying to go beyond that doesn't present any real time-saving opportunities. I want to focus efforts on the things that will save designers/developers the most time. The template engine is an unnecessary layer that consumes overhead and doesn't deliver any real benefits for us. Whereas things like the find selectors in PW are delivering significant time savings relative to the alternative. I think you might be able to realistically compare the difference of using a single selector string to using a query array (to the same function, like $pages->find). That would be a little closer comparison of template engine vs. native PHP (and maybe what you originally meant?). I probably wouldn't have originally bothered with selector strings if it weren't for the 'operator' part of them, which can't be succinctly represented in a PHP array (unless our only operator were "="). As the needs expanded to include things like OR fields/values, AND fields/values, negative expressions, and more, PHP (or any language) would have left us with a ugly, long and complex query (whether out of arrays or objects). Then we'd be asking "why not just use an SQL query?". I'm sure you will too, most of us will at some point. The query engine is not a full-on replacement for database queries. But it is meant to cover the vast majority of common needs. But there are occasions where you may still want to go in and do a query yourself. Though for me, those occasions are pretty rare.

I went to the web site and see a "box with an image and a link" at the bottom, so am thinking you already got this figured out? On the other hand, if that box is currently static, and you are trying to figure out how to make it dynamic in PW, then let us know too.

Good idea -- hope you don't mind but I went ahead and removed it myself. I'm glad you posted this though, I didn't realize another site was cloning our content like that, so it's good to know about.

Actually, that's not a review--that's our marketing copy. Looks like they copied and pasted it from these two pages: http://processwire.com/about/what/ http://processwire.com/about/why/ We allow this usage with our press releases, but not with our site copy. The ProcessWire site copy is not open source, so whoever posted this should have asked for permission before doing so.

I've worked with a spreadsheet exactly like that before and had to do something similar. What I ended up doing was reading it in via PHP, converting the column with the data in it to the format I needed, and then wrote it back out as another CSV. Then loaded back in Excel to work with it. But I'd check out that Google Refine first. If you find that doesn't do the trick, let me know and I can explain how you can do it with PHP.

Thanks for all the great feedback. Much more enthusiasm than I expected! Yes. The FormBuilder adds a new $forms API variable to your installation from which you can grab forms, results, etc. However, they aren't initially as comprehensive as something like the $pages API var. It initially creates the page in Setup, but you can move the page to be wherever you want it in the admin. This is exactly what I did for a client this week, I dragged /processwire/setup/form-builder/ to /processwire/form-builder/, so that it shows up as a "Forms" nav item in their top admin nav. There are a few reasons, but I worry that taking donations might give a one-man project impression and discourage others from getting involved. We will probably be able to take donations once ProcessWire is incorporated as its own company/organization, and donations would then go specifically towards predefined operating costs and marketing, rather than some individuals wallet. Basically I want to make sure we've got the right structure in place.

This sounds good to me. I'm guessing we could do the JS confirm pretty easily from the ajax upload, though probably not from the oldschool one. So might be good to have a setting that goes with the file field as to whether the default behavior is to overwrite or rename. It'll also require some changes in the WireUpload class, but I don't think anything too major.

Actually $page->viewable(); does check if the template file exists. See the viewable() function in the file /wire/modules/PagePermissions.module. One of the first checks it performs is $page->template->filenameExists(). If you've run into some scenario where viewable() isn't responding properly, let me know how to reproduce? What doesn't check if a template file exists are any functions that return a Page or PageArray. So you can end up with pages that don't have template files from a non-specific $pages->find() call, or $page->children call, for instance. These functions are only bound by access control (defined in the template) and page status (hidden, unpublished, etc.). The intended way to exclude pages from results like this is to use the 'hidden' status that you see on the 'Settings' tab of every page. Once page has a 'hidden' status, it's not going to show up in any find() or children() results unless you add "include=hidden" (or include=all) to your selector string. Soma's suggestion to use specific selectors to include only the things you want (or exclude the things you don't) is also a good way to go.

Thanks guys, glad you like what you see so far. The product will be relatively simple in the first version (like what you see in the video), but I'll continue to expand it to be more and more capable. Things like multi-page forms, double-post URLs (like for Salesforce integration), multi-language forms, publish to pages and more are already planned and getting attention. But much of the direction will also come from what the audience wants most. Making themes is really easy. You just go here to do it. Then click "download" theme. Rename the CSS file included in the theme to jquery-ui.css and place it in /site/modules/FormBuilder/themes/[your-theme-name]/. Copy the /images/ directory that comes with it too. I'll include more detailed instructions with it, but just wanted to get across how simple it is to theme it. That's all assuming that you decide to even use jQuery UI for theming. You can certainly disregard jQuery UI output entirely and style it yourself with your own CSS. But I prefer the quick and easy Themeroller for most cases. Also, if you are using Datepicker or asmSelect inputs in your form, then you'll probably prefer jQuery UI css as I think it would be less fun to style those things manually. The Form Builder uses the same Inputfields as ProcessWire, so you can download more input types (like Soma's color picker, for example).

I wanted to give you a little preview of a new module I've been working on recently: the Form Builder module. This module lets you create simple-to-complex forms and place them in your site without any need for development. In this video we show how we can create, publish and test a simple contact form in less than 5 minutes. Then we take a quick look at a more complex form (already produced). I recommend viewing the full screen + HD 720p version so that you can see it more clearly than in this small forum embed. (note: there's no sound, so no need to adjust your volume) More about the Form Builder The Form Builder has many options for the developer to customize output and create their own themes, markup, etc. But the goal here was to build something that could enable you (or your client) to publish a form in less than 5 minutes, so that's the focus of this video. This tool is literally easy enough for your clients to create and manage their own forms. Or from a developers perspective, it takes something that used to consume hours and makes it happen in minutes. Form results save in the database and optionally can be CC'd to you by email. Result entries and be viewed, filtered by date, and even edited in the admin. You can export results to a spreadsheet as well. I'm working on the ability to export to pages, though that isn't quite ready yet. How the Form Builder will be licensed This module will be individually licensed on a per-site basis for a small license fee. It will also be available for free personal use to established forum members. Basically, I want to see if I can substitute some of my client work to focus on ProcessWire instead. And in order to do that, I need to have an income (I have a family to support). So I thought that building a special tool like this would be a way to make a go of it. A lot of you have asked to make donations to the ProcessWire project, and while we still won't be able to take donations, you will be able to support the ProcessWire project by purchasing and using the Form Builder in your own client projects. So a lot of motivation for this module came from wanting to provide something really special for all that had wanted to support ProcessWire. After a few months of work, I'm pretty happy with how this module has turned out -- it's already saved me tons of time in my client projects. So I'm thinking and hoping you guys will really like it too. I look forward to your feedback.

Are you logged in to PW or logged out? (not that it should matter, but just curious if it makes any difference here). You might also want to enable debug mode in /site/config.php, just in case there is some PHP error that is getting suppressed. You could also look in your /site/assets/logs/errors.txt file as well. Do you get a 404 no matter what GET variables you put in the URL? Even something like /service-pages/?aljfelkjflkfj ? I'm at a loss to know what to try next. Is this something at a publicly-accessible URL that I could try accessing it and watching the headers in my browser? If so, PM me the URL.

How about: $pages->find("articleImageLinks|articleImageFiles!=, include=hidden"); I've not tried to combine these two different fieldtypes in an OR before, so if that doesn't work, Diogo's suggestion might be a good one, or you could always do this: $pages->find("articleImageLinks!=")->add($pages->find("articleImageFiles.count>0"));

It's quite a mystery. When you access /service-pages/?template=picture, is it a ProcessWire 404 or an Apache 404? You can tell the difference by going to /some-fake-url/ on your domain, and you should get the ProcessWire one (so long as the characters in the path are a-z, dash or underscore). I am hoping you are getting an Apache 404, as that would reduce the mystery a lot. What other 3rd party modules do you have installed?

What does your ProcessWire version say? For this module, I think it has to be 2.2.5 or newer. If you just edit the URL directly in your address bar to say: domain.com/service-pages/?template=picture -- do you still get the 404? Is your site running from the domain root "/" or from a subdirectory?