Including field defaults and other settings (e.g. max VARCHAR length)

I think this should be placed in the Attributes section of the Column settings, and grouped together with Column Type in the interface (so you can visibly see the relationship), the ability to add additional 'key/value' meta attributes to a column would be great too

pod_PODNAME should now be capability: pods_PODNAME

All other roles would be pods_ROLE

This is separate from the Dev blog, it's meant for the community to share tutorials, tips, techniques, etc.. as well as show off their work. This would be digg-like.

• Copy all Pod tables and save them as tablename_bk for backup purposes
• Setup Pod Types with new CPT settings
• Setup Pod Type's fields with new pickval / pickobject settings
• Migrate Pod Type's field non-core attributes to options JSON
• Migrate IDs stored in wp_pod_rel to match Object IDs and add datatype ID
• Delete wp_pod table

Not sure the best approach on this, perhaps a [pods_content] shortcode, also would be good to have a uri attribute to choose which pod page content to pull in (defaults to current uri).

On load, public form would create a unique nonce based off the form action, the current URL, the session ID, and the current form fields. The current URL and form fields would then be saved into the user's session and compared upon submission to ensure it matches. This ensures no one can submit or change the fields they are saving from beyond the ones set in the form configuration and that they can't change their session values to try to trick the system.

It makes sense to standardize this, as lots of people are echo'ing them anyways, but it's good to not force people to use output buffering to modify output when they need to.

Matt - 16 Sep 2010, 8:56am
My recommendation would be to leave these functions as-is, but create newer, better functions.

E.g. show_template($options), show_form($options), show_filters($options), show_pagination($options)

Where each new function would take an associative array ($options) as input.

$options['echo'] can default to "true".

We need to update the User Guide, and perhaps add some better examples both simple and complex.

Currently on activation, Pods adds it's tables to the current prefix, but on network activation it should create tables across each of the sites.

I made a 'bunnies' Custom Content Type.

I only added two fields. An image field, and a category (relationship to categories taxonomy) field. When trying to add an item, I get an Error: Item not found message..and the url shows an id=0, like

?page=pods_bunnies&action=edit&do=create&id=0

When I go back and edit the Content Type and add some arbitrary field that would actually save to the _pods_bunnies table (like a text field) instead of ONLY saving an id, I can successfully add an item and the url displays the new item id like

?page=pods_bunnies&action=edit&do=create&id=1

Manage the UI of a Pod, basically a UI for pods_ui options.

When something happens in Pods like:

"SQL failed; SQL: SELECT id, name, coltype, pickval FROM fh_pod_fields WHERE datatype = AND (coltype = 'file' OR coltype = 'pick') ORDER BY weight; Response: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AND (coltype = 'file' OR coltype = 'pick') ORDER BY weight' at line 1"

We should show the real error. Like 'Pod not found' or what-not.

Post Types exist in wp_posts.post_type, where as Taxonomies exist in wp_terms_taxonomy.taxonomy

We should use one set of code for Post Types in general, and one set of code for Taxonomies in general - It doesn't make much sense to add this as additional code - it should replace the existing Categories / Posts / Pages code.

A slight change in the way the relationship is stored will be required though, we should discuss further

Scott Kingsley Clark - 10 Jan 2010, 2:33pm
i think it may be best to combine some of our existing post types like Post / Page as well as Taxonomies like Categories to simplify the PICK relationships and code necessary, by making it generalized it will cover all Post Types and Taxonomies

Matt - 13 Jan 2010, 10:07am
Agreed. Then the user could use the "PICK filter" column to manually choose the post_type(s)...

post_type IN ('page', 'post', 'something_else')

Scott Kingsley Clark - 13 Jan 2010, 12:51pm
Well.. it should be more in the User Interface, so they could select which post_type (like an attribute), perhaps we should save this for when we redo the UI for the Setup tabs

Scott Kingsley Clark - 3 Sep 2010, 12:45am
With all the new changes, to relate going forward we will store CPT and Taxonomies (along with other stuff in the 'object' field. Examples:

• object = post (pickval = empty)
• object = page (pickval = empty)
• object = cpt (pickval = cptname)
• object = tag (pickval = empty)
• object = category (pickval = empty)
• object = taxonomy (pickval = taxonomyname)
• object = comment (pickval = empty)
• object = user (pickval = empty)
• object = pod (pickval = podname)

All existing Category pickval data goes into the options JSON

Scott Kingsley Clark - 3 Sep 2010, 12:47am
The reasoning behind the separation of Pod objects and CPT objects are that there can be completely separate CPT built outside of Pods, which shouldn't cause an additional query to check if it's a Pods-based CPT or not in use

Scott Kingsley Clark - 3 Sep 2010, 12:49am
I'm not partial to storing post / page in the CPT object pickval, same with tag / category in the taxonomy object pickval. That could simplify things a lot possibly.

pod_{PODNAME} should now be capability: pods_{PODNAME}

All other roles would be pods_{ROLE}

We need a system to list donors, contributors (and what they contributed on), etc..

more customizable & versatile on searching / filtering (ie: by date - month/year, etc..)

Field coverage

• Relationship dropdown fields (pick)
• Associated Taxonomies (filter by taxonomy terms) for Post Types (taxonomy)
• Date / Time ranges (date / datetime / time)
• Number ranges (number / currency)
• Boolean checkbox (boolean)
• Text fields (code, color, email, paragraph, phone, slug, text, website, wysiwyg)
• Option to use a checkbox for checking for a non-empty value or not (all fields, specifically useful to check if file / avatar fields are set)

A theme or a plugin could include functions that could be run when a user calls that 'function' (or any PHP function) as the helper name.

As we get ready to push Pods into the CPT, it makes sense to push it across the other data types. Effectively, Pods could "extend" any of the metadata types by taking over their meta storage. The prefix for all fields used in metadata functions for the field names must be something, maybe 'Pods', this way it doesn't overwrite any core meta data fields for these types.

Mike Van Winkle did a nice diddy with this plugin: http://www.mikevanwinkle.com/wordpress/plugins/wordpress-podscms-widgets/

So we need to clean it up and put it into core already ;)

A number of changes need to be made on the Pod tables, I feel, to extend and simplify at the same time. See tasks for the differences.

Please note, going forward, we need to normalize the 'id' of the wp_pod_tbl_{podname} to match the ID of the object in which it's related.

Examples:

• Post Types: wp_posts.ID = wp_pod_tbl_podname.id
• Taxonomy: wp_terms.term_id = wp_pod_tbl_podname.id
• Comments: wp_comments.comment_ID = wp_pod_tbl_podname.id
• Users: wp_users.ID = wp_pod_tbl_podname.id

All Pods attach a one-to-one relationship, so all IDs should remain the same. If someone wants to relate other pods / objects to that from there, that's a separate thing and would need to be related to Taxonomies or whatever other Object Type they pick.

So if someone wanted to add many photos, but only many photos as the addition to their Users data, they would add the first pod and attach to User. Then they would add the File field to attach files. Yes, the table would still be sitting there only with the 'id' column, but that's so long term they can add additional fields.

• Pod Fields: Store all non-core attributes in JSON column in wp_pod_fields.options (to make it possible to extend each column) -- KEEP id, datatype, name, coltype, pickobject (add), pickval, sister_field_id, weight, options (add)
• Pod Types: Add 'object' field to wp_pod_types -- CORE OPTIONS: post, page, cpt, tag, category, taxonomy, comment, user
• Pod Types: Store all non-core attributes in JSON column in wp_pod_types.options field
• Delete wp_pod
• Relationships: Rename pod_id to object_id, Rename sister_pod_id to sister_object_id, Rename tbl_row_id to related_id, Add datatype int(10) column directly below id column to store Pod Type ID, Move field_id below datatype new column

Load this code only if XML-RPC is turned on for a site

http://codex.wordpress.org/XML-RPC_Extending

Methods / Actions

• method=pods&action=list&pod=%s to add a Pod Item - (Pod Name / ID, find params)
• method=pods&action=add&pod=%s to add a Pod Item - (Pod Name / ID)
• method=pods&action=save&pod=%s&item=%s to save a Pod Item - (Pod Name / ID, Item Slug / ID)
• method=pods&action=delete&pod=%s&item=%s to delete a Pod Item - (Pod Name / ID, Item Slug / ID)
• method=pods&action=duplicate&pod=%s&item=%s to duplicate a Pod Item - (Pod Name / ID, Item Slug / ID)
• method=pods&action=export&pod=%s&item=%s to export a Pod Item's data - (Pod Name / ID, Item Slug / ID)
• method=pods&action=export&pod=%s to export Pod Item(s) - (Pod Name / ID)
• method=pods&action=import&pod=%s&data=%s to import Pod Item(s) - (Pod Name / ID, Item Data)
• method=pods-api&action=list to add a Pod Item - (load_pods params)
• method=pods-api&action=add-pod to add a Pod - (Site)
• method=pods-api&action=save-pod&pod=%s to save a Pod - (Pod Name / ID)
• method=pods-api&action=delete-pod&pod=%s to delete a Pod - (Pod Name / ID)
• method=pods-api&action=reset-pod&pod=%s to reset a Pod - (Pod Name / ID)
• method=pods-api&action=duplicate-pod&pod=%s to duplicate a Pod - (Pod Name / ID)
• method=pods-api&action=export-pod&pod=%s to export a Pod's settings - (Pod Name / ID)
• method=pods-api&action=import-pod&data=%s to import a Pod - (Pod Data)