Plugin Territory: Custom post types

[emiluzelac]

../helpers.php

---

register_post_type() is a plugin-territory functionality.

[justintadlock]

I think it's safe to say just about everything in the helpers.php file is plugin territory. There's a few things that are design-/presentation-related, such as customizer options. But, for the most part (roughly 70% of this file), it belongs in a plugin.

[leac]

OK, how should I do this - should I create a plugin for each functionality, making it like a dozen plugins? Is that normal, to have so many small plugins (like in the case of register_post_type, a plugin with 20 lines of code)? Also, could you please help me by being more specific and telling me what can stay in helpers.php and what has to go into a plugin?

[justintadlock]

OK, how should I do this - should I create a plugin for each functionality, making it like a dozen plugins? Is that normal, to have so many small plugins (like in the case of register_post_type, a plugin with 20 lines of code)?

Plugins, themes, or other scripts should be self-contained. One of the cornerstones of good programming is to have each script do one thing and to do that one thing great. Most programmers learn to do this naturally over time as they do more and more debugging.

You must decide, on a case-by-case basis, how to code something with this guideline in mind. You wouldn't put 12 separate, unrelated things into a single plugin. If all 12 things are unrelated, you should have 12 plugins. That is completely normal and the proper method of coding such scripts.

Also, could you please help me by being more specific and telling me what can stay in helpers.php and what has to go into a plugin?

I'll see if I can round up a complete list. In the meantime, here's some questions:

Will the user need that data or functionality when they switch to a different theme? If the answer is yes, it's absolutely plugin territory. If the answer is no, the next question is: Is the feature related to the presentation of content on the front end? If the answer is no, it's plugin territory. If the answer is yes, it's most likely theme territory.

[leac]

Thank you very much for the guiding questions. They definitely help! Maybe you can hold off rounding up a complete list. I'll try to do that myself using your guidelines, and will consult you if I'm uncertain about something.

[justintadlock]

Sounds good.

[leac]

I have another question that I ask myself when contemplating whether code should stay in the theme or should be turned into a plugin: what will happen if this plugin isn't activated? If the answer is that some parts of the site won't look good, I feel it should stay in the theme.

However, I assume this isn't a good guidance for a plugin decision, but I don't know why :) I'd appreciate it if you could explain to me why it's not. Thanks!

[justintadlock]

What will actually happen is that some parts of the site simply won't exist.

Whether something "looks good" is all about how the theme is designed, not whether a part of the site exists.

[leac]

Thanks for the clarification. I went over helpers.php and made a list of what I think should stay, and what I'm not sure about. It came out longer than I'd expected, so I'll understand if you can't relate to every issue brought up. Any input will be appreciated.

Functions I think should stay in helpers:

• kamoha_setup_more
• kamoha_modify_query (with an exception, detailed lower down in the "not sure" list...)
• kamoha_posts_where
• kamoha_show_movie_icon: Shows alittle icon of audio or video on the post's featured image, if there is a movie or audio in the post.
• kamoha_tag_cloud_widget: Called with the widget_tag_cloud_args hook. Limits the number of tags shown. Other themes might not need this.
• kamoha_show_post_one_cat: This function returns one category of the current post. It's used to display the post category in the front page, and near the post title in the single page. Seems to me theme related.
• get_homepage_categories: Get a list of categories whose posts should be displayed in front page
• kamoha_order_categories_by: Get the order in which to show the categories in the front page. Seems related to theme.

Functions I'm not sure about:

• kamoha_menu_cat_subnav - creates child items out of sub-categories of menu items that are categories. I can't decide if this is something that the user will want when they switch themes, or maybe, because it belongs to the menu, and the menu is a theme territory, it should stay in the theme.
• kamoha_register_required_plugins - On the one hand, it doesn't handle presentation of content on the front end. On the other hand, if some of the plugins recommended by it aren't activated, the site won't look well (for example, the Responsive Menu plugin. I need it for lower resolutions). So if I make this function into a plugin (a plugin recommendation plugin :) ), and this plugin isn't activated for some reason, how will the site admin know that they need to install the Responsive Menu plugin?
• kamoha_event_list: Maybe its functionality is needed even when changing themes. But maybe not? I'm not sure.
• edit_posts_orderby_desc, edit_posts_orderby_asc: Both are used by kamoha_event_list, so if that moves out, they go with it. However, they're also used by part of the code in kamoha_modify_query regarding the meetings_category, so if these go, this part should go with them.

[leac]

CPT: http://www.codeinwp.com/blog/top-custom-post-types-plugins-for-wordpress/#ECT