Define post-types using extendable PHP classes

[GoogleCodeExporter]

What functionality do you want to see?
Instead of using the database for custom post types i would like to see a 
generated php file that takes care of the Post-type the metaboxes and jadda 
jadda

You still can have them im the database in order to generate them, but having 
them hardcoded (ie rendered to a php file) would increase performance and 
stability.

Another upside of those kind of files is that one could create another function 
in that file in order to ie. display the different columns in the admin 
"overview"

Next Upside would be the exportability which then is guaranteed.

BTW what i also would like to see is a community page where we can contribute 
(i.e. share Post types etc)

Thanks for your work, you are really doing a good job

Do you have examples of similar functionality on other sites or in other
plugins? (Please share URLs below)
well about any theme using post types for something ^^

Original issue reported on code.google.com by googleac...@vision-network.org on 4 Oct 2011 at 11:14

[GoogleCodeExporter]

Thanks for the note.  Yes, some of these things are already planned: a sharing 
page is planned (I'm still trying to find a pastebin-type service that offers a 
usable API for this and find some time to build out the http://wpcctm.com/ 
site).  Customized columns is slated in issue 53, customized metaboxes are 
slated in issue 34.  You're right though: a PHP file would offer a more 
familiar method of customization.  My concern is that PHP files are more 
vulnerable to exploits -- It's really easy for me to export and transport the 
JSON definition files because they don't ever execute.  The other concern is 
with the speed: actually including multiple files (e.g. one for each registered 
post-type) would certainly be _slower_: everything the plugin needs it gets 
with one database query from the wp_options table, and that table is indexed on 
the option_name, so it's a fast query.  Some of the directory scans are cached 
in order to increase speed -- this approach is certainly faster than including 
files repeatedly.

But I do like your idea... it matches up EXACTLY with the other things I'm 
doing for this plugin: I've created abstract PHP classes for both Custom Fields 
and for Output Filters.  I haven't documented all of this yet, but essentially, 
if you want to create your own type of Output filter or your type of custom 
field, all you have to do is implement a PHP class and store it on your site 
and BOOM, you've got a new type of custom field or a new type of output filter. 
  The idea there is to build up a way to share these components too.

This same approach could be used when defining post-types, but it could simply 
be a normal class (instead of an abstract one) with the default functions 
handling standard behavior, but if you extended the class for a given 
post-type, you could override the behavior.  THAT would be cool.  I just gotta 
think about the structure a bit more...   the only downside I can see to this 
would be the exporting/importing feature would get more complex.  The current 
idea is that I can highlight any custom output filters or new custom field 
types when you import a definition, and if detected, I could provide a link 
back to the sharing page where users could download the "extras".    I could do 
something similar if there were PHP classes extending base functionality.

The other related issue there would be the ability to export your templates 
with the definition: if you've customized your templates to display a very 
specific set of content, then it'd be helpful to include that template for 
others when you share the definition.  But I don't want to be another theme 
site -- I added a link where users could specify the URL of their custom 
template, and I'll be adding support for including a definition with a template 
(see issue 170).  

Anyhow, this is a good idea... there's just a lot to think about.

Original comment by fireproofsocks on 4 Oct 2011 at 3:07

• Changed title: Define post-types using extendable PHP classes
• Changed state: InReview
• Added labels: Type-Enhancement, Priority-Medium

[GoogleCodeExporter]

Well i have given this some thought now and whilst i have to agree that 
querying might be a good way to do this, the downside is that it maybe not 
recognized system wide, like some plugins may hav problems with "virtual 
post-types" also querying always takes up more memory since you are 
constructing the "function ón the fly" with values from the database, that can 
never be quicker than the requiredment of a file because they are in fact 
constants when they are loaded.

Anyway as far as Templating is concerned, i would just put a message in the 
admin header which informs the user that "you have not imported/created  the 
templase for you custom Content Typ "bla" yet, click here to import the default.

Now what i think should be done is only to change the output format of the 
core: i.e. that content types get generated on runtime. Why? because they 
rarely change and if they do they do so over the admin interface which means 
that we can have a "heavy backend" that generates the PHP file for us. You may 
be right that having multiple files for multiple content_types is overkill, but 
we can merge them all into one. And still use the Json exporter for "sharing".

what iam thinking of is Code Templates. Which could look like this:

