Matt Mullenweg to make WordPress great again – puts releases on hold

In his State of the Word 2016 speech Matt Mullenweg, the project lead for the WordPress project announced that there will be no releases of WordPress in the upcoming future. Development on the project will continue, but before a new official version is released – there will need to be significant improvement in key areas.

Matt will not sign off any new releases before the community addresses three key areas in WordPress that he identifies as which could become a hindrance as WordPress reaches for higher market share and even wider popularity in it’s task for world domination to democratise publishing of content in the Internet:

It is best in life to crush your enemies with marketshare, to see them driven before you, and to hear the lamentations of their proprietary CMS.
– Conan the Mattarian

The three areas that the great leader sets his target to are:

1. The WordPress REST API: The WordPress REST API has been in development for a number of years, but continues to lack many key functionalities, including authentication. WordPress 4.7 adds more endpoints to core, but this is not sufficient according to Mullenweg.
2. The Editor: The rich text editing functionalities provided in the default editor are lacking behind the competition. He would like the community to reimagine the editing experience and embrace the poetry of the code. This is partially already happening in the Automattic built JavaScript shell for WordPress, Calypso.
3. The Customizer: The customizer allows live-previewing to configuration changes done to a WordPress installation. It enables handy previews of theme changes, color changes and widget placement to provide a basic WYSIWYG preview. Competition like Wix and Squarespace are more advanced and for WordPress to stay relevant and remain number one most popular publishing tool it needs to catch the proprietary pair.

With these targets set the project should be well set to continue dominating and even expanding it’s market share and reach. This is key in battling proprietary corporations that have the funding to run multimillion dollar marketing campaigns of their products, where as WordPress is an effort of love and devotion for many – a true community effort!

Let’s Make WordPress Great Again!

A tale of WordPress, Wix and Open Source Licensing

On October 28th the Automattic CEO Matt Mullenweg published a blog post accusing that Wix, a provider of competing services, has stolen code from the WordPress codebase. To be specific, it was about the use of a rich text editing component in the Wix mobile app:

If I were being charitable, I’d say, “The app’s editor is based on the WordPress mobile app’s editor.” If I were being honest, I’d say that Wix copied WordPress without attribution, credit, or following the license. The custom icons, the class names, even the bugs. You can see the forked repositories on GitHub complete with original commits from Alex and Maxime, two developers on Automattic’s mobile team.
– The Wix Mobile App, a WordPress Joint

There were some claims that Wix had not respected the GPL licensing in place for the component. They may or may not be valid, but what Matt is claiming about it being a copy is just what is going on with Open Source. It is supposed to be the exact same code, warts and all…

But with Matt Mullenweg being no stranger to petty litigation, it seemed like FUD driven by jealousy over use of Automattic code in a competing product. Wix CEO Avishai Abrahami soon replied, making it clear that it is the exactly the same code that is being used. And that component is available as open source on GitHub:

Yes, we did use the WordPress open source library for a minor part of the application (that is the concept of open source right?), and everything we improved there or modified, we submitted back as open source, see here in this link – you should check it out, pretty cool way of using it on mobile native.
– Dear Matt Mullenweg: an open letter from Wix.com’s CEO Avishai Abrahami

What Avishai fails to address are some of the accusations Matt Mullenweg makes against Wix and that the whole mobile application should be made available by complying to the terms of the GPL license. This is interesting, but the saga continues.

Update: It has now been confirmed that Wix will release the full source code to their mobile application:

Wix to release full mobile app source code, including the GPL disputed WordPress Rich Text Editor

Automattic themselves fail to comply MIT licensing

From a more technical post by the lead developer of the mobile app at Wix, it seems that the component that Mullenweg and Wix are quarrelling over is itself a wrapper for another Open Source project, ZSSRichTextEditor, licensed under the MIT license:

The WordPress GPL Rich Text component in question, is actually a wrapper around another Rich Text component named ZSSRichTextEditor which is licensed MIT. In retrospect it would have been easier to use it directly.
– How I Found Myself Accused of Stealing Code from WordPress

Now it is no longer clear whether the WordPress editor component itself has a valid license, at least when it comes to the iOS version of the Rich Text Editor. This is because on  March 20th 2015, the Automattic team proceeded with removing the MIT license from ZZRichTextEditor and replacing it with a GPL one:

