Mike Rockett

Results for the YAML poll indicate that the most preference is given to its implementation in addition to JSON (with six votes of the ten votes already cast). Will get cracking on this now. It'll work by auto-detecting what is in use, and will give preference to JSON, if both formats are provided for a form. That poll is now closed. Shortly after, will get to work on multi-language support for validation and other messages. Then, I'll begin work on the renderer, which may take a while (guess I need to do a bit of research). Anyone with ideas on how to go about it and/or what the config structure should be is more than welcome to contribute them.

PostCSS is really looking awesome. Going to start playing with it today.

I haven't yet had a chance to play around with ProcessRedirects on multi-language sites, and so can't be sure why that is happening. Have you perhaps tried using Jumplinks?

Hi blynx, Presently, the module simply processes forms using their config.json files. I have a few things I'd like to do (mentioned previously) before I get to the rendering/generating of the forms. In case you did not see any the previous posts, form rendereing will have support for PW Inputfields, Bootstrap, and Foundation (I may include support for more frameworks - not so sure yet), but the rendering process will be very simple. As this is a developer-centric module, the idea is to leave the form-building side up to the developer/designer. I have had a look at your question regarding JSON-form-building. SimpleForms (or whatever it is named in future, based on poll results) is really designed for use in front-end templates. I have not given any consideration as yet to allowing other modules to make use of it. Will give it some thought, though. Thanks - I only just realised that polls are associated with topics. So "More Reply Options" doesn't do it for me. I have to go to the first post and "Use Full Editor". As I've already created the polls and people have already started voting, I'll just stick with PollMaker for this one. Will use the forum-polls in future.

Have never found the need to. Except back in the day when I developed in Delphi - there was some strange plugin for that. If I did ever find the need to, I'd probably just use private (or public) gists, or just use a repo. Gotta keep it simple. ;-)

Hi Peter, and welcome to the forums. I have a strange feeling you're on 1and1 hosting - though, I could be entirely off-target here. I only guess as much because 1and1 (at least the UK 1and1) did that to me several years back. Your best bet is to contact your host and ask what the issue may be. It could also have something to do with cron-jobs - if you have access to those, best you have a look there to see if any script has been programmed to overwrite the file.

Okay, have created two polls: YAML Config Module name Vote away!

Would anyone be interested in YAML support (as opposed/in addition to JSON) for the form config?

SimpleForms Alpha bumped to 0.7.0, with a few chages. Firstly, SimpleForms is now ready for translation. If anyone is willing to translate the module, please go ahead - your contributions are most welcome. Side note: there isn't much to translate at this point, and some messages may change as I go along. Next, template stylesheets are now automatically prepended to each HTML template if found. The way in which this works is simple. If you have a CSS file with the same name as the form being worked with, that stylesheet will be prepended to every HTML template for that form. Of course, if you're not using HTML templates (these are indeed optional), then stylesheets will simply not work. I am considering the possibility of being able to define for each template whether or not it should have the form stylesheet prepended - some templates will not require such a stylesheet. (Input here is also most welcome.) I've also made a few changes (additions, rather) with regards to using forms without AJAX. A few new methods have been added for the rendering of errors. Before, you would simply wrap $simpleForms->fieldError('name') inside a <div data-simpleforms-fielderror="name"/>. The problem that this brings about is that if no error is present, and you have added padding to the error block, it would always be visible. Now, you can use a renderer-method or a has-method to assist. Either of the below will work: <!-- Render the default field error markup --> <!-- Result: <div data-sf-fielderror="name">This field is required.</div> <?= $simpleForms->renderFieldError('name'); ?> <!-- Or render it yourself, if you want to style the div. --> <!-- The data-sf-fielderror is completely optional if you wish to not use AJAX. --> <?php if ($simpleForms->hasFieldError('name'): ?> <div data-sf-fielderror="name" ><?= $simpleForms->fieldError('name'); ?></div> <?php endif; ?> The same applies for $simpleForms->formError(), where you can use hasFormError() and renderFormError(); Note: This change is only for those who specifically choose not to use AJAX, and does not support the dual-approach, where AJAX is enabled, but the visitor does not have JS enabled. If you want to use AJAX (always recommended), then you should always render the error blocks, even if they're empty. Remember that they are used by the front-end module, which hides them when they are not needed, including when the page is loaded. You'll also notice from the above example that the data attributes have been renamed. Instead of the full data-simpleforms-*, simply use data-sf-*. Next on the todo-list: Two major things coming up are support for multi-language form messages (form and field errors, success message) as well as module configuration, which entails being able to set module-wide defaults that affect all forms. @teppo: Thanks for the mention on ProcessWire Weekly today - much appreciated, as always.

Have just bumped the dev branch up to 1.3.4, bringing several important updates to be merged with master soon. Firstly, and most importantly: In light of PW 2.7 being around the corner, the minimum PW version requirement is now 2.6.1. This allows the use of 2.6 goodies that were not used before. Mainly, Jumplinks now uses ModuleConfig. Next, the Entity Editor (the name used for the jumplinks editor page) is now working as expected. PageListSelect and PageAutocomplete are now syncing correctly. This is really just a visual gimmick for the purposes of consistency. The editor now looks much cleaner, and easier to use. Few other changes to note: Table font size has been increased a notch. Destination column now has page title and full path hint for jumplinks that reference existing pages. Table footer has been removed - I don't think this was very informative, and thus not needed. Please note that I have not tested everything extensively as yet - this will be done soon. As such, don't use this branch on a production site until merged with master. Once merged, I'll bump the version up to 1.5, considering the major changes/departures compared to the current 1.3.x.