###########
## Post-type-definition
add_action('init', 'portfolio_register');    

function {POSTTYPE}_register() {  
    $args = array(  
        'labels' => $labels,  
        'public' => {opt_public},  
        'show_ui' => {opt_public_show_ui},  
        'capability_type' => '{opt_cap_type}',  
        'hierarchical' => {opt_hierarchical},  
        'rewrite' => {opt_rewrite},  
        'supports' => {opt_supports}  
       );    

    register_post_type( '{POSTTYPE}' , $args );  
}

## Admin Col ##
add_action('manage_{POSTTYPE}_posts_columns', 'posts_column_{FieldName}', 10);
add_action('manage_{POSTTYPE}_posts_custom_column', 
'posts_custom_column_{FieldName}', 10, 2);
function posts_column_{FieldName}($defaults){
    $defaults['post_{FieldName}'] = __('Hello World');
    return $defaults;
}
function posts_custom_column_{FieldName}($column_name, $post_id){
    switch($column_name) {
        case 'post_{FieldName}':
            echo {Formated template}
            break;
    }
}
### Meta Box ##
function show_meta_box{fieldname}($post) {
    echo '<input type="hidden" name="meta_box{fieldname}_nonce" value="'. wp_create_nonce('{fieldname}_nonce'). '" />';
    -> Get Item Wrapper
        -> Render item Template according to Type i.e.: <input type="text" name="_{FieldName}" id="{FieldName}" value="<?php echo get_post_meta($post->ID, '{FieldName}', true)?>" /></td
}
## save metabox function ##
## Actually i think we possibly could handle all custom field savings through 
this format i.e. foreach Customfield -> save ##
function save_my_meta_box($post_id) {
    // check nonce
    if (!isset($_POST['{FieldName}_nonce']) || !wp_verify_nonce($_POST['{FieldName}_nonce'], '{FieldName}')) {
        return $post_id;
    }

    // check capabilities
    if ('post' == $_POST['post_type']) {
        if (!current_user_can('edit_post', $post_id)) {
            return $post_id;
        }
    } elseif (!current_user_can('edit_page', $post_id)) {
        return $post_id;
    }

    // exit on autosave because we dont do that
    if (defined('DOING_AUTOSAVE') && DOING_AUTOSAVE) {
        return $post_id;
    }

    if(isset($_POST['_my-awesome-field'])) {
        ### possible Check if Data needs some special Data options (multidemensional arrays bla bla )
        update_post_meta($post_id, '_my-awesome-field', $_POST['_my-awesome-field']);
    } else {
        delete_post_meta($post_id, '_my-awesome-field');
    }
}
add_action('save_post', 'save_my_meta_box');
######

Now this is just a draft so done blame me if it doesnt work out of the box ;)

Original comment by googleac...@vision-network.org on 5 Oct 2011 at 10:26

[GoogleCodeExporter]

also this guy has another dynamic metabox approach one could simply "render to 
php":
http://www.wproots.com/ultimate-guide-to-meta-boxes-in-wordpress/

Original comment by googleac...@vision-network.org on 5 Oct 2011 at 10:31

[GoogleCodeExporter]

I'll consider this.  What you're recommending is really a change in the "Model" 
component of the MVC stuff here.  I'm not sure what you mean by 
"virtual-post-types".... It's nearly impossible to make custom post-types play 
nice with any other plugin... part of that is simply because WP doesn't have a 
storage model built-in for these definitions like Expression Engine or MODx do, 
instead, each plugin has to design its own storage method for these 
definitions.  I suppose the only sure-fire way to know whether a single 
database query is faster or slower than including multiple files would be to do 
an A/B test... but I strongly suspect it's splitting hairs here.

The downside to printing out definitions to a file are many however: you run 
into permissions problems on many servers, whereas the database permissions are 
already established and maintained.  Also, PHP sucks for testing for syntax 
errors *before* loading a file, so this makes it difficult to do custom 
developments like this.

I still think this is a good idea, but I really have to give it some deep 
thought as to how to best implement it.  I think I'd probably lean towards some 
middle ground: maybe by default read data definitions from the database (like 
it's doing currently), but also look for "override" files and run those files 
if they exist.  Something like that.  It probably could be handled in a way 
that's agreeable to many people by running these events through WP's actions.

Original comment by fireproofsocks on 5 Oct 2011 at 3:20

[GoogleCodeExporter]

Dammit, this type of thing just bakes in my brain and I can't stop thinking 
about it. ;)  

