Mike Rockett

Am nearly done with the jQuery plugin side of things. Wil try and push this to GitHub tomorrow for those interested to test. Haven't started yet with form-rendering - let's just do this thing one step at a time.

Also true (much truer than anything else) - my brain is evidently exhausted for the day.

You shouldn't be able to access php files directly in the templates folder - that could bring about a security problem. Better to use a module, or perhaps move engine.php to a different location that has nothing to do with ProcessWire.

Thanks, tpr. My current plan is to, at the very least, get a base-functional module up soon. I have quite a bit of work coming up really soon (not dev-related), and so won't be able to put much time into it for a little while after the initial release. However, this will be a good time for user-feedback that I can look at when I continue development. Whilst there are proven solutions out there, I haven't seen one as flexible as this (other than FormBuilder, of course). I have actually given some thought to Pete's suggestions, and will be going ahead with some kind of HTML builder for each form. @everyone: There are so many ways one could go about building each form as automagically as possible. So I'm going to put together some ideas and share them with you. As stated before, I'm going to make this available as an opt-in feature - you'd be able to choose between something like $forms->render('contact') and rendering the form manually. I think that one of the best approaches would be to allow the developer to specify what kind of form-output is needed for each form. Choices would include 'bootstrap', 'foundation', and 'processwire' (using Inputfields). Based on that specification, the render() method would pick out the applicable HTML blueprints/builder-methods and render the form from there. Of course, and based on the rendering spec, each field would need to have certain properties defined - only properties that make a difference to each spec would be required. Anyways, let me give this some more thought. In the meantime, I'm going to change the directory structure, and release a prototype for feedback purposes as soon as its ready.

Another idea that I'm considering, thanks to Pete's name suggestion of QuickForms, is the ability to quickly create forms based on blueprints. One would go to the module's config page, select a blueprint, and then the config and templates would be created for it.

Hehe, nice one. Though, I'm not a fan of naming things after myself... Will stick with SimpleForms for now. Pete's suggestion is also quite nice - it does indeed portray the essence of the module's purpose. The original intention of this module was to simply the process of building simple forms - such as contact and feedback forms. To me, adding on extra functionality like an HTML form builder seems a tad too much in terms of the intention. I feel it would be better to leave the front-end markup to the developer/designer. However, and with that said, I'm willing to reconsider should there be a decent amount of demand for it. For one, I don't look at these things often enough, because I don't really have an interest in using UI kits. I prefer to use a good responsive grid framework, and design from scratch. I'm sure, though, that many developers/designers prefer UI kits, and so I would consider making this an optional extra. Thoughts?

Sorry, forgot to respond to this part. I'm using a simple StringTemplate engine for the email templates. The objective is to easily allow the developer to specify variables, such as {info.company} and {input.name}. It's not a fully-featured template engine - I don't believe this is really required here. The goal with this module is to make simple forms quickly. Here's an example of an email template: {stylesheet} <div class="body"> <p><strong>Dear {input.name}</strong></p> <h3>Your message has been processed.</h3> <p>This communication serves to confirm that our website has processed your message. We should receive it shortly, and will get back to you as soon as we can (usually within two working days).</p> <p>If you need to get hold of us urgently, please call us on {info.tel} or {info.altTel}.</p> <p>For your reference, your details and message appear at the bottom of this email.</p> <p class="nM">Kind Regards,</p> <p>{info.fromName}</p> <div class="line"></div> <p class="notice">Please note that this email was sent to you from an unattended mailbox. Replies to this email will not be received.</p> <div class="box"> <p><strong>Your Details and Message:</strong></p> <p class="nM">Email Address: {input.email}</p> <p class="nM">Contact Number: {input.contact}</p> <p>Company Name: {input.company}</p> <p>{input.message.html}</p> </div> </div> In terms of the front-end, I haven't gotten there as yet. I will be building a simple "middleman" jQuery plugin to handle the AJAX processing of the form. Essentially, the developer would need to design the form, and place the HTML for that form directly into their templates. I don't want the module to make any assumptions on how the form should be laid out. The only requirement would be for the developer/designer to insert the necessary tags in which errors will be displayed. Off the top of my head, here's an example of how the front-end would work: <form id="contactForm" data-simpleforms-form="contact"> <!-- auto-resolve to modules/simple-forms/contact --> <div class="inputGroup"> <label for="name">Your name:</label> <input type="text" id="name" data-name="name"> <div data-simpleforms-error="name"></div> </div> <div class="inputGroup"> <label for="company">Company name:</label> <input type="text" id="company" data-name="company"> <div data-simpleforms-error="company"></div> </div> <!-- etc. --> </form> <script> $('[data-simple-forms-form]').simpleForms(); </script>

