v0.10.3 of TDO Mini Forms released: an end to register_global and session issues! (I hope)
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
Guest
April 16th, 2008 at 1:03 pm
wow, good to know, thanks a lot mate!!
April 16th, 2008 at 2:02 pm
[...] More If you like this why not read the previous dated post. LiveJournal This post is avalible on my LiveJournal here. Trackbacks You can [...]
Guest
April 17th, 2008 at 5:09 am
Hello, I’m having trouble displaying custom fields’ input fields in the submission forms with the recent upgrade. It was an upgrade from a previous installation and everything in the admin area is set up correctly. I think it may be a small error, any fixes? It’s not outputting any errors for me to give you.
Administrator
April 17th, 2008 at 9:12 am
Hi Obey, I am in the process of fixing it. It’ll be in v0.10.4.
Administrator
April 17th, 2008 at 10:03 am
This issue is fixed in v0.10.4 which is now avaliable on wordpress.org … I’ll post about the new version soon…
Guest
April 20th, 2008 at 3:15 am
You Are the Man breathren. People can now post. Great Job. I was ready to switch servers.
I see your a Gammer - play any cooperative? http://www.Blackhall.net/Games.htm
Administrator
April 21st, 2008 at 9:13 am
No problsm STARTNET. You’re not the first to ask for it.
I’m a gamer alright but table-top games such roleplaying and board games. I used to be a big PC Gamer but I don’t have the time - except for my Wii!