The Saga Continues

WordPress

WordPress was borne of initial idea seeding via B2 (Cafelog) in 2001, which was launched by Michael Valdrighi. In 2003, cofounders Matt Mullenweg and Mike Little forked B2 and created WordPress, an Open Source blogging and now content management system estimated to power the largest number of websites of any individual product (20%). Through the largest thriving community of any website management system, WordPress has grown to include theme designers, plugin developers, webmasters and site developers. With the power of participants, WP now can power anything from small individual blogs to large multi-user social communities to business websites. Core contributing developers include Ryan Boren, Mark Jaquith, Matt Mullenweg, Andrew Ozz, Peter Westwood and Andrew Nacin. WordPress has just recently celebrated its 10 year anniversary.

WPCommunity

WPCommunity.com was started as an extension of Web Developer Tom Ford who found WordPress in the early days looking for a solution to power a group of large websites that had outgrown their flat HTML infrastructure. Needing more features, WordPress was chosen based on another user who was kind enough to put together a comparison chart of several platforms, with detailed information. The way this individual was able to present this side by side comparison using WordPress ultimately led to giving it a shot...which led to massive experimentation to the different things it could do. The heavy and growing demand for assistance led to offering such, bringing us to today. Tom Ford has contributed to various other development agencies including TC Websites, WPMU.org and WPML. (as well as solving countless technical issues and working through many full website builds).

Photo Credit: Ian D. Keating

