Posted on

Why Portfolio Functionality is Best Handled by a Plugin

When it comes to adding a portfolio section to your WordPress website, there’s more than one way to do it. Before taking a look at three most common ones allow me to explain why allowing a theme to handle content generation usually isn’t a great idea.

For those of you already running a website, WordPress or not, it is very likely that it’s your content that defines you. Not shiny buttons or complex banners, content. You don’t want what ever it is you’re currently wearing to define you as a person, same should apply to your website. You could switch to another WordPress theme that completely changes the layout, your content must remain the same and all the data should still be there.

If you think of your website as an Oreo biscuit, tools that allow you to generate content (WordPress installation and maybe some plugins) are the bottom part, your content is creamy middle and top part is what site visitors see (normally, this would be WordPress theme you installed).

Try combining top and bottom parts — yes, you’d have to crush the biscuit — and see what that does to the middle. Not as pure as it used to, with all those crumbs in it and parts of it falling off.

Crushed Oreo biscuits

Themes that Register Portfolio Custom Post Type

This is the crumbled Oreo. It can still be delicious but restoring its original look is very difficult. Take a look at this scenario:

  1. You just set up a new website, installed WordPress and picked a theme that has “Portfolio” menu in the dashboard
  2. You add projects for several hours until all of your work is showcased
  3. Everything looks great
  4. A year later you want to refresh your website and pick another WordPress theme
  5. You install the theme and “Portfolio” menu is either gone completely or it doesn’t show any of your projects
  6. All portfolio projects URLs now return 404 errors
  7. You panic?

Worst of all, what happened there is not a bug. The first theme you used registered a custom post type, let’s say it was called ‘theme_1_portfolio’. The second one either doesn’t register a post type for portfolio at all — “Portfolio” menu is gone — or registers ‘theme_2_portfolio’ post type, keeping “Portfolio” menu, but not showing any of ‘theme_1_portfolio’ posts.

Luckily, all of your data is still in your WordPress database, it’s just that you can’t see it. Unless you value a theme more than your content I can’t imagine you being OK with this. Never let a theme do plugin’s work.

Themes that Use Posts or Pages to Display Portfolio Projects

This method is much better because it uses WordPress native functionality to add projects to the database. No matter which theme you install, your posts and pages will always be there.

What these themes do is simply apply a different layout to posts from your designated portfolio category or pages that use portfolio project Page Template.

The problem with this is that posts and pages are not exactly what you think of when you hear the word project. There’s also the extra hoop to jump through by assigning a certain posts category to be your portfolio category or using a certain Page Template for your portfolio projects. But at least switching to another theme won’t hide your projects.

Portfolio Plugins

As you know, WordPress doesn’t have portfolio functionality built-in. Yes, it is possible to interpret posts or pages as freely as you’d like, but they will still be posts and pages pretending to be portfolio projects, even if no one but you knows.

Plugins are what adds functionality to WordPress and because of that they seem like a logical choice for adding portfolio to your website. A portfolio plugin would:

  1. Register portfolio custom post type and any related custom taxonomies
  2. Try to use the template file in your theme that is in charge of showing single posts as base and add any additional project data (usually stored as custom fields) to it

This way you still have a separate “Portfolio” section in your WordPress dashboard and your projects are not allowed to mingle with your posts and pages, but they also won’t disappear when you switch to a new theme.

And that’s what we’re working on here at ThematoSoup. A simple, yet powerful WordPress plugin that will allow you to add portfolio section to any WordPress theme and keep it the moment you decide there’a better theme for you out there.

Binder portfolio plugin settings
Binder portfolio plugin settings

We do have most of it done, but if you’re in need of such plugin, you can help make it better by letting us know which features you’d find most beneficial.

Is one custom taxonomy enough, or would you prefer to be able to register as many as you wish? How about custom fields, would a pre-defined set work, or do you prefer to set your own? Help us make it better.

Free Marketing Updates
Get the best marketing practices in your inbox.
We always respect your privacy.

Slobodan Manic
I love working with WordPress and doing it the right way. Themes and plugins I develop have a common #1 goal: Keeping it as simple as possible for users to publish their content.
Slobodan Manic


Web consultant with 10 years of experience in web development and web analytics.
Slobodan Manic
Slobodan Manic

Latest posts by Slobodan Manic (see all)

