ryan

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?

Try this: $pages->find("articleImageFiles|articleImageLinks!=''");

You mentioned earlier that you could see the instructions page. Just to make sure we're talking about the same thing: in the PW admin, you click "view" for the page titled "Pages Web Service", and you see this (the instructions page): Then you click the second submit button, and you get a 404? Assuming I'm right so far, what is the URL in your address bar when you see the 404?

Nice work MadeMyDay. Regarding the navigation: I think Diogo makes a good point, but stepping outside just this site, I'm wondering if a client might understand the concept of a site like this if they still have the familiar reference point of that navigation. It's kind of the difference between them thinking of it as a 1-page site, or a creatively-presented multi-page site. Not sure what's best on this particular site, but as a general thing, having that nav seems like a good thing to me.

You can always reset your password just by pasting this temporarily into any one of your templates, and then viewing a page that uses the template: $u = $users->get('admin'); // or whatever your username is $u->of(false); $u->pass = 'your-new-password'; $u->save();

When it comes to translating text from one character set to another, look into PHP's iconv() function. You'll want to run your latin1 text through this function before assigning it to a field in ProcessWire: $newPage->title = iconv("ISO-8859-1", "UTF-8", $row['HEADLINE']); With regard to the duplicates, it sounds like you already solved this. But when you are doing an import like this and it's more than a one-time thing, then you need accurate duplicate checking. The best way to get that is to make sure that you are the one assigning the 'name' field, and that you aren't letting ProcessWire auto-generate it for you: $name = wire('sanitizer')->pageName($row['HEADLINE']); $newPage->name = $name; If there is a possibility that $row['HEADLINE'] will ever change on future imports, then you'd be better off using a separate ID field to match things up. I typically add an integer field named 'old_id' to my template, and that would contain the primary key from the old data. Then you would check that when determining whether its an existing page or a new one. Last thing I want to mention is that you might be better off caching your $parent page above the loop where you are creating the pages: $parent = wire('pages')->get('/news/'); // .. then in your loop: $newPage->parent = $parent; The reason for this is that ProcessWire clears its own cache of loaded pages every time you save(). So you'd end up re-loading that $parent (/news/) on every loop iteration. Whereas, if you've kept a copy of it in your code ($parent) then you can continue using the same one without reloading. Basically it's just a little more efficient/faster, though probably doesn't matter much.

Make sure your ProcessWire version is up to date (but I'm assuming it is). The default/instructions page has some tools for you to test the service. When you submit those, do they work? Check also your module settings, as ServicePages limits the queries to only the templates and fields you have defined as allowed. So in your example, if you haven't allowed the "picture" template, then the request is going to fail.