I'm still leaning towards extendible PHP classes where the parent class does 
the default action (e.g. read the definition from the database), but if you 
create a child class, you can override that behavior, e.g.

class CCTMPostType {
   function get_post_type_definition($post_type) {
      // read from the database as in current implementation
   }

}

// in your own file somewhere:
class my_post_type extends CCTMPostType {
    // override the parent's implementation:
   function get_post_type_definition($post_type) {
      $args = array(  
        'labels' => $labels,  
        'public' => 1,  
        'show_ui' => 1,  
        'capability_type' => 'post',  
        'hierarchical' => 1,  
       // etc...
       ); 

      return $args;
   }
}

Any actions that we identify could be overridden using standard PHP 
parent/child classes.

I'm thinking the following functions could be implemented in this type of setup:

 * get_post_type_definition($post_type)
 * draw_meta_boxes
 * print_custom_field($fieldname)
 * define_columns($post_type)

Probably others here, but I think those are  the main ones.  Ultimately, my 
goal here is to have an architecture that a non-technical user can use and 
customize without any peeking under-the-hood, but also have the architecture be 
completely customizable for developers/coders.  

Keep up the good comments!  It's really got me thinking! 

Original comment by fireproofsocks on 5 Oct 2011 at 3:48

[GoogleCodeExporter]

I see what you mean and it makes totally sense but on the other hand if i have 
to extend some class in order to get the post-type to work properly,  wouldn't 
i have written the post-type by hand afterall?

The only upside that is left then is that, once i change themes, the 
contet-types will still be there but well one could have "written a plugin" for 
that cause then.

i think the point of the exercise should be to have it nice and easy to 
configure (which your interface is on the best way to) and then, once 
everything is done generate it to the fastest possible result, which imho still 
is the php file. sure caching and what not do facilitate things but in the end 
thats gonna do more good than harm (stuff partially not updated, not sync, bla)

And lastly what i have been thinking bout alot is the fact, that those content 
types dont change. welll at least rarely. I sure get your point about files 
being "funny" and thus crashing the wordpress theme, but i think post-types are 
trivial enough in order to break em down into generated php functions which 
would act more like inbuilt
post-types (btw we should find out what differenciates a custom post-type from 
a built in one so we effectivly could move post-types more to the core)

In the end it will all come done to presets anyway... i have been thinking 
about it and actually "developing" content types once will mostly be enough... 
or how many datamodels could a book-store possibly have?.. i know millions... 
but how many of those actually make real sense? hmm i dunno...

Oh yeah and i found this: http://yoast.com/custom-post-type-snippets/ you 
prolly gonna like it if you dont know it already ;)

thats it for now,
best wishes,
Joe 

Original comment by googleac...@vision-network.org on 5 Oct 2011 at 6:26

[GoogleCodeExporter]

I'm not so worried about speed yet... who's the developer guru who was quoted 
with something like "premature optimization is the root of all evil"?  It'd 
really take an A/B test to know which method was faster... unfortunately I 
don't have a dedicated server where I could realistically test that.  I'm more 
concerned with ease of use and ease of development for now.

Nice link @ yoast.com. 

Original comment by fireproofsocks on 5 Oct 2011 at 6:35

[GoogleCodeExporter]

in the end, what iam talking about is nothing else then printing a template 
like you do already with the default template =)

but okay...
here for ease of development:
http://www.wproots.com/ultimate-guide-to-meta-boxes-in-wordpress/ ;)

Original comment by googleac...@vision-network.org on 5 Oct 2011 at 6:42

[GoogleCodeExporter]

Yeah... I thought about the sample template as a point of comparison.  That 
works easily because it never has to update that text.  It's just one-way.  
I've tried to write that file and I ran into permissions issues on many 
servers, so I just let the user copy and paste.  It'd be possible to generate a 
class file in the same way, and that's what I was thinking for this... I just 
don't want to *force* users to have to create a PHP class because that will 
alienate a lot of users.  Maybe it could be used as a way to prime the pump on 
creating a child class. 

Wow, that's a great link re metaboxes!  

Original comment by fireproofsocks on 5 Oct 2011 at 7:01

