There was a great article written on WP Tavern yesterday entitled Why WordPress Doesn’t Need To Fear Ghost, Yet.
And before I go any further, I want to be absolutely clear that as much as I know that people who are involved in WorPress love a good dramatic story – especially one that involves mudslinging and controversial statements that generate all kinds of fun conversations in comments and on Twitter – this is not one of those stories.
Don’t read it that way, don’t spin it that way, and don’t try to twist any of the words that are in here as that’s that the purpose of what I’m trying to say.
Instead, this is my take on two of specific topics that were discussed in the article.
The WordPress Post Editor
First, I think Ghost is a really neat platform. I hope they succeed. My desire to see Ghost succeed is not mutually exclusive to seeing WordPress succeed. If you look at where each product is headed – especially if you’re listened to the past two years of State of the Words – then you know that WordPress is trying to branch out beyond just a CMS and, to use a coined phrase, an “operating system for the web.”
That is, it’s aiming to be a foundation for web applications and that’s exciting.
On Open Source
I could be way off in this, but I think that open source has always been about having freedom. The freedom from the restrictions that are imposed on us by proprietary licenses and software and companies that allows us to take the code that we’ve been given, modify it, and redistribute it (along with a few gotchas) as we see fit.
Ultimately, this is why so many variations of, say, Linux exist. We have the freedom to modify the source code as we see fit, and then we have the opportunity to distribute it as its own package to those who are interested.
Where is not for the license, then we wouldn’t be able to choose between Debian, Slackware, Ubuntu, Fedora, or any of the other distributions.
So to that end, Ghost’s maturity is something that I welcome. It’s going to help bring new ideas to the table that we can all debate and optionally incorporate into our own software, and it’s going to give people some really great choices depending on the type of software they want to build.
On Editor Styles
This is something that I’ve talked about in-depth before, but Jeff mentions a fantastic point in the article that I couldn’t overlook:
WordPress supports the ability for theme developers to link a custom stylesheet to the TinyMCE visual editor. It’s called editor-style.css and unfortunately, not many theme developers take advantage of this nifty feature. The stylesheet enables the visual editor to take on the look and feel of the frontend of the site, delivering a what you see is what you get experience. Stargazer by Justin Tadlock is an excellent example of how to use editor-style.css.
And Jeff is absolutely right. There is a feature in core that will allows us to easily close the gap between what the user will see on the screen based on what they see in the post editor and it makes for a really, really nice experience when working on WordPress themes.
Why is this not required? I dunno. I mean, under what conditions would that be forced? I could see it being a requirement for, say, Automattic or ThemeForest themes, but not freely given themes.
But, in my mind, if you’re shipping a commercial theme, then you should be making sure that quality is being pull through from end-to-end of your product as much as possible. Not adopting
editor-style.cssin commercial premium themes simply feels very lacking especially given that it’s so easy to implement.
Ironically enough, we’ll spend our time debating plenty of other things that are no where close to being in core:
- The post formats user interface
- A standardized or non-standard collection of custom post types
- Whether or not Links should be brought back into WordPress
- …and other such things
We’ll talk and even navel gaze about all of the things that should or shouldn’t be rather than focusing on the things that are already right in front of us that are deserving of some type of action.
But come on. I’m not saying they’re unimportant – they are – but right now, we have a complaint the the drafting experience in WordPress that can easily be fixed with taking a bit of the CSS from the front end, applying it to a custom style sheet, and including it in
It’s essentially a solved problem – it’s just not a solution that people adopt for one reason or another. I wish I knew why.
Instead, we complain about the experience and talk about how it doesn’t stack up against competitors. But isn’t that the wrong attitude to have? If something doesn’t match up to what someone else is doing, why sulk about it? We’re talking open source here. Do something to improve it!
Finally, I know that there are some other really cool projects people are working on that will allow us to work on front-end content in the near future. Personally, I don’t think it will be a “dashboard killer” (and I hate that terminology, anyway, but that’s another post for another time), but I think there are some people who could heavily benefit from it.
At any rate, let’s stop saying that WordPress’ drafting experience is more inferior to that other systems are doing when, in reality, our laziness (or lack of education) is partially to contribute to this experience.
From there, look to enhance the existing editor as much as possible. We’ve got the infrastructure in place to do it – we just need actually take advantage of said APIs.
With that said and to be clear one again, all the best of luck to both Ghost and WordPress and whatever other CMSs are out there that are up and coming. I can’t wait to see what you all bring to the table.
Leave a Reply
You must be logged in to post a comment.