Closed GoogleCodeExporter closed 9 years ago
GoogleCodeExporter
commented
9 years ago There's also an older, no longer supported (but really good) plugin, TDO Mini
Forms, that could be incorporated in some way for adding front end user post
capability.
http://wordpress.org/extend/plugins/tdo-mini-forms/Original comment by rul...@gmail.com on 6 Aug 2011 at 1:09
GoogleCodeExporter
commented
9 years ago Very cool. I'll take a look. For the front end, I think it would make sense
to incorporate reCAPTCHA if possible... I don't think that would be difficult:
just have an admin setting somewhere so the user could paste in their key.Original comment by fireproofsocks on 6 Aug 2011 at 2:39
GoogleCodeExporter
commented
9 years ago [deleted comment]I've looked under the covers of both U Can Post and TDO mini forms. There is
another by Perishable Press called User Submitted Posts. Of these, TDO had the
most potential but customization of the form layout was overwhelming and
mapping those fields to custom fields that I had manually created didn't seem
to work on image uploads.
A friend of mine pointed me to this project after I had done the work on
creating my own custom fields that worked with my own custom form. Yesterday,
I got the image uploads to attach to the custom form. Since I am working
against a deadline, I will have a look at the ease of use for your plugin once
the current project is wrapped up.Original comment by marjwy...@gmail.com on 6 Aug 2011 at 6:13
GoogleCodeExporter
commented
9 years ago Hi fireproofsocks,
I am using Gravity Forms + the (Gravity forms + Custom post types) plugin to
create posts from the front end. Seems to be working well, mapping to custom
fields etc.
Do not know if that helps.....Original comment by sas...@thespacelab.co.uk on 13 Aug 2011 at 8:00
GoogleCodeExporter
commented
9 years ago Thanks for the link -- I'll look at this for comparision.Original comment by fireproofsocks on 14 Aug 2011 at 8:13
GoogleCodeExporter
commented
9 years ago Original comment by fireproofsocks on 3 Sep 2011 at 5:23
GoogleCodeExporter
commented
9 years ago Original comment by fireproofsocks on 10 Nov 2011 at 7:39
GoogleCodeExporter
commented
9 years ago The variations here are many... shortcode seems the best way to handle this
because then the interface is cleaner: you could let the user choose which post
type the form should create, then you could let them decide which fields should
be available, e.g. if you didn't want the user to be able to create ALL the
fields. But this should also be possible via raw PHP in the template files.
The tpls used in the manager could be repurposed here for use on the front end,
but it'd also be helpful to have a master template where savvy users could
format the entire form displayed. That formatting stuff would not fit well
into a shortcode, so perhaps the best thing would be to reference a specific
directory in the tpls/ directory.
This has to come after the integration of input validation in the custom fields
(issue 6): the submitted forms should contain the same restrictions on data
input, lest the model get polluted.
This is a lot more work than I anticipated...Original comment by ever...@fireproofsocks.com on 23 Feb 2012 at 4:27
GoogleCodeExporter
commented
9 years ago This is interesting:
http://uproot.us/custom-field-suite/docs/gravity-forms-integration/Original comment by ever...@fireproofsocks.com on 2 Mar 2012 at 4:48
GoogleCodeExporter
commented
9 years ago At a minimum, the CCTM should integrate with Gravity Forms... I think the only
potential problem is the JSON encoding for multi- fields.Original comment by ever...@fireproofsocks.com on 2 Mar 2012 at 7:21
GoogleCodeExporter
commented
9 years ago Simple integration might just require the post-type to be referenced:
[create_post post_type="something"]
CCTM could look up the stats and display the form as needed. Who should be
listed as the author? And how to override other built-in fields (e.g.
post_parent)? Maybe any values listed will be hard-coded when the field is
created, e.g.
[create_post post_type="something" post_author="3" custom_field1="something"]
If a field is verbosely mentioned in the shortcode call, should that field not
be visible? Or should the value be the default? Or should there be an extra
parameter to determine the behavior?
Formatting string should include ALL available placeholders so that verbose
usage would allow for any formatting desired. We also need a parameter for the
"Thank you" message.Original comment by ever...@fireproofsocks.com on 27 Jun 2012 at 8:41
GoogleCodeExporter
commented
9 years ago Check this out: http://blog.dwolla.com/integration-spotlight-gravolla/ -- a
Dwolla integration through the form. Very cool.Original comment by ever...@fireproofsocks.com on 22 Aug 2012 at 8:46
GoogleCodeExporter
commented
9 years ago I think you are overcomplicating this. You're going at it the hard way first...
Do this instead:
Generate master template files for form submission and require savvy users to
implement the template file. This will make working with the code simpler for
you and simpler for other people who want to contribute to the project or make
recommendations. It will make it simpler to deal with security problems.
Just make a form generator and let it submit using WP's built-in method of
receiving new posts. Don't reinvent the wheel.
It really shouldn't even be necessary to deal with security problems in a form DISPLAY page because security SHOULD be handled by the page that RECEIVES the form submission. Don't worry about the front-end validation.Original comment by pha3...@gmail.com on 1 Sep 2012 at 7:47
GoogleCodeExporter
commented
9 years ago I appreciate the comments, and I'm not sure you have properly gaged the full
scope of this, but to clarify my reasoning/approach:
1. Not sure how "master template files" are possible without mixing HTML and
PHP in a messy implementation because each form is unique depending on the
elements in it. All formatting strings are tokens and are present in the tpls/
directory. Those components fit together to make the forms, e.g. as used by
the GetPostsForm class and also by the form generation that occurs in the
manager.
2. Form generator is already made (that's the GetPostsForm) class: form
generators are subtly complex esp. when dealing with repopulating data,
validation, and allowing for customizations. You cannot use WP's "built-in
method of receiving posts" because WP has no coherent API for post-creation,
and even if there were, it would not obey the validation rules or storage
procedures used by the CCTM. Seeing the massive shortcomings in the WP
architecture here is what prompted the SP_Posts class, which does offer
consistent methods for creating and updating posts.
3. Dealing with only form display is myopic: the form must submit somewhere,
and the most common and easiest place for that submission to be handled is on
the page that generates the form. So data validation must be handled at the
same time, especially when you are exposing forms to the public.
My plan here was to add a button to the TinyMCE editor, pop a thickbox, and let
the user make selections as to what kind of form to generate. A simple version
would allow the user to select a post-type, more thorough implementations could
involve styling options etc. The pieces are already there, it's just a matter
of integrating them.Original comment by ever...@fireproofsocks.com on 1 Sep 2012 at 2:49
GoogleCodeExporter
commented
9 years ago Re: 1. I probably shouldn't have used the term "Master template file". What I
meant was simply generating stock templates that require only minor
modification so that users can easily just generate a new template if they
change the data...
By template file I'm talking about WP Templates for pages. As in the case of
single-custom_post.php I may have not been clear. But what I was talking
about is generating a WP page template with an html form on it and appropriate
CSS tags.
Re: 2. Ok, I didn't realize there was such a problematic limitation in WP. Is
this partly due to the AJAX nature of post/page creation? One of the reasons I
always harp on overengineering is because its so common to see applications
with lots of "features" but no coherency in the foundation and pretty soon
you've got unrepairable junk. It looks like WP falls victim to that here...
no??
Re: 3. Given the limitation described in 2, I can see why you're saying dealing
with form display is myopic. However, if limitation 2 did not exist, I would
disagree.
A form and the code that receives and processes it are completely independent
things and SHOULD BE thought of as such to AVOID security problems. A good
approach to secure programming is to assume any data you receive could be
anything and could come from anywhere. Take the form out of the equation. It
also makes it easier to conceive the framework.
You're saying the most common and easiest place to handle submitted data is in
the same page that generates the form. Is it common? Yes. Is it easiest? I
don't know how so many people have arrived at that conclusion. I think it
complicates matters since now you're dealing with user experience and UI, data
acceptance, and data validation and storage all in one giant chunk.
To me it makes far more sense to use the conventional rapid application
development approach where you focus on defining data classes. Then you use
piecemeal sections of code to specialize on interactions with those data
classes. One section of code generates a stock form. One section accepts data
and stores it and a subsection can be called ot validate the data before
storage.
From what you're saying, it seems like the perspective you have stems more from
WP and ill-conceived frameworks.
But I could very well be the one who is in error. I'm certainly no database
programming guru.
I'll take a look at GetPostsForm and some of the other things you've mentioned.
Original comment by pha3...@gmail.com on 1 Sep 2012 at 5:26
GoogleCodeExporter
commented
9 years ago I looked at GetPostsForm and it doesn't seem to be the same thing as we're
talking about. The file comment says:
This class generates search forms that act as a graphical interface to the
* GetPostsQuery->get_posts() function.
Its for running a query to view a list of posts. I was talking about
generating basic blank forms that users would fill out when creating a new
custom post. And, then, extending that to automatically populate the form
values with values of an existing post in the case of making an Edit to the
post.
I still stand by what I said before. There's no reason to think of form
output/display as directly linked to form data reception and processing. Even
if you output an HTML form and populate it with all the existing values of
Post53 (so the user can edit Post53), the code that receives a submission for
edited data for Post53 still has to assume this submission is completely
foreign and could have come from anywhere. The two operations are independent
and should be coded as such.Original comment by pha3...@gmail.com on 1 Sep 2012 at 5:42
GoogleCodeExporter
commented
9 years ago Re WP limitations: there are many. It's not a framework by most definitions...
it's code by committee with many poorly conceived contributions. The lack of
certain API functions has nothing to do with Ajax, it's probably just the usual
oversights of amateur developers that tend to plague open-source projects.
Again, form generation is a complex and vastly complicated project. I'd like
to see something workable implemented for this particular ticket (which I think
would satisfy your request), and broadly speaking, I think most of the pieces
are already there since I'm already generating partial forms inside the WP
manager (i.e. the custom fields).
I've tried to make the CCTM follow sound architectural principles, keeping to
MVC as closely as possible and I've tried to keep up on my unit tests so that
the whole thing has sensible coherency and code patterns that other developers
would recognize, but any software project has flaws and oversights.
Re stock templates: yeah, that's an easy modification if you want to use
variants of the single-xxxxx.php template, just please file a feature request
for that explicitly since the sample templates for the single-xxxx.php theme
files is a different feature request.
Security is a broad topic, but to keep the discussion germane to the issue: the
form and the "listener" are usually tightly bound, often on the same page, and
usually following a design pattern like this:
if (!$submitted) {
// display form
}
else {
// process form submission
}
That's the rule in the WP manager (and many other frameworks) rather than the
exception, and with good reason: it leads to an economy of code, and more
pragmatically, it makes the task of repopulating the form and displaying
error-messages that much easier. So yes, of course the form and the listener
exist in separate parts of the code, but most often you see them married
together in something like the above. I don't want to debate you on
architectural philosophy or design patterns, however: this is a bug and feature
tracker not a forum for airing opinions, and this discussion has already
strayed from the original feature request. If you've got a project and a
budget, I can implement features to your specs, otherwise, please keep the
tracker to the standard stuff: steps to reproduce issues or the listing of
details specs for features.Original comment by ever...@fireproofsocks.com on 2 Sep 2012 at 6:03
GoogleCodeExporter
commented
9 years ago Basic form is working. Requires testing before release of 0.9.7.1. See
https://code.google.com/p/wordpress-custom-content-type-manager/wiki/cctm_post_f
orm for limitations due to security concerns.
Committed revision 682783.Original comment by ever...@fireproofsocks.com on 16 Mar 2013 at 7:57
GoogleCodeExporter
commented
9 years ago This will go live in 0.9.7.1.Original comment by ever...@fireproofsocks.com on 21 Mar 2013 at 12:31
Original issue reported on code.google.com by
fireproofsockson 24 Jul 2011 at 4:09