I’ve just released v0.10.3 of my TDO Mini Forms plugin. Get it in all the usual places.

The biggest changes in this version is that I’ve implemented a work around for the register_globals and $_SESSION issues. It should be noted that 99% of the time these are/were host configuration problems and nothing to do with TDOMF but I got fed up trying to support users on various different hosts who had difficulty turning off register_globals or enabling $_SESSION support. (So if this enables TDOMF to work flawlessly for you, consider donating, because it’s for you I did it. :) )

But moving forward, whats in store for TDOMF?

I’m currently working on two new features. The first is AJAX support. I did some experiments on v0.10.2 and found I could enable AJAX and everything seemed to work. However I only did “shallow” testing. I’d have to check if there is a limit on the size of the post and if it supports foreign/non-standard characters in posts. I won’t, initially, support fallback to a non-AJAX form, mostly because it would require making sure that all widgets have a javascript-less version (I think they do but I haven’t checked). AJAX was never really a critical feature, however I’m using it to support the other feature, which is a Form Hacker. (AJAX also neatly side-steps the register_global and form data stuff too - maybe I should have implemented this first rather than the fix above! :) )

The Form Hacker will allow you to modify the generated form without modifying the code. A lot of people want customisation that I haven’t built-in to TDOMF and modifying the code can be a bit of a nightmare with the innovative building-your-form using drag-n-drop/widgets as the code for the form is spread among a lot of files. It also means, that if you modify the code, you can’t upgrade without losing your hacks. I thought this might be an easy feature, and I have the bones already implemented. I added some tags that get expanded when the form is displayed, like user info, form name, form key, etc.

But I hit a snag with preview and validation of a form. Both these features, currently need to update the form once activated, often on a per-widget basis, otherwise if your form fails to validate or you preview your input, all the previous filled in fields are empty - forcing your user to re-input the form! However if AJAX is used then those filled in fields are untouched as only the preview and validation information is passed back. This means I could get an beta version of the Form Hacker out that supports only AJAX to get people using it and feedback on it. I’d like then to extend the Form Hacker so that you can hack individual widgets (not just an entire form) and support conditional tags (so that widgets can fill in previously entered input after validation and preview).

I’ve always tried to get the big features out of the way before concentrating on little bits and pieces and mostly these have been driven by what users have been asking for support and help on. The next big feature in my mind has always been the ability to edit posts. (In the back of my mind, having edit-posts means the plugin hits v1.0 status). It’s not really that big in terms of code but it is in how to implement it because there is a million different ways. Some considerations I have in mind so far:

An Edit Form could be included on posts that user can edit and/or just have an “Edit” link to the form page. If you have AJAX, it could just “replace” the form in-line. It requires a new user-access, i.e. the author - and how do you handle submitters who don’t have a user account? When someone edits a post (or page), the post can be automatically updated and published (assuming your happy to trust the submitter) or set back to draft for moderation. But you may also want only the changes to be held in moderation while leaving the original post in place. The ability to editing a post also implies the ability to delete the post. And likewise it should be optionally possible to manage comments (delete, approve) And then what about comments?

Your opinions are welcome!

Version info for v0.10.3:

Fixed a bug in the random_string generator: it did not validate input and I’ve been using a value that’s too big (which meant it could return 0) Widgets now support “modes†which means widgets can be filtered per form type. Right now that means widgets that don’t support pages will not appear, if the form is for submitting pages. Can now choose how to verify an input form: original, wordpress nonce or none at all Implemented a workaround for register_global and unavailability of $_SESSION on some hosts Fixed double thumbnail issue in WP2.5