https://twitter.com/#!/kovshenin/status/154565706090942465
Posted this yesterday on Twitter, thanks for all the retweet and fave love! I started seeing quite a lot of tweets and posts on how to do things “without a plugin” in WordPress and 99% of them involve writing snippets in your theme’s functions.php file. Now, how does that differ from writing a plugin?
- It’s more difficult to manage and maintain.
- If something stops working you can’t “deactivate” your functions.php snippets one by one to figure out which is causing the problem, you can do this with plugins.
- When you switch to a new theme you’ll have to port and then merge and cleanup the functions file too.
- It’s easier to share plugin files than it is to share functions.php snippets.
I’m pretty sure there are a lot more reasons. So dear all, write plugins, even if they’re dead simple and do one thing only. The “all in one” plugins carry the real overhead which is never used. Then, when you’re ready, submit your plugins to the WordPress.org Plugins Directory to give back to the community. That’s why the open source WordPress is so strong.
Personally I’m becoming very tired of these big little issues; options no options, plugins no plugins, the only thing that should decide this is the end user experience and I really can’t see the end user wanting to have to activate / deactivate / update a whole set or plugins or fiddle with a ton of options this leads to bad user experiences, think about it – a user enters the admin and sees you have 20+ plugins that needs updating “WTF” goes the user!
One example of this was OTTO’s Facebook plugin one of the best IMO, but I hated using it the thing installed a ton of other plugins thank God he fixed it, I started to look for an alternative.
JetPack form WordPress gets it right one install and simple setup options, an excellent model for plugin and theme developers alike…
We really need to change the conversation, think user first!
Shawn, good points, but if you’d rather have the end user browse through and edit a 1000-line long functions.php to remove a feature from their site, I disagree, 20+ plugins is way more user friendly and can be updated in bulk too. Then again, updates is a separate conversation.
I’m not saying “absolutely not” to one-in-all plugins, there actually are some really good ones out there, but what worries me is when a certain theme or plugin does too much. A good example is SEO, Google Analytics, etc. A lot of premium themes come with SEO options and GA profile input. But hey, I’m using Yoast’s WordPress SEO plugin already, do you really want me to overwrite a couple thousand SEO titles for all my posts? Hell no, good experience? And I’m using Yoast’s (what an irony) Google Analytics plugin too, and this thing will print the tracking code twice. Doh!
Installing extra plugins to make another plugin work is a mess I agree, and I believe that the “Import from…” plugins is a good example, but I can totally understand the reasoning behind that decision. JetPack from Automattic is pretty damn good, allows you to use only the features that you’d like to use without any overhead, a great example of how “all-in-one” plugins should be bundled.
Anyhow, the conversation initially was plugins vs. “without a plugin” meaning functions.php, and not about one plugin vs. multiple plugins ;) I hope you get my point and thanks so much for commenting!
I understood the conversation, my point was that the problem wasn’t really the functions file as much as it was about the function of design. The function file was originally designed to hold theme specific functions not for mini plugins.
For some reason or the other options stuffed into the function file driven by the premium theme market became the rage. The outcome of this practice was a poorly designed theme production workflow… tons of files stuffed into themes to make them premium.
I agree that the functions file is the wrong place for this, but I’m afraid that what will happen is a ton of “plugins, even if they’re dead simple and do one thing only” especially when they are plugins that do it already. So we are not really solving the problem, creating more bloat.
I would prefer to see themes and plugins use native php to extend theme and plugin functionality OOP, auto-loading, abstract classes…. why can’t I access a plugin function when I need it without loading the plugin.
Maybe better design is the conversation we should be having :).
Shawn, the part of using OO PHP is something that really puts me off writing WP plugins. I’m sure this might sound silly to some, but it’s just down to preference – a bit like the way you might prefer one PHP framework over another.
I do wonder if WP will eventually start to phase in some PHP 5 / 5.3 stuff – I haven’t looked at any upcoming dev plans – but it would make sense, considering that one of the recent WP upgrades dropped support for PHP 4 (correct me if I’m wrong). So are we going to start using PHP 5 code soon?
For a system as widespread as WP is, I imagine that any major changes to the core code would not be taken lightly. However, there is so much I would love to see. I build fully custom sites using PHP 5.3, Zend framework, Doctrine2, Twig, classes, namespaces, dependency injection… all of which have made a huge difference to the logic in the applications I’m working on.
I guess a lot of this stuff can be debated ad nauseum – like why use an open source framework when you could build a really lightweight one with the bits you need? (I’m not really suggesting WP should adopt Zend, btw.) Why use an ORM? Why use a templating engine? IMO using Twig for templates would really help – in WP, the constant opening/closing of PHP tags makes for messy templates.
I just can’t get over the approach of using really_long_function_names. It works, but it feels clunky.
Would love to get into a proper design discussion btw, sorry for getting way off-topic.
Ben, yes support for php 4 has been dropped recently, so we can now write
$thisinstead of&$thiswithout having to worry that the object duplicates itself in memory, hurray! Matt asked the audience at WordCamp San Francisco in 2011 “how many of you have learned php thanks to WordPress?” and you wouldn’t believe, but there were a lot of hands. My point is that you can have some programming/php basics and learn the rest on the fly with WordPress, but in order to do something with Zend Framework, you really need to be good and understand the object-oriented concepts, things you can’t learn overnight.However, I do agree that it would be nice if WordPress had a better templating language, a good ORM instead of
$wpdbandWP_Queryalthough I really, really likeWP_Query. The long function names, yeah that’s something to think about ;) I’ve seen a major improvement to the codebase since WordPress 2.7 and I believe that it will only get better with each and every update, so eventually we’ll get there.Thanks for your comment Ben and don’t worry about being off-topic ;) Cheers!
Shawn, yes I understand your point and totally understand why you’re pushing towards the design conversation. Regarding simple plugins, I didn’t mean duplicate what is already available, but if you can make existing ones better, why not contribute? It’s not difficult to get in touch with the developers and get them to give you Subversion access, I’ve got half a dozen plugins myself that I can’t keep up with, they’re still at like 2.9 and I’d be jumping like crazy if somebody came up and said “hey, give me access I’ll update those for you” :)
Anyway, the object oriented approach, patterns, etc. sounds more like Zend Framework or something, and although I truly believe that it’s an incredible product for developers, I think that WordPress is many developers’ choice because of it’s simplicity. It’s easy to learn, it’s easy to use, and it’s flexible when you need it to be. Yet again, this is more related to the core design, not the way plugins and themes are written. Oh and how exactly would you like to access a function in a plugin file without loading the plugin file?
Thanks again for your feedback!
I would love to contribute, I don’t because while I can read and write my own code and have gotten considerably better at it, I do not consider myself a “developer” I code out of necessity and the need to shape code to meet my needs. I’m still learning GIT, SVN I just can’t seem to get IMO it is complicated, I keeping wishing more developers would use git.
WP’s flexibility is definitely it’s strength, to some it’s weakness. The benefit is that it allows plugin developers to easily extend the core functionality. The beauty is that you can be flexible in how you adopt an objected oriented approach in your themes or plugins.
My plugin files execute WordPress plugin api functions, all other functions are placed in classes, admin, post, tpl (template), users etc built into a core plugin that includes the auto-loader, if the plugin is inactive I can include the auto-loader, to access the classes, mu-plugins folder makes it active all the time.
I reuse and extend this core to build all my themes and plugins, the main benefit for me in this is that I can call the functions I need when and if I need them. Each theme contains a functions file (theme-functions.php) that turns on and off the things I need for that specific theme.
Most developers assume I need all the functions automatically run them be it in the functions file or the plugin itself there is no way to access a function without activating the plugin and unwanted baggage.
Here is a Word Camp presentation by Brandon Dove that address it in a more concise way;
http://www.slideshare.net/brandondove/building-a-pluggable-plugin
http://wordpress.tv/2010/12/03/brandon-dove-the-pluggable-plugin/
Shawn sorry for the comments mess, got caught up for approval. Brandon’s presentation is quite interesting, thanks for sharing that! However, I think that using functions without loading plugins themselves won’t solve any problems. I don’s see how a *good* plugin can become an overhead if loaded but not used. Maybe we’re talking about different things, I like how WordPress loads the WP_Http class on demand through its wrapper functions. Is that what you mean?
Anyway, thanks for the discussion, and by the way, although I’m a Git fan myself, Subversion is okay as long as you learn it before Git ;) Cheers!
Ahh… links required approval… understood.
What I meant is that I can use a plugin function even if I don’t want to activate and enable all the features of the plugin. If you look through theme functions.php you will see that a lot of it’s code is already available in plugins in one form or the other, and are in the functions because theme developers don’t want to use all the functions of the plugin. The plugin debate needs to be approached in the same way theme options were; too many are bad for the end user experience.
Thanks, I didn’t know about the WP_http class, yes this is basically what should be happening with plugins and themes, http://planetozh.com/blog/2009/08/how-to-make-http-requests-with-wordpress/.
I think it is something theme and plugin developers need to look into some more…
Although I agree with you, I think there are still several benefits to blog posts about “how to do X without a plugin”.
It tends to focus on the core of what’s being discussed, as oppose to countless other features you don’t need. Giving me just the code I need to acheive something is great
They *tend* to follow better coding practices, as they’re written with the main intention of being read by others. This benefits beginners, which leads me on to
They tend to be beter documented, as the post will typically say what each part of the code is doing, and this will typically go into more detail than code comments
I think the natural progression for many developers (myself included), was to start off by putting everything into functions.php and copy these various snippets, and then as you get better, you start understanding it, write your own snippets and then move onto custom plugins. Maybe we need to emphasise how easy it is to make a custom plugin, and dismiss the rumors of having lots of (good) plugins is bad.
What authors of these posts should do, is show the code, explain how it works, and then also provide it as a downloadable plugin, so that you can take that route if you wish
Damian, valid and good points and I totally agree with you that some of such posts (except for those that just give you a 5-line snippet and say paste this in your functions file) are great tutorials to learn to do things in WordPress. What I do not like about them is how they stress the without a plugin part like it’s some sort of magic or something.
Many developers (myself included) start off by writing stuff in the functions.php file and I agree it’s quite natural, but only because doing it in a plugin takes two extra steps – copy/paste plugin header and activate plugin in the admin. It’s just something we’re used to, right? The plugin route will pay off in the long run though, which is why I started to “re-educate” myself. I’m more comfortable dealing with 20 plugins than 500 lines of code in my functions file which have nothing to do with my theme per se.
However, documenting the code and explaining what you’re doing is a must for both ways, not only functions.php snippets, if the purpose of the post/code is to teach of course. Thanks for your comment!
Of course, if they want to do it ‘without a plugin’ and want to avoid the two extra steps of the plugin header and activation of the plugin, they could always write it as a mu plugin.
;)
John, right, as always :)
[…] #3: Plugins vs. “… Without a Plugin” […]
I think it all boils down to who the site you are building is for.
If you are building a site for a client then you need to make a decision on how they will use it. When building client sites i prefer to put in functionality into the functions file so they cannot fiddle with it as they don’t tend to want to look at code. However if it is something like a twitter sidebar plugin then it is good to have that as a plugin so it can be deactivated if they want to use another one.
Lee, good argument but even when doing something for a client I tend to be a little selfish and think about myself too, like how am I going to manage this thing afterwards. I try to make things comfortable for myself too, so in your scenario I’d rather spend an extra 2 minutes and setup WordPress multisite with the plugin activated throughout the whole (one site) network.
There’s a new plugin called ‘Toolbox’, which aims to solve this problem by loading every small snippet as a module. You can select if the code should only be loaded on the frontend or the backend area.
Unfortunately, the plugin description is in German. But have a look at the screenshots & the code: http://wordpress.org/extend/plugins/toolbox/
Pascal, looks quite interesting although I didn’t understand some things. Where do you put the code and how exactly does this differ from plugins? Maybe a better organization of the plugins section would help. Like management, social and so on. That way it’ll be much easier to get around that huge list ;)
Thanks for your comment!
I’ve been doing a fair bit of development with Drupal lately at work, and their modules section (aka plugins) is split in this way. Modules are split into various categories, such as core, social, users, discussion, commerce etc (any module can define it’s own section, or use an existing one).
One of the other things I like about the Drupal module system, is how there are a lot of very basic and focused modules, which are then the basis other other modules, as you can define dependencies on a module. Maybe we could take a few ideas from that…
Honestly I haven’t had any experience with Drupal, so I can’t say much. As good as the dependancies idea sounds, we have to be careful not to start building a plugin that depends on another one which turns out to be broken. The concept’s not far from child themes, ones like Genesis and Thesis, or even better — the WooCommerce model.
So whoever builds a plugin to be a base for other plugins has to be well known, respected and trusted by the community. Probably an established company like WooThemes or someone from the core team like Andrew Nacin, Otto Wood and Mark Jaquith. If an “average Joe” (no offense to Joes) builds one I would rather reinvent the wheel than risk it.
Yet the concept is quite interesting. Thanks for your comment!
I agree, some steps would need to be taken to ensure the reliability and long term availability of these base plugins. Within Drupal, most of these dependencies tend to fall into the “core” category, and I assume are maintained by core/well known developers.
The other use case of this, is a single developer breaking down a large plugin into a number of bundled smaller plugins. For example, an E-Commerce store would have several core components that it can’t function without, but things such as “gift wrap”, “related products”, “multi currency” are all features that aren’t core, but you may want. In this case, it would be one developer (or team) maintaining the plugin as a whole, but it allows users to pick and choose what they want.
Damina, although I agree to some extent, if done correctly, such plugins can ship with everything you might need but should be opt-in. As already mentioned above, think how Jetpack is bundled as a single plugin with many different features. When you enable social sharing, it doesn’t enqueue a billion of scripts to your page but only the ones that you will tell it to, hence there’s no overhead other than that extra hundred kilobytes that you download from the plugins repo.
I’d be disappointed if I had to download 7 more plugins to get Jetpack working, and I’d hang myself if I had to download 20 more plugins to get 20 more social share buttons too ;)
But I agree, in some places it works, again, as mentioned earlier, the import plugins is a good example. Thanks for being part of this discussion and cheers!
I neglected to mention something which answers your gripe with the above…
When you download a Drupal module, such as Ubercart (an E-Commerce module, with 20+ components), it’s downloaded as a single module, but within it are a load of sub modules (although the sub modules can be moved out of the parent module and become independant modules with a dependency).
In escence, it would work very much like Jetpack (I assume… I’ve not used Jetpack yet).
Unfortunately there’s no “silver bullet” solution which will solve all the problems with no drawback…
Oh, yeah, that’s a little different and totally makes sense. And I do believe that the people building Drupal are not a bunch of idiots, so yes, that’s something that the WordPress folks should (or probably already did) take a look at. And I’ll have to check that whole thing out too at some point :)
Hmmm…. Maybe you guys correct me here if I’am wrong here, is it necessary to for something like this to be released as modules or by a particular group, requiring a great deal of organization?
Would it not be simpler and more in keeping with WP philosophy if we could use php5 autoload function to autoload classes. I have not used drupal but I’am pretty sure that’s how it’s done.
Links:
http://gen5.info/q/2009/01/09/an-awesome-autoloader-for-php
http://code.google.com/p/php-autoloader/
http://anthonybush.com/projects/autoloader/
http://php-autoloader.malkusch.de/en/
http://ajbrown.org/blog/2008/12/02/an-auto-loader-using-php-tokenizer.html
Shawn, no Drupal experience, but I do agree it would be nice to autoload classes. However, I think that the majority of theme and plugin developers don’t use too much classes yet, so I guess it’s just too early. But hey, the fact that we can extend the WP_Widget class is cool, there’s also Walkers, List Tables and other classes we don’t use everyday, but we’re getting there step by step :) Thanks for sharing the links!
I really feel that this could help alot, here is an article I ran across on optimizing plugins by dev4press I don’t know if you read it yet, http://www.dev4press.com/2011/tutorials/wordpress/practical/how-to-optimize-plugin-loading/
Awesome, I’ll check that out, thanks!
Agreed. Something like this would be a huge benefit to WP, and it does not need a total rewrite form the core, it could be started by plugin developers.
I appreciate the insights shared here. As we move forward here at PressTrends and start to release stats concerning plugins, we’ve got to decide which stance to take on them. For instance, if one blog theme is used with 4 plugins on average and another blog theme is used with 2 plugins on average, which one should rank better?
Why should they rank differently based on the number of average plugins used? Say the first theme comes with a bunch of SEO options, so the second one gets an SEO plugin to do that. So how is the first better than the second? Or the second better than the first? Personally I’d pick the second over the first since I don’t want my SEO options in my theme, but how can you tell? :)
Thanks for stopping by!
[…] Funny thing is I recently had a discussion (comments) with Konstantin on a similar subject; https://konstantin.blog/2012/01/plugins-vs-without-a-plugin-3745/, it something that really needs to be explored. Share this: Posted in News | Leave a comment […]