Why Wordpress?
johnmaeda.com
johnmaeda.com
I'd be very happy to use something else, more secure and better written, but what comes even close?
I have never seen a better alternative for what I do.
With Varnish in front of it, the server doesn't break a sweat with 1,000 concurrent connections (according to Analytics)
One area that Wordpress wins is with respect to the overall number of themes and plug-ins, but that's pretty much it.
The WYSIWYG editor is still nice though. But it adds a lot of complexity if you want something it can't do. Somme abstracted forms in wordpress are easier.
I really like Wordpress, it gets a lot of hate; but it's easy to develop on allowing for fast turn around, has the best editor of any CMS around for client happiness, and has a robust ecosystem. I'm in charge of around ~150 websites that run Wordpress, and I moved them all under an active management platform with always up to date plugins, themes and core. I inherited a lot of them with my new job, but I am slowly putting them all behind Cloudflare's firewall and setting up the appropriate page rules to keep them safe. I often scan them and compare them against the core to make sure there have been no changing of core files by a hack. I also have them on scheduled back-ups to private Azure blobs and have alerts set up with Azure's monitoring tools.
It takes a while to set all of that up, but once it is set up your install is pretty safe against any sort of attack relative to other CMSs. Another great thing about WP is if it IS hacked, it's pretty easy to fix. Other CMSs getting hacked is quite the chore to hunt down, especially the other major PHP based CMSs. I'm looking at your Magento & Drupal.
I think about what is best for turn around, has the best cost/benefit, and what makes clients happiest, and so far that is Wordpress is the answer 90% of the time. Until that changes, Wordpress will continue to run a huge chunk of the web. I do grant you that a lot of lazy developers and unmanaged/out-of-date installs from agencies, small businesses and individuals are hacked very often and are often turned into zombie sites. There's no doubt about that. But just taking some basic common sense security measures can do wonders and keep you and your clients safe(r) from attack.
I too (and many others) could make most WP hosting really secure if I got to say "you can only use these 9 plugins (or whatever the number was) and no, you can't put any custom code on the server at all".
EDIT: Indeed... every moderately-sized WP project I've worked on ends up being dozens of plugins (more than 15 being average, and one recent one having about 45 active plugins). Every time I mention that to anyone I know who 'does' WP they all recoil in horror and say "I'd never even work on that - that's impossible! Why would you need that many plugins ever?!" And then I think... they don't really understand WP, or they don't understand clients. Or... yeah, it must be my problem, because I'm somehow not good enough to deliver everything a client asks for in wordpress (requirement) in the mythological "3-5 plugins" everyone tells me is their max.
EDIT2: The client project referenced above was getting tens of millions visits per month, and as such the WPengine number I was told was somewhere in the region of $1500/month.
I took over supporting/developing a WordPress site and one of the first things I did was delete a bunch of pointless plugins. I wound up writing quite a few of my own for different tools and left some third party plugins so there are still probably 10 active between 3 sites on a multisite install.
I installed Google analytics directly in the header of the custom themes on each of the multisites.
There were no comments so all of the comment plugins were pointless, as were all the form plugins except for one.
So, why so many plugins? Am I missing something?
Would you like to force everything to be SSL? Another plugin. Do you want a contact form? Another plugin. Do you want to disable the bizarre update messages from ignite woo that won't go away? Another plugin. Oh, you want some slider-carousel thing on some page? Another plugin. Caching? Another plugin. Image optimization? Another plugin. Some sort of 'maintenance mode' to deal with taking down the site for upgrades? Another plugin. Social sharing buttons? Another plugin.
I could keep going, but perhaps you get the picture. And the argument could be made that 90% of these are not needed, and there's other ways to deal with the requirements. In my most recent excursion, I'd taken over a project from someone else, and this was it. Any changes to anything would require investigation, custom code, and still require some sort of UI to manage things, all of which cost time and money, which were in short supply, so this particular project kept going with dozens of plugins.
You want to do an upgrade to WP core? You've got 30+ plugins to test. Or... just click 'update' and hope for the best. Or test each plugin and upgrade process on a separate server. Again, back to relatively large amounts of time and money expended just to keep up with wp core to avoid inevitable hacking attempts.
I have another multisite install I was brought in on over the summer, with 165 plugins. It's just another version of 'crappy legacy software and undocumented crap with no documentation' which we've all seen, but it is also quantified by "number of wp plugins". No, not every site is using all 165. But there were/are > 40 sites, with various groups using various combinations - there's 0 good reasons for all of these to have been combined (over several years) in to one massive multisite mess, but it was, and it's taken many people far too long to unravel some of the mess to extricate some sites.
Yes, some of this is just a 'bad code is bad code' rant, but given the mindshare that WP owns, it would seem to be incumbent on them to raise the bar with respect to tools for plugin management (as just one example), give developers better starting code and samples and guidance for what's acceptable and what's not. A paid certification program which would vet code for 'best practices' would be something I think would help improve the landscape in short order (and no doubt has been considered by some over the years).
I agree that knowledge of best practices is really important, because why would you need to run a plugin on top of your site to force HTTPS?
I use Apache to force HTTPS, Apache to handle error documents, etc. My themes each have their own cache manifest.
It's common sense / best practice to have a second server to test updates on, that's what I do. Given I only have 12 plugins with a handful on active on each site, it doesn't take too long. I also add and develop plugins on the second server.
IMO the shittiest thing about WordPress is the library so by and large I choose not to use it when it isn't necessary, so pretty much everything besides querying posts and accepting AJAX calls since they make it nearly impossible to otherwise.
In general, I try to develop apps/plugins that run 100% independent of WordPress and just write a wrapper for the library that's used for administration on the WordPress dashboard.
An example of this is a plugin that's more or less a long test, with some custom GUI and other requirements (save progress, download CSV, take notes, etc). I wrote it to WordPress standards and used a short code to add it to a page. It was slow, sooooo slow.
So, I rewrote the entire front end to be an independent app that uses a custom DB table, propagated by a plugin on the WordPress dashboard. Result? 80% faster load times.
Another example, I made a simple app that gets some data from another custom DB table and sends tweets, triggered by cron. It uses a SQLite DB to track a few settings and a list of users to mention.
I wrote a wrapper for the library with a simple API to manage settings in the WordPress dashboard.
Unless there is a drastic change to WordPress's plugin system these apps will always work. Even if there is a change, pretty much all the code that WordPress cares about is displaying the settings page and receiving AJAX requests.
It might not be by the book but it's faster and in my opinion, pretty logical. This way apps are portable and can be transferred to other platforms easily, not necessarily other WordPress sites on shared hosts but they're custom so that isn't the point.
* Edit to say, I wouldn't recommend any non technical user maintain a WordPress e-commerce site, anyways. Square makes it so easy, hosted secure and has tools for inventory and other things, too. All included in standard credit card processing fees.
I'm sure they aren't the only ones but I was amazed at how simply someone could set up a site, as I know someone who has a store and uses square for payment processing already.
WP specifically makes this non-trivial, because post and db data has hardcoded path info in it. Export/import a database? You have to make changes to it. For something that is 10 years old... an import/export system that acknowledges the reality of plugins and separation of data would be nice.
SSL? When you're running wordpress, and you think "I want everything to be SSL"... you look for a plugin. I wouldn't and don't, but this particular system was something I inherited.
20+ plugins in WP systems seems to be something I run in to far more often than the "expert dev/ops guy who knows about SQL and can handwrite in 5 plugins what takes 15 by normal folks" systems.
I think you're in the minority when it comes to being able to be 'good' with wordpress. As I was suggesting before, part of the appeal in wordpress is there's a low common denominator. Someone who came across your WP code that used custom tables, (instead of throwing EVERYTHING in to either wp_options or post_meta)... they'd be lost. Honestly. Really. I see it quite often. People writing plugins and themes and selling WP solutions not having the foggiest idea how to write or use SQL.
"Square makes it so easy, hosted secure and has tools for inventory and other things, too. All included in standard credit card processing fees."
This particular client was sold on "you can customize everything in woo/wp". There were a number of technical things they wanted to do which Square and others do not do, and they'd already tried with other hosted solutions as well (3dcart, for certain, and maybe another).
What we inherited (and what I normally get in most projects that get referred) is an undocumented mess of stuff that is not in version control of any sort, a mishmash of various versions of libraries, etc.
CAN you build 'decent' code in WP? Without a doubt, it's possible, but the defaults still go against commonly accepted dev practices. The more configs go in databases ("wp_options for everything by default"), the harder migrating between various environments is (I can't just pull code, for example, because db configs are required for everything to run correctly). That's not insurmountable, but you're working in an environment where these common tools and practices are a) not provided and b) not-understandable or accessible by the majority of the developers in that community.
The nicest plugin I've seen [code wise] is the Jasig CAS authentication plugin, and for that I had to modify it to specify the behavior I wanted (custom 500, 501 screens, don't upsert user). So, whenever an update comes around I have to either ignore it or modify the code. Honestly, I think that's even against the license since I didn't publish my changes.
Many people treat WordPress as a fully featured CMS/CRM that runs their entire business. They often have multiple complex custom developed plugins.
Many of those "bottom of the barrel" solutions are someone else's attempt at building "whatever they wanted" with custom post types, theme options, etc.
My number one reason for WPEngine is their excellent support, both in terms of response times and general knowledge. They have never let me or a client down.
My time is money (or the client's money). Yes it's much more expensive than self-hosting, but my hourly rates are much more than their professional plan costs each month. One unfortunate issue and they'll spend more on paying me than they'll save on hosting elsewhere for a year. This is also how I "sell" WPEngine to new leads. It's not a hard sell.
I now have 12+ client sites there. Some several years and none have suffered a single issue of a compromised site. I've actually used WPE's (free) service to migrate compromised sites to their platform and get them cleaned as a feature to garner new clients.
The WPE interface allows me to switch between them in an instant. Add to that general performance/caching, security/firewall, automatic updates, daily snapshots and reverting to a previous version with one click, on-demand backups, the staging site functionality, free automated SSL certs, CDN (pro plans), etc etc
It has come to the point that I don't accept any projects that don't agree on hosting there.
PS Fought battles with many different CMSs --e.g. don't even get me started on Joomla or even Drupal-- and don't believe that wordpress is any more vulnerable than other CMS sites. Moreover, there are so many WordPress developers out there, that I can safely promise that me getting hit by a truck is really not a problem.
Edit 2: I limit plugins to the absolute minimum. I avoid free plugins whenever possible. Buying highly rated plugins with support from places like ThemeForest is really really useful and well worth the money.
https://www.netlify.com/blog/2016/05/02/top-ten-static-websi...
Roots is mentioned, but the team has since developed Spike which is built on a more modern stack:
Wordpress could solve a lot of security issues by using a newer version of PHP, but they are scared of breaking legacy items. Also using things like Wordfence and Cloudflare solve most of the basic Wordpress security issues.
There's nothing stopping you from running it on PHP 7.1 (and we are on our client sites). There's not a great amount that could be gained by WordPress (the project) by dropping support for the older versions; the main gains would be namespacing and closures.
That said, I do think it's time to drop 5.2 support. 5.2 is down to single digit percentages: https://wordpress.org/about/stats/
So they pick wordpress: 1 click install in cpanel, no html, css, js, php knowledge whatsoever, pick a free theme from millions of themes, pick plugins from millions free ones, done. Maybe a bit of google to personalize it but that's it.
What do you offer devs who can make a quick 50 bucks in afternoon installing a plugin/theme, or even 100 for a quick website with admin panel and all that easy stuff?
There is a market for everyone and cms's will live one way or another. The simple & free stuff will always be more successful.
For a variety of reasons, the blog crashed and when I started a new one, I chose Pelican[1]. Haven't looked back.
[1] https://github.com/getpelican/pelican (linking to the github repository because the main site happens to be down https://github.com/getpelican/pelican/issues/2079).
How difficult would it be to get WP to run off of sqlite? I'm not familiar with the code base to know.
NibbleBlog was drag and drop. My friend went to hell and back to fix these exploits. WordPress has more features but also more ins-and-outs to learn. The choice is up to you if it's worth it.
Also from what I remember NibbleBlog stores JSON files and doesn't use SQLite in flat-file mode. Very handy.
Hard, but not impossible. WP has a pluggable database connection class that you can override, but it doesn't have a DBAL. You'd have to modify queries to remove MySQL-specific things.
It is possible though: https://wordpress.org/plugins/sqlite-integration/
1 - use a C panel "one click" install of the CMS from your web host
2 - start looking for plugins to give you the functionality you want
3 - install said plugins without sand boxing them or even testing them for vulnerabilities.
4 - end up getting hacked and then wonder what happened
It's true that for the most part the WP core is pretty solid, but its the billions of sketchy plugins that people use that create vulnerabilities and allows their sited to get hacked.
I have to wonder if WordPress added a small cost and verification system at front, similar to the app store, if third-party code would be of higher quality.
https://bestpractices.coreinfrastructure.org
Disclosure: I'm the co-author of the badge at the Linux Foundation.
The policy docs don't seem specific enough in areas where plugin developers need help (ie. don't use superglobals, raw sql or PHP scripts outside of the plugin load process) while being an over burden in less important areas (ie. requirement that each project have a security expert, and CI builds)
Having an audited plugin repository for Wordpress is an idea i've had in the back of my mind for a while now. I believe it's something a lot of businesses would pay for
I agree that a big part of wpengine's value is the validation they do of certain plugins. A business model that could charge for information of which plugins are most safe would be challenging.
The goal of the Badge project is to incentivize improved behavior by the plugin authors.
That shouldn't be surprising. The CII badge process opened in May 2016, so it's only been available for about half a year. I expect that most WordPress plug-in authors don't even know about it (yet).
> I have to wonder if WordPress added a small cost and verification system at front, similar to the app store, if third-party code would be of higher quality.
I think that's likely. At the very least, someone could run some static analysis on the plug-in with rules very specific to WordPress (e.g., "don't use superglobals"). That could really help.
However, there are many general "good things" that plug-ins should do. Trying to recreate a list of general good practices would take a lot of time, and be a pain (trust me!). Instead of reinventing the wheel for a list of general good practices, I suggest using the CII best practices badge identify general good practices, and then if you wish, create a separate list of rules specific to WordPress. That'd be much easier.
Disclosure: I'm technical lead on the CII best practices project. But it's still a good thing :-).
Static HTML will often fit the bill
Our current setup is using a static site generator (we're Rubyists on Middleman - https://middlemanapp.com/ - but take your pick here) to build the actual site. However, the content itself lives in a cloud-based CMS (we're on Contentful, but Prismic and Siteleaf are also good choices) - this is what the client has access to. During the build proc, the SSG polls the CMS and grabs all the latest content to package into the static site.
On publish of any piece of content in the CMS, a webhook hits our build proc (either Codeship or Netlify) which in turns fires a rebuild of the site (which in turns pulls down the latest content).
For us, the best part about the setup is that it's virtually impossible for the client to break the site. They could certainly make it look like hell - but they can't break it. On top of that, if they somehow, someway, manage to break the build by simply editing content, then the new site is simply never deployed.
Let me know if you have any more questions - I love talking about this stuff.
There are a few things which don't get called out very much, but which were/are some of the underlying motivating factors for people defaulting to wordpress (perhaps as a more root underlying reason behind some of the 'large ecosystem' reasons people typically default to).
A primary one which gets overlooked is that fact that WP is about the only 'framework' of any sorts in any tech stack which allows people to simply move files up to a server. There are no command line incantations to run, no npm/build stuff to use, no compiling, etc. It's about the only platform I can point someone to where they can do an install themselves, and still make modifications later (days/months/years later). Many do 'one click' installs via cpanel or whatever, but even outside of that, the process to install and make changes later is about as basic as you can get - editing and moving files - nothing else needed.
Secondly, in the realm of web frameworks (whether we describe it as one or not, wordpress is indeed a framework, albeit possibly reluctantly for a while), it's one of the few that comes with a username/password/registration process ready to use, out of the box. Anyone looking to build any extension/plugin can count on a standard user/pass/registration/recovery process being there. Most other web platforms shun this most basic aspect, comparing their routing options and ms-oriented benchmarks. I think ASP.NET MVC v4 came bundled with a standard user/reg system?, and one might throw Drupal/Joomla in that camp too. Outside of that - certainly all the major PHP platforms for years - symfony, zend, kohana, code igniter, ez, etc - all gave you parts, then told you to build it youself. Typical rationale was "everyone's needs are different".
So... people 'build it themselves', thinking their own needs were 'different' from everyone else's (hint - vast majority of times, they're not), then we wonder why things get hacked, and point the finger at the devs themselves who... shouldn't have to be reinventing that wheel every other month. Devise in Rails seemed to have been a go-to for a while, and many other languages tend to coalesce around 1-2 frameworks and 1-2 user/auth libraries, but the PHP world is just too damn big for much consensus...
Except in Wordpress. Whether it's good or not, it provided enough of the basics in a standard way to become the basis for people to build on. And... build they did - often extremely poorly (no, really, not everything should necessarily go in to 'wp_options' - session data? really? and I have to run my own stuff to clean it up?)
These low barrier to entries have been at the root of why WP has gained so much popularity and control.
I certainly know there are 'good' ways to develop with WP as a basis, if you wanted to. And some people really want to. But doing things too 'correctly' from a dev standpoint (migrations, testing, dev/staging/prod setups, etc) means you're now fighting against the WP core principles of 'move files up and execute'. The core of WP doesn't support these concepts, and tacking them on feels... tacked on. You're also alienating yourself from the 99% of wordpress developers (in every sense of that word) who do not even understand those concepts in the first place - they will never be able to use or contribute to your code/project/tool. At some point, doing things the 'developer' way conflicts so much with the core ethos of WP, that you're fighting the base, and there's probably not much benefit (outside of latching on to the name recognition) and you're probably better off in another tech stack.
WP itself providing some 'blessed' approaches for creating plugins with testing processes, standard/defined way of importing/exporting plugin data, and other attendant issues around plugins would solve problems for larger-scale developers/users, but might very well alienate many of the folks who were earlier adopters. But... at this point, where else would those folks go?
Told you. Get it on GitHub and watch how much better it becomes.
Also sorting out the versioning would make it more usable.
This took me the time it took to type in the URL as a guess. "wordpress github", "wordpress source" both have this as the first result.
WordPress has historically been a security nightmare.
Possibly there was a tone of anger in the way PravlageTiem expressed themselves, but the security flaws in WordPress are worth discussing any time that WordPress is discussed.
Certainly, when I have a freelance client, and they ask me "Should we use WordPress?" I typically answer with some long version of "It has a good admin section for non-technical users, and also designers love it, but it also has a lot of security flaws."
*Besides best security practices for the server, database and Wordpress install, and clients aren't allowed to install new plugins or tweak the actual source code. The lightweight UI customization that themes provide is usually enough.
Seriously, there are youtube tutorials about 'How to Hack Wordpress.' It can't get much worse than that:
In general, security isn't something that can be tacked on as an afterthought, it has to be built in from the beginning.
This. And all this started around the same time - in 2006 -- when Stefan Esse, the PHP security expert "resigned".
In a blog post in 2006 (that can no longer be found) Esse was quoted as saying he quit > "because among other things they were resistant to his finding bugs in PHP, and had refused to patch some of the bugs he found."
Source(s)
http://www.darkreading.com/risk/php-security-expert-quits/d/...?
https://preilly.me/2006/11/09/php-security-expert-resigns/
PHP is the backbone of WordPress and none of the core team members have taken any of it's security holes seriously, many of which can be traced back to PHP's security hole. They simply come out with "It's the Plugin-Developer's fault" every few months when a security hole is found.
I don't think it's in their best (business) interest to fix WordPress' security holes any time soon. Because Matt Mullenweg, and other "Wordpress Security" companies like Sucuri Security, even WP Engine, all charge an arm and a length (WP Engine is 100$ a month for a simple blog serving < 25K pageviews a month) by selling "Peace of Mind" security with Wordpress if you use them / host with them.
[0]https://web.archive.org/web/20061215080243/http://blog.php-security.org/archives/61-Retired-from-securityphp.net.htmlAnd the Sistine Chapel is a country church.
The bad guys of the world do nothing but find new Wordpress installs and take them over. It's a mess. I'd love to see the next year of Wordpress releases spent on nothing but fixing internal security issues and dealing with some of the upstream PHP stuff.
50% of my inbound traffic is people trying exploits.
One of my clients spends $99/month on WPEngine, and $5-20K per month on the advertising and social media that brings in all their new traffic. They have five people on staff, who probably cost $80-100K per month. $99 for WPEngine is a blessing--it frees them up to think about what's important, rather than wondering whether their tech provider is handling backups.
Your arguments about WP security are not strengthened by the point about WPEngine costs.
""" Because it's ability to generate a limitless supply of zero-days makes it easier for us in San Francisco to go after blogs we don't politically agree with.
Isn't that right, Mr. Altman. :D """
On the topic of PravlageTiem, the issue of WordPress' security flaws seems to be incidental to his attempt to accuse Sam Altman of censorship. If I had to guess, that would be why the comment is dead. I wouldn't call that sarcasm.
Here we go! Like I stated in my comment, companies like WP Engine, Sucuri and other can easily charge 100$ + for what costs < 5$ to host, because it's wordpress and they "guarantee" a secure un-hackable website.
Fear is a great motivator.
This is basically a result of plugins and themes being run as part of the main process (they're just regular PHP code), which is practically-speaking unavoidable.
That's not to say that WP is 100% impenetrable, and any large and mature software is going to have bugs, some of which may turn out to be security-related. The best defence against that is regular updates (inc. auto-updates, which are built in).
(I work at an enterprise WordPress agency where we build large sites for large clients (media orgs, banks, etc). I'm also a committer to WP core, and hence on the WP security team. I'm also one of the leads on the WP REST API project, and was running the HackerOne project until the API was merged into WP.)