The one big mistake in his premise, however, is that only 34% of WordPress users are blogging, the actual percentage is much higher. The survey he quotes me talking about was of mostly people who make their living building WordPress sites (over 20,000) and mostly WordPress.org users. This community naturally focuses (and contributes) more on the CMS and application framework side of WordPress.
On WordPress.com, however, the vast majority of its millions of users blog, and are blogging more every day. If you visit WP.com you will see a simplified and streamlined user experience that is boldly different from the traditional wp-admin dashboard. Already we've seen huge boosts in user engagement from this new experience, and while it's a few dozen iterations from being ready I'm confident the best concepts will make their way back into WordPress core when they are ready.
But overall, I love seeing different people's takes on what the next generation of WordPress will look like, and I wish more people did blog posts like this. We've had 3 dramatic shifts in our evolution before, and the shape the next one will take is a topic that occupies most of my waking hours, mind space, and creativity. And don't even get me started on mobile... :)
You can still access the full nuts-and-bolts dashboard via a drop-down menu, but it's deliberately harder to find, and editing happens in the simplified area by default. I've recommended WordPress.com accounts to a few people recently; I was surprised by this change, but they - having never used WordPress - seemed delighted by the simplicity of it. This can only be a good thing, and I can see this working in WordPress.org blogs too.
I run a collaborative writing forum and, newly obsessed with markdown at the time, I figured that since users were mostly writing many paragraphs of text, they could pick up the markdown basics if a toolbar + cheatsheet helped them out. In my head, it was going to be some sort of amazing improvement and my forum community would begin chanting my name as they experienced the splendors of markdown.
Yeah, sure -- the writers could certainly grasp markdown #headers, how two linebreaks become a new `<p>`, and even `()` vs `()` links (with toolbar/cheatsheet help). Great! But nested elements and pretty much anything more complicated were a real monkey wrench or just plain unsupported.
Writers would put great effort into their posts (just like a blogger would), changing colors, right-aligning, center-aligning, changing font sizes. -- Things that markdown just doesn't support without some extending or post-processing that would turn into something far more confounding than the intuitive bbcode you started with.
Everyone just understands:
[center][size="6"][color="red"]My Cat, Mittens:[/color][/size][/center]
[size="3"]Mittens says: [i]"Meow!"[/i][/size]
What did your cheatsheet look like?
Also, other communities that deal with a similar audience had the same problem with Markdown and moved back to BBCode. For example, these guys (http://guildwork.com/forum/threads/4e46f3d5205cb22721000765-...) moved from BBCode to Markdown and then ended up moving back and writing their own BBCode parser in Python.
Markdown is good when users have limited syntactical/formatting options. But BBCode makes it easier to extend features with an intuitive syntax that nobody seems to have trouble with.
One example would be Markdown's dependence on character glyphs:
I am currently writing a forum CMS (http://pygm.us/IbkgNZ4d), and I, too, have wondered how to expand the number of tags within a rigid nomenclature. Using a lexer that automatically converts links to tweets and YouTube videos to embedded scripts seems like an unintuitive solution, but on the other hand, people unfamiliar with the commands will automatically display the embeds in their posts.
For commands that don’t convert links, I was thinking about something like ':<COMMAND>:' with an expandable list of whatever people prefer. Something Awful already use this model for their emoticons, and it could be extended to things like images in general like states for election conversation and such.
I have always found the `[url]` solution to be incredibly bothersome and to some extent unintuitive, and with the advent of mobile devices, letting people write their posts in as few characters as possible is a big advantage to be taken into consideration when weighing the pros and cons.
Lots of vBulletin forums use the `:<string>:` syntax because vBulletin's default smilie set ships with that form of syntax (even though you can use arbitrary strings like setting "lol" to display a laughing gif) so everyone just piles onto it. Basically, direct string replacement seems to be universally understood by all users.
But the real riddle here is devising a syntax superior to bbcode that transcends string replacement and does things like take arguments and act like functions.
Because, it's this less-straightforward symbolism that requires the higher order of savviness/pattern-recognition that less-experienced users struggle with. Like `!()` turning into an image (but not `! ()`) or why you'd need to indent 4 spaces to resume a bullet point after an empty line.
In other words, where you and I may find it obvious that we're conforming to the rules of a parser (on some back-of-the-mind intuition at least), I found that this concept of mechanical recognition is nonobvious to the user archetype that expressed confusion over Markdown. To them, `! ()` doesn't work because of a negative rule "there can't be a space", not because the token is simply no longer recognizable to the robot behind the curtains that renders their post. That's the crux I've arrived at that makes Markdown suboptimal for my particular community demographic.
The final point I discovered is that users almost always use the toolbar button for anything that comes from their clipboard (namely image and website URLs). Click, paste, and done. Even on smartphones. So essentially all Markdown did there was take cumbersome syntax that was seldom typed-in to begin with and replace it with less intuitive syntax for a benefit that was seldom awarded: being easier to type! Users then had to confront the `()` beast when editing posts or modifying their post's layout.
Fun stuff to ponder. It's always extremely eye-opening and humbling to be so wrong.
Moreover, I can teach people Markdown 10x faster than I can teach them CMS-specific HTML rules. Moreover, WordPress's TinyMCE stuff can break quiet easily (we have to disable it for most of our writers, I'm still allowed to have it because I never use it), so having a readably syntax AND having an instant-preview seems pretty perfect.
As a huge fan of the WordPress community and what the software and platform has empowered, I'm seeing a decreasing amount of interest in blogging as my social network turns toward meme-sharing and 140-character quips simply because they're much more conducive to consumption and sharing on mobile.
It's so bad that there are startups trying to fix this like Blogstand (http://blogstand.co - our project). We know that others are attempting the same (and they should be!)
I would 100% agree with that.
Every time I use my iPhone to browse to Twitter or LinkedIn I'm taken away from the full site and to a silly "mobile" site that resembles the native app. If I wanted the native app. experience, I'd download and use it! Ever try approving a LinkedIn recommendation using your iPhone? Good luck!
It seems to me that many people think that "mobile responsiveness" is such a great thing, but I'm not sure they've really considered whether it's even necessary. I'd bet that most designers who build WP sites on themes that tout "mobile responsiveness" (and have it enabled by default) haven't even considered whether their client needs the second version of their site. Even if they do, I think often times the "mobile" version ends up being an ugly, hardly-tested, bastardized version of the "full site". Just give us the real website, please!
Absolutely. We had the WordPress community summit just last week, and one of the topics we discussed several times was mobile. The WordPress apps are good, but there's improvements that can be made to both the apps and the way they interact with a WordPress install, so plans were made to move this stuff forward. It's definitely something that everyone (especially Matt) is interested in.
the promise of blogging for me has always been the ability to have my own printing press and know that nearly everyone else in the world had access to one as well.
i'm still trying to understand how this "evolution" has actually decreased the quality of communication.
the promise of blogging for me has always been
the ability to have my own printing press and know
that nearly everyone else in the world had access
to one as well.
Then again, this versatility has its drawbacks. We're constantly challenged by the complexity of building a mobile viewport onto WordPress and present it in a way that makes reading, discussing and sharing this kind of content. The options for publishers are limitless and translating that to mobile in a way that makes sense is really non-trivial.
In core WordPress we'll track our progress and discuss over on the Make/Mobile blog. Feel free to chime in there! http://make.wordpress.org/mobile
I remember switching from my first self written CMS to a small blogging platform called wordpress a couple of years ago. I never looked back after that :)
That's fine, as mentioned in the post, but there is a reason that Svbtle (etc) is suddenly the flavour of the month, and it's not just cause Dustin is the coolest kid in San Fran.
This project doesn't need someone who loves WordPress and wants make more plugins for it. It needs someone who thinks they can make a good thing even better. Steve Jobs didn't just make a new cover for mobile phones. He fundamentally proved that communicational devices must become many times better than what they were before and that's what I expect from John.
Even Steve couldn't fix AT&T so don't expect John to fix WordPress core issues. That job is for WordPress itself.
Buried in the text is it would be a fork of wordpress.
Net is filled with that sentiment, but it never takes off:
If you want to replace wordpress you need a modern rewrite, not a fork.
The #1 problem of wordpress (among many) is it loads every darn thing on every darn page and it's now a godzilla of a program so it's becoming a huge nightmare. A cache miss in WordPress on a busy server is a horrible, horrible thing.
You cannot escape that problem by a fork.
And the whole-page-is-images thing really bothered me too. Some nice designs and interesting ideas for sure, and knowing CSS isn't a prerequisite for being a designer, but damn, I have some doubts about the understanding of the technologies here.
Which is probably exactly where the concept of "forking Wordpress" came from—a misunderstanding of exactly what that would entail.
Modern rewrite is what's needed, definitely. But don't call it anything related to Wordpress. Don't need to.
Perhaps one thing overlooked in the argument for fork vs new build is that there aren't a huge number of developers with the skills to make this happen who would do it entirely on an Open Source contribution basis as opposed to, say, a startup basis. Appealing to existing WordPress developers, businesses and users, as well as cutting down time to ship first working concept, are (in my mind) some important arguments in favour of a fork.
I am one of the early contributors to WordPress (you'll see my name on wp.org's About page near the bottom), and one of the founders of the Habari Project. We started the Habari Project for many explicit reasons, but in part because the curators of the project (Automattic) were not behaving in a way that we felt was beneficial to the community they had begat. So let me tell you a little about our project:
Not only is the Habari Project an entirely Open Source platform, but it recognizes participants in the project appropriately based on their contributions, something that I did not observe during my tenure working on WordPress.
Habari employs the Apache Software License, which is more permissive than WordPress' GPL. Want to develop a plugin or theme? Is the code tainted by the GPL? In WordPress, I don't really know for sure what parts can be redistributed, if any. In Habari, you can sell your themes and plugins for profit if you want to, or contribute them back to the community -- most themes and plugins so far have been.
The passion of the Habari community for producing good, documented code has (in my mind) been one of the driving forces behind WordPress' "recent" adoption of similar policies. The quality and friendly tone of assistance I get from people who know about Habari has been consistently orders of magnitude better than anything I've seen come out of WordPress, which is a characteristic that everyone working on Habari strives to maintain in the project. One of our guiding principles has been to be a project that is useful for web development education; We've seen a lot of people join our project and learn how to code well, both in the method they use and in the collaborative environment our development often lives in.
We've accepted a policy of keeping up with as current a deployment of technology and standards as our core users can stand. We recently adopted a PHP 5.3 minimum version, and I'm pushing hard to take that to 5.4. Habari simply does not run on PHP 4, and never will because it's no longer secure. We code for HTML(5). We're using CSS3. Our roadmap (admittedly difficult to find online) includes PSR-0 and namespace adoption to more easily integrate with vendor libraries. The use of current technology and techniques is really good for developers, and a refreshing change from projects that insist on supporting every old (insecure) server architecture out there.
And I'm currently making a living (yes, paying the mortgage) deploying Habari as a CMS for clients. It is viable. It is open source.
I know first hand how long it takes to build a working product with a small community. We are admittedly behind in our implementations of some features that WordPress was able to steam ahead with due to their larger community. There are also non-dev areas like marketing where we could use some work. We've been trying (albeit weakly) to lure those kind of contributors to the project.
We had a talented designer help us with our current admin design, and one of the things people comment on most about it is how it's not as cluttered with st as WP's. I like the design you've used in Ghost because it's similar to ours, yet modernizes, and I think our community would like it, too. We've been talking heatedly about a new admin design for our next release...
Habari may not be the thing for you, but I do encourage you to take a look, visit our IRC channel on freenode, and take from it what you can. If you still want to try to bend a WordPress fork, I'm at least interested in the story of your effort and struggle. And if you want to chat about why we started over (though I think it's obvious, maybe it's not to everyone else) instead of forking, or why a new project with a handful of addons (compared to a competitor) can still be a contender, I'm happy to chat. Here we are: http://habariproject.org/
Also, when you mention that you manage to pay the bills with development of habari powered sites, do you draw from a community need for habari developers or are these clients that you persuade to use habari ? I'm curious about the overall community and where it's going.
As others mentioned, the main habari/habari repo commit count is low because the main development doesn't happen there, but in a submodule'd repo, habari/system. The purpose of this is to allow you to easily fork the main repo to add your own plugins and themes to it, while the submodule continues to pull from the system repo. It's very beneficial from a maintenance standpoint.
I'm not sure how to explain the community. My involvement has been nothing but beneficial for me, and it has been a similar experience for the people I know the community has touched. Development has been reasonably continuous, as you can see here: http://www.ohloh.net/p/habari
I can't answer for @ringmaster, but for me it's client work, though it's a sideline to my main job at the moment.
Because WordPress is built on PHP it has a wider array of deployment options, including many low-cost options, while maintaing a relatively easy to use sheen.
I think it makes sense to evolve WordPress to merge the benefits of something like octopress with WP.
A small distributed team could probably build basic Ghost functionality in a couple of weeks based on PW.
There is a very popular piece of software that millions of people use today that was a fork of a large, sprawling suite of a mess of several programs that used an actual Godzilla as its mascot: Firefox.
Having said that, you may be right.
I agree that Wordpress should have saner defaults but it is not impossible to build a fast site with it.
WordPress is over 100 files of code 3mb size, loading on every page, BEFORE plugins.
It's impossible to build an active, non-cached site with it.
I have 100% dynamic php forums running side-by-side with wordpress and they are completely uncached - for WordPress that's impossible at the same load.
This is what I love about PHP devs. Imagine how much effort it was to write that. The author may not have have the chops to refactor that into something elegant, but he wanted it done and was perfectly willing to just do it the hard way and FUCKING SHIP IT, warts and all. Its easy to laugh at code after the fact, but you can't argue that a ton of people aren't finding the author's work valuable.
I find it curious we don't necessarily aspire to quality; and I think we should. I'm not happy just FUCKING SHIPPING IT.
How are end-users supposed to judge whether they just blew an enormous hole in their site, by selecting a plugin from the repo?
Time to reflect upon a classic of the genre:
There is an entire WP ecosystem of people having to judge whether they blew an enormous hole in their sites by selecting one of the zillions of plugins available, why is this one different?
But with web programming, if you're not good at it, but you have the perseverance to bash on code until it's "good enough that it works" (which is admirable, don't get me wrong), there's a very high chance it's got some major holes.
This is a real consideration to me, cause I'm working to teach kids technical computer skills, including programming. If I'd teach them PHP, I'd have to wall off the server, because many of their projects are bound to be full of holes, and we can't take the chance that one of those would affect our organisation's website. It's volunteer-based, so there might not be money to get a separate hosting package. Same if I were to give them all their own WP install, some of the projects are going to be forgotten, and I'm not going to be the one making sure they're all being kept up-to-date and secure for the rest of their lifetime.
And that's a cool article you linked. I already knew it, but for those who don't: it's worth reading, check it out!
Of course, I fall short of offering a solution, because there is none that doesn't imply writing bug-free code (impossible if it's not trivial); spending inordinate amounts of our spare time vetting this code; or otherwise stopping people from learning in the first place. The other one is to tell people not to use these plugins, or to be more careful, but they need to know what's currently'safe' and what isn't.
I just don't like the mindset that 'shipping' code is the be-all and end-all when as masters of our craft (hyperbolic?) we should at least aspire to more than 'good enough' or 'working', even if it's unattainable.
Unless I misunderstood what you mean, here :)
Yes, it is - there's a lot more non-techies than there are of the other kind, so it makes sense that you focus your efforts on the larger market.
As for the whole "language that beginners use to learn about programming", do you mean Python or Java? PHP is everywhere but the last I checked, Python and Java are the teaching and taught languages.
PHP itself is designed to get things done, not necessarily elegantly. For all it's problems, it is a workhorse and blaming the language for what the users have done is just wrong. Programming languages are like hammers and should not prevent one from doing something stupid or irresponsible. Doing the smart or right thing is the responsibility of the user.
I don't want to spark some sort of war on what language beats up your language. So I wont. Besides I don't think something 'being everywhere' makes it good. By that standard lots of things in this world are good.
PHP is exactly what you say it is with regards to being similar to a workhorse. It is a tool for programmers who like to work very hard to achieve something that a harvester could do a lot quicker and more efficiently.
Alex Munroe explains what I meant better than anyone I have seen. It is a great read. Also if you like PHP.
He does not bash PHP, he explains why he thinks it is the wrong tool for the job. Interestingly, he also uses the tool analogy. We are all so predictable :).
I go to any $5/month host, check "install wordpress", and it's done. When Clojure CMS/blog apps have even 1% of the installability (as in, ability to be installed) by non-developers, perhaps they'll have a fighting chance.
I say this as someone who develops Grails apps all day long.
That is a function of popularity, not language. If some blogging app had a userbase the size of wordpress's, it wouldn't matter if it were written in PHP or brainfuck, shared hosting providers will set it up. This is why appealing to techies makes sense. They will be the ones setting it up in the initial "its not popular yet" phase, and if they don't use it, it will never get off the ground. Once they start setting it up for their friends/family/etc, a few companies start offering it as an option for their hosting. Then a few more, and it snowballs as the app gets more and more popular. Trying to start from "use PHP so end users will use it" doesn't work, because installing a PHP app is just as hard for them as installing anything else.
Keeping JVM engines going, and keeping a lot of compiled apps in RAM, on the offchance that someone makes a request, means fewer apps/sites can coexist on the same hardware. My $5/month PHP plan (hypothetical - I don't have one) - only compiles/executes the PHP when the request is made. If no one requests my site for 3 days, it's all just sitting there, not using any resources.
Until there's another technology that follows a similar model (or something else which provides good economies of scale for hosting providers), PHP will continue to dominate large segments of certain problem spaces.
Anyone that only has PHP likely also doesn't have their PHP/MySQL updated to the point that anyone should trust them.
apt-get/yum install ruby rubygems
gem install rails
Rails is a great platform for building a custom web app, but it's a terrible platform for building an open-source blogging platform. It simply moves too quickly and breaks things too often to be useful for the demographic that uses WordPress.
When you're talking about web code with such an astronomical deployment to developer ratio, the advantages of PHP are magnified by several orders of magnitude. Even the perfect WordPress replacement written in Rails with elegant, featureful and performant Ruby code digitized by God's own hand is by definition a niche product that can never hope to compete meaningfully with WordPress.
That being said, I like the idea of a focussed blogging software. Probably because I sometimes contribute to one: Serendipity (http://www.s9y.org). And there are so many different blogengines ones out there, including Wordpress-forks, and of course some of them focus on being a blog-software instead of a cms. Heck, like so many even I wrote a blog-software for myself, based on Sinatra, cached and with spamfilter and using browserid, which is already probably quite useable (https://github.com/onli/dsnblog, though the description paints the image of something more, till now it is only an almost complete blog).
Definitionally a blog is a web log, or an online journal. There is no requirement that a blog have comments. Dustin Curtis' Svbtle is a recent blogging platform without comments, Jekyll and its brethren of blog-aware static-site generators are also without comments (unless the publisher adds them using an external service).
Nobody needs comments, and there are many good reasons not to have comments on a blog, ranging from the fact that it removes the ability for people to impulsively write a negative comment for no reason other than to be negative to reducing server and database load.
And btw, I "need" comments in my blog. I like them, they add value to the articles and if an article results in a good discussion, to write him was instantly more worth it. How can you for yourself come to the conclusion that no one needs them?
But, if you use a different set, say a group of people who use Jekyll or another static site generator, than normal turns into no comments.
Do we include all sites that consider themselves to be a blog inside of this set? Should there be a number of readers over time and a number of posts over time requirement? Should the content being delivered be of a certain category? You can't say that a "normal" blog has comments without defining those, you can't even define "normal" without defining the set.
Definitionally, a blog does not require a commenting system. I said it before, and you seem to be refuting that. [Wikipedia says that](http://en.wikipedia.org/wiki/Blog)
> Although not a requirement [...] blogs are interactive, allowing visitors to leave comments
Yes, I took out the "most good quality" part, because it shows a bias.
Princeton WordNet defines a blog as "a shared on-line journal where people can post diary entries about their personal experiences and hobbies", making no reference to comments at all. The Wiktionary also has no references to comments. [WordPress' Codex](http://codex.wordpress.org/Glossary#Blog) likewise makes no reference to comments inside of it's blog definition. Same with [Blogger](https://www.blogger.com/tour_start.g).
There are many people called bloggers who's sites don't have comments, Gruber's Daring Fireball, Marco Arment's blog for a few.
You just proved my point about nobody needing comments. You use the term need, but imply want. Your blog has no commenting requisite, you just enjoy having them. Functionally it would have very few differences if it didn't have comments.
And, I never said nobody wants comments. There are many instances where people may have a site built like a blog where comments are meant to be a discussion board of sorts where some BBS for forum software would suit them better. There's no commenting requirement for a blog to be a blog.
Some people may enjoy discussion inside of a comments section of a blog, and some people may operate their website in a manner dependent on a comments section, but I would argue that in such cases they're the ones who aren't operating a "normal blog", and are instead operating a discussion forum of sorts.
Likewise, trackbacks, pingbacks, and refbacks are not required for a blog either. None of those are official "web features" as specified by the W3C or the WHATWG the two organizations considered to be the "keepers of web standards". And it requires additional work by the publisher as it isn't something that can be implemented by generic server software (note the generic part, server software created specifically for serving a specific piece of software could very easily implement them).
Plus, comments and all of the *backs require some form of a database to run, even if it isn't your own database. Are you saying that a database is also a requisite for a site being considered a blog?
>Although not a requirement, most good quality blogs are interactive, allowing visitors to leave comments and even message each other via GUI widgets on the blogs, and it is this interactivity that distinguishes them from other static websites.
Even with a reference to an academic paper and exactly what i said prior.
> You can't say that a "normal" blog has comments without defining those, you can't even define "normal" without defining the set.
I define the set. Easily. Take every site on this internet someone thinks is a blog and merge them to a default. You will have comments and ping/trackbacks (and PHP, probably).
You choosed an interesting example: Jekyll. There is that interesting motion that you can observe technical development to follow circles. Those new static site generators are on such a backward circle. As I was told, in those early times before Wordpress, it was common to use systems like this to generate the sites that resembled modern blogs. Then came Wordpress & Co, PHP-based dynamic blog-engines. With comments and ping/trackbacks. I'm pretty sure, like the wikipedia-entry you cited, there are enough definitions acknowledging that.
They became the archetypical implementation of a Blog for many years, just like the iPad clinges to the archetypical implementation of a tablet laid down by Star Trek and functional requirements.
The movement now to generate blogs as static sites is probably a reaction to the awful caching and ressource-usage of Wordpress or a reaction to the popularity of git.
> You use the term need, but imply want. Your blog has no commenting requisite, ...
Really not true. If I didn't have comments, my blog would almost certainly not exist anymore. Which qualifies as a need over a want.
> There are many people called bloggers who's sites don't have comments, Gruber's Daring Fireball, Marco Arment's blog for a few.
There are people sitting on a tree claiming to ride a horse. Gruber for example is so popular that almost every entry of his gets dicussed here. HN is his comment-area. And no, that doesn't refute my own argument that a typical blog has a comment-area, because he has one (HN) and the unknown average Blogger has one on its site, or he gets no discussion at all, making him an atypical pseudo-blogger.
> Plus, comments and all of the ping/trackbacks require some form of a database to run, even if it isn't your own database. Are you saying that a database is also a requisite for a site being considered a blog?
Yep, they don't follow the typical blog-design. Though you can of course have trackbacks with plain-file-blogs without a dedicated database. I assume you included that with "some form of database".
And careful with the generic serverpart required: pingbacks use a generic and stadnardized xmlrpc-call, trackbacks are nothing but a POST with defined parameters. Sure, additional work to implement, but that is true for everything you really do with a server.
Again: Depending on when you started coming in contact with blogs, and I argue still today, it is highly likely that almost every blog you visit has comments (sometimes deactivated, nonetheless the engine has them), has some form of ping/trackback-machanism. It is so common for a blog to have those mechanisms that they became essential for the distinguishing between a static site with constant updates and websites we call blogs.
Basically, you've got a very exclusive view of what is a blog, and I think you've got the wrong definition of a blog. You say that your blog requires comments and wouldn't exist without them. To me, that sounds a lot more like a discussion forum than a blog.
Look at any top blog today, do they need comments. Would they disappear without them? Or, are the comments just a nice feature that people enjoy, but doesn't really change the nature of what they publish?
To me, comments are to blogs as radios are to cars. Sure, most cars have radios, but they don't need them to function. It makes the definition a whole lot more inclusive, and it should ring true to everyone. Cars of old did not have radios, blogs of old did not have comments, but as they've aged they both added new features that people enjoy (radios and comments), but to function properly, neither needs them.
If a "blog" is dependent on comments, I argue that it isn't a blog, because what is a blog but an online journal? Each of the five definitions I posted (four of which you failed to even look at or comment on) says that blogs are online diaries or journals based on experiences or hobbies. Only Wikipedia mentions comments, and only Wikipedia says "most good" blogs have them. While they may have them, there is no functional requirement that they have to be there, same with the car radio.
All cellphones have more functions than just calling a phone number and being portable. They can all store contacts in them, most have calculators, most have some personalizations you can make. Because they all have contacts, and most have calculators, do all cellphones have to have them to be considered a cellphone?
Your server part irks me. It irks me because it's wrong. You're defining the software that runs on top of the server as the server itself. Generic servers (apache, lighttpd, nginx, thin, etc) have no idea how to process a *back call. They can read POST requests, but they'll just forward that on to the software running on top of the server.
Sure, one could modify them to know how to process those requests in the specified manner, but than they wouldn't be the generic server, they'd be a specialized server.
I didn't react to the other definitions because they mean nothing. Your wordpress-Glossary has an entry for comments. The Blogger-definitions talk about how visitors may comment. Sorry, all of that points to my definition. Note that the latter interactivity-part of the wikipedia-definition is not necessarily related to "good blogs" but to all blogs.
If you want to have analogies: Disregarding comments in blogs but calling normal websites a blog is like calling a bike a car because it drives.
Server do one thing: They listen to requests on a port and forward them to a script, or serve the corresponding file. Reacting to such a request is normal business, and implementing trackbacks and pingbacks is a three-liner. They are not more of an artifical extraodinary thing than a php-script serving some output. Don't see what the classification as complex and weird here aims to.
PS: I hate it when HN eats comments!
It's a massive, huge step backwards. I can't even search the page. I wanted to try and read all of it, but I gave up. I understand that it's quick and dirty, but I don't really think you should throw something out for comment when you can't even copy/paste from the source.
If you insist on using images instead of actual text, at LEAST add alt-text of the content to the images! Then the page would be screen-reader accessible.
Why would anyone do that?
This isn't a dig on your images or design (I really liked the ideas and design for sure)—but out of curiosity, do you find image layout easier or more difficult than CSS? I ask because if I wanted to build something like this, I'd go straight for HTML/CSS not because it's proper but because it would be faster and easier.
I ended up closing the page because the font size is too small.
I think forking wordpress isn't as good of an idea as building a product which changes wordpress but still leaves everything in tact if someone wants to switch without requiring complex importing/exporting.
> Ghost would be developed openly, and it would encourage contribution. Until
> now, Open Source projects have often had an incredibly high barier [sic] to
> entry for contribution, which is so complicated and convoluted that only
> advanced-level developers have ever really had a hope of getting involved.
> Ghost would facilitate open and easy contribution from people with different
> skillsets to help grow and evolve the platform. Because designers and
> developers working together to solve problems always produces a better end
I disagree that there's an ‘incredibly’ high barrier to entry with many FLOSS projects, over and above the technical ability to read and understand what's happening in the code (which cannot be made up for through community efforts, or indeed forking). The language used in this passage presents these issues as manufactured or intended, and therefore as problems that can be fixed by simply making different decisions. But they're fundamentally issues of community, and of time/attention management on the part of the core developers, and they require extraordinary patience.
It's very easy to say "get designers and developers working together". But, as I've seen with DevOps (which is the principle of "developers and operations working together"), the phrase "working together" is often used without any understanding of its meaning.
I don't want to come across as a naysayer. But seriously, if you have the answers to the problems presented here, a lot of people would love to know.
Here are some related notes from Matt Mullenweg on a "radically simplified WordPress" http://ma.tt/2012/05/simpler/
I'd like to see something like Ghost as a step two of Matt's thoughts, rather than a fork or separate project.
Because we talk so much about our back compat efforts, it is certainly understandable that people might think that is where almost all of our development effort goes. But that isn't actually the case.
We heavily emphasize our philosophies because it makes adopting and updating WordPress easier, and we want users to know that. But in practice, the way we build software doesn't hamstring us. We've introduced new features and rewritten entire APIs without needlessly breaking plugins or sites. And we do sometimes drop stuff -- we are just careful about it. We do whatever is necessary to make WordPress evolve. In the end, we've simply become really good at following through.
All that said, I'm not sure I want a CMS from someone who uses images for text instead of actual text
Has any blogging platform implemented anything like that? I know there are Markdown editors with a split view, but I don't know of any that are web-based, nor any that are integrated into existing blogging platforms. And I've definitely never seen any "manage/edit old posts" system as clean and simple as the one in the concept.
Oh, and btw, a brilliant concept that's super easy to miss - being able to type "(image)" in the editor pane and seeing an image upload placeholder in the preview pane. It's a small thing, but one of those things that seems way more obvious than it actually is.
I'd love something like the "Oblivion" colours in gedit for instance, although I am aware that opinions differ on dark backgrounds :) It would give a nice visual distinction though, like the old "underwater" mode in WordPerfect.
It keeps position as you scroll and write.
I cannot see why people use WordPress over the likes of Concrete5 or a full CMS on any other platform outside of WordPress being accessible for entry-level developers. For this reason, a full rewrite of WordPress to be solely a basic CMS would probably have these novice developers flock to the system, allowing WordPress to scale back down to doing what it does best.
I run a very modestly profitable website that gets about 1k visitors per day. I'm not even an "entry-level developer", I'm not a developer at all, with only the most rudimentary ability to kludge together a little JS and php.
I chose Wordpress for the site, even though it's not a blog. In fact, creating a system where posts weren't displayed in chronological order actually took a few hours of blindly hacking at various WP functions.
The reasons I chose Wordpress over an existing CMS:
* I already know how to use WP
* There is a vast array of FLOSS themes and plugins to meet virtually any need available
* Wordpress is well supported by shared hosting and managed VPS providers (through cpanel etc.)
* It's relatively easy to get free high-level support through IRC because so many people know WP
Most of these reasons are inertia based. It would be a vast undertaking to create a CMS version of Wordpress that actually gained traction because, awkward as WP is, it has an enormous library of free existing solutions to take on virtually any problem. This quality, which the author of the article complains about, it the same reason WP would be so hard to kill. Even if your product is better for a given purpose, people aren't going to give up the advantages of WP I outlined above just for an incremental improvement in UX or speed.
Now I'll be the first to tell people there are certain things that you should build from scratch, but the examples of what people build with WordPress can be pretty breathtaking even to me:
The point I disagree with the most is that users won't need training to use it. I hear this all the time with absolutely nothing to back it up, other than "I haven't trained a user to use it".
Well, I have, and the users for this company struggled a lot with how things will work. I've trained users on numerous scripts, including Umbraco, Sitecore, Concrete5 and bespoke CMS's and every one of the others were far easier to both sell to a client and train. Umbraco and Concrete5 are far better for users than WordPress.
But that only includes *.wordpress.com subdomains, and our highest traffic blogs almost always invest the money to have their own domain. We have a tag to track those in Quantcast, and it's currently at 129.7M people in the US, which would place it between Facebook (143M) and MSN (98M). (Blogger might have a similar boost into the top 10, but I don't see any others in the top 50 that could have so many mapped domains.)
Of course we cache, with a publicly available WP plugin called Batcache.
I agree that using caching is normal, but the difference is the total reliance on caching. I wouldn't be impressed with google's scalability either if it were 99.9999% static pages being served up.
I think we agree that "scaling" small (sub-RAM-size) amounts of data to a largely logged-out and cached audience is easy, but I think you think of WordPress.com as much smaller and more static than it actually is. My apologies if I'm misunderstanding your point of view.
If you want to see standalone sites in the top 100 running WP besides wordpress.com, check out time.com, umbrellanews.com, celebuzz.com, and large sections of nytimes.com, cnn.com, and people.com. If you were to spider the top million Alexa domains, you'd find about 17% of them on WP:
I realize lots of people run wordpress. That doesn't support the claim that it easily scales to the traffic demands of a top 10 site.
Yeah, I said wp-admin theme. It's not generally considered a theme but that's what it is: the core-provided view of everything you can touch when you're an admin. Try thinking of the back end the same way you think of a front-end theme.
Unfortunately WordPress has not yet devoted a development cycle to making the entire admin area easily pluggable. Any seasoned WordPress developer could hack together a plugin that hijacks wp-admin URLs and displays its own interface. Several have. Wouldn't that satisfy your requirements?
Of course none of that addresses the issues around efficiency and performance. My hope is that WordPress will finally undergo a deep refactoring to remove its worst practices even if it means forcing updates to popular plugins and themes. There is no longer a reason to fear mass defection from the community for pulling that trigger. After the initial shock the changes would be embraced and everyone would enjoy better performance.
The WordPress Foundation and Automattic Inc are two entirely separate entities.
You are right in saying that they share a nearly identical relationship - however this small difference is extremely key to the difference in the overall philosophies of the platforms, in my opinion.
First of all, gorgeous mockups! I love where you're headed with the design and user experience. The cluttered WordPress dashboard and clunky post editor are my least favorite aspects of WordPress. I also really like how you're incorporating Markdown syntax.
There are a few points where I disagree.
Wouldn't merging 8+ configurable plugins into core be contradictory to avoiding bloat? Shouldn't you start with a clean slate? The plugin system is a great way to customize your environment to fit your individual needs. If you add defaults, you make it less personalized. You also add more bloat by adding functionality not everyone wants.
Don't forget there are many alternatives to Wordpress that have more features built-in, but Wordpress has succeeded because it's simple, flexible and easy.
I personally think this is a really good idea however, I wouldn't remove the comment system.
I'd like Wordpress to be more flexible than it already is. I see websites like The Verge and Polygon, how they have different styles for different kinds of posts. They create beautiful reviews, very magazine-esque, how it's supposed to be. Giving this amount of control the users would allow authors to be a lot more creative and create even more beautiful and better websites than ever before.
If I'm grabbing the thesis statement properly, it sounds like the idea is to make WP more flexible as a CMS. If so, that'd be very handy.
I'm not sure how it would work logistically, but it'd be cool if admins could flip a switch (maybe in wp-config) that makes a site either "blog" mode or "CMS" mode. Sort of like what you have to do to make a site networked (i.e. multiple blogs same domain).
I like John's ideas here, and this is something that should be talked about. If John has ties back to WP, though, I would present the ideas and make a case for letting him head up design or experience. The forking thing could get way out of hand (and confuse a lot of people).
Short of that, I'd say take the Ghost name and start building your own platform. It'd be cool to see another open competitor to WP. Especially if it shared a lot of the same principles.
Extensibility is the key factor for any modern web framework / language / system.
Also Wordpress is last-century with deployment options - there are no (built in) options for deployment and a smooth upgrade process including backups and optional rollbacks. The "automatic updates" claim by WP is btw. a good example for the limiting view of marketing jargon and how technical terms can be abused and this way educating millions of flies to eat tthe wrong food. Upgrade without rollback of course does not make sense and is no way "automatic".
Please, if you build a new system, study modern web frameworks before and please do NOT use PHP.
John makes some great points, which is why I'd like to follow him and see the progression of this. One of us (or a few of us) are going to need to just get down-n-dirty and start building it.
The internet is indeed filled with a lot of sentiment for rebuilding WordPress. Most of us who've worked with WP a long time (since b2) have considered it (myself included).
I'd love to roll out of bed one morning and press a red LAUNCH button that releases a fresh new fork of WordPress to the world that's compatible with most of it's theme/plugin ecosystem.
For comments, IntenseDebate. The backend is just four tables: options, posts, categories & feeds. (Yes, it aggregates feeds too.) Index.php does all the front-end work, another php file for the AJAX server, 4 more php files for the backend pages. Basically, interact with the database using AJAX datagrids. I can edit the blog without clicking Publish ;-)
- Seriously consider redesigning the logical layout of the software. Some sort of rough MVC-ish pattern would be a huge improvement over the 'loop' in Wordpress which is almost impossible to deal with.
- I personally dislike PHP, but I do see its benefits in deployment.
- Make it easy to make beautiful typographic layouts. There's a reason this 1-page wasn't done in Wordpress itself; it is almost impossible to make 'hand-crafted-web' looks in Wordpress without deep CSS and HTML diving. Great blog post layouts shouldn't be that hard. Not all content is the same.
I haven't touched WP in a few years; does it have the equivalent of the Rails Asset Pipeline yet?
*This plugin hasn't been updated in over 2 years. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.
As for the per-post CSS files it would be easy to do with a Posts custom field. You could take text input (CSS) and spit it out in the header using a basic query on the current post.
Probably convenient when you get hit by HN - and don't seem to be hosting images on S3.
Symfony, as a core framework for CMS's gives an amazing bedrock to build exactly what you're talking about.
... Just as an example of something else that exists that is working forward towards exactly what you're wanting to build, you should check out Apostrophe, http://apostrophenow.org/
And then theres the 90 other projects that exist on 90 other languages... But yeah, don't fork Wordpress, make something better.
Where is something like that?
Wordpress, atrocious code support.
Jekyll, too much configuration. I don't want to learn Jekyll I just want to post code.
Where is the middle ground for people like me? Sounds like this hypothetical "Ghost" is just what I'm looking for. Now if someone could build it...
It's worth the $39, but you can try it on a non-public site before you buy. It's incredibly simple, powered by plain text markdown files, easy to extend, and there is a "Panel" plugin that gives a very basic backend. Very little setup since it runs on PHP and without a true database. You can also connect it with Dropbox if you have the server permissions, to make editing files even easier.
I really like Ghost, but as a front-end to a github-pages/Jekyll powered blog. It'd be exactly what I'm after.
I'll look into prose.io
I'm guessing all the 477 points came from those looking at the pretty pictures but ignoring the text (two extra points could have been awarded by the author and his SO.)
Instead, what if there were a small set of plugins that were "Recommended by Ghost". They could be lightweight and specially geared for extending Ghost. But still totally optional. (sort of like Jetpack I guess)
Are you considering any changes regards the stack, since many installations can have a issues with speed now (not intended as a criticism). So eg something like Postgres, or MongoDB even for the DB Backend?
The vast majority of performance issues I've seen are not from something intrinsic to PHP or MySQL, but how people configure them. (MySQL is especially confounding.) There have been ports to other DBs but nothing that matches the performance of regular WP with a single layer of caching, like Batcache or Supercache.
For dynamic pageviews, ck2 is correct, our biggest barrier is just the amount of code we're parsing and executing on every pageload, which a different DB backend would not change. This problem is bigger on WP.com. I think we can fix this by becoming more conservative and clever about what we load for a given page and it's something I expect to be addressed bit by bit over the next few releases. (BTW ck2 if you want to work on that, please ping me!)
Again - I'm not advocating that you switch the default, but if switching database engines is not your bottleneck, then would you be willing to consider that option (maybe Kickstarter it)
However, WordPress still supports PHP 5.2, whereas most frameworks are now 5.3+. There's still a huge  userbase still on 5.2, so dropping it isn't really possible at this point in time.
I really like the split screen and markdown support. That would definitely get my interest. But please, ship 0.1 and let us know, don't tease us with vapourware.
As a site note: super +1 for the very last comment, made me laugh.
"i hate it/hate you/hate everything - Noted. Haters gonna hate."
I also agree that they are taking WP to do too much and if you look at the history, it all seems like trying to keep up with the popular trends everywhere.
HOWEVER, your idea / prototype / concept looks awesome and it is something I have been waiting for!
And you hope to captivate the hearts and minds of the open-source developer community? Haven't you seen what happened with earlier versions of GNOME 3 and Unity? We love options. We love settings. We don't want them gone, we just want them neatly organized and tucked away in an inconspicuous corner so that we can tweak them at lunchtime.
You yourself might have never used an obscure feature, such as posting by e-mail, but other people do use it every day, and will never switch unless they can keep using it. In fact, there exists an entire blogging platform (Posterous) that is based on the premise of posting by e-mail. Even my grandfather, who is utterly lost when it comes to regular blogging, can use Posterous because he knows how to send e-mail. Since Posterous is now on life support, I've been considering migrating him to one or another WordPress platform, precisely because WordPress supports posting by e-mail. If your fork removes this feature, it will fall right off my radar. I'm sure that somebody else will be able to tell a similar story regarding any WordPress feature that you think is unnecessary or unrelated to blogging. For example, "No Comments": excellent, now I need to send all my visitors to a third party who specializes in tracking them across the world wide web. Someone who had a blog about online privacy might consider it a case of hypocrisy.
It's easy to drop options and features that you don't see yourself using as part of "blogging". Anyone can do it, and each person who tries will get a product that fits his or her definition of "blogging". Such products, however, won't gain widespread use like WordPress has. A much more difficult but potentially rewarding task is to reorganize options and features so that casual users get sane defaults and power users can tweak to their heart's content. It takes a lot of careful thinking, planning, asking around, and UX experience to get this right, but once you do get it right, the difference can be stunning. As the saying goes, 80% of people only use 20% of features, but each person uses a different 20%.
One solution would be to organize these "extra" features into easily installable plugins, and to have those plugins ready before you sign off on your first official release. That would prevent the kind of negative publicity that surrounded the premature releases of some Linux interfaces. But another section of your write-up gives the impression that you don't want that many plugins, either.
PS: But you should definitely kill the ability to edit themes using the web interface. It's a security nightmare, leaving so many critical files writable by the web server. Also, the split view looks wonderful.
I think this is probably preferable to the overhead of tonnes of plugins??
Yes! Please do it. And put large text saying "This is blogging platform. Please DO NOT build your next e-commerce site using this software." :)
Do they? What do they mean? Can't you download the full, working source code of Wordpress anymore?
WP is free as in beer (you don't pay for it) but not as in speech (you can't do whatever you want with it because of the GPL).
But why Open Source? Such a proper rewrite is a big undertaking and I don't see how that could be pulled off without financial compensation. Why not offer it for let's say $19 per domain? I would easily pay for it and I am sure many others. This way you could at least pay salaries to developers working on it.