Building a better WordPress
medium.com
medium.com
Of course I haven't used any of these cheap hosting solutions or setup a Wordpress site in a couple years so I might be out of date on the state of things.
Then again I went out of my way to find a good host after dealing with so many terrible ones.
The fact that Wordpress is used by developers setting up a CMS and being paid thousands of dollars for it is what could be improved upon.
That's the generous interpretation. A more jaded reader might have started reading the article thinking 'mention of Angular... 3... 2... 1... ah there it is! suggesting node... 3... 2... 1... ah there it is! Well at least he managed to contain himself until the next to last paragraph'.
It's technology-centered myopic navel-gazing. Yeah nobody uses Wordpress because PHP in templates is not 'clean'... Oh wait, half the world does use Wordpress because everybody and their dog has a server with PHP and because it's dead simple to hack up something working by cramming some PHP into a template you bought for 5$. For 95% of all websites, who cares about maintenance? Just do a new one in 3 years with whatever is hot then.
This article (and many like it, not singling this one out) reads like people who call themselves 'real' woodworkers, lamenting that people won't fork over $2500 for a hand-crafted oak dining table and instead get a $100 Ikea one. The popularity of 'Ikea hacks' amongst the crowd that tends to author articles like this is ironic in that sense...
Fixing the mess that is wordpress is a very nobel goal.
The ones you can buy however are a nightmare for sure, so are most of the copy-pasted-glued-together ones.
And where wordpress really shines is in the ecosystem. Subscription list popups, SEO, social media integration etc are just a few things that clients commonly want that take far less time to integrate into wordpress than building from scratch (because it's fairly common that authors of less popular developer-centric CMS'es didn't think to implement those things).
In my experience, WordPress is not built for developers or designers. It's built to be simple and extensible from the end-user's point of view. Most end-users don't expect absolute perfection and accept that it will do 90% of what they want. As long as it keeps doing that, no one will care what a "mess" the insides of it are.
...except the poor bastard who will have to build the website and maintain it.
I think what you'll find has changed in the last few years is that "cheap" hosting isn't limited to shared cPanel type accounts any more.
The basic Linode is $10 per month, and presents a VPS with vastly more capabilities than your basic Bluehost plan.
It's hard to argue such things exist due solely to pricing these days. Rather, they exist largely due to the contingency of developers requiring features such as "1-Click Wordpress install".
You honestly wouldn't believe how often a helpdesk gets a call from someone saying "I'm a web developer and I've sold a website I built to a company on your host. Apparently I need to install something called Filezilla, can you help me with that?"
And that's why Wordpress will never run on Node.
Which works great if you have an in-house sysadmin to keep those servers in working order. Otherwise, going with managed hosting is much better for a client.
Can someone explain to me why using a front-end javascript framework for entirely static content would be a sound idea?
I think a good API would be great to have for a CMS (and one could or maybe even should run the normal frontend of it), but not for this reason.
EDIT: And if you build non-standard-CMS apps on top of or using data from the CMS, then you could use React or whatever and the API.
Hypothetically simple scenario could be running WP as user management, and i18n translations, for a single page application.
For the most part, I can imagine a node.js application layer that simply interfaces with wordpress api in the back. WP can be upgraded as and when needed, and the frontend application isn't tied down by clumsy php templating. A separate api with oauth and token authorization could be layered on top for mobile applications.
This is looking towards making wp more open to developers in other ecosystems (an area which is considerably lacking other places like .Net. Umbraco? Sharepoint? ew)
In general I expect that it's not the best solution. But look at projects like turbolinks. JS replacement is quicker than a full page reload.
That's interesting, as most people claim PHP and the army of developers that come with it, is a major factor in WP's domination of the CMS market. If WP had initially been developed in Python, perl or anything not named PHP would it be the dominating force it is today? (Honest question, I don't presume to have the answer)
I'm a PHP developer, I hate working with WP but this whole article had me scratching my head asking "what? why?".
This isn't 'fixing' wordpress, the author is essentially building a spec for a new/different CMS that isn't dependant on WP. There's lots of those not named Wordpress.
Most of the solutions around at the time were perl, including Movable Type, which was the WordPress of the time. The only reason anyone went with WordPress was because the MT developers jacked the price up, and WordPress was free at the right place/time.
Of course, that difference had its disadvantages - you had to make sure WP traffic didn't melt the server(s), optimize for the traffic, then finally give up on caching strategies after traffic growth overwhelms conditions, and upgrade to a CDN to basically imitate a static site you were avoiding.
In some ways, we're making a full circle in blogging technology (and web in general), but here's a major WP disadvantage at this moment in time: it might take 32MB of ram to generate a 3kB page.
Well, that's going to be the same no matter which technology you choose. The dependency on ReactJS is also going to turn many developers away from your proposed changes.
Why turn away? Here's a possible reason: Instead of generating perfectly valid and semantic markup that can be understood by all clients from Lynx to Chrome as well as search engines, you want to turn every blog into a single-page "webapp" where the markup only contains some empty placeholders and all content is rendered separately by a hefty JavaScript framework.
No, thank you.
One thing I'm absolutely flabbergasted about is that we as a community have spent the last 10 years trying to get everyone to serve valid semantic markup, only to throw it all away. This tastes just as vile as using tables everywhere.
There's a time and place where JavaScript MVC frameworks make sense. A blog ain't one of them. Even Medium is barely tolerable nowadays -- I am often forced to use the Reader View in Firefox to get rid of all the junk that Medium throws into every blog post.
Please, please keep that junk to yourself. Don't pollute my precious WordPress with it.
Using a DOM manipulation engine does not disqualify the developer from producing perfectly semantic markup.
Good luck loading that page with whatever the most popular browser is in 2040, or on archive.org if the original website has long disappeared.
The reality is that the modern web depends on JS, and the argument of deprecation won't change that anytime soon. We're moving forward, not backward.
On a technical note, there is quite some effort in rendering React/Angular apps on the server in case it's serving an outdated browser.
Edit: just realized that of course storing JS files isn't the solution to archive.org's challenge, it's storing server responses.
It won't be difficult to extract useful information from a static HTML document 25 years from now, even if it doesn't render correctly. Actually, we do that already with static HTML documents written 20-25 years ago. But there's no guarantee that a script with lots of moving parts written today will run without errors on a future browser, especially if it stopped being maintained sometime in the middle.
Why do we need so many moving parts to display a goddamn blog post? It's a mostly static document, after all. There's no reason it shouldn't be readable with NoScript on, or even in a terminal-based browser like lynx, with a very small number of HTTP requests.
The reality is that only some parts of the modern web depends on JS. Hiring five people to change a lightbulb is not "moving forward", it's just wasteful.
the dependency on <chose your programming language> can turn many developers away from using it.
> Almost all interactive elements are built using jQuery, which, while a great library in many respects, is weak in comparison to many of the emerging front end frameworks we have today — ReactJS, AngularJS and others.
Weak? what does that even mean? Also the author is horribly confused because he compares a library with two frameworks.
Calling jQuery weak in this context is like calling C weak in comparison to Java, however, I would still prefer to write my operating system in C thank you very much.
> I’ve already mentioned using localStorage as a mechanism for providing caching in front end apps, ensuring content is loaded quickly, avoiding ugly loading screens and flashes of blank content, but this only goes so far. As ReactJS (and soon AngularJS 2.0) can be run on the server as well as in the browser, we can pre-render the initial page load for the user on the server, and then hand-off all future content and navigation requests to the browser.
You solve a problem that you introduced in the first place. I'm surprised I don't see MongoDb mentioned anywhere in this article.
Wordpress is a pretty terrible platform to work on as a developer, however introducing trendy technologies will not make it any better. Ironically JavaScript is more similar to PHP than a lot of people care to admit:
* JavaScript, just like PHP was not designed for what people are using it for today
* JavaScript, just like PHP is riddled with bad legacy
* JavaScript, just like PHP is trying to evolve to escape from that legacy and become more like other languages.
The fact of life right now, is that PHP and MySQL are well understood technologies, countless web applications in production are using them, the same cannot be said for NodeJS and this has real world consequences, because running a NodeJS app on your laptop is totally different from running it in production.
On a standard Ubuntu machine, having a production viable PHP installation is 1 apt-get install away and I get: web server set up, error handling, logging and a standard way to customise the system wide configuration. With NodeJS, I have to worry about restarting it if it fails, logging the error, handling them, configuring the web server etc.
I find that people who criticize PHP, have no clue on what makes it so popular.
(Feel free to ask questions if you've got any :) )
We've been short on time in the past, which is why our docs aren't up to scratch. Fingers crossed we'll get that sorted very soon!
Current version pros:
- SQLite makes deployment and backups a breeze. I can also copy the SQLite file to create two versions of the site: "draft" and "live". Hitting "publish" syncs them.
- From the developer's perspective, it's just a regular Python app, except you can insert user-editable elements into any template.
- From the user's perspective, you can edit stuff right in the page.
Works fairly well. Two big hurdles remain:
- I rely on medium-editor[1] for in-page WYSIWYG editing. It's the best open source solution I've seen, but it's still horrible. Generates crap HTML[2].
- For major layout changes, the developer has to create a new template with placeholders for content creators to fill in. Ideally, developers would create building blocks that creators could then drag and drop in to place.
I've found it has better HTML output than medium-editor (though still not perfect) and has a more flexible design, though it requires a bit more developer involvement to get up and running.
TinyMCE's markup output is probably as good as it gets.
I expected an humorous article about Medium being the better WordPress. I think Medium might just be the better WordPress (for most, not all).
Take note, folks... theming and designers are crucial to your platform if you plan it to be used by a significant number of websites.
Themes definitely help with the target audience WP is going for, particularly now that it's trying to be a CMS and not just a blogging platform. However, it seems likely that being PHP-based, and therefore easy to install on almost any cheap hosting even from many years ago, helps; plenty of hosting services would even provide ready-made WP installations. Being the de facto standard option also helps a lot in terms of building your community and ecosystem, and WP was the dominant blogging platform for almost an eternity in Internet time.
Second, WP used jQuery itself in the management interface, which is actually what he was on about.
Downside with Drupal is that it ships with a stone-age version of jQuery, which sucks if you want to use any modern jQ plugin. Also, Drupal mixes config and data in the database, making proper separation of live/stage/dev a PITA.
IMHO tying itself to a single front-end technology would be the totally wrong thing to do.
Luckily, we've already made it. :)
lol
I have had very few calls / emails about complaints with the WP admin area, though I do/did generally drop them into a less privileged account with less flashy buttons to break things with, as well as set their dashboard up with some notes about how to accomplish tasks specific to their usage (how to post / edit / delete, how to clear the cache manually if they had to, etc).
I might be in the minority there, and I feel like that contributed a bit to the no-complaints thing... but even a vanilla WP admin area is very usable.
If what they're using day-in and day-out is in their way or not "simple to use", its hindering (to various degrees) their progress in doing what they want to do.
If I make a website for a musician, they want to probably publish musician / band related stuff and go on making music; if they're having to figure things out or call me every time they log in... I've done a very, very bad job at giving them what they need.
I can't say I've ever had a client comment to me that the system was difficult / non-obvious, especially when using WP (even the first few I pushed that used almost vanilla WP admin).
After building their site for ongoing management ...correctly, and tutoring them many were/are thrilled with WP and the content editing process.
The key is implementation and tutoring. Asking a client to manage raw markup, or handing the keys over with no tutoring are recipes for dissatisfaction.