Building a better WordPress(medium.com)
medium.com
Building a better WordPress
https://medium.com/@chrishutchinson/building-a-better-wordpress-4b2a771b4d0b
83 comments
Yeah, I was with him up until that point. That's a huge negative, and something that could be avoided very simply by using a framework other than React.
Re:PHP. That's, this is why Wordpress won on the web.
The host I have a few business wesbites on supports Node, Ruby, PHP, Python, Redis, Memcached, MySQL, and MongoDB on all of their hosting packages except the very cheapest one. I think I'm paying like $100/year, although these are small/low traffic sites so I dont need or get a lot of disk or bandwidth.
Then again I went out of my way to find a good host after dealing with so many terrible ones.
Then again I went out of my way to find a good host after dealing with so many terrible ones.
That's all true, and there's no reason why Wordpress couldn't continue to service the users who want a simple solution for setting up a website ... But that doesn't preclude creating a new solution for professionals setting up websites for other people that's based around modern techniques and languages.
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.
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.
"is that the author arrives on the two node-based solutions as the preferred path forward."
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...
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...
Have you ever tried to modify a wordpress theme? It's a nightmare. And we are proffessional developers. Imagine the pain this must be for mere webdsigners.
Fixing the mess that is wordpress is a very nobel goal.
Fixing the mess that is wordpress is a very nobel goal.
Write your own and keep it simple. It's not that hard.
The ones you can buy however are a nightmare for sure, so are most of the copy-pasted-glued-together ones.
The ones you can buy however are a nightmare for sure, so are most of the copy-pasted-glued-together ones.
Admittedly, it was a few years since I looked at the inside of wp, but it was horrible, with php api calls inside the template code, bad/missing/misleading documentation and non-existing database structure.
Come on, nightmare? It's kinda annoying, fussy and handle-turning, but taking a page that has been designed and fitting that into the template tags is really not all that bad for a days work.
I had to clone a website, then make a few tiny adjustments (like change the site name), and it took me several days.
I have, and I somewhat disagree. I agree that it can feel dirty to your programmer sensibilities when you start from the base template one and go "building from the ground up", but if you set expectations accurately with the client (and yourself) wrt the amount of flexibility a theme gives and what type of work you're going to be doing, you can get some pretty high quality themes (where "quality" here refers to the template's ability to fulfill the goal of offering a feature-rich GUI to non-techies). Some themes are so elaborate that you can change virtually every aspect of the template down to the most granular levels directly from the admin interface.
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).
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).
> And we are proffessional developers
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.
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.
> 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.
...except the poor bastard who will have to build the website and maintain it.
>Of course I haven't used any of these cheap hosting solutions or setup a Wordpress site in a couple years
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.
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.
> The basic Linode is $10 per month, and presents a VPS with vastly more capabilities than your basic Bluehost plan.
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.
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.
I don't disagree, but that plays into my point that you didn't choose based on what it was cheap.
Instead of making the whole REST API, perhaps we could consider using something like Meteor (or at least offer ways to skip the API altogether in favor of some other mechanism.)
Couldn't you build something like that on top of the REST API?
You should check out how Meteor (https://www.meteor.com/) works. It makes REST pretty much unnecessary.
But then you don't have a nice REST API to integrate with different things anymore (authoring tools. exporting tools. frontends for devices that don't like meteor. ...)
IMHO tying itself to a single front-end technology would be the totally wrong thing to do.
IMHO tying itself to a single front-end technology would be the totally wrong thing to do.
Meteor is not tied to any single front end technology, nor is it a front end technology. It has an optional templating system, but lots of people are using react now instead. I love meteor, but using meteor with wordpress sounds like a nightmare. I think it was probably suggested more as an alternative.
Ok, then I got that wrong. Meteor apps always seemed incredibly coupled and integrated to me, so I assumed it was one "package".
The things people want to us WP for are totally unrelated to the things Meteor is good at.
> Instead of making the whole REST API
Luckily, we've already made it. :)
Luckily, we've already made it. :)
I think you meant implementing Meteor's DDP protocol and not the whole Meteor?
https://www.meteor.com/ddp
https://www.meteor.com/ddp
> The WordPress admin interface is it one its best features, and provides a clean and elegant way of viewing and managing data
lol
lol
While not saying I whole heartedly agree with that statement, the admin panel is a major selling point.
And yet I've never had a client say they like it, or find it easy to use. Neither did they find Drupal any better, but they have found other options easier to use.
I wouldn't necessarily take client praise as a testament to being good or bad. When I started out I was pushing WP sites; I usually gauged things by complaints (very similar vibe to when I was working on cars).
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.
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.
I would be interested in finding what those other options are, in all my career I never had any client tell me a CMS it's simple to use.
Why is that? Getting the CMS out of their way is one of the primary reasons they outsourced development (or implementation, or whatever) to someone else (agency, freelancer, whoever).
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).
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).
I feel like people don't take advantage of how easy it is to create a simple user interface for a Drupal site. Create a new page for the user on login that lists the most frequently used functions with another link for advanced functions. That said I die a little every time I see the markup D7 produces.
I have over 50 clients (small business owners) who run WordPress. Many came to us complaining about their old CMS, sometimes even WordPress.
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.
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.
Would you reach out to me (contact info in profile) if you'd be willing to talk about WP management on those 50 clients? I'm working on a hosting solution focused on the problems agencies may have managing updates and cleaning up broken or hacked client installs.
Hey there, didn't see this until ... now - don't see any contact details in your profile.
No worries. If you see this, you should now be able to find my email in my profile. Would love to chat.
I've been building and iterating little toy CMSes for years, each one a little better.
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.
[1] https://github.com/yabwe/medium-editor
[2] https://twitter.com/etodd_/status/644898235836989440
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.
[1] https://github.com/yabwe/medium-editor
[2] https://twitter.com/etodd_/status/644898235836989440
Have you tried Scribe editor? https://github.com/guardian/scribe
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.
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.
I took this same route after trying to make a site with (an older version of) wordpress. My current version has everything I need for most of the websites I make, dynamic content, 'blog' style posts, comments integrated, analytics, and most importantly the actual page code is really clean. +1 for putting in the effort
Have you tried the "inline" option in TinyMCE 4? Basically you just give each editable element on the page its own, independently configured TinyMCE instance.
TinyMCE's markup output is probably as good as it gets.
http://www.tinymce.com/tryit/inline.php
TinyMCE's markup output is probably as good as it gets.
http://www.tinymce.com/tryit/inline.php
I haven't seem this before.... might have to give this a try.
Ironic that this is posted on Medium.com.
I expected an humorous article about Medium being the better WordPress. I think Medium might just be the better WordPress (for most, not all).
I expected an humorous article about Medium being the better WordPress. I think Medium might just be the better WordPress (for most, not all).
Medium is a a blogging platform. Wordpress is a CMS. Medium is not a better WP, it is a better group blogging product, one of the many ways you can use WP.
Wordpress started out as a blogging platform. Who knows what Medium will be in ten years.
I have never build a Wordpress theme using jquery. What is he on about?
First, you might very well be an outlier. In which case, what you did or did not doesn't matter at all with regards to WP. FWIW, tons of WP plugins and themes (professional and popular free ones) use jQuery.
Second, WP used jQuery itself in the management interface, which is actually what he was on about.
Second, WP used jQuery itself in the management interface, which is actually what he was on about.
> Yet again, the RESTful API comes to our rescue. Thanks to its simple JSON output, we’re able to use JavaScript to its full potential, using ReactJS or AngularJS to craft beautiful and fast front end experiences, taking advantage of many of the new HTML5 browser APIs that have become available over the past few years, including localStorage and more recently, service workers. Even better, we don’t have to use jQuery.
Can someone explain to me why using a front-end javascript framework for entirely static content would be a sound idea?
Can someone explain to me why using a front-end javascript framework for entirely static content would be a sound idea?
Because that's what the cool kids use. /s
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.
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.
It's just an example. I would never say anything is never a good idea... there just needs to be specific conditions that would require it.
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)
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)
I wish I could just use the same APIs to dump out static pages to host on something like GitHub pages. External JS could take care of the stats (for the few users who don't block it)
I used to use a mobile RSS reader that was just a phonegap app. It was useful for downloading reading for my morning subway ride. Cell service on the TTC has been long project filled with fail.
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.
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.
> the dependency on PHP can turn many developers away from using it
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.
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.
>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.
Using a DOM manipulation engine does not disqualify the developer from producing perfectly semantic markup.
Using a DOM manipulation engine does not disqualify the developer from producing perfectly semantic markup.
Sure, but that beautiful markup only exists inside the Developer Tools of modern browsers, and only thanks to several megabytes of scripts that waste my time, data, and battery.
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.
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.
You believe that HTML won't be deprecated by 2040, but JS will? You also believe archive.org won't make an effort to store JS files within that timeframe?
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.
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.
JS is a lot more fragile than HTML.
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.
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.
web is not moving forward. It moves sideways at best, and runs in circles at worst.
> the dependency on PHP can turn many developers away from using it
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.
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.
>If WP had initially been developed in Python, perl or anything not named PHP would it be the dominating force it is today?
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.
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.
MT was fairly clumsy in some ways by comparison to WP, though my use of the word is very questionable. Updating templates was always a pain because we'd want to update a sidebar widget, and it would take hours to have that change reflected (regenerate all pages statically) because we had a legion of prolific writers and they churned out tons of content throughout the years. By comparison, WP was dynamic - change instantly reflected.
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.
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.
I find one of the quickest and easiest ways to greatly improve working with WordPress (in my opinion) is to just install the timber plugin. This allows you to write template files in twig and does a good job of cleaning up the mess of HTML weaved into 'the loop'.
Let's face it. Wordpress works because of the themes. Hire a quasi developer to set it up for you with plugins, and they will find a nice theme to install. And the result - the end client WHO PAYS will get a visually nice site! Especially responsive themes.
Take note, folks... theming and designers are crucial to your platform if you plan it to be used by a significant number of websites.
Take note, folks... theming and designers are crucial to your platform if you plan it to be used by a significant number of websites.
Couldn't agree more. Somebody above mentioned Drupal, which is also a widely-used PHP-based CMS, but (IMO) far superior to WP (Comparing the two communities is night and day — when I published my first Drupal module, I got hours of community support and released something that was high quality and reviewed by a member of the security team. With my first WP plugin, the most code review I got was somebody who ran it through a linter). Alas, theming Drupal is awful (especially if you're a designer who's invested in learning WP theming); my personal opinion about why it's never gotten anywhere near WP's market share is largely (largely!) due to the lack of themes.
There must be more to it than just themes. Sites like Svbtle and Medium rose to prominence pretty quickly and attracted significant numbers of contributors, despite very much trying to build their own brands as a blogging platform with a recognisable style in each case.
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.
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.
Bemoaning WordPress for being built in PHP, then proposing something built on top of Node.js and Angular. Now I've heard it all.
While I'd LOVE WordPress to be run on Node, don't forget FB runs on PHP, and they're investing in React.
https://github.com/reactjs/react-php-v8js
https://github.com/reactjs/react-php-v8js
That project literally requires that you have PHP manage a separate javascript runtime just to compile your templates. No thanks.
Side note: we started the process of getting the REST API merged today: https://make.wordpress.org/core/2015/09/21/wp-rest-api-merge...
(Feel free to ask questions if you've got any :) )
(Feel free to ask questions if you've got any :) )
This is awesome, nice work and good luck ;)
Congratulations, that's great news! What is the documentation status, as http://v2.wp-api.org/ has a lot of gaps?
We're working on it; meetings just started two weeks ago on our new documentation efforts: https://make.wordpress.org/core/2015/09/07/wp-rest-api-v2-do...
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!
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!
> the dependency on PHP can turn many developers away from using it.
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.
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.
What the author wants can be done way more efficiently with Drupal and its AJAX, not to mention that Drupal's data and template management is far better than Wordpress'.
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.
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.
Sure, dude, let's make a theme which is unusable with JS off.
Also known as: instead of plain HTML let's complicate things as much as we can.
[deleted]
I thought, WP was successful, because it was easy to deploy and easy to use ... and not because all the newest cool things where included ...
When I started to play around with Node and learning about NoSQL, this was the first thing I thought of. I knew this was going to happen.
Sure, this looks like a cool project, but good luck getting a bunch of non tech people to install node on some server. PHP is just too dead easy. What might be a good first step is to create a plugin for wordpress which creates these same rest endpoints and then replacing the frontend entirely (has been done before). Then, allow the backend to be swapped out with wordpress, this, ghost, whatever.
Seems nobody cares about this question: what's the target market?
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.