[GoogleCodeExporter]

hmm the further i investigate the more a self-coded approach to custom 
post-types seems to be the way to go... for example: 
http://code.hyperspatial.com/1367/custom-post-types-on-right-now-dashboard-widge
t/ this shows all the custom post-types in the dashboard widget and it actually 
works, but not for the "virtual custom post types" you are creating. it just 
cant function througha generated class (the way your doing it) because of the 
underlaying pipline. Theme Content-types > virtual content types because they 
actaully get shown. Maybe thats because you are coding a plugin?!? i dunno WP 
is strange... 

Anyway i think the best way of doing this is hardcoding em once and using em 
over and over again or maybe have the plugin create a theme php file but that 
might not work as you pointed out. well its weird but it seems like thats the 
way to go :/

Original comment by googleac...@vision-network.org on 6 Oct 2011 at 10:49

[GoogleCodeExporter]

hmm it seems like custom-post-type ui already supports this functionality

Original comment by googleac...@vision-network.org on 6 Oct 2011 at 1:27

[GoogleCodeExporter]

I don't mind the possibility of custom coding, but if it's required, that sort 
of defeats the purpose of the plugin.  If you want a "self-coded" approach, 
then you could code the entire post-type, e.g. each as a separate plugin 
(granted, that would miss out on the standardized custom fields and UI etc).  
So it's imperative that no coding is required -- any custom coding would have 
to be strictly optional.  Again, I'm open to this as an option, but I'll never 
force this as a requirement because it would alienate the majority of users.  
Creating an optional child class to override the standard behavior would give 
you full flexibility to handle the mechanics of the definitions or printing 
etc. in whatever way you wanted -- I could even print up a sample child class 
just like in the template samples.  It'd give you the same type of flexibility 
as using WP actions to intercept parts of the behavior.

The Custom Post-Type UI plugin is fatally flawed because it stores field data 
as taxonomical terms instead of as meta data.  That runs against sensible 
development and more importantly, it runs into database limitations because the 
taxonomy tables store VARCHAR's with a limit of 255 characters per field value, 
whereas meta data uses TEXT fields which have a limit of pages and pages of 
data.  In other words, the Custom Post-Type UI can never really support 
WYSIWYG, textarea, or long array fields, so it offers only a marginal 
improvement over WP's reliance on simple text fields.

I'm not sure I'm following what you're saying regarding the "Right Now" widget. 
 You can print that data in the dashboard listing (this would make a great 
feature request).  The problem with the example on 
http://code.hyperspatial.com/1367/custom-post-types-on-right-now-dashboard-widge
t/ is how it uses WP's get_post_types() function.  The arguments to WP's 
register_post_type() function are sophomorically insane, so the example there 
fails if you don't define your post-types as "public" and instead you verbosely 
define them to "show_in_menu" instead.  So depending on how you define them 
determines how you have to query for them (it's a really bad way WP has 
implemented this). The "Right Now" listing make a good feature request, and all 
it would take would be a bit more thorough querying on the defined post-types.  
This example is a good point of how it makes zero difference in how you store 
your definitions: WP doesn't care.  Any custom post-type plugin is relying on 
the same register_post_type() function to do all of this stuff.  

In other words, changing the behavior of the "Right Now" widget has to do with 
changes in the controller or view layers of the MVC design pattern, so the 
question of where the data came from (i.e. the model) is entirely arbitrary -- 
it wouldn't matter if the definitions were stored in the database or in 
classes: once they're registered, they can be queried.  

There is no distinction in WordPress between built-in post-types and 
custom-post types: all of them are registered using the same function, just 
post and page types set the "_builtin" option.

Original comment by fireproofsocks on 7 Oct 2011 at 4:41

[GoogleCodeExporter]

Feature request:
http://code.google.com/p/wordpress-custom-content-type-manager/issues/detail?id=
200

Original comment by fireproofsocks on 7 Oct 2011 at 4:43

[GoogleCodeExporter]

Well to be honest with you, i wasnt trying to offend you that "their way is 
better or bla" im still here. I like your plugin and the approach you are 
taking, when generating custom post types. I really do and i understand that 
rendering the stuff to php is mere "template processing".