This is a violation of the MIT license terms from Automattic. So as it stands it seems quite unclear who actually has the right to do what as the MIT license requirement is no longer respected by the Automattic editor component:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
– ZZRichTextEditor MIT license

Maybe in the future it would be good not to shoot first and ask questions later. But I guess this is how they do it in Texas.

The only person who has not gotten credit for work is the original creator of the ZZRichTextEditor, Nic Hubbard. If this case moves beyond throwing words on the web, only one thing is for sure: Lawyers will be making a killing off it.

So for sure Open Source licensing continues to be a tricky subject, with keeping in mind that the underlying React library from Facebook has some unclear licensing itself.

UPDATE: Wix has now abandoned their work on the WordPress editor and are focusing on a direct fork of the ZZRichTextEditor: Wix abandons WordPress GPL editor fork in favour of original MIT library

WordPress Calypso and GraphQL

GraphQL is a communication protocol that allows web applications to communicate. It is similar to the much hyped REST APIs, but is more uniform and thus more universal. This makes GraphQL usable across CMS products.

Which takes us to the gamble that WordPress and the Automattic corporation behind it have taken with the Calypso initiative. It’s a JavaScript powered shell for the WordPress PHP CMS.

Calypso is heavily built on technologies that come from the world of Facebook, especially the combination of React.js UI library and the Redux Flux architecture implementation.

GraphQL is also a Facebook initiative, so one would think it’s a drop-in-replacement for the WordPress REST API. But currently as of June 2016 the effort is in so much work that there are no visible signs of WordPress Calypso for taking GraphQL into use.

Instead WordPress continues to utilise it’s own communications library, WPCOM, that uses a custom version of the REST API that is currently only available to users of the proprietary hosted WordPress.com content platform similar to Medium.

In the future WordPress may well choose to go with GraphQL, but it using Facebook technologies does not guarantee this as the communication layer is separate from the UI. In addition it’s worth noting that the WordPress REST API itself is not progressing as smoothly as it could.

Mossack Fonseca trusted WordPress

An incredibly large number of WordPress sites run a large parts of the web. From one hobby blogs to code boutiques to enterprise blogs, everyone is running an own copy of this popular Open Source blogging platform turned Content Management System.

The problem with WordPress is not that it’s inherently insecure, it’s just that it’s become so very popular that it’s become a tempting target for hackers to exploit. The codebase dating from the early 2000’s does not help. Neither do the thousands of the amateur level plugins people blindly install to create the functionalities they want to their site.

This issue has been largely ignored by many audiences, even if their site keeps getting all kinds of “skulls and crossbones” popping up in the admin every once in a while. If it’s a marketing site that you’re running it may seem like a reasonable compromise that you need to handle for a free Open Source product and cheap custom implementation. With nonexistent maintenance.

But WordPress and other similar tools are now widely employed in all kinds of environments. Usually the hacks don’t yield much damage for individual site owners as it’s much more beneficial for the attackers to use them for Distributed Denial of Service attacks (DDoS) than deface them.

In some cases such a vulnerable WordPress installation can lead to massive information breaches. This seems to be the case for Mossack Fonseca, the company that suffered from the largest information leak in history:

Maunder said his team assessed Mossack Fonseca’s IP history and discovered that the firm’s website IP was on the same network as its mail servers. The law firm’s website was wide open until a month ago and would have been “trivially easy” to exploit, he wrote on Wordfence.com, in a security update.
– Pros examine Mossack Fonseca breach: WordPress plugin, Drupal likely suspects

In this case tax evasion information was a juicy bit of information to leak out. But imagine, if hackers can attack such an organisation. What’s stopping them from using an insecure installation at some of the establishment that you trust with your private data like medical records or something.

Not long ago Ashley Madison, a dating site for example leaked large amounts of information that was very sensitive and harmful to many individuals. The minimum you should do in the future when deploying WordPress is to understand the dangers of blindly collecting a number of plugins and leaving your WordPress installation unmaintained.

State of the WordPress REST API

There are two key “components” to the API: the infrastructure that makes it possible to register endpoints and define their behaviours, and the core endpoints which leverage the infrastructure bits to create RESTful endpoints that let you read/write/manipulate WordPress features like posts, pages, etc.

