Make WordPress Core

Updates from October, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • John Blackbourn 12:06 pm on October 1, 2015 Permalink |  

    Request for feedback: Your HTTPS configurations 

    An ongoing goal of WordPress is to improve the way it works for sites that use HTTPS, and more specifically sites that run a mixture of schemes (for example, HTTPS in the admin area but HTTP on the front end).

    One of the most visible bugs currently is that media in an HTTPS admin area is served over HTTP unless the ‘WordPress Address’ setting (siteurl) also uses HTTPS, which means that the FORCE_SSL_ADMIN constant isn’t a complete drop-in solution to securing your admin area.

    Addressing all the possible configurations of HTTPS is difficult, so I’d like to put out a request for anyone who’s using a particularly interesting HTTPS configuration on your site to let us know what your setup is.

    Of particular interest would be a site that’s using different domain names for HTTPS and HTTP, different domain names for the admin area and front end, different ports anywhere, self-signed certs for the admin area, HTTPS admin areas with additional access restrictions, multisites with and without domain mapping that use a mixture of HTTPS and HTTP, etc.

    If your site has an interesting HTTPS configuration, and of course if it suffers from scheme related bugs as a result, please let us know in the comments below.

    • David Smith 8:57 pm on October 2, 2015 Permalink | Log in to Reply

      Substantially all of our sites are behind an F5 LTM appliance (actually, a cluster of them…) for SSL offloading.

      There’s an iRule (F5’s scripting language) that redirects all port-80/non-SSL requests to port 443, and the sites have https:// in the WordPress database site_url. Couple different wildcard certs for various third-level and fourth-level domain names, nothing too fancy there. The F5 proxies requests to the backend Apache server (or, in my case, to a Varnish cache server, which in turn talks to WordPress), and everything behind the F5 is non-SSL. (Authentication isn’t an issue, it’s handled external to WordPress via Shibboleth, and that IS encrypted even on our internal network.)

      One thing I’ve done, that looks kinda strange but works just fine: Apache is perfectly happy to respond to “SSL” requests over port 80, if you tell it to. You just specify a second ServerName parameter in the configuration, like so:


      ServerName yoursite.name.org
      ServerName https://yoursite.name.org:443
      (whatever other stuff you normally do here)


      If you forget that, or have a sticky keyboard that keeps typing ’43’ instead of ‘443’, you’ll notice immediately because most of your JavaScript and CSS won’t load. :)

    • Jeremy Felt 7:39 pm on October 2, 2015 Permalink | Log in to Reply

      I wrote up some of the workings around our config here: https://jeremyfelt.com/2015/04/24/a-method-for-managing-mixed-httphttps-sites-in-multisite/

      In a nutshell:

      • We get individual certs from InCommon.org as domains are created. We’ll request multi-domain certs when we want to support www as well. Each unique, non-www domain gets some kind of cert.
      • Sites are sometimes briefly accessible via HTTP on the admin and front-end while we wait for a cert request to be fulfilled.
      • Once a cert is available, all admin requests for that domain are forced HTTPS.
      • Recently, we’ve started forcing all front-end requests for new domains to HTTPS, though there are some domains that still support HTTP requests.

      We’re usually on the latest Nginx mainline release and the following config is included for each site: https://github.com/washingtonstateuniversity/WSU-Web-Provisioner/blob/master/provision/salt/config/nginx/wsuwp-ssl-common.conf

      We’ll be switching to HTTP/2 next week. :)

    • jwz 5:49 pm on October 2, 2015 Permalink | Log in to Reply

      I recently switched my site to be SSL-only. But before that, I had it configured so that admin URLs were HTTPS and non-admin URLs were forced to be HTTP. I did this because my SSL cert was self-signed, since I was the only one using it. I didn’t want normal blog readers to ever be hit with the “unsigned cert” warning.

      Here’s how I accomplished that:

      RewriteEngine On
      RewriteBase /blog/

      1. These URLs require SSL. All others require non-SSL.

      RewriteRule ^wp-(admin|login|register|signup) – [E=NEEDSSL:1]

      1. This URL can be either SSL or non-SSL. Leave it alone.

      RewriteRule ^wp-admin/admin-ajax\.php$ – [QSA,L]

      1. This Facebook query-string can be either SSL or non-SSL. Leave it alone.

      RewriteCond %{QUERY_STRING} (^xd_receiver) [NC]
      RewriteRule .? – [QSA,L]

      1. NEEDSSL && !SSL: turn it on.

      RewriteCond %{HTTPS} !=on [NC]
      RewriteCond %{ENV:NEEDSSL} =1
      RewriteRule .? https://%{HTTP_HOST}%{REQUEST_URI} [R=301,QSA,L]

      1. SSL && !NEEDSSL: turn it off. Except on staging server.

      RewriteCond %{HTTP_HOST} !=staging.jwz.org [NC]
      RewriteCond %{HTTPS} =on [NC]
      RewriteCond %{ENV:NEEDSSL} !=1
      RewriteRule .? http://%{HTTP_HOST}%{REQUEST_URI} [R=301,QSA,L]

    • mydiskdriveonline 4:21 pm on October 2, 2015 Permalink | Log in to Reply

      I have a multisite/subdomian install with a couple mapped domains at Dreamhost.

      I rewrite the root site and mapped domains to https in apache virtual hosts:

      RewriteCond %{HTTP_HOST} =myrootsite.com [NC]
      RewriteRule ^(.*) https://myrootsite.com$1 [R=301,NE]
      RewriteCond %{HTTP_HOST} =mappeddomain.com [NC]
      RewriteRule ^(.*) https://mappeddomain.com$1 [R=301,NE]

      I pull out the ServerAlias’s(mapped domains) that Dreamhost groups in with the “mirrored” rootdomain from and give them each their own so they can each get a cert.

      So my root site uses a regular cert, not a wildcard(cant afford it). mapped domains each have there own cert, the rest of the subdomains do not use https.

      Issues I have are:

      Network admin get_site_url(); for sites defaults to https. Is there a way to force it to use http:// all the time?

      To fix the Networked sites upgrader i use:
      add_filter(‘https_ssl_verify’, ‘__return_false’);
      add_filter(‘https_local_ssl_verify’, ‘__return_false’);

      I also do a search and replace in post_content and make my urls relative instead of absolute (ie. remove https://mysite.com/files/ and replace with /files/) every week or so.

      I know I’m beating a dead horse but I really wish WordPress used relative urls.

    • Henry Wright 8:43 am on October 2, 2015 Permalink | Log in to Reply

      I try to use HTTPS everywhere, always.

    • war59312 11:19 pm on October 1, 2015 Permalink | Log in to Reply

      We force SSL using Strict-Transport-Security and Content-Security-Policy. 100% SSL. A+ Rating on ssllabs.com.

      We follow security guide @ bettercrypto.org as well.

      Along with a few other security methods, such as Content Security Policy (CSP), X-Frame-Options (Frame-Options), X-XSS-Protection, X-Content-Type-Options, X-WebKit-CSP, and X-Permitted-Cross-Domain-Policies.

      Even though we don’t store any Personally identifiable information (PII).

      I want my users, clients, staff, partners, etc. to know they are protected to the very best of my ability.

      Personally, I believe all of these should be the default and required (by LAW). Even more so if you do make use of PII.

      Think it would be wise for WordPress to enable as many as these security settings as possible by default.

      • war59312 11:24 pm on October 1, 2015 Permalink | Log in to Reply

        wordpress.org should make use of all of these features.

        Please enable Strict-Transport-Security and Content-Security-Policy. Takes a few seconds really. 😉

        Your already “forcing” SSL, so how about do it correctly!! Please!!

        • war59312 11:26 pm on October 1, 2015 Permalink | Log in to Reply

          That is:

          Content-Security-Policy “upgrade-insecure-requests”

        • vhmark 1:48 am on October 2, 2015 Permalink | Log in to Reply

          In our case we’re https to the load balancer, http between the LB and the web servers, and the LB does NOT pass through any $_SERVER variables to indicate this.


          • Requests come from the client to the load balancer as https, but are translated to http from the the LB to the web server.
          • Unfortunately the LB does not tell the server it is working over https, so the is_ssl() function returns the wrong result.
          • The practical result is that you can see the site, see the login page, but cannot login.
          • Forcing SSL gets around the problem.

          $_SERVER[‘HTTPS’] = ‘on’;
          $_SERVER[‘SERVER_PORT’] = 443;

      • vhmark 1:42 am on October 2, 2015 Permalink | Log in to Reply

        Our is all https back + front-end mutisite subfolders. The twist is that to cut down on mixed content errors we built a search-replace-on-submit of post+comment content for a whitelist of sites.

    • Mike Nelson 6:11 pm on October 1, 2015 Permalink | Log in to Reply

      We have an event registration plugin, where many users want to only make certain frontend pages (relating to event registration) SSL.
      Specifically, an issue many users encounter is the following: when someone goes to register for an event, one payment option is to go to Paypal and then return to the site’s “Thank You” page. However, on certain browsers when a user is redirected from an SSL Paypal page to a non-SSL “Thank You” page, they will get a scary warning “You are visiting an unencrypted page etc etc… are you sure you want to do this?”.
      Us technical people think “yeah that warning makes sense, they entered their credit card data onto a secure Paypal page, and now they’re returning to a non-secure page on WordPress which doesn’t need to be secure anyways because no sensitive data will be exchanged on this page, so that’s a-ok” but many of our site admins using the plugin don’t understand that, and many of their clients signing up for events don’t understand that either. So the solution most of our plugin users want is to ONLY have the frontend “Thank You” page to be SSL, so that users won’t get the browser warning I just mentioned, but otherwise they want to keep everything else non-SSL.
      We used to recommend the WP HTTPS plugin https://wordpress.org/plugins/wordpress-https/ but it’s recently not getting much support

      • Ipstenu (Mika Epstein) 9:02 pm on October 1, 2015 Permalink | Log in to Reply

        FWIW, WordPress-Https still works. And it’s good for when you have to enforce things like “Damn it, why did you enqueue with http!?!”

        I’ll make a post on make/plugins to remind people though…

    • dmori 6:05 pm on October 1, 2015 Permalink | Log in to Reply

      I have a situation with http in admin but https on front page login form. I noticed that you cannot load customizer and page if they are different (i.e. http/https mix).

      It would be good if you could make the wp-login page use https only – rather than force all admin. This way logging into site would be secure.

      If there was a way to make have all wp-login pages use https (without users needing an SSL for their site) would be great. I don’t know if this could ever be possible, but this would have an immediately positive effect for all wordpress websites.

      I know this is for top level devlopers – but please remember not all wordpress users have the knowledge and experience you do. We want to make it as accessible to as many people as possible.

    • jancbeck 4:40 pm on October 1, 2015 Permalink | Log in to Reply

      I have a multisite installation where I host sites of my friends. I’m using WPMU domain mapping to give each of them their own non-https domain. It’s a multisite subdirectory setup but the domain mapping works with subdomains too, so it’s kinda mixed (shop.mydomain.com and mydomain.com/shop are both possible).
      My host comes with one free HTTPS domain that I already use for other projects so I installed the whole multisite into a ‘/wp/’ subdirectory. It doesn’t really matter for the frontend URLs, because they are mapped anyways. It’s just so the admin area is available at https://mydomain.com/wp/wp-admin/
      I also use Jetpacks CDN (Photon).

      This runs pretty stable for a about a year now. The most common problem is related to the subdirectory install. However one current problem related to HTTPS is that the “link modal” in the editor will add the https protocol to the content and clicking these links on the non-https frontend will result in a browser error message.

    • xwolf 4:38 pm on October 1, 2015 Permalink | Log in to Reply

      I am hosting a multisite network at our university in which all plain HTTP requests are redirect towards HTTPS. We dont make a mix of HTTP and HTTPS, cause there is no need for HTTP and we made the experience, that on mixed installation several themes and plugins use absolute pathes based on HTTP for generating media files or other things.
      Therfor all multisite instances are SSL only.
      We did this by changing the siteurl and all other settings to SSL.
      For redirection from HTTP to HTTPS we are using Server directions and RewriteRules in .htaccess for the main hostname of the site an its potential cname aliases.

      We set the main university site http://www.fau.de to SSL-only in October 2014. We got no problem report or issue about it. Our website-statistics show that only 0.23 % of 65.827.341 pageviews last month were made bei IE6-Browsers. IE8 got 1.21 %. Thats not enought to take care about this old trash.

      • war59312 11:27 pm on October 1, 2015 Permalink | Log in to Reply

        Should use:

        Content-Security-Policy “upgrade-insecure-requests”

        Force SSL without an insecure redirect needed. And will NOT break http paths. :)

    • DuzAwe 3:58 pm on October 1, 2015 Permalink | Log in to Reply

      Using LetsEncrypt and cloudflare to provide SSL for live and test sites currently. Nothing fancy

    • Aaron D. Campbell 3:26 pm on October 1, 2015 Permalink | Log in to Reply

      I have a multisite install for some of my personal sites (read that as “I haven’t had time to invest in solving all the idiosyncrasies with the setup”). The plan was to use aarondcampbell.com as the main site with a wildcard SSL. I then wanted to use subdomains over SSL for admin for the sites (geekreprieve.aarondcampbell.com/wp/wp-admin), and mapped domains for the front end (geekreprieve.com).

      I tried to use Mercator, but it ended up still requiring some code to filter ‘upload_dir’ to use the proper front-end URL rather than the current URL when you add media to a post. Ultimately, it was far more difficult to set up than I had expected, and it still has it’s quirks that I just haven’t had time to fix up (like the main site front end being accessible via both http and https).

      @johnbillion I’m happy to give you access to poke around (or give you the code or whatever) if you think it would be helpful.

    • Brandon Kraft 3:14 pm on October 1, 2015 Permalink | Log in to Reply

      I have a multinetwork multisite site. 99% of domain mapping takes place via separate networks on the install. The rest of the domain mapping is secondary domains that redirect to the primary.

      The main network is a subdomain multisite site with HTTPS on a wildcard cert. None of the other networks have SSL.

      With regard to SSL, the most noticeable pain point is the WP Multi Network plugin has a link to each network’s dashboard that uses `network_admin_url`, which is uses `network_site_url()` with the `admin` flag for scheme, which returns of the HTTP/HTTPS scheme of the *current network* not anything specific to that network.

      I just traced back the code; haven’t opened a ticket yet or explored the best way to check if a particular network should have a particular scheme.

    • Otto Keklinen 2:27 pm on October 1, 2015 Permalink | Log in to Reply

      We force admin https for our users always. If the site does not have its own SSL certificate, it will fall back to our generic wildcard certificate, so the whole admin will be at a different domain. This is possible with our custom plugin: https://wordpress.org/plugins/https-domain-alias/ This plugin would solve at least all the current unencrypted password transmissions in all official hosting environments (not self hosted).

    • Ipstenu (Mika Epstein) 1:48 pm on October 1, 2015 Permalink | Log in to Reply

      Multisite – https backend, one site on the network is https front end.

      And Multisite is a good warning spot for HTTPS everywhere since if you have subdomains, you have to either have a multi-subdomain cert or you have to make one per subdomain. And no, HTTPS Everywhere is NOT going to make multi-subdomains right away. They’ve outright said that, so please keep in mind the biggest hurdle with HTTPS will be getting certs installed :/ The common man does not find this easy. Hell, I’m a professional and I hate it.

      As soon as HTTPS everywhere is out, my stand-alone sites will be going to https all around, but Multisite I have to test and figure out.

      • webaware 11:22 pm on October 1, 2015 Permalink | Log in to Reply

        +1 same scenario, plus multi-network multisite. I have CloudFlare providing SSL to the networks with wildcard so it’s not a problem at present, but it’s not ideal and looks unprofessional (have you looked at the certs? nasty!) However, it’s a simple free solution to that problem if CloudFlare is suitable for the network. Individual sites can then be configured with their own certs.

        Talking with clients about SSL certs, single site certs are confusing enough for many. Multisite with subdomains, or even single site with a mobile subdomain, gets messy and/or expensive fast. Throw in some mixed content errors and clients start pulling hair — theirs, yours, passers by.

    • Bjørn Johansen 1:11 pm on October 1, 2015 Permalink | Log in to Reply

      If you’re behind a reverse proxy that handles, and terminates, HTTPS for you – with the connection between the reverse proxythe result of the protocol between the reverse proxy and WordPress

      If you’re behind a reverse proxy or load balancer that handles and terminates HTTPS for you – like CloudFlare, Sucuri, Big-IP and many more – and the connection between the reverse proxy and WordPress is plain HTTP, WordPress gets confused.

      The reverse proxy should, and usually does, set a HTTP header explaining the situation. I believe the de-facto standard for this is to set the header “X-Forwarded-Proto” to “https” (even though I’ve seen many others variant as well: E.g. the header “WL-Proxy-SSL” to “true” on Big-IP).

      This is an issue that can easily be solved in the web server config, or by adding the following code to wp-config.php:
      if ( isset( $_SERVER[‘HTTP_X_FORWARDED_PROTO’] ) && ‘https’ == $_SERVER[‘HTTP_X_FORWARDED_PROTO’] ) {
      $_SERVER[‘HTTPS’] = ‘on’;

      Maybe this should be considered as an addition to the is_ssl() function?

      • J.D. Grimes 1:37 pm on October 1, 2015 Permalink | Log in to Reply

        Yes, I use CloudFlare on my sites, and having to add this code to wp-config.php is a pain. It would be a nice enhancement if that was handled automatically. The only reason that might not be feasible is that the HTTP_X_FORWARDED_PROTO header, being client-supplied, isn’t trustworthy.

      • Jon Brown 2:29 pm on October 1, 2015 Permalink | Log in to Reply

        This is the unusual case I was going to share. I setup cloudflare + self signed ssl on several of my personal sites, it can work, but can be flaky. I’ve used that same snippet.

        Beyond that it gets weird as well when I want to ssl a few front end form pages (I use the WordPress https plugin).

        Fwiw, I’m more worried at the moment about supporting http2, but this is still important.

      • webaware 11:35 pm on October 1, 2015 Permalink | Log in to Reply

        This can’t be handled “automatically” because that header (and its friends) cannot be trusted; you need to know that a) your website uses such a configuration, and b) which one. See this comment on #31288 for more details.

        At the very least, you need to select this as an option. Pasting that code into wp-config.php is the simplest and fastest fix, or you can use a plugin (there’s a couple, including my SSL Insecure Content Fixer).

    • Dave McHale 1:03 pm on October 1, 2015 Permalink | Log in to Reply

      Considering that Symantec recommended Always-On SSL as far back as 2011, I wonder how much longer it will take for most administrators to finally realize that there isn’t a good reason to NOT supply https for all connections. http://www.symantec.com/page.jsp?id=always-on-ssl

      Google and many other vendors have also repeatedly stated that secure connections do not have a measurable performance hit (MaxCDN source: https://www.maxcdn.com/blog/ssl-performance-myth/ ) I just don’t see any valid arguments against it nowadays.

      While WordPress obviously needs to support numerous configurations, it would be nice to see a push towards encouraging “best practices” moving into the future. I think this means “make my whole site use https” is the primary DECISION users should be making in the admin area. Is it turned on, or turned off? Less granular OPTIONS.

    • Patrick Steil 12:56 pm on October 1, 2015 Permalink | Log in to Reply

      Two points to add here:

      1. Google wants “SSL everywhere” so I think you all shouldn’t worry too much about supporting http on front or back and https on the other. Should be all or nothing.

      2. Every site out there can get a FREE SSL certificate for any domain they want by using CloudFlare as their web site firewall / front end. We are using this on our WPMS and it is working very well!

    • Gregory Karpinsky (@tivnet) 12:49 pm on October 1, 2015 Permalink | Log in to Reply

      After several unsuccessful attempts to have regular pages HTTP, admin and WooCommerce checkout HTTPS – we gave up and made https the whole site.
      If was really impossible to track all redirects, and also to fight WC bugs with their “force SSL on checkout”.
      From now on, any serious e-commerce site we’ll do on https from the very beginning.

    • CotswoldPhoto 12:40 pm on October 1, 2015 Permalink | Log in to Reply

      I have to wonder how many sites will NOT be https soon. With Let’s Encrypt nearly ready to launch its free service, due week of 16 November 2015 https://letsencrypt.org/2015/08/07/updated-lets-encrypt-launch-schedule.html https is going to blossom.

      • Ipstenu (Mika Epstein) 2:11 pm on October 1, 2015 Permalink | Log in to Reply

        Please note: LetsEncrypt has pushed back the date at least 3 times already, and they’re not going to be world-wide usable right away. At best we can say that this might be usable for the general public by next summer (2016).

        Also remember getting the cert is problem #1. Problem #2 is the common human ADDING the cert to their servers. Shared hosts may have problems.

    • Mark Wilkinson 12:39 pm on October 1, 2015 Permalink | Log in to Reply

      I run a similar setup to @thomaswm. I have a multisite installation install on my domain and this domain has a wildcard SSL certificate. Most of the actual sites in the multisite are mapped to a domain name which does not have a certificate and therefore I want the backend to happen over the sites sub domain URL. This can then use the wildcard SSL of the main domain.

      I have had issues in that the domain mapping plugin re-writes all the admin links to mapped-domain.com/wp-admin rather than using subdomain.domain.com/wp-admin, but have over come this with a plugin.

      I am sure there are going to be more issues crop-up with this setup though. Hope this is the sort of thing you where after.

    • thomaswm 12:30 pm on October 1, 2015 Permalink | Log in to Reply

      We operate a multisite network with subdirectory configuration. Every site gets a domain mapped to them using the Domain Mapping plugin. We have a wildcard SSL certificate for the main site’s domain, but we do not have any certificate for the other sites’ domains.

      We have a custom plugin in place to make certain sites available under a subdomain of our main site’s domain via HTTPS so they can use our wildcard SSL cert. This would lead to scheme-related problems, but we use the “WordPress HTTPS” plugin to rewrite the URLs of embedded media.

      Also, one of our most used themes has its own way of dealing with mixed content: It uses the “the_content” filter, look for URLs which point to the current website and runs them through the function “wp_make_link_relative”.

      You see that this is all quite hacky and I’m not really happy about that, but it works after all. 😉

    • AdamConway 12:29 pm on October 1, 2015 Permalink | Log in to Reply

      Couldn’t agree more with @petermolnar. Apart from the fact that I don’t see good arguments for not simply hosting the whole site on SSL (if you have part of it there), there is a solution to this built in to URI syntax standards, so why not just use it? I can’t see a downside with that! It might not solve issues where you have mutliple domains with SSL only on some, but relative links (relative to site root at least) are the only real solution to that.

      I use a very simple solution of allowing HTTP to the server but then redirecting to HTTPS in apache (mod rewrite) before it gets anywhere near wordpress, and haven’t had any issues with that. The early sites which were set up with http we had to do database rewrites to fix.

    • John Huebner 12:22 pm on October 1, 2015 Permalink | Log in to Reply

      On the hosting provider I use if I set up SSL then on a site then the entire site is severed on HTTPS, no choice. Once done you cannot access the site by HTTP.

      I have had serious problems setting up WP with SSL. If I set up SSL first then the site breaks because it attempts to redirect to HTTP while the server is redirecting to HTTPS and I can’t login to change it. If I change WP first then the site breaks attempting to redirect to HTTPS that does not exist while I’m setting up the SSL.

      I think that the above comment by @petermolnar might help solve this situation.

      • petermolnar 12:33 pm on October 1, 2015 Permalink | Log in to Reply

        You could; at least it _can_ be set up like that, that’s a choice of the provider if it redirects to https.

      • Ipstenu (Mika Epstein) 3:28 pm on October 1, 2015 Permalink | Log in to Reply

        I want to say this is a hosting issue, but it highlights a major concern. Not all hosting platforms are created equal :/ And telling the end user “its your host” is a terrible idea.

        • John Huebner 1:38 am on October 2, 2015 Permalink | Log in to Reply

          Thank you for that. The company I work for uses a particular host for all the sites we build. I can’t simply decide to use another one and I doubt I’m going to convince the hosting provider that they need to change the way they do things.

    • petermolnar 12:18 pm on October 1, 2015 Permalink | Log in to Reply

      I have no idea what reasoning could justify https only for the backend.

      Anyway: use // for urls, for _every_ in-site url, including css, js, any link instead of http:// or https:// prefixes. That will help avoiding mixed content issues because it get interpretered by the browser according to the url.

      Apart from that… use https w/ http2 everywhere, not just for the backend.

  • Morgan Estes 7:37 pm on September 29, 2015 Permalink |
    Tags: ,   

    Week in Core: Sept. 21-27, 2015 

    Oh Snap!, it’s time to usher in a new edition of Week in Core! If you have the time, throw a house party with some friends and read the full force of changes on Trac; if not, don’t sweat it — take simple pleasure in these highlights.

    This post covers changesets [34362][34658], committed during Sept. 21–27, 2015. Let’s give a hi-five and some TLC to the 102 contributors for a combined 296 updates! Together, we’re making WordPress nice & smooth.

    (More …)

  • Morgan Estes 9:08 pm on September 21, 2015 Permalink |
    Tags: ,   

    Week in Core: Sept. 13-21, 2015 

    Welcome to the Week in Core — Week Four, with super-exciting news from around WordPress-land, and Core changes and updates for Sept. 13–21, 2015 (commits [34093][34361]). This week’s core contributors number 106! I’m especially jazzed about the number of new names on the list, and want to thank everyone for your effort this week.

    News you can use

    The WP REST API team submitted a proposal to merge the plugin into core, with a two-phase integration plan. The merge proposal blog post also does a nice job of presenting the history of the plugin and some use cases.

    Do you use my-hacks.php in your site? Don’t. (A quick search through the plugin and theme repos shows only 10 plugins and 3 themes that mention the file.)

    Multisite is making some pretty big changes, including the addition of the  WP_Network class. Check out this blog post, which outlines some of the changes and a roadmap for future updates for 4.4.

    Interested in the user-focused part of WordPress? Of course you are! Join in the conversation about “Potential UI/UX projects in core.”

    Code changes

    Here are some highlights from the 268 change sets published to Trac; the complete report is available online in plain-text format for a bit more in-depth coverage.

    (More …)

  • Morgan Estes 9:04 pm on September 16, 2015 Permalink |
    Tags: ,   

    Week in Core: Aug. 31 – Sept. 12, 2015 

    Welcome to the Week in Core, with updates from weeks 2 & 3: Aug. 31 – Sept. 12, 2015, changesets [33821][34092].

    It’s been a busy couple of weeks in Core, with almost too many changes to count (for the record, this one covers 271 commits!). I’m going to keep this update shorter than usual and highlight some of the bigger changes.

    If you’re interested in helping write this weekly post, ping @morganestes in #core-weekly-update on Slack.

    Special Note: WordPress 4.3.1 was released this week, with three security-related fixes. Be sure to update your sites!

    Here’s some highlights of recent changes in core, along with some future plans and ongoing initiatives. Remember, Core moves pretty fast. If you don’t stop and look around once in a while, you could miss it.

    • WordPress will support PHP7 when it’s released. Huzzah!
    • HTTP/2 is coming! Here’s a list of tickets that need attention to get WordPress ready.
    • Get involved in Twenty Sixteen, which is in active development on GitHub.
    • Write better commit messages. The world will thank you for it. :)
    • As described in this post by @johnbillion, the show_ui flag for post types now gets fully honored. See #33763 for the ticket discussion.
    • A new helper function, wp_validate_action( $action = '' ), was introduced in [34059] and is used throughout admin instead of directly accessing $_REQUEST['action'].
    • A new file, wp-admin/includes/noop.php, was created to load all of the noop functions for load-script|styles.php and is only loaded by those files. DRYs in the process. [34037] #33813
    • Schema change introduced in [34030] to increase the length of wp_options.option_name to 191 chars. #13310
    • Implement a priority system for Help Tabs to add them at specific positions. [33985] #19828
    • Multisite: Don’t allow sites to be created with the following reserved slugs: wp-admin, wp-content, wp-includes [33952] #33615
    • Updated recommendations for minimum versions of PHP (5.6) and MySQL (5.5), with a special note that Oracle only actively supports MySQL for 5 years after a General Availability release. [33937] [33946]

    For the full report, visit https://core.trac.wordpress.org/log/?verbose=on&format=changelog&rev=34092&stop_rev=33821&limit=400&mode=stop_on_copy.

    Thanks to @adamsilverstein, @afercia, @amereservant, @ankit-k-gupta, @antpb, @austinginder, @azaozz, @BdN3504, @benjmay, @boonebgorges, @bradt, @brettz95, @celloexpressions, @cgrymala, @Cheffheid, @chriscct7, @codeelite, @CoenJacobs, @danielbachhuber, @daniellandau, @dannydehaan, @dd32, @dimadin, @dipeshkakadiya, @dlh, @DrewAPicture, @dustinbolton, @egower, @enshrined, @ericdaams, @ericlewis, @extendwings, @figureone, @filosofo, @gaelan, @GaryJ, @gitlost, @gnaka08, @gradyetc, @gregrickaby, @hauvong, @helen, @imath, @ippetkov, @iseulde, @ixkaito, @jazbek, @jeffstieler, @jeremyfelt, @jesin, @jobst, @johnbillion, @joostdevalk, @jorbin, @juliobox, @JustinSainton, @kevinlangleyjr, @khromov, @kitchin, @kraftbj, @lancewillett, @liljimmi, @lukecarbis, @macmanx, @MatheusFD, @mehulkaklotar, @mercime, @metodiew, @michielhab, @MikeHansenMe, @miqrogroove, @mitchoyoshitaka, @mordauk, @morganestes, @mrahmadawais, @mrmist, @Mte9, @nacin, @netweb, @nikeo, @nikolovtmw, @nofearinc, @obenland, @ocean90, @OriginalEXE, @Otto42, @paulwilde, @pavelevap, @pento, @peterwilsoncc, @racaseh, @rachelbaker, @rajnikmit, @rmccue, @rommelxcastro, @sc0ttkclark, @scribu, @SergeyBiryukov, @sillybean, @solarissmoke, @stevehenty, @swissspidy, @tmatsuur, @trepmal, @tyxla, @umeshnevase, @utkarshpatel, @wen-solutions, @wenthemes, @westonruter, @wojtekszkutnik, @wonderboymusic, @yoavf, and @zeo for their contributions!

  • Ryan Boren 4:43 pm on September 2, 2015 Permalink |
    Tags: , maintainership   

    Component Page Updates for 4.4 

    Now that 4.4 is underway, let’s update the component pages to reflect 4.4 activity. The Customize, Editor, and Press This pages serve as good templates, though they all need 4.4 updates. The component pages are targeted at beta testers. They should describe the component, list milestones (roadmap), and explain what needs testing and how to test it. Good component pages assist triage. For details, see the previous round of component page updates.

    Also, if your component has a corresponding Slack chat, link to the component page from the chat’s channel topic. This assists using Slack in beta testing flows.

    Component maintainers, here are your component pages…

    (More …)

  • Morgan Estes 5:03 am on September 2, 2015 Permalink |
    Tags: ,   

    WordPress Core Weekly – Aug. 24-30, 2015 

    Welcome back to the weekly core development recap post, with highlights from Trac changesets and other development updates for 4.4. This week’s update covers changesets [33721][33820], Aug. 24-30, 2015. That’s a lot of changes, but there are a few that developers need to be especially aware of:

    • File restructuring: new class and functions files have been introduced, and existing files used as loaders for the new files for backwards compatibility.
    • File and class documentation enhancements: ensuring every file gets a standard file header, even if that file only contains a class that is itself documented.
    • Switching themes now takes menu locations into account so the new theme (maybe) gets the locations of the current theme.
    • New hooks introduced: 'invite_user' (Multisite users) and 'wp_verify_nonce_failed'.
    • The Twenty Sixteen theme is being developed on GitHub.

    Now on to the firehose…


    • Bump h3 headings to h2 on various admin screens for better accessibility:
    • Network Admin: Hide the bulk actions checkbox for super admins. [33777] #28529
    • Avoid PHP notices in redirect_canonical() and _wp_menu_item_classes_by_context() if $_SERVER['HTTP_HOST'] is not set. [33775] #32229


    • Remove error from the query variables when cleaning up a URL in wp_admin_canonical_url(). [33770] #32847
    • Prevent unintended password change after clicking “Generate Password” and then “Cancel” when editing a user profile. [33766] #33419
    • When wp_json_encode() calls json_encode(), the latter will generate warnings if the string contains non-UTF-8 characters. No one likes warnings, so we need to do something about that. [33747] #33524
    • Add oEmbed support for ReverbNation. [33745] #33207
    • Remove rounded corners from “Choose from the most used tags” result in Tags meta box. [33742] #31560
    • Add some more data for shortcode unit tests. [33740] #33455
    • Allow these CSS properties in KSES: min-height', 'max-height', 'min-width', 'max-width' [33739] #31949
    • Pass option name to option and transient filters with dynamic names. [33738] #28402
    • In get_home_url(), import the $pagenow global to avoid having to check if it exists before comparing against it. [33736] #33545
    • In WP_Users_List_Table::single_row(), $actions is not always set before being used. [33735] #33491
    • foreach is a statement, not a function. [33734] #33491
    • Instead of [33713], allow WP_Posts_List_Table::get_bulk_actions() to check edit_posts AND delete_posts. [33733] #29789
    • TinyMCE: ensure the wordpress plugin is loaded before calling _createToolbar(). [33728] #33393
    • With a few modifications in wp-admin/menu.php, we can eliminate the extra logic for Post and Page menu registration. Instead, they can just declare menu_position on post type registration. [33723] #16865
    • WP_Query: add changelog for the title param after [33706] [33722] #33074

    Restructured some files for separation of purpose, so class files only contain classes, functions files only contain functions, and the existing file loads the new files for backwards compatibility.


    Move WP_Tax_Query into class-wp-tax-query.php and functions into taxonomy-functions.php; taxonomy.php contains only top-level code and loads the new files. [33760] #33413


    Move WP_Post into class-wp-post.php and functions into post-functions.php. post.php contains only top-level code and loads the new files. [33759] #33413


    Move classes into their own files, and functions into its own:

    • class-wp-roles.php
    • class-wp-role.php
    • class-wp-user.php
    • capbilities-functions.php

    capbilities.php contains only top-level code and loads the new files. [33752] #33413


    Move classes into their own files and functions into its own:

    • class-wp-http-cookie.php
    • class-wp-http-curl.php
    • class-wp-http-encoding.php
    • class-wp-http-proxy.php
    • class-wp-http-streams.php
    • http-functions.php

    http.php contains only top-level code and loads the new files, so this is 100% BC if someone is loading http.php directly.

    class-http.php requires functions from http.php, so loading it by itself wouldn’t have worked.

    WP_Http remains in class-http.php. [33748] #33413


    Move WP_Meta_Query into class-wp-meta-query.php and functions into meta-functions.php. meta.php contains only top-level code and loads the new files. [33761] #33413


    Move WP_Rewrite into class-wp-rewrite.php, functions into rewrite-functions.php, and constants into rewrite-constants.php. rewrite.php contains only top-level code and loads the new files.

    The rewrite functions have all kinds of cross-dependencies (like WP_Query), so loading the file by itself would have been bizarre (and still is). [33751] #33413


    Move WP_Comment_Query into class-wp-comment-query.php, and functions into comment-functions.php. comment.php contains only top-level code and loads the new files. [33750] #33413


    Move WP_User_Query into class-wp-user-query.php and functions into user-functions.php. user.php contains only top-level code and loads the new files. [33749] #33413


    Move classes and functions into their own files:

    • class-wp-widget.php
    • class-wp-widget-factory.php
    • widget-functions.php

    widgets.php contains only top-level code and loads the new files. [33746] #33413


    It’s important for every file in WordPress, regardless of makeup or architecture, to have its own file header, even if the file contains nothing but a class. When parsed, files and classes are mutually exclusive and should be documented with this in mind. [33755] [33756] #33413

    • Bring the file header and class DocBlock summaries for class-wp-widget.php in-line with the intention of the docs standard:
      • File headers: What the file is
      • Class DocBlocks: What purpose the class serves. Mentioning the class name in the class DocBlock is redundant [33816] #33413
    • Add inline-docblocks for the require_once() calls that now bring in the WP_Widget and WP_Widget_Factory classes, as well as general core widgets functionality, as of [33746]. [33758] #33413
    • Add a file header description and @since version to wp-includes/widget-functions.php, introduced in [33746].
      Also adds sub-section headers per the inline documentation standards for syntax. [33757] #33413
    • Add a file header to wp-includes/class-wp-widget-factory.php, created when the WP_Widget_Factory class was moved to its own file in [33746]. [33756] #33413
    • Correct the hook docs for the user_profile_update_errors action. [33769] #33537
    • After [33764], fix docblock formatting for wp_list_categories(). [33765] #33460
    • Use proper array documentation formatting for wp_list_categories().
      This changeset also corrects a few parameter descriptions, and adds a few that
      were previously missing. [33763] #33556
    • Fix copy pasta in wp_cache_decr() doc block. [33809] #33548
    • The type for the $t_time parameter in the post_date_column_time filter docs should be string, not array. [33731] #33540
    • Document the default comment data arguments for wp_new_comment(). [33730] #32369
    • After [33698], wrap the time constants in a DocBlock template. [33737] #33397
    • Clarify the return description for wp_create_user() to illustrate that a WP_Error object will be returned on failure. [33725] #33321

    Add changelog entries for a variety of hook doc parameters added in [33738]:

    hook parameter changeset/ticket
    set_site_transient_$transient $transient [33794] #28402
    site_transient_$transient $transient [33792] #28402
    pre_delete_site_option_$option $option [33789] #28402
    pre_add_site_option_$option $option [33788] #28402
    pre_site_option_$option $option [33785] #28402
    transient_$transient $transient [33783] #28402
    option_$option $option [33779] #28402
    pre_option_$option $option [33768] #28402
    pre_set_site_transient_$transient $transient [33793] #28402
    pre_site_transient_$transient $transient [33791] #28402
    pre_update_site_option_$option $option [33790] #28402
    site_option_$option $option [33787] #28402
    default_site_option_$option $option [33786] #28402
    pre_set_transient_$transient $transient [33784] #28402
    pre_transient_$transient $transient [33782] #28402
    update_option_{$option} $option [33781] #28402
    pre_update_option_$option $option [33780] #28402
    default_option_$option $option [33778] #28402


    • Get the correct theme when template and stylesheet were both passed as arguments. Fixes a bug introduced in [21131] where $new_theme got set before the second argument was
      appropriately handled, causing the current_theme option to later always be updated to the parent theme’s name. [33815] #32635


    • Improve/update escaping in default widgets:
      • wrap some variables in esc_attr() before echoing
      • replace some strip_tags() calls with sanitize_text_field()
      • call esc_url() when wrapping some URLs [33814] #23012
    • Improve/update escaping in WP_Widget_Pages. [33813] #23012
    • Switch back to using array_key_exists() instead of isset() for widget instance existence check.
      Reverts unnecessary change in [32602] since array_key_exists() does actually work with ArrayIterator objects.
      Merges [33696] to the 4.3 branch. [33721] #32474, #33442



    • Fix the doc block syntax for the 'wp_get_current_commenter' filter. [33811] #33304
    • get_comment_count() currently increments awaiting_moderation when comments are in the trash. This occurs because case 0: will match any value passed to switch that is a string that isn’t specified in the list of cases. This is terrifying.
      Cases for 0 and 1 should be '1' and '0'
      Add unit tests for get_comment_count(). Currently, there are none. [33806] #33414


    • Favor using the consistent and agnostic string ‘Attach’ over ‘Attach to a post’ in the media list table. [33810] #33515
    • Make a period translatable. [33802] #33594
    • Switching themes: if the new theme doesn’t have nav_menu_locations defined, but the old theme does, copy the old theme’s nav_menu_locations into the new theme’s theme mods. [33808] #18588


    • Improve the reliability of the crop returned by image_get_intermediate_size() and add a bunch of unit tests to tests/image/intermediate_size.php. [33807] #17626
    • When inserting an image into a post, the values in wp.media.controller.Library should not default to linking the image when no user settings are present.
      The default display setting value for link is now none. User settings persist and will override or confirm this value based on user actions. [33729] #31467

    Posts, Post Types

    • In get_post_type_labels(), ensure that filtered labels contain all required default values. [33776] #33543
    • Don’t change the View Post button permalink in the sample permalink HTML when updating the slug on a published or future post. [33773] #32954
    • Pass taxonomy name to filters in get_adjacent_post(). [33805] #33568
    • Make post meta box toggles accessible. [33762] #33544


    • Improve the efficiency of is_user_member_of_blog() by removing its use of get_blogs_of_user(). Adds additional tests. [33771] #32472
    • Add 'invite_user' action that fires immediately after a user is invited to join a site, but before the notification is sent. [33732] #33008


    • In wp_list_categories(), ‘current_category’ should accept an array of values. [33804] #33565
    • Introduce $hide_title_if_no_cats parameter to wp_list_categories(). [33764] #33460
    • Rename param added to wp_list_categories() in [33764] to $hide_title_if_empty. [33767] #33565
    • Term Splitting: Switch to a faster cron unschedule process to benefit sites with thousands of affected jobs. Fix the cron hook name in the failsafe rescheduler. [33727] #33423
    • In WP_Query::parse_tax_query(), allow ‘cat’ and ‘tag’ querystrings to be formatted as arrays. [33724] #32454, #33532


    • Simplify the weeks-per-year calculation WP_Date_Query::validate_date_values(). [33803] #30845


    • Bring network admin user searching to parity with single site user searching by wrapping search terms in asterisks. This means that searches don’t require an exact match and therefore significantly reduces friction when searching for users on the network admin screens. [33801] #32913

    Bundled Theme

    Correct license information in readme.txt.

    Text Changes

    • Drop the hyphen from e-mail and standardize on email.
      The AP Stylebook changed this in 2011, and we’re woefully inconsistent, so let’s go with the standard. [33774] #26156



    • Add 'wp_verify_nonce_failed' action that fires when nonce verification fails. [33744] #24030
    • Fire the check_ajax_referer action on failure as well as success. [33743] #33342

    Build Tools

    Thanks to @azaozz, @BinaryKitten, @boonebgorges, @bordoni, @Cheffheid, @chipbennett, @danielbachhuber, @dd32, @DeBAAT, @dimadin, @DrewAPicture, @ebinnion, @egill, @eherman24, @ericlewis, @garza, @hauvong, @helen, @janhenckens, @jjeato, @jmayha, @joedolson, @joehills, @joemcgill, @johnbillion, @KalenJohnson, @kitchin, @liljimmi, @luciole135, @mako09, @MikeHansenMe, @miqrogroove, @morganestes, @niallkennedy, @nikeo, @obenland, @Otto42, @pavelevap, @pento, @peterwilsoncc, @rachelbaker, @rhubbardreverb, @sammybeats, @sboisvert, @scribu, @SergeyBiryukov, @Shelob9, @tyxla, @Veraxus, @vilkatis, @Viper007Bond, @voldemortensen, @welcher, @westonruter, @wonderboymusic, and @yamchhetr for their contributions!

  • Samuel Sidler 2:47 pm on July 10, 2015 Permalink |
    Tags: , ,   

    Feature Plugin Chat on July 14 

    Hey everyone!

    As I mentioned at this week’s dev chat, we’re going to have a feature plugin chat this coming Tuesday July 14 19:00 UTC.

    If you have an idea that you’d like to propose as a feature plugin or if you have a feature plugin already in development, come to the chat and comment below with the following details:

    • A brief (one paragraph) overview of your feature plugin proposal.
    • Current status (e.g. idea, planning, early/late development, existing plugin, testing, stable, etc). If you’re just in the idea stages, list any existing plugins that are similar to your idea.
    • A list of those involved or already interested in your feature plugin (including you!).
    • A link to the plugin in the WordPress.org plugin directory and/or GitHub repository, if applicable
    • What you’d like help with (scoping, planning, wireframing, development, design, etc).

    Please leave just one comment per feature plugin/idea so others can comment on the ones they’re interested in.

    Current feature plugin leads: We want your feature plugins here too! Please post an update with the information above.

    • Ryan Boren 2:36 am on July 15, 2015 Permalink | Log in to Reply


      Working on the latest Today in the Nightly post reminded me that I’ve been wanting a carousel feature plugin. The galleries on this post are handled by Jetpack’s carousel. Clicking/tapping an image pops up the image in a modal. The single images are not handled by JP’s carousel. They get the core behavior of following the bare image link. This is a bad experience, especially on mobile. Even on desktop, clicking the single images is a far worse experience than the carouseled images. Bare image links present no nav. You’re only way back is browser back history. This should work out of the box.



    • dshanske 2:01 am on July 15, 2015 Permalink | Log in to Reply

      Overview #32844 – There is interest in trying to put together a group to work on revamping Post Formats. This would not necessarily be the Post Formats UI that has laid dormant since 3.6, but a serious look at the feature as it exists today and how it can be refined in the same way the long-abandoned Press This feature was refined.

      I’m not looking to propose something with the scope of the WordPress 3.6 work, as I think the starting work is refining how Post Formats work. This includes better defining their use, producing examples of the types(documentation), looking for opportunities to better integrate them into existing parts of WordPress and enhance their functionality.


      I think @helen laid out a reasonable list of goals.

      “…existing content must be considered, as well as migration paths for those who currently use plugins/themes that store into meta. This may include things like auto-detection in Press This, modular content building, creation-only UI affordances, and so forth.”

      I’m willing to put in some time on this, and contribute out of my limited ability. Looking for interest.

    • Joe McGill 1:25 am on July 15, 2015 Permalink | Log in to Reply

      For posterity…

      **RICG responsive images**

      **Big idea:** to bring responsive image markup natively into WP core.

      **Current status:** In development, stable (8,000+ active installs) could be considered for a 4.4 merge but will need some shepherding.

      **Plugin devs:** @tevko, @joemcgill, @dnewton, @jaspermdegroot, with consultation from @wilto (and a host of others).

      WP.org: https://wordpress.org/plugins/ricg-responsive-images/
      GH: https://github.com/ResponsiveImagesCG/wp-tevko-responsive-images

      **Get involved:** We could use dev feedback, more testing (particularly against non-standard setups).

    • Ryan McCue 4:43 pm on July 14, 2015 Permalink | Log in to Reply


      The WP REST API adds a JSON-based REST API to WordPress, allowing accessing and modifying your site from a modern API.


      Ready for merge (version 2). Always more work to continue in the meantime.


      @rmccue, @rachelbaker, @danielbachhuber, @joehoyle


      https://wordpress.org/plugins/json-rest-api/ (v1 only)

      Get Involved

      We’re mostly deep focussing on getting it ready for merge, but we always need help on documentation and associated projects (OAuth, Basic Auth, client SDKs).

    • Pascal Birchler 12:59 pm on July 14, 2015 Permalink | Log in to Reply

      oEmbed for WordPress Posts

      Basically, we want to make WordPress an oEmbed provider. Users should be able to paste an URL from a WordPress blog and the post gets embedded right away. Difficulties here are discovering other WordPress sites as oEmbed providers and whitelisting them. The oEmbed endpoint requires the WP-API to be in use, so this can’t land in core until the API does.

      Current status: Idea / early development. There’s an existing plugin on GitHub we can build upon and we already have mockups of the desired end result.

      People already involved:


      And all the others who have joined the discussion on Trac.

      Project links

      Ticket: #32522
      Plugin on GitHub: https://github.com/swissspidy/oEmbed-API

      What we need help with: Mostly design and development, especially the oEmbed auto-discovery part.

      I’ll be around tonight for the chat, the others can’t make it unfortunately.

    • Weston Ruter 10:54 pm on July 13, 2015 Permalink | Log in to Reply

      Customize Partial Refresh

      Refresh parts of a Customizer preview instead of reloading the entire page when a setting changed without transport=postMessage. The goal with this plugin is to eliminate full-page refreshes as much as possible, as they are extremely bad for performance. This has been implemented in Core now for menus in the Customizer as of 4.3 beta. This plugin currently implements partial-refresh for widgets, but it also will abstract the functionality into a general API for developers to register their own partial-refreshable regions. This plugin has been floating around as a feature plugin for awhile. Blue sky: if we can eliminate full-page refreshes, we can start to introduce controls inline with the preview (e.g. widget controls appearing with their widgets), and even eliminate the Customizer iframe altogether since the Customizer pane could then slide-in on any existing frontend page the user is on without having enter into a completely different Customizer state; when done, they can just collapse the Customizer away and continue on their way browsing the site.

      Current status: existing plugin, development, testing

      Contributors: @westonruter

      Project links:

      Areas to contribute: identifying use cases and designing API for registering partial-refreshable region.

    • George Stephanis 4:57 pm on July 13, 2015 Permalink | Log in to Reply

      Two-Factor Authentication

      Simple username/password authentication is fast becoming insufficient for the modern web. Several plugins so far have begun implementing methods for running two-factor authentication through varied systems, but none of them play well with one another. Our goal is to get a framework for two-step, two-factor authentication into core with several default providers (emailing a code, TOTP, and FIDO U2F) that core can support without any dependency on external providers, and keep it extensible, so that third-party plugins can add in new methods, such as Clef or TXT codes.

      Current Status: Active development, probably ~60% complete. Some providers need fleshed out, and the system needs backup provider support and some UI help. Also probably needs a couple audits from varied perspectives to make sure it solves everyone’s use cases and is accessibility friendly.

      Interested folks (who have expressed interest on Twitter or directly):

      @brennenbyrne (and the Clef gang)

      Probably some others I’ve missed.

      Current repository: https://github.com/georgestephanis/two-factor

      I’ve got the plugin approved for the .org repo, I just wanted to get backup methods fleshed out before starting porting it across.

      What we need help with: Code audits, design help, security audits, accessibility audits, development time fleshing out providers.

    • Nick Halsey 8:06 pm on July 12, 2015 Permalink | Log in to Reply

      Customizer UI Experiments
      Customizer UI Experiments is a new feature-plugin designed to be used on an ongoing basis for testing smaller UI/UX changes in the Customizer before rolling them into core. It contains several components that can be merged into core and subsequently removed from the plugin on an individual basis, with new components added as ideas are proposed. This single plugin to cover several distinct proposals allows testers to evaluate UI changes without wading through patches on different tickets scattered throughout trac. It also gives us a place to evaluate patches with feedback from a larger audience, hopefully improving our processes around UI-related Customizer tickets, which have had issues in the past. As a general rule, components added to this plugin should have a trac ticket first. This is a great plugin for multiple people to have commit access to, so if you’re interested in working on it (primarily porting patches to plugin form, and maintaining the plugin as components are added, updated and removed), please let me know and I can add you.

      The plugin is awaiting review on the .org repo, and initially contains an implementation of the patch on #32296. Components implementing #31195 (device-preview buttons) and #29158 (testing approaches to increasing visual contrast and improving focus styles for accessibility) are in the works as well.

      Current Status: This is a slightly different type of feature-plugin, so it will always be in a stable mode where testers can try it out (and leave it on) on their sites, with features coming in and out as they’re developed and merged into core. This is a sort of preview and testing ground for minor changes and features to come. Scope is strictly limited to changes with the Customizer UI itself – this plugin should avoid implementing larger features that add new panels/sections/settings/controls. Once the plugin is available on .org, I’ll link it on the tickets that it implements currently.

      Involved: I’ve done the initial development and scoping, with @voldemortensen already volunteering to help out and have commit access. Anyone interested in welcomed to jump in on Customizer-ui-related trac tickets and ping us in #core-customize or #design on Slack to discuss ideas.


    • Nick Halsey 7:51 pm on July 12, 2015 Permalink | Log in to Reply

      Background Image Cropper
      This plugin adds cropping to background images, to bring the feature into closer parity with header images. The plugin is currently awaiting review for the plugin repo, but is trivial code-wise and more about deciding whether this is a feature that users need/want. See also #32403.

      Current Status: Late development. The plugin is not currently functional due to a critical core bug in trunk that will be resolved in #29211 (specifically, it prevents the Customizer from loading, but there are additional issues that need to be cleaned up with the new API here). Once that core ticket is resolved in 4.3, the plugin will be fully functional and only potentially require minor tweaks.

      Involved: @johnbillion first proposed the idea in #32403, and I’ve built the plugin. Now, this feature is all about getting the word out about the plugin (once 4.3 is out, since that’s the required version), and gauging user interest. I suspect that we may run into issues here with some of the broader problems with the background images feature, and it remains to be seen whether cropping should be introduced without exploring broader changes here. Feedback and ideas welcome.


    • Nick Halsey 6:48 pm on July 12, 2015 Permalink | Log in to Reply

      Customizer Theme Installer
      Customizer theme installer would build on the Customizer Theme Switcher plugin merged in WordPress 4.2, bringing .org-repo-browsing and theme installation into the Customizer experience. The current idea is that entering theme-installation mode would bring the Customizer controls area full-width, hiding the preview, and the different tabs on the existing admin screen would be available, along with an “installed” tab. This would incorporate “shiny” theme installs – for each theme there are two options: “install” and “install & preview”. We would remove the existing theme-install previewer and instead offer the ability to download a theme and preview it in the Customizer with your actual site in one click. The basic install action would allow multiple themes to be installed at once, then the user could go through them to preview within the Customizer using the existing workflow.

      Current status: idea/design/wireframing

      Involved: @folletto and I (@celloexpressions) have tossed several ideas around and done some initial branstorming and wireframing, building on the work done in 4.2. I was originally planning on working on this for 4.3, but did Menu Customizer instead. I’d like to set up a meeting in the next couple weeks to get going on this effort and try to develop a merge-ready plugin by the time 4.3 is released, to be ready for merge in 4.4. Based on Customizer Theme Switcher (which was developed in only a few days), this effort will likely be more design/UX-heavy than development-heavy.

      • Paal Joachim Romdahl 7:02 pm on July 13, 2015 Permalink | Log in to Reply

        Features added to the customizer will these also be added outside of the customizer as well? For instance to the settings section. (Just thinking in general here).

    • Daniel Bachhuber 9:41 pm on July 10, 2015 Permalink | Log in to Reply


      Shortcake adds a user interface to shortcodes.


      Late development. The next slated version is 0.5.0. You can easily skim through many discussions to date.


      @danielbachhuber, @mattheu, @goldenapples, @davisshaver and others



      Get Involved!

      At this time, we’d very much appreciate involvement in the form of documentation and user testing.

    • jrf 4:37 pm on July 10, 2015 Permalink | Log in to Reply

      > Overview of your feature plugin proposal.

      Dependency management for themes and plugins the WordPress way.
      Allow themes and plugins to indicate dependencies on (other) plugins and providing an easy way for admin users to install, update and activate those. Will include activation prevention if dependencies are not met and providing cascading deactivate of dependents when a providing plugin would be deactivated.

      > Current status

      Existing external library which is widely used. +/- 6% of all themes in the repo use it, also used by a large number of premium themes and numerous plugins.
      A large refactor is planned and knowing what parts would be acceptable for core would be useful before starting the refactor.
      Roadmap for refactor from before this proposal (open to change per scoping): https://github.com/TGMPA/TGM-Plugin-Activation/issues/394

      > People involved

      Thomas Griffin – Project Owner & creator of the original TGMPA library
      Gary Jones – Project Lead
      Juliette Reinders Folmer – Lead Developer

      Suggesting this as a feature plugin is inspired by numerous users who keep suggesting it should be part of core.

      > Link


      > What you’d like help with

      Scoping: the libary currently features some functionality which may or may not be acceptable for core. Advise on this would be helpful before starting the refactor.
      Ref: https://docs.google.com/document/d/1abkiqT15SSboJVF8a16QDOL8o8Ocy4EHxsoZKwuwMFY/edit?usp=sharing

      Placement in the admin/user interface: currently plugins and themes can influence where the admin screen for TGMPA will show up. In the roadmap for 3.0 we’ve already included removal of this functionality and creating a set place for the admin page. Thoughts on where this should be and/or whether this should be integrated in an existing admin page would be helpful.

    • BrashRebel 3:49 pm on July 10, 2015 Permalink | Log in to Reply

      The TV team is collaborating on a plugin which places tutorial videos in the contextual help menu. The videos come from WordPress.tv and provide a visual walkthrough of the current screen in the wp-admin. The plugin is being developed for the purpose of assisting beginner WordPress users through video. The idea of proposing it as a future feature plugin has been briefly discussed.

      Current status: existing plugin
      Interested parties: @brashrebel @jerrysarcastic @roseapplemedia @ubernaut @johnparkinson
      Github: https://github.com/brashrebel/wptv
      We’d like help with:

    • Pascal Birchler 3:13 pm on July 10, 2015 Permalink | Log in to Reply

      At the moment you can’t edit multiple users at once, which is pretty annoying for some use cases. Maybe this is something that should be explored as a feature plugin.

      Status: Idea
      Similar plugins: https://github.com/Automattic/bulk-user-management (old, multisite-only)

      I could help with scoping, planning and development if there’s enough interest. But I’ll probably end up developing something anyway 😉

      Relevant core tickets: #28050 and #32356

    • Pascal Birchler 3:10 pm on July 10, 2015 Permalink | Log in to Reply

      I think there was a discussion about a toolbar feature plugin as mentioned in #32678. Basically, it should explore adding (most of) the admin menu to the toolbar.

      Status: Idea
      Similar plugins: https://wordpress.org/plugins/admin-bar-plus/

      I’d love to help with development and testing.

  • Konstantin Obenland 8:58 am on June 11, 2015 Permalink |
    Tags: ,   

    Dev Chat Summary, June 10 

    Agenda, Slack log.

    Menu Customizer Status Update (#)
    The a11y review did not unveil any blockers, although it wasn’t done on the feature branch the team is currently working on. Introduction of a blocker there was deemed unlikely however. A new plugin version can’t be released since it’s now dependent on some core patches being applied.

    For the rest of the requirements: The biggest blockers are almost complete, Customizer setting re-architecture and sub-menu drag & drop. The settings re-architecture has been integrated into JS for the nav menu items, allowing nav menus to be edited, added, removed all with 100% previewability and not making any changes to the DB. Once Save & Publish is done, any newly created nav menu items get inserted at that time. Same goes for nav menu deletion. The submenu drag & drop has been merged into the same branch and it is all working together now.

    The biggest outstanding pieces are:

    • adding back the ability to add/remove entire menus
    • updating keyboard-accessible reordering to work with new menu settings
    • more unit testing for PHP, and write tests for JS

    Estimated time of completion is June 11, which leaves 5 – 6 days to merge.

    Admin UI (#)
    Even more prep work has gone into list tables, now working on the responsive part on #32395. They have gotten some feedback so far, would love more even on the rough cuts. Helen will be at wordcamp philly’s contributor day this weekend, looking to knock through a bunch of the low hanging fruit on the screen sweep spreadsheet, and find takers for some make-flow tickets (#29906 in particular). She has some catch up to do with other contributors on visual regression testing and media-new, which will happen at tomorrow’s meeting.

    Network Admin UI (#)

    Objectives from last week:

    • #32434 is in. Jeremy is still poking at #22383 and #32503 with a target of this evening.
    • They had no additional iterations on WP_Network and WP_Network_Query, but @jjj is working on having something this week.
    • Did not yet generate discussion around HTTPS. Moving this objective along to this week.
    • They made quite a bit of progress with flows. @kraft added Nexus and @earnjam has iPad screencaptures he will be publishing shortly. Their next push is to start creating tickets. Jeremy wrote a post to try and drum up support – https://make.wordpress.org/core/2015/06/05/help-test-and-capture-the-network-admin-ui/ – and they had a handful of people hop in. Pretty optimistic that they’ll start making progress here, especially with a couple contributor days this weekend.

    Objectives for this week:

    • New tickets to address found issues in flow. These issues logged in the screen sweep spreadsheet.
    • Iterations on WP_Site and WP_Network. Discussion around iterations.
    • #22383 and #32503 committed.
    • Write post, generate discussion around HTTPS in multisite.

    Better Passwords (#)
    Mark turned the plugin into a patch for the new UI. After a cleanup, that can land, and we can iterate a bit, as well as tackle the new user password flow, which is different. The expiration of reset links (#32429) needs testing (human and unit), before that lands. And the “notify users of password and email changes” patch (#32430) needs a review on the hooks in it. I’m not sure we’re passing the right things along. Like, email instead of the whole user array.

    Favicons (Site Icon) (#)
    There’s been a status update on make/core. It’s looking like #29211 would be a better approach to a reusable control with image cropping functionality. So John is wondering whether we should aim for 29211 for 4.3 and site icon for 4.4. On the topic of using the Customizer or not: much of the image cropping control for the header image is also used on the old header image screen (it’s mostly media library and ajax functionality), so it’s not necessarily tied to being a customizer control.
    Let’s meet today June 11 2015, 20:00 UTC to discuss what a good approach could look like.

    Next chat will be on June 17 2015, 20:00 UTC

  • John Blackbourn 2:29 pm on June 10, 2015 Permalink |  

    Site icon and image cropping controls 

    A couple of weeks later than intended, a brief update on the site icon functionality which has been touted as a potential feature for 4.3. The site icon functionality aims to provide an admin UI (via the Customizer, at least initially) for users to upload an icon which is then output as a favicon and associated touch icons, while also allowing themes or plugins to re-use the icon in other places as they see fit.

    The existing header image control in the Customizer (and its corresponding functionality on the old custom-header screen) provides a means for uploading a header image and then cropping it to the desired size. Unfortunately this control is fairly tightly coupled with the header image functionality, and therefore extending it for use with the site icon control has meant duplicating a lot of code.

    It’s looking more and more like #29211 should be tackled before the site icon functionality, in order to avoid this duplication and in order to allow other controls to provide a croppable image upload (such as for background images in #32403).

    Due to my limited availability to work on the site icon feature in the coming weeks, I think it would be worthwhile instead focusing on #29211 and the introduction of an abstracted control that supports image cropping, which can then be used for the site icon and custom background controls.

    The current non-working site icon feature plugin can be found in this repo on GitHub. It uses considerable code from the custom header image control. If someone wants to take that and run with it that would be great, or if someone wants to tackle #29211 instead, that would be great too.

    • imath 5:29 pm on June 23, 2015 Permalink | Log in to Reply

      Hi @johnbillion thanks a lot for your great work about this feature, i’ve been exploring the plugin on the github repo and just posted some suggestions into a pull request :)

    • Nick Halsey 1:40 am on June 11, 2015 Permalink | Log in to Reply

      A note regarding #29211 – that was originally written before 4.1, when we redid the other core media controls. So the best approach would probably to make a cropped-image control that extends WP_Customize_Media_Control, using header images as inspiration, then update the header image control to leverage it. Header images no longer use the latest and greatest in the Customizer, so it’s worth a bit more of a rethink than generalizing their functionality I think.

    • Mel Choyce 5:14 pm on June 10, 2015 Permalink | Log in to Reply

      Are there any plans to support .ico?

      • Samuel Wood (Otto) 5:45 pm on June 10, 2015 Permalink | Log in to Reply

        ICO files are somewhat difficult to do. Supporting them should be an optional thing, I think, not necessarily a blocker for implementing the underlying support for favicons as png-only to start with.

        A few ICO producing libraries were mentioned in #16434, and if something like this is created as PNG first, then adding on code to also save ICO files would not be difficult if the right library to do so can be found or created.

    • Ciprian 3:11 pm on June 10, 2015 Permalink | Log in to Reply

      Would this replace the Jetpack favicon feature? Would they be developed/maintained in parallel?

    • Greg Ross 2:48 pm on June 10, 2015 Permalink | Log in to Reply

      I spent quite a bit of time working on this problem when I built my OS Integration plugin (https://wordpress.org/plugins/os-integration/), but I didn’t integrate it in to the customize.

    • Marko Heijnen 2:44 pm on June 10, 2015 Permalink | Log in to Reply

      I’m more then happy to help out. Image cropping etc is what I did before.

  • Konstantin Obenland 5:59 am on June 5, 2015 Permalink
    Tags: ,   

    Dev Chat Summary, June 3 

    Agenda, Slack log.

    Menu Customizer Merge Proposal (#)
    @westonruter, @celloexpressions
    We went through the feature plugin checklist and discussed if the plugin was fit for core. It was approved for merge, pending the following conditions:

    Items that should be done before merge:

    • Complete a11y audit.
    • Address possible blockers.
    • Merge php tests.
    • Add JS tests.

    Then with/after merge:

    • Killswitch for plugin.
    • An outline for a fieldguide post.

    Better Passwords (#)
    New password UI on Profile screen, via GH plugin. Generates and shows by default. Lets the user hide, or click into the field and type (in show/hide modes). Also, the strength meter has been more closely integrated. The color wraps around the field, and it is integrated as one “unit” instead of being this button-like thing that floats below it. Mark would like to get the current state turned into a patch and merged, as he thinks it’s a fine inflection point, even if the next steps aren’t ready in time.

    Admin UI (#)
    Got a lot of a11y fixes in play for list tables. A fair number of small/low-hanging fruit issues being noted, which aren’t crucial to hit before beta, so they’ll keep focusing on the bigger items for now. They also started to sync up with #core-flow issues and getting those into the patch and review queue.

    Network Admin UI (#)
    Last week’s objectives and progress:

    • Wrap work on the edit site flow and MS sites list table and then take a look at the add site flow and validation in `update_blog_details()`. We made progress on the edit site flow and are nearing commit readiness for a few patches.
    • Continued progress on WP_Network, WP_Site, WP_Network_Query, and WP_Site_Query. We had quite a bit of discussion on the WP_Network ticket and in Slack. Not much ticket progress, but we’re doing good at continuing to pay attention.
    • More thoughts on tracking scheme in wp_blogs for sites. We discussed this in the meeting yesterday and need to do some more research on impact. There’s some info in the recap, but we’ll also have a call for info/thoughts soon.
    • More flows and network admin UI tickets from those flows. We have iPhone 5s flows from @ubernaut. We need to do more creating of tickets and generating of additional flows.

    Objectives for next week:

    • Have all 3 tickets related to the edit site flow closed and committed.
    • Additional iterations on WP_Network and WP_Network_Query. Please watch this.
    • Generate discussion around tracking site scheme. @jeremyfelt will gather a list of HTTPS related tickets and share.
    • Nexus (@kraft) and iPad (@earnjam) flows. Tickets created for bugs found in existing flows. Volunteers needed!

    And the recap has all the juicy details: https://make.wordpress.org/core/2015/06/03/multisite-office-hours-recap-june-2-2015/

    Favicons (#)
    Site Icon progress has been slow due to him being too busy, but he has a working implementation now which he will put up in a repo on GitHub tomorrow, then he’ll see about liaising with contributors to get feedback, and basically go from there.

    Next chat will be on June 10 2015, 20:00 UTC

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar