81 Responses

  1. Travis Taylor
    Travis Taylor Published |

    I agree with you 100%. I think custom post types should have been a plugin only function from the beginning. But since it’s not, how do you compete with themes that have so many out of the box? How do you convince someone with very little WordPress knowledge that clicking one “install” button is worse than clicking ten “install” buttons for a proper theme with multiple plugins? New users want an easy button, and unfortunately they don’t realize the penalties of it.

    I like that themes are starting to advertise their compatibility with plugins like woocommerce. This is the direction themes should go in. Making them compatible with multiple plugins, instead of forcing them to install a theme that gives them no option of switching themes later on without data loss.

    Reply
  2. bb
    bb Published |

    Thank for this clarification. When you mentioned woocommerce and bbpress, I caught the drift. However, some WP authors may desire to create a niche theme and do want some independence by creating custom post types to sell their themes. For instance, I want a School WordPress website and if most of the plugins do not cater for the functionality I’m looking for or not sure about the support update of the plugin, what do you expect me to do than to create a custom post types for the theme? Will I say because I want some few functionality would create a plugin? Please help me out with this. I love your education and zeal, thanks a million!

    Reply
  3. Grégoire Noyelle
    Grégoire Noyelle Published |

    Thanks Justin

    Like Travis I agree. Following your older tutorial I start the the first method and quickly change my mimd.

    Normally, if you change your mind later, you can make the plugin later without losing data if the CPT name are similar.

    Reply
  4. Marcus Tibesar
    Marcus Tibesar Published |

    Hell Justin I’m not a developer and I fully understand your differentiations.

    I’ve probably had 20 themes on my single site over 4 years or so including your themes and I hate being locked in.

    I immediately abandoned tablepress because it would have locked me in to the plugin so I’m wary of plugins too (let alone themes)!

    Your writing impresses me and I really like your clear lines of thought and communications.

    Another great post!

    Marcus Tibesar

    The Tibesar Family Archives

    Reply
  5. Mike Schinkel
    Mike Schinkel Published |

    Hi Justin,

    I’ve heard this same rant many times in the WordPress community and I agree with it for most use-cases. But what I’ve never heard is for anyone making this rant to clarify the use-cases where this advice applies and contrast with use-cases where it does not (necessarily) apply.

    The use-case where your concern applies is for themes that are developed for distribution to and use by end-user site owners. And yes, that is by far the broadest use-case in the WordPress community.

    However where your concerns do not (necessarily) apply are for custom themes that are developed for specific clients, and the larger the project the more your concerns do not apply. Think agency projects for larger corporate clients.

    For example, if I were developing a theme for a website that Walmart plans to use to promote one of their initiatives then none of your stated reasons are relevant. One of your reasons in particular, code-reuse can be handled via version control sub-repositories, Composer, and/or build scripts. And for these types of projects it’s often much cleaner workflow to put everything in the theme because then you can deploy from one repository to one server directory and don’t have to deal with keeping theme and plugins in sync during the development cycle.

    What’s more, point-of-fact, the project I’m on right now for a Fortune 100 company requires our team to put everything in the theme; we don’t even have the option to put code in plugins because they are using a Multisite configuration where they have set significant constraints. The site we are building will be just one of many that will be hosted on the Multisite and they want to avoid managing plugins for required individual site functionality.

    So my reason for comment is hopefully to see you and others reading this to caveat your future discussions on the subject so that agency folk who run across your posts but don’t apply any analytical thought come up with the opinion that there are never good reasons to put post types and other data features into the theme.

    -Mike

    P.S. I was also pained to see you ask the question “Do you really need a post type for that?” For an end-user managing their own blog/site that is probably good advice, but for a developer building customized sites that’s probably really bad advice. In my experience I’ve found that every time I don’t create a custom post type for use-cases that are not (nearly) identical to the regular use-cases for the built-in post types I end up regretting it, and often refactoring to add in that new custom post type. But to be fair the sites I’m involved in a highly customized at the PHP and Javascript level so I’ll caveat my advice on custom post types too.

    Reply
  6. Jon Brown
    Jon Brown Published |

    All I do is custom work, but in every case I create a functionality plugin. I do see Mike’s point that there are some edge cases where that doesn’t make sense.

    I think the missing part of this discussion however is how to connect plugin functionality with theme output. There are lots of questions about best practices in the actual dividing up of code between the two. What I mean is do you write query functions into your plugin for that CPT and then check for and use that function in your theme or do you do it all in the theme? Do you use virtual pages, shortcodes, etc to make output easier in the theme?

    I think it’s easy to say out functionality in the plugin and presentation in the theme, but in all the calls to put shortcodes and CPT in plugins I haven’t seen much in the way of practical examples of best practice when doing so.

    Reply
    1. Sami Keijonen
      Sami Keijonen Published |

      I also use custom plugins in clients work. It’s easier to maintain and debug problems that way. And also clients want re-desings (new theme).

      Reply
  7. Andrew
    Andrew Published |

    Great post Justin, very thought provoking and a timely one for me…

    I’m relatively new to WordPress and still at the stage where the more I learn the more questions seem to be created.

    I recently worked on a site where I outsourced one of pages. The page basically contained a slider (powered by MetaSlider), a row of four images with links and 2 content areas under that in 2 columns wrapped in the the usual header and footer. More importantly he setup meta boxes to match so we have a box we can add a shortcode to for the slider, 4 image upload buttons with matching URL boxes and 2 text editors. Been the first time I’d seen that kinda setup I thought it was really really good and very end user friendly and meant we could easily setup multiple pages with this layout with different links/graphics on each.

    My plan was then to use something like Easy Content Types to create several layouts with matching CSS that I could drop into any theme where they are needed but I’m now wondering if that’s the right way to go or whether I should look at trying to make them into plugins… ?

    As I learn more I’m better seeing the reasons to separate presentation from functionality but as noted above, as a relative newbie, there is initially a big appeal in finding a theme that has a lot built into it’s control panel that takes care of a lot of this stuff even if it locks you into the theme… I’ve started playing with _s and intend to get to a point where the theme is ‘just’ presentation but still a way to go yet for me! lol

    Thanks for another thought provoking article :-)

    Reply
    1. Andrew
      Andrew Published |

      Out of interest where do tools like Visual Composer – http://codecanyon.net/item/visual-composer-for-wordpress/242431 – fit into this. It is a plugin and appears to make life very easy to control layouts and will work with custom post types?

      Reply
  8. Faraz
    Faraz Published |

    Great Post, thanks for sharing this helpful information.

    Reply
  9. Turcu Ciprian
    Turcu Ciprian Published |

    Great! Now if we can also just get rid of shortcodes (in general, stop using them, stop developing them) that’d be great. And we’ll all have a much cleaner, organized, functional platform :)

    Reply
  10. Jan van Iperen
    Jan van Iperen Published |

    Dear Justin,

    Love your line of thoughts… Had just written an article from the perspective that for a large proportion of users, the whole post type question should be answered automatically from the core… giving the user the option to correct/change afterwards.

    Creating a multitude of plugins for this… I still do not know whether this does any good to the overall simplicity of WP and the current demands that users are having.

    The whole matter is food for thought indeed.

    Reply
    1. John Locke
      John Locke Published |

      This is the best explanation I have seen so far for why the decoupling of Custom Post Types from a specific theme is a good idea. End-users may switch themes without knowing that their content is going to be affected. Imagine the frustration they feel when that happens to them, and they don’t understand what is going on.

      Reply
  11. Miles Gilmour
    Miles Gilmour Published |

    Is being tied to a plugin (which would invariably be bundled with a theme) really any better than being tied to a theme? I appreciate the ideal – that a user should be able to easily swap between themes – but once they start adding any kind of custom content, that portability goes out of the window.

    IMO, a key strength of WordPress is the customization and CMS capabilities afforded by custom post types. If you separate the custom content into a plugin – how would it be styled in a manner that keeps it in line with the rest of the site? Would the theme developers have to be aware of every potential content type that a plugin author may add, or the plugin authors be limited to a few pre-set layouts? Even when plugging-in something mature and well defined like bbPress I find myself having to make changes and additions to css to make it look an integrated part of a site.

    I can certainly see a case for making the user aware that using custom post types, etc. will take them “off piste” with limited options for returning, but I think its a decision best left to the site owner to make. People who want a simple blog/site and to be able to change themes often can stick with “posts” and “pages”, but those users who want more complex functionality have a tradeoff to make. I don’t think it’s possible to split functionality and design so cleanly that you can retain 100% theme compatibility and allow the levels of extensibility that have made WordPress the success it is today.

    Reply
    1. Frank McClung
      Frank McClung Published |

      Miles has made some very good points here Justin. I know you are trying to defend your position, but in doing so you respond like his are not valid. You take more of a developers viewpoint and Miles represents a theme designer/user standpoint, and that is where the rub is.

      Reply
  12. Kein T.
    Kein T. Published |

    I’m WordPress developer and I agree with you on that, but in some case the CPT plugin will useless.

    Let’s say I create a directory theme and had a CPT plugin called Listings, it has a lot of custom meta field which I use for search, custom google map.

    You are using my theme and want to move to another theme in the same niche. My Listings plugin still work fine but the data and layout output to the front-end look very mess.

    If you deactivated my plugin and use new theme with new Listings CPT plugin provide by the new theme author, the CPT data still there but all of custom meta field is different.

    Can you tell me how you deal in this case. Please help me out of this :)

    Kein T. From SmoothThemes.

    Best Regards.

    Reply
  13. Andrew Ledwith
    Andrew Ledwith Published |

    When I’m developing a website for myself or a client I add the appropriate custom post type code to a file that I drop in the mu-plugins folder. For all the reasons you’ve cited a custom post type is something I’m going to want running at all times as if it were part of the core. A standard plugin makes more sense when you want someone else to add the functionality to their website without your help though.

    Reply
    1. Joy
      Joy Published |

      Plugins are best for managing the custom post types, but no one seems to mention using child themes to enhance the styling of custom post type. It’s easier to change the child to use a new parent theme than to try to add all that to another theme.

      Reply
  14. Florian Gabele
    Florian Gabele Published |

    As I saw this post at first, I thought, this will make it complicated to code themes and style CPT, but after reading your article I think you`re right.

    There are already Plugins wich can create CPT, (http://wordpress.org/plugins/custom-post-type-ui/ and http://wordpress.org/plugins/types/) but whats about styling?

    A solution would be to define a few Post Type Keys, like gallery, portfolio_item, photos and so on, so the developers have to use one of these keys to keep the data portable.

    Reply
  15. Jenny Beaumont
    Jenny Beaumont Published |

    Great food for thought. I often struggle with the question, “To CPT or not to CPT”, and while I’m more and more in favor of them these days, I try to keep up on best practices. I only do custom work, versus distributed themes, but the topics you bring up are important ones to discuss with clients so that they have all the facts, and can ask the pertinent questions. Really appreciate the focus on the long-term health of a site and contributing to user knowledge – things developers often gloss over or overlook.

    cheers!

    -jennyb

    Reply
  16. Henrik Blomgren
    Henrik Blomgren Published |

    Thanks for this very intruging post. I was against having custom post types as a plugin from the start. But after reading this post and thinking about what it actually would mean for me as a starting developer I have to say I´ve changed my mind.

    A standard plugin from automatic that is all about creating custom post types would be awesome. Then I could use that plugin instead of coding it myself which would mean I could easily change themes whenever I wanted and simply add some code to create pages that show the custom post types.

    For future clients, educating them onto such a plugin instead of having to tell them why their new theme doesn´t show all of the custom post types they previosuly had would be much easier.

    Good post on the topic.

    Reply
  17. GilCatt
    GilCatt Published |

    I understand the logic behind putting CPTs in plugins.

    However, by definition we are talking about custom content for custom purposes, which certainly restricts the freedom of switching themes.

    For a simple reason: elaborated custom content needs a matching design.

    You are talking about themes, I am thinking in terms of user interface. When a theme becomes a user interface, it seems pointless to focus on efforts to make CPTs compatible with every WordPress theme and make it a rule. Unless you believe it is reasonable to modify a theme to make it fit.

    As you say, and rightly so “realistically, you need a theme that was specifically designed for a plugin to present the data in a beautiful way.” I couldn’t agree more: you don’t want to redesign every theme to make them compatible with a plugin.

    I do agree that you could offer some CPTs as a plugin. Yet I also believe there are as many CPTs, if not more, that would not fit that model, for the aforementioned reason.

    So, what would be the point of CPT portability ?

    You say, mentioning your portfolio plugin, that if every portfolio theme supported it, users would have tons of theme choices. The hypothesis works in that simple, almost universal use case, but is it a good example?

    Let’s see how it translates in true market conditions:

    Bloggers used to be the core market of WordPress. It has changed. Small businesses are using it more and more. The blogging functionality has become marginal in most use cases. There will be a time for WordPress when small businesses websites will outnumber blogs. After all has it not evolved into a rather user friendly CMS?

    These new users won’t tinker with a website’s innards, ever. Most of them have specific needs related to their specialty.

    Indeed, you will have noticed a market move towards specialty themes. We have all seen restaurant themes, real estate themes, and so forth. This trend is getting bigger. This is one of the reasons ThemeForest is gaining popularity every year.

    This category of users doesn’t switch theme that easily. They are businesses. They have a brand, an identity that does not allow for regular theme changes. It is fun when you are a blogger, it is dangerous when you run a business.

    Furthermore I believe there will soon be a time when the theme offering will be so large in terms of diversity and quality that designing a theme for scratch for the end client will be an economical nonsense. Who goes to the tailor anymore when he needs clothes? The very high end market, by definition a very small market. When you buy a car, you get to pick the model, the color and some options, and that’s it.

    I don’t see why that won’t happen with WordPress for business websites. Especially if themes are easily customizable.

    The theme market is already based on that paradigm: plug’n'play.

    To such an extent that WordPress themes are now offered as a Saas to a growing list of business niches.

    Web designers will have to adapt. Create themes for the theme market, for niche businesses, not only for bloggers, and get better at content and marketing services if they want to serve the end market as well or leave the latter to experts who are better at this, because that is what such clients are buying in the first place.

    Bloggers create their own content, have fun changing themes, trying plugins. Businesses do not. This is a completely different market. Traditional web designers will end up working for “web dealerships”, just like car factories provide car dealerships. Selling wholesale in a new way: one theme to thousands of clients. This is what the theme market is about: volume sales.

    When I meet a future client, I don’t want to give him the freedom to start with a blank slate. I show him themes that I believe suit his business well, and I show him the price of such themes. This instantly kills the “traditional” competition: they can’t compete with this value shift. Their proposals are usually based on development and graphic design items justifying the price tag. You can imagine the client’s reaction to that when he already knows the price of a theme, when he has been shown how easy it is to customize them, enough to fit his needs. WordPress is just fabulous for that kind of demo. This is how you build trust. Then I can focus on the real value: content and marketing advice, advertising and so on. Business services in other words. With the added benefit of shorter delivery dates, lower prices and recurring revenue. PootlePress is doing something similar, and I love their business model.

    I’d rather spend 90% of my time creating and formatting my clients’ content for the web and 10% on technical issues than the contrary. And most of the time these 10% are spent creating or modifying existing CPTs, tailoring them for their specific offer, adding specific fields for their specific data. I don’t see how you could standardize this into a plugin when it is precisely an area where they want to stand out from the crowd.

    The less time I spend on code the better. It is definitely faster to use a theme’s integrated CPTs around which the design has been well done, than modifying the design of a theme to use CPTs it has not been created for, and then modifying a CPT plugin on top of that. I mean you can but moneywise it is not the best thing to do.

    One last point: quite frankly I’d rather have my clients tied to their theme because I want them to need me.

    This is a basic business rule. All car models from all makers would have interoperable parts, otherwise.

    An engineer’s utopia, but what a mess it would create on the business side.

    What is smart technically wise is not always smart business wise.

    I do agree that you provide some of the best code available in the WordPress realm, and I have often relied on your plugins. But your themes are not the best value for businesses out of the box – which may be one of the reason you sold so few on ThemeForest, by the way. It is not the market you are necessarily after, I agree. Bloggers will remain a great niche market for your themes. What you are saying about CPTs is only valid for that market, in my opinion. For “theme switchers”.

    Reply
    1. Frank McClung
      Frank McClung Published |

      This is the most concise and insightful comment on where the theme market is headed that I’ve read in a long time.

      Reply
  18. Restaurant plugin preview
    Restaurant plugin preview at |
  19. The Easy Way to Keep Your Custom Post Type in a Plugin » Theme Foundation
  20. Manny Fleurmond
    Manny Fleurmond Published |

    I wonder what your stance is on widgets? I’m leaning towards putting them in plugins but a lot of themes come included with them

    Reply
  21. Steven
    Steven Published |

    I too struggle with how to put the CPT data presentation from a plugin into a theme. Especially in custom sites built for clients with particular needs. I usually put the CPTs in plugins for data portability. Down the road when they decide to do a site ‘redesign’ – a new custom theme, or even a “premium” marketplace theme they can take their data with them.

    BUT, the presentation of that data will always have to be tailored to the theme. Even in standardized plugins like WooCommerce you will need to tailor the presentation of data to suit your theme. It is a lot of work, but so is building custom themes anyway.

    One approach is to create some functions in your CPT plugin that present the data, complete with custom markup and class names. Then you can use those functions easily in your theme and style accordingly. That way those little bits of functionality are also portable along with the data. Maybe you can create an option to disable your plugin styles. WooCommerce does this. This too requires more work and you should charge for it accordingly. If they have a smaller budget use Justin’s plugin ;)

    This approach can be used for your custom plugins for your custom themes as well. As long as you have a great relationship with your client they may want you to build a new theme down the road – you can use your plugin.

    This may not be the most ideal way to handle this but I believe it sure beats putting the CPTs in the theme.

    Your thoughts Justin? Thanks for the write up and initiating this conversation.

    Reply
  22. Piet
    Piet Published |

    What I usually do for themes I develop for clients is to place all custom code (custom post types, custom taxonomies, custom metaboxes) in a separate library folder and then include that via the functions file.

    I think this could also be an approach for (commercial) theme developers if they would write clear instructions on how to copy that library folder over to the new theme and copy the line of the functions file to the new theme.

    Of course on the front end of the new theme a lot of editing would still be needed to make the custom content look proper again, but at least the user still has access to all the data.

    Reply
  23. The Weekly WordPress News, Tutorials & Resources Roundup No.43 | Supreme Factory
  24. WordPress Francophone : L’Hebdo WordPress n°199 : WordPress 3.7 – WooCommerce – PressNomics | WordPress Actualités
  25. Récap semaine n°38 des Custom post type, du Lorem Ipsum et des tweetsArnaud Banvillet
  26. WP Magnet | The Weekly WordPress News, Tutorials & Resources Roundup No.43
  27. Creating A Custom Post Type In WordPress
    Creating A Custom Post Type In WordPress at |
  28. Ajay
    Ajay Published |

    You say that “Consider the portfolio_item post type. For many of the themes I’ve seen with this, all they really need is a custom page template that pulls in “image” (post format) posts.”

    What understand is that I will create a page template say Page_Portfolio. This will list all my image post format type posts. When I click on any of the post on this page it will take me to my individual portfolio items. So I want to customize the display of the individual portfolio items to achieve how I want to display my individual portfolio. Right?

    But when I change the theme, Am I not going to lost all my portfolio page display customization and if the new theme does not support post format, I am even going to see a broken page.

    Please correct em if I am wrong..

    Reply
    1. Joy
      Joy Published |

      You are correct that Page Templates change with the theme. However, a plugin can filter the page template request and provide an alternate that is stored in the plugin.

      Reply
  29. This Week In WordPress: Sep 23, 2013 - Max Foundry
  30. 公開テーマではカスタム投稿タイプを定義すべきでない理由
  31. Mark Senff
    Mark Senff Published |

    I understand the reasoning for having custom data in plugins (and not the actual theme). However I’m having lots of trouble wrapping my head around how to go about this.

    I recently created a site for a company where I made custom post types for various things:

    - management / team members

    - projects

    - industries

    - events

    etc. etc. Basically because these types of data would show up being listed on the site here and there. So I called queries to list these various things right within my theme (for example, the home page would list the 5 most recent projects, all industries and the 3 latest events).

    I thought that was the most logical thing to do, but now I’m worried I did it all wrong.

    What WOULD have been the proper way, structurally? I would still create the custom post types, but how would I put that in a plugin and then make ‘em show up on my front page? How would I ensure they still show up on the home page if another theme was used (or would that also require editing that particular theme)?

    Appreciate it if you would point me in the right direction. Thanks!

    Reply
    1. Joy
      Joy Published |

      This sounds like a case of using a custom post type when it’s not really needed. Those could be posts in categories of those names instead.

      The home page content should be created to be theme independent, by using various plugins to list the posts (if they really need to be dynamic) or contain that content (if it doesn’t need to be dynamic).

      Reply
  32. Custom backgrounds and headers
    Custom backgrounds and headers at |
  33. Churchthemes.com Does it Different : WPMayor
  34. Plug-Ins | Pearltrees
    Plug-Ins | Pearltrees at |
  35. Jame
    Jame Published |

    This is another great post and also another post that I’ve read from Pippins’s site.

    I’m using Pippins’s Easy Custom Content Types. Yet, I always doubt when building the templates for displaying those custom post types.

    I like Hybrid Theme but always having issue when dealing with displaying the data from custom types.

    Anyways, good explanation for the best practice of WordPress.

    Jame

    Reply
  36. mario bianchi
    mario bianchi Published |

    Nice writing! Glad I found this original piece. Just learned some valuable information. It may help me about related matter. I will come back for more reading…

    Reply
  37. Francis
    Francis Published |

    Great post Justin, I totally agree with your vision. I have a question though. Let’s say I create a theme I want to sell and I use a CPT plugin of someone else. How do you think the dev of the plugin will react seeing his plugin used in a Premium theme. He could say a part of the money made with the theme should be his, no?

    Reply
  38. Rizqy Hidayat
    Rizqy Hidayat Published |

    Hi, this post really change my mind and think that I’m agree with you. And I see where it goes. When we have a good and popular plugin, take example at portfolio case, we could use that publicly-available plugin and just start to make-over and integrate that plugin with our theme. Just like the way we create a theme with WooCommerce/bbPress/BuddyPress/etc. support: design the themes, and left the big part of it to the plugin. Nice.

    But, it would be nicer, if we built that public plugin with extandability support/API, which we could easily takeover from our themes, not just the visual part of it. For example back to portfolio case, it would be good if we (theme developer) could specifically add custom metabox with just an array of settings, and the plugin take the rest of it. Just like the way action/filter works.

    just my opinions,

    Rizqy.

    Reply
  39. WordPress portfolio plugins – a requirements list | charliedotau
  40. Charlie
    Charlie Published |

    Great article. And I applaud your efforts Justin on the portfolio plugin. I can’t agree more that we need a de facto standard portfolio plugin a la woocommerce in the ecommerce space.

    You said at the moment your plugin is not that popular. Which got me thinking, what would make a portfolio plugin really popular? What features would that plugin have to really make it have broad appeal? I’ve had a stab at answering that very question here – http://charliedotau.wordpress.com/2013/10/14/wordpress-portfolio-plugins-a-requirements-list/

    Reply
  41. WordPress Plugin Integration with Custom Theme Development | S2 Web
  42. The Menace of Theme Creep | WPShout.com
    The Menace of Theme Creep | WPShout.com at |
  43. Why You Should Never Add Analytics Code to Your WordPress Theme
  44. Btag
    Btag Published |

    Thanks for this sharing…

    Great post!

    Reply
  45. Designer Interview: Steven Gliebe – Church WordPress
  46. Justin C
    Justin C Published |

    I agree with what you’ve said and what a lot of others have said as well. As of now I include my custom code in separate files like Piet mentioned. I’m new at plugin development, are there any resources that you can recommend to put your article into practice?

    Reply
  47. Clubs premium: un modelo de negocio de la economía directa - CoLabores
  48. rakesh kumar
    rakesh kumar Published |

    You may be 100% right in your case or the cases you have taken to show that it must be inside a plugin, as a niche wordpress theme developer its my priority to give my user everything inside my theme and do not ask him/her to install a lots of plugins to run my theme or to get that functionality, so in my opinion it must be very from project to project as you have already mentioned in the beginning of this article.

    Reply
  49. WordPress Theme Shops Move Towards Preserving Data Portability
  50. El arte de rastrear, contextualizar (e incluso generar) debates - CoLabores
  51. Tesla Themes Review - aThemes
    Tesla Themes Review - aThemes at |
  52. TeslaThemes Review - aThemes
    TeslaThemes Review - aThemes at |
  53. Rahat Ayaz – Freelance web designer Abu Dhabi WordPress as a CMS – Side by side comparison with Joomla & Drupal | Rahat Ayaz - Freelance web designer Abu Dhabi
  54. Tiago Gouvêa
    Tiago Gouvêa Published |

    Great post Justin!

    I have a question. I’m starting to create a plugin and I want to use Post Types to easy the data store/read process.. I’m saying that all data of my plugin will be stored in Post Types. It’s a event scheduler, with booking and online payment plugin.

    The plugin will have some functionality and do a lot of data read, search and update on the user (visitor) interation.

    There still Post Type a good idea in this case? Or you recommend me you MySql tables to store it? Do you think I will have limitations using Post Type like that?

    Thanks for help!

    Reply

Leave a Reply

By submitting a comment here you grant this site a perpetual license to reproduce your words and name/Web site in attribution.

Please use your real name or a pseudonym (i.e., pen name, alias, nom de plume) when commenting. If you add your site name, company name, or something completely random, I'll likely change it to whatever I want.

css.php