If you ask any 2 developers that build web sites with WordPress about which plugins they like to use, for whatever reason, you will have 2 different lists and mindsets. They build according to their resources, training, ideology, and whatever they can get out of you, their client. WordPress is a framework, modular, you build with it by adding and removing, tweaking what you add – for purpose. A lot of the time a developer will have a collection of common plugins they will install for the function they want that site to deliver, and it’s ease of use and scale-ability – the client’s goals and wants, but a developer will have a common set of plugins to start off most builds with.
WordPress sites generally benefit from a common task-list of tweaks and a common set of plugins. Example, web sites benefit from having ways for visitors to communicate with them. No-brainer; forms do nicely. Most web sies need forms – Caldera Forms is my favorite, or, I’ll just write up my own real quick. Is it prudent, when delivering a ‘web-site-in-a-box’, like WordPress, to burden the client with custom code they are now responsible for, absent a maintenance plan? The answer is no, as a developer you don’t commonly want to deliver your product and have it be difficult to use. This is why WordPress works so well, with some exception, plugins allow your clilent to manage your changes.
Now, let’s jump back a bit for a second and consider a couple things. First of all, your site is a collection of files in a directory on a computer. Like your documents directory on your computer. Only, it’s in a ‘special’ directory that an application (web server software) controls and with assistance from other applications, serves up your ‘web site’. This is your web host. You sign up with a company to host your web site. They make you a folder, add your account as a ‘user’ on that machine, and give you connection points: FTP, ssh, by which you may upload, write, save, manage the files of your web site. Easy. It gets good.
As a user on that machine you can do things: have backups. Example: every Kit from 5 Beans Kit includes automatic backups of your: site, database, email, because the host does this anyway. Every day. It’s a whole ‘nother conversation on a different level, but, suffice it to say, as a developer, I’m not adding complexity where I don’t have to, and there’s already enough redundancy built in, so, I don’t typically add a plugin to a WordPress build for the purpose of backup – it’s getting done every day, anyway, and they are a snap to use to restore. What I would do, instead, is walk my client through the administrative interface of their web host account and educate them on its function. This teaches to fish and educated clients are better clients. They get to see and understand some function, much of which they see as a bonus, of their server and not just their web site.
Who doesn’t want a secure site? Well, nobody. But, you don’t add complexity for the sake of it, in fact, adding complexity should be one of the first things that you don’t do – rule 1: do not add complexity. Your site is hosted. A company manages that server and they need it to keep being available. It’s super tweaked, built to stay on and do its job. It creates users and serves-up sites – it allows code to run, it offers up a ‘playground’ in which people, companies, can play – have a site. There is a fence around the playground, there are rules of play, the playground is on property that has its own parameters. What I am saying is, your web host has security features already in place that we don’t want to double-up on. Adding plugins in a WordPress install for the purpose will often add complexity nobody needs. Your developer will supersede any plugin by writing ‘rules’ and whatnot in an .htaccess file, for example, as that security plugin would anyway. Also, some of these plugins include backup capabilities. We just talked about that…
I hope you can come to see that, while plugins are what it’s all about with WordPress, you don’t want to go crazy, and any common set of them needs to address what a host already does as well as any extra need of any particular client. Otherwise, you don’t use one, you code it or get the ‘function’, or compromise, another way. Also, I over-simplified things a little for the sake of argument – and there are variables, but, my general message remains true. My common set of plugins is quite small in this regard and includes at least one that might be redundant based upon what I have just written, but, in some cases one needs to add some extra mojo to what exists.
Every site I build with WordPress includes these common, and in no way exclusive, plugins: