How did WordPress win?(majordojo.com)
majordojo.com
How did WordPress win?
http://www.majordojo.com/2011/02/how-did-wordpress-win.php
18 comments
It's not just a question about the software engineering benefits of PHP (or of Wordpress) but also about deploy-ability.
When I started programming CGI scripts in Perl it was unusual for a web server to be configured to let just anybody write CGI scripts because it was easy to hose a web server or a whole machine with CGI scripts. CGI scripts had a highly inefficient execution model, and no resource limits to prevent CPU and memory overages from bringing the server down.
Now, in principle, mod_perl is better, but practically, a mod_perl installation is rocket science. I saw more than one organization with a crumbling system written in Perl reject mod_perl, because their existing code base wouldn't work correctly in it and because they didn't have faith that they could work all the problems out.
PHP, on the other hand, put a trouble-free installation and deployment experience first, rather than last. PHP might be a crappy language, but an absolute idiot can build a very reliable web server that performs acceptably with no effort. Python, Java, Ruby and other languages are superior in many ways, but they've spent years hacking together deployment answers (with various levels of success) as an afterthought, whereas PHP had performance, reliability and simple deployment baked in from day one.
When I started programming CGI scripts in Perl it was unusual for a web server to be configured to let just anybody write CGI scripts because it was easy to hose a web server or a whole machine with CGI scripts. CGI scripts had a highly inefficient execution model, and no resource limits to prevent CPU and memory overages from bringing the server down.
Now, in principle, mod_perl is better, but practically, a mod_perl installation is rocket science. I saw more than one organization with a crumbling system written in Perl reject mod_perl, because their existing code base wouldn't work correctly in it and because they didn't have faith that they could work all the problems out.
PHP, on the other hand, put a trouble-free installation and deployment experience first, rather than last. PHP might be a crappy language, but an absolute idiot can build a very reliable web server that performs acceptably with no effort. Python, Java, Ruby and other languages are superior in many ways, but they've spent years hacking together deployment answers (with various levels of success) as an afterthought, whereas PHP had performance, reliability and simple deployment baked in from day one.
[deleted]
Can you give more detail on this? I'm curious if they're really that bad or if this is just a common thing to say because it's cool to hate anything built in PHP. I made a basic template for WP and I thought the little parts of the API that I used were fine. I've never done anything serious with WP but I do run a WP install.
Some tidbits that come to mind off the top of my head:
Until a few (minor) versons ago, some functions built entire translation tables EACH TIME they were called on the same page load. Someone finally caught it recently and put a static in there.
The critical add_action/do_action functions had a slowdown issue up to a few versions ago if there were more than a dozen actions on a filter. It was finally optimized to be hundreds of times faster.
The first time they tried to update the cookie functions for a major release (I think it was 2.5) they misunderstood the research paper and had to change cookies again in 2.6, breaking some plugins twice in two versions.
The meta tables until very recent history were allowed to have non-unique indexes on key values. This "feature" (an alternative to serialization) was almost never used and made meta updates much more complex (and the db slower in general).
The entire tag db structure was changed in version 2.3, breaking all tag plugins, because someone thought it was theoretically better to have a "Term_taxonomy" reference - which is still unused to this date. Having it in there makes tag queries much more complex and slower. Then they took out the timestamp for when tags were added which makes it impossible to track.
The list goes on and on. Remember, a few versions ago is still 2009.
Last time I checked (2.8?) WordPress still uses SQL_CALC_FOUND_ROWS which has some nasty performance problems on many versions of mysql.
To this day, the query count for most pages on a default install with a few posts/comments without plugins is over 20. WordPress 3.1 now uses nearly 1 megabyte of php code PER INSTANCE.
Oh and last but not least, ALL plugins are loaded on EVERY page load regardless of the request/rendering requirements. Even admin-only functions. Clever plugin authors can somewhat code around this but it's still a crazy system.
Until a few (minor) versons ago, some functions built entire translation tables EACH TIME they were called on the same page load. Someone finally caught it recently and put a static in there.
The critical add_action/do_action functions had a slowdown issue up to a few versions ago if there were more than a dozen actions on a filter. It was finally optimized to be hundreds of times faster.
The first time they tried to update the cookie functions for a major release (I think it was 2.5) they misunderstood the research paper and had to change cookies again in 2.6, breaking some plugins twice in two versions.
The meta tables until very recent history were allowed to have non-unique indexes on key values. This "feature" (an alternative to serialization) was almost never used and made meta updates much more complex (and the db slower in general).
The entire tag db structure was changed in version 2.3, breaking all tag plugins, because someone thought it was theoretically better to have a "Term_taxonomy" reference - which is still unused to this date. Having it in there makes tag queries much more complex and slower. Then they took out the timestamp for when tags were added which makes it impossible to track.
The list goes on and on. Remember, a few versions ago is still 2009.
Last time I checked (2.8?) WordPress still uses SQL_CALC_FOUND_ROWS which has some nasty performance problems on many versions of mysql.
To this day, the query count for most pages on a default install with a few posts/comments without plugins is over 20. WordPress 3.1 now uses nearly 1 megabyte of php code PER INSTANCE.
Oh and last but not least, ALL plugins are loaded on EVERY page load regardless of the request/rendering requirements. Even admin-only functions. Clever plugin authors can somewhat code around this but it's still a crazy system.
My current least favourite design decision is the import/export system. It spits out posts, links etc in an XML file.
So far so good, except that upon importing, it creates an entire tree any memory before doing in processing. I complained to Matt about this being a less-than-ideal design. His response was, essentially, "it works for me".
Of course it works for him. He has dedicated servers with gigabytes of RAM. I do not. What I do have blogs with dozens of authors, thousands of posts and hundreds of thousands of comments. Consolidating them on a single installation of Wordpress has cost me days and days.
So far so good, except that upon importing, it creates an entire tree any memory before doing in processing. I complained to Matt about this being a less-than-ideal design. His response was, essentially, "it works for me".
Of course it works for him. He has dedicated servers with gigabytes of RAM. I do not. What I do have blogs with dozens of authors, thousands of posts and hundreds of thousands of comments. Consolidating them on a single installation of Wordpress has cost me days and days.
Oh, no, I'm a PHP developer myself, and I think that PHP code can be well structured, but Wordpress is generally a mess. It isn't MVC, a lot of it isn't object oriented, and it generally lacks a logical sense of things.
It has gotten better over the years, though, I will grant it that.
It has gotten better over the years, though, I will grant it that.
There's a lot of non-MVC, non-OO "good" code out there. An immediate example is the Linux kernel. I just don't think that's really a great argument; the last several web projects I've done have been MVC, but I haven't really developed an affection for that format, and some implementations (CakePHP ಠ_ಠ ) make it serious pain in the rear.
I guess "no logical sense" is the most legitimate complaint here, but aren't a lot of programs also like that? A lot of things start out one way and end up finding a niche in something different, and that can make the initial assumptions costly and/or annoying, but I don't think it necessarily taints the whole codebase, though.
Maybe I'm old-fashioned but a huge rap sheet of functions is a lot more workable for me than a lot of OO programs that I've had to deal with.
I guess "no logical sense" is the most legitimate complaint here, but aren't a lot of programs also like that? A lot of things start out one way and end up finding a niche in something different, and that can make the initial assumptions costly and/or annoying, but I don't think it necessarily taints the whole codebase, though.
Maybe I'm old-fashioned but a huge rap sheet of functions is a lot more workable for me than a lot of OO programs that I've had to deal with.
MVC (or OO) is not a guarantee against bad code, but it does provide some necessary structure, especially for large, extensible projects. Other patterns can also be utilized, but some kind of pattern needs to be implemented. Wordpress had no logical pattern to it's implementation.
Also, MVC wouldn't make sense for the Linux kernel, but it would make a lot of sense for a major CMS.
Also, MVC wouldn't make sense for the Linux kernel, but it would make a lot of sense for a major CMS.
A lot of the Linux kernel these days is basically OO, at least the parts I look at. It's not in an OO language, but the concepts and patterns are there: an opaque void * "object" that's only accessed via a set of associated "methods", which all have manually name-mangled names like foo_method1 and foo_method2. These "objects" are created via a "constructor" foo_create and destroyed via a manually called "destructor" foo_free, etc. There's even a little bit of manually implemented inheritance and virtual-function stuff going on with function-pointers-in-a-struct type patterns.
Generally a "because it's cool to hate anything built in PHP" thing.
If you take a look at wordpress's internals especially nowadays they aren't that bad
If anything I would say the codebase is not bad and the user interface is amazing. I love it because I know that even the least tech savvy of my clients can figure out its backend user interface so they can make content changes themselves.
Another great thing is especially at this point in its maturity you wouldn't need to alter the wordpress codebase itself at all to get most of the value out of it.
Plugins,whether found or written by you, can take care of whatever you need.
If you take a look at wordpress's internals especially nowadays they aren't that bad
If anything I would say the codebase is not bad and the user interface is amazing. I love it because I know that even the least tech savvy of my clients can figure out its backend user interface so they can make content changes themselves.
Another great thing is especially at this point in its maturity you wouldn't need to alter the wordpress codebase itself at all to get most of the value out of it.
Plugins,whether found or written by you, can take care of whatever you need.
Please don't downvote this guy any more without discussing why he's wrong.
Just take a look at the WordPress' code. "aren't that bad" is like saying shit doesn't smell bad if you get used to it.
Hell, you don't even have to look at the code. Even running some static analysis will tell you how bad it is.
Hell, you don't even have to look at the code. Even running some static analysis will tell you how bad it is.
As a simple example, back in the earlier days, Wordpress was mostly a collection of a many, many functions. As it has matured, it's become more class based and slightly less functions. Perhaps more importantly, many of the functions now have quite good phpdocs so you can simply grep the code to figure out what you want to do. Also, as WP has matured, it's added a lot more hooks and actions for various things you might want to do, so it's become less and less necessary to hack core.
It is still relatively brutish code, but damnit if it doesn't work pretty well.
It is still relatively brutish code, but damnit if it doesn't work pretty well.
The same with any other product, the internals would only matter to the technical people.
Absolutely the dead-simple install has been huge for Wordpress. Getting into Wordpress’ bowls is disgusting, and some configurations you might think would be trivial are impossible, but they hook you in those first five minutes. It’s just so easy to start blogging.
Wordpress is a fractal image of PHP, in that respect. It's-easy-to-start turns into Hotel California.
Hotel California, from Wikipedia:
>The lyrics describe the title establishment as a luxury resort where "you can check out anytime you like, but you can never leave." On the surface, it tells the tale of a weary traveler who becomes trapped in a nightmarish luxury hotel that at first appears inviting and tempting. The song is an allegory about hedonism and self-destruction in the Southern California music industry of the late 1970s; Don Henley called it "our interpretation of the high life in Los Angeles"[6] and later reiterated "it's basically a song about the dark underbelly of the American dream and about excess in America, which is something we knew a lot about."
http://en.wikipedia.org/wiki/Hotel_California_%28song%29
>The lyrics describe the title establishment as a luxury resort where "you can check out anytime you like, but you can never leave." On the surface, it tells the tale of a weary traveler who becomes trapped in a nightmarish luxury hotel that at first appears inviting and tempting. The song is an allegory about hedonism and self-destruction in the Southern California music industry of the late 1970s; Don Henley called it "our interpretation of the high life in Los Angeles"[6] and later reiterated "it's basically a song about the dark underbelly of the American dream and about excess in America, which is something we knew a lot about."
http://en.wikipedia.org/wiki/Hotel_California_%28song%29
Luxury? Hedonism? OK, maybe Hotel California is a bad analogy.
It's easy-to-start rapidly turns into a tarpit made of sparrow droppings.
It's easy-to-start rapidly turns into a tarpit made of sparrow droppings.
It's a common case in PHP, but might have less to do with the language's inelegance than the size of the app. I doubt a comparable CMS in Python/Ruby/etc, with a similar number of contributors and plugins developed over 8 years would really be much better.
(Rails/Django might be a different case, due to the benefits of having an MVC framework as base. But these exist in PHP as well)
(Rails/Django might be a different case, due to the benefits of having an MVC framework as base. But these exist in PHP as well)
I haven't looked at wordpress code in a really long time, but 5 or so years ago I had to hack up a wordpress install for a client. There was one giant monolithic method that created a string for the sql query to get the posts for pretty much every imaginable part of a wordpress site that is an index of posts. there was a combinatorial explosion of options you could pass this monolith and it was nearly impossible as someone who didn't write it to figure out how to make it do something really simple like add paging to the RSS url.
There is no reason any code in any language should have this sort of problem. It isn't merely cruft from a long legacy of existence.
There is no reason any code in any language should have this sort of problem. It isn't merely cruft from a long legacy of existence.
The core difference between the platforms was that wordpress was designed for any schmuck to follow a howto, while MT was designed to sell the real product, professional services billable hours. There were soooo many things about MT that stayed locked up in "plugin packs" or were completely undocumented that if you weren't paying a few (hundred)grand in proserv it was just plain not a usable product.
For the record, I was the enterprise customer clamoring for ldap support in Byrne's post, and I've since worked for another high profile site built on MT. Its a solid product if you bring a handful of good engineers in on top of it, its just got that "you must be this tall" barrier to entry that makes it an immediate loss for broad-consumer adoption.
For the record, I was the enterprise customer clamoring for ldap support in Byrne's post, and I've since worked for another high profile site built on MT. Its a solid product if you bring a handful of good engineers in on top of it, its just got that "you must be this tall" barrier to entry that makes it an immediate loss for broad-consumer adoption.
An even better question is why WordPress continues to win.
I've done a few startups and quite often I will create the marketing front end in WordPress/PHP. Even if the main application will be written in Ruby or Python.
The reason is that there are just so many off the shelf templates and themes you can download and/or buy. And the themes are generally in the under $25 price range. Plus finding people who can maintain a marketing site in WordPress is extremely easy. For the simple stuff like "add a post" or "update the text" you don't even need to know PHP.
Now it would be nice if there was a dead simple platform like WordPress for Python. But until that day comes it is still a pretty damn good solution for a site.
I've done a few startups and quite often I will create the marketing front end in WordPress/PHP. Even if the main application will be written in Ruby or Python.
The reason is that there are just so many off the shelf templates and themes you can download and/or buy. And the themes are generally in the under $25 price range. Plus finding people who can maintain a marketing site in WordPress is extremely easy. For the simple stuff like "add a post" or "update the text" you don't even need to know PHP.
Now it would be nice if there was a dead simple platform like WordPress for Python. But until that day comes it is still a pretty damn good solution for a site.
The license debacle got me to switch (I clearly remember Dive Into Mark's spirited long rant), but Movable Type's weird Perlisms, and quirks like rebuilding all the posts when you changed the layout, would have sent me running eventually anyway. MT just wasn't a great package in the first place.
(Disclaimer: I worked for Six Apart Services for 2 years)
I don't think MT has "weird perlisms", it's just... written in perl. WordPress took off around the time folks were realizing that you could build big sites in PHP, and so PHP in general was taking off (as Byrne mentions in his piece, more enterprise sites were adopting PHP as well). Perl started a slide back into "sysadmin" land as far as many developers and managers were concerned.
Static publishing is not a "quirk": it's a feature that sold MT to most of the large publishers using it. Yes, you have to make some design decisions with static publishing in mind, but I've never heard of an MT site being Fireballed, either.
I don't think MT has "weird perlisms", it's just... written in perl. WordPress took off around the time folks were realizing that you could build big sites in PHP, and so PHP in general was taking off (as Byrne mentions in his piece, more enterprise sites were adopting PHP as well). Perl started a slide back into "sysadmin" land as far as many developers and managers were concerned.
Static publishing is not a "quirk": it's a feature that sold MT to most of the large publishers using it. Yes, you have to make some design decisions with static publishing in mind, but I've never heard of an MT site being Fireballed, either.
It's also a barrier to entry. The right way to do static publishing is to have a dynamic site with a cache. Wordpress started with just a dynamic site. MT started with just a cache.
Cache-only works OK for big sites, but it's annoying for little sites. And the little sites are the big sites of tomorrow.
Wordpress's dynamic-only strategy created a huge pool of potential big customers for Wordpress, and they later tacked on caching. SixApart's cache-only strategy kept a small pool of existing big customers happy, but it was a barrier to entry, and there wasn't an easy path to the ideal "dynamic+cache" solution.
Cache-only works OK for big sites, but it's annoying for little sites. And the little sites are the big sites of tomorrow.
Wordpress's dynamic-only strategy created a huge pool of potential big customers for Wordpress, and they later tacked on caching. SixApart's cache-only strategy kept a small pool of existing big customers happy, but it was a barrier to entry, and there wasn't an easy path to the ideal "dynamic+cache" solution.
I was there when it happened, as were many around here.
Movabletype did their pay-only nonsense after version 2.66
People starting looking for alternatives.
WordPress 1.5 out and 2.0 was in beta and it seemed the strongest choice at the time. 2004 is like a lifetime for the internet, seems like a poor choice now but things were different then.
Movabletype did their pay-only nonsense after version 2.66
People starting looking for alternatives.
WordPress 1.5 out and 2.0 was in beta and it seemed the strongest choice at the time. 2004 is like a lifetime for the internet, seems like a poor choice now but things were different then.
Came here to post this. Although MT was a far more mature and better product, the licence shenanigans just drove everyone away. It was as though someone in MT just thought, "Hey guys, how can we alienate every non-paying user?" and ran with it.
Matt and co were very shrewd, had a 'good enough' product and got a few high profile bloggers to switch (and be vocal about it) and WordPress became the common blogger's tool. By the time 2.0 was released it became fairly ubiquitous for blogs, and people added stuff from there to make it a fuller CMS.
Matt and co were very shrewd, had a 'good enough' product and got a few high profile bloggers to switch (and be vocal about it) and WordPress became the common blogger's tool. By the time 2.0 was released it became fairly ubiquitous for blogs, and people added stuff from there to make it a fuller CMS.
Essentially Wordpress was a triumph of marketing. There were other ostensibly just-as-functional systems around, but Wordpress had a nice looking site and moved fast to capitalise on the MT licensing fuckup.
I switched from Blogger to WordPress and began learning PHP in January 2005. In August 2005 I went to work for Automattic as the second full-timer (after Donncha, inventor of WPMU). That was before WordPress.com was announced. I am still working for Automattic.
Byrne, in his MT-centric worldview, fails to mention a man who contributed more to WP's success than MT's failures could. The name "Matt" only appears within "Automattic" and the name "Mullenweg" doesn't even show up until the comments.
Many have said it and I agree: WordPress is shitty software. Having written a significant percentage of the code in WordPress since version 2.0, I can proudly accept the blame for some of the shittiest parts of WordPress. I was responsible for the integration of the rich editor, the widgets system, the media library, and many other poorly-designed components I have since expunged from memory. I wrote this crap because Matt asked me to.
In wisdom or dumb luck, Matt saw that a feature that mostly works for most users next week is better than a perfect feature next year. He coded as much as he could, then he learned to delegate and trust others. Then, as far as I could tell from inside my coding cave, he shifted most of his attention from engineering and design to promotion and business. He brought Toni and Raanan into Automattic and that's when the switching campaign really took off.
From the early days to now, Matt has exploited every resource for the benefit of WordPress. Even now, non-WordPress Automattic projects help subsidize the core development of WordPress. I don't know how much money Matt has made but I know that everyone who makes a living with WordPress owes him some credit for feeding so much power back into the project.
Matt wasn't the only contributor to the success of WordPress. It would be impossible to cover them all; go look at the About page on wordpress.org to get a taste. But if you could use a time machine to kidnap one person off that list, you would do the most harm to WordPress by choosing Matt.
Byrne says in a comment that his piece is about WordPress, not Automattic. He works hard to avoid delving into personalities. But the story of WordPress can't be told without discussing Matt Mullenweg. If your goal is to "see what lessons can be learned from WordPress so that others seeking to build a successful product can learn from it" you really should be looking at the people and the work they did more than the project that they worked on.
Byrne, in his MT-centric worldview, fails to mention a man who contributed more to WP's success than MT's failures could. The name "Matt" only appears within "Automattic" and the name "Mullenweg" doesn't even show up until the comments.
Many have said it and I agree: WordPress is shitty software. Having written a significant percentage of the code in WordPress since version 2.0, I can proudly accept the blame for some of the shittiest parts of WordPress. I was responsible for the integration of the rich editor, the widgets system, the media library, and many other poorly-designed components I have since expunged from memory. I wrote this crap because Matt asked me to.
In wisdom or dumb luck, Matt saw that a feature that mostly works for most users next week is better than a perfect feature next year. He coded as much as he could, then he learned to delegate and trust others. Then, as far as I could tell from inside my coding cave, he shifted most of his attention from engineering and design to promotion and business. He brought Toni and Raanan into Automattic and that's when the switching campaign really took off.
From the early days to now, Matt has exploited every resource for the benefit of WordPress. Even now, non-WordPress Automattic projects help subsidize the core development of WordPress. I don't know how much money Matt has made but I know that everyone who makes a living with WordPress owes him some credit for feeding so much power back into the project.
Matt wasn't the only contributor to the success of WordPress. It would be impossible to cover them all; go look at the About page on wordpress.org to get a taste. But if you could use a time machine to kidnap one person off that list, you would do the most harm to WordPress by choosing Matt.
Byrne says in a comment that his piece is about WordPress, not Automattic. He works hard to avoid delving into personalities. But the story of WordPress can't be told without discussing Matt Mullenweg. If your goal is to "see what lessons can be learned from WordPress so that others seeking to build a successful product can learn from it" you really should be looking at the people and the work they did more than the project that they worked on.
"In wisdom or dumb luck, Matt saw that a feature that mostly works for most users next week is better than a perfect feature next year."
In other words, Worse is Better.
In other words, Worse is Better.
<i>2 What makes Movable Type hard to install has actually nothing to do with Perl at all. It has to do with CGI. CGI was originally architected to allow any script to be run and invoked via an addressable URL, and when that capability was first introduced system administrators and programmers feared the security ramifications of allowing any arbitrary script to be executed in that fashion. Therefore, they instituted a number limitations enforced by the web server: 1) only certain directories on your web server can possess the ability to run CGI scripts, 2) only executable files can be invoked via CGI, and 3) no static files (html, css, javascript, or any text file) can be served from the same directory as a CGI script. These limitations are often inappropriately attributed to Perl only because Perl became the dominant, if not the only scripting language used to author CGI based web applications early on.</i>
But... many (most?) shared webhosts - which support PHP and WP just fine - run in CGI or FastCGI mode. GoDaddy, IIRC - all PHP is CGI-based. It's been a while since I've done LAMPhp setup, and even longer since that P meant Perl, but it's always felt (as in, going back to 2000/2001) that configuring Apache for mod_php or CGI PHP was just more straightforward than Perl. Reasons?
PHP allows for (encourages?) very 'hack' based approach to development, which most other languages don't. Don't understand how or why to pass parameters around? Just use the 'global' keyword. Rinse, repeat, and you've got your customizations to WP.
I'm not saying all WP mods are hacks, but it was/is very easy for people to experiment with trying their hand and hacking around. IMO this was the biggest thing that has led to WP dominating, and PHP as a language continuing to dominate. Yes, it's not the cleanest around, but it does allow for rapid experimentation (far more than something like Java, and depending on the code you're hacking, Perl).
But... many (most?) shared webhosts - which support PHP and WP just fine - run in CGI or FastCGI mode. GoDaddy, IIRC - all PHP is CGI-based. It's been a while since I've done LAMPhp setup, and even longer since that P meant Perl, but it's always felt (as in, going back to 2000/2001) that configuring Apache for mod_php or CGI PHP was just more straightforward than Perl. Reasons?
PHP allows for (encourages?) very 'hack' based approach to development, which most other languages don't. Don't understand how or why to pass parameters around? Just use the 'global' keyword. Rinse, repeat, and you've got your customizations to WP.
I'm not saying all WP mods are hacks, but it was/is very easy for people to experiment with trying their hand and hacking around. IMO this was the biggest thing that has led to WP dominating, and PHP as a language continuing to dominate. Yes, it's not the cleanest around, but it does allow for rapid experimentation (far more than something like Java, and depending on the code you're hacking, Perl).
The first quote shows exactly why they lost the battle:
"""...in fact, if you want to say anything, why don't you run it by me first? And Anil, and through marketing, and while you are at it through a couple other people as well... Cool?"""
Every single issue is about giving maximum control to the users for wordpress. Licensing, easy of installation on almost any host, and language choice. All these said, "Wordpress lets you control your code, where you install it, and how you manipulate it."
In my mind it was a battle of cultures and philosophy. For example, wordpress had the idea of the five minute install. They focused on making the 20% that 80% of users absolutely need as easy as possible.
"""...in fact, if you want to say anything, why don't you run it by me first? And Anil, and through marketing, and while you are at it through a couple other people as well... Cool?"""
Every single issue is about giving maximum control to the users for wordpress. Licensing, easy of installation on almost any host, and language choice. All these said, "Wordpress lets you control your code, where you install it, and how you manipulate it."
In my mind it was a battle of cultures and philosophy. For example, wordpress had the idea of the five minute install. They focused on making the 20% that 80% of users absolutely need as easy as possible.
What do people use these days when they want to self host something a bit more light weight? I have setup a few wordpress installations but really if I wanted something to tinker with I think I would look elsewhere, the code has you trawl though many files at times to make simple changes.
Jekyll (http://jekyllrb.com) is a "blog aware static site generator." I use it to power my blog and I love it. You write your layouts in HTML or HAML using the Liquid templating language and then your posts can be in markdown/textile/whatever and you run Jekyll - it generates static HTML files and publishing is just a SCP away.
There really isn't anything outside of HTML, or perhaps Squarespace?
I'd love to find something in the middle.
I'd love to find something in the middle.
Jekyll is a nice way to generate a static HTML blog.
A step above that is Frog CMS.
Closer to WordPress are Habari and Chyrp, which are still fairly lightweight.
If you're just looking to publish a weblog-like thing, rolling your own remains a viable option...
The easy install and developer friendly focus is what attracted me to it. The license and the language attracted developers and designers towards making lots of themes and plugins. Furthermore a large professional developer base legitimized Wordpress in the eyes of bloggers.
Wordpress is probably one of the greatest things that has ever happened to the internet.
As a the administrator of a small Wordpress network, I respectfully disagree.
At the risk of sounding foolish, what exactly is a Wordpress network, and what is it for?
(not a troll, genuinely interested)
(not a troll, genuinely interested)
It's what they now call a "Multi-site" installation, previously Wordpress Mu. Essentially I have a single installation and DB serving a number of different blogs.
The expression "Wordpress network" generally means a branded site for these. Wordpress.com is the biggest, edublogs is big too. I run a little one called Ozblogistan: http://ozblogistan.com.au
The expression "Wordpress network" generally means a branded site for these. Wordpress.com is the biggest, edublogs is big too. I run a little one called Ozblogistan: http://ozblogistan.com.au
Is that before or after Geocities?
I think it would make more sense to state that generally.
'A Free, Open Source, feature rich, easily set up publishing platform is the greatest thing that ever happened to the internet'.
But, isn't that basically what the internet was created for? So it sounds a bit like 'The internet is the greatest thing that ever happened to the internet'. If it wasn't WordPress fulfilling this role, I could easily see another product doing the same thing.
'A Free, Open Source, feature rich, easily set up publishing platform is the greatest thing that ever happened to the internet'.
But, isn't that basically what the internet was created for? So it sounds a bit like 'The internet is the greatest thing that ever happened to the internet'. If it wasn't WordPress fulfilling this role, I could easily see another product doing the same thing.
To clarify, I mean: I agree that the emergence of an open source, free and libre content management system based on a similarly open programming language, operating system and server environment is a fantastic thing for society. It didn't have to be WordPress specifically, that's all, because WordPress is not perfect or unique. It merely fills that role well.
"greatest things that has ever happened to the internet"
What a bold bold statement. Care to elaborate why?
What a bold bold statement. Care to elaborate why?
I would say it is one of the greatest things. Not only can you get started on the WordPress website, but you can download it and run your own. It appeals to everyone, kind of like other great things: Google and Facebook come to mind. There's something for everyone to get excited about, from bloggers to programmers.
I pretty much know something like 0.1% programming and have very little artistic skill but decided to have fun with building websites anyways with html using frontpage and dreamweaver. They came out alright as i used a template then hacked the crap out of it. It took a lot of work still and gave up for a while. Then i decided to make a prank site and used moveable type first and tried a few other blogging software, ending up with wordpress because it was more flexible than moveable type at the time and much easier to use. I think this was version 1.5. I still have that blog up somewhere on a free server, oh man was it easy to use compared to today. Later i got a job at a local web design firm. They had their own CMS based on .Net. It was actually quite good, quite easy, and powerful as hell. They charged $4k to use it. I wouldn't know what to do with it even if i had access to the code. I played with some other CMSes while there, drupal being one that gained steam while a bunch of others. Oh man are they hard to use. It takes quite a while to figure them out. I gave up on websites yet again. A few friends needed a site so i fired up trusty wordpress, now at 3.0. Wow did they change a lot. Stuff that should have been there from the beginning are finally there. Its now 30x more complicated, trying to teach someone WP3 almost defeated the original reason why i chose wordpress, it had a simple backend. But its still a good bit easier to use than most other stuff and I know it well enough to hack most things up. And the themes/plugins jesus, try even searching for a theme for moveable type on google, i came up with 2 ugly ones. And Britney Spears website comes up as Movable types featured showcase? That can't be good...
WP makes thing easier and harder for me at the same time. Well I guess its like money, the more you have the more problems it brings. As for the backend, But try WP 3.1, it adds a top bar that was so useful from a plugin i used since 1.5. Also wordcamp rocks.
WP makes thing easier and harder for me at the same time. Well I guess its like money, the more you have the more problems it brings. As for the backend, But try WP 3.1, it adds a top bar that was so useful from a plugin i used since 1.5. Also wordcamp rocks.
[deleted]
[deleted]
I started using it because it was easy to install and tinker with. I stopped using it because I fundamentally disagree with Matt on a variety of topics.
I don't like the management, but it is a good product.
I don't like the management, but it is a good product.
for all of WordPress' open sourcey, socialist, hippy goodness
Now I don't think socialism is a dirty word, but saying Open Source is socialist is wrong. If anything it's extreme Libertarianist. It's saying if I give you something, you can do whatever the fuck you want with it.
Open Source is not about the government, or any other organization, providing institutionalized software for the good of all.
Now I don't think socialism is a dirty word, but saying Open Source is socialist is wrong. If anything it's extreme Libertarianist. It's saying if I give you something, you can do whatever the fuck you want with it.
Open Source is not about the government, or any other organization, providing institutionalized software for the good of all.
"Now I don't think socialism is a dirty word, but saying Open Source is socialist is wrong. If anything it's extreme Libertarianist. It's saying if I give you something, you can do whatever the fuck you want with it.
Open Source is not about the government, or any other organization, providing institutionalized software for the good of all."
Open source may be this way, but the GNU (which Wordpress is licensed under) isn't.
The GNU license makes it so everyone is equal. Nobody can have any competitive advantage over another, because as soon as you do, everybody else can now have your code.
You also can't do anything you want with it.
Open source may be this way, but the GNU (which Wordpress is licensed under) isn't.
The GNU license makes it so everyone is equal. Nobody can have any competitive advantage over another, because as soon as you do, everybody else can now have your code.
You also can't do anything you want with it.
Honestly, I think the answer is pretty straightforward in this case: WordPress was just a great piece of software, much ahead of its competitors.
But it wasn't really at the time. That's what's interesting.
In terms of ease-of-install and basic user interface stuff, I remember it as a substantial improvement over most of what people had been exposed to.
Mind you, I hated it passionately from the first time I was asked to do anything more involved than installing it and switching a theme, and I've never had any inclination to use it on my own time, but I think it's easy to forget that the bar was pretty low when WordPress first came on the scene.
Mind you, I hated it passionately from the first time I was asked to do anything more involved than installing it and switching a theme, and I've never had any inclination to use it on my own time, but I think it's easy to forget that the bar was pretty low when WordPress first came on the scene.
There's something to be said for open source packages which work really well out-of-the-box for the vast majority of people who use it.
But oh, my lord, are the internals awful.