I'm glad you do, and thanks for the input! I can already see the second directory structure being the preferred one - it makes much more sense. Will await other feedback on the front, nonetheless. Regarding attachments, I was thinking more along the lines of template-driven attachments. So, for example, you may wish to include your logo in the auto-reply sent to the user - it would be better to use an attachment (file saved on server) as email clients do not automatically show linked/external images. The module simply makes use of wireMail, and so all extensions will be supported. So, for attachment functionality, I'll be making the feature available, but the module will check to see if the required wireMail extensions are available. (I haven't actually checked if these modules support attachments.) I do think it will be a good idea to allow user uploads as well. Will work on this over the weekend. (The module's core functionality works, so just adding and tweaking based on what is discussed in this thread.) Great stuff - once all the adding and tweaking is done, I'll swing this over to GitHub for testing. I'm guessing you both like the name SimpleForms?

Edit: The title of this post has been renamed to use the word "processor" instead of "builder" - this is not a form-building module. I'm currently putting together a simple developer-centric form processor for one of my projects, and have decided that I'd like to release it as a module as soon as it's stable enough. The idea is to separate it from the backend, and use per-form configuration files and templates instead. I could well implement a backend solution for this, but my preference is for it to be developer-centric. For me, this makes it easier to use and, of course, develop. Here's how it currently works: developer specifies forms and their particulars in a JSON file stored in the module's directory. The file includes dictations such as the name of the form, the fields it uses (along with their sanitization/validation rules), template information, and a set of emails to send when the form is being processed. An example of such configuration is: { "contact": { "name": "Contact Form", "fields": { "name": { "sanitize": "text", "rules": { "required": "Please enter your name." } }, "email": { "sanitize": "email", "rules": { "required": "We need to know your email address so we can get back to you.", "email": "That doesn't look like a valid email address." } }, "company": { "sanitize": "text", "rules": { "min(4)": "That's a tad short for a company name." } }, "contact": { "sanitize": "text", "rules": { "int": "Please enter only the digits of your phone number (no spaces or other punctuation)." } }, "message": { "sanitize": "entities1|textarea", "textField": true, "rules": { "required": "Please enter your enquiry/message.", "min(250)": "Please enter at least {$0} (but no more than 2000) characters.", "max(2000)": "You have reached the {$0} character limit. Please shorten your message." } } }, "info": { "fromName": "The ABC Accounting Team", "tel": "(011) 100 1234", "altTel": "(011) 100 5678" }, "emails": { "autoReply": { "template": "auto-reply", "to": "{input.name} <{input.email}>", "from": "ABC Accounting <noreply@abc.accounting>", "subject": "Enquiry/Message Submitted - Thanks!" } } } } As seen in the 'emails' key, templates can be defined for each email. These templates can be plain/HTML/both, and accept information regarding form input, the 'info' key, and a custom stylesheet, which is created as a file, but imported directly into the HTML version of the template. The module will also come with a jQuery module to assist in processing the form. Frontend is up to the developer/designer. Currently, the directory structure of the module is: root - forms.config.json / templates / form-name - template-name.html - template-name.css - template-name.txt I'm now thinking that it would be better to change the structure to this: root / form-name / templates - template-name.html - template-name.css - template-name.txt - config.json That is: each form will have its own folder containing configuration and templates. So I'm starting this thread to ask the following: Firstly, what do you think of this idea, and do you think you would make use of this module? Of the two structures above, which one would you prefer? Would you want the ability to make use of attachments in your emails (such as a logo)? (If I'm not mistaken, we'd then need to require WireMailSmtp or WireMailSwiftMailer...) As a side note, it's worth mentioning that this module is really intended to be used on small- to medium-sized sites that require multiple forms where developers are not in a position to obtain Ryan's excellent FormBuilder. Any input here is most welcome. (And yes, as gathered by my signature, the module is called SimpleForms. If you have a name suggestion, please feel free...)