I have a c# bg and im worried about memory and performance, thats all. The way 
wordpress is wirriten kind of scares me and as far as i recon, custom post 
types still use the default table in the datbase which is kind of scary. I have 
checked out Pods cms which creates own tables for each custom post type, which 
memory wise makes sense, but their overhead is even more gigantic.

Im trying to move my clients from my custom c# environments to Linux cauz its 
cheaper and wordpress is just the easiest to handle for all of em, so basically 
im just  trying to create a rock solid foundation and go from there.

Btw yesterday i found this: 
http://www.twothirdsdesign.co.uk/article/2010/03/setting-templates-for-wordpress
-3-0-custom-post-type/ and this 
http://www.greenorangestudios.com/2010/05/27/custom-post-type-template-redirect-
the-right-way/

what i was thinking is generating a default scenario (the preview) into a tpl 
file in the plugin folder with a notice "in order to change this template copy 
it into your themes folder and change whatever you like"

btw n1 with the start Dashboard,=)

Original comment by googleac...@vision-network.org on 7 Oct 2011 at 9:01

[GoogleCodeExporter]

Sorry if I sounded defensive, I didn't mean to  -- I need a better filter on my 
mouth.  I really appreciate your insights and helpful links!  

Oh man, the way WP is written is shocking to me at times.  Its architecture is 
so limited that I'm surprised it is as popular as it is.  I'm more of a MODx 
fan, but WP is easy to work on, quirks and all (kinda reminds me of a VW Beetle 
-- you only needed a wrench and screwdriver to work on it).  MODx does about 
90% of what this plugin does out of the box... it's UI is just a bit rough, and 
sometime I'd like to make a MODx counterpart with some of the CCTM features 
like importing/exporting definitions.  It'd be a lot easier in MODx because it 
uses a much more mature architecture (i.e. fewer surprises/conflicts).

Yeah, I've been fascinated by how different CMS's handle custom fields.  MODx, 
Drupal, and Expression Engine all store the definitions in their databases, so 
it's a global recognized way of storing the definitions.  Expression Engine 
used to (still?) modify the table structure, which does make for much easier 
reporting, but you can end up with some very wide tables and lots of null 
values.  I tend to like that approach better though: the whole idea of having 
multiple rows in a related "wp_postmeta" table that all point back to a single 
row in the "wp_posts" table just causes a lot of trouble, e.g. 
importing/exporting content or writing reporting queries become increasingly 
difficult -- I did manage to get a list of posts and all of their custom fields 
using a single query written for my Summarize Posts plugin, but it does require 
more from the database to perform the concatenation in that query. MODx has a 
"scaffolding" type feature that abstracts the database entirely, so it can 
create custom data models for any type of content without you having to do any 
of the create table statements.  That's pretty  amazing, but it's also kind of 
scary since my skills at MySQL are a lot better than my skills at knowing 
MODx's scaffolding behavior. Anyway, that's a topic I could visit over and over 
again.

Nice links for the templates.  Here's where I miss the MODx templates the most. 
 I really have a hard time swallowing the repercussions of having executable 
code in my view layer... it grates against my MVC sensibilities.  It's awful 
that a WP template can get hacked -- that shouldn't even be possible in my 
mind.  What I'd like to do here is to integrate/absorb the functionality of the 
"Cucstom Post Template" plugin -- 
http://wordpress.org/extend/plugins/custom-post-template/ (see issue 19).  It 
opens the door on how a CMS templates "should" be in my opinion: you can select 
any template file you want to display any particular post or page.  By default, 
you can only do that for WP pages, but that's so limited.  And then I'd like to 
implement support for generating an entire WP them (as per issue 129): the idea 
being that the user could click a button and have a fully functional 
starter-theme instead of having to copy/paste the sample code from the sample 
templates for each content type.  I could use improved functions for iterating 
over posts and I'd leave the functions.php file empty if possible -- I really 
want the View layer to be as dumb as possible because it avoids confusion and 
avoids security holes.

BTW: The dashboard thing has been implemented and it's on the dev branch (SVN 
is always fresh... I'm having some problems with my build script, but the zip 
is @ http://wpcctom.com/cctm-dev.zip) ... I'm debating whether I should add a 
setting that enables/disables that feature.  Seems like every time I implement 
a feature, it has unintended consequences.  I guess that's the nature of 
software development, but WP and it's event-driven architecture seem 
particularly squirrelly.

Original comment by fireproofsocks on 7 Oct 2011 at 3:26

