Just because it's a rough concept, and I wanted to put it out as quickly as possible rather than delaying by procrastinating about coding a layout. I actually stole got the idea for making it a big page of images from the original .Mail concept page.
If there's interest - of course we could put something more professional (and machine readable) together!
I'd guessed this was to get something out the door quickly. It would be useful if you linked the FAQ image as a mailto to your e-mail address, or just through to your Twitter account. Having to type those out manually is a bit annoying.
Why not go the roots route? Build a parent theme/theme framework that does everything you want - while maintaining WordPress as its base. This allows you to take advantage of the changes in WordPress overtime - and allows users to switch to a full website if their blog takes off and they turn it into a company/personal website instead of blog. Best of both worlds.
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.
Yeah, my retina display gave you away. Looked pretty bad.
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.
Well my non-retina MacBook display gave it away too. I don't know if it's the original font or the rasterization, but the body font antialiasing looks poor, or at least uncanny compared to the native one.
It really put me off. It's not about making it machine-readable, it's about making it human readable for the sizeable number of people who are visually impaired, prefer or need to read in large print, are on high DPI devices, or even copy/paste.
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.
Just came to comment on the lack of accessibility for this page - thank you for pointing it out to the author.
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.
It's a terrible mistake. I can't read the site on my iPhone. I can't double tap to fit the text to the screen, it fits the image. If I zoom in, the text looks hazy since its not being re-rendered.
I kept trying to select the text (when I scroll that's how I keep my place on the page). You probably don't need to re-do this page, but consider a text option in the future.
These are some beautiful concepts by John. However, I think it's also worth noting that just about everyone that works with WordPress wants to see the interface itself be simplified, even if most of us want to retain its flexibility as a CMS.
Unrealistic for software that powers over 20% of all new websites. Also, a bit presumptuous of the core team. I think there is a lot of support for a simplified UI (see Matt's post above). Just because there is a barrier before you get patches submitted doesn't make the core team unwilling. Each decision needs fleshing out before getting put into a new version of WP. If it wasn't that way, the project would be a (total) mess.
Our commitment to backwards compatibility simply forces us to make smarter, more deliberate decisions.
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.
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.
This would absolutely be better solved by an entirely new application, written from the ground up.
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.
I've been committing code to the core WordPress codebase for 3 years, so while I'm not a PHP developer - I have some idea.
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'm relatively new to the WP scene, and already its totally clear that WordPress is tolerated because it has a vibrant ecosystem. Getting to keep that is way bigger factor in uptake over the next five years than anything a rewrite could deliver.
I think you could gain momentum surprisingly fast with a new project if it offered a quality alternative. (I say this as the author of a CMS in another content-type space which has done that fairly well)
First, let me say this: I love what you've done with the Ghost design. I think it's clean and useful. More on this below...
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/
I looked at the code, installed a test site and read the Wiki. Is this project on a down low at the moment with only 19 commits and low activity since late last year ?
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.
In my work, clients mostly need a site built to perform a specific function, and if Habari fits that task, I use it. There isn't an explicit demand for Habari developers, but there is a high demand for sites that Habari is suited to produce, which overlaps a bit with WordPress' capabilities.
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
http://octopress.org/ is essentially something written from the ground up that addresses many of the concerns in ghost, but that doesn't mean its the solution.
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.
Slow loads are an individual implementation problem as much as it is a Wordpress problem. Wordpress will happily give you more than enough rope to hang yourself with (e.g. Recent Comments), but even slightly savvy engineers should be able to avoid the pitfalls and AJAX expensive queries when needed.
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.
I used the sociable plugin (like/tweet/+1 buttons). Out of extremism I tested under elinks, saw some weird empty ul/li hanging around, inspected the plugin config and then went into the code. The latest release at the time was barely beta code, large spans of deadcode, copy/pasted pages-long loops that were 90% similar. Wordpress plugin pages quote millions of download for this plugin. Who needs quality ?
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.
Agreed, and my question was half sarcastic / half pragmatic. But I don't know where I stand on this issue. Answers lie somewhere in the middle, and to me, this case was quite out of balance.
I think there's a false logic present in arguing that "lots of people use it, so it's ok even if it's shit." Apply this same argument to one of several poorly coded plugins that have introduced basic security vulnerabilities and had widespread adoption. I think this is even worse when there's no commitment to improving it.
I find it curious we don't necessarily aspire to quality; and I think we should. I'm not happy just FUCKING SHIPPING IT.
Since there are always bugs, all code is an opportunity for security vulnerabilities. Users take their site security into their own hands whenever they have to trust others' code, as well as trusting their own coding skills (if applicable).
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!
Sure, can't refute that. However it's the same mentality that allows the same, basic vulnerabilities to persist throughout the years. The code basically works so sod it, who cares.
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.
i'm reminded of one of my favourite programming blog posts ever, "slumming with the basic programmers" [http://prog21.dadgum.com/21.html]. i reread it every so often, just so that i keep that perspective in mind.
PHP has the big benefit of being deployable anywhere. Without that fact it is unlikely that projects like Drupal or WordPress would've taken off as they have.
Newer languages aren't? Every linux distro that matters (including BSD, Gentoo, and others with a ports system), heck even Windows, has a full Rails stack that's about two commands away from being fully set up.
Yes thats the way to create great new products. Make it easy for non-techies to get them up and running and make sure they run on shared hosting and are created in a language that beginners use to learn about programming.
I can't tell if you're being sarcastic or not, so I'll just assume the worst.
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.
Let's switch Java for Javascript and Python for Coffeescript as far as similar syntaxes go. In any case, regardless of existing userbase, doing a forward looking project in backward looking technologies doesn't sound right to me. Go with Node, or Clojure if easily deployable today is a must.
"easily deployable" for Clojure or Node isn't even on the radar for 99% of people.
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.
Granted I don't know the state of Clojure, but I thought running on the JVM would make it easily deployable most anywhere. Of course then having a blog engine or cms built in Clojure that's easy to install is another problem, but this thread is exactly discussing such a solution.
>I go to any $5/month host, check "install wordpress", and it's done.
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.
"easily deployable" is part of the equation, but even assuming a clojure app was 'easily deployable', the architecture of JVM apps runs against the interests of shared hosting providers - anyone looking to get more functionality from less hardware.
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.
Back in the 1900's and even before that electric cars were invented by several people. In 1916 some inventor called 'Woods' created the frist hybrid car.
One reason for the decline of the electric car market was that the infrastructure eventually could not facilitate them. Read; hosting providers didn't support them.
Another reason was they were slightly more expensive, especially when Herny Ford came along. Read; shared hosting is cheap.
Another reason I have heard told is that electric cars had less parts that you could tinker with. It was more interesting to have a fuel car because you could use other car's parts and combine them, you could spend your weekend working on them. Electric cars just worked, or people didn't have the technical know-how to toy around with them. Read; non-techies don't know how to setup a Rails app.
Assuming 'Ghost' is the new best thing, making the underlying technologie easy for non-techies is NOT the way to make it happen. The whole goal seems to be to make the UI easy and useful.
You make the point that non-techies need to be able to set it up. You make the wrong assumption that they would need to touch code/servers to do this.
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.
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 have only run across one host that didn't have Ruby / Python available, and they were charging 4x the market rate for bad shared hosting - we easily saved $15 / month by ditching them.
Anyone that only has PHP likely also doesn't have their PHP/MySQL updated to the point that anyone should trust them.
That's not sufficient to serve a Rails site though.
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.
I see no reason why it can't be a fork. You may not want it to be a fork, but that's different from it needing to be a new project.
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.
And, if I recall correctly, Mozilla had a hard time keeping it at the same level of WebKit/Chrome, partly because the code was too old and needed a lot of changes.
One should be careful not to frame a new product as an engineering problem. Users don't care if it's a Wordpress fork or a rewrite. Users care about the product experience, what it delivers, benefits, etc.
The images and the proposal part was what I noted first as well. I left the site as soon as I noticed that all content was in images. I wonder what the reasoning behind such a poor choice of displaying content was? Prevent Search Engine crawling? Prevent easy copying of the text?
i don't think it's the right place to go into detail here, but there are so many things which make wordpress NOT awesome, that i cannot take anyone seriously who states that wordpress IS awesome. architecture, performance, wordpress's code itself, templating, continious security issues just to name a few.
Is there any alternative ? I guess there platform is very generic that is why there are 1000s of themes. I was able to build up http://syncfin.com in less than a month using wordpress and with an awesome theme. I believe it is a great platform but would like to know if there is any alternative ? I am not looking for RoR or DJango for just a simple blogging needs until there is some significant performance improvement prrof.
It's a super interesting concept because I think more sites are using wordpress as a CMS and the custom skinning for wordpress sites has a spanned a new industry in itself.
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."
God says...
weaken lost IT Cross suspense Bear If dry naked storing
force journey sold vail Paulus Glad roared fatness afterwards
Ostia divine recovering creation respected yield offerings
cleansed emerging familiar clasp ABOUT alloy delight suggestion
countenance descend remember VI Exodus deserve
7:24 Therefore whosoever heareth these sayings of mine, and doeth
them, I will liken him unto a wise man, which built his house upon a
rock: 7:25 And the rain descended, and the floods came, and the winds
blew, and beat upon that house; and it fell not: for it was founded
upon a rock.
7:26 And every one that heareth these sayings of mine, and doeth them
not, shall be likened unto a foolish man, which built his house upon
the sand: 7:27 And the rain descended, and the floods came, and the
winds blew, and beat upon that house; and it fell: and great was the
fall of it.
7:28 And it came to pass, when Jesus had ended these sayings, the
people were astonished at his doctrine: 7:29 For he taught them as one
having authority, and not as the scribes.
8:1 When he was come down from the mountain, great multitudes followed
him.
8:16 The Jews had light, and gladness, and joy, and honour.
8:17 And in every province, and in every city, whithersoever the
king's commandment and his decree came, the Jews had joy and gladness,
a feast and a good day. And many of the people of the land became
Jews; for the fear of the Jews fell upon them.
9:1 Now in the twelfth month, that is, the month Adar, on the
thirteenth day of the same, when the king's commandment and his decree
drew near to be put in execution, in the day that the enemies of the
Jews hoped to have power over them, (though it was turned to the
contrary, that the Jews had rule over them that hated them;) 9:2 The
Jews gathered themselves together in their cities throughout all the
provinces of the king Ahasuerus, to lay hand on such as sought their
hurt: and no man could withstand them; for the fear of them fell upon
all people.
----
An "Adder" is a logic circuit. "hazardous"?
----
God says...
effort fools orbs resolved ointments diversely ipod Giver
bed hairs discomfort Catastrophic_Success ingrated calls
congratulation missing joking disentangle thyself turned
evermore Michael behind crowned Animals hesitate words
materials fit strangely don't_worry reclaiming opinion
Orestes rocks downer resisteth curb hot subsists bodies
achieve enigma moderation excepted stars houseless ranged
fig unpraised righteous it wallow students indued ungodly
giant tale PARTICULAR morrow afterward procured events
darkness abstinence yea irons Thefts Turn story millennium
begged text fields staggered magnified drives people's
free goest rob editions certain dully suffrages veiled
Kazakhstan
----
Hot iron manipulation with robot fingers is exciting.
Yes? That page says that GPL'd software is free software. WordPress is GPL'd. TFA seems to imply there's something unfree about WP, I'm trying to find out what it means by that.
The point, if I understand correctly, is that WP is libre and nominally gratis, but it has become so complicated (and resource-heavy) since its conception as a blogging platform that it often costs real money to get it up and running satisfactorily. And there is a certain truth to that; it has, to an extent, become consultantware at industry scale, and often forces even "lightweight" personal sites onto more expensive hosting plans due to file loads, database hits and memory usage. There are "standard" plugins that can help a lot, but that's pretty much opaque to the typical non-technical end user, and it takes more than a passing knowledge of, say, HTML+CSS to style/theme a WP site. Free themes, which a user will often turn to after giving up on the idea of learning to write their own theme are often multiply base64-encoded (and just as often are ad-plagued and/or malware-harboring), and after being bitten once or twice, people resort to paying for themes or to have themes created for them. Not much, perhaps, but more than the "free" (gratis) software they thought they were buying into.
There's a little bit of contradiction in your desires: you say you want to keep "exactly the same theme and plug-in structure" but you also want to limit backwards compatibility. You also say you want to remove bloat and non-core features yet you want to bundle a load of questionable plug-ins. The nicer interface and UI would be welcomed, but I think if you start going too far you'll detract away from Wordpress's core appeal.
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.
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.
I'd almost like to see it go the other way. WordPress is a good blog, but a poor CMS choice for anything but the most basic of websites. I reckon the "66%" that use WordPress use it for personal sites or very small business sites (1-10 visitors a day) on shared hosting. There are huge sites using it, but they seem to be the exception that proves the rule.
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 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.
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.
Because it's easy to develop for, can scale to be one of the top ten sites on the internet, and your users won't need training to use it.
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:
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[0] 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.[1]
So, none of them? It doesn't include other domains and it shouldn't include other domains. Really, it is being exceedingly generous in that estimation already. Hosting thousands of totally independent, small sites is trivial, and does not require scaling wordpress in any significant way. Facebook is one site, all their data needs to be able to be accessed by all their software. Bob's blog and Joe's blog are totally independent, and have no need to be on the same software or hardware at all. Thus making scaling a non-issue.
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.
That's sort of like saying Facebook scaling is a "non-issue" because it's just a bunch of small, independent profile pages. Of course some elements can and should be sharded, but that doesn't mean that scaling is trivial, especially as you get into more advanced and social features and a rapidly increasing percentage of traffic is logged in and fully dynamic.
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:
Except that as I pointed out, facebook isn't independent pages. Wordpress.com is tons of tiny, entirely independent sites. That's like claiming godaddy is a top 10 website because they host tons of little PHP sites. Tons of little sites is not the same as one big site.
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.
That's incorrect. WordPress.com serves hundreds of thousands of websites from a single install. That means one set of PHP files and one database. Not unlike Facebook.
It is entirely correct. First of all, they do not serve hundreds of thousands in one install. Second, it doesn't matter. The point is they are individual sites, they are not tied to each other in any way. So lets say they host 100 sites on server X. Now one of those sites explodes in popularity and the server can't handle it all. They can simply move the site to its own server (or a server shared with a smaller number of other sites). It doesn't matter that the data is currently in the same database, as the data is in no way tied to the data of the other sites in that database. So it can be trivially exported and moved to a different server.
Many other CMS's are easy to develop for. The "scalability" issue is true but as I'm aware none of the top ten sites use WordPress.
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.
Many other CMS's are easy to develop for. The "scalability" issue is true but as I'm aware none of the top ten sites use WordPress.
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.
As someone who makes WordPress sites almost 8 hours a day, what would be the best start is a rewrite of the WordPress core on a popular, modern framework (my vote would be Symfony2). This would bring a breath of fresh air to coding for WordPress. Ideally much of the API would be similar too.
One of the things we're looking at moving forward is using things like this. We're taking a look at various frameworks at the moment as we look to move forward on a few issues (such as request variable abstraction, for which we're looking at Symfony's HttpFoundation/HttpKernel).
However, WordPress still supports PHP 5.2, whereas most frameworks are now 5.3+. There's still a huge [1] userbase still on 5.2, so dropping it isn't really possible at this point in time.
This proposal makes many good points. If I were rewriting Wordpress, here's what I'd think of:
- 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.
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.
Does that banner* need to be in place if no one has voted "It's broken" for the latest version of WP?
*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.
ImageOptim can be configured to reduce the size by a lot more than any of the online tools will. If you're on a Mac, there's no reason to use anything other than ImageOptim and ImageAlpha[1].
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.
Have to say, the most intriguing ideas I saw in the concept were the two "split view" concepts - one for managing blog posts, and one for writing posts.
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.
From an aesthetic point of view, I'd really want the Markdown code to be more visually distinct from the preview.
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.
> Less Options ... there are still too many options, too many settings, too many things which you have an unnecessary level of control over in the administrative user interface ... Things that many people have never even used. Ghost would get rid of all that.
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.
WordPress already has a "hidden" options page which lets you tweak a tonne of things. Therefore I think you're hitting the nail on the head with hiding the lesser used options away. It'd be nice if, should you change a setting, it would automatically become part of your main options screen & not the hidden one. It would also need to be heavily documented.
I think this is probably preferable to the overhead of tonnes of plugins??
The problem is that Wordpress is vehemently anti-MVC, and its plugin structure depends on this. You'd have to design an entirely different system to work on Rails.
You know, IIRC the first Rails demo actually used building a blog app as example. 8 years later and still no one has come up with a real Wordpress/Drupal/Mediawiki alternative - or at least none that's gained any significant userbase. I often wonder why..
This is a problem being answered with a half dozen other projects. (I'm, admittedly a drupal guy. But I even know whats wrong with Drupal...)
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.
Very interesting ideas here, for me particulary in the "free as in Mozilla, not as in Automattic" angle. Some might consider it blasphemy to say Auttomattic and WordPress have divergent goals so I'm glad people are having the discussion.
All that said, I'm not sure I want a CMS from someone who uses images for text instead of actual text
235 comments
[ 3.1 ms ] story [ 214 ms ] threadI 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.
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.
Well my non-retina MacBook display gave it away too. I don't know if it's the original font or the rasterization, but the body font antialiasing looks poor, or at least uncanny compared to the native one.
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?
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.
Buried in the text is it would be a fork of wordpress.
Net is filled with that sentiment, but it never takes off:
http://www.google.com/search?q=fork+wordpress&tbo=1&...
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.
Thanks !
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.
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
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.
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: http://cm.bell-labs.com/who/ken/trust.html
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 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.
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. http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
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 :).
Anyone that only has PHP likely also doesn't have their PHP/MySQL updated to the point that anyone should trust them.
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.
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.
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."
India-nigger in denial on God.
What do You think of Ghandi, God?
God says... weaken lost IT Cross suspense Bear If dry naked storing force journey sold vail Paulus Glad roared fatness afterwards Ostia divine recovering creation respected yield offerings cleansed emerging familiar clasp ABOUT alloy delight suggestion countenance descend remember VI Exodus deserve
http://www.youtube.com/verify_age?next_url=/watch%3Fv%3DpfoR...
http://www.youtube.com/watch?v=y1YcNT-v2ik
----
God knows what you're going to think like an old couple completing each other's sentences.
http://www.biblegateway.com/passage/?search=acts%202&ver...
God says...
7:24 Therefore whosoever heareth these sayings of mine, and doeth them, I will liken him unto a wise man, which built his house upon a rock: 7:25 And the rain descended, and the floods came, and the winds blew, and beat upon that house; and it fell not: for it was founded upon a rock.
7:26 And every one that heareth these sayings of mine, and doeth them not, shall be likened unto a foolish man, which built his house upon the sand: 7:27 And the rain descended, and the floods came, and the winds blew, and beat upon that house; and it fell: and great was the fall of it.
7:28 And it came to pass, when Jesus had ended these sayings, the people were astonished at his doctrine: 7:29 For he taught them as one having authority, and not as the scribes.
8:1 When he was come down from the mountain, great multitudes followed him.
----
These are like ink blots or cloud animal shapes.
God says...
hast bends containing inflicted difficult Though
----
Saw robot video.
https://www.youtube.com/watch?feature=player_embedded&v=...!
God says...
was glad.
8:16 The Jews had light, and gladness, and joy, and honour.
8:17 And in every province, and in every city, whithersoever the king's commandment and his decree came, the Jews had joy and gladness, a feast and a good day. And many of the people of the land became Jews; for the fear of the Jews fell upon them.
9:1 Now in the twelfth month, that is, the month Adar, on the thirteenth day of the same, when the king's commandment and his decree drew near to be put in execution, in the day that the enemies of the Jews hoped to have power over them, (though it was turned to the contrary, that the Jews had rule over them that hated them;) 9:2 The Jews gathered themselves together in their cities throughout all the provinces of the king Ahasuerus, to lay hand on such as sought their hurt: and no man could withstand them; for the fear of them fell upon all people.
----
An "Adder" is a logic circuit. "hazardous"?
----
God says...
effort fools orbs resolved ointments diversely ipod Giver bed hairs discomfort Catastrophic_Success ingrated calls congratulation missing joking disentangle thyself turned evermore Michael behind crowned Animals hesitate words materials fit strangely don't_worry reclaiming opinion Orestes rocks downer resisteth curb hot subsists bodies achieve enigma moderation excepted stars houseless ranged fig unpraised righteous it wallow students indued ungodly giant tale PARTICULAR morrow afterward procured events darkness abstinence yea irons Thefts Turn story millennium begged text fields staggered magnified drives people's free goest rob editions certain dully suffrages veiled Kazakhstan
----
Hot iron manipulation with robot fingers is exciting.
You like this, God?
http://www.youtube.com/watch?v=jBfygUiS5...
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).
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.
http://twitter.com/johnonolan
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.
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:
http://wordpress.org/showcase/
https://www.quantcast.com/top-sites/US/1
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[0] 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.[1]
[0] http://cl.ly/image/081G1r2f0Z18 [1] http://wordpress.org/extend/plugins/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:
http://w3techs.com/technologies/history_overview/content_man...
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.
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.
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.
However, WordPress still supports PHP 5.2, whereas most frameworks are now 5.3+. There's still a huge [1] userbase still on 5.2, so dropping it isn't really possible at this point in time.
[1]: http://wordpress.org/about/stats/
- 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?
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.
http://wordpress.org/extend/plugins/art-direction/
*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.
http://wordpress.org/extend/plugins/per-post-scripts-and-sty...
Probably convenient when you get hit by HN - and don't seem to be hosting images on S3.
http://imageoptim.com/
[1] http://www.smushit.com/ysmush.it/
[1] http://pngmini.com
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.
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.
http://www.youtube.com/watch?v=wn97WbalJwM
http://windows.microsoft.com/en-US/windows7/products/feature...
https://addons.mozilla.org/en-US/firefox/addon/fox-splitter/
https://github.com/natew/obtvse/tree/refresh
http://cl.ly/image/0m3d3k230b47
It keeps position as you scroll and write.
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.
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??
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.
All that said, I'm not sure I want a CMS from someone who uses images for text instead of actual text
http://john.onolan.org/wp-content/uploads/2012/10/81.png