Mike Rockett

As can be made apparent by testing them, there are big differences. Give them a try, and you'll see.

Quite correct - the user has indeed begun to irritate me (and others, I'm sure). Fact of the matter is that the user signed up, started posting things all over the place about whether or not PW should be used - yet this discussion has been had so many times before. There are indeed signs that the user has tried PW, but not enough signs indicating that he/she read the docs. For me, this is meant to be a high-quality discussion and support forum and, as such, I agree with the encoding of his two posts (which are exactly the same, for those who did not notice). </thread>

Well yeah - the thing is that their source code went along with it, which may speed up the process of de-hashing (though, I'm not so sure on that one).

A site I've never heard of before has been hacked. I couldn't resist posting here, however, because their logo reminds me of a good friend. Info on the hack: http://arstechnica.com/security/2015/10/gigabytes-of-user-data-from-hack-of-patreon-donations-site-dumped-online/ Patreon's site: https://www.patreon.com/

Whoa. That's the strangest thing I have ever seen. Just wow. Can't test here at the moment, but will try have a look later. Quick question: Does this happen in the current stable? (PS: You've made me drink a brown cow now.)

Are you asking how to do that? Is the directory not writable?

Very nice indeed, great work. Gotta love minimal sites.

That is true, hacking happens all the time. The thing with ProcessWire is that the system is not as well-known (that is to say that it is not as widely-used) as WordPress/Drupal/Joomla, etc. As such, attempts are very rare. Ryan Cramer is the creator of the project, and pours a lot of effort into improving it. Suggestions are always welcome, and there are a few others that work with Ryan on specific features (so far as I am aware - perhaps someone else can elaborate on that). Nonetheless, Ryan is the primary developer and, as such, makes the vast majority of changes. You're very welcome indeed. Hope you enjoy using ProcessWire - it's certainly been a great journey for me. I love it, clients love it - it's just a win-win for everyone, really.

ProcessWire is under active development, and will be for the foreseeable future. Please see the 'dev' branch for more recent commits (the most recent one was made 1 minute ago). Also check out the blog for information about latest updates to ProcessWire. Additionally, I am not aware of any 'hacks' - ProcessWire is a very safe and secure system. Only 'bad modules' could create the potential for a hack, but that doesn't seem to have ever happened.

Have changed the module's extension to .module.php for syntax highlighting on GH and specific extension support in ST3. Module refresh required, more than likely.

New Commit: Non-AJAX implementation Version: 0.5.0 This commit adds support for users without JavaScript enabled, or developers who choose to not use AJAX. Of course, the implementation of non-AJAX forms is different, as the template needs to handle things. The following is a simple example of how to go about using non-AJAX forms: <?php $response = $simpleForms->response;?> <?php $old = $simpleForms->oldData;?> <?php if ($simpleForms->successful): ?> <p class="formSuccess message"><?=$response->success;?></p> <?php else: ?> <form data-simpleforms="contact" action="<?=$simpleForms->actionFor('contact');?>" method="POST"> <?=$simpleForms->csrfToken();?> <div data-simpleforms-formerror><?=$response->error;?></div> <div class="inputField text"> <input type="text" name="name" id="name" placeholder="Your name (required)" value="<?=$old->name;?>"> <div data-simpleforms-fielderror="name"><?=$response->errors->name;?></div> </div> <div class="inputField text"> <input type="text" name="email" id="email" placeholder="Your email address (required)" value="<?=$old->email;?>"> <div data-simpleforms-fielderror="email"><?=$response->errors->email;?></div> </div> <div class="inputField text"> <input type="text" name="company" id="company" placeholder="Company name (optional)" value="<?=$old->company;?>"> <div data-simpleforms-fielderror="company"><?=$response->errors->company;?></div> </div> <div class="inputField text"> <input type="text" name="contact" id="contact" placeholder="Contact number (optional)" value="<?=$old->contact;?>"> <div data-simpleforms-fielderror="contact"><?=$response->errors->contact;?></div> </div> <div class="inputField textarea"> <textarea name="message" id="message" cols="30" rows="10"><?=$old->message;?></textarea> <div data-simpleforms-fielderror="message"><?=$response->errors->message;?></div> </div> <div class="inputField submit"> <input type="submit" data-value="Submit Form"> </div> </form> <?php endif;?> Of course, there are other things that need to still be taken into account here. For example, using this specific method keeps form error tags visible at all times. The JS module actually hides these when they are not needed (a CSS rule is also needed to hide them when the page loads). However, when not using AJAX, these fields are always available. As such, if you style them (with padding and colour, for example), you'll see them when the page loads. A simple isset() should do the trick. A suggestion is to always use the above implementation along with the JS one so that both work.

Perhaps this will point you in the right direction: https://processwire-recipes.com/recipes/resetting-admin-password-via-api/ The only difference is that you would get the current user, instead of admin, and pass the post input: set('pass', $input->post->password);

Update regarding the HTML builder: This is obviously something that people would be interested in, especially when it comes to getting forms up and running as quickly as possible. However, it should be noted that I don't intend on making a full suite to handle this due to the fact that every form is different, and every scenario cannot simply be assumed. However, the builder will be able to output simple form layouts that do not require specific attributes to be set. At best, the JSON configuration for each form will accomodate classes/IDs for each input field, and will output the form in either Bootstrap, Foundation, or ProcessWire InputField format. If that doesn't suit you, then you should build the form yourself. As this is a developer-centric module, it is recommended that you design your own forms anyway. This gives you the fine grained control you may need - flexibility is key, here. I'll continue to work on this for the next week or so, and will push major updates as they're completed. The next major feature will be the builder, or at least a very simple implementation of one. With that said, the module is currently working as expected (form-processing), and already does more than I'd anticipated (input-masking), which puts a smile on my face anyway. I'll also be working on a full set of docs soon. The todo list has been moved to the repo's readme file.

This looks great! Going to try it out in a new project soon.

New Commit: Add inputmask.js support Version Bump: 0.4.0 This commit adds inputmask.js support, which can be used when you need more flexibility with your masks. Due to the fact that there are now two plugins for masking, the configuration keys represent their names. Instead of inputFormats, you should now use either formatter or inputmask. To use inputmask.js, simply call the script, and specify the applicable formats: <script src="<?=$simpleForms->script('inputmask');?>"></script> <script src="<?=$simpleForms->script();?>"></script> simpleForms({ inputmask: { contact: "(999) 999-9999" } }); // OR simpleForms({ inputmask: { contact: { mask: "(999) 999-9999", placeholder: "\u2007", // figure space (quite handy) } } }); Learn more about inputmask.js.

New Commit: Add formatter.js (plus multiple script support) Version Bump: 0.3.0 This commit adds formatter.js support to the front-end plugin. You need only include the plugin and specify the applicable formats. Add the script before the main script: <script src="<?=$simpleForms->script('formatter');?>"></script> <script src="<?=$simpleForms->script();?>"></script> Specify the formats for each field: simpleForms({ inputFormats: { contact: "({{999}}) {{999}}-{{9999}}" } }); Each input field is defined here by name (that is, the [name=""] of the field). You may either set a pattern (as above) or a configuration object (as below): simpleForms({ inputFormats: { contact: { pattern: "({{999}}) {{999}}-{{9999}}", persistent: true, // always show literal characters } } }); To see how formatter.js works, check out the demos.

ngrok is really great as it maps nicely with my virtual hosts, so everything just works automagically.

Note: An oversight on my side: upgrades will replace the forms directory. So I'd like to move the directory elsewhere - perhaps the assets directory?

New Commit: Plugin fixes and improvements Version Bump: 0.2.0 Fix: config pass to simpleForms() Configuration was previously not passed when using the simpleForms() shorthand method. Imp.: configuration structure (deep extension) Configuration array has been modified, now making use of deep extension.The default configuration now looks like this: { interimButtonText: 'Just a moment...', logErrors: true, processingClass: 'processing', scroll: { enabled: true, offset: 0, duration: 500, easing: 'swing', }, serverErrorAlert: 'Something went wrong on the server, and so this form could not be submitted. The form has been left as-is so that you may leave it open and try again in a few minutes.', events: { // Supplementary methods submitStart: function(form) {}, submitEnd: function(form) {}, // Override methods success: null, // function(form, message) failure: null, // function(form, errors, message) serverError: null, // function(message) } } Imp.: callbacks (overrides and supplementaries) All known callbacks have now been implemented. As seen above, submitStart and submitEnd are supplementary methods, which are called in addition to the defaults. success, failure, and serverError are override methods. New: Add processingClass to form on submitStart I had a case where I needed the form to be translucent when processing, and so the class has been added - you may style this as you wish. The name of the class may also be changed (see above config). Fix: AJAX options (global: true) AJAX event should adhere to global options. Fix: Add AJAX 200 OK 200 OK statusCode now implemented. Either make use of the success event, or it will fall back to default, which replaces the form with the success message determined in config.json; plate format: <div data-simpleforms-success class="sfSuccessMessage">{0}</div> Imp.: Scrolling options Scrolling has been improved. Per the above configuration, you can now turn it on or off, and change duration, easing, and offset (pixels above the form).

So I seem to have left out a crucial part for the jQuery plugin: the part when the form submission is successful. Will get this done soon. For now, if the module returns a 200 (meaning the form was processed successfully), there will not be any change on the form itself. I'll be setting it to either remove the form and show a message or call a user event method.

Sure thing - we never stop learning. Just a sidenote for everyone regarding the 500 errors. When a server error is returned, the plugin only alerts the user to the effect that they are told tha something went wrong. The reason can be determined by examining the request in the inspector. The plugin also has events for when the submit button is pressed (i.e. processing begins), when a response is received (i.e. processing finishes), and when a server error occurs. the simpleForms() method takes a configuration array, the defaults for which are: { interimButtonText: 'Just a moment...', serverErrorAlert: 'Something went wrong on the server, and so this form could not be submitted. The form has been left as-is so that you may leave it open and try again in a few minutes.', scrollTime: 500, onSubmitStart: function() {}, onSubmitEnd: function() {}, onServerError: null, } The methods do not take any arguments at present, but will do in the future. This will be handy when you want to use your own callbacks to display errors, dim out a form, show a processing message, etc. As mentioned before, more configuration options will become available over time.

I should probably be using a different error code for errors relating to the module itself. 422 seems to be the acceptable standard for invalid input - Laravel is using it. The errors are thrown in JSON format at present - this is an AJAX-driven module.

Forgot to mention something here: <div data-simpleforms-formerror></div> The front-end plugin fills this block with the validation error message, as defined in config.json. The one used in this testing release is as follows: <strong>Could not submit form</strong><br>{ucfirst:0} validation [error|errors:0] [was|were:0] found on the form, preventing it from being submitted. Please check the [error|errors:0] below (as indicated in the red [box|boxes:0]), correct the [field|fields:0] in question, and try again. As you can see, I've implemented my own simple JS templater here - simply called plate. The method in the plugin passes the error count (in digits and words, parameters 0 and 1 respectively) to the string. plate is intended to be a simple templater that replaces {0}, {1}, {2}, etc., with the arguments passed to it. Additionally, it does word-pluralisation if a number is provided as the parameter, and is able to ucfirst() a parameter on demand. In the case of the validation message: {ucfirst:0} will be replaced with the error count in words [word|words:0] will be replaced with either 'word' or 'words' based on the error count (in words). [word|words:1] would do the same thing. The plugin prepares everything like this: var errorCount = objectLength(errors); var errorCountWords = toWords(errorCount); var errorNotification = plate(responseData.error, errorCountWords, errorCount); Essentially, this is just a helper to make things as easy as possible when you want to be specific and informative. You need not use params if you don't want to. If you'd like to use plate in your own projects, please feel free to do so - no credits required. Here's the method: /** * String template parser. * @return string */ var plate = function() { var input = arguments[0]; var ucfirstMethod = 'ucfirst'; // Loop through each argument, checking for replacements. for (var i = 0; i < arguments.length - 1; i++) { var formatter = new RegExp("\\{(" + ucfirstMethod + "\?" + i + "\\}", "gm"); var pluralise = new RegExp("\\[([a-z]+)\\|([a-z]+):(" + i + ")\\]", "gmi"); var argument = arguments[i + 1]; // Detech ucfirst as toWords() always returns lowercase. if (input.match(formatter) && input.match(formatter)[0].indexOf(ucfirstMethod) >= 0) { argument = argument.charAt(0).toUpperCase() + argument.slice(1); } // Replace the input input = input.replace(formatter, argument); // Check for plurals/singulars if (input.match(pluralise)) { input = input.replace(pluralise, (argument === 1 || argument.toLowerCase() === 'one') ? "$1" : "$2"); } } return input; } Validation is handled by Violin, a package by Alex Garrett. Have a look at the readme to see which validation rules are available to you.

Have just committed 0.1.0 to GitHub. The bundle comes with a preset contact form definition, used for easy testing. All that needs to be done after installation is the HTML form, which is below for copy-paste purposes: <form data-simpleforms="contact" action="<?=$simpleForms->actionFor('contact')?>" method="POST"> <?=$simpleForms->csrfToken()?> <div data-simpleforms-formerror></div> <div> <input type="text" name="name" id="name" placeholder="Your name (required)"> <div data-simpleforms-fielderror="name"></div> </div> <div> <input type="email" name="email" id="email" placeholder="Your email address (required)"> <div data-simpleforms-fielderror="email"></div> </div> <div> <input type="text" name="company" id="company" placeholder="Company name (optional)"> <div data-simpleforms-fielderror="company"></div> </div> <div> <input type="text" name="contact" id="contact" placeholder="Contact number (optional)"> <div data-simpleforms-fielderror="contact"></div> </div> <div> <textarea name="message" id="message" cols="30" rows="10"></textarea> <div data-simpleforms-fielderror="message"></div> </div> <div> <input type="submit" data-value="Submit Form"> </div> </form> Of course, this form is not styled, and is very basic. This is just for testing purposes. actionFor simply prints the URI to the form processor for this form. csrfToken prints the hidden CSRF token. The next step is to ensure jQuery is loaded on the page - I tested with 1.8.3 (bundled with ProcessWire) only, so not sure if any bugs will pop up in later versions. Then, link up the front-end jQuery asset with either of the following: <!-- Cache-busted (default); outputs /site/modules/SimpleForms/assets/jquery.simpleforms.min.js?<unix_time> --> <script src="<?=$simpleForms->script();?>"></script> <!-- Non-cache-busted; outputs /site/modules/SimpleForms/assets/jquery.simpleforms.min.js --> <script src="<?=$simpleForms->script(false, true);?>"></script> <!-- Non-cache-busted, non-minified; outputs /site/modules/SimpleForms/assets/jquery.simpleforms.js --> <script src="<?=$simpleForms->script(false, false);?>"></script> And lastly, prepare the form using any of the following methods (just above the closing body tag): <!-- Just the contact form. --> <script>$("[data-simpleforms=contact]").simpleForms();</script> <!-- Or all the forms - all of these are the same, so best to use the last one. --> <script>$("[data-simpleforms!=''][data-simpleforms]").simpleForms();</script> <script>$(allSimpleForms()).simpleForms();</script> <script>simpleForms();</script> Form definitions have been moved to their own directories, as discussed previously. Have a look at the forms/contact directory, which contains the config and templates. Have also included a @todo list in the module's main file so you can see what's in the pipeline. For easy reference, here's the current list: /* @todo Auto-prepend existing stylesheet to HTML template - need not rely on template var {stylesheet}. * @todo Template attachments (inline data or attachment reference - perhaps we should rely on SwiftMailer for this?). * @todo Use reply link builder (for cases where emails may not be sent from sender - usually the case with SMTP). * @todo Translate all the things! * @todo Make module configurable - allow for default form-recipient and noreply/auto-response sender. * @todo Simple form builder, based on JSON specifications. * @todo Make AJAX optional, using standard form submission protocols. */ There are many configuration options still to come; I'd like to make this as configurable as possible, but without code-bloating the module. Looking forward to input from testers - this is, of course, nowhere near perfect, but is a good base/blueprint from which to start. Once we've reached feature-parity and the module is stable, I'll release it on a new thread, and put up some documentation.

Phew, I didn't even notice that until now.