The infrastructure bits are already in WordPress core. If you maintain a plugin or client website that you’d like to build a custom API for, that’s all set. You can go ahead and do that right now, no questions asked.

The core endpoints are what are causing all the fuss and drama. Essentially, a certain group of people (most vocally WordPress creator Matt Mullenweg) feel that the core endpoints, which are not yet in WordPress core, shouldn’t be merged until they can replicate every piece of functionality that the WordPress admin panel(wp-admin) is capable of.

The team who has been building the REST API for the past few years isn’t thrilled about that stance. They designed the API to be capable ofprogressive enhancement, where new features can be added without breaking old clients. They argue this gives them more time to determine the best approaches for some of these really complex features.

The other faction feels that releasing a limited set of core endpoints will ultimately cause more confusion and frustration for users, many of whom may be encountering APIs for the first time ever when they work with the WP REST API.

That’s essentially the state of affairs. Because Matt Mullenweg is a sort of “benevolent dictator for life”, the API is kind of in a stalled point until his (and others; he’s not the only one with this stance, but he’s uniquely positioned to affect change) concerns are quelled.

Kudos: https://www.reddit.com/r/webdev/comments/4curo1/what_is_the_state_of_the_rest_api_in_wordpress/d1lmlju?context=3

Drupal goes with Angular 2, WordPress with React, Laravel with Vue.js

Drupal and WordPress continue their battle for supremacy of the web, it looks like the two have also sided differently when it comes to their decoupling with JavaScript and REST efforts. Back in November 2015, Automattic – the driving force behind WordPress – announced their WordPress shell running on Facebook’s React view library:

Calypso is a modern shell for the old WordPress back end, using the soon to be available REST API. The shell is built with contemporary technologies such as React and Node.js. The interface is built off a clean slate and is already in production use over at WordPress.com.
– The future of WordPress is JavaScript

Some six months later and much deliberation Dries Buytaert seems to have sided with the Google backed Angular 2 front end framework for their future:

Decoupling Drupal and working with a front end framework has been a hot topic in the Drupal Community for a while now. Dries Buytaert has discussed the prospects of different options, and has even credited the Angular 2 team for changing their licensing to be compatible with Drupal.
– Drupal team working on Angular 2 Universal support for Twig / PHP

These are competing technologies and the battle has now been upped a notch. What remains notable is that both sit on the shoulders of Giants; WordPress Facebook’s and Drupal on Google’s. The odd one out is Laravel showing support for Vue.js:

Vue.js is the best JavaScript framework that you’ve likely never heard of. We’ve already covered React here at Laracasts, so let’s move on to something else – something far more simple, many might say. Intrigued?
– The Vast World of Vue.js 0.12

JS Comparison: Angular vs. React vs. Vue

Data Journalism CMS Requirements

Content Management Systems are tools for publishing created content online. With the rise of rise of Data Journalism there is an increasing need to provide content creators with the tools to merge content and data.

Below are some opinions on what those requirements should be for a good Data Journalism CMS should have.

A mature DMS will let people do all the following things. Whether as a proprietary monolith, or by slick integration across the web:

• Load and update data from any source (ETL)
• Store datasets and index them for querying
• View, analyse and update data in a tabular interface (spreadsheet)
• Visualise data, for example with charts or maps
• Analyse data, for example with statistics and machine learning
• Organise many people to enter or correct data (crowd-sourcing)
• Measure and ensure the quality of data, and its provenance
• Permissions; data can be open, private or shared
• Find datasets, and organise them to help others find them
• Sell data, sharing processing costs between users

– Content Management Systems, remember those?

And another set:

Data Journalism requires flexibility from the publishing platform. Not only do you need to provide tools for creating original content by hand, but also integrated tools to collect and analyse large amounts of data. And all this needs to be done in a single easy-to-use environment to keep production cost reasonable.

Four points sum up what you should look at when selectign :

• Excellent content creation tools: Content is where the media focuses at, you should not compromise on this.
• Integrated data collection and analysis tools: There should be basic collection and analysis tools for collecting data from the visitors.
• Integrated personalization tools: Automatic content recommendation tools for inserting data into the correct visitor context – based on profile or device at hand
• An extensible interface: Both content and data centric activities need to be done in the same interface. It should be easy to embed content derived from data.

– Best CMS for Data Journalism