Video: How to Fix WordPress Not Sending Email Issue

WPBeginner - WordPress Tutorials originally appeared at http://www.youtube.com/watch?v=GhKSg5-FskM

Release Dry Run and Window, RC2 and String Freeze

Hey everyone!

The WordPress 4.5 release proceedings will start at April 12, 2016 at 0900 PDT, with the expectation of release within 2-3 hours of that meeting time. This time allows a decent margin before 5pm EDT (April 12, 2016 at 1400 PDT), at which point a punt to the next day would be discussed.

To help hit that window, let’s meet the day before at April 11, 2016 at 0900 PDT for a dry run.

As a final note, WordPress 4.5 RC2 has been released, and with it, hard string freeze is upon us.

See you at the dry run, and thanks for your help in getting this far!

Release Dry Run and Window, RC2 and String Freeze by Mike Schroder was originally posted at https://make.wordpress.org/core/2016/04/10/release-dry-run-and-window-rc2-and-string-freeze/

Dev Chat chat notes for April 6/March 30

This post summarizes the last two dev chat meetings.

March 30 meeting:

Review the full logs on Slack.

Schedule notes

• Currently in RC, 4.5 release planned for April 12 according to the schedule.
• Work on the About page progressing.
• Report on remaining tickets for the 4.5 release looking good.
• @jorbin noted that the WordPress 4.5 Field Guide was published.

Ticket review

• Discussion of the new link dialog and the removed ‘list of recent posts/search’ section that previously existing in the advanced modal (a regression). It was replaced with the easier inline search, but some users miss it; plan is to restore and rework for the modal.

April 6 meeting:

Review the full logs on Slack.

Schedule notes

• Release of WordPress 4.5 is scheduled for April 12.
• About screen nearly complete.
• Full string freeze by Saturday.

Ticket review

• The core dev team went thru remaining tickets for the 4.5 release to decide what should get committed and what should get pushed to a later release.
• Extensive discussion over the cropper and how to treat options passed by themes when setting up a theme logo.
• A data inconsistency bug affecting the WP-API was considered significant enough that it needed fixing.
• As we approach release and changes have less time to be tested, committers feel reluctant to make any changes.

Dev Chat chat notes for April 6/March 30 by Adam Silverstein was originally posted at https://make.wordpress.org/core/2016/04/07/dev-chat-chat-notes-for-april-6march-30/

Week in Core, Mar 29 – Mar 5 2016

Welcome back the latest issue of Week in Core, covering changes [37092-37160]. Here are the highlights:

• 69 commits
• 16 contributors
• 62 tickets created
• 7 tickets reopened
• 32 tickets closed
• Target release date for 4.5 is April 12th

Ticket numbers based on trac timeline for the period above.

Note: If you want to help write the next WordPress Core Weekly summary, check out the schedule over at make/docs and get in touch in the #core-weekly-update Slack channel.

Accessibility

• Improvements for the Editor wpLink modal form fields. [37160] #33301

Build/Test Tools

• Adjust unit tests to account for change in [37145].
• Adjust unit tests to account for change in [37144] [37150]
• Remove Debugging code introduced in [37145] [37148]
• Remove Debugging code introduced in [37146] [37147]

• Wrap the formatted comment text on the comment moderation screen in comment_text() so paragraphs and texturisation are applied. [37158] #34133

Customize

• Fix toggle of title attribute field visibility on nav menus admin page. [37153] #35273, #36353
• Put focus on change button instead of remove button in media control. [37152] #36337
• Respect aspect ratio on cropped images. [37113] #36318

Docs

• Ignore _wp_upload_dir_baseurl() from parsing for the Code Reference. [37114] #36371

Editor

• Remove trailing space from a help text string. [37159] #36407
• Restore the bottom half of the modal. Make it always expanded and remove the toggle. It is used as advanced link options now, no need to have simple mode. [37154] #36359

Embeds

• Improve how iframes are loaded after being initially hidden. [37093] #35894

General

• Add deprecated notice and removal warning to _wp_upload_dir_baseurl(). [37112] #36371
• Snoopy: use escapeshellarg instead of escapeshellcmd [37102-37094]

HTTP API

• Improve detection of valid IP addresses. [37123-37115]

I18N

• Clarify translator comment for an a11y label added in [36618]. [37155] #35111, #36396

Javascript

• Add nonce to AJAX action for script compression setting. Merges [37143] to the 4.4 branch [37144] [37143]

Networks and Sites

• Improve escaping in network settings.  [37132-37124]
• Validate new email address confirmations. [37111-37103]

Plugins

• Use correct placeholder for the number of reviews. [37156] #35111, #36395

Role/Capability

• Add create_sites and delete_sites to the list of capabilities that are checked as part of the comporehensive roles and capabilities tests. [37157] #32394, #36413

Taxonomy

• Make sure taxonomy functions work correctly with taxonomy names with special characters [37142-37136], [37134], [37133]

Themes

• Remove $size reference from get_custom_logo().  [37135] #36327

Upgrade/Install

• Add Nonce to updating wporg_favorites user meta field Merges [37145] to the 4.4 branch [37146] [37145]

Thanks to @adamsilverstein, @afercia, @azaozz, @dimadin, @DrewAPicture, @iseulde, @jeremyfelt, @johnbillion, @jorbin, @nbachiyski, @obenland, @ocean90, @sidati, @swissspidy, @TacoVerdo, and @westonruter for their contributions!

Week in Core, Mar 29 – Mar 5 2016 by Andrew Rockwell was originally posted at https://make.wordpress.org/core/2016/04/07/week-in-core-mar-29-mar-5-2016/

Outdated and Vulnerable WordPress and Drupal Versions May Have Contributed to the Panama Papers...

Here's a lesson from the Panama Papers that every business owner should learn. Don't leave your client data vulnerable because your website code wasn't kept up-to-date. http://wptavern.com/outdated-and-vulnerable-wordpress-and-drupal-versions-may-have-contributed-to-the-panama-papers-breach

Authorities have not yet identified the hacker behind the Panama Papers breach, nor have they isolated the exact attack vector. It is clear that Mossack Fonseca, the Panamanian law firm that protec…

Originally posted at The WP Guy - WordPress Web Design

REST API: Slashed Data in WordPress 4.4 and 4.5

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 Problem

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 call wp_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).

For example, the following two pieces of data are equivalent in the REST API:

// JSON body:
{"title": "Foo"}

// Form-data ($_POST)
title=Foo

// Both result in:
$request->get_param('title') === 'Foo';

However, if the data contains slashes itself, this will be inconsistently passed to the callback:

// JSON body:
{"title": "Foo\Bar"}

// Results in:
$request->get_param('title') === 'Foo\Bar';

// Form-data ($_POST) (%3D = "\")
title=Foo%3DBar

// Results in:
$request->get_param('title') === 'Foo\\Bar';

This means that callbacks need to understand where parameters come from in order to consistently handle them internally. Specifically:

• Data passed in the query string ($_GET, $request->get_query_params()) is slashed
• Data passed in the body as form-encoded ($_POST, $request->get_body_params()) is slashed for POST requests, and unslashed for PUT and DELETE requests.
• Data passed in the body as JSON-encoded ($request->get_json_params()) is unslashed.
• Data passed in the URL ($request->get_url_params()) is unslashed.
• Data passed as a default ($request->get_default_params()) is unslashed.

In addition, parameters set internally via $request->set_param() are unslashed. Unit and integration tests for API endpoints typically use these directly, so the majority of tested code (such as the WP REST API plugin) assumes parameters are unslashed.

See the related Trac Ticket #36419 for more information.

The Solution for WordPress 4.4 and 4.5

We are regarding inconsistently-slashed data as a major bug, and are changing the API infrastructure to ensure unslashed data. This will ensure that data is consistent regardless of the source. Callbacks will now receive unslashed data only, and can rely on this regardless of the original data source or request method.

If you are using functions that expect slashed data in your callback, you will need to slash your data before passing into these functions. Commonly used functions that expect slashed data are wp_insert_post, wp_update_post, update_post_meta, wp_insert_term, wp_insert_user, along with others. Before passing data into these functions, you must call wp_slash() on your data.

The fix for this issue, will be included in the WordPress 4.5 release candidates and final release. Due to the severity of the bug, we are also backporting the fix to the next minor WordPress 4.4 update. This also ensures you can update your plugins can act consistently across all versions of the REST API.

We understand that this may inadvertently break some plugins that are expecting slashed data. Right now, it’s not possible to consistently ensure that callbacks receive slashed data, so it is likely that these plugins will already break in some conditions.

tl;dr: if you’re using wp_insert_* or *_post_meta in your REST API callback, you need to ensure you are calling wp_slash() on data you are passing in, regardless of source.

We apologize for this bug existing in the first place. Slashed data is a problem that has plagued WordPress for a long time, and we’re not immune to getting caught by the issue ourselves.

REST API: Slashed Data in WordPress 4.4 and 4.5 by Ryan McCue was originally posted at https://make.wordpress.org/core/2016/04/06/rest-api-slashed-data-in-wordpress-4-4-and-4-5/

Road to 4.5: All Hands on Deck

We’re almost there! Release day is April 12.

In order to get there, help is needed to resolve the remaining issues in the report.

The regular dev meeting will be at April 6, 2016 at 20:00 UTC, where we’ll go over status, but the report should really be clear before then.

There are currently 11 tickets in the milestone, which with few exceptions need to be resolved so that we can ship an RC 2 this week in preparation for release next week.

We need all hands on deck — especially if you are a component maintainer or committer, but all eyes appreciated. Please watch the milestone for tickets you can suggest remedies for or whose patches you can review.

In particular, the help of lead developers and permanent committers is requested, because without approval from two of you for each patch, we cannot move forward with committing fixes. Thanks to those of you who have been doing reviews!

Tickets with a patch and single sign-off in need of a second are:

• #34133 – Selective Refresh: Make sure refresh transport is used only when appropriate.
• #36389 – Moderate Comments: Pass through comment_text().
• #36407 – I18n: Remove an extra space.

Needs testing and double sign-off:

• #36380 – Moderate Comments: Show link URLs to avoid abuse.

Needs patch:

• #36412 – Custom Logo: Can’t skip crop for images smaller than specified in theme.
• #36392 – Script Loader: wp_add_inline_script() breaks script dependency order.
• #36173 – About Page: Needs commit with final strings by Wednesday. Draft design & strings attached for review.

Can ride:

• #36354 – Bump core themes versions prior to release.
• #36401 – Bump Akismet for 4.5.
• #36413 – Additional tests for roles/caps
• #35857 – Additional tests for customizer/selective refresh

Thanks for your help in getting us through the final stretch.

Road to 4.5: All Hands on Deck by Mike Schroder was originally posted at https://make.wordpress.org/core/2016/04/04/road-to-4-5-all-hands-on-deck/

Editor chat 4.6

This Wednesday, 6 April, 18:00 UTC we’ll have our weekly editor chat. This time we’d like to discuss the roadmap and ideas for 4.6, so please join us if you can and are interested in pushing the editor forward. If you can’t attend feel free to comment here, or on the summary of the chat that we will post on this blog afterwards.

Editor chat 4.6 by Ella Iseulde Van Dorpe was originally posted at https://make.wordpress.org/core/2016/04/04/editor-chat-4-6/

Video: How to Display Your WordPress Posts in a Grid Layout

WPBeginner - WordPress Tutorials originally appeared at http://www.youtube.com/watch?v=PDnt6mGZfpc

WP REST API: 2.0 Beta 13 & Roadmap

Hi folks! I’m here with another exciting update from the API team.

Beta 13

First off, we’re excited to announce 2.0 Beta 13 “yoink.adios\losers” is now available. Grab it from the plugins repo or GitHub while it’s hot. Here’s some of the key updates:

• BREAKING CHANGE: Fix Content-Disposition header parsing. This technically breaks backwards compatibility to correctly match the header specification. (#2239)

• BREAKING CHANGE: Use compact links for embedded responses if they are available. We now use CURIEs for sites on 4.5+, which look like wp:term (but canonicalise to the full URI relation). (#2412)

• Updated JS client to the latest version. (#2403)

There’s lots more changes in this release; check out the release notes or the commits for this release.

Roadmap

We’ve been thinking about how to tackle the API in the coming future. We want to do the most we can to ensure you can build sites with confidence.

Along these lines, we’re going to release a 2.0 final version in the coming months. This will be a completely stable release with guaranteed backwards compatibility for the foreseeable future. This backwards compatibility ensures that your sites can remain up-to-date with minimal maintenance or issues with upgrading.

We originally held the software in beta for a long period to ensure that breaking changes could be rolled in if deemed necessary to move the project forward. However, the majority of these breaks occurred at the start of the 2.0 lifecycle, and the API is mostly stable at this point. Keeping the ability to break compatibility benefits only us, whereas moving to a stable release benefits everyone.

Moving forward, version 2.0 of the WP REST API will follow a normal project release cycle. We will have minor releases in the 2.x series as new features are added, and bugfix releases in the 2.0.x series.

As for the core merge itself, we are not submitting a merge proposal of the core endpoints for WordPress 4.6. We believe endpoints for the main WordPress objects (posts, users, comments, terms, and taxonomies) are not enough to garner the support needed for the proposal to be accepted. Our hope is that with a stable version 2.0 release, we will attract our community members that have been waiting for the endpoints to be available in core, and submit a merge proposal for the WordPress 4.7 release cycle.

In addition to attracting more developers within our community, we are also looking to get more contributors involved with the project. As noted in previous discussions, the four of us on the API team can’t keep pace with WordPress itself without help. We’re looking to get WordPress core component maintainers involved in their relevant components, as well as new developers from outside the project. Moving forward, the API team sees our role as advisory over the API itself, with the API treated as an integral part of the component rather than maintained by a separate team. We’re also going to continue to work on our feature plugins (metadata, site/multisite, menus/widgets, and authentication) in parallel, and are looking for help on these as well. (There’s also more news regarding authentication coming very soon.)

If you’d like to get involved with the API, please let us know. You can comment here, ping us on Slack in the #core-restapi room, or via GitHub issues. We’re looking at spending significant time onboarding new users, so if you’d like to get involved, now’s the time! Our weekly meeting is at Monday 23:00 UTC

Thanks for catching up with us, and have a wonderful day.

With love,

Ryan, Rachel, Daniel, and Joe

WP REST API: 2.0 Beta 13 & Roadmap by Ryan McCue was originally posted at https://make.wordpress.org/core/2016/04/04/wp-rest-api-2-0-beta-13-roadmap/