design and development workflow

We’re developing a set of websites, complex ones with a lot in common, and the company have decided to use WP as a base CMS.

As in every site, there is a design process, followed by HTML, then development/CMS integration. However, I’m wondering how would that work with WP?

Read More

Do companies design all templates, then HTML, and then theme and CMS development, or do they finish the CMS development (which in this case a layer of custom plugins extending WP), then create individual themes that works on it?

As time is crucial and many people are involved -which raises the cost- , I would want to raise efficiency of the team and make design and dev teams work in parallel.

Any idea of what the sequence should be are appreciated.

By the way, we have common features amongst the sites and then we have site-specific features, which you can think of as theme specific features

Related posts

Leave a Reply

4 comments

  1. If you are comfortable with a source control system such as git – one approach I have used successfully is to create a ‘lowest common denominator’ theme with all the standard functionality shared between the sites and nondescript styling (black and white, standard reset and typography styles etc).

    Then to do a new site, branch off from the master branch and do the site-specific CSS etc to create the design for the individual site (plus extra template / PHP code if necessary to add functionality). If you have a solid master theme you should it will be a lot less work to build a new site than if you had to start from scratch. Also if the designers are creating PSDs a good front-end coder should be able to code the design from the PSD on top of your master theme fairly easily.

    Also, if you discover something like a security bug or something breaks in a new version of WordPress you can make the changes in the master and cherry-pick the changes into individual deployed sites.

    Of course this is only one way to do it and if your sites are very different you might want to start new themes from scratch… Hope this helps.

  2. Personal recommendations

    Most important: Don’t try to do everything on your own. In most cases it’s cheaper and better

    • to donate to open source plugins.
    • to drop your own code and replace it with some open source lib and start contributing there (some have GitHub repos) – I dropped my own set of meta box classes library and now work on Rilwis Meta Box class lib.

    Themes, Plugins and parts

    I have a basic framework/library/wireframe that serves as parent theme. Then I add a child theme that does the bootstrap and loads from the parent theme, what’s necessary. This way I can update my changes directly from my main repo and keep the project specific stuff separated in a child theme.

    Plugins

    Bigger parts and those that need to intercept pretty early are kept in a plugin. It doesn’t matter if I use functions.php include modules, template_parts or plugins. The only difference is the access to hooks. And here plugins, mu-plugins and dropins work best. My personal recommendation is to keep functional stuff in plugins

    Themes

    Themes are IMHO more the view part of the story. So I try to stay clever and keep them as “micro” as possible for reuseability. In my case they only contain standard mark-up and get rendered from my custom library parts. So the mark-up gets only new classes from some css framework and the functions that echo stuff are just definition-callers. This way you can rapid prototype in the sense of the word: Rapid. If your custom plugins or theme parts are smart enough to spit out dummy content as default, then you can easily make sketches, your designers can work with.

    An Example of what I’m talking about is the default image function, that you can take a look at this trac ticket in the patch i provided.

    Commenting on the ticket is highly appreciated and maybe brings it into the next version!

    SEO

    This one’s – like some other bigger parts – better kept on specialists side. Just go with one of the defaults like wpSEO from Sergej Müller or the one from Yoast.

  3. Typically when I start a theme from scratch, I start with the design, then the HTML, and then WP integration. It’s definitely the easiest way to get the job done for themes but I think plugins are different.

    When I start a plugin, I usually build all of the functionality into one big PHP file, and split it up as I go, building it piece by piece.

    While plugins and themes code are nearly identical, and can (for the most part) have the same amount of functionality, it really depends on if you want plugins that you can copy and put on every site, while adding certain features to each site/theme individually, or a theme that you could essentially copy and modify with the site-specific features, so long as that theme has a good wireframe for editing the design per-theme.

    You can usually take code out of a plugin, put it in your theme’s functions.php file (with the exception of changing some file paths) and it would work the same.

    I hope this helps to guide you in the right direction.

    Edit:

    On a further note, WordPress also has a MultiSite feature that you can enable and use the same plugins throughout your entire site network, while installing separate (or even the same) themes for each site. Documentation on this is here.

  4. Great question! Here’s my suggested workflow:

    First, use WordPress Multisite, as this will save you a ton of time, money, energy, resources. Use the Domain Mapping Plugin if you need each site to have a unique domain.

    Develop one parent theme and make your customizations using Child Themes. This way, you have a core set of files that you add to and don’t repeat your efforts with every new site. If you need a good theme to get started with as a parent, Automattic made one called Toolbox.

    Become masterful with writing your own plugins, and then with Multisite you can automatically enable them across all sites, or you can cherry pick them. It’s a great workflow. I’ve been doing this for a number of years, and it’s a terrific workflow that allows you unsurpassed system management, DRYness (Don’t Repeat Yourself), security, and agility.

    If you have any more specific questions about workflow, i.e. deployment routines, don’t hesitate to ask!

    Cheers~