[GoogleCodeExporter]

well i see what you mean by MVC pattern but remember that WP itself is not MVC 
and prolly never will be ;) ... i have been on c# MVC for ages and i really 
miss it but wel... im currently on the PHP is "cheaper" and wp templates cost 
only 35 bucks bandwaggon ^^

I think in the end we will figure this out and since the way wp caches pages 
(or the plugins that do for that manner) we can worry about the backend 
overhead later.. so my concerns about that are limited 

But i started picking up on your code and am currently working on custom 
Metaboxes and i think i got that solved with a snippet of mysql.. ill let you 
know how things turn out ;) if you wann get in touch just drop me an email or 
send me some IM contact over that. Im using Aim/icq/msn/skype ;)

Original comment by googleac...@vision-network.org on 7 Oct 2011 at 3:37

[GoogleCodeExporter]

just realised that you use serialized data in the wp_options table.. can do ;)

Original comment by googleac...@vision-network.org on 7 Oct 2011 at 3:48

[GoogleCodeExporter]

meh... i just realised why i hate php so much ;)

Original comment by googleac...@vision-network.org on 7 Oct 2011 at 4:59

[GoogleCodeExporter]

Cool!  I'm on skype @ fireproofsocks. 

Yeah, the WP options functions handles the serialization of the data 
automatically.  update_option, add_option, get_option, etc. all integrate with 
that automatically.  

I have another WP project that requires that I get a repeatable custom field 
built, but I'd like to get the metaboxes thing implemented (see issue 34).  I 
think the  best way to do it from a UI perspective would be to generate an HTML 
form that grabbed all the values the metabox function required.  Then there'd 
have to be a way to choose which metabox a custom field displayed in.... 

Original comment by fireproofsocks on 7 Oct 2011 at 5:09

[GoogleCodeExporter]

isnt that just Jquery  + a Serialised hidden field?

i added you, but dont be shocked cause i allready wrote some of my thoughts 
down that i want to discus with you ;)

Original comment by googleac...@vision-network.org on 7 Oct 2011 at 6:43

[GoogleCodeExporter]

I got your Skype, thanks.  Instead of killing custom fields entirely, I think 
the way to do this is so it's scalable and flexible is to normalize the data 
objects so you can freely associate between them.  So I'm thinking the 
following:

1. Define metaboxes -- by default, there will be the one for custom fields in 
their traditional place, but if we create an interface where users can create 
any type or number of meta box, then we  can use them later...
2. Allow any custom field to associated with any metabox.  So when you define a 
custom field, you can choose where it should live... it's pretty much the same 
association type of thing that is now being done to associate custom fields 
with a post-type.  

It is more click-work (which I don't like), but it is much more flexible to 
maintain object and then join them, much in the same way that you have in a 
database with primary and joining tables.  I think you could just lean on the 
default behavior (which is more or less what's in place now), but for the 
curious types, you could let them define their own metaboxes and edit which 
fields show up in each.  And, let all of that be overridden optionally by the 
PHP class.

Original comment by fireproofsocks on 7 Oct 2011 at 8:56

[GoogleCodeExporter]

well im sorry to say, but if im developing my own metabox as a user, what is 
stopping me from doing the same with the post-type? it really are just a couple 
lines of code more.. plus there are a few "frameworks" that help me do so from 
code as well 

the second problem with the current approach is that all other custom fields 
are gone unless i specifically add em through this plugin. I know they are 
still there and i just cant acces em, but what about everybody else?

to point 2: well you cant just assosiate a custom field to a metabox, you can 
only have the save operation store the value in one. at least in the way i 
understood the api in the docs of WP

and truthfully i think all plugins that use custom fields, do so over meta 
boxes as it is just more user friendly.

Plus what are the advantages of registering a custom field, besides it showing 
up in the custom field dropdown compared to the metabox anyway? ;)

Original comment by googleac...@vision-network.org on 7 Oct 2011 at 9:22

[GoogleCodeExporter]

or we go overkill with mysql prepared statements and transaction using the 
godfather of designs ;) 
http://www.databaseanswers.org/data_models/father_of_all_models/index.htm

Original comment by googleac...@vision-network.org on 7 Oct 2011 at 10:58

[GoogleCodeExporter]

