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.
Make sense of both sides of the argument
There are many benefits on both sides within WordPress for using the Pods CMS Framework versus coding up your own Custom Post Types.
Pods CMS Framework
WordPress Custom Post Types
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.
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
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.
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!
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.
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.
I believe that Pods should be used instead of custom post types for many reasons. In no particular order of importance here is how Pods makes up for Custom Post Types.
Better DB Utilization - It doesn't really make any sense how WordPress utilizes its posts table. The fact that pages, posts, custom post types, menu items AND revisions go in the same table is just mind boggling. This makes WordPress a poor choice for bigger sites for obvious performance reasons. While it has been said that caching can be used to solve the natural performance degradation, caching should never be used to solve a performance issue, it should be used to enhance already good performance. Pods solves this dilemma by having each piece of data reside in its own table.
Data relationships - The only kind of data relationships WordPress offers are custom taxonomies. While this a cool feature its only the tip of the ice berg and easily accomplished with Pods. Not only can Pods accomplish custom taxonomies but it lays the foundation for many complicated relationships; relationships that can be used to build app style functionality like shopping carts, directories, forums, wikis, etc.
Being that WordPress has greatly evolved past the point of a simple blogging application, and now leans more towards a CMS, I think people should treat it as such. Using the custom post types as a solution stifles the platforms growth and cuts off a usually more educated, tech savvy part of the market. While Pods is still in its adolescent phase as a piece of software, it offers many features that CPT doesn't and does so according to best practices.
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.
As a rule, data shouldn't be stored within it's own tables unless absolutely necessary.
(admin note: please provide a URL or further explain what extra work is required, as well as an explanation of why completely separate content types ranging from simple to complex wouldn't qualify as being necessary)
Is an argument missing?
Please contribute - sign in and add the argument yourself.
Is an argument inaccurate, incorrect or has it been debunked?
Please contribute a counter-argument that gives a reasonable response to the argument with a web address to a reference for further reading.
Does the text of an argument misrepresent it in a biased or inaccurate way?
Please tweet @stef on Twitter to start a conversation about how to fix it.