WordPress is web software you can use to create a beautiful website or blog. We like to say that WordPress is both free and priceless at the same time.
The core software is built by hundreds of community volunteers, and when you’re ready for more there are thousands of plugins and themes available to transform your site into almost anything you can imagine. Over 25 million people have chosen WordPress to power the place on the web they call “home” — we’d love you to join the family.
This release features a lightning fast redesigned linking workflow which makes it easy to link to your existing posts and pages, an admin bar so you’re never more than a click away from your most-used dashboard pages, a streamlined writing interface that hides many of the seldom-used panels by default to create a simpler and less intimidating writing experience for new bloggers (visit Screen Options in the top right to get old panels back), and a refreshed blue admin scheme available for selection under your personal options.
There’s a bucket of candy for developers as well, including our new Post Formats support which makes it easy for themes to create portable tumblelogs with different styling for different types of posts, new CMS capabilities like archive pages for custom content types, a new Network Admin, an overhaul of the import and export system, and the ability to perform advanced taxonomy and custom fields queries.
Hi everyone. The REST API team recently discovered a bug with parameter parsing in the API infrastructure, part of WordPress 4.4. For those of you using the API infrastructure, you need to be aware of a bug fix we’re making with the API.
The REST API has several types of parameters that it mixes together. These come from several sources including the request body as either JSON or URL-encoded form data ($_POST), query parameters ($_GET), the API route, and internally-set defaults. Unfortunately, due to an oversight on our behalf, these parameters can be inconsistently formatted.
In WordPress, the superglobal request variables ($_POST and $_GET) are “slashed”; effectively, turning magic quotes on for everyone. This was originally built into PHP as a feature to help guard against SQL injection, but was later removed. Due to compatibility concerns, WP cannot change this behaviour for the superglobals. This only applies to the PHP superglobals, not to other sources of input like a JSON body or parameters in the URL. It additionally does not apply to form data on PUT or DELETE requests.
Internally, some low-level WordPress functions expect slashed data. These functions internally callwp_unslash() on the data you pass in. This means input data from the superglobals can be passed in directly, but other data needs to be wrapped with a call to wp_slash().
When the REST API gathers the data sources, it accidentally mixes slashed and unslashed sources. This results in inconsistent behaviour of parameters based on their source. For example, data passed as a JSON body is unslashed, whereas data passed via form data in the body is slashed (for POST requests).