Open GoogleCodeExporter opened 9 years ago
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
meh... i just realised why i hate php so much ;)
Original comment by googleac...@vision-network.org
on 7 Oct 2011 at 4:59
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
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
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
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
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
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
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
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
" <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
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
Original issue reported on code.google.com by
googleac...@vision-network.org
on 4 Oct 2011 at 11:14