It's that time! Proposal to merge into core. A 2-parter though. Whatcha think?
Hello everyone! This is the post you’ve all been waiting for. We on the REST API team (myself, @rachelbaker, @joehoyle, @danielbachhuber, and newest member and core committer @pento) would like to propose merging the REST API into WordPress core. We’ve been working a while on this, and think it’s now ready to get your feedback.
This is our first iteration of the proposal, and we’re actively looking for feedback. If you have thoughts on the project, or on this proposal, let us know! Only with your feedback can we make progress.
What is the REST API?
The REST API differs from existing WordPress APIs in that it is explicitly designed from the ground up for modern mobile and browser usage, using the lightweight and widely-supported JSON data serialization format with a modern REST interface.
One of the hardest things to do in technology is disrupt yourself. But we’re trying our darndest, and have some cool news to introduce today. When I took on the responsibility of CEO of Automattic January of last year, we faced two huge problems: our growth was constrained by lack of capital, and the technological foundations of the past decade weren’t strong enough for the demands of next one.
The first has a relatively straightforward answer. We found some fantastic partners, agreed on a fair price, issued new equity in the company to raise $160M, and started investing in areas we felt were high potential, like this year’s WooCommerce acquisition. This “war chest” gives us a huge array of options, especially given our fairly flat burn rate — we don’t need to raise money again to keep the company going, and any capital we raise in the future will be purely discretionary. (Since last May when the round happened we’ve only spent $3M of the investment on opex.)
The second is much harder to address. The WordPress codebase is actually incredible in many ways — the result of many thousands of people collaborating over 13 years — but some of WordPress’ greatest strengths were also holding
This is a security release so better get to updating. Three issues including WP_Query being vulnerable to a SQL injection and a cross-site scripting (XSS) vulnerability.
WordPress 4.7.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.7.1 and earlier are affected by three security issues:
The user interface for assigning taxonomy terms in Press This is shown to users who do not have permissions to use it. Reported by David Herrera of Alley Interactive.
WP_Query is vulnerable to a SQL injection (SQLi) when passing unsafe data. WordPress core is not directly vulnerable to this issue, but we’ve added hardening to prevent plugins and themes from accidentally causing a vulnerability. Reported by Mo Jangda (batmoo).
A cross-site scripting (XSS) vulnerability was discovered in the posts list table. Reported by Ian Dunn of the WordPress Security Team.
Thank you to the reporters of these issues for practicing responsible disclosure.
Download WordPress 4.7.2 or venture over to Dashboard → Updates and simply click “Update Now.” Sites that support automatic background updates are already beginning to update to WordPress 4.7.2.
Thanks to everyone who contributed to 4.7.2.
Nice interview (with audio-only or video) of Matt by Brian Krosgard at WordCamp US 2016. Nice one-on-one moment, usual great content from Post Status (this is public, open to all).
I had the opportunity to interview Matt Mullenweg at the end of WordCamp US 2016, and we chatted about the new WordPress development cycle, the WordPress REST API, and more. During contributor day of WordCamp US in Philadelphia, I was able to interview Matt Mullenweg to follow up on several items he announced in the State of the Word.
We mostly discussed the new WordPress development cycle and how it will work with the three focus areas. We also discussed how that will affect other non-major updates and WordPress features.
Matt also talked about the WordPress REST API, how he defines success for it, what he hopes to see out of it, and what he thinks would cause it to revert to a plugin only feature.
And as this was the second and final year of WordCamp US in Philadelphia, we reflected on the event, and talked about what there is to look forward to in Nashville for WordCamp US 2017 and 2018.
You can listen to just the audio, also on our podcast, which you can find on iTunes, Google Play, Stitcher, and via RSS for your favorite podcatcher.
Or just watch the video on YouTube, or below for the full experience. And don’t forget to subscribe to my new channel on YouTube.
WordPress officially hits 25% - will be a solid 25% by WordCamp US.
People are abuzz because it looks like the W3Techs survey of the web now has WordPress at 25% market share. Sometimes it goes up and down through the course of a month, but it’s still a pretty fun milestone that we can now say about one in four websites are now powered by the scrappy open source underdog with its roots stretching all the way back to a single person in Corsica, France. We should be comfortably past 25% by the end of the year.
The big opportunity is still the 57% of websites that don’t use any identifiable CMS yet, and that’s where I think there is still a ton of growth for us (and I’m also rooting for all the other open source CMSes).
If you want to celebrate with us come to the first-ever WordCamp US event next month in Philadelphia (tickets still available) — it’s shaping up to be an amazing event. We just published the schedule and there are some amazing speakers and sessions.
It's here! Version 4.7 of WordPress, named “Vaughan” in honor of legendary jazz vocalist Sarah “Sassy” Vaughan.
Version 4.7 of WordPress, named “Vaughan” in honor of legendary jazz vocalist Sarah “Sassy” Vaughan, is available for download or update in your WordPress dashboard. New features in 4.7 help you get your site set up the way you want it. Introducing WordPress 4.7Get Link to Video
Presenting Twenty Seventeen
A brand new default theme brings your site to life with immersive featured images and video headers.
Twenty Seventeen focuses on business sites and features a customizable front page with multiple sections. Personalize it with widgets, navigation, social menus, a logo, custom colors, and more. Our default theme for 2017 works great in many languages, on any device, and for a wide range of users.
Your Site, Your Way
WordPress 4.7 adds new features to the customizer to help take you through the initial setup of a theme, with non-destructive live previews of all your changes in one uninterrupted workflow.
Theme Starter Content
To help give you a solid base to build from, individual themes can provide starter content that appears when you go to customize your brand new site. This can
Every year there's a brand new default theme, and Helen Hou-Sandi post gives us a preview. Designed by Mel Choyce.
It’s that time again: time to build a new default theme for WordPress! WordPress 4.7 will launch with a brand new theme – Twenty Seventeen. Designed by Mel Choyce (@melchoyce), Twenty Seventeen sports a modern look and will make a good base for any business website or product showcase.
Check out the gallery below to preview our next default theme at full-size: Higher resolution mockups
In addition to having a wide appeal, Twenty Seventeen will focus on providing a seamless initial theme setup so anyone can set up a website for themselves or their business with minimal hassle.
Twenty Seventeen aims to show off some new core features and enhancements, such as:
A better flow for using a static page as your front page.
Visible edit icons in the Customizer, replacing the current hidden shift+click method.
Expanding custom header images to include video (think: atmospheric video headers!).
Dummy content for live previews.
Mel will keep an eye on all things design during the creation of Twenty Seventeen. Laurel Fulford (@laurelfulford) and David Kennedy (@davidakennedy) will assist her, leading the theme’s development. Lots of opportunities exist this year for getting
The purpose of this post
We put the final version of PHP 7 to the test! We ran benchmarks for WordPress, Drupal, Magento, OctoberCMS and PyroCMS on a bare metal box comparing the performance with HHVM and PHP 5.6 and the results are non-ambiguous.
It’s been in the works for quite some time and after a long wait PHP 7 was released on December 3, 2015. We tested the most popular PHP based frameworks to see how they perform with PHP 7! It’s a great day for all of us who use PHP every day and that doesn’t just include developers (and web hosting companies) but end users as well. It will speed up the most popular web development language in the coming weeks and months which means faster websites and web services for everyone!
We’re addicted to optimizing the load times of websites and we’ve released numerous guides on the topic previously, take a look at A Beginner’s Guide to Website Speed Optimization, Best Free Website Performance Testing Tools, and more.
To see how much of an improvement we can expect from this new PHP interpreter we put the public release version of PHP 7.0 to test and compared a couple of popular software suites’ performance using PHP 5.6.16, PHP 7.0 and HHVM 3.10.1 on a bare metal server (so virtualization doesn’t interfere with the results). Tested software include WordPress 4.3.1, Drupal 8, Magento 2.0 CE, OctoberCMS build 309, PyroCMS v3 beta2, and Flarum v0.1.0-beta.4.
Long story short, HHVM wins hands down.
Accessible WordPress Components Library from 10up is awesome! Check it out!
We’re proud to introduce the WordPress Component Library: a collection of front-end components constructed with WordPress and accessibility at the forefront. Many of the HTML and CSS components we build for our clients are structurally similar, particularly for prolific features like menus, search forms, posts, and blogrolls. A common starting point offers efficiencies to our clients while simultaneously raising the bar on polish and compliance with standards like accessibility. In evaluating existing libraries, we found that the industry was missing a good, open source project built with WordPress’s often opinionated markup (e.g. menus) and basic layout structure in mind.
Since accessibility is a top priority for many of our clients, and critical to our mission to make the web a better place, each component in the library is WCAG 2.0 accessible. We think that this project will help engineers and clients who value accessibility, but may struggle to budget for it, achieve a higher standard with little-to-no added cost.
We are actively adding to and improving the components. Hosted on GitHub, we welcome feedback, questions, and pull requests.
The plugins review team has announced that WordPress frameworks are no longer allowed in the official plugins' repository. So we created IncludeWP.
Earlier this year (March 2016), the plugins review team issued a statement on make.wordpress.org that frameworks are no longer allowed in the official plugins repository. We decided to take it upon ourselves to create a worthy repository for WordPress frameworks and created IncludeWP. A home, or rather, a leaderboard, to display all open-source frameworks for WordPress plugin & theme developers. A one-stop-shop for developers to evaluate what’s currently out there in the market.
It had started as a fun & refreshing weekend side-project that the team had decided to pull together three weeks ago, and the plan was to release it right away. But, during the years I adopted a habit of not releasing anything before getting some feedback on it from people whose opinion I trust, so I decided to poke a few of my friends from the WordPress community first.
We got great feedback and some UI suggestions, but one comment drew most of my attention: Luca Fracassi from Addendio said: “Vova, it would be super-cool if I could click on a framework and see what plugins & themes are actually using it.”
“Hell yeah! That would be amazing.” I thought to myself. But
WordPress has supported custom page templates for over 12 years. With WP 4.7 the same functionality is coming to all post types, using "Template Post Type" in the file header.
WordPress has supported custom page templates for over 12 years, allowing developers to create various layouts for specific pages. While this feature is very helpful, it has always been limited to the ‘page’ post type and not was not available to other post types. With WordPress 4.7, it will be. By opening up the page template functionality to all post types, the template hierarchy’s flexibility continues to improve.
In addition to the Template Name file header, the post types supported by a template can be specified using Template Post Type: post, foo, bar. Here’s an example:
<?php/*Template Name: Full-width layoutTemplate Post Type: post, page, product*/// … your code here
That way, you’ll be able to select this full-width template for posts, pages, and products.
When at least one template exists for a post type, the ‘Post Attributes’ meta box will be displayed in the back end, without the need to add post type support for 'page-attributes' or anything else. The ‘Post Attributes’ label can be customized per post type using the 'attributes' label when registering a post type.
Selecting the post template
A must read! If you are a WordPress developer, you must read this post to find out about what's new in WordPress 4.4 releasing this December.
WordPress 4.4 is the next major release of WordPress and is shaping up to be an amazing release. While you have likely discovered many of the changes from testing your plugins, themes, and sites (you have been testing, right?), this post highlights some of the exciting
More folks need to be advocating for hosts to update their PHP versions. This is a fun post on the pitfalls of outdated PHP versions and it's impact on WordPress.
Recently in a facebook group someone posted this image, asking for clarification: This is what’s wrong with web hosting in 2016.
I thought I’d use that as a jumping-off point to talk about “bargain” hosting. This user is on a large (Super-Bowl-ad-budget large) hosting company’s “shared” plan. The irony is that the user would have no way of knowing what version of PHP they are running, were it not for this gently-worded (ahem) encouragement from a plugin developer. This warning didn’t come from the host. It came from a 3rd party plugin developer.
Allow me to be a little more blunt.
But first, a related personal story: some time in 2015, after about 1,000 active users had installed my plugin, I had a user get in touch with me in the support forums saying that they were getting a strange “fatal error” upon activating Better Click To Tweet.
The short and non-technical explanation of the problem my user was having is that the version of PHP they had installed did not include support for a function my plugin needed to function correctly.
The even-shorter explanation: this user used the same large web host as the original picture-sharer above.
For some web hosts, service and security clearly
While some delay makes sense but converting everything in the wp-admin before merging doesn't. IMHO that's not the core purpose of WP REST API. Progressive enhancement makes more sense.
The WP REST API team met yesterday in the #core-restapi Slack channel to discuss the status of the existing post, term, user, and comment endpoints. There are a few outstanding issues with these four core objects, which the team wants to tackle via a feature plugin approach instead of holding the API back from merge. These outstanding items include things like password-protected posts, autosaves and post previews, and meta handling. “For now, we’re not going to support them, and will be working on them in a separate feature plugin instead,” WP REST API project lead Ryan McCue said. “Again, this will be an enhancement to the API in the future, and doesn’t block compatibility here.”
In September 2015, McCue and contributors outlined a merge plan for the REST API which brought the infrastructure into the 4.4 release with the endpoints on deck to follow one release later in 4.5. Contributors to the REST API believe that the project is still on track for this goal.
“Our proposal is that we merge the four core objects in the REST API with full read, create, update, delete support, with the more peripheral features to come when they’re ready,” McCue said.
Several WordPress contributors,
WordPress officially ending support for Internet Explorer versions 8, 9, and 10, starting with WordPress 4.8.
Previously, we discussed the new editor and browser support within WordPress core. Following up on those conversations, we are officially ending support for Internet Explorer versions 8, 9, and 10, starting with WordPress 4.8. Microsoft officially discontinued supporting these browsers in January 2016, and attempting to continue supporting them ourselves has gotten to the point where it’s holding back development. I realize that folks still running these browsers are probably stuck with them because of something out of their control, like being at a library or something. Depending on how you count it, those browsers combined are either around 3% or under 1% of total users, but either way they’ve fallen below the threshold where it’s helpful for WordPress to continue testing and developing against. (The numbers surprised me, as did how low IE market share overall has gone.)
Of course, wp-admin should still work in these older browsers, but with fewer capabilities, and we will no longer be testing new features and enhancements in these browsers. For example, the next versions of TinyMCE – currently targeted at WordPress 4.8 – will not support older IE browsers.
From a performance standpoint, there appears to be a slight advantage. This isn't a topic i've seen covered before, good read!
Since the introduction of the WordPress REST API, many plugin developers have started converting their plugins to use the REST API instead of the older AJAX API (admin-ajax.php). Aside from the REST API simply being newer technology, rumor has it that the REST API is also faster and more reliable than the older endpoints due to the fact that not as much of WordPress is loaded during a typical REST request. In this article, we’ll be looking at the life of a typical REST request as well as a similar request made over admin-ajax.php to see how they compare.
The Life of an admin-ajax.php Request
Let’s start by breaking down what happens when we make a typical AJAX request to admin-ajax.php. When your browser makes a request to that file, it loads a few other core WordPress files in order to be able to serve the request with core functions loaded:
/wp-settings.php (which loads most core files, all active plugins and themes, and the REST API)
After loading these files, WordPress calls the admin_init hook, which several core functions hook into. The below core functions were called on this hook
Great overview of many of the features coming to WordPress 4.5 from Aaron Jorbin
WordPress 4.5 is the next major version of WordPress and with it come some bang bang changes. This guide will describe many of the developer-focused changes to help you test your themes, plugins, and sites. So grab a ☕️ ,
Matt gives some of his thoughts, perceptions and feelings on of how things are going with core foci. Rest API admin will take some time I think.
Just wanted to give folks my perception and feelings on of how we’re doing thus far with the core foci: Writing: I’m really happy with the progress. It has had some slower weeks here and there the past few months, but by and large the technical prototypes we implemented have been successful and we’re ready to move into the next phase. We have a Chrome fix we have to get in the next minor release, and the link boundary improvements will be going into TinyMCE core and could be great for an interim +0.1 release.
Customization: Doing well. Remember: The plan is for the larger block-driven customization work to kick off in June. Prior to that, we’re focusing on widgets and other low-hanging fruit. Lack of developers slowed us down last few months, now doing better but could still use more help there. Media widgets + WYSIWYG on text widget seem simple but will have a big user impact.
REST API: There has been little to no perceivable progress on having any parts of wp-admin powered by the REST API.
Considering 4.8: The TinyMCE inline element / link boundaries, new media widgets, WYSIWYG in text widget, and perhaps something else small like the WordCamp / meetup dashboard
Ideas for improving workflow and encouraging more PHPUnit test writing.
We use Varying Vagrant Vagrants (VVV) as the development environment for as many projects as we can. It provides a great foundation not only for developing client projects but also for core development itself. One great thing about VVV is that it installs all of the tools needed to run the core unit tests right out of the box. Our wp-dev-lib project has a PHPUnit plugin bootstrap that makes use of the core unit tests as installed by VVV, and we have a pre-commit hook which can run the plugin PHPUnit tests inside the VM even when making a commit from outside (on the host machine). This ability to run PHPUnit tests inside the VM makes it easy for getting developers quickly set up to run PHPUnit tests, and it’s also something that is suggested for core’s PHPUnit Grunt task (#36190).
Tests running outside of the VM are a fast and happy place.
— Jeremy Felt (@jeremyfelt) March 10, 2016
Even though VVV lets you run core’s PHPUnit tests right out of the box, the tests can run more slowly in the box. If you have a pre-commit hook that runs unit tests with each commit, your workflow can be really slowed down (especially since the tests should eventually by run by Travis CI after
Matt Mullenweg, on Medium (!!!), talks about update signing and security in general.
We all make mistakes, and sometimes we need to hear about other's (larger potentially) mistakes to feel good.
I’m going to take you guys back to a time when I was doing some client work. I was at the time working on becoming a somebody in the WP Dev community. I attached myself to a really awesome designer George Wiscombe, and started working on a theme he designed called Handgloves. I began by widgetizing it (which was just starting to catch on — that probably dates me a little) then added a couple of built in social media hooks. I emailed him and told him I was working on it, and he released my changes, and because he is an AWESOME dude, gave me a byline on it.
We (Humankind) had a client that wanted a WordPress Multi-User (yep, before multi-site — dating myself yet again) installation for their interior design network, with an asset catalog that lived under the main root, but all the designers’ sites as sub-domains. We ran into a little problem, Handgloves used TimThumb, and TimThumb’s wordpress implementation at the time had a small problem. It was hard-coded to use only the local uploads folder by prepending the website URL to the uploads directory, then appending the image name.
I decided to do a quick fix for this, and post it up on my old personal blog.
The WordPress Theme Developer Handbook has finally been released. Congrats to the almost 100 involved. Feedback welcomed.
Weekly Meetings As well as discussing docs issues here on the blog, we use Slack for group communication.
Individual teams have their own regular meetings – you can find details of those in the sidebar.
WebDevStudios just published a list of their development resources- bookmark to get them in one go.
Some people make health a focus of their New Years Resolutions–not that being healthy shouldn’t be on a persons mind, but I like to use the New Year as a way to clean out the cobwebs of development. To think over the past year and decide what processes worked and didn’t and then wipe away those that failed. I usually start by cleaning out my git repos and local development. I like to think about any frameworks/libraries that I didn’t fully use over the past year and evaluate their worth. Some may have been used others are kicked to the curb. Now that I have a cleaned up development environment I like to see what new open source frameworks/libraries I could benefit from. 2015 was defiantly the year companies open sourced their code.
Its beneficial to create reusable code in projects so future projects can be more efficient. Over time we have created some open source development resources that you can add to your development tool belt. The list below contains plugins, frameworks and libraries that you can get from the WDS Github or WordPress plugin repo.
WDS Image Class library can be used in your theme template files to get an image whether it be a featured image, the first image in