If you want to do all that work, then of course you can code your own plugin 
for it.  This can't possibly be all things to all people, but I don't get the 
feeling that you understand the architecture of what I'm trying to build here.

Remember that metaboxes are *already* involved: all custom fields are already 
being printed in a metabox that the CCTM plugin defines -- it just is a metabox 
of the same type that WordPress uses for the same purpose. It's easy enough to 
add other metaboxes and print other custom fields in other boxes and it's 
*completely* possible to associate a custom field with a metabox as I said 
before.  You can just say "Custom Field A prints in Metabox B, Custom Field C 
prints in Metabox D" etc. etc. etc.... the only thing a metabox does is it 
handles is the visual placement of the form element, but the form doesn't care 
where the elements are, it simply posts to the $_POST array, so it will work 
fine that way, regardless of what the API docs say.  Metaboxes are nothing more 
than eye-candy: they affect the layout, they in no way affect functionality.

Custom fields are standardized on purpose: WP's architecture here is awful, so 
the CCTM rescues WP from its own stupidity and allows for easier templating.  
WP completely paints itself into a corner by allowing non-unique field names.  
There is a feature request to let users add additional custom fields or keep 
others defined with other plugins (see issue 7) -- it's dangerous to do that 
because of WP's bad architecture, but I think it's a fair to give people the 
benefit of the doubt and assume they know what they're doing.  I feel like 
you'll understand what I'm trying to do better once you see it.  

Original comment by fireproofsocks on 8 Oct 2011 at 3:17

[GoogleCodeExporter]

well to be fair i actually understand what you are doing as i have read your 
code pretty much entierly.. i just dont see the benefit of it. What your doing 
now is "deactivating" custom fields inexchange for your own:
    /*------------------------------------------------------------------------------
    Remove the default Custom Fields meta box. Only affects the content types that
    have been activated.
    INPUTS: sent from WordPress
    ------------------------------------------------------------------------------*/
    public static function remove_default_custom_fields( $type, $context, $post ) 
    {
        $content_types_array = CCTM::get_active_post_types();
        foreach ( array( 'normal', 'advanced', 'side' ) as $context ) {
            foreach ( $content_types_array as $content_type ) {
                remove_meta_box( 'postcustom', $content_type, $context );
            }
        }
    }

and this is where you are going wrong in my humble opinion.

I know your rock solide approach to this but the only way to get my "other 
custom fields" back is to either implement them into your types or to 
deactivate the plugin i know it makes sense from a dev perspective, but there 
is literally no benefit from a custom field vs a custom meta box, only that you 
are making your life harder then it is.. furthermore you are right that you 
eventually will get to that in issue 7 but thats just another hack to have the 
WP architechture please your coding style

If this would be a rock solide framework we are working with i would agree with 
you completetly. If this would be an asp.net c# app i would be with you but its 
not. Its php its a scripting language...

Furthermore whats the difference if your plugin is rock solid when the rest of 
WP just stays the same?

Trust me i made up my mind about this and i even have sketches for your 
approach here and it just doesnt feel right. One would have to define the type, 
then to define the fields and then assosiate em with a custom Metabox but why 
the hassle? For all i know the user wants his type to be working and easy to 
acces thus creating the metabox right after creating the type.

Check this out: http://www.farinspace.com/wpalchemy-metabox/

furthermore the way metaboxes are set up you would need to hack the following:
<?php
    public static function create_meta_box() {
        $content_types_array = CCTM::get_active_post_types();
        foreach ( $content_types_array as $content_type ) {
            //get MetaboxesName For Custom Post-type
            //get Fields for Metabox then foreach metabox ->
                        // check what type it is, get the right callbacks (textbox bla) 
            add_meta_box( 'cctm_default'
                , __('Custom Fields', CCTM_TXTDOMAIN )
                , 'StandardizedCustomFields::print_custom_fields'
                , $content_type
                , 'normal'
                , 'high'
                , $content_type 
            );
        }
    }
    // and the  storage prolly would look something like this:
    array(
    'title' => 'Custom meta box 1',
    'Content_Types' => array('post', 'page', 'link'), 
    'context' => 'normal',
    'priority' => 'high',
    'fields' => array( 'fieldid1','fieldid2')

    )

    ?>
