Great news! The website and code are all coming in under the WordPress.org umbrella and financial support is also involved.
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.
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.
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
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
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
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
MIka explains policies regarding forks and copies in the WordPress repo.
This has come up recently. What happens when someone submits a plugin that’s a copy of another? The tl;dr here is this: Please email us at email@example.com if you find someone has slipped an uncredited fork or identical copy of another plugin into the repository.
In general, we spot these before they ever get published. We rejected 10s of plugins a month for being identical copies. That said, we also approve double that for being legitimate forks.
While the GPL and it’s compatible licenses allow for forking, we have an ‘above and beyond’ rule for hosting here, that means your plugin must be a substantial change of the original. We do not allow direct copies of other plugins to be re-listed under somebody else’s name, we allow changed forks.
What does that mean? It’s very simple. You have to add new features, remove features, modernize, fix, clean up, or otherwise make a change to the plugin that differentiates it from the original. In rare cases, a simple clean-up will be accepted, but normally we try to get a hold of the original authors and have the fixes folded in to the original plugin. If you have a fork, we require you to retain all credit and/or copyright information.
Mika does a descriptive guide on how to properly report plugin issues.
Note: I’ll be using Hello Dolly as my example ‘bad’ plugin for this post. It’s fine and not (to my knowledge) vulnerable. There are a few reasons people report plugins but the main two are as follows:
If you report a plugin, you can make everyone’s life easier if you do the following:
Verify that it’s still applicable
Before you do anything, check if the exploit is on the latest version of the code or not. If it’s not, we may not do anything about it, depending on how popular the plugin is.
Use a good subject line
“Plugin Vulnerability” is actually not good at all. “Plugin Vulnerability in Hello Dolly – 0 Day” is great.
Send it in plain text
SupportPress is a simple creature. It doesn’t like your fancy fonts and inline images. Attachments are fine, but we cannot read your ‘Replies in-line in red’ so just keep it simple.
Link to the plugin
Yes, it’s that easy. Put the URL on it’s own line, no punctuation around it, for maximum compatibility. With over 35k plugins, and a lot with similar names, don’t assume, link.
If the plugin is not hosted on WordPress.org, I’m sorry, but there’s nothing we can
If you got all mad about the shortcode breaking thing in the last update, here is your chance to smile again. They are unbreaking the shortcode thing now. :)
tl;dr WordPress 4.2.4 RC1 is available (download) for testing and fixes an issue with inline scripts. A change in WordPress 4.2.3 had the unintentional side effect of breaking some inline scripts when the CDATA block is used (see #33106). For example, consider the intended content here:
In 4.2.2, this content is left as is and _my_function() fires as expected. In 4.2.3, the content is manipulated as such:
This results in the script being commented out by the // and it will not fire. A workaround for this is to use /* for commenting.
However, this workaround should not be necessary. As a result, we intend on releasing WordPress 4.2.4 to fix this issue.
Additionally, WordPress 4.2.3 caused issues when using shortcodes within angle brackets (see #33116). For example, this shortcode usage worked in 4.2.2 but did not work in 4.2.3:
While we do not recommend this use of shortcodes and strongly encourage plugin developers to move away from this use of shortcodes, the breakage was unintentional
Konstantin Obenland, Samuel “Otto” and Meta team is working on bringing V3 for WordPress.org plugin directory. They are looking for MVP by March 1 and working for the final release date of June 26. Stay tuned, and check all the improvement coming. Its big change, as instead of using bbPress, now all will be based in WordPress.
A year after relaunching the Theme Directory on WordPress, the Plugin Directory will finally get the same make over. With the entire process being open source from the start, please feel free to follow along and contribute on Meta Trac and in the #meta Slack channel. For more in-depth information, please consult the project overview page.
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 ☕️ ,
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.
"A long overdue change is in the air " — Emil Uzelac
Sometimes, things need to change; that’s true for everything. The Theme Review Team is aware that we currently have problems. This post proposes some suggestions for how we should change. The objective of these changes are to reduce queues and make reviewing easier, both for those being reviewed and those doing the review. A big thanks goes out to everyone that has helped with writing this post. Specific props to @emiluzelac, @grappleulrich, @greenshady, @samuelsidler, @cais and @jcastaneda. The admin team have signed off on this in agreement.
Our role as a team should be to check that the theme has no licensing, security, or “breaking” issues. Any issues beyond those three categories should be dealt with after the fact, not during review. We all want to do more, but without ensuring we provide the minimum review to themes in a timely manner, we aren’t succeeding.
Let’s have a look at the following sections and see how we can improve.
In order for us to function, we should change the structure of our team.
Reduce down to 2 tiers for reviewers: key reviewers and reviewers. No more admins. If you have not been actively contributing to theme review
A collection of useful links to all the things shipping with WordPress 4.7. A must-read for all WordPress developers.
WordPress 4.7 is shaping up to be the best WordPress yet! Users will receive new and refined features that make it easier to “Make your site, YOUR site”, and developers will be able to take advantage of 173 enhancements and feature requests added. Let’s look at the many improvements coming in 4.7… RESTing, RESTing: 1, 2, 3
The foundation for RESTful APIs has been in core since 4.4, and 4.7 sees the addition of Content Endpoints after a healthy discussion. We’ve defined four success metrics as part of the merge discussion and you can help by building themes and plugins on top of the API, using the API in custom development projects, and utilizing the API for a feature project, core features, or patches. So, dive in, start playing around, and let us know what you build!
Hi everyone, it’s your friendly REST API team here with our second merge proposal for WordPress core. (WordPress 4.4 included the REST API Infrastructure, if you’d like to check out our previous merge proposal.) Even if you’re familiar with the REST API right now, we’ve made some changes to how the project is organised, so … Continue reading
It don’t mean
Twenty Sixteen is here, what do folks think, as always with default themes opinion seems mixed. I quite like it.
WordPress 4.4 will see a brand new default theme; that’s right, today is time to meet Twenty Sixteen! The process of selecting the Twenty Sixteen theme was a long one, taking several months. Lots of themes were considered, eventually settling on the one you see below. It’s a perfect fit! Twenty Sixteen features a new, never-released design that has some really unique touches on a traditional blog layout. It adapts well to different devices and is a joy to use.
Twenty Sixteen is a modernised approach of an ever-popular layout — a horizontal masthead and an optional right sidebar that works well with both blogs and websites. It has custom color options that allow you to make your own Twenty Sixteen. The theme was designed on a harmonious fluid grid with a mobile first approach. This means it looks great on any device.
Let’s take a look at more!
We have the pleasure of welcoming back Takashi Irie as the designer of Twenty Sixteen. This year, the core team developing our new default theme will be myself and @iamtakashi — and you! We hope you can join us in getting Twenty Sixteen out to the world. Along with us, @iandstewart and @samuelsidler will be making sure the ship stays
Well, slap me with a feather! I never thought I'd see the day where perhaps the biggest annoyance in all of WPland is now going to be just a distant memory! Happy days, oh happy days! :D
In  and  for #31168, we’ve turned comments off on new pages by default. I know many of you have done the “make a bunch of pages, fill them out, realize comments are turned on, go back into the admin, turn off comments” dance. Now when you make a page, you won’t have to manually turn off comments — it’ll match the expected behavior of being off by default.
In addition to pages, this functionality has been extended to all custom post types. Post registrations that don’t explicitly add support for comments will now default to comments being off on new posts of that type (before, they defaulted to on). Up until now, post type support for comments has only affected admin UI; a developer could omit comment support on registration but still allow comments to be posted. This is a change in behavior, and we will be closely monitoring its effects during beta. Moving to explicit support will allow core behavior to be more predictable and robust in the future, but we will always consider real-world usage.
In trunk, you’ll notice two new things: the get_default_comment_status() function, which accepts the post type and comment type as arguments (both optional), and within it a get_default_comment_status
If you're a WordPress plugin developer with plugins in the repo, note these changes to two specific guidelines.
With the advent of the new directory being on the horizon, which allows us to easily hard-limit the number of plugin tags displayed, we have taken the time to change the guidelines. While minor updates to the guidelines (with regard to spelling, grammar, etc) are common, major changes are rare and we are striving to be more transparent about them. Hence this post
Guideline 12 (readme links) clarified to cover spam and tags.
The guideline now reads as follows:
12. Public facing pages on WordPress.org (readmes) may not spam.
Public facing pages, including readmes and translation files, may not be used to spam. Spammy behavior includes (but is not limited to) unnecessary affiliate links, tags to competitors plugins, use of over 12 tags total, blackhat SEO, and keyword stuffing.
Links to directly required products, such as themes or other plugins required for the plugin’s use, are permitted within moderation. Similarly, related products may be used in tags but not competitors. If a plugin is a WooCommerce extension, it may use the tag ‘woocommerce.’ However if the plugin is an alternative to Akismet, it may not use that term as a tag. Repetitive use of a tag or specific
This could be a MAJOR improvement for Core. Imagine the whole Editor as "tiny blocks". Yes Please!
At the core of the 2017 editor focus is the is idea of introducing blocks (or sections) which help “make it easy what today might take shortcodes, custom HTML, or ‘mystery meat’ embed discovery”. How do we do that? Let’s start with paragraphs as blocks/sections. If we count a paragraph as a block or section you can manipulate, here’s how that could look:
You can still type type type but you create blocks along the way. When you mean to insert content that isn’t text, click the plus (or perhaps as a power-user feature, type / on a newline, Slack-style?), to invoke the insert menu:
Click an item to insert it, or pick it using arrow keys.
One of the interactions we need to figure out here, is what happens when you press Enter, as you’re writing. Over chat in the past week it was suggested we might want to tweak the default behavior so that Enter inserts just a single linebreak, and a new paragraph is created with two linebreaks. (The pertinent bits of the chat starts here, or you can read this summary).
Let’s discuss these mockups, data structure, linebreaks and lots more in Wednesdays editor chat, January 25, 2017 6:00:00 PM GMT! And
This is 2016 and email is no longer the only way to send notifications. We have many more options, like push notifications to mobile platforms, desktop notifications to browsers, messages to chat apps, endless services via webhooks, SMS messages, or even notifications in the WordPress admin area. Maybe it's time we get a really flexible API.
Most of the situations where WordPress sends an outgoing email can be classified as a notification. X just happened on your website and you should be aware of it. Back when WordPress was a youngster, the only way to reliably notify a user was via email. In 2016 we have many more options, including push notifications to mobile platforms, desktop notifications to browsers, messages to chat apps, endless services via webhooks, SMS messages, or even notifications in the WordPress admin area. The list goes on. For many users, email is no longer the optimal delivery mechanism for ephemeral notifications.
To that end, let’s think about replacing wp_mail() with a modern API that allows developers to route notifications to services other than email, allow them to better modify notifications and the way in which they’re formatted, and allow them to do so without stepping on each others’ toes.
The current lack of a notifications API (or even an email sending API) can be easily summed up:
Problem: Plugin A wants to provide HTML emails, and Plugin B wants to send emails via an email delivery service such as Mandrill. Plugin C wants to disregard emails and send Slack notifications.
The call is out for those interested in leading 4.8 and beyond releases. Release leads do not need to be developers!
WordPress 4.6 will be released in a couple of weeks, and Helen Hou-Sandí is preparing to lead 4.7, the final major release of 2016. With five months left in 2016, it’s time to start considering release leads for 2017. Giving release leads time to prepare is beneficial to the success of the release. It might seem advantageous to announce a year’s worth of release leads, but it puts the first and even second release lead at a disadvantage. Going forward, identifying and pre-announcing the next two release leads will help give them time to prepare. For example, at the start of the 4.8 cycle, both the 4.9 and 5.0 release leads should be confirmed.
Leading a release is a substantial time commitment. It blends aspects of being a product manager, project manager, engineering manager, and release manager. The release lead works across teams to ensure the success of the release. They are supported by the lead developers, permanent committers, and deputies of their choosing. Release leads do not need to be developers, but having experience contributing to WordPress is recommended.
Here’s how some previous release leads have described the role:
Leading a release of WordPress
It's that time again, when you can make your suggestions count, and dump your wishlist for WP 4.4 :)
Would like to see improvements in these areas: User profile screen.
To be make as post edit screen. Means we could add custom metaboxes, collapse metaboxes, use featured image in profiles (avatar ?), rearange drag and drop sections (metaboxes) in profile screen. Anyway WordPress would benefit tremendously if profiles worked similar way as post/pages.
User/Role dependent TinyMce settings. (as Drupal has long time ago)
Visual Editor in comments, maybe optional as one checkbox in settings.
Post/Page/Settings/etc.. Save and Close button. Saving close edit screen and redirect to the list.
Easy to adapt Dashboard.
Random Math captcha in the core for registration, login, comments. Forms can follow and use core code.
Default featured image fallback.
Put basic robots.txt in root.
Put Interconnect script for converting URLs in core folder, or implemented in settings. Dont know how other people do but I am using it 100%, on all websites. If this doesnt qualify as candidat for core, I dont know what would.
Number of revisions and Autosave interval as settings in backend.
Backend left sidebar auto adapting to longer menu item names, adapting middle area too.
One or two metaboxes of beer and collapsible
It almost looks like TwentySeventeen is getting into Page Builder Territory with its "Sections" feature built into the Customizer.
Here’s the summary for this week. The meeting was busy, so feel free to add anything missed in the comments. Housekeeping
Slack archive of meeting.
Meetings are every Friday at 18:00 UTC in #core-themes in Slack.
The major design implementation pull request was merged today.
discussed #37974 (Add multi-panel feature to pages through add_theme_support) for the majority of the meeting. The goal was to find a minimum viable product that could be developed in the time left.
decided to shoot for this feature to be 1. limited to the front page only. 2. exist in the Customizer 3. provide basic markup, created by Core.
decided this story board stood out as the strongest to be iterated on and mocked up as a design.
decided live preview in the Customizer wasn’t critical at the current time.
@helen and I will work on marshaling people to help with the project.
@karmatosed will work on the initial mock-up of the feature.
briefly discussed #38172 (Enable video headers in custom headers) It also needs to have a minimum viable product defined and those interested were encouraged to comment on the ticket with that in mind.
brought up #19627, and that could be worked on
Finally, the WP importer is getting some love! Major renovations have already been made. Download and play with it. Yay!
Hi, I’m Ryan McCue. You may remember me from such projects as the REST API. I’m here today to talk about something a bit different: the WordPress Importer. The WordPress Importer is key to a tonne of different workflows, and is one of the most used plugins on the repo.
Unfortunately, the Importer is also a bit unloved. After getting immensely frustrated at the Importer, I figured it was probably time we throw some attention at it. I’ve been working on fixing this with a new and improved Importer!
If you’re interested in checking out this new version of the Importer, grab it from GitHub. It’s still some way from release, but the vast majority of functionality is already in place. The plan is to eventually replace the existing Importer with this new version.
The key to these Importer improvements is rewriting the core processing, taking experience with the current Importer and building to fix those specific problems. This means fixing and improving a whole raft of problems:
Way less memory usage: Testing shows memory usage to import a 41MB WXR file is down from 132MB to 19MB (less than half the actual file size!). This means no more splitting files just to get them to import!