Comment form using FormUI
ringmaster
I'm running into a snag.
When using FormUI to build the comment form, I have two options:
1) I can set the action URL of the FormUI form to the existing
"submit_feedback" rewrite rule URL.
Problem: The native form processing of the FormUI object never takes
place, and so things like automatic validation of fields (for URL,
email, and required values) doesn't happen. This is especially a
problem for custom-added fields, which is an advantage of using FormUI
at all.
2) I can leave the action URL blank and let the FormUI object process
the form and add the comment.
Problem: Because the custom submission URL isn't used, plugins like
SpamChecker that rely on adding additional data to the request via the
URL don't work properly.
Perhaps I need more time with it, but I haven't been able to determine
a way for this process to degrade gracefully so that the current
comment forms continue to work while FeedbackHandler also supports
FormUI-based submissions and tackles the above problems. I was
thinking more eyes on the issue might be fruitful.
If no means can be determined to account for both posting types, then
ideally what I'd like to do is convert all themes to use FormUI for
comment submission, and update all plugins that previously modified
the comment submission process to use FormUI instead.
The advantages of using FormUI for comment submissions, to be clear
about it:
* Allows plugins to programmatically add fields to the comment form
(think hidden fields or custom captcha)
* Allows the form to more effectively process submission errors
(required fields and field types)
* Allows the form to be generated from core (by calling one function:
$theme->comment_form();)
* Continues to allow customization of the form to fit into the site
layout
I have code that solves all of the associated issues I could think of
except for those two points listed above.
http://pastoid.com/bil
What I'm looking for is alternate ideas for solving either of the
above two problems, or opinions on revising comment submission to
require FormUI.
Owen
mikelietz
jogged my memory.
Did you try the one from theme-helper?
http://trac.habariproject.org/habari/browser/trunk/htdocs/system/plugins/themehelper/themehelper.plugin.php#L121
Just scanning that code it appears to start with option 1. I haven't
used it in a theme to say if it works or not.
-mikelietz
ringmaster
>
> Did you try the one from theme-helper?http://trac.habariproject.org/habari/browser/trunk/htdocs/system/plug...
> Just scanning that code it appears to start with option 1. I haven't
> used it in a theme to say if it works or not.
I've also added code to address the display of multiple comment forms
on a single page and FormUI validation for required fields (which
doesn't work and is the main issue with option 1).
Owen
Matt Read
> I would like to build the comment form in my theme using FormUI, but
> I'm running into a snag.
>
> When using FormUI to build the comment form, I have two options:
>
> 1) I can set the action URL of the FormUI form to the existing
> "submit_feedback" rewrite rule URL.
> Problem: The native form processing of the FormUI object never takes
> place, and so things like automatic validation of fields (for URL,
> email, and required values) doesn't happen. This is especially a
> problem for custom-added fields, which is an advantage of using FormUI
> at all.
FeedBackHandler could create the current active theme object, then
call $theme->get_comment_form() to retreive the submitted formUI
object, then process the formUI calling plugin hooks as needed, also
allowing themes to hook in. The theme could also overload the
get_comment_form() for specialized formui fooness.
> 2) I can leave the action URL blank and let the FormUI object process
> the form and add the comment.
> Problem: Because the custom submission URL isn't used, plugins like
> SpamChecker that rely on adding additional data to the request via the
> URL don't work properly.
This is an interesting idea. GET request would retrieve the post
object/child objects; POST request would write to the post
object/child objects.
Although, I do like having a separate URL/ActionHandler to submit
comments to. It allows Plugins to hook the "before_act_$action" and
"after_act_$action" hooks, if you are doing something crazy like only
allowing OpenID authenticated comments ;).
> Perhaps I need more time with it, but I haven't been able to determine
> a way for this process to degrade gracefully so that the current
> comment forms continue to work while FeedbackHandler also supports
> FormUI-based submissions and tackles the above problems. I was
> thinking more eyes on the issue might be fruitful.
>
> If no means can be determined to account for both posting types, then
> ideally what I'd like to do is convert all themes to use FormUI for
> comment submission, and update all plugins that previously modified
> the comment submission process to use FormUI instead.
To degrade back to normal form submittion would require checking if a
formui was submitted, then possibly extract the formui name/value
pairs and process (This would still allow formUI to do it's validation
and extract any custom added feilds for processing through plugin
api). If no formui was submitted we would just grab and process the
data.
Essentially we would be creating two unique systems to gather the same
data so it can be processed in a uniform way. I would rather force the
use of FormUI in themes, or not use it at all.
> The advantages of using FormUI for comment submissions, to be clear
> about it:
>
> * Allows plugins to programmatically add fields to the comment form
> (think hidden fields or custom captcha)
> * Allows the form to more effectively process submission errors
> (required fields and field types)
> * Allows the form to be generated from core (by calling one function:
> $theme->comment_form();)
> * Continues to allow customization of the form to fit into the site
> layout
I'm all for using FormUI for comments form, if we can work out the
problems that currently trump it.
Also, since the element names are hashed, wouldn't that make it harder
for the spam bots to determine which field is name/email/url? .. But I
guess most just fill every one with the same crap.
--
Matt Read
http://mattread.com
ringmaster
>
> FeedBackHandler could create the current active theme object, then
> call $theme->get_comment_form() to retreive the submitted formUI
> object, then process the formUI calling plugin hooks as needed, also
> allowing themes to hook in. The theme could also overload the
> get_comment_form() for specialized formui fooness.
If the form fails to validate, it should display the post page again
with the errors. There's no guarantee that the form will exist on a
page showing a single entry (one that would display for the rewrite
rule "display_entry"). I've been building my new theme on the premise
that a comment form could appear on every post on the home page, for
example. (Yeah, this seems a little crazy, but I have plans for this
that would behoove keeping FormUI/comments this flexible.) So it's
not enough to simply redirect back to $post->permalink.
Anyway, since you have submitted the form to a new URL, it's hard to
know where the form submission came from unless you want to trust
$_SERVER['HTTP_REFERER'] or add a hidden field to the comment form
with that information. Either way, you'd need to either display the
original page at the feedback URL (that would look confusing) or store
the form errors in the session, bounce back to the referring page, and
then have FormUI pull the errors back out of the session for display.
Tricky business, that. But maybe it's the way to go. Storing FormUI
errors in the session might be useful for other things, too. I'm not
sure what yet, though.
> Although, I do like having a separate URL/ActionHandler to submit
> comments to. It allows Plugins to hook the "before_act_$action" and
> "after_act_$action" hooks, if you are doing something crazy like only
> allowing OpenID authenticated comments ;).
that we get in Habari that other systems don't have. I think this is
responsible for a good bit of reduction in automated spam.
> To degrade back to normal form submittion would require checking if a
> formui was submitted, then possibly extract the formui name/value
> pairs and process (This would still allow formUI to do it's validation
> and extract any custom added feilds for processing through plugin
> api). If no formui was submitted we would just grab and process the
> data.
>
> Essentially we would be creating two unique systems to gather the same
> data so it can be processed in a uniform way. I would rather force the
> use of FormUI in themes, or not use it at all.
to doing so. It would actually be easier to have only one system,
since determining how to handle incoming submissions, whether using
the existing code or FormUI, is a challenge in itself.
> I'm all for using FormUI for comments form, if we can work out the
> problems that currently trump it.
system this way, but I didn't want to make any changes that would
affect existing themes without more input first.
I may not have said it explicitly before, but if we make a decision on
this, my local code is 80% there already.
> Also, since the element names are hashed, wouldn't that make it harder
> for the spam bots to determine which field is name/email/url? .. But I
> guess most just fill every one with the same crap.
be used. But if that's not a requirement, then the names can be
hashed per-post, per-field. Also, the ability to add new fields to
enhance protection from spam, like the honeypot plugin does, would be
almost too easy.
Owen
Michael Harris
you're talking about, so this might have no bearing, but please bear
in mind the impact (or advantages) various approaches might have on
outsourced comments systems such as Disqus or Intense debate (that
might even one day interoperate, Owen :)
--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
IRC: michaeltwofish #habari
Arthus Erea
they override Habari – regardless of how Habari is processing clients.
+1 for forcing use of FormUI, for all the excellent reasons outlined
by others.
+1 for having the form target be the current page (no redirect). It
seems simpler in the long run and will always ensure that errors are
displayed in the correct place. Additionally, it should be relatively
trivial for plugins to hook into FormUI for any additional error
processing (such as forcing OpenID) they wish to do.
Michael Harris
>
> I can't see that those services would be affected in the least, since
> they override Habari – regardless of how Habari is processing clients.
Disqus, for example, does not have to override Habari comments
completely. Comments can still be submitted to and stored by Habari.
ringmaster
wrote:
> 2008/12/13 Arthus Erea <arthus.e...@gmail.com>:
>
>
> > I can't see that those services would be affected in the least, since
> > they override Habari – regardless of how Habari is processing clients.
>
> Disqus, for example, does not have to override Habari comments
> completely. Comments can still be submitted to and stored by Habari.
would happen after the comment is received via whatever means,
conventional or FormUI, via hooks in the Comment class.
Just sayin'.
Owen