Seem to have got it working. Really hacky, but it does the trick. (Keeping in mind, here, that this is really just a visual gimmick...) $('#destinationPage').on('pageSelected', function(a, b) { if (b.id > 0) { $('input#destinationUriUrl').val('page:' + b.id) $('#destinationPageAuto').val(b.id); $('#destinationPageAuto_input').attr('data-selectedlabel', b.title).val(b.title); } }); $('#destinationPageAuto').on('change', function(b) { if (b.currentTarget.value) { $('input#destinationUriUrl').val('page:' + b.currentTarget.value); $('#destinationPage').val(b.currentTarget.value).parent().find('.label_title, .PageListSelectName').text($('#destinationPageAuto_input').attr('data-selectedlabel')); } });

Sorry about that - accidential input appeared on that line when attempting a grep. Issue has been resolved - please replace Jumplinks.module with the one from Github.

At first glance, my personal preference is Semantic. (Keep in mind I have not seen it before.) It seems much more refined than UIKit, and has a whole bunch of features that I'd need for a few projects coming up. It's also less Bootstrap-like, carrying it's own design 'language', if you will. Have never been a fan of Bootstrap's default UI/UX experience, and so this is a big plus for me. As for actually working with these two frameworks - I haven't done so myself, and, therefore, wouldn't be able to say anything about it. Upon looking at the Semantic docs, I much prefer it in comparison to other frameworks. Grid looks pretty wicked as well. Just my 2c. ;-)

I think that was indeed the intention. Surface Book looks cool, but it's name is obviously designed to target MacBook directly. As for the flagship phones, I think they're excellent in terms of features, but the design could have been much better. We'll just have to see how things pan out over the next few weeks - high adoption rates = Apple's butt kicked.

I have found the issue. If there are no Jumplinks registered scanAndRedirect simply returns false, which lands up skipping the process of logging the request. I have now fixed the issue both on master and dev. Will get Module Directory to see the update shortly. Thanks for the heads-up!

Interesting... I just tested on 2.6.17 (one of my local testing installs) and it really isn't logging 404s... Let me have a quick look.

File upload support is now ready - albeit a few possible oversights. You can grab the latest update from here. As part of this new feature, several things have changed. Most notably, the template form output now uses $simpleForms for fetching previous input as well as responses. This prevents warnings when using debug mode, and generally looks a lot cleaner and easier to understand. (This is shown at the bottom of the post.) Of course, the big part of this is that file uploads now work. As described in my previous (greyed out) post, the front-end module now uses FormData, as opposed to simply serialising the form on submission. This allows for AJAX file uploads. If you'd like to make use of a file field, it needs to be defined in config.json. However, it should not be defined in the "fields" array, as validation etc is handled differently, mostly due to WireUpload, and internal checking to see if the field is actually required. As can be seen in the config file included in the repo, defining a file is as simple as: "files": { "file": { "required": "You need to upload a file", "validExtensions": ["pdf", "docx"], "maxSize": 4096000 } }, Each file field can be declared with a name - the same name used on the HTML form itself - and should be declared with the above rules in place. Of course, the required rule is not necessary if the upload is not required. The maxSize rule is measured in bytes, per the WireUpload standard. Each field may only take one file for the time being - WireUpload will throw an error otherwise. Will be looking to support multiple files in the future, but this will involve quite a few changes (off the top of my head, I can see it being a little overboard - I could be wrong). If the uploads are valid, they will be saved in a UID directory in the uploads directory for the form. For example: site/modules/SimpleForms/forms/contact/uploads/{random_uid}/filename (Keep in mind that the storage location for form configuration, templates, and uploads will change to the assets directory when the module is ready for production use. Currently, any module upgrades overwrite the forms directory.) These will then be made available to each of the email templates as linkable downloads through {files.{field}.name} and {files.{field}.url}. See the template examples to see how they can be used. Lastly, as mentioned at the beginning of this post, there is a new method for declring forms, should you wish to allow them to work without AJAX. I don't think any explanation is required here, so here's the template file example (this is not included in the repo - you'll need to add it to a template yourself). Documentation I'm still working on the docs, but won't finish them until such time as the module has reached feature-parity and is mostly stable. Naming Have decided to stick with SimpleForms. I still quite like QuickForms, and so the chance of me renaming the module is not lost forver. ;-)

I'm busy finalising the file upload part, but it appears that the $_FILES global is an empty array when not using AJAX. It works perfectly when AJAX is used, however. For some context: the front-end plugin now uses JS FormData instead of serialising the data - this adds support for file uploads, and PHP puts these in the $_FILES global as expected. However, if I turn offthe AJAX side of things, the file does get sent (request headers show this), but the global is empty. I need the $_FILES array so that I may only proceed with a WireUpload if files were uploaded (and provided they are allowed). Any idea what may cause this? Ah, I do apologise - I left out the enctype="multipart/form-data"

Update coming soon with support for file uploads (AJAX or not), plus a few fixes.

Hi pwnebie, and welcome to the forums. If you're ever keen on separating things properly (which is much nicer, and easier to maintain), give TemplateDataProviders a try. TemplateTwigReplace also works really nicely with it.

Hmm, that is strange. Technically, there would be no reason for that to occur, and can't reproduce it. I don't think it would be a server issue either, but what was the related issue regarding IDs?

May be silly to ask, but are you 100% sure you've selected the intended template for the page? And have you perhaps tried with the latest dev (2.6.19)? (For the record, I am unable to repdroduce this.)

Thanks for the clarification.

Haha, I only just noticed that. (Methinks troll.)

Had a look at the moderating team list today, and noticed there are two moderation groups: "Moderators" and "PW-Moderators". Is there an intended difference between the two? If so, should they not be named more appropriately?