I have in the past few years done more and more development in Wordpress and would like to get some feedback about custom post types/taxonomies.

What are the pros/cons of using custom post types, rather than creating your own database tables and your own admin pages? I have myself always used posts/taxonomies, but found myself restricted by the pre-defined relationships between each. I also noticed some modules do use them, some don't.

What would you guys suggest, and if both could apply, what's the logic behind it?

  • 3
    This is an open ended question, and open ended questions tend to result in opinion and not in definitive answers. Pro for one person is a con for another depending on personal preference about software organization, maintenance, aesthetics or whatever.. Please try to edit your question and give a concrete scenario to refer to. – Mark Kaplun Feb 4 '16 at 12:31
  • …by "custom posts" I suppose you are referring to custom post types "CPT"? – tillinberlin Feb 4 '16 at 12:31
  • This is just way too broad with too many variables. Exact usage depends on the project at hand – Pieter Goosen Feb 4 '16 at 12:32
  • What restrictions have you found? I think in almost everything is already done for you: CRUD and REST APIs, user access control, object cache ready, extensible by third party developers .... One of the things I like more of WordPress, and one of the main reasons I think it has that great market share, is the high level of abstraction on the concept of content and content clasification. So, what kind of restrictions have you have that make you to think about building all of that from scratch? I think that is the real question. – cybmeta Feb 4 '16 at 12:34
  • 1
    @cybmeta Thanks for understanding my question. I explicitly didn't give any example just so I could avoid the answer being focused on one particular issue. – Fran Feb 4 '16 at 13:17

The rule of thumb in wordpress development is that you should stick with the highest level API you can use. From software development perspective it helps you get a better documentation for your code and reduce the maintenance cost due to the backward compatibility policy.

As CPTs have wrapper APIs in core and costume tables do not, it is easy to see that by default you should prefer CPT, and there should be very very very strong reason to use additional tables.

The only somewhat plausible reason to use additional table is if you need to be able to drop it, or you need a different index structure. Even then not sure if you will gain any actual performance benefit over doing it with less optimized queries.

[joking] If you don't have 20k reputation on this site, additional tables are just not for you [/joking]

  • @cybmeta, tnx, yes that was part of why I wrote it, to end that discussion :) – Mark Kaplun Feb 4 '16 at 13:23
  • Thanks for your answer, I will accept it because you are the only one who really bothered to. – Fran Feb 4 '16 at 13:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.