I have a regular and mobile theme for a site; there are currently a couple of duplicate functions in the template.php of each theme, which do some text munging on the same fields. That is, the markup is the same for these fields in both themes.
How can I impose DRY and only have the logic in one place?
I understand I could make the regular theme inherit the mobile theme, but this doesn't seem like a "proper" solution, since the themes are quite different at the end of the day. Even more so as this would require ex-post-facto manipulation of the preprocess functions, and overriding mobile CSS and JS files - seemingly creating as much work and future WTH as it solves.
Thanks!
I would love to see the proper answer for this.
All i can think of is making a module that holds the duplication of functionality. A library module if you will.
So I'm making this "answer" as a conversation starter.
in: (mobile)template.php
preprocess_page(&$vars){
mymodulename_pagepreprocess($vars,'mobile');
}
(desktop)template.php
preprocess_page(&$vars){
mymodulename_pagepreprocess($vars,'desktop');
}
You can have preprocess-functions in modules as well btw. But it might be nice to send witch template as an argument.(you could however extract this from the global $theme)
How about you make a base theme which holds the functions, and implement both as sub-themes of it.
Or just the mobile theme a sub-theme, and the PC theme is the base?
Creating a sub-theme
Related
first approach to CMS and wordpress I'm wondering if there's any predefined html structure and classes/IDs "must-be" reference that I can refer for making my own theme willing to change in the future for another wordpress theme
thanks
Luca
There are a few other 'template' themes that could get you started - if Starkers isn't quite your thing, you might find WP Framework a good alternative. Or - just start stripping down the Twenty Eleven theme to give you a base (which is just what the Starkers theme does, using the Twenty Ten theme as a base).
There's also quite a handy first-time guide on the WordPress Codex around theme development if you'd prefer to start from scratch.
Wordpress doesn't require you to have any specific classes or IDs in your theme in terms of the HTML and CSS, the only things WP needs are things like the wp_head function inside your element on every page. Having said that themes such as Starkers were created to enable developers to have a starting point instead of starting from scratch.
Now the above applies only to whatever code you write, there are however some functions in WP that will return standard code, for instance if you don't specifically create the comment thread code, WP will generate it for you, and that is really the only code that many themes will share.
I would say that if you are intending on making a number of blogging themes for instance, having a set of standard code might be a good idea, for the article pages for example, so that you don't have to re-write code over and over. Aside from that the only code I ever reuse when making themes is the CSS to style comments if I don't hand-code the comments section, this is a good idea as it will save you a lot of time.
Wordpress provide some functions which add CSS classes depending of page type, templete, conditional tags . . .etc.
These functions are body_class() and post_class().
For more info check:
http://codex.wordpress.org/Function_Reference/post_class
http://codex.wordpress.org/Function_Reference/body_class
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
What think to be consider when you prefer coding a solution in form of child theme rather then in form of a plugin ?
Themes and plugins solve different problems: plugins are for business logic, themes for presentation. They are not interchangeable. I prefer the right tool for the right job. :)
i prefer in child theme (or in function.php), rather then in form of plugin. It's more easy to reuse. You can just move it from one theme to another.
Any generic functions should be in a plugin. That way, they are available to all themes, and if you make changes in one place, you don't have to copy and paste to several files.
The benefit of a child theme is that you can make changes to an existing theme, such as twentyten, without directly modifying the source code, which is fragile -- it can cause errors and has to be repeated every time the theme is updated.
Depends on the situation. If it's something that could readily be used by any (or many) different sites regardless of the theme, I do a plugin.
If it's something specific to This Particular Site Only, I would probably put it in the child theme's functions.php. Even if specific to the one particular site only, I might make it a plugin if it's something I might want to turn on and off later.
Other than the fact that you can turn plugins on and off, there is little if any difference between code in a plugin and code in functions.php.
If it's something most easily coded straight into the theme (e.g. a particular permutation of the_loop) then of course just do it in the theme template and put supporting code in functions.php
For creating wordpress themes, people usually follow one of these two methods
Design Mockup in photoshop or similar tool and code the HTML & CSS from the scratch
Choose a base theme and design the mockup keeping the base theme in mind and code on the selected base theme.
Which is the better way of these (or anything other than these) on tackling the Wordpress theme creation?
It depends on what you're trying to accomplish. I lean and develop using Option 1, with using option 2 as a way to glean ideas from.
The main reason is that the photoshop mock-up, no matter how close you ask the designer to follow a existing template, "usually" is different in some fashion, so that by the time you get into the middle of the theme you find that the existing template you could modify doesn't accomplish everything that the client is asking for (unless the client is a relative, in which case you could say too bad).
The other reason is call scope creep. Meaning that the original scope that was presented has now grown past your theme. You'll then have to ask yourself if you can dive into someone elses code and figure out what they were trying to do and then see if you can hack it up enough to fulfill you clients new requirements or if you're better of developing from scratch and then when scope creep comes up, you know right where to go/do in order to meet their requirements.
Anyways, something to think about.
It really depends on what your company/client requires. If they have specific requirements that cannot easily be met with a theme, you'll probably be better with option #1. If they are asking for a design submission, and are leaving the implementation/design up to you, go with option #2.
Some of the premium wordpress themes out there are quite good. Note that for either tool you'll be doing a mockup in Photoshop, so start with that and see what your company/client thinks.
You'd probably want to use an existing theme as a base for a new theme, or at least as a reference, for knowing which Wordpress Codex functions to call to retrieve data to use in your theme.
The HTML/CSS design is only half the solution - you still need to retrieve the data from WP to show.
Use Sandbox to start your theme with, it is free and it gives you many classes to do a lot of the design tricks you see is great wordpress themes.
http://www.plaintxt.org/themes/sandbox/
Another great theme to start from would be Thesis:
http://diythemes.com/thesis/
I always start from a theme that allows me to do things easier in the long run.
I always start out with a Naked theme (like Starkers, by Elliot Jay Stocks), and otherwise build everything from scratch.
If you want to save time, or are not (and don't care to become) very familiar with Wordpress PHP logic, then I'd start with an existing theme.