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.
Related
Im working on a wordpress site and right now a lot of elements has the same id which makes it difficult to customize.
Right now my solution is to add changes to all of the elements which isn't feasible, the difficult part is I am unsure of how to add an ID to the specific element.
Do I do this in the css file or do I edit in php somehow?
Or is it possible to add an ID with some plugin or similar?
There is no short or easy answer to this.
The best way to figure out what's broken in your theme is by looking into the files it contains and how it works. I could not find the Cherry theme that you mentioned in your comment so that I could take a look.
Of course, to understand what's going on you're going to have to know a good amount about how themes are written. I can't suggest a better place to start than the Codex article on theme development. You may get better results (depending on how you learn best) from a web search for something like wp building a theme. I did and I got this and this but I learn best by reading; maybe videos will help you more. Unfortunately, you really won't be able to eliminate this step and it takes time.
Your theme most likely -- if it has been built in the WordPress way -- uses a series of included templates with the get_template() call. As you're looking, this is probably what you want to look for. I remember the first time I dissected a WP theme it was a daunting task and I had already been a very experienced developer for a long time at that point. Don't be discouraged.
Some themes and plugins use actions and filters to allow modification of their content. If your theme does this, modification could be as easy as hooking on a few of the right ones. This will still require figuring out which hooks to attach to.
I may be able to update this answer with something more specific if you point the first 5 or 10 hierarchical children directly below the <body> element in a typical page, like your home page or your blog page.
If this seems too complicated, you're probably best to consider hiring someone who is more familiar with WordPress theme modification to help you out.
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 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!
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.