Could you tell me whether several generations of inheritance is possible for WordPress?
A theme
A child theme
A grand child theme
If it is possible, could you tell me how to do that? I have failed.
Why do I need that? Because I use one theme on multiple sites. I have organised a child theme and I modify it constantly, improve it.
But some of the sites may need special functionality. Nevertheless, shese sites should also benefit from general improvements I made.
Please, don't suggest using plugins for modifying the functionality. Plugins depend on hooks, but not everything is possible to do by hooks. A theme is a theme, it can't be substituted by plugins.
Related
I haven't been able to look this information up online. Perhaps I am not searching correctly.
I'm looking for information on the best practices. I have a custom built Wordpress theme that I want to implement on several similar websites. On each of the websites, I then intend to implement a child theme so that parts of each site can be customized, while still utilizing the parent theme.
I don't want my parent theme to be downloadable for other users, just myself.
I'm sure that "copying and pasting" the main theme from one of the sites to the others isn't best practice, because if an update needed to be made, I'd have to do it across all the sites. Ideally, I'd like to able to apply an update, and then within the dashboard of each of the sites, just "update" the theme.
What would be the best practice for this? Or am I misinformed about how this all works? Any insight would be appreciated.
You can perhaps try multisite - https://codex.wordpress.org/Create_A_Network.
I have a client who has asked me to develop a WordPress theme based on an existing one. My first thought was to create a child theme, but - his clients will need to have custom themes based on the one he's asking me for.
I know "grandchild themes" are a bad practice - I don't like them, either. I can create a new parent theme based on the original theme, and then, he'll have child themes of this to be released to his clients.
In order to let the final users easily upgrade their child themes, would it be appropriate to make a branch of the existing theme using Subversion? I'm not very familiar with version control, so I'm not sure if this is the best choice. What I need is to have every theme up to date whenever the one it relies on releases a new version.
None of these themes will be listed at WordPress.org, I think.
Sorry for my bad English.
Thanks a lot.
AFAICS, you want to implement vendor branches. Using vendor branches allows you to keep your child themes synced with parents.
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
Thing I plan to do is to make many websites based on Drupal core.
All of these websites will be quite small, but there will be many of them (in matter of hundreds).
I'm working on this with one HTML / CSS coder, guy who should make themes for every website we make.
He doesn't know much of a PHP (enough for PHPTemplateEngine tho) therefor I what I want is to make as little interaction between me and him as possible. He shouldn't touch PHP part of themes, I shouldn't touch HTML part of themes.
My question is:
Can you tell me what structure of theme folder should I use, what's your opinion of Zen theme for beginning of Drupal theming and how can I make automatic JavaScript and CSS loading script for themes?
Also I'd greatly appreciate any tips concerning multi-site Drupal setup, best practices and so on.
Thanks in advance.
With regards to drupal theming you have a couple of options:
If all the themes will share 98% of the same code base and just have different classes etc to style it visually different (say a different heading colour), then you can get away with one drupal theme and use theme settings to alter the configuration of the theme on each site. This has the advantage of having to maintain only one code base. Zen can still be used as a base theme if you wish
Another option is one you have mentioned above, in which you have a base theme which declares all inherited code, and sub themes to which override specific parts of the base theme to create the necessary effects. I would suggest that this is the better option if your themes vary wildly from one site to another. There is a administrative burden with this option though, as say you have 100 sites, you could potentially have 100 sub-themes to maintain and provide fixes for.
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