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!
Related
I have built WP sites in many different ways over my career, and I am always curious of peoples' methods for building custom WP sites. In the past, I have done everything from hacking together premium themes to do what I want, to building each file in my theme from scratch. Over my evolution as a developer I have currently become mostly satisfied with using a 'starter' blank theme like underscores or understrap. I then use ACF Pro along with custom post types, and that usually covers the majority of what I am trying to accomplish. I have a design background so I design my own stuff sometimes, and I also work with a few very talented designers that push their designs, which I love. This frequently requires highly customized layouts, headers, and footers that I try to couple with an intuitive backend, so the client can change any content on the fly, while having some control over appearances like placement and adding columns.
Second to the Underscores / ACF method, I and surprised how easily I can accomplish the same result with something Like Divi (page builder), where I almost total freedom with code, templates, and custom react modules. Also, the client still gets a drag and drop product that looks very nice on the backend. Sometimes more so than my preferred method. Through both of these methods I always use a child theme so I have very few boundaries when building stuff, but still get to benefit from the theme updates without everything breaking two years down the road.
These are just my own experiences, and since there are many people on this site that have far more experience and know-how than I do. I am interested to here how other people go about always starting with a versatile theme. I am open to trying new types of themes, and also ways to build custom fields, meta-boxes, and taxonomies.
I'm working on a premium theme for WordPress, it's my first. My question is how modular should/can I get my code before it gets to be a problem for the server or other developers who buy my theme?
For example I have 3 custom post types with taxonomies and custom column headings. Should they all be in one php file or can I break them up so that each post type is in its own file?
I'm thinking that for future projects more modular is the way to go so I can just drag and drop the pieces that I need for that project. I don't want to make my theme any slower though so I could use a little advise on how granular to make my files.
I've bought themes in the past that have both extremes but want to set myself up properly from the start.
Thanks.
This is an opinion request this one because either approach works and based on this information plus the fact you seem keen on individual files. I would encourage just that.
Modular approach works with themes if you plan to provide the same functionality per theme as you won't need to edit functions per theme. I would go with individual files and just put them in a folder. If one of those files has a bug you'll be quick on applying the changes to all the themes you create.
If you put all the functions in one file and each theme gets its own versions of those files due to requests etc. Then you create a little more work in that you copy and paste code. Not a lot of work but then that demands on just how much that single file changes over the years or even within some months.
There is nothing wrong with many folders and files. It won't have an effect on loading. It would take hundreds of include() or require() before it becomes an issue.
I'm migrating a site from a proprietary cms (reddot) to drupal. For all its flaws, reddot has a very simple yet flexible model:
templates consist of markup with placeholders for variable content
every piece of content, from a full page, to a shared piece of sidebar content, and even a single image can be built from a template, if an appropriate one exists
My first impression of drupal is: woah, this is complicated! Rather than three simple objects, now i'm dealing with nodes, pages, blocks, regions, views, panels, etc. What is the simplest way to recreate the template/content/placeholder model that i'm familiar with?
Reddot uses a rather well architectured MVC-alike system. In addition, from my limited experience, Reddot follows the there is only one way to achieve Foo-philosophy.
Coming to Drupal, especially as a frontend-developer you will be dissapointed, lose a lot of hair and probably curse a few times when you realise everything has to be done all over again.
Coming to Drupal you will love the gigantic amount of (unfortunately unorganised) documenation and its flexibility and enormous amount of new posibilities.
When people come from properly architectured systems into Drupal, I advice them to do one thing: become pragmatism-exstremists. Don't (ever) try to make things proper, clean or well-thought out. You will only be able to do that once you truly grok Drupal. And that only comes with a lot of experience. Just fiddle untill it works, close the code and never look at it again.
First thing you will need to learn, is Drupals PHPTemplate engine, which is rather different from Reddots, but has a lot of similarities. Where Reddot uses RenderTags, Drupals PHPTemplate uses plain old PHP.
<%!! Context:CurrentPage.Template.Name !!%>
becomes
<?php print $name ?>
And yes, $name is entirely globally scoped. Remember? I told you to be a pragmatism-extremist. Don't even think about namespacing, object scoping and such.
Want to know what variables you have available? Just do a <?php print get_defined_vars() ?>.
Want new variables in your template? You need to preprocess them.
Want to change, alter, strip or modify existing variables? You either need to preprocess, or template override or even write new modules that make new or different variables available?
Knowing which to choose, when to preprocess, when to create modules, when to override, when to implement hooks to alter stuff is experience.
Drupal has never thought that out clearly, there is no general rule or best practice, other then the last eleven times that Foo-concept did not work out, maybe Bar proves the best.
Drupal's templates are similar to what you describe of reddot, but there are probably more options and they can be nested. To get a good sense of how the templates work together download the Theme Developer module and watch the associated screencast.
To get a sense of the "placeholders" you can use in a given template, visit the api.drupal.org page for the template file or check out this Drupal 6 Theming Cheat Sheet.
Another one bites the dust.. ;)
Let me know how you go with the migration Bobby Jack.
I think for the content you might be able to create an XML variant in the CMS and export everything to re-import it to Drupal..
On the Drupal note: Once you get your head around the concept of templates being able to inherit/being overwritten it's easy.
It's like a set of pre-assigned content classes in RedDot which can change to render them in a different layout. Similar to the "replace content-class" functionality.
I am a Wordpress Theme Developer (Freelancer) and I make somewhere between 1-2 Themes / Week so I need a Quick way to make this happen.
Examples:
I use twentyten every time, delete the functions that I don't need, the CSS, images etc. I kinda let it "naked". (Not a quick way, maybe a personal framework?)
I search for Wordpress functions (since I can't remember all of them), on Wordpress Codex and again, not a quick way. So, do you guys think that a personal Function DB would be ok for me?
And more other stuff that I can't remember right now.
How do you guys organize your workspace?
If the themes you make are fairly similar, you might want to create that "naked" version and keep that as your base for future work.
I've created a handful of themes myself and I followed the same approach. I take that base theme and create new versions of the particular files that need to be customized.
However, if your themes vary quite a bit in form and function (being a freelancer, I'm certain they do), you may still want to create a library of functions and stylesheets rather than re-implementing everything for each project. Even if it means creating functions that call single Wordpress functions with default values, if it streamlines your workflow then it is well worth the minor overhead.
I think it's really a matter of personal preference, what works for you, what's easy to remember, what makes sense to you, etc. If you like starting with a stripped TwentyTen theme, then take that theme as a whole, strip it of everything you don't want, and then use that as your starting point for each theme you build. Certain functions that you find yourself using over and over, you could simply place in the functions.php file, in the theme folder. Then, which ever functions you end up needing for that specific theme are there, and the rest of them you can delete once you've built the theme.
First, it would be useful to develop your own theme as a starting point. Ripping stuff out of twentyten is really inefficient. If you develop one that has everything you need, you can do the second step:
Use child themes. A child theme will keep the parent untouched and you only have to change the things that you need to be different and add a new stylesheet. A big benefit is that it only consists of the stuff that is specific to that particular site. The generic stuff stays in the parent theme. Also you have the benefit of updating the parent easily and adding upgrades across multiple sites quickly.
A good starting point might be to try one of the frameworks like Thematic.
Also take a look at Automattic's toolbox theme. Twentyten is kind of messy and bulky. Toolbox is actually meant to be used more like you are using Twentyten.
I've been coding in PHP for 4 years and even I find it so convoluted and hard to grasp. I have no idea how they expect designers to manage theming.
I know basic theming, theming with tpl files, views templates, contemplate templates etc. However I get lost whenever I enter the template.php file.
I needed to theme a node input form for a custom content type. I wracked my brain over it with like 7-9 tutorials and it's still not coming together. I understand why module building can be complicated - because most people who work with modules are developers anyway.
However, when even a developer can't understand theming, it's definitely over-engineered!
Maybe it's my fault, maybe I didn't learn Drupal properly. In that case, is there a step-by-step system to becoming a Drupal guru?
Theme is really not that difficult, if you only know basic php. You have 3 ways of altering the markup, the css and js, you should be able to handle.
Template files. By creating a template file in your theming and naming it correctly, it will take precedence over other template files, and you can thus create custom markup for views, nodes etc. By creating a template for a noce type, you can do stuff like printing out the cck fields in any other instead of using $content. All you need is on the node object.
Preprocess functions, which are placed in your theme, will give you the possibility to add or alter variables that will be used in your template. You name the functions like hooks: yourtheme_page for the page template yourtheme_node for the node template etc. Here you can create some custom logic, or modifications, to help make your templates more clean and just handle the printing of the variables.
Theme functions. You can overwrite theme functions to alter the markup that's used. You only need to create a function called yourtheme_[theme_function_name]. You don't need to understand much php to do this. Often, you can just copy the original theme function, and make a few alterations in it to get the markup you want.
With the above you can do 90-95% of what you need. Forms are a bit special since you in Drupal 6 can't alter them (easily) in your theme. Instead what you want is to create a small module and use hook_form_alter, which allows you to modify the form, text used on buttons etc. This is changed in Drupal 7, which will be even easier to theme.
So it really isn't all that complicated, just use the 3 basic tools described above. The tricky part can be to name your functions and templates, but devel themer can help you with that. Another tool you use is devel which can assist you in printing out variables so you can inspect them and see what you have available, fx CCK fields on the node.
Maybe you should get a copy of Front End Drupal.
In my opinion, Drupal theming is not difficult once you wrap your head around the concepts like templates, overrides, .info files and preprocess functions. Those things are not directly related to php skills, it's all about understanding the system.
It's interesting to see that you're a themer, yet you only talk about php, not CSS and HTML. In my experience, a lot of theming tasks can be accomplished with CSS, without even touching php.
Finally, I don't know if you are using a base/starter theme (like Zen or Genesis) already. I recommend using a base theme and realizing your own design as a sub theme.
Most people get an 'ahah!' moment when themeing suddenly starts to make sense.
I'd argue that this is probably tougher for experienced PHP developers, since you have to get past a lot of concepts that don't make sense in vanilla PHP ("the function is magically called at the appropriate time ... because of how it's named?!")
#googletorp's answers is pretty comprehensive, so I'll just add some practical tips that helped me along:
1) Try building a module that implements it's own themeable output and simple hooks. Hooks and theme functions make a lot more sense when you see how modules are actually calling them and using them.
2) Make liberal use of the devel module, especially the Theme Registry menu (note how it changes when you add a new theme function), the 'Render' tab, and the dpm() and dvm() functions
3) Buy a old-tyme dead-tree book on Drupal themeing. The online docs are really outstanding if you already know what you're doing, but can be extremely confusing if you're not sure what you're looking for.
4) Empty your cup. At the theme level, PHP is really just for simple logic and syntax -- almost everything of substance is getting handled by Drupal API functions. Try to think like a Drupal developer and not a PHP developer (i.e. don't assume you know how to do something just because you built a vanilla PHP site that does the same thing) and you'll have an easier time.
Keep with it! The theme system is actually really easy to use once you've figured it out.
to answer your question on why it is so hard:
Drupal themes may seem overwhelming, due to the sheer amount of possibilities, see #googletorps answer for a good overview.
Having "many ways to do one thing" brings power: power users can choose the best of all possibilities. But it also brings complexity: new users don't get a good lead, because there is no "you should do it this way. fullstop."
Alongside that amount of ways to get stuff done, there is the problem of nesting. Drupal has a concept of very deeply nested items. To take a random, yet simple example:
username<menuitem<menuitem<menuitem<menu<block<region<page.
Will render a menu-item, containing a username in a three level deep menu-item in a sidebar-block.
Where most templating-environments have concepts of a page, containing several "contents" that, at most, might contain some partials. the nesting is at most three levels deep. And each level has a clear, distinct area of expertise. Drupal does not have that: the nesting is fairly arbitrary. And each nested item is no different from its parents. This, again, offers power-users a great concept and power to work with, but is hard to grok for new developers/designers.
Lastly, another reason why it is hard to learn, is that the Drupal online documentation is more a wiki then a read-from-begin-to-end manual. There are great books that fill htat gap, you will have to buy them, though.
If you haven't seen it already, this is a great presentation on why Drupal 6 theming is difficult and how it is improved in Drupal 7. There is hope! The video made more sense to me a second time watching after more experience theming.
http://sf2010.drupal.org/conference/sessions/design-and-theming-whats-new-drupal-7
One of the biggest tricks is to override something that is normal rendered with a theme function into a template. This gives you much more control over the markup, and also lets you use the preprocess functions to manipulate the variables before handing it over to the template.
This is a huge boon to theming forms. See a short video that explains it better than I could here: http://drupaldojo.com/session/fine-tuning-ui-theming-forms-drupal-60