ryan

I tracked down what the issue was here. I'm betting you have a field called 'notes' ? ProcessWire's form rendering was getting confused, since that is a reserved word to Inputfields. However, it was an easy fix, so it'll show up in the source in the next day or two.

Just got your pull request -- this is great, thanks for taking the time to help out with this!

This capability will be included in the first version, as I've now got it working. Here's a screenshot of a form configured to cross-post to Salesforce. When a form is submitted, it saves locally, emails to me, and then posts to Salesforce. Like many other services, Salesforce requires some extra variables in the request like "oid" (some sort of customer ID they use). They also use some of their own variable names, which you find when exporting a web-to-lead form there. In the screenshot you'll also see how to do these variable replacements. This same method can easily be used with other services like Campaign Monitor, Mail Chimp, etc. So we'll have this capability right from the beginning.

I actually have a site exhibiting this same behavior on my dev server right now, so already can reproduce. Just haven't figured out what's causing it, but not far off. As for your Textformatter module that won't uninstall-- likely it's not related to the other issue. Double check that your Textformatter module doesn't have "permament=true" in it's getModuleInfo() function at the top. If it does, remove it. If that's not it, then check that you don't have any Text/Textarea fields with that Textformatter module assigned to them. If they do, they will install the module themselves unless you physically remove the module's files.

It's not in the live source yet. I like to test things out locally for a day or two before I commit them to GitHub, just to play it safe. So I'll usually push several updates at a time.

Changing the fieldtype is non destructive in this case. For example, changing a field from Text to TextLanguage, or from PageTitle to PageTitleLanguage, will not wipe out what's currently in the field. However, if you do the reverse (change from TextLanguage to Text) then it would of course be destructive to all but the default language. When in doubt, backup your DB before making a change like this, so that you can always revert should you want to.

I'm not sure I understand that last bit of code: $random_images->images->getRandom() ? I guess it's that first variable $random_images that I'm not sure I understand what it is or where it came from. But if I understand the parts before correctly, then it seems like this is what you want: $image = $page->images->getRandom(); if($image) { echo "<div id='home' style='background: url($image->url}); width: {$image->width}px; height: {$image->height}px;'></div>"; }

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, );

Thanks got it (sorry, didn't see it earlier). I've logged in and don't see any red flags. However, I did find something interesting. If you add the "debug=1" param to the URL, it works: /service-pages/?template=picture&debug=1 I can't find a reason for why it works with that and not without. I've gone through the code and nothing in ServicePages throws a 404. So it's really unclear where that 404 is coming from. I also tracked the live HTTP headers, and noticed that ServicePages "content-type: application/json" header never gets sent, meaning the 404 appears to be happening before the module is executed. Since this module has no initialization, I'm of the opinion right now that something else is interfering with the request. I've gone through your modules and don't see anything that appears to be a problem. The only thing you might want to try is temporarily switching back to the default admin theme, just in case there is something there. Though not sure how there could be, but give it a try. Next steps is that it may be good for me to get a look at your phpinfo(), and I can do further tests but probably need FTP or SSH if you want me to. I would modify the ServicePages module while doing the requests, which should give a much closer look at what's going on.

I've updated this with the suggested improvement, thanks for finding it.

There is some redundancy there, so you can shorten it up to this: foreach($page->photo as $image){ $description = $image->description; if(strpos($description, '@') !== false) { list($description, $link) = explode('@', $description); } else { $link = $img->url; } $thumb = "<img src='{$image->getThumb('thumbnail')}' width='50' height='50' alt='$description'>"; echo "<div class='single'><a href='$link' rel='prettyPhoto[gal1]' title='$description'>$thumb</a></div>"; }

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.