The counter ($boxCount) is first set to 0. Then, the loop starts. As the counter is at 0 (not == 3), it will output the box, and increase the counter by 1 ($boxCount++). When the third box is done, and $boxCount == 3, then a line break is inserted, and $boxCount is reset to 0. If you have 7 boxes, then the output will be: <div class='projektbox'> ... </div> <div class='projektbox'> ... </div> <div class='projektbox'> ... </div> <br> <div class='projektbox'> ... </div> <div class='projektbox'> ... </div> <div class='projektbox'> ... </div> <br> <div class='projektbox'> ... </div> It's really that simple. @LostKobrakai's reference to doing this without PHP is the correct way to do it, though.

$box_count is a new variable - you need to be initialising it to 0 outside the loop. The variable is simply a means for you to see where you are in the loop, and has no direct association with $box itself. (I have used the camelCase naming format for the counter, in my example.) <?php $boxCount = 0; ?> <?php foreach ($page->projectBox as $box) { if ($boxCount == 3) { // start a new line echo "<br>"; $boxCount = 0; } else { echo "<div class='projektbox'>"; // box stuff echo "</div>"; $boxCount++; } } ?>

So I've updated mine - these are essential to my current projects: TemplateDataProviders TemplateTwigReplace MarkupSitemapXML Blick VersionControl (ProDrafts looks awesome, though) And, of course, for migrations: Jumplinks

Both fields are meant to be empty. The password could not be inserted as PW does not know it - after all, it is hashed. You must be using a password manager of some kind, and it may be interfering with the submission process.

You won't find it in the field list - check under "Advanced", like every other template.

There are a few hosts that seem to require this. Perhaps adding a shortlist in the .htaccess file will help?

Quite correct, as you have it exactly.

Love posts like this. Thanks for sharing, elabx.

Spotted this several months ago - quite handy indeed.

Hi MuchDev, The asterisk wildcard was not part (and probably still is not part, haven't actually checked) of the original ProcessRedirects shipped via the modules directory. That was one of the reasons I did not include the functionality. However, and more importantly, it's sometimes hard to tell what that wildcard implies. Sure, when used at the end of a path, it means "everything until the end", but, when used in the middle, does it represent 1 segment, or all segments? It could catch paths that were not meant to be caught. I may look at implementing a proper solution for the importer to detect these, but that won't be soon. As a recommendation, swap out the asterisk wildcards with {all} - this is a good base level. So, in your case: Source: path/subpath/{all} Destination: newPath Have a look at the documentation on wildcards and smart wildcards - Jumplinks doesn't use regular expressions or asterisk wildcards. There's also a new wiki page containing examples.

There's only one other thing I can think of at the moment, but I don't think it's completely viable, and may be somewhat irritating: when a select value is changed, the value should be passed to a function that refreshes the page and, thus, the other selector. Any changes to the source and timed activation would also be kept. As said, though, refreshing the page would be irritating (especially to me)... (I made a little progress syncing the selectors, but manually setting the Autocomplete seems to break it - that is to say that its normal functionality no longer works.)

Yeah, I gave use-case a thought - doesn't seem like anyone else has done this before... I think that it may just be best to leave the functionality as it is, where both selectors only update the text input, which is used when saving data. Not a very elegant way of going about it, though. Perhaps a note explaining that the selectors do not sync will be of help. Wonder if Ryan may be able to assist on this one - though it isn't in demand, it can prove to be useful at times.

Sure, but that's only used to submit data - how do I actually get the fields to visually sync?

As part of a new feature for Jumplinks, I need to be able to sync the above. Presently, when a page is selected via either of the two, the text input field gets updated accordingly. However, if I use PageAutocomplete, then PageListSelect needs to reflect that change, and vice-versa. I have been looking around the various source files, but haven't found any standard method for updating them. Naturally, val() doesn't work because it isn't tied to anything. Any other way I can accomplish this? Right now, I have this: $('#destinationPage').bind('pageSelected', function(a, b) { if (b.id > 0) { $('input#destinationUriUrl').val('page:' + b.id) } }); $('#destinationPageAuto').bind('change', function(b) { if (b.currentTarget.value > 0) { $('input#destinationUriUrl').val('page:' + b.currentTarget.value); } }); Oh, and it appears that the pageSelected event doesn't seem to work for PageAutocomplete - is this a bug?