21 comments Why Portfolio Functionality is Best Handled by a Plugin

  1. Oreo biscuit example is really exceptional. I totally agree with your points. Theme should handle styling and plugins should handle functions. I thinks its the way it should work. Due to the misconception – “Plugins slow down WordPress” many developers are including code in the theme. Pretty bad thing I say.

  2. Ramsay,

    Thanks for your comment. You’re absolutely right, it’s not plugins code that slows a website down, it’s bad code, no matter where it is located. Simply moving it to functions.php will not solve a thing.

    There’s only one way to see themes stuffed with plugin features – an attempt to trick the user into thinking they’re getting “more for less”, while what they’re actually getting is potential headache.

  3. I think the post types should definitely be registered via a plugin for convenience if the user ever switches themes. But I am not a huge fan of having the front-end display controlled by the plugin.

    I recently switched to using plugins for registering custom post types in my themes at ThemeForest…what I found out was people actually really disliked it and as you might image people started hacking away at the plugin even though all the necessary filters were in place for modifying things such as labels/slugs.

    I’m switching back to a built-in system that will run if the custom post type isn’t active and provide the plugins with my themes for those who do ever decide to switch themes. That way hopefully I can please everyone ;)

    But anyway…looking forward to see what you guys come up with!

    1. This is a great point AJ.

      I’m not crazy about plugins handling front-end display either, but what we’re trying to do is sell plugins independently at CodeCanyon (so plugin has to be 100% functional regardless of it being supported by the theme) and have a standalone theme shop where users will be able to first select a theme they want and then decide which features they want in it.

      For example, a theme with no extra features would either be free or have a certain price, then if you want to have portfolio in it, a certain amount is added to the price, same thing with events management, author box etc. And for our themes, plugins like the one that handles portfolio won’t be handling front-end display at all, because they’d check if a certain template file exists before they do:

      if ( '' == locate_template( 'single-ts_binder_portfolio.php' ) ) {

      Not sure how much sense this will make, but only one way to find out I guess.

      But I do like your solution of providing plugins to be used as fallback when a users switches theme as well.

  4. Great article – I agree that portfolio post types should be handled in a way that’s theme-independent. I’m really eager to see how that plugin you’re working on turns out. I’d love if it had several built-in display functions: the two I’d see as most useful are box/card display and a slider. And I’d also love to be able to have options to call the portfolio display with a shortcode and with a php function.

    1. James,

      Thanks! Great ideas there and actually that is very similar to what we’re working on (several display modes, shortcode).

      One thing that we’re still trying to figure out the best way to use full width template or add ability to select which sidebar is shown in portfolio custom posts. So far, nothing I’d say I’m happy with, but I’m sure we’ll work it out.

  5. You’re saying that layout should be defined in the theme, right?

    Then why are you having fields for sliders, etc. In the plugin setup? What if I don’t need a slider in my portfolio? What if I want a theme which displays my portfolio items differently?

    The problem here is the WordPress itself, it is a blogging platform, not a content management system. All this crap with custom post types, meta fields and taxonomies is simply wrong. It is pushing round pegs in square holes. Hacking all the way. Borderline between plugins and themes is blurred and there will ALWAYS be cases where one must change the code of theme or the plugin to setup things right.

    Sisiphus task, if you ask me.

    1. Layout is definitely theme teritorry and you shouldn’t judge the plugin based on an early settings page. Besides, there is an option for plugin not to do anything but register custom post type and taxonomy, step aside and let the theme take care of layout (not shown in the screenshot, but that’s really not what the point is). So, you’d be able to both not have a slider in portfolio items and let theme display items differently.

      Ideally, plugin would do nothing more but extend WordPress functionality and let the theme display content. That way nothing is blurred, but that makes it tougher to sell both themes and plugins. But if there’s one really good plugin that handles a particular functionality well (like WooCommerce), then theme developers can focus on developing themes instead of crossing the line.

  6. OK, you’re right, portfolio is a plugin territory, not theme. What I expect from a portfolio plugin :
    as many taxonomies as I want;
    ability to have different categories and different layout for each

    Looking forward to test your plugin!

    1. We were actually going to use just one taxonomy, and allow themes (or other plugins) to hook in and register more, if needed. Would that make sense?

      “ability to have different categories and different layout for each”

      For example, you’d need to display photos archive in one way, videos archive in another etc?

  7. I suppose it all boils down to the user, for myself, creating and developing my own theme, which will be succeeded by another own developed theme (when i get time) then not necessarily relying on to many plugins is ok. For the general user, which is now literally anybody thanks to the evolution of WP then I would agree.

    1. 100% correct, but to make myself clear, this post (and pretty much any other post I write here) is about best practices for developing public WordPress themes.

  8. Such a plugin would be great. Top of mind suggestions: 1) Granular on-off control over author, date, comments, likes, etc. 2) Option to enable or disable “prev-next” icons or text (and position choices for these such as top or bottom) for quick movement through posts. 3) Several layout choices with options for each category.

  9. Since most of my portfolio work would be with graphics, or website screenshots, I would appreciate a plugin that is coded for speed, which potentially allows larger portfolio photos to be displayed minimally or with easily access class/id names so I can customize with CSS.

    The problem with images, especially larger ones, is that you have to consider the size of the image. I carefully optimize my images before uploading them, but not everyone does that (or seems to know to do that *grin*) so any way to further optimize the image(s) used within a portfolio would be great.

    Also, if you have a featured image which would display in a portfolio archive/category/display page that is configurable (so if I wanted 2 or 3 columns on that page I could click a button and make it so, with the images are adjusted as well!). I’m not sure I would want a slider for displaying the portfolio on the actual “portfolio” page, but a slider that I can pull onto the home page of just portfolio items would be great if it were included as a shortcode or added easily in some way (while I could figure it out I’m wondering how easy it will be for clients).

    Basically I’d want to be able to pull the portfolio projects onto other site pages — so potentially a slider shortcode, a widget possibility, a configurable display for the main projects page … does that make sense?

    Other than that, well coded with best WP practices in mind, with CSS that can be added to the main CSS style file easily (not always an option but one I appreciate so I can load all my CSS in one stylesheet easier); scripts that are minimal and able to be accessed if needed (for instance some themes/plugins already load some scripts so being able to click off one script or another would be a great way to reduce loading of unneeded scripts).

    1. Katrina,

      Thanks for commenting and for very useful insights.

      I agree handling images is an important feature in a portfolio plugin. For themes that are developed with WordPress best practices in mind and set $content_width variable, it’s easy. For those that don’t, things get a little bit tricky. Perhaps a field in which users can set content width could do the trick, but that would require them to know exactly how wide their content area is, and that could be a problem.

      Slider shortcode, a widget possibility, a configurable display for the main projects page — yes, it all makes perfect sense and belongs in a portfolio plugin.

  10. I use a plugin which handles all of my custom post types and meta fields, so switching themes (something I don’t do often, I create my own) wouldn’t have any effect on the data on the backend, I just need to make sure my theme uses the correct post type names.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.