Video: How to Install a WordPress Plugin for Beginners

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

How to Add Google Analytics to AMP Pages in Wordpress

How to prevent AMP from stripping out your Google Analytics code... http://www.thesempost.com/how-to-add-google-analytics-to-amp-pages-in-wordpress/

If you have implemented the official AMP plugin for WordPress, you have probably discovered that the plugin strips out the Google Analytics code from all AMP pages. But even though the plugin strips it out, AMP pages will still validate with Google Analytics code, but you need to add it manually. F…

Originally posted at The WP Guy - WordPress Web Design

Core Dev chat notes for Feb 24

Agenda

Schedule, Beta.

Schedule

Reminder of the 4.5 release schedule:

• Beta 1 today (Feb 24th).
• RC1 on March 23rd.
• 4.5 release on April 12th.

Beta

• @mike wanted to discuss Theme Logo Support (#33755). It’s a big feature that still hasn’t landed. Discussion of a more generalized API for theme images as a long term goal. @obenland will put together a commit for a first run.
• Reviewed the six enhancements that were left in the 4.5 milestone:
  • Improve default Imagick compression settings (#33642) @mike putting together a first run commit.
  • Permit sticky posts to affect the query in REST_REQUEST (#35907). @jorbin to commit committed.
  • Include auto-discovery header on REST responses (#35580) possibly punting.
  • Add filters to allow creating REST API middleware plugins (#35590) possibly punting.
  • Include a refreshed nonce when responding to an authenticated REST API response (#35662)  possibly punting.
  • Provide an “Edit user” link after adding a new user to a site or network (#35705) – @jeremyfelt will commit committed.
• Discussion around what items should be in the 4.5 Beta 1 release announcement.

Full logs on slack.

Core Dev chat notes for Feb 24 by Adam Silverstein was originally posted at https://make.wordpress.org/core/2016/02/24/core-dev-chat-notes-for-feb-24/

Week in Core, Feb. 16-23 2016

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

• 131 commits
• 82 contributors
• 89 tickets created
• 9 tickets reopened
• 140 tickets closed

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.

Code Changes

Accessibility

• Improve the color contrast ratio for the input placeholders. [36619] #35777
• Remove title attributes from the Plugin details modal. [36618] #35111
• Remove the revisions limit warning from the Publish box. [36612] #35029
• Fix displaying of Universal time and Local time info on the General Settings screen. [36585] #35064
• Improve color contrast updating any #999 gray used for text or icons to a darker gray. [36587] #35660
• Accessibility: after [36000] conditionally print out the aria-describedby attribute on the Featured Image postbox. [36584] #35076
• Accessibility: Reduce the WordPress shades of grey, Episode 2. [36582] #35783

Administration

• Replace the custom comment form with comment_form() and reduce number of links. [36595] #35888
• Remove extra spaces between function names and brackets [36572] #16774, #34365
• Remove slashes from search terms and use urldecode() in non-URL contexts. [36560] #35712

Authentication

• Allow users to log in using their email address. [36617] #9568

Autosave

• Do not strip slashes from the whole &_POST when doing autosaves. [36543] #35408

Bootstrap/Load

• Don’t display errors during Ajax requests. [36571] #34915, #23811, #26262
• Make $wp_local_package explicitly global in wp-settings.php. [36557] #34975

Build/Test Tools

• Add Tests_dbDelta::assertTableHasPrimaryKey(). [36552] #34877
• Add a test for testing wp_enqueue_script() with an alias handle in the footer. [36559] #35643
• Test that jQuery can be moved into footer after [36550]. [36596] #25247
• Add test for wp_get_installed_translations(). [36563] #35284

Comments

• Rename $linea to $remote_source for clarity. Add remote_source to comment data, so it’s available to preprocess_comment and comment_post filters. Pass the original (unfiltered) response source to the filters too (as remote_source_original in comment data). [36661] #34141
• Pass comment data to the comment_post filter. [36660] #34141
• Look for wp_error when checking whether $wpdb->get_col_length() has failed. [36542] #10377
• Refresh the Moderate Comment screen for a friendlier experience with email moderation actions. [36588] #34133

Customize

• Let WP_Customize_Selective_Refresh class be final to match manager and other component classes. [36624] #27355
• Ensure dynamic_sidebar() finishes with removing the sidebar ID from the current_dynamic_sidebar_id_stack. [36623] #27355
• Prevent dropping backslashes from input on general settings and settings for nav menus and some widgets. [36622] #35898
• Fix and extend broken ajax unit tests to account for partials being skipped from rendering. [36650] #35914
• Skip exporting partials to client and handling rendering requests if user can’t modify associated settings. [36643] #27355, #35914
• Add visual feedback to reorder buttons. [36641] #35041
• Contain “No image set/selected” in dashed border. [36639] #35826
• Update unit test for WP_Customize_Nav_Menu_Item_Setting::value_as_wp_post_nav_menu_item() to account for slashing if user can’t unfiltered_html. [36610] #35869
• Prevent PHP notice and JS error caused by widgets and nav menus components if user only has customize capability. [36611] #35895
• Fix previewing and updating of nav menu items containing slashed/slashable characters. [36608] #35869
• Fix “Loading…” message from persisting in panel title when user does not have manage_options cap to edit blogname. [36606] #35579
• Add selective refresh framework with implementation for widgets and re-implementation for nav menus. [36586] #27355
• Prevent consecutive refresh requests from preview from causing JS error. [36583] #27355, #35866
• In nav menus show the location name instead of slug. [36573] #34755
• Add missing test changes for [36573]. [36574] #34755
• Autoprefixer for [36532]. [36548] #31195

Docs

• Correct $number type in number_format_i18n(). [36644] #35893
• Update the type for $callback parameters to callable in DocBlocks for add_settings_section() and add_settings_field(). [36642] #35772
• Improve documentation for WP_REST_Request to highlight a caveat of ArrayAccess when it comes to passing similar arguments for multiple request methods. [36636] #35799
• Improve description of get_term() return value. [36634] #35919
• Correct param types on some filters in wp_filter_comment(). [36626] #35908
• WP_Meta_Query accepts ‘EXISTS’ or ‘NOT EXISTS’ for $compare. [36609] #35891
• Fix two incorrect notations of the $show_admin_bar global to specify a boolean type, not WP_Admin_Bar. [36601] #35686
• Add missing @since and @access tags to get_curies method and filter from r36533 [36593] #34729, #32246
• Add an explanation for the dynamic portion of the {$taxonomy}_term_edit_form_top hook, introduced in [36526]. [36577] #32246
• Add formatting to a changelog entry in the hook doc for the rest_dispatch_request filter. [36576] #32246
• Remove a duplicate @static tag from the WP_Customize_Panel->instance_count property DocBlock. [36568] #32246

Embeds

• Only display an iframe when it was successfully loaded. This prevents showing a blank iframe by first checking if a message was successfully received from it. [36648] #35894
• Make the click event handler work for dynamically added links. [36637] #35630
• Load the default site icon from the wp-includes directory. [36635] #35322

External Libraries

• Update Backbone and Underscore to the latest versions. [36546] #34350

Feeds

• Make Custom Taxonomy Feeds Auto-discoverable [36671] #23677

Formatting

• Avoid a PHP warning when wptexturize() is called with a trailing less-than symbol. [36578] #35864

Help/About

• Remove unused strings. [36554] #34909

HTTP API

• Certificate bundle: Attempt to move a certificate lower in the file to allow older OpenSSL versions to parse it & communicate with WordPress.org securely again. The OpenSSL version which was failing in this case was OpenSSL 0.9.8e 23 Feb 2007. [36570] #35637, #30434, #25007

I18N

• Add translator comments and context to “New Site Created” email notification strings. [36669] #35716
• Replace hardcoded URL in a translatable string with a placeholder in wp-admin/upload.php. [36668] #35743
• Add missing periods to two strings in wp-admin/network/sites.php [36664] #35720
• Add translators comments to wp-admin/users.php. [36621] #35885
• Remove HTML tags from translatable strings in wp-admin/plugins.php. [36662] #35679
• Add the ability to parse a whole directory with add-textdomain.php. [36600] #35499
• Remove PHP4 constructor from add-textdomain.php. [36599] #31982
• Add test for wp_dropdown_languages(). [36631] #35294
• Respect the coding standards when adding textdomains with add-textdomain.php. [36603] #21616
• Remove tag from translatable string in wp-admin/includes/class-wp-filesystem-ssh2.php. [36670] #35741
• Remove tag from translatable string in wp-admin/includes/class-wp-ms-sites-list-table.php. [36663] #35676
• Remove tag from translatable string in wp-admin/theme-install.php. [36666] #35739
• Remove tag from translatable string in wp-admin/options-general.php. [36656] #35673
• Remove tags from translatable strings in wp-admin/install.php. [36665] #35738
• Remove tags from translatable strings in wp-admin/custom-header.php. [36658] #35675
• Remove tags from translatable strings in wp-admin/themes.php. [36657] #35745
• Remove tag from translatable string in wp-admin/user-edit.php. [36655] #35672
• Remove tag from translatable string in wp-admin/import.php. [36653] #35671

Media

• Update unit tests after change to default image quality. [36616] #33642
• Reduce default image compression quality to ’82’. [36615] #33642
• After [36546] restore the “Add new” functionality. [36575] #34350, #35853

Menus

• Ensure backslashes are saved in menu item fields. [36613] #14134

Multisite

• Make view mode sticky for network users and sites list tables. [36562] #34365
• Avoid a PHP Notice when saving a site address without a path. [36561] #35631

Performance

• In wp_upload_dir() do not cache error from wp_mkdir_p() when a directory cannot be created. Keep trying to create the dirs. This happens mostly in file upload context. [36628] #34359
• Replace wp_upload_dir() with the new wp_get_upload_dir() in all cases where a file is not being uploaded. Deprecate _wp_upload_dir_baseurl(), and replace it with wp_get_upload_dir(). [36569] #34359
• Reintroduce term meta unit test accidentally removed in [36566]. [36567]
• More performance improvements to metadata lazyloading. [36566] #35816
• Improve the performance of wp_upload_dir(): [36565] #34359

Plugins

• Remove an unused variable after [35953]. [36581] #35050

Posts

• Introduce get_post_types_by_support(). Similar to get_post_types(), this new function returns a list of post type names that support a specific feature. [36652] #34010
• Non-trashed posts should take slug priority over trashed posts. [36607] #11863

Query

• Search should match post_excerpt in addition to title and content. When ordering search results, exact matches in the post excerpt are weighted above those in post content, but below those in the post title. [36647] #35762
• Allow a seed value to be passed when using ‘rand’ $orderby. [36632] #35692
• In WP::handle_404() introduce a filter pre_handle_404 to short-circuit default header status handling. [36629] #10722
• is_*( $int ) should not falsely match strings starting with “$int”. [36625] #24674, #35902

Revisions

• Clean up _wp_post_revision_fields() [36659] #13382

Schema

• Add an index to wp_users.user_email. [36654] #9568, #33376

Script Loader

• Don’t parse $src if the current color scheme isn’t registered. [36591] #35882
• Pass the media attribute as an argument to the style_loader_tag filter. [36592] #34765
• Bail if WP_Styles::_css_href() returns an empty value. [36590] #35229
• Make sure that inline styles for handles without a source are printed. [36550] #35229
• JSHint for [36602]. [36605] #33301
• Fix missing script output when the groups of dependencies are different. [36604] #35873
• Introduce wp_add_inline_script(). [36633] #14853
• Restore loading order for wp-admin: open-sans, dashicons, etc. [36551] #35229

Styles

• Clarify the allowed values for the $media parameter of wp_register_style()/wp_enqueue_style(). [36649] #35921

Taxonomy

• Make $taxonomy parameter optional in get_edit_term_link(). [36646] #35922
• Allow get_terms() to fetch terms regardless of taxonomy. [36614] #35495
• In get_terms(), assemble WHERE conditions in an array instead of concatenating. [36598] #35495
• Add changelog entry for publicly_queryable argument in register_taxonomy(). [36564] #34491

Template

• Update label for the username field in wp_login_form() after [36617]. [36620] #9568

Themes

• After [36546] restore theme search functionality. [36580] #34350
• Fix flickering of the theme screenshot on hover in WebKit browsers. [36579] #35787
• Improve error messages for broken themes. [36638] #35286

TinyMCE

• Inline text patterns [36627] #33300
• Fix the regex that removes spaces from empty paragraphs. Was causing problems when wpautop is disabled and there are many U+00A0 chars between the opening “ and an inline tag. These chars are inserted by the browsers to maintain consecutive spaces typed by the users in contentEditable. [36597] #35890
• Update to 4.3.4. Changelog: https://github.com/tinymce/tinymce/blob/master/changelog.txt. [36589] #35876
• Create and edit links inline. [36602] #33301

Updates

• Pass locales of all available languages to the themes/plugins update API. [36630] #34937

Upgrade/Install

• Prevent further actions if an update button is disabled. [36558] #35257
• Add a hook to the end of the network’s Add New User form. [36556] #15389
• Add a hook to the end of the Add Site form. [36555] #34739
• Enhance the language of the “Success” message. [36553] #34897
• Improve wording on the page for the database connection details. [36545] #26879
• Use “Username” instead of “User Name”. [36544] #35850

Users

• Pass the array of user IDs being deleted to the delete_user_form action hook in two places. [36640] #35063
• Introduce _wp_get_current_user() for improved backward compatibility. [36651] #19615

Widgets

• Avoid a PHP notice in is_dynamic_sidebar() is a sidebar is registered but does not yet have an index in the sidebars_widgets option. [36667] #35928

Props

Thanks to @dnewton,@joemcgill, @abiralneupane, @adamsilverstein, @afercia, @aidanlane, @Ankit, @apaliku, @atimmer, @azaozz, @barryceelen, @boonebgorges, @charlestonsw, @chris_dev, @ckoerner, @coffee2code, @coreymcollins, @danielbachhuber, @dd32, @Denis-de-Bernardy, @dlh, @DrewAPicture, @dshanske, @ericlewis, @ethitter, @flixos90, @GaryJ, @gitlost, @groovecoder, @Gupta, @hakre, @helen, @hlashbrooke, @iamntz, @igmoweb, @iseulde, @JamesDiGioia, @jdgrimes, @jeremyfelt, @JoeFusco, @joehoyle, @johnbillion, @jorbin, @K, @karmatosed, @kjbenk, @kovshenin, @lpawlik, @mayukojpn, @mdgl, @meitar, @melchoyce, @MikeHansenMe, @mikejolley, @mikeschroder, @netweb, @nicd, @ocean90, @pento, @prettyboymp, @ptahdunbar, @rachelbaker, @ramiy, @realloc, @ryan, @ryankienstra, @salcode, @sc0ttkclark, @sebastianpisula, @SergeyBiryukov, @stevegrunwell, @stevenkword, @swissspidy, @thewanderingbrit, @thisisit, @usermrpapa, @valendesigns, @vhomenko, @welcher, @westonruter, @williamsba1, and @wpsmith for their contributions! for their contributions!

Week in Core, Feb. 16-23 2016 by Andrew Rockwell was originally posted at https://make.wordpress.org/core/2016/02/24/week-in-core-feb-16-23-2016/

Theme Logo Support

It’s been proposed that we add Theme Logo Support to core for 4.5. This would allow themes to declare support for a logo, which would be customizable via … the customizer! Let’s walk through some background, and how this would work.

Theme Logo Support was kindly ported over to core from Jetpack’s “Site Logo” feature by sir @obenland on #33755, with much assistance from others in getting it core-ready ( ).

In core, it’d be a theme mod enabled via add_theme_support( 'site-logo', size ), rather than storing the logo persistently across themes. This is for a few reasons:

• Customizer controls should only be visible when a feature is supported by the theme.
• Prevent plugins from using a “global” logo when the Customizer controls may not be visible
• Prevent poor display of logos that looked good on one theme, but whose size is not appropriate for another theme’s declared size.

The plan would be to ship a new version of Twenty Sixteen (thanks @karmatosed, @iamtakashi!) that supports this feature along with 4.5, as an example to other themes for implementation.

This would allow a common theme feature, logos, to have a common implementation provided by core and available in a consistent location for users.

There were user tests performed by @karmatosed, on make/flow, which showed confusion with customizer discoverability, but were generally positive in users being able to tell the difference between the Logo feature and a Site Icon.

@boren also has a running set of flow screenshots that you can look through, with the newest ones on iPhone, and the screenshot above reflecting the most recent patch.

To test this, apply the most recent patch on #33755, and install the Twenty Sixteen theme found in the site-logo branch.

Let me know what you think!

Theme Logo Support by Mike Schroder was originally posted at https://make.wordpress.org/core/2016/02/24/theme-logo-support/

4.5 Enhancements Scrub

4.5 beta 1 is scheduled to be released tomorrow. To help facilitate it, we are going to have a scrub VERY SOON of the open enhancements (this list needs to be zero before tomorrow). At 7pm EST today (aka, about 2 hours from this being published), join the #core room on slack to help scrub this list down to nothing.

4.5 Enhancements Scrub by Aaron Jorbin was originally posted at https://make.wordpress.org/core/2016/02/23/4-5-enhancements-scrub/

REST API Authentication

On Thursday of last week, we had an Authentication chat in #core-passwords — truth be told, the discussion spilled over into Friday and a bit on Saturday as well. I delayed posting this summary a bit to make sure there wasn’t anything else about to be said that I’d miss.

Spoiler alert: we didn’t decide anything conclusively, it was more brainstorming and voicing possibilities.

Also worth noting is that we place equal weight on the user experience of the authentication system as we do on the security when evaluating it for core. That isn’t to say that we value the security any less, but rather that we also view the UX as critical to nail down as well, and is likely easier to suss out problems earlier on in casual conversation than evaluating the eccentricities of crypto. So if some of the discussion tended more towards UX considerations than Security considerations, be aware that both are critical, we were just tending to evaluate the UX first, as it’s an easy litmus test for whether a particular method is worth pursuing, and more easily understood by more people than the intricacies of replay attacks and the sort.

There were two major areas of discourse that were addressed: Authentication Scheme, and Authentication Scope.

Authentication Scheme

The scheme would be one of several possibilities, such as OAuth 1.0a, OAuth 2, Application Passwords sent as Basic Authentication, or some other either ad-hoc or previously unconsidered system.

There are assorted concerns with various systems:

• HTTPS — WordPress cannot guarantee that the site will be hosted on a HTTPS infastructure, and as such, any API tokens passed along with the request could potentially be sniffed in transit. However, if the site doesn’t have HTTPS available, the same thing happens on every page you view already with your authentication cookies. The major difference being that cookies become invalidated on logout or expiration, so cookie thieves have a smaller window to exploit the stolen authentication than tokens that are valid until revoked.

• OAuth Application Registration — The user experience flow for OAuth can be particularly tricky. Imagine it: You’ve just installed an app on your phone, and you want to link it to your user account on your WordPress site. Your steps are as follows: Log in to your WordPress site, Create an AppID for the phone app, give the phone app it’s Secret tokens. Now from the Phone app, you click a button to go back to your site and approve the link to your user in the application and exchange user access tokens. That is a /lot/ of back and forth-ing. It could be simplified somewhat if there was some sort of central repository for all WordPress sites that apps could register at, and then .org sites could dynamically pull down public keys for applications that they can use to verify the secrets in the apps, but that then becomes a significant amount of overhead for the construction and maintenance of the application ‘clearing house’ and it’s been clarified that it is not something that WordPress.org (the website) is up to build or host. Long story short: this UX flow is so confusing that it really feels much more like plugin territory at its current iteration.

Probably some other points I’m missing, but those felt like the major two.

Authentication Scope

The second issue at hand is one of Authentication Scope. That is, when an application authenticates, what functionality is it permitted to do?

This is significantly different from user capabilities. We had discussed an extra field when auth’ing applications where you could ‘downgrade’ your user role for that application’s API requests (that is, if you’re an Administrator, you could only give an application Author capabilties), but that doesn’t really solve the issue — as every user role has the ability to — for example — update their password or email address. And if an application can do that, then that’s the ballgame, and they can log in to wp-admin as you and do whatever they like.

We also talked about perhaps just disallowing certain functionality from ever being used as a part of the REST API. However, with the rise of third-party site management applications, such as Calypso, or if other programs like ManageWP or InfiniteWP or whatever the other half dozen ones are wants to truly manage your site, they’ll need access to that functionality. After all, what’s the point of aiming at eventually achieving REST API parity with the wp-admin experience if it can’t be used anywhere outside of wp-admin?

The solution we seemed to be leaning towards is a ‘two-tiered’ scope system. That is, provide a default ‘content’ tier — akin to the functionality of the legacy XML-RPC API — that can support writing and updating posts, taxonomies, comments and the like (and any custom endpoints that are explicitly opted in to the limited tier), and a second ‘full control’ tier that allows access to everything — plugins, themes, users, what have you. The second tier would be suited for full control applications like Calypso or remote management tools, whereas the first more limited tier would be more than adequate for the functionality in the legacy WordPress mobile apps, or blogging applications like Desk or Microsoft Word integration. It’s simple enough for users to understand, and technologically could be passed in via the `$args` array to `register_rest_route()` whether an endpoint should be available or not.

—

Still with us? Thanks for slogging through a somewhat lengthy summary, we’d love to hear your thoughts below on anything you think we missed or didn’t consider sufficiently in depth.

If anyone would like to read the full discussion, it starts here in the Slack logs: https://wordpress.slack.com/archives/core-passwords/p1455832859000040

REST API Authentication by George Stephanis was originally posted at https://make.wordpress.org/core/2016/02/23/rest-api-authentication/

Video: How to Install Facebook Remarketing Retargeting Pixel in WordPress

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

Proposal: Increase the default image compression in WordPress

In order to improve page load performance, I propose that the default image compression setting be changed from 90 to 82 in WordPress. Let’s get into why.

Background

The default quality setting for resized images in WordPress has been 90 since the image_resize() function was shipped in version 2.5. This setting creates images with much larger file sizes than recommended by modern web best practices.

Over the past several years, the importance of performance has been highlighted as users access the web globally on slower connections, and performance has even started being used by search engines to influence search results.

Tools like Google PageSpeed Insights and WebPagetest will warn site owners if images aren’t sufficiently compressed. For example, the glossary at the bottom of the WebPagetest performance optimization page states:

Within 10% of a photoshop quality 50 will pass, up to 50% larger will warn and anything larger than that will fail. The overall score is the percentage of image bytes that can be saved by re-compressing the images.

Research

With this in mind, web developer and performance advocate Dave Newton published recommendations for ImageMagick compression settings based on his research comparing various ImageMagick settings against Photoshop’s ‘high quality’ (60) setting for JPEGs. He found that an Imagick compression setting of 82 was closest to this using an objective measurement named DSSIM to compare the visual similarity between two images.

We experimented with Dave’s settings in the RICG Responsive Images plugin during the 4.3 cycle and found that not all Dave’s suggestions can be easily applied by default in WordPress due to the memory required to process large images on shared hosts. However, changing the default image quality setting is a relatively small change that makes a big impact on file size without sacrificing much in the way of perceived image quality.

In research released in 2014, compressed images with a DSSIM score of 0.015 were deemed acceptable to most people. In tests of several different images, I found that changing the default compression setting in WP_Image_Editor from 90 to 82 reduced image sizes by an average of ~25% with DSSIM scores ranging from 0.0014 to 0.0019 for ImageMagick and 0.0019 to 0.0023 for GD — both of which are drastically under the 0.015 threshold cited above.

Proposal

Given these results, I suggest making the change to 82 for the default image compression setting. You can follow the discussion on the related ticket (33642) and give feedback in the comments or in the #core-images channel on Slack.

As a reminder, this setting only applies to the intermediate sizes that WordPress creates, and not the original files uploaded by users. For any users who need to maintain a higher image quality for intermediate sizes, the default quality can still be changed with the wp_editor_set_quality filter.

Proposal: Increase the default image compression in WordPress by Joe McGill was originally posted at https://make.wordpress.org/core/2016/02/22/proposal-increase-the-default-image-compression-in-wordpress/

To trust or not to trust: Small business survey hails WordPress, dings Yelp - Greensboro - Triad...

Interesting numbers. And #WordPress is at the top! #smallbusiness #smb http://www.bizjournals.com/triad/blog/morning-edition/2016/02/alignable-survey-smb-trust-q4-2015-yelp-wordpress.html

For small-business owners, WordPress is a well-trusted company, Yelp is a brand in trouble, and Facebook is on a downward path.

Originally posted at The WP Guy - WordPress Web Design

PHP Unit Test Meeting on Feb. 26th

We met last week to discuss PHP unit testing, and will meet again on February 26th 7PM UTC in #core on Slack to continue the conversation.

Our general goal here is to make writing unit tests easier through documentation. If you’re interested, join!

PHP Unit Test Meeting on Feb. 26th by Eric Andrew Lewis was originally posted at https://make.wordpress.org/core/2016/02/19/php-unit-test-meeting-on-feb-26th/

WordPress joins movement toward HTTPS encryption

In case you are wondering, the proposed change to add HTTPS to WordPress core doesn't mean that your self-hosted site won't still need a dedicated IP address with an SSL certificate. Both of those are necessary if you want a secure site for transactions. HTTPS will also help your site rank better for SEO purposes over competitors who do not have encrypted sites. If you need help or have any questions, I am just a phone call away. http://www.csmonitor.com/World/Passcode/2016/0217/WordPress-joins-movement-toward-HTTPS-encryption

Popular blogging platform WordPress is the latest in a growing number of sites that are enabling website encryption to protect their users.

Originally posted at The WP Guy - WordPress Web Design

Core Dev chat notes for Feb 17

Agenda

Schedule Notes, Status Updates, Open Floor

Schedule Notes

• Today is the feature plugin merge deadline!
• Customizer Responsive Preview was merged. Thanks to everyone who helped out there!
• The first beta is scheduled for release next week! This means that any remaining features/enhancements need to land before then.
• @chriscct7 has been leading daily scrubs of these tickets; ticket owners should post an updates on the ticket status.

Status Updates

• Image Improvements: @joemcgill
  • Improving the performance of wp_uploads_dir() (#34359). @azaozz committed this and left the ticket open for possible function name changes or additional tests.
  • PDF Thumbnails (#31050) are close. Creates a thumbnail version of uploaded PDFs. Feedback would be welcome, particularly from UI focused folks and around how the PDF thumbs’ meta is stored. This needs careful consideration as it would be a model for any other thumbnails for non-image types. The intent for this release is to improve the editor experience a bit, which the thumbnails would achieve.
  • Improving default image compression (#33642): Looks like we should be able to reduce the default compression quality and see big improvements in file sizes without a perceptible loss in image quality. Look for a blog post requesting feedback later this week to make sure core is ok with changing the default quality for intermediate sizes.
• Customizer: @westonruter, @celloexpressions
  • Published a post on Make Core that detailed Selective Refresh in the Customizer. Hoping to get feedback on the implementation for nav menus and widget, on the framework for theme/plugin authors to register their own partials for selective refresh, and also for a general code audit for security and docs. In the process right now of creating that core patch and will attach to the ticket #27355. I’m also in the middle of writing unit tests, but help there would be appreciated.
• Multisite/WP_Site: @jeremyfelt
  • No big updates. Started making progress on a few tickets today. Nothing negative or breaking with the new `WP_Site`, though we’ll continue to keep testing and looking for ways to improve. @spacedmonkey has also submitted a ticket for `WP_Site_Query` which will be fun.
• Editor: @azaozz, @iseulde
  • Thinking and testing if the inline link dialog should have two fields, URL and link text, like the modal. Seems the more streamlined version with just the URL is better.
  • Another change that’s coming is to add autocomplete to the modal instead of the infinite scroll at the bottom. That gives plugins some more space to add additional “advanced” settings and simplifies it/makes it consistent with the inline dialog.

Open Floor

• @mike Wanted to discuss Theme Logo Support (#33755).  @obenland was kind enough to do a port of the feature from Jetpack, and there’s been good conversation happening on the ticket. It needs testing. Can be tested with Twentysixteen and a patch and with any theme that supports Jetpack site logos. Needs work on this suggestion.
• @ocean90 raised Unifying permission error messages (#34521). Right now we use a variety of  language for error messages and this ticket is about unifying and clarifying that language. @ocean90 asked for opinions about the best language to inform users they are not allowed to perform some action. Extensive discussion ensued and Sorry, you are not allowed to… seemed to be the top choice.

Full meeting log available in Slack.

 

Core Dev chat notes for Feb 17 by Adam Silverstein was originally posted at https://make.wordpress.org/core/2016/02/18/core-dev-chat-notes-for-feb-17/

Backbone and Underscore updated to latest versions

WordPress trunk upgrades Backbone and Underscore to the latest versions (they were last updated two years ago in [27233]). Backbone is upgraded from 1.1.2 to 1.2.3 and Underscore is upgraded from 1.6.0 to 1.8.3; see #34350 and [36546].

The new versions of Backbone and Underscore offer numerous small bug fixes, some optimizations and some small improvements. Check the Backbone changelog and Underscore changelog for the full details.

The upgraded versions include some changes that may break existing code.

Plugins or themes that rely on the bundled Backbone and/or Underscore libraries should carefully check functionality with the latest versions and run any available unit tests to ensure compatibility.

Some changes of note that were addressed in core as part of this upgrade:

• _.flatten no longer works with objects since Underscore.js 1.7. _.flatten() working with objects was an unintended side-affect of the implementation, see underscore#1904. Check any _flatten usage and only flatten arrays.
• As of Backbone 1.2.0, you can no longer modify the events hash or your view’s el property in initialize, so don’t try to modify them there.
• Since Underscore 1.7, Underscore templates no longer accept an initial data object. _.template always returns a function now so make sure you use it that way.

 

Backbone and Underscore updated to latest versions by Adam Silverstein was originally posted at https://make.wordpress.org/core/2016/02/17/backbone-and-underscore-updated-to-latest-versions/

Week in Core, Feb. 9-16 2016

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

• 35 commits
• 37 contributors
• 67 tickets created
• 3 tickets reopened
• 52 tickets closed

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.

Code Changes

Accessibility

• Reduce the WordPress shades of grey, first part. [36537] #35783
• Improve the color contrast ratio for the TinyMCE button icons. Also, tries to use the new grays from the Design Handbook wherever applicable. [36528] #35604

Build/Test Tools

• Make sure fixtures have empty post_content in search test. Introduced in [36278]. [36520] #3102
• Improve Automated Feed Tests [36519] #35160
• Unit test for wp_get_comment_fields_max_lengths(). This adds tests for the comment form field lengths returned by wp_get_comment_fields_max_lengths(). Replaces unit test removed in r36514. [36515] #10377

• In the comments list table, only link rows inside the “Submitted On” column to the comment if it is publicly viewable. [36521] #35279
• Change wp_get_comment_column_max_length() function to wp_get_comment_fields_max_lengths() for consolidation and better fallbacks. [36514] #10377
• Set the $comment global in comment_form_title(). [36512] #35624

Customizer

• Add a user-friendly way to preview site responsiveness for desktop, tablet, and mobile. [36532] #31195
• Ensure that nav menu items can be shift-clicked to edit in secondary instances of the same nav menu. Amends [36383]. [36523] #32681
• Hide widgets re-order button when no re-ordering is possible. [36522] #35533
• Reduce the spinner re-painted area to the smallest possible one. [36518] #35649

Editor

• Introduce {$taxonomy}_term_edit_form_top action to edit-tag-form.php. This new action gives developers a place to output content at the beginning of the form element on edit-tags.php. [36526] #35252

i18n

• Prevent is_textdomain_loaded() from returning true even if there are no translations for the domain. [36538] #21319

Menus

• Allow larger menus to be created in the Edit Menu screen. This was attempted previously in [36506] which was reverted in [36507]. Some form fields were not being slurped into the form’s JSON representation, and it did not scale for a site with many posts. This approach [36510] #14134

Meta

• In delete_metadata(), only invalidate cache for affected objects. [36511] #35797
• Don’t double-unslash meta key when update_metadata() falls back on add_metadata(). [36509] #35795

Query

• Improve WP_Query lazyloading logic, for better performance. [36524] #35454, #35816

REST API

• Apply rest_post_dispatch to embedded responses. [36536] #35628
• Allow explicit HEAD callbacks. HEAD callbacks can now be registered independently, with the GET callback still used as a fallback. [36535] #34841
• Add routing args to rest_dispatch_request filter. This allows requests to be hijacked via the filter more easily. [36534] #35507
• Add support for CURIEs. [36533] #34729
• Don’t display errors during REST API requests. [36530] #34915
• Add helper function to get server instance. This allows using rest_do_request() outside of the API itself easily. [36529]

Taxonomy

• Introduce publicly_queryable taxonomy argument. If not provided explicitly, the value of publicly_queryable is inherited from public. [36525] #34491
• Bail from get_term() if a filter returns an object that is not a WP_Term. This prevents fatal errors in certain cases. [36516] #35808
• Remove unused variable from get_terms(). Unused since [31284]. [36508] #35784

Themes

• Use the attachment ID as the key in get_uploaded_header_images(). Prevents missing header images when an image has the same name as another header image. [36539] #31786

TinyMCE

• Fix removing a space before inline tags when applying formatting shortcuts. [36513] #35798

Props

Thanks to @danielbachhuber, @adamsilverstein, @afercia, @azaozz, @boonebgorges, @celloexpressions, @Chouby, @d4z_c0nf, @danielbachhuber, @DrewAPicture, @ericlewis, @Fab1en, @flixos90, @folletto, @jdgrimes, @joehoyle, @joelerr, @jorbin, @jrf, @michaelarestad, @nacin, @neoxx, @ocean90, @rabmalin, @rachelbaker, @rahalaboulfeth, @rmccue, @rockwell15, @sirbrillig, @stevenkword, @swissspidy, @TimothyBlynJacobs, @tmuikku, @valendesigns, @welcher, @westonruter, and @WisdmLabs for their contributions!

Week in Core, Feb. 9-16 2016 by Eric Binnion was originally posted at https://make.wordpress.org/core/2016/02/17/week-in-core-feb-9-16-2016/

API Authentication discussion!

I was chatting with @rmccue and we though it’d be a good decision to have an open discussion regarding potential avenues for API Authentication on Thursday, February 18th at 22:00 UTC in the #core-passwords channel in Slack.

We’ll be addressing everything from OAuth 1.0a, OAuth 2.0, Application Passwords, and what limitations should be used to scope assorted tokens.

Relevant background reading: http://stephanis.info/2016/02/14/on-core-rest-api-authentication/

API Authentication discussion! by George Stephanis was originally posted at https://make.wordpress.org/core/2016/02/16/api-authentication-discussion/

Bug Scrub Changes and Recap of 2/12/2016 Bug Scrub

As announced previously, for the next two weeks only, bug scrubs will be held daily Tuesday, February 16th 17:00 UTC to Friday, February 19th 17:00 UTC and  Monday, February 22nd 17:00 UTC to Friday, February 26th 17:00 UTC. These bugscrubs will only focus on tickets that are milestoned for 4.5 inclusion, in order to reduce the number of tickets open in the milestone before the enhancement merge window closes Wednesday, February 24th 17:00 UTC.

On Friday, February 12th at 17:00 UTC, we had our regularly scheduled bug scrub. As a reminder, for the 4.5 release, trac bug scrubs will be held normally weekly each Friday at 17:00 UTC. Bug scrubs are held in the #core channel of WordPress Slack.

The Slack archive for last week’s meeting begins here: https://wordpress.slack.com/archives/core/p1455296539002539

During the bug scrub, the following tickets were covered:

#35495, #22363, #24251, #35807, #34625, #12955, #21667, #35774, #35804, #35720, #35716, #35422, #35427, #35428, #34913, #20537, #18997, #32075, #35160, #31237, #35390

We’ll return to the standard pre-submitted & open floor format after two weeks.

Bug Scrub Changes and Recap of 2/12/2016 Bug Scrub by Chris Christoff (chriscct7) was originally posted at https://make.wordpress.org/core/2016/02/16/bug-scrub-changes-and-recap-of-2122016-bug-scrub/

Pop-Ups & Disruption to Customer Engagement - 'Net Features - Website Magazine

Design accordingly! 90 percent of consumers express outright hatred for pop-up surveys and 93 percent hate pop-up ads. http://www.websitemagazine.com/content/blogs/posts/archive/2016/02/15/popups-amp-disruption-to-customer-engagement.aspx

Turns out, consumers aren't fans of pop-up ads and surveys after all. Who knew? A recent survey from IgniteFeedback found that nearly 90 percent of consumers hate taking pop-up Web surveys (up 6 percent from 18 months ago). Is it causing harm to brands? The initial research in late 2014 found that 8…

Originally posted at The WP Guy - WordPress Web Design

Selective Refresh in the Customizer

The Customizer is our framework for live previewing changes. However, settings edited in the Customizer get sent to the preview via the refresh transport by default, meaning that in order for a setting change to be applied, the entire preview has to reload: this refresh can be very slow and is anything but “live”. To remedy this poor user experience of a laggy preview, the Customizer allows settings to opt-in to using a postMessage transport which relies on JavaScript to preview the change instantly without doing any server-side communication at all. This provides for a great user experience.

There is a major issue with settings using the postMessage transport, however: any logic used in PHP to render the setting in the template has to be duplicated in JavaScript. This means that the postMessage previewing logic violates the DRY (Don’t Repeat Yourself) principle, and so it is really only suitable for simple text or style changes that involve almost no logic (e.g. site title or background color). Even in this case, it is often not possible to fully re-implement the PHP logic in JS, since as in the example of #33738 there may be an unknown number of PHP filters that get applied to the setting’s value (such as the site title) when rendering the content on the server.

What the Customizer needs is a middle-ground between refreshing the entire preview to apply changes with PHP and between applying the changes exclusively with JavaScript. The selective refresh is the solution proposed in #27355, and this post is about documenting the feature, as it was approved for core merge in 4.5. Selective refresh also appears on the proposed Customizer roadmap.

Partial preview refreshing was first explored when Customizer widget management was being developed for the 3.9 release. It was added to the Widget Customizer plugin and described in a Make Core post. But it was decided to remove the feature in favor of having a better generalized framework for partial refreshes in a future release (which is now). In 4.3, nav menus were added to the Customizer and with this the first core implementation of selective refresh, as described in Fast previewing changes to Menus in the Customizer. (For more background, see Implementing Selective Refresh in the Customizer.)

With the shipped example of selective refresh of nav menus in the Customizer, and an initial implementation of selective refresh for widgets, work progressed to generalize a selective framework that would support the complicated examples of nav menus and widgets, but also to support simpler use cases such as letting the server render the updated site title so that wptexturize and other filters can apply. The generalized framework has been implemented in the Customize Partial Refresh feature plugin, which also re-implements selective refresh of nav menus and introduces selective refresh of sidebars and widgets.

To see a simple example of selective refresh, see the Site Title Smilies plugin showing wptexturize and emoji applying to site title updates in the preview:

Note in this example that the standard postMessage updating of the site title in the header is still in place and so the change appears immediately. It gets followed, however, by the content being rendered by the partial on the server. This allows for JS to apply a quick low-fidelity preview for a setting change until the server can respond with the high-fidelity preview.

Selective Refresh Architecture

This plugin introduces a selective refresh framework which centers around the concept of the partial. A partial is conceptually very similar to a Customizer control. Both controls and partials are associated with one or more settings. Whereas a control appears in the pane, the partial lives in the preview. The fields in a control update automatically to reflect the values of its associated settings, and a partial refreshes in the preview when one of its settings is changed. The name “partial” is derived from  get_template_part(), which is a natural function to use in a partial’s  render_callback.

In addition to a partial being associated with one or more settings, a partial is also registered with a jQuery selector which identifies the partial’s locations or “placements” on the page, where the rendered content appears. For example, a partial can be registered for the site title to update the header as well as the document title via:

function my_register_blogname_partials( WP_Customize_Manager $wp_customize ) {

        // Abort if selective refresh is not available.
        if ( ! isset( $wp_customize->selective_refresh ) ) {
                return;
        }

        $wp_customize->selective_refresh->add_partial( 'header_site_title', array(
                'selector' => '.site-title a',
                'settings' => array( 'blogname' ),
                'render_callback' => function() {
                        return get_bloginfo( 'name', 'display' );
                },
        ) );

        $wp_customize->selective_refresh->add_partial( 'document_title', array(
                'selector' => 'head > title',
                'settings' => array( 'blogname' ),
                'render_callback' => 'wp_get_document_title',
        ) );
}
add_action( 'customize_register', 'my_register_blogname_partials' );

When a setting (like blogname here) is modified, each registered partial is asked on the client whether it isRelatedSetting(). If that method for a partial returns true, then the partial’s refresh() method is invoked and a request is queued up to render the partial via the requestPartial() function. Calls to this function are debounced and multiple simultaneous partials being changed will be batched together in a single Ajax request to the server.

When the server receives a request to render partials, it will receive the list of partials as well as all of the modified settings in the Customizer. Partials need not be all registered up front: as settings support the customize_dynamic_setting_args and customize_dynamic_setting_class filters, so too partials support the customize_dynamic_partial_args and customize_dynamic_partial_class filters. These filters allow partials to be added on demand to support the partials being requested to render.

If there is no registered partial for the request, or if the partial’s render_callback returns false, then false will be returned in the response as the content for that partial, and the default fallback() behavior in the client-side Partial object is to requestFullRefresh(). On the other hand, if the request recognizes the partial and the render_callback returns content, then this content is passed along to the Partial instance in the client and its renderContent() method then follows through to update the document with the new content.

As noted previously, the location in the document where a partial renders its update is called a placement. A selector may match any number of elements, and so too a partial may update multiple placements. A partial’s placements in the document may each have different sets of context data associated with them. This context data is included in the partials request and is passed along to the render_callback so that the content can vary as needed, for example a widget appearing in two different sidebars would have different sidebar_id context data, which would then determine the before_widget and after_widget args used.

Partial placements may also be nested inside other placements. For example, a Custom Menu widget is rendered as a placement which then contains another placement for a nav menu. The nav menu placement is updated independently from the parent widget placement. This being said (and this is advanced usage), a selector does not need to be supplied when registering a partial: alternatively to a top-down selector, the placement for a partial can be declared from the bottom-up by adding a data-customize-partial-id attribute to any container element. Whenever a partial is re-rendered, any nested partials will be automatically recognized. (As noted above, each placement can have a different associated context, and this is indicated by JSON object in a data-customize-partial-placement-context HTML attribute.)

Aside: The architecture of the Infinity Scroll module in Jetpack mirrors Selective Refresh framework in several ways.

Linking Partials to Controls

Since each partial is associated with at least one setting, shift-clicking on the placement for a partial will attempt to focus on the related control in the pane. This was already implemented for widgets since 3.9 and recently for nav menu items as well, but now the functionality is available partials generally.

Selective Refresh of Widgets

Selective refresh for nav menus was enabled by default in 4.3. While some themes needed to add theme support for any dynamic aspects (such as the expanding submenus in Twenty Fifteen), generally nav menus seem to be fairly static and can be replaced in the document without needing any JS logic to be re-applied. Widgets, on the other hand, have much more variation in what they can display, since they can in fact display anything. For any widget that uses JavaScript to initialize some dynamic elements, such as a map or gallery slideshow, simply replacing the widget’s content with new content from the server will not work since the dynamic elements will not be re-initialized. Additionally, the sidebars (widget areas) in which the widgets are displayed may also have dynamic aspects associated with them, such as the Twenty Thirteen sidebar which displays widgets in a grid using Masonry. For this theme, whenever a widget is changed/added/removed/reordered, the sidebar needs to be reflowed.

In order to allow themes to reflow sidebars and widgets to reinitialize their contents after a refresh, the selective refresh framework introduces widget-updated and sidebar-updated events. Additionally, since re-ordering widgets in a sidebar is instant by just re-ordering the elements in the DOM, some widgets with dynamically-generated iframes (such as a Twitter widget) may need to also be rebuilt, and for this reason there is a partial-content-moved event.

For the above reasons, I believe it will be much more common for widgets (and sidebars) to need special support for selective refresh, and so I think that at least for 4.5 the selective refresh should be opt-in for widgets (and perhaps in themes for sidebars). See theme support for Twenty Thirteen and plugin support for a few widgets in Jetpack (which won’t be part of the merge). At last week’s Core dev meeting, it was suggested that we add the opt-in for widget selective refresh at RC.

Selective Refresh API

What follows is a list of aspects of the API that should be more commonly used. For full documentation, see the inline docs in the plugin source.

PHP

I suggest that Selective Refresh be added as a new Customizer component to be accessed via $wp_customize->selective_refresh which is where the methods for partials(), add_partial(), get_partial(), remove_partial(), and others would be accessed.

New classes:

• WP_Customize_Selective_Refresh
• WP_Customize_Partial

New filters:

• customize_partial_render
• customize_partial_render_{$partial->id}
• customize_dynamic_partial_args
• customize_dynamic_partial_class
• customize_render_partials_response

New actions:

• customize_render_partials_before
• customize_render_partials_after

JS

Namespace: wp.customize.selectiveRefresh

New classes:

• wp.customize.selectiveRefresh.Partial
• wp.customize.selectiveRefresh.Placement
• wp.customize.navMenusPreview.NavMenuInstancePartial
• wp.customize.widgetsPreview.WidgetPartial
• wp.customize.widgetsPreview.SidebarPartial

New properties:

• wp.customize.selectiveRefresh.parital (collection)
• wp.customize.selectiveRefresh.partialConstructor

Events (triggered on wp.customize.selectiveRefresh):

• render-partials-response
• partial-content-rendered
• partial-placement-moved
• widget-updated
• sidebar-updated

The Future

If we can eliminate full-page refreshes from being the norm for the Customizer, we can start to introduce controls inline with the preview. If the entire preview does not reload, then the inline controls won’t get destroyed by the refresh with each change. For example, consider a widget control floating immediately next to the widget in the sidebar it is editing. With selective refresh, it will then also be possible to eliminate the Customizer altogether. The Customizer could be available to anyone who is logged in, with the controls being bootstrapped on demand when a user wants to edit a given element. There would be no need to navigate way from a page on the frontend to enter a unique Customizer state: the Customizer would come to the user. Any controls not relevant to being inline could remain in the Customizer pane, but it could slide in only as needed instead of appearing by default. That is to say, selective refresh makes the Customizer a much better framework for implementing frontend editing.

Feedback

There is just over a week until the first beta for 4.5. I’d like to get any final feedback on the feature as soon as possible before committing it to trunk. The plugin is on GitHub and the plugin directory. Feedback should be left on #27355. Note that the plugin depends on 4.5-alpha-35776 to run.

Selective Refresh in the Customizer by Weston Ruter was originally posted at https://make.wordpress.org/core/2016/02/16/selective-refresh-in-the-customizer/