FEB 2, 2016
WORDPRESS 4.4.2 SECURITY AND MAINTENANCE RELEASE  WordPress 4.4.2 is now available. This is a security release for all previous versions and we strongly encourage you to update your sites immediately. WordPress versions 4.4.1 and earlier are affected by two security issues: a possible XSS for certain local URIs, reported by Ronni Skansing; and an open redirection attack, reported by Shailesh Suthar. Thank you […]
  • RECENT WORDPRESS NEWS ON THE WEB
      • FEB 8, 2016
        WPTAVERN: WORDPRESS CONTRIBUTORS LOOK FOR A PATH FORWARD FOR THE WP REST APIphoto credit: Valeriy Poltorakphoto credit: Valeriy Poltorak

        Over the weekend, discussion continued surrounding the direction of the WP REST API, as both Matt Mullenweg and Ryan McCue took to their WordPress blogs to clarify statements from last week’s status meeting. Differences of opinion are driving a heated debate about what constitutes a goalpost for the API’s readiness for core.

        In a post titled “Chicken and Egg,” Mullenweg addressed the recent WP REST API discussion while sharing an anecdote from a book that covers history from the mid-90s hip-hop era.

        I love the idea of Questlove realizing the song was missing something, and going back to the booth to keep working on it until it resonated with his target audience. A song that doesn’t stand up on its own wouldn’t be any better when bundled as part of an album. (Or Samsung would have the most popular apps on Android.) Fans hear the care and quality of each track, and they become super-fans.

        Mullenweg relates it to considerations when building products for the web:

        There’s this tension in everything we produce. Where’s the line to tread between 1.0 is the loneliest and a minimum viable product? Or is it about a minimum lovable product? Are we building a car with no air conditioning or a car with no wheels?

        ‘Pivot’ has become passé, but it’s much worse to assume that distribution will solve something core to your product that isn’t working.

        Mullenweg mentioned the same car analogy during the meeting last week. In response to a commenter who asked for more clarification on how the analogy applies to the REST API, Mullenweg said the following:

        If you want a good heuristic to use generally: there were decades of cars, millions of vehicles and drivers, before they had air conditioning. The core value proposition of a car is transportation, AC just helps you get there more comfortably. You didn’t need a car to get AC, you could have it in your house. AC might cause you to chose one car over another, but you probably wouldn’t walk or ride a horse if the car didn’t have AC, you’d just roll down the windows.

        This begs the question, what constitutes wheels? Contributors to this discussion are divided on whether or not the existing endpoints are ready to be merged into core. The WP REST API team members, many of whom are already successfully using the API in production, believe that the endpoints are ready now. The current state of the API offers the ability to get content in and out of WordPress, opening it up for easier communication with other platforms, which many believe is the primary use case.

        Mullenweg and others who joined the discussion last week are in favor of delivering something more complete, a REST API that supports everything available in wp-admin. This includes WordPress’ many site management features and would put the API several releases away from core readiness.

        In a comment on our initial report, Drew Jaynes advocated what he believes to be a middle ground that provides a solid jumping-off point. This would involve resolving the missing pieces in the existing endpoints before merging them (items like password-protected posts, autosaves and post previews, and meta.)

        “As I and others from the contributor/committer camp said in the chat, there can be a middle ground,” he said. “Whether that ends up looking like the four core endpoints alone, four core endpoints with some flavor, XML-RPC parity, or some measure of wp-admin parity, remains to be seen,” he said.

        In a post titled “Progressive Enhancement with the WordPress REST API,” Ryan McCue outlined a full-on iterative approach that would push for distribution now and roll out more endpoints in future releases:

        Progressive enhancement is our key solution to a couple of related problems: forward-compatibility with future features and versions of WordPress, and robust handling of data types in WordPress. Progressive enhancement also unblocks the REST API project and ensures there’s no need to wait until the REST API has parity with every feature of the WordPress admin.

        McCue’s post goes into further detail of the REST API’s feature detection capabilities, which allow developers to easily detect support for features and build them in a forwards-compatible way while waiting for core support.

        Is Distribution the Answer?

        During last week’s meeting McCue said that continuing the project’s development as a feature plugin will do more harm than good. If the REST API is not allowed to ship without offering support for everything in wp-admin, the team would be forced to continue iterating on it as a feature plugin while simultaneously resolving difficult roadblocks in WordPress core. With just four major contributors operating at less than part time on the project, this requirement could stall the WP REST API indefinitely.

        “We believe that the progressive enhancement approach is the best approach for continuing API development,” McCue said. “Progressive enhancement is a paradigm the REST API project ​must​ adopt, if it’s an API we want to add to (without breaking backwards compatibility) over the next 10 years.”

        Mullenweg, who has led an iterative approach to development throughout WordPress’ history, is wary of latching onto distribution as the only way forward.

        The larger WordPress’ usage becomes, the louder its footsteps are heard. Iterating on the REST API in core, with distribution to millions of sites, may affect the web in ways contributors cannot yet anticipate. As they say, heavy is the head that wears the crown. The ripples extend beyond WordPress sites to the outside platforms that will also consume the API.

        Contributors are still discussing the nuances of iterative development in core vs. delivering a more complete API. Meanwhile, adoption is stilted by the uncertainty surrounding the project and the fact that it still carries a plugin dependency. It’s not yet clear whether WordPress contributors will dig in and push for inclusion of the endpoints against Mullenweg’s recommendation or whether they will opt to spend more time polishing the existing endpoints. If the WP REST API team is required to ensure that the API can support a wp-admin replacement, it may not land in core until the end of this year or later.

        FEB 5, 2016
        WPTAVERN: WORDPRESS.ORG HAS FEWER THAN 20 PLUGINS USING THE WP REST API V2Plugin Recommendations Featured Imagephoto credit: when i was a birdcc

        During yesterday’s pivotal WP REST API meeting, WordPress contributors discussed adoption of the API. A cursory search of the WordPress.org plugin directory shows that fewer than two dozen plugins are currently using the API scaffolding included in WordPress 4.4. For reference, here are the 20 plugins identified by Mika Epstein during the meeting, along with active installation numbers for each:

        With a few notable exceptions, most of these plugins are hovering around a range of 10 – 100 active installs. These low numbers may indicate that plugin authors have not yet readily embraced building with the scaffolding that was merged into core in 4.4. However, some developers who have embraced building with the API have opted not to offer their plugins and themes for large scale distribution on WordPress.org.

        “I think the plugin directory is the wrong place to look for adoption,” WordPress developer Nate Wright said at the most recent meeting. “As a plugin author myself, I have to bend over backwards to ensure compatibility with tens of thousands of weird plugins and themes. Javascript itself is highly unstable in the ecosystem because of all the terrible code out there. I’ve used the API in client projects and am currently integrating it with some customizer tools I’m building. My publicly available plugins will be the last thing I’ll introduce to the API.”

        Taylor Lovett, author of Custom Contact Forms, believes that it’s important to get REST API-powered plugins into the hands of users, despite the support challenges of public distribution.

        “It pushes plugin and theme developers to start working around API JavaScript conflicts now,” Lovett said. “There are many plugins that conflict with the API for a variety of reasons, one of the big ones being modifying Backbone.sync. Having plugins use it now is painful but will push people to start reporting those JS conflicts.”

        Custom Contact Forms is currently the most widely-used plugin running the WP REST API with more than 70,000 installations, but the journey to using v2 has been fraught with challenges.

        “There have been a number of backwards compatibility breaks with the JSON REST API project,” Lovett said. “If I had known going into it what would happen, I probably would have not used the API.

        “I am still not completely comfortable with using the API because of the perceived instability of the project,” he said.”

        Nevertheless, public distribution has brought Lovett considerable feedback from users which has been invaluable for his contributions to the REST API project.

        “I’ve had a number of patches to the API that were discovered through Custom Contact Forms,” he said. “I’ve discovered some real edge cases while maintaining the API across more than 70K installations.”

        Distributing his plugin on WordPress.org while the API went through significant changes was more challenging than Lovett anticipated, but through it the API has gained more exposure.

        “The faster the API is exposed to people and people get comfortable using it, the sooner we will see some major strides in applications being built around WordPress,” he said.

User Representations

"Numbers Don't Lie, Check the Scoreboard"

Download Counter