as opposed to creating the box directly, keeping the regular custom fields 
(used by like every themecreator out there), not having an additional "add 
metabox" tab where the user just enters a Name and finally the thought of just 
adding a "box" is is an easier context to grasp

Original comment by googleac...@vision-network.org on 8 Oct 2011 at 10:09

[GoogleCodeExporter]

Right: you HAVE to remove the default meta box, otherwise both the plugin and 
WP draw the custom fields and when you submit the form, you would get conflicts 
in the $_POST array, e.g. 

     <input type="text" name="my_field" ... /> <-- CCTM's version of the field
     <input type="text" name="my_field" ... /> <--- WP's version of the field = Conflict!!!

So you must remove the metabox or otherwise prevent the duplicate versions of 
the field.  It's not just "to please my coding style", it's a reality of array 
keys.

The other thing that the plugin offers is the various types of custom fields: 
dropdowns, checkboxes etc.  WP doesn't offer that.  The Custom Fields are a 
completely customizeable -- it's not documented yet, but any 3rd party can 
write their own types of custom fields.  WP can't do that. 

The point is that you have to draw the custom fields somewhere -- the metaboxes 
are nothing more than a visual grouping.  You can't just let the user define a 
metabox and be done with it.  They don't store information, and I disagree that 
the concept of custom fields is somehow confusing.  Metaboxes have zero effect 
on functionality.  You have to print the fields somewhere, and yes, the  
create_meta_box() function is where that happens -- I'm suggesting that the 
create_meta_box() function gets moved into a new overridable class that draws 
one or more metaboxes based on what the user has defined, and prints the 
appropriate custom fields in each.  The storage array you sketched out infers 
those exact type of associations that I've been mentioning all along: you have 
to link the field and the metabox, or the metabox and the field -- the point is 
the data gets joined, and in the end you get the result of having custom fields 
printed in a metabox.

I'd recommend that you let me code up a new version of this so you can see how 
it fits together and then we can review it.  Sound good?

Original comment by fireproofsocks on 8 Oct 2011 at 5:16

[GoogleCodeExporter]

"    <input type="text" name="my_field" ... /> <-- CCTM's version of the field
     <input type="text" name="my_field" ... /> <--- WP's version of the field = Conflict!!!" 

yes that is because it is a registered custom field, thats why you can create 
metaboxes without having the custom field defined

"The other thing that the plugin offers is the various types of custom fields: 
dropdowns, checkboxes etc.  WP doesn't offer that." yes and those are metaboxes 
not custom fields. customfields are hackable textboxes for template layouts.

"The point is that you have to draw the custom fields somewhere -- the 
metaboxes are nothing more than a visual grouping" Yes they are and that is the 
point. You are stil l saving to the same Postmeta id, but you dont have to 
register it, which means no conflict as mentioned above.

"I'm suggesting that the create_meta_box() function gets moved into a new 
overridable class" who is going to ovverride all those clases you are talking 
of? its not like there is an infinite number of Content types, but the ones in 
use you can count with two hands. Plus if someone wanted that, WP-Alchemy and 
other frameworks offers the most flexibile solution to that with their tpl 
enginge and what not.

"The storage array you sketched out infers those exact type of associations 
that I've been mentioning all along" thats because its meant to be your 
association model ;) the buzzword here is complexcity. The way all options are 
stored in a serialized array makes filtering by content type extremly 
difficult, keep in mind that they get added again in each request, i just dont 
think its worth the overhead.

Don't get me wrong, i think i understand your approach and the benefits of it, 
im just thinking that the development enviroment isnt build in the same way 
which acutally crowns a pile of shit with a diamond on top ;) Wp is 
hacktogether enviroment and sadly allways will be :(
If this would be an c# MVC Projekt i'D be with you all the way but it just 
sadly isnt :/

Original comment by googleac...@vision-network.org on 9 Oct 2011 at 1:03

[GoogleCodeExporter]

You really lost me there. I think you've mixed up custom fields and metaboxes.  
"customfields are hackable textboxes for template layouts."  That and a couple 
other comments were not at all accurate or relevant, so you've completely lost 
me.

All I'm trying to do is to allow the default behavior to be overridden.   It 
could be done "Free-hand" or it could be assisted using a class generator 
similar to how the sample templates are generated.  Like I said, I think you 
should let me code up an example and then take a look.

Original comment by fireproofsocks on 9 Oct 2011 at 3:21