Shortcode to generate post-creation form to end-user

[GoogleCodeExporter]

It'd be cool to allow users on the front-end to be able to submit their own 
posts (using custom content types).  See this plugin: 
http://wordpress.org/extend/plugins/ucan-post/

This is almost possible using the Summarize Posts plugin (which is being 
integrated).  I'm imagining a shortcode that would generate the form -- there 
should also be a custom tpl somewhere so that the editors can control how the 
HTML looks.

Original issue reported on code.google.com by fireproofsocks on 24 Jul 2011 at 4:09

[GoogleCodeExporter]

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]

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]

[deleted comment]

[GoogleCodeExporter]

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]

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]

Thanks for the link -- I'll look at this for comparision.

Original comment by fireproofsocks on 14 Aug 2011 at 8:13

[GoogleCodeExporter]

Original comment by fireproofsocks on 3 Sep 2011 at 5:23

• Added labels: Milestone-Release0.9.5

[GoogleCodeExporter]

Original comment by fireproofsocks on 10 Nov 2011 at 7:39

• Added labels: Milestone-Release0.9.6
• Removed labels: Milestone-Release0.9.5

[GoogleCodeExporter]

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

• Added labels: Milestone-Release0.9.7
• Removed labels: Milestone-Release0.9.6

[GoogleCodeExporter]

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]

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]

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

• Changed state: Accepted

[GoogleCodeExporter]

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]

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]

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]

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]

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]

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]

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

• Changed state: InProgress

[GoogleCodeExporter]

This will go live in 0.9.7.1.

Original comment by ever...@fireproofsocks.com on 21 Mar 2013 at 12:31

• Changed state: Fixed