Should Pods be used instead of coding Custom Post Types in WordPress?

In Pods 2.0, you can create / manage Custom Post Types and implement them with the functions that Pods provides to deploy them or setup customized management panels.

http://dev.podscms.org/pods-2-0/

Argue against this point

Each Pod gets it's own table and stores it's fields in the format they are specified to be. Such as Date, Number, Text, and Pods handles relationships in a way that allows for easy deployment.

This allows for complex deployment, quicker MySQL reads, and minimal storage impact compared to the Key / Value approach.

http://dev.podscms.org/2010/10/15/pod...

Argue against this point

Displaying multiple loops, Searching within categories, subcategories, looking through tags or anything advanced is just a massive pain in WordPress.
You feel like you spend your time looking through the codex for functions to do something for posts to end up realizing the function is called something else to handle custom post types, and it actually doesn't behave exactly the same.

Looking for the right functions, making sure you are not messing up the loop for the sidebar, just becomes a massive waist of time. I can't imagine how difficult it must be for a beginner to peace something together that actually works without messing some part of "the loop" up.

"For a PHP developper the syntax of Pods will make a lot more sense than WP's syntax."

Pods is consistent in it's simplicity.
It has a very easy to learn and very light syntax.
You can build anything you can imagine based on 10 functions and 2 classes with something like 10 methods each.

You actually properly use php when you use Pods.
Wordpress polutes it's own name space (and codex) with different functions to either echo or return values.

I could go on

Argue against this point

The Pods 2.0 upgrade will be as automated as possible. We have made it so that any existing code will be able to continue working without modification. Like WP though, we have deprecated certain functions to facilitate more advanced features. As long as you are utilizing Pods core, most (if not all) of your code will work after the upgrade.

We will also provide a comprehensive guide to future-proofing your code which lays out which functions are deprecated and their replacements.

http://dev.podscms.org/

Argue against this point

Pods has actually had TinyMCE for a while now, check the Packages section of the site. It doesn't work with WP 3.1 because of how Pods uses the editor and how WP restricts it's implementation. Because of this, we are facilitating the development of a more advanced API for the editor within WP Core, hopefully to be released with WordPress 3.2 or 3.3, but most likely available before then as a plugin or standardized set of functions that plugins can use.

Technically, it is still possible to use TinyMCE with Pods even in WP 3.1, minor JS modifications are needed to get the script working again but we have chosen to not play the 'fork game' and attempt to roll a better editor API for themes / plugins / users to utilize.

In fact, the whole process is happening as we speak -- and I challenge anyone to use the_editor in the way we are doing it without having to fix the core WP bugs that revolve around it :) Try to honor WP's TinyMCE editor implementation and you'll see why we've had all the hooplah!

Argue against this point

Technologies change all the time, having the data stored directly as tables in a database allows for easier export, backup, and processing. Inversely, being locked into a proprietary system that was not intended for extreme flexibility, limits you to that system. Many times people want to create a website as a MVP (Minimal Viable Product). Once this product has been released into the ecosystem, they naturally may want to revisit it and improve upon it. Having the data stored in tables simplifies the process were one wanting to build out new functionality, or rewrite it using completely custom code.

Argue against this point

Argue against this point

Pods 2.0 uses core WP functions, and you can utilize core WP functions for deployment and implementation. Pods also offers a number of other extra tools for more complex needs which would otherwise be not possible with additional themes or plugins out of the box.

Argue against this point

I don't think the WordPress mantra of "no new tables unless absolutely necessary" is based on the needs of the individual developer but on the perceived communal benefits of keeping database schemes as consistent as possible. And there are definitely benefits to the community. For instance, you don't have to worry about plugin dependencies if everyone is starting from the same place.

But in the event that you're extending WP to handle very specific data ... say like a flight schedule ... you can easily spend more time trying to contort your data to fit into the WordPress table structure than you would have if you had gone with individual tables for the content types.

Argue against this point

Pods 2.0's use of Custom Post Types will allow for core WP functions to be utilized, should the user not opt-in to using the Pods functions. Essentially, Pods would create / manage CPT, setup their fields and additional options, and your normal WP code would take over the rest.

http://dev.podscms.org/pods-2-0/

Argue against this point

You can enable extra tables if you'd like, otherwise the defaults for Pods are Custom Post Types and meta-based storage for their fields. Nothing scary here.

Argue against this point