How do you organize your plugins and themes code?

I starting working with WordPress as a CMS,开发者_如何学运维 now that the V3 makes it way easier to manage taxonomies and custom post types. My work is mostly focused on developing plugins and themes.

My biggest plugin does some admin stuff (add admin menu items and the related pages and features), but also does some importing and exporting, and hooks some of the base post processing treatments ("when a new post is created").

My biggest theme is pretty small, and all it does is display custom posts in a custom way.

After a few weeks of work, I have several thousands of LoC, and it's getting harder and harder to dig into it. Which leads me to the following question: How do you organize your WP plugins code? And what about your WP themes code?

several thousands of LoC

That's pretty epic! I've always found the beauty of WP is that I can, as jQuery put it;

Write less, do more!

You might be much better off using Pods CMS alongside WP to cut down your code.

This is how we structure client deployments that include themes, third-party plugins, and custom code.

• wp-content/plugins only contains third-party plugins, no code in here is modified, and the site should not be deadlined by any of these plugins being disabled / removed.
• wp-content/themes should contain the code related to presentation of the front-end. The trick is not not overload the theme (functions.php and other theme-related files) with code not directly related to presentation.
• mu-plugins/ contains all of your implementation-specific business logic. Things in here should never be disabled, and are required for operations.

That is avery brief summary, but in a nutshell that is the logical compartmentalization of code that we've found to be most failure proof.

Why not to split plugin into several files by function? The same goes to themes. Any problem you have with that?

There are basically three ways you can do this: prefixed functions, with require_once's including files by functionality, which is quite common.

The other "right" way that's touted a lot is having one giant class with all your plugin code in it. While keeping things nice, as you said, once that file gets into the thousands of lines of code, you're screwed for manageability.

The way I like to do it is a way coming from my C# background - have one main plugin class, and other "worker" classes (you can put them in a namespace to keep classnames short). For example, have a class dedicated to the admin section (it can have its own little "subclasses" too, say one for each page). It'll take a while to refactor all this code into the different classes and files, but it'll be worth it - it'll be much easier to keep track of everything, as well as for example getting people to work on the codebase together. It also forces you to think more of how your application all fits in together, which lends to better thought out code.

I'm actually writing an article series about this, outlining the three different methods. You can take a look at the first instalment here. There are two more coming in the following weeks.

Hope I helped!