I think that although related to appearance, favicon support should not be part of a WordPress theme. You’ll probably want to take your favicon with you, no matter which theme you use. Conclusion: favicons are plugin territory.
Agree? Disagree? Why?
About the author
Agree. Because you’ll probably want to take your favicon with you, no matter which theme you use. :) You said it right there.
Thanks for your input Konstantin. Do you think we can say the same thing about themes with logo uploaders anytime soon?
That’s true ; no more bloated themes
Thanks for your comment Anthony, just ran a search on ThemeForest for “favicon” and found a bunch of themes that advertise it as a feature!
And it is a feature, actually. Till WordPress incorporates it as a feature of itself, it is a nice solution for someone who does not know how to load it otherwise.
Favicon should simply be a part of WordPress core, I think.
Never take Themeforest as reference for code quality. Themeforest is just a design gallery.
Hey Daniel :) I never said anything about code quality, I know exactly the kind of code one could get from ThemeForest and other such marketplaces, nevertheless there are some really great designers and developers among the top-selling authors.
I’m referring to the part that almost sounds like:
The same could be said about themes with SEO, Google Analytics and other things. Anyway, thanks for your comment and have a great day :)
That’s all part of a marketing strategy on the premise the more features a theme has, the more potential buyer. But only uneducated users bite that bait. Everyone who has run a website for more than 2 years or switched themes more than 2 times knows some features are just pain in the ass.
And, again, I have bought and used many themes from Themeforest (and I’m developing one for there, also, trying to have very good coding manners, if one could say so) and have used many from the theme repository.
From all that “using” all I can say is that I have seen weird stuff in both places. In my personal case (just mine), more times in the repository than in Themeforest.
Themeforest is a market with tons of developers. Some of them make wonderful things while some of them may not. At the end of the day, and in my opinion, a theme that helps a user add his favicon it’s better than one that not, while WordPress does not do it by itself. Why shouldn’t a developer add that to the list of features? I mean, it’s a market, come on.. ;) You may not like the idea of themes being sold for WordPress, but it’s a market after all.
Honestly, I think favicon is core territory. Add it to the general settings tab. Favicon is something that definitely passes the 80/20 rule IMO.
There’s also a core ticket to address that, but it didn’t turn out as simple as it sounds. Also, as Chelsea mentioned:
I agree, though most people will use the very same favicon generators anyway :)
If you want to see Favicons in core, contribute here:
http://core.trac.wordpress.org/ticket/16434
It’s been under discussion for a year and a half…
Absolutely agree. Core would be lovely because so many users aren’t up to hacking their html headers or even comfortable with FTP — but it’s something that needs to stay with the site regardless of which theme they’re using.
(Although themes that implement a setting are nowhere near as bad as themes that insert their own favicons in users’ sites! Grrr…)
This is so true. I feel so ashamed, because one of my very first themes does this. Thanks for the reminder, will go update immediately :)
Cheers and thanks for stopping by!
Disagree! Sometimes users adapt their logo to keep up with theme, the same goes to favicon. I think that it should come with theme options.
Marcelo, that’s an interesting argument, thanks for sharing! What if the next theme they pick does not have a “favicon feature”?
What if, you using this plugin and install a theme that also implements this feature? Which one have the preference?
The problem is that plugins and themes can change the favicon but, in my opinion, this is theme territory.
After all, maybe this is really a core solution… heheheh.
That depends on the way the two were written. Worst case scenario is you end up having two favicons in your
headsection and the browser will just pick one :)Agree. The Favicon is branding/identity, not content presentation. It is absolutely Plugin territory.
Having the Favicon change when the active Theme is changed would be analogous to having the Site Name or Site Description change when the active Theme changes.
Hey Chip, thanks for your comment. I like the site name/description analogy!
Chip makes a good point here on the branding part.
Having said that however you should definitely ask yourself the question how many times does a company change their theme?
If we developers are lucky, a company changes their site once every 3-5 years (if at all!).
When the economic lifespan of a company website is that long, is it then really necessary to install a plugin to add something so trivial as a favicon?
I disagree wholeheartedly.
Plugins break, get abandoned and what not. I know that it’s quite unlikely that a favicon plugin would break, but still, if the plugin developer abandons the project you end up with a plugin that eventually is removed from the WordPress plugin repository (according to the new “rules”).
Therefore I stick to adding the favicon as part of the theme :)
Hey there Piet, thanks for stopping by! That’s an interesting point of view you got there, and I agree to some extent, especially the “plugins break” part, but I think that it’s a different problem, and a different, larger discussion.
Themes tend to break and get abandoned too. A favicon plugin code bundled inside a theme is still the same code, right? So is there really a difference between a broken favicon plugin, and a broken theme with a favicon upload feature? :)
I believe that there are two ways for a plugin to be removed from the repository: author request, or upon discovery of a serious security issue. If a plugin’s (or a theme, for that matter) not been updated in a while, it just gets removed from search results on WordPress.org and gets a big yellow notice, that’s all.
Thanks so much for your input Piet, I really appreciate it!
That doesn’t make any more sense to me in this case than saying “themes break”. Plugins are not inherently more fragile than themes, especially when they’re doing the same thing (favicons). If anything, a theme seems more fragile in this case because its favicon implementation may depend on particulars of the theme, which can also change or break.
Hi Evan, thanks for your comment :) You’re right, they’re not more fragile, I should have phrased that differently. I was referring to the “plugins break” assumption in general, because there is no review process for plugins like there is for themes, plugins have no clearly defined scope, etc.
But yes, a theme with a favicon feature can break just as easily as a favicon plugin, and as I and Chip mentioned above, if both are done right, they’re probably running the exact same code anyway, so there really is no difference :)
Thanks for stopping by and hope you’re enjoying the weekend!
First: “companies” are not the controlling demographic of end users. So, what is ideal for “companies” or for developers is not necessarily relevant, or the most important consideration.
Identity and “banding” apply to all end users. I have a Favicon for my personal site. I would be extremely upset if I installed a Theme that overrode my chosen Favicon. I believe most users would feel likewise in the same situation.
Also, this:
…is a misnomer. A Theme that implements a Favicon properly and a Plugin that implements a Favicon properly would use exactly the same implementation: a simple callback, hooked into wp_print_styles or wp_head, that prints a Favicon link. Whether that callback exists in a Plugin or in a Theme makes absolutely no difference with respect to code execution or obsolescence, and I daresay that code in Themes is just as likely to become obsolete or to break as code in a Plugin.
Great comment Chip, there’s really nothing I can add, well said!
I know that there are (still) more natural persons than companies using WordPress, but I tend to focus on the latter.
And included in companies are also the more commercial blogs, i.e. blogs that generate income and/but written by natural persons.
If people want to use a plugin for something so trivial, fine, I just think it should not become some kind of ruling that it is wrong (or not done or whichever wording you choose) to include it in a theme.
Hey Piet! When you say it like that, it sounds like plugins are some kind of black magic, while in reality, they’re exactly the same as the theme’s functions.php fine, only portable across different themes.
Which is why I wouldn’t say that it’s wrong, but I would say that it doesn’t feel right :) just like it doesn’t feel right to make Google Analytics part of a theme, because it’ll stop tracking visitors as soon as you switch to a different one.
Thanks for your comment!
Nah, that is not what I mean, really!
And it’s good that you bring up the functions.php file. Isn’t there a trend going on to use a functionality file for all stuff that needs portability?
Let’s put the favicon call in that functionality file and everyone is happy! :)
great discussion, thanks
Heh, I can’t tell whether you’re being sarcastic or not, but just in case, linking to an earlier plugins vs. … without a plugin discussion :)
Have a great day!
I was definitely not being or trying to be sarcastic, sorry that it came out that way. Have a nice weekend too!
I’m sympathetic to Piet’s argument. A lot of us developers work pretty much exclusively for clients who have no plans to just up and change their theme — and whose sites are too complicated to do that anyway. So I always feel a little removed from these theme options debates, where the prevailing argument is “but users should be able to change their theme without losing important settings.” Sure, if we’re talking about a basic blog or a five-page site…
That said, since we are the ones configuring these companies’ sites, we have the luxury of knowing what should be in a theme, and what should be in a plugin, and developing accordingly.
Good discussion.
Hi Michael, thanks so much for your comment. I don’t see why you can’t do what you’re already doing, but put portable stuff in a custom plugin for your client? It’s just a matter for separating stuff into different files ;)
The next time (in a year or whatever) when the same client asks you (or anybody else) to create a new theme for their website (or maybe launch a new website? or maybe a totally different client?) you won’t have to rewrite the things over and over again, but focus on the new theme appearance, and copy the essential plugins over. I’m pretty sure you already do that by copying
/include/folders and things, but isn’t it easier and more portable just by using a plugin?Thanks for sharing your opinion and have a nice weekend :)
I totally agree, and gradually moved in that direction.
You start out…you realize you keep rewriting a bunch of code…you start reusing code snippets…which turn into theme includes…which you then abstract into plugins. Early life cycle of many WordPress developers, I imagine.
Awesome to hear that, seriously! Also, when the time comes, don’t forget to open source such plugins, and share them with the rest of the world via the WordPress.org directory :)
Keep up the good work!
IMHO, a discussion such as this one is predicated on the assumption that it applies to publicly distributed Themes.
Bespoke Themes developed for a specific client are a completely different use case, in which case the deliverable is much more holistic than just the Theme, and includes the site functionality (social media integration, e-commerce integration, perhaps even some content development). While even in that use case, I would still argue that Favicon implementation belongs in a site functionality Plugin, I think that it is outside the scope of this discussion for the most part.
Or at the very least, that’s the scope to which I limit myself: what is the best practice for publicly distributed Themes.
Until it is a part of the core I’ll continue to include it as an option in all themes I create. It’s viewed by the typical premium theme customer as a ‘necessary feature’, and whilst I agree it is in plugin territory, those customers do not.
Hey Bryce, thanks for your comment. I understand your point of view, though if I were making premium themes, I’d probably replace the “feature” with a link to a good favicon plugin :) thanks for stopping by and have a great weekend!
Hey Konstantin. Yeah I definitely agree about linking to a good favicon plugin. For the meantime I think I will include a recommendation that the user uses a plugin but still include the ability to upload a favicon through the theme, giving them the choice and information they need to make that choice.
That’s a nice model to deprecate features :)
This is a great and informative arguments going on here, I believe it would be easier if it was just added to the core of wordpress, that way it saves everyone from the extra heap a plugin or switching a theme might have on the favicon. But I believe it also based on urgency and need of it by the wordpress community. I imagine if I have a wordpress.com blog, it would be easier if the favicon was embeded into the wordpress core. But then in either way, if the community really deems it urgent then I believe it could be considered
Hi Addo, thanks for your input. On WordPress.com under general settings, there’s a field for “blog picture” which is used throughout the WordPress.com network, and as a favicon too. But downsizing an image is easier in a network like WordPress.com with Gravatar and such, but not as easy in core as seen from this ticket. I believe some new media and image management tools in 3.5 might help with this too, we’ll see…
Meanwhile, all the cool kids
areshould be using plugins :) Thanks again for your comment!Thank you Konstantin, please would you advise in using themes from the worddpress marketplace for developing websites, since majority of those developers focus more on design and go against some of the wordpress best practices please?
In my opinion, the best themes to learn from, and base other themes upon, are the following: Twenty Twelve, Twenty Eleven, Underscores and Twenty Ten. Hope that helps!
Need to do something about this threaded comments craziness ;) Replying to Javier Schvindlerman:
I get your point, but that’s the problem: market demands — developers deliver, regardless of whether it’s good stuff or bad stuff, and the competition is just so damn high, that you can’t say “no.”
Or can you? There are numerous successful theme authors and companies who make their fortune without “favicon uploader” as a unique selling point. And for that matter, unlimited shortcode generators and SEO options too. More of this in a video my previous post.
We (theme developers) should probably be trying to educate the users (and learn from them too!) instead of just doing everything (or almost everything) they say.
Thanks again for your input!
I think you’ll find few more staunch supporters than me of businesses responding to market demands; that said, just because the market demands something does not mean that what the market demands is the best practice.
For years, even after the Post Thumbnail integration in core, the market demanded TimThumb. How well has that worked out, on the whole?
I totally agree there Chip! Also loving your use emphasizing things in your comments. Thanks for being part of this discussion :)
Short answer: I believe this should be part of core.
Longer answer: The majority of customers that my team and serve want to be able to customize their favicon. The thing is, this isn’t portable if they were to swap themes.
On top of that, favicons are now used to serve as homescreen icons for Apple and Android devices and there’s certain ways that they have to be declared in the header element.
If this was baked into core, then it’d be done right, users would be able to port them between themes, and there’d be one less theme option (which is a good thing) that developers would have to include in their product.
Thanks for your feedback Tom! Device icons are certainly important in today’s world of mobile, thanks for mentioning that. Have a great weekend! :)
Hi Konstantin! After reading this and some of the comments I have decided to remove the ability to add a favicon from my theme options (just submitted my very first theme to the .org repo).
How do you feel about having the ability to customize the footer text for a theme. I think it should be on a theme by theme basis and should not be a plugin, but some might not agree.
Anyway, very nice post and discussion.
Hi James, thanks for coming by! I think footer text is okay to have in a theme, because the location, look and feel, font size and color, and everything else is defined by the theme itself. Another theme might not have a footer. However, what I usually do is not a theme option (I hate theme options) but just run an action in the footer, which I (or any other developer) can then hook to and output footer text via a plugin.
This is a whole different problem though, and I’ve been thinking about ways to solve it for years. Not footer text, but “content chunks” in general. I haven’t found a clean solution yet, but I will. Anyway, “a footer text” plugin doesn’t make much sense to me, at least not on this fine Saturday morning ;)
Thanks for your comment and enjoy the weekend!
I really don’t think this should be in core. There are already many themes that offer this functionality and adding it to core just means duplicating functionality that is already available.
I think it is extremely important for WordPress to stay as lean as possible, and no features should be added to the core that can be easily theme-independently done by a plugin. Some comments above mention WordPress.com, which I think is horribly bloated like the Jetpack crap with its own interface styles and therefore NOT a good reference point.
Also, nowadays having only a favicon.ico is not enough as you should also add an icon for iOS (apple-touch-icon), which needs a couple of different images to accommodate for different screen resolutions -> scope creep -> core bloat ;)
Hi Johan, thanks so much for your opinion.
Fine, let’s remove menus, backgrounds, media, thumbnails, comments, categories and everything else. Behold, BackPress — the lean, clean solution you’re looking for :)
I think WordPress should have the right amount of features, for users to be able to use it, without having to spend too much time downloading plugins and configuring things. And I think a favicon uploader won’t do any harm. That said, as mentioned in the initial post, I feel like favicon belongs to plugins, not core, but I wouldn’t mind it in core :)
Thanks for commenting and have a great day!
I don’t see how implementing categories and comments in a theme is comparable to adding a favicon as my point was that no features should be added to the core that can be *easily* theme-independently done by a plugin but I guess this might have to do with a difference in programming skills :)
Hey Johan, I got your point. What I meant was that a lot of core features can be *easily* and theme-independently done by a plugin, due to the flexibility of core’s actions and filters. It’ll actually be the exact same code most of the time. In fact, before a certain feature is built into core, it’s often coded as a plugin for proof-of-concept, like this one.