The problem with wordpress security is mostly attached the insecure developer practices when dealing with themes. Many developers just take a standard theme, copies it, and then attach their own modifications. This piece of code never gets updated and the owner rarely even know that its there until they get hacked, reinstall with a updated wordpress, and then get rehacked a few days later.
Themes rarely have hackable exploits due to what they (are supposed to) do. If there's insecure code in there it's probably code with functionality that belongs in a plugin to start with. Themes that have had vulnerabilities in them tend to be the kinds of commercial themes that are filled with features and 3rd party scripts to satiate users demands. Not really a WordPress core problem, it is a market problem. Although package management is something WordPress lacks in.
That made my day.
I got Anxiety Attacks reading that article and some of the comments here. A shitty codebase with a kinda useless API on top of the cockroach of databases. Et voilà, the perfect platform to make the web a little bit less stable, less performant and contributing to the increasing trend of low quality code.
i kind of wonder how did we get to this point. technologically speaking it's a disaster - terrible slow and insecure language as a platform for bad practices and codr base. i guess the answer is that technical excellence.is absolutely secondary to other concerns, but it's a concerning view.
There may be other technical solutions that are better from a technology POV.
What WP did right is to choose a platform supported EVERYWHERE (PHP, and not Ruby, Java or other crap only supported by few hosters), with a shitload of developers (again, the massive advantage of PHP), and packed the installation process in a way everyone from an 8-year old school kid to a 70-year old grandpa can handle (and literally, I have seen both!).
Also add in that wordpress.com's free hosting platform... well... surpasses any other blog solution by far.
> What WP did right is to choose a platform supported EVERYWHERE
When WP was created, their options were PHP or Perl. PHP was by far the hottest thing back then, so what they actually did was use the hot tech of the day and made it work. The reason PHP is supported everywhere is for the same reason; back then it was PHP or Perl via CGI. Python was added later and was also supported EVERYWHERE.
Technical excellence is usually secondary to anyone except technicians and a few power users. It was the same with VHS/Betamax. The network effect and the set-up cost are much more important for the majority of users than technical excellence.
Google and Ask.com used to have a "Blog search" feature. Nowadays minor sites are hard to find, and many seatch results on the first page are ads (that look almost like real search results on a non-IPS screens aka low price TFT/LCD screens on consumer notebooks/PCs).
That's something that gets overlooked in these discussions of wordpress. Wordpress has the unique ability to use a single install and backend to manage hundreds of sites. If you need content cross posted across multiple sites, wordpress can do that. If you want to pull an entire column of articles from one site to another, wordpress can do that.
Wordpress has spent a ton of time on multisite features and (as far as I know) there's no other CMS in existence that handles this stuff out of the box. That's why large media companies love it and, I suspect, why a quarter of the internet runs it still when there are faster and more secure alternatives out there.
I've never used it professionally, but dotCMS is a Java- and Elasticsearch-based CMS that has very impressive multisite features [1]. From what I can tell, a lot of its capabilities stem from a design that treats absolutely everything (data, content, static assets, "themes") as a node in a virtual filesystem, or rather a filesystem-per-site, so everyday filesystem operations cover a lot of use cases. I believe you can even manipulate your site(s) via WebDAV to some extent, e.g. to develop a theme in your IDE of choice while saving directly to the site or, more realistically, saving to a private staging copy of the site that lives on the same server, which you can then copy into production from within the dotCMS admin.
I gave some consideration recently to adopting dotCMS for client work to replace an in-house PHP CMS, but although Java-the-language isn't particularly intimidating and dotCMS itself looks fairly self-contained and straightforward to deploy -- Elasticsearch is embedded rather than requiring separate setup, for example -- it's still tied up in the Java ecosystem (OSGi, maven, XML configuration) so there's a lot to get used to for someone approaching it from outside that realm.
tl;dr: It's 25% of the top 10 million websites according to Alexa over the last 3 months, and only includes top-level domains (So skips counting the millions of WordPress.com subdomains).
If it were all websites, it'd surely include tens of millions of low-traffic WordPress sites - but none of those are used in this calculation.
> tl;dr: It's 25% of the top 10 million websites according to Alexa over the last 3 months, and only includes top-level domains (So skips counting the millions of WordPress.com subdomains).
Nit, from someone in this industry: A top-level domain is .com, .net, .org, etc. The Alexa statistics only include second-level domains, which is what fully qualified domain names without hostnames are called.
WordPress is like the Kalashnikov of the web. You can use it for pretty much anything, run it anywhere, do god knows what to it and it'll still happy hum along (albeit behind a very big varnish cache).
A few of our clients have millions of pageviews running off of a couple t2.small instances and the single biggest factor for them is the UI and the security of knowing they're not tied into a bespoke platform.
nginx + varnish + cdn + pagespeed + php-apc. Most definately possible and you will still have 400+mb memory to spare on a 1gb server, avg cpu usage is at 30-40%. Done it for few clients myself.
We have clients running multisite with 150MM+ page views per month but on dedicated hardware and Varnish running in front of it. The latter is a must in a setup like this. You save on MRC for server rentals, which is a huge value proposition.
I run a community site that does 1m pv's a month and growing but we get hammered on 'breaking news' as wp-super-cache does not seem to handle post updates well under high use thus interested in possible solutions or alternatives.
It's roughly $90/mo for 1m+ pvs/mo (includes management). With wp-super-cache you're still hitting PHP/MySQL (although not as heavily if you're pulling everything cold).
Whereas with Varnish you're getting hot pages off RAM and on you go.
If everything is cached, sure, serving static content is cheap. The comparison with a solid machine I find it funny, a bad update in a plug-in can render your site useless for a while and WP's security record is abysmal.
An argument to be made is that it's security record is due strictly to its popularity. Given the choice between the 1000 pound gorilla that everyone uses and has double digit CVEs released every year, and the unknown that nobody uses, I'm going to pick the first one simply because the second one likely has just as many holes - there's just not enough people trying to attack it.
Wordpress has improved a lot since version 3, and most of the vulnerabilities you see for it now require some kind of privilege escalation or don't really give the attacker a whole lot to work with (http://www.cvedetails.com/vulnerability-list/vendor_id-2337/...). And Wordpress handles updates remarkably well, including automatically installing security updates in the background.
I previously hated Wordpress because it was a source of so much trouble on the web, but now I sort of grudgingly appreciate it. I still don't enjoy having to work with it on occasion for clients, but it doesn't make me grind my teeth anymore.
I have to say, setting up blogger was just far too hard. Maybe something has changed, but back in the day I was trying to find a math renderer for http://randomtechnicalstuff.blogspot.com.au - but couldn't find anything.
I haven't bothered since, and my latest blog at http://sherlockchrisblog.wordpress.com is just working with LaTeX markup. It's honestly a breath of fresh air.
It's not that surprising to be honest. WordPress' success comes down to the following:
1. It was simple to use in an era where CMS meant 'large, complicated system that was tailored towards technies rather than the general population'. It didn't have a ton of features, but it was easy to use for the average blogger wanting to write posts without worrying about all the setup and coding and what not.
2. You could pretty much install it anywhere without minimum technical skill, since PHP and MySQL was (and is) supported by about 99.99% of shared hosts. Its newer competitors tend to be written in languages that are usually only available on a VPS or dedicated server.
3. It has a very large ecosystem for themes, plugins and other such things, so someone with no technical skill could find add ons for anything they wanted without needing to call in a developer or know PHP.
It's not the best written software and its not the best optimised for anything in particular, but it is one of the easiest to install and use for someone without a technical background, which is why it's so widespread.
I agree with your points, but always wonder why shared hosting is often PHP/MySQL only. E.g. if you are using Python, say Django or Flask, and want to outsource your devops (i.e. shared hosting) you do not have many options.
Of course, there is pythonanywhere or you might want to use PAAS like Heroku, but I find it interesting non the less. Is it so much more work for shared hosting providers to provide Python?
PHP guys are very smart about not trying to reinvent the wheel. They always supported the most common web setup: Apache running on its standard configuration. That's why every shared host company in the world is confident in deploying PHP and avoids like the plague more complex solutions based on Python, Java, and Rubi.
I'd say it's actually the opposite - the users are comfortable with PHP and not the more complex solutions. I'd love for us to support other stuff, but anyone who is using anything else wants more control over their environment than the average shared host can offer. We have as many deployment issues etc. with PHP as we would anything else... possibly more.
That said, isn't 'IaaS' like Heroku basically 'shared hosting for other stuff'?
> but always wonder why shared hosting is often PHP/MySQL only.
It's easy. Compare with trying to track Rails upstream, particularly in the 2.x/3.x days when minor version increments could sometimes see you building a whole new set of ruby binaries compare to what shipped with your base Linux distro.
How often do you hear PHPers handwringing about virtual environments, locking dependencies, and whatnot? Like DOS and Windows, the PHP world has done a pretty good job of making it easy to install PHP, run PHP programs, and not spend hours of your life dinking with mutually-incompatible bits of the stack.
Why would a shared hosting service want the pain of other solutions?
I've studied this one a few times and it's very much a positive feedback loop.
Rewind to 2005: Django and Rails had just been released. PHP had already been out for 10 years and there were dozens of large systems - PostNuke, phpBB, WordPress, Drupal - that were already out there being useful.
For many hosts, their customers wanted to get a blog, forum, etc online quickly and easily. The vast majority were written in PHP, so they set up with PHP by default. Throw in the fact that most of these companies deployed Cpanel (or similar) with one-click installers like Fantastico, etc - which dealt with PHP exclusively iirc - and it was a no-brainer.
The availability of apps drove PHP deployments.
The sheer number of PHP deployments drove the installation of the same apps.
The simple answer is that the last time I looked I couldn't find good documentation for getting Python (and Ruby) support working side-by-side with a modern LAMP stack. Most Python (and Ruby) hosting-related documentation assumed nginx, which, while I like it otherwise, still lacked good support for .htaccess files, which are a must-have when providing hosting for people using things like Wordpress and Joomla and Drupal. The documentation that I could find for Apache environments was way, way behind the best practices for a PHP+Apache environment and some of the recommendations were orthogonal to my current environment.
I still would like to provide a hosting environment that can handle a mix of PHP and Python and Ruby, but it's going to be fiddly and involve a lot of trial-and-error and I haven't been able to justify the time sink yet.
Getting suexec + event-mpm + fcgid + PHP opcode caching has been enough of a headache as it is.
Take a look at webfaction. They support apache+php as well as a host of other languages and frameworks (python+django, ruby+rails) by treating them as separate webapp (e.g. each php websites run their own apache instance under local linux user) and uses nginx as reverse proxy in front of those webapps.
PHP was designed from the ground up to work well on shared hosting with things like restrictions on CPU and memory use so one user wouldn't bring down the others. Here's PHP's inventor explaining:
You forgot backwards compatibility. For #3, the large ecosystem didnt grew overnight, it was an accumulation of themes, plugins, and dev hours throughout the years. It was made possible by WP's backwards compatibility.
The total economic activity attributable to WordPress must be staggering. How many small businesses use it? How many consultants and design firms? Even the business of creating WordPress themes must be very significant.
(I have no affiliation at all with this nor any other WordPress business, I just think it's interesting—as a counterpoint to the stereotypical HN focus on fancy new technology—how enormously productive this ecosystem really is.)
> One day, as I was in the process of writing a post for inspireddad.org, I had a sudden epiphany. I thought to myself, WordPress is not like any other website builder I have used before. It is powerful, simple, and can be used for almost anything… and I can see myself making a living off of this one day. It was this thought that set me into motion, and I began learning everything I possibly could about WordPress—I became obsessed. [...]
> I honestly believe I might have given up on this dream if it hadn’t been for the amazing support that the ET team gave to me early on. This support, coupled with my own growing WordPress knowledge, enabled me the opportunity to launch approximately two dozen websites in my first year—which gave me the confidence I needed to take my business to the next level. [...]
> The incredible support and products of [Elegant Themes] have enabled me the chance to do what I love—achieving an entrepreneurial lifestyle that has allowed me to truly help my clients, while also giving my family my time and attention as a husband and father.
I'm half tempted to abandon my current plans of startup world domination and just make WordPress websites for local businesses.
It's a fascinating ecosystem, but a little confusing. I was hoping there was an easy(ish) way to develop a custom theme, and use wp.com for hosting -- but as far as I've been able to figure out, there's no way to do that -- to use wp.com is to opt out of any serious customization. On the flip side, you get (presumably) rock solid wp hosting, and few security issues.
Every time I've considered wp, I've ended up turning away - the code base is quite awful for the basic features it provides, and as soon as you start adding third party plugins (for added features), you need to be very careful to avoid either breaking on updates, or security issues (with a plugin, or cross section of plugins). It feels like half of the traffic to full-disclosure is related to wp plugins.
I'm not the typical wp customer of course, but for me the ability to develop some fairly static (html+js+css) themes along with wp hosting might have been interesting. If I can't use custom themes, wp.com hosting isn't all that interesting -- and if I have to host it myself, I want something that's a more solid software design than wp (and hopefully maxes out at around a single db query per page view. Something which is easier if you can assume the db has proper views, for example (select * from anonymous_page_view where page_id=?)).
I see that the same is true for the elegantthemes (which appear to be terrific value at ~250 USD for a life-time, unlimited license, btw):
"Unfortunately WordPress.com does not allow the use of custom themes. If you would like to use a custom theme of any kind, you will need to purchase your own hosting account and install the free software from WordPress.org. If you are looking for great WordPress hosting, we recommend giving HostGator a try."
Yeah, I don't think I'll be suggesting clients to use HostGator as a web host.
Wrt. themes and wp.com -- I can see how I could make a few themes and sell them at an affordable price -- I don't really see how the economics of support works out when you need to deal with the entire gamut of outdated php/mysql versions and the plethora of combinations of server+(f)cgi/php-module+mysql/mariadb/otherdbs(?)+windows/solaris/bsd/linux for support and testing. Not to mention interaction with hundreds of buggy third party wp plugins.
> I'm half tempted to abandon my current plans of startup world domination and just make WordPress websites for local businesses.
I agree entirely with the premise that WordPress is not the most impressive codebase in the world — but that's not why people select it.
The reason that sites opt to use WordPress is that the editorial interface is familiar and the plugin ecosystem is very robust. The reason that sites stay on WordPress is that upgrades arrive for free every couple of months and do not break backwards compatibility.
WordPress's performance has improved over the years largely as a result of the rising tide of CPU and RAM upgrades and improvements to PHP and MySQL themselves — and more recently through integrations with Elasticsearch, which WordPress works particularly well with.
It's also possible to use WordPress as a framework and to develop elegant code using its APIs, which is largely what my firm does (I run one of the handful of agencies that partner with Automattic to provide WordPress consulting to big companies). But that's the exception, not the rule, and most of the prospective developers we interview who have WordPress experience can't use it the way we want.
Paid plugins (with support) are the way to go for getting the highest quality and I've had great experiences with them. Some of the ones I've had great luck with on my site are Advanced Custom Fields, Gravity Forms, and most recently FacetWP.
Edit: that said, there are also high quality free ones as well
Any consultants on here that have to deliver/maintain WordPress sites? If so, mind sharing what your basic workflow is?
There are many articles on the web, but they are mostly for very entry level users. The fundamental problem my company runs into with WP is that only a theme can be meaningfully checked into version control. Everything else, including installation of plugins is coupled with entries in the database. And of course the database also includes changes necessarily made on the production instance, like comments to blog posts.
Any thoughts or links to posts on this greatly appreciated.
If you prefer git-based deployment for your wordpress project, bedrock is probably for you: https://roots.io/bedrock/
Also, wp-cli helps a lot in streamlining the project (enabling/disabling plugins, updating site settings, etc, all from command line or deployment script scripts)
I worked briefly for a wordpress consultancy last year.
Our main workflow involved using Yeoman, Grunt, NPM, wp (the wordpress command line tool) and vagrant. Locally, we'd run vagrant just so we don't have to monkey around with environment issues (too much). Yeoman, grunt, npm and wp were used in tandem to script the creation of a new wordpress install, install any dependencies needed, run any tools needed through grunt (like sass and JS minifiers), and pull plugins and themes from their separate git repositories. We still had to import the database by hand, though, when setting up our environment as well as add lines to wp-config for however we wanted to handle debugging.
Then we'd write code and check it in via git as with any other project. If you were working on frontend anything (html,css,js) you either ran grunt all the damned time or ran grunt watch. Those of us who had a hard time with the unique programming requirements of wordpress (escaping, sanitizing, formatting) used phpcs to automate that.
As for deployment, we'd just go through the same setup on the server that we do locally. Updates were pushed via git.
The fundamental problem my company runs into with WP is that only a theme can be meaningfully checked into version control. Everything else, including installation of plugins is coupled with entries in the database.
That wasn't my experience. We separated functional features into separate plugins (so they could be disabled or enabled on a site by site basis) and had no problem using version control with them. In fact, one project had some government security problems and required each plugin to be in its own repo. I wouldn't suggest that, but it works.
the database also includes changes necessarily made on the production instance, like comments to blog posts
That was something I found aggravating that was never really addressed at the company I worked at. When new people were brought on to a project, they'd get a mysql dump of the staging environment. After that, as new features were added, you were responsible for adding your own test data to see if those features worked. As for production, the changes made that were specific to the production database were made manually in production. When a new plugin was pushed, you had to log into the production instances manually and turn the new plugin on. Luckily, there are hooks you can use to automate any setup or teardown of plugins when they get turned on and off respectively.
I recently looked at Hugo[1] as a WP alternative and have been very impressed. It's a static website generator written in Go and features its own server with live-reload so you can see changes to your content instantly in the browser. I was looking for something that a non-techie might be able to maintain and since Hugo offers prebuilt binaries the only requirements for the maintainer is to drop hugo.exe into the working directory and type a few commands. In the end though, it's still a bit more complicated for non-techies than maintaining a website created via WordPress.
Considering some of the people I've made wordpress sites for couldn't even figure out the wordpress interface, command line anything is a no go for a large percentage of wordpress's intended audience.
Yeah, I'm sure it'd be possible to build on top of Hugo (or many other static site generators) to build something that might be usable for the typical wp customer - but afaik none of them are that out of the box. The most likely alternative I can think of is Ghost: https://ghost.org/
But, I'm not sure how easy it is to customize along the lines that people expect from wp (Now, that could be considered a feature - but it also means it could be a hard sell to someone that just wants a wp site).
If what is needed really is a static site (a "web site"/"homepage") -- I think netlifly looks quite promising:
Actually the command line interface wasn't the deal breaker for me. I was asked to help out creating a website for a tiny organization (< 10 people). Once I found out multiple people would need to collaborate and edit the website it basically eliminated Hugo as a possibility. I suppose they could sync files via Dropbox but as I'm not a dropbox user myself I have no idea how it handles merges. Git is not really a possibility for obvious reasons.
Finally, deployment is the final hurdle. If they wanted to edit a sentence on a WordPress site it's very easy. But with something like Hugo it would be a 3 step process: Edit the file. Build the website. Deploy to your web host.
Not sure what you meant by that. I mentioned it was written in Go for the HN crowd. You do not need to know Go to use it. I've never written a Go program in my life and followed the tutorial without any issues.
Another vote for Hugo, it's lightning fast on the generation side and the support is amazing. I came across a subtle bug in the generator and within a day or two there was a fix in the works.
But it does get an inordinate amount of attention from people looking to crack it. At least according to my server logs. So sure... if everything is locked down and up to date and no shaky plugins installed no problem. On the other hand, one careless slip up...
And how is it not the same for any other server side software?
Most of the WP security issue is related to user not knowing what they are doing or third party plugin/theme.
Wordpress vanialla itself is not anymore insecure than other popular CMS or simialar software out there. From my own personal experince from doing at least 70-80 WP installs in different configurations and have never experienced any security issues in over 10 years. Thats doesnt mean its the norm. Its just that if you are going to play with a highly customizable and powerful piece of server side software and if you dont know what you are doing then you are going to screw shit up.
Other server side software doesn't get nearly the same number of attacks. At least according to my server logs. Plus, other server side software doesn't let button clickers get into trouble as easily.
I learned a lot about security on the web by poking around wordpress sites in school. While I believe what you're saying is true it's hard to believe that the perception alone of wordpress's 'hackability' doesn't make it much more of a security risk.
"Oh they run wordpress? I can probably get into that."
Yup: so I moved my low traffic vanity site back to static html when I worked out that I was spending more time reinstalling WordPress because of security advisories than actually writing anything.
As the chap who runs pinboard put it [1] people like me should not be running web applications like WordPress on live server space.
So I ran WordPress locally and harvested the html pages. Then realised that I was using a poky little text area to write when I could just use a text editor...
I agree that Wordpress is probably the most secure major CMS out there, but it's unfortunately still not good.
It had a whole bunch of XSS issues lately. XSS should be a thing of the past if people would implement Content Security Policy. I'm not aware that Wordpress is working on this. This is hardly defensible.
On the positive side I think their automatic update mechanism helps a lot and it's a pity other major CMSes don't have that.
"The big opportunity is still the 57% of websites that don’t use any identifiable CMS yet, and that’s where I think there is still a ton of growth for us (and I’m also rooting for all the other open source CMSes)."
Raw [programming language of choice] or custom CMS that someone's nephew hacked together and they don't care enough or have the time/money to replace.
In 2005-2008, I made good money switching people from those systems to Drupal with the simple pitch of plugging into a larger community and being able to shop around for modules and developers who wouldn't have to learn a new codebase.
I must admit ignorance here. I've installed WP a couple of times but never went live with it or did anything past poking around.
Here's my hangup: I can't understand why one would start with a blogging platform, pound at it with various plugins and transform it into, say, a product/ecommerce website. It feels like starting with a shovel when you need a pick (or some other more applicable analogy).
That's the part I don't quite understand. Carrying all of that baggage to build something diametrically opposite what the original stated function of the software may have been.
On the funny end of the scale, I've seen five page static websites with a landing page, a few info pages and a form done with WP. Unbelievable. Are developers that lazy today that they throw WP at everything? Or is it easier at that level to charge X to do a WP site rather than charging the same for straight-up PHP/HTML/JS?
On the funny end of the scale, I've seen five page static websites with a landing page, a few info pages and a form done with WP. Unbelievable. Are developers that lazy today that they throw WP at everything? Or is it easier at that level to charge X to do a WP site rather than charging the same for straight-up PHP/HTML/JS?
When the client says they want to be able to update site content themselves.... okay, here's your five page WordPress site with a single form.
I haven't used Wordpress much, but I am working on an Orchard site at my current job. It's a CMS kinda like Wordpress, but built on C#/ASP.NET. Our dev team is mostly working on a dozen or so custom-coded account management pages in a separate module, but most of the content is marketing material as pages built in the Orchard management screens, kind of like blog posts, but arranged like a conventional website.
The developers aren't terribly enthusiastic about working with those Orchard pages, since they're tough to collaborate on and version control. But the Marketing people seem to like it just fine, probably because conventional web site building tools, like writing HTML and CSS and managing folders of content with source control tools, is too complex and error-prone for them, and the site UI is worlds better than any other technique they might be willing to use. I'm guessing Wordpress works in a similar way.
Now that I think about it, I had always idly wondered whatever happened to those desktop GUI web page building tools, like Frontpage and Dreamweaver and such. They may still be around, but don't seem to have any mindshare. Maybe it's because the people who were using them put up Wordpress sites instead and are building their pages in the Wordpress UI.
The first problem is pigeon-holing it as a blogging platform that you have to bolt stuff onto. There's a lot more to WordPress than blogging these days. The origins are still there, sure, but fewer and fewer sites these days are using that as a starting place.
> On the funny end of the scale, I've seen five page static websites with a landing page, a few info pages and a form done with WP. Unbelievable. Are developers that lazy today that they throw WP at everything?
I see some version of this question all the time. The main problem is that you're thinking about it from a development perspective only. The major thing WordPress brings to the table is democratization of publishing from the user perspective. You see a five page site some dev built and wonder where the benefit is. The benefit is that the actual owner of the site, the "user" can easily control, modify, add-on-to, or remove that content. They can easily turn it into a 10-page site if they want to.
With some of these other less user-friendly systems (such as static site generators), control largely rests in the hands of developers, with WordPress, it rests with the content owners.
113 comments
[ 2.8 ms ] story [ 133 ms ] threadWhat WP did right is to choose a platform supported EVERYWHERE (PHP, and not Ruby, Java or other crap only supported by few hosters), with a shitload of developers (again, the massive advantage of PHP), and packed the installation process in a way everyone from an 8-year old school kid to a 70-year old grandpa can handle (and literally, I have seen both!).
Also add in that wordpress.com's free hosting platform... well... surpasses any other blog solution by far.
Are you sure? To me, it's by far the slowest one of them all.
When WP was created, their options were PHP or Perl. PHP was by far the hottest thing back then, so what they actually did was use the hot tech of the day and made it work. The reason PHP is supported everywhere is for the same reason; back then it was PHP or Perl via CGI. Python was added later and was also supported EVERYWHERE.
Germanys big hosting player Strato doesn't offer Python in its cheap plans, Hosteurope according to their FAQ is stuck at python 2.6.
Granted, a German-centered POV, but still. Python support is far from mainstream.
It's full of horrendous things all the way down, but it just doesn't matter.
https://managewp.com/14-surprising-statistics-about-wordpres...
(2014)
How many users/hits/bandwidth of the web does WP get?
While impressive, the headline is misleading.
http://www.wpbeginner.com/showcase/40-most-notable-big-name-...
It's fairly common among large media publications.
Wordpress has spent a ton of time on multisite features and (as far as I know) there's no other CMS in existence that handles this stuff out of the box. That's why large media companies love it and, I suspect, why a quarter of the internet runs it still when there are faster and more secure alternatives out there.
I gave some consideration recently to adopting dotCMS for client work to replace an in-house PHP CMS, but although Java-the-language isn't particularly intimidating and dotCMS itself looks fairly self-contained and straightforward to deploy -- Elasticsearch is embedded rather than requiring separate setup, for example -- it's still tied up in the Java ecosystem (OSGi, maven, XML configuration) so there's a lot to get used to for someone approaching it from outside that realm.
[1] http://dotcms.com/#anchor1
tl;dr: It's 25% of the top 10 million websites according to Alexa over the last 3 months, and only includes top-level domains (So skips counting the millions of WordPress.com subdomains).
If it were all websites, it'd surely include tens of millions of low-traffic WordPress sites - but none of those are used in this calculation.
Nit, from someone in this industry: A top-level domain is .com, .net, .org, etc. The Alexa statistics only include second-level domains, which is what fully qualified domain names without hostnames are called.
A few of our clients have millions of pageviews running off of a couple t2.small instances and the single biggest factor for them is the UI and the security of knowing they're not tied into a bespoke platform.
http://nestify.io/benchmarks/
I run a community site that does 1m pv's a month and growing but we get hammered on 'breaking news' as wp-super-cache does not seem to handle post updates well under high use thus interested in possible solutions or alternatives.
Whereas with Varnish you're getting hot pages off RAM and on you go.
https://www.varnish-cache.org
Or, you can start with this to get the general idea first:
https://en.wikipedia.org/wiki/Varnish_software
I previously hated Wordpress because it was a source of so much trouble on the web, but now I sort of grudgingly appreciate it. I still don't enjoy having to work with it on occasion for clients, but it doesn't make me grind my teeth anymore.
I haven't bothered since, and my latest blog at http://sherlockchrisblog.wordpress.com is just working with LaTeX markup. It's honestly a breath of fresh air.
1. It was simple to use in an era where CMS meant 'large, complicated system that was tailored towards technies rather than the general population'. It didn't have a ton of features, but it was easy to use for the average blogger wanting to write posts without worrying about all the setup and coding and what not.
2. You could pretty much install it anywhere without minimum technical skill, since PHP and MySQL was (and is) supported by about 99.99% of shared hosts. Its newer competitors tend to be written in languages that are usually only available on a VPS or dedicated server.
3. It has a very large ecosystem for themes, plugins and other such things, so someone with no technical skill could find add ons for anything they wanted without needing to call in a developer or know PHP.
It's not the best written software and its not the best optimised for anything in particular, but it is one of the easiest to install and use for someone without a technical background, which is why it's so widespread.
Of course, there is pythonanywhere or you might want to use PAAS like Heroku, but I find it interesting non the less. Is it so much more work for shared hosting providers to provide Python?
That said, isn't 'IaaS' like Heroku basically 'shared hosting for other stuff'?
It's easy. Compare with trying to track Rails upstream, particularly in the 2.x/3.x days when minor version increments could sometimes see you building a whole new set of ruby binaries compare to what shipped with your base Linux distro.
How often do you hear PHPers handwringing about virtual environments, locking dependencies, and whatnot? Like DOS and Windows, the PHP world has done a pretty good job of making it easy to install PHP, run PHP programs, and not spend hours of your life dinking with mutually-incompatible bits of the stack.
Why would a shared hosting service want the pain of other solutions?
Rewind to 2005: Django and Rails had just been released. PHP had already been out for 10 years and there were dozens of large systems - PostNuke, phpBB, WordPress, Drupal - that were already out there being useful.
For many hosts, their customers wanted to get a blog, forum, etc online quickly and easily. The vast majority were written in PHP, so they set up with PHP by default. Throw in the fact that most of these companies deployed Cpanel (or similar) with one-click installers like Fantastico, etc - which dealt with PHP exclusively iirc - and it was a no-brainer.
The availability of apps drove PHP deployments.
The sheer number of PHP deployments drove the installation of the same apps.
The simple answer is that the last time I looked I couldn't find good documentation for getting Python (and Ruby) support working side-by-side with a modern LAMP stack. Most Python (and Ruby) hosting-related documentation assumed nginx, which, while I like it otherwise, still lacked good support for .htaccess files, which are a must-have when providing hosting for people using things like Wordpress and Joomla and Drupal. The documentation that I could find for Apache environments was way, way behind the best practices for a PHP+Apache environment and some of the recommendations were orthogonal to my current environment.
I still would like to provide a hosting environment that can handle a mix of PHP and Python and Ruby, but it's going to be fiddly and involve a lot of trial-and-error and I haven't been able to justify the time sink yet.
Getting suexec + event-mpm + fcgid + PHP opcode caching has been enough of a headache as it is.
PHP was designed from the ground up to work well on shared hosting with things like restrictions on CPU and memory use so one user wouldn't bring down the others. Here's PHP's inventor explaining:
https://youtu.be/6uodrhwUXFM?t=10m48s
It is, lots of people make full-time livings doing it, and even have entire companies set up to do it.
http://www.elegantthemes.com/gallery/divi/
Here's a testimonial from an independent web site creator that I found interesting.
http://www.elegantthemes.com/blog/customer-spotlight/creatin...
(I have no affiliation at all with this nor any other WordPress business, I just think it's interesting—as a counterpoint to the stereotypical HN focus on fancy new technology—how enormously productive this ecosystem really is.)
> One day, as I was in the process of writing a post for inspireddad.org, I had a sudden epiphany. I thought to myself, WordPress is not like any other website builder I have used before. It is powerful, simple, and can be used for almost anything… and I can see myself making a living off of this one day. It was this thought that set me into motion, and I began learning everything I possibly could about WordPress—I became obsessed. [...]
> I honestly believe I might have given up on this dream if it hadn’t been for the amazing support that the ET team gave to me early on. This support, coupled with my own growing WordPress knowledge, enabled me the opportunity to launch approximately two dozen websites in my first year—which gave me the confidence I needed to take my business to the next level. [...]
> The incredible support and products of [Elegant Themes] have enabled me the chance to do what I love—achieving an entrepreneurial lifestyle that has allowed me to truly help my clients, while also giving my family my time and attention as a husband and father.
I'm half tempted to abandon my current plans of startup world domination and just make WordPress websites for local businesses.
Every time I've considered wp, I've ended up turning away - the code base is quite awful for the basic features it provides, and as soon as you start adding third party plugins (for added features), you need to be very careful to avoid either breaking on updates, or security issues (with a plugin, or cross section of plugins). It feels like half of the traffic to full-disclosure is related to wp plugins.
I'm not the typical wp customer of course, but for me the ability to develop some fairly static (html+js+css) themes along with wp hosting might have been interesting. If I can't use custom themes, wp.com hosting isn't all that interesting -- and if I have to host it myself, I want something that's a more solid software design than wp (and hopefully maxes out at around a single db query per page view. Something which is easier if you can assume the db has proper views, for example (select * from anonymous_page_view where page_id=?)).
I see that the same is true for the elegantthemes (which appear to be terrific value at ~250 USD for a life-time, unlimited license, btw):
https://www.elegantthemes.com/join.php#wp-com "Can I use your themes with WP.com?"
"Unfortunately WordPress.com does not allow the use of custom themes. If you would like to use a custom theme of any kind, you will need to purchase your own hosting account and install the free software from WordPress.org. If you are looking for great WordPress hosting, we recommend giving HostGator a try."
Yeah, I don't think I'll be suggesting clients to use HostGator as a web host.
Wrt. themes and wp.com -- I can see how I could make a few themes and sell them at an affordable price -- I don't really see how the economics of support works out when you need to deal with the entire gamut of outdated php/mysql versions and the plethora of combinations of server+(f)cgi/php-module+mysql/mariadb/otherdbs(?)+windows/solaris/bsd/linux for support and testing. Not to mention interaction with hundreds of buggy third party wp plugins.
> I'm half tempted to abandon my current plans of startup world domination and just make WordPress websites for local businesses.
Best of luck to you :-)
The reason that sites opt to use WordPress is that the editorial interface is familiar and the plugin ecosystem is very robust. The reason that sites stay on WordPress is that upgrades arrive for free every couple of months and do not break backwards compatibility.
WordPress's performance has improved over the years largely as a result of the rising tide of CPU and RAM upgrades and improvements to PHP and MySQL themselves — and more recently through integrations with Elasticsearch, which WordPress works particularly well with.
It's also possible to use WordPress as a framework and to develop elegant code using its APIs, which is largely what my firm does (I run one of the handful of agencies that partner with Automattic to provide WordPress consulting to big companies). But that's the exception, not the rule, and most of the prospective developers we interview who have WordPress experience can't use it the way we want.
It's not true, a lot of WP plugins are buggy and sometimes conflict each other.
> upgrades arrive for free every couple of months and do not break backwards compatibility
But sometimes plugins break with upgrades
Edit: that said, there are also high quality free ones as well
There are many articles on the web, but they are mostly for very entry level users. The fundamental problem my company runs into with WP is that only a theme can be meaningfully checked into version control. Everything else, including installation of plugins is coupled with entries in the database. And of course the database also includes changes necessarily made on the production instance, like comments to blog posts.
Any thoughts or links to posts on this greatly appreciated.
A plugin will usually set some entries on installation (then add its work data as well)
But yeah, I believe there's an interesting void of supporting tools for WP (it needs to be DevOps'd)
[0] https://github.com/ExpandedFronts/revisr
Also, wp-cli helps a lot in streamlining the project (enabling/disabling plugins, updating site settings, etc, all from command line or deployment script scripts)
Our main workflow involved using Yeoman, Grunt, NPM, wp (the wordpress command line tool) and vagrant. Locally, we'd run vagrant just so we don't have to monkey around with environment issues (too much). Yeoman, grunt, npm and wp were used in tandem to script the creation of a new wordpress install, install any dependencies needed, run any tools needed through grunt (like sass and JS minifiers), and pull plugins and themes from their separate git repositories. We still had to import the database by hand, though, when setting up our environment as well as add lines to wp-config for however we wanted to handle debugging.
Then we'd write code and check it in via git as with any other project. If you were working on frontend anything (html,css,js) you either ran grunt all the damned time or ran grunt watch. Those of us who had a hard time with the unique programming requirements of wordpress (escaping, sanitizing, formatting) used phpcs to automate that.
As for deployment, we'd just go through the same setup on the server that we do locally. Updates were pushed via git.
The fundamental problem my company runs into with WP is that only a theme can be meaningfully checked into version control. Everything else, including installation of plugins is coupled with entries in the database.
That wasn't my experience. We separated functional features into separate plugins (so they could be disabled or enabled on a site by site basis) and had no problem using version control with them. In fact, one project had some government security problems and required each plugin to be in its own repo. I wouldn't suggest that, but it works.
the database also includes changes necessarily made on the production instance, like comments to blog posts
That was something I found aggravating that was never really addressed at the company I worked at. When new people were brought on to a project, they'd get a mysql dump of the staging environment. After that, as new features were added, you were responsible for adding your own test data to see if those features worked. As for production, the changes made that were specific to the production database were made manually in production. When a new plugin was pushed, you had to log into the production instances manually and turn the new plugin on. Luckily, there are hooks you can use to automate any setup or teardown of plugins when they get turned on and off respectively.
[1] https://10up.github.io/Engineering-Best-Practices/
[1] https://gohugo.io
But, I'm not sure how easy it is to customize along the lines that people expect from wp (Now, that could be considered a feature - but it also means it could be a hard sell to someone that just wants a wp site).
If what is needed really is a static site (a "web site"/"homepage") -- I think netlifly looks quite promising:
https://www.netlify.com/
Finally, deployment is the final hurdle. If they wanted to edit a sentence on a WordPress site it's very easy. But with something like Hugo it would be a 3 step process: Edit the file. Build the website. Deploy to your web host.
We're doomed :-(
The issue is that its simplicity and easy installation, brought a lot of non-technical people to use it and develop for it.
So you get a lot of bad written themes and plugins that lead to all sort of security issues.
On the other hand, Drupal and Joomla, all had SQL injections on their core discovered lately:
https://www.drupal.org/SA-CORE-2014-005
https://blog.sucuri.net/2015/10/joomla-3-4-5-released-fixing...
And how is it not the same for any other server side software?
Most of the WP security issue is related to user not knowing what they are doing or third party plugin/theme.
Wordpress vanialla itself is not anymore insecure than other popular CMS or simialar software out there. From my own personal experince from doing at least 70-80 WP installs in different configurations and have never experienced any security issues in over 10 years. Thats doesnt mean its the norm. Its just that if you are going to play with a highly customizable and powerful piece of server side software and if you dont know what you are doing then you are going to screw shit up.
"Oh they run wordpress? I can probably get into that."
"Runs wordpress vulnerability scanner script"
"Oh hey look ~wp-config.php!"
As the chap who runs pinboard put it [1] people like me should not be running web applications like WordPress on live server space.
So I ran WordPress locally and harvested the html pages. Then realised that I was using a poky little text area to write when I could just use a text editor...
[1] http://idlewords.com/2009/09/how_to_not_get_your_blog_hacked...
On the positive side I think their automatic update mechanism helps a lot and it's a pity other major CMSes don't have that.
"The big opportunity is still the 57% of websites that don’t use any identifiable CMS yet, and that’s where I think there is still a ton of growth for us (and I’m also rooting for all the other open source CMSes)."
I wonder what currently runs the remaining 57%.
[1] http://ma.tt/2015/11/seventy-five-to-go/
In 2005-2008, I made good money switching people from those systems to Drupal with the simple pitch of plugging into a larger community and being able to shop around for modules and developers who wouldn't have to learn a new codebase.
Here's my hangup: I can't understand why one would start with a blogging platform, pound at it with various plugins and transform it into, say, a product/ecommerce website. It feels like starting with a shovel when you need a pick (or some other more applicable analogy).
That's the part I don't quite understand. Carrying all of that baggage to build something diametrically opposite what the original stated function of the software may have been.
On the funny end of the scale, I've seen five page static websites with a landing page, a few info pages and a form done with WP. Unbelievable. Are developers that lazy today that they throw WP at everything? Or is it easier at that level to charge X to do a WP site rather than charging the same for straight-up PHP/HTML/JS?
When the client says they want to be able to update site content themselves.... okay, here's your five page WordPress site with a single form.
The developers aren't terribly enthusiastic about working with those Orchard pages, since they're tough to collaborate on and version control. But the Marketing people seem to like it just fine, probably because conventional web site building tools, like writing HTML and CSS and managing folders of content with source control tools, is too complex and error-prone for them, and the site UI is worlds better than any other technique they might be willing to use. I'm guessing Wordpress works in a similar way.
Now that I think about it, I had always idly wondered whatever happened to those desktop GUI web page building tools, like Frontpage and Dreamweaver and such. They may still be around, but don't seem to have any mindshare. Maybe it's because the people who were using them put up Wordpress sites instead and are building their pages in the Wordpress UI.
> On the funny end of the scale, I've seen five page static websites with a landing page, a few info pages and a form done with WP. Unbelievable. Are developers that lazy today that they throw WP at everything?
I see some version of this question all the time. The main problem is that you're thinking about it from a development perspective only. The major thing WordPress brings to the table is democratization of publishing from the user perspective. You see a five page site some dev built and wonder where the benefit is. The benefit is that the actual owner of the site, the "user" can easily control, modify, add-on-to, or remove that content. They can easily turn it into a 10-page site if they want to.
With some of these other less user-friendly systems (such as static site generators), control largely rests in the hands of developers, with WordPress, it rests with the content owners.