WordPress Generators

At this point, it’s relatively easy to find a generator to do almost anything you want with WordPress. In fact, you can assemble an entire theme with custom post types, taxonomies, and options all without actually writing any code.


But you know what I’m talking about – generators are small web-based tools that are used to, er, generate code for you based on a couple of inputs that you specify on an interface.

Off the top of my head, I can think of…

  • Generators for custom post types
  • Options frameworks for easily creating settings pages
  • Generators for taxonomies
  • Custom theme generators
  • …and more.

Don’t get me wrong, I think that these tools have their place in the development space (in fact, my boilerplates have even been converted to generators!).

But as a profesional developer and someone who cares about writing quality code tailored exactly for the problem at hand and as someone who wants to create the highest-quality products that I can, I dislike WordPress generators.

And there are a number of reasons why I don’t use them:

  • WordPress Coding Standards. These are defined standards that are intended to be used in all WordPress-based projects. The ultimate goal is to provide the right way to write code for WordPress. I’d even go as far as to say that when developers follow coding standards it looks as if code is written by the same person. Without testing every single generator and every permutation of settings, there’s no way to know that the generated code is up to standard.
  • Debugging Sucks. We spend enough of our time debugging code and that’s why we write our own, but if something goes wrong with a product that you’ve released that is based on code provided by a generator, you have a layer of complexity through which to trudge in order to narrow down the problem. So it’s not enough to find bugs in your own code, it’s now a matter of understanding what the generated code is doing, the key/value pairs it’s creating, how it’s serializing its data to the database, and then determining how to resolve a problem that’s a result of code you didn’t even write.
  • You’re Shielded. If you really want to become a professional developer – regardless of if it is for themes or plugins – then there’s a period through which you have to suffer while learning the various API’s. Be it the Options API, the Settings API, the Transients API, the Plugins API, or whatever it is that you’re trying to pursue, you’re never going to learn it if you’re letting an automated tool generate the code.
  • Database Ignorance. In additional to generating questionable code, we – as developers – should be responsible for having a holistic view of the project that we’re working on. This includes understanding how the data is serialized in the database, being responsible and validating, sanitizing, and generally cleaning up the database when we’re doing. We need to be wise with our resources. Again, without spending additional time with the generators, it’s difficult to know how much we’re cluttering our customer’s databases.

I view software engineering as a craft. It’s a practice of identifying a problem, architecting a solution, and then implementing it using code. These are principles that are completely agnostic to what platform on which you’re working.

Sure, code you wrote two years ago probably sucks and code you write today will suck in a few months. But the point is that you’re writing code, you’re refining your craft, and you’re improving yourself.

Generators rob you of that.

With that said, I do believe that these frameworks and generators have their place in WordPress development. I think they are great tools to use when rapidly prototyping a project to make sure the core business problem is understood. I also think they are fine for putting together a quick demo, but you have to strike that balance – if you’re not careful, you’re piecemealing together a product and that’s not quality software development.

You can always default “to each his own,” but I call into question the integrity of anyone that brands themselves a developer but pushes products that have been assembled by nothing more than purely generated code.

Use generators when appropriate – for demos and prototypes, not products.


Join the conversation! 21 Comments

  1. Well said Tom. I had started using others code so I know how much time I had to spent while debugging.

    • Thanks Harish – I think that using generators can ultimately bring an unnecessary level of complexity in. If you’re not used to working with the WordPress API, it makes even that much more complicated when something goes wrong.

  2. I understand your view, but I disagree based on the fact that it’s generalized.

    As an example, when coding in dotnet a lot of code is generated by the IDE for you. That doesn’t mean it’s all bad.

    I think that generated code has it’s place beyond prototypes. It can and should be used in production. I argue that one should understand the generated code and ensure that it meets appropriate standards.

    Some people take pride in writing every single line of code and that’s fine. But it doesn’t take away from your professionalism if you recognize a tool and use it effectively if it meets your needs.

    After all, isn’t that why we’re all using WordPress to begin with?

    • Kevin – these are good thoughts and, for the most part, I agree with you, though I don’t think I’m being too general.

      For example, when you’re looking at code that’s generated by .NET, that ships with Rails, or that provides a framework for any other project (say CakePHP, Zend, etc), then you’re absolutely right – that’s either prewritten or generated code that’s meant to lay the foundation of an application so that you can focus specifically on the business logic – the domain – of the problem at hand.

      But where does the code generation stop? For example, Rails stills requires that you write your models to represent your database schema and the appropriate validators. .NET still requires you to hook up event listeners (or controllers if you’re using MVC) to connect the form elements to the appropriate handler.

      Similarly, that’s how I view certain aspects of WordPress – it provides the foundation on which you can build your theme, your plugin, or whatever project you’re working on. It can’t generate the dependencies (say, JavaScript libraries, the specific nuances of custom post types, some custom views that you may need) because that’s where the responsibility of the developer lies.

      You’re absolutely spot on with this:

      “But it doesn’t take away from your professionalism if you recognize a tool and use it effectively if it meets your needs.”

      And I’ll be the first to admit that I don’t aim to write every single line of code. That’s prideful and I’d argue that’s a trait of an immature developer. I’m a huge advocate for DRY and for if a library exists that already achieves what I need, then I can bundle it into my application, but there’s a different in using a dependency (perhaps a plugin – a jQuery plugin or a WordPress plugin – or some other library) to help you achieve a certain goal and using a tool to generate an entire theme.

      Ultimately, I’m more concerned with people overusing generators and not becoming familiar with the WordPress API to build less-generalized work than I am anything helps. Hopefully this clarifies that point.

      • Just checking :-)

        As an example, I use Custom Post UI to handle my Custom Post Types and Taxonomies. I would classify that along the same lines of the generators.

        At my 9-5 job (.NET development) I’ve written code generators for a lot of mundane, uninteresting tasks.

        • I view custom post types a like I do models – if the rules are more strict, then generators may not provide enough constraints around what needs to be done. On the the other, if you’re basically creating what’s essentially a post with some custom labeling, that’s another field.

          Like with your 9-to-5, I’ve done similar things, too. That’s definitely an advantage to being a programmer – automatic the mundane.

          And that’s where I think the line gets crossed. People try to automate what isn’t mundane and what should require a higher level of attention to detail.

  3. But whatever the tool, you’re going to find people who abuse it.

  4. This is my sentiment exactly. I use tools if the tool isn’t part of my install and if I can adjust the code to my liking, but no more.

    Examples are your plugin, settings, and widget boilerplates. I’ve used them, but I’m not bound to them. I also use Themergency’s CPT and taxonomy generators, more to remind me of the arguments available and help me think through my process than as a “do it without coding” mentality.

    Well said, Tom.

  5. I agree with this post but more specifically Brian’s comment, and actually work similar to him. Whenever I use a generator outside of WP, I make sure I examine and modify/format the code before adding it. I actually noticed a bug in the Themergency CPT generator because of this.

    • Thanks Kyle – and exactly.

      I think that budding developers often treat WordPress generators like libraries (or gems) in other platforms and they’re totally different things.

      …and props to noticing a bug. Did you open a bug report? I’m a fan of what the Themergency guys are doing (just as long as users aren’t abusing their tools ;).

      • Yes, I contacted them as soon as I noticed it. This was many months ago, and was resolved shortly after sending the bug report.

        One slightly off topic ‘generator’ I’m on the fence about is Advanced Custom Fields. I absolutely love it – it’s great for 90% of projects where you don’t need to do custom metabox styling in the admin panel. Creating lots of metaboxes manually takes time and a lot of code, but it does have some benefits and I control all of the code. It just pains me to use a ‘generator’ all the time. Anyone have any thoughts about this?

        • As far as I’m concerned, I typically just develop small pieces of functionality or utility plugins that I keep on file for later.

          It still requires a bit of programming but it saves some of the initial bootstrap code.

          • See I have done the same in the past until I realized ACF saves a lot of time, especially when you’re adding 20+ fields to a site. It would be helpful if I built a class to do everything I wanted to do, but then that’s basically rebuilding ACF (in a way). Still on the fence, but I appreciate the thoughts.

            Because of ACF, I think some generators are useful but you have to understand them and what they do. I’ve looked at the code of ACF and even picked it apart, so I feel more confident about it. The same could also be said about form generators (Gravity Forms) – we all know how to make them, but there’s a time and a place for everything.

  6. As a novice coder I pretty much agree with your thoughts Tom. They only way I will learn is by actually doing it – manually. Having said that I can see where generators may be somewhat of a time saver in certain situations for experienced coders.

    • Yep – I’m pretty much 1-to-1 with you. I think generators are also a great place for novices to learn how certain things are done – you get direct experience with the code that’s generated for the API and can probably get a better understanding of how to work with the WordPress API.

  7. There are always two sides of coin. Some of them love it some don’t.

Leave a Reply