Make WordPress Core

Welcome to the official blog of the core development team for the WordPress open source project.

Here, we make WordPress core. Follow our progress with general updates, status reports, and the occasional code debate.

We’d love for you to help out.

Looking to file a bug?

It’s easy to create a ticket on our bug tracker.

Want to contribute?

Get started quickly. We have some tickets marked as good first bugs for new contributors. There’s more on our reports page, like patches needing testing.

We also have a detailed handbook for contributors, complete with tutorials.

Weekly meetings

We use Slack for real-time communication. As contributors live all over the world, there are discussions happening at all hours of the day.

We have a project meeting every Wednesday at 20:00 UTC in the #core channel on Slack. (Find out more about Slack.)

You can find meeting agendas on this blog. You’re welcome to join us or listen in.

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Tammie 7:35 pm on October 2, 2015 Permalink |  

    Update on Twenty Sixteen 

    Everyone has done amazing work getting Twenty Sixteen ready to be brought into core. This year, has seen some experimentation in the way we work by using GitHub. It’s always interesting to explore new ways of working and look at how things are done. In that vein, the experimentation is going to carry on by continuing to use GitHub for all contributions to Twenty Sixteen. Twenty Sixteen now also will require 4.4-alpha.

    Currently Twenty Sixteen syncs nightly to the theme directory and it will now also be added to the nightly build. This should be set up soon. Twenty Sixteen will now get the benefits of both worlds and that’s great news!

  • 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.

  • Aaron Jorbin 5:25 pm on September 30, 2015 Permalink |
    Tags: make/core, , this is so meta   

    Proposal: Make/Core Post Guidelines 

    During the 4.3 retrospective, one commonly mentioned theme was make/core posts and improving their style and language. All active contributors should review this post and comment with your feedback. This is a DRAFT and a PROPOSAL, it is not a whack from above with Mjölnir. After revising, this document will live in the core handbook.


    The Make WordPress Core Blog (make/core) is the official blog of the WordPress core team. It is read by thousands of people, many of which don’t know the intricacies of WordPress core or that don’t fully understand the process of how core is developed. In order to ensure the best experience possible for the developer community, these guidelines are developed with the reader in mind. The goal of most make/core posts is two-fold: to generate feedback from the developer community (including testing) and to ensure developers know about changes and can plan accordingly.

    When to write a post

    All API changes should have a post written on the make/core blog, ideally no later than the first week of the beta period.   Examples of API changes that should be announced include, but are not limited to: new filters, new actions, changed order of hooks, substantial enhancements to queries (The Boone Gorges Rule), Doing a ticket binge on a component, changing the purpose of a parameter in a hook, and new general helper functions.

    Grouping related changes into one post is fine. For example, a single post called “Customizer changes in WordPress 4.2” is fine, rather than individual changes about each commit. If in doubt, discuss your posting plans during the weekly dev chat.

    Changes should be announced as early as feasible. There is almost always more feedback on make/core posts than in Trac tickets. This feedback is important to the development process.

    Peer Review

    It is strongly encouraged to ask a committer to proofread a post before publishing it. This is to ensure that you look your best when publishing a post. Merge Proposals should always be read by the release lead (or a designee) before posting. Release dev notes should be read by the release lead (or a designee) before publishing.

    Style and Substance

    First Person pronouns should be avoided. As the blog is the official voice of the core team, you should keep your personal thoughts out of the body of the post and instead put them in comments.

    In general, the word “We” should be avoided without it being very clear who the group is you are speaking about being a member of.

    Posts that are designed as Requests for Comments or are draft roadmap in nature should make sure to highlight that it is a draft proposal. Highlight this in the title and in the opening paragraph.

    Many people reading make/core don’t speak English as a first language (or in the case of Jorbin, don’t read or write in any known language). Keep that in mind when choosing words. It’s better to keep it simple than it is to sound smart. In general, the tone should be similar to WordPress: Friendly.

    Meeting Announcements

    When announcing a meeting, you should always use the time shortcode so that visitors see when a meeting is in their local time. You should also include what slack channel the meeting will take place in.


    Almost all posts are related to a specific component, please tag them with the component name.
    For announcements related to a specific release, please tag them with the release number.
    For announcements of API changes, including additions, please tag them with dev-notes.
    For posts related individual projects and initiatives, please tag them consistently with a project name.

    • Ryan Boren 2:44 pm on October 2, 2015 Permalink | Log in to Reply

      Most feature plugin merge proposals have these tags. Some of the new posts do not have them.


      Merge proposals could use their own checklist that includes things like a detailed call for testing targeted at beta testing audiences.

    • bobbingwide 9:21 am on October 1, 2015 Permalink | Log in to Reply

      Re: It is strongly encouraged … to proofread.
      Suggest correcting the spelling of Guidelines in the subject.

    • Ryan McCue 1:00 am on October 1, 2015 Permalink | Log in to Reply

      In general, the word “We” should be avoided without it being very clear who the group is you are speaking about being a member of.

      While I agree in general with the guidelines, I disagree with this part. Generally, I think it’s pretty clear what group you’re part of, and it helps give it a lighter and more conversational tone.

      • Dion Hulse 8:44 am on October 1, 2015 Permalink | Log in to Reply

        Unfortunately it’s often very murky slope though.
        It’s often clear to those of us who are active, but for those who are not, or for whom English is a second (or third) language, it can be difficult to distinguish it from the person or team vs. “WordPress said this” – and that’s what the Guideline is hoping to avoid, cases where something is read out of context.

        Even I trip up on “we” being used elsewhere sometimes, I often don’t know who “we” is until I look up the persons background to work out what group the person is involved with.

        This isn’t designed to outlaw the usage of ‘we’, just to clarify that it should be avoided unless it’s abundantly clear to someone who knows little or nothing about you as to who is included in that we.

      • Samuel Sidler 11:50 am on October 1, 2015 Permalink | Log in to Reply

        What Dion said. :)

        I think there are situations when it will make sense to say “we” but it should always be preceded or followed by the group speaking. For example, “we, the Customize component maintainers, discussed…” If you’re referencing a meeting you can avoid “we” altogether with something like “those of us in attendance” and list those who were in attendance at the beginning or end of the post.

    • Knut Sparhell 11:06 pm on September 30, 2015 Permalink | Log in to Reply

      1. This seems like a good start for a set of guidelines.

      2. When to post, what to post, who to post this, should be a set of rules or best practices, separate from how to post and the guidelines for the content, tone and language of such a post.

      3. This a core development blog, and the audience is developers (but not only coders). Don’t make it more simple than necessary. Non-developers, end users, will have other sources. See 4. below.

      4. Please avoid acronyms not very common among developers globally. Example: API is ok, SXSW is not.

      5. Important changes in workflow for end users should be announced or proposed on the wordpress.org/news blog (too), may be with a link to a post on this blog. It seems the news blog is only used for release announcements. There’s never anything about what is, or may be, coming in the next release.

    • Konstantin Obenland 5:42 pm on September 30, 2015 Permalink | Log in to Reply

      I appreciate your quest for better documentation and an improved experience around dev notes for new releases. However I don’t think that it is feasible or even desirable to have every new filter, action, or function announced here. I fear it will lead to reading fatigue when important posts are buried in minor dev notes and adds a considerable burden to every commit (where these things are already documented) which in return has the potential to further increase the committer bottleneck that we’re trying to remove.

      I’m generally against rules and guidelines and instead rather rely on common sense wherever possible. This seems like a good opportunity to remind people about values and the importance of the points you mentioned, but I would be disappointed if we used it to introduce rules and requirements around posting here.

      • Helen Hou-Sandi 6:15 pm on September 30, 2015 Permalink | Log in to Reply

        I don’t think this is saying that every new thing be documented on Make/Core individually – those are examples of the type of content you might find here. Most of those things (hooks, functions, parameters) are included in the weekly summary posts. The proposal does say “Grouping related changes into one post is fine.” – being related by time seems reasonable to me.

        I think it’s been demonstrated here and elsewhere that “common sense” is not actually “common” (as in shared). There have been numerous very distracting and draining issues stemming from poor communication, most of them avoidable. For instance, the 4.3 retrospective post did not make it clear that the bullet points listed out were direct quotes, not processed or prioritized information, or that the concluding paragraph was a personal note and not a team conclusion, and the few comments that followed reflected that. And those are mild comments.

        You could say that commit message contents are mostly “common sense”, but I was more than happy to write them out, and the commit messages ever since have been much more consistent and helpful. Including more extended information based on guidelines such as including the why/backstory of a change has really helped on many fronts, including easing in the introduction of changes that might otherwise be contentious.

        If we don’t document things like this, we continue to rely on the institutional knowledge of individuals, which is a fragile reliance, constantly shifting based on who’s around at a given moment, and also does not provide any view into the history of how something has evolved. This is a rather general set of guidelines – if nothing else, they’re a good introductory document that we can link to people who are writing on Make/Core for the first time.

      • Aaron Jorbin 7:41 pm on September 30, 2015 Permalink | Log in to Reply

        Thanks for the feedback Konstantin. I agree that reader fatigue is a concern, which is why the suggestion to group related changes into one post. This could be a component summary, or this could be a generalized “Minor API changes you should know about in WordPress 4.4” post.

        It also doesn’t need to be the committer that writes these posts. I am happy to make any regular contributor[s] to WordPress a contributor [role] on this site.

        I also don’t like rules, which is why I didn’t frame these as rules. This isn’t a set of rules that you will be punished if you break them. This is documenting institutional knowledge that we don’t often do a good job of sharing. You and I who have been contributing and writing posts for a while know what we need to. Guidelines makes a lot more sense than “All the advice I have recieved or given”, but if you have a better idea of how to phrase it, I’d love a suggestion.

  • Scott Taylor 5:24 pm on September 30, 2015 Permalink |

    4.4 Dev Chat, September 30: Suggest items for today’s agenda 

    Here are my agenda items for today’s Dev Chat in the #core channel on Slack.

    Time/Date: Wednesday, September 30, 2015 16:00 UTC-4:

    • Gardening
      • 6 weeks, 995 commits Since 4.3
      • 268 in the past 7 days Timeline
      • We’ve closed 484 tickets since 4.4 started
        821 if you count those that have been closed on other milestones as a result of gardening
      • Biggest drop in tickets since 3.7 Ticket Graph
        This is not unique Boom and Bust
      • Can we get below 3000 tickets (it will be tough…)?
        • We have to ignore .org from the # or move the tickets to Meta
        • We need to close 274 non-.org, non-4.4, non-4.3.2 tickets AND every new ticket that is submitted
    • 3 weeks til Beta
    • Comments: changes and many more changes
    • Request for Comments: Shortcode Roadmap
    • Customizer
    • Multisite
    • My next 2 focuses: Multisite and Media

    Please suggest any other agenda items for today’s chat. The band’s taking requests.

    • Paal Joachim Romdahl 1:45 pm on October 4, 2015 Permalink | Log in to Reply

      It would be great if this ticket could be looked at: The Ability to Align oEmbedded Content

    • Weston Ruter 10:49 pm on September 30, 2015 Permalink | Log in to Reply

      Update which I didn’t get a chance to share in today’s epic meeting :-)


      Patch for #33901 has been committed. This can drastically improves DOM performance on sites with lots of widgets by deferring their embedding into the document until they are actually needed.

      A patch has been written for #33052 (Widgets section in customize late to show up). This improves the UX for the Customizer by not withholding the Widgets panel from being displayed until the preview loads. When the panel expands, there is also now featured a notice that explains why the panel may be empty for the given URL being previewed (due to no dynamic_sidebar() calls being made), and it explains to the user to navigate around the preview to access the desired page having the sidebar widgets displayed. *Help testing appreciated.* Getting this change in will facilitate lazy-loading of widget settings/controls, since we’d be able to use the widget panel expansion as the signal for fetching the data over Ajax (#28580).

      The other big performance improvement that has been sitting for awhile is reworking how multidimensional settings get sanitized and previewed in the Customizer (#32103). As the number of multidimensional settings with the same id_base increases, the number of calls to multidimensional_replace() grows exponentially. For instance, given 100 widgets of a given type I’m seeing the number of calls to multidimensional_replace() growing to 20,000+. There is a lot of wasted operations going on here, doing replacements on settings that haven’t even changed. A patch has been attached to the ticket which can cut down the number of multidimensional_replace() calls by 99.98%, resulting in a faster refresh time :rocket: for the preview. *Patch needs help testing/review.*

      For future releases, more discussion has continued on adding responsive breakpoints to the Customizer (#31195). This is for a future release. I punted #31436 from 4.4 to Future Release, since it should have a good feature plugin first.

      I’ve not had time to dive into selective refresh (#27355, née “partial refresh”), other than to continue ruminations. There is a feature plugin specific to widgets (Customize Partial Refresh), but I doubt I’ll be able to distillate a core patch for that in a week given my other responsibilities. There is also a lack of community feedback and user testing on this plugin. What may up happening here given my constraints is just facilitating the underlying framework for selective refresh, making sure that menus in the Customizer use it, and then provide this selective refresh API for themes and plugins to utilize (e.g. for widgets in a feature plugin for 4.5)

    • Aaron Jorbin 5:29 pm on September 30, 2015 Permalink | Log in to Reply

      I would like to start discussing the dev posts that need to be written for 4.3. So much activity in the last few weeks, and we need to make sure it gets documented (not just in the code).

      • Samuel Sidler 3:41 pm on October 1, 2015 Permalink | Log in to Reply

        Sadly, we didn’t get around to this today. Can you make sure it’s on the agenda for next week? We really need to get on the bandwagon with these posts. :)

  • Joe McGill 1:57 pm on September 30, 2015 Permalink |
    Tags: ,   

    Responsive Images: Merge Proposal 

    The RICG WordPress Team is proposing a partial merge of the RICG Responsive Images plugin into core in version 4.4. Specifically, we are proposing to add native srcset and sizes support to WordPress (ticket #33641).


    As of today, the average web page currently weighs over 2 MB with the majority of those bytes being attributed to images. Screen density and display sizes continue to increase and site owners are including larger image assets to keep up, causing slower page load times for people on smaller/older devices and on slower/expensive network connections. We have the opportunity to make a huge impact on the ~25% of the web that runs on WordPress by adding responsive image support out of the box so sites can serve appropriate sizes images to all users.

    Project Background

    The initial plugin idea was conceived by Tim Evko and Chris Coyier in April of 2014 before becoming the basis for the official WordPress implementation from the Responsive Images Community Group last November. Since that time, the plugin has been downloaded over 40,000 times and is actively installed on over 10,000 WordPress sites. We’ve gotten input from many WP core committers during regular meetings in the #feature-respimg slack channel, and received guidance from Mat Marquis and other members of the RICG—including the same people who wrote and are implementing the responsive image HTML spec.

    Implementation details

    First off, the plugin does not add any UI or admin settings to core. 🙌

    The plugin adds srcset and sizes attributes to images by extending wp_get_attachment_image(), which includes all post_thumbnails, photo galleries, and any other images that use wp_get_attachment_image() to build the markup.

    For images embedded in post content, we have opted to add srcset and sizes using a display filter rather than writing those attributes directly to the database. You can read more about that change in our previous project update. We’ve improved the performance of the display filter and believe it’s acceptable, but are still working to improve it further.

    In all cases, we have chosen to make use of the native intermediate sizes functionality in core to create alternate image sources for our srcset attributes rather than adding additional image sizes specifically for our use. This includes any user defined image sizes as long as they are resized versions (i.e., soft crops) of the file defined in the src attribute. Themes and plugins can also filter the value of the srcset attribute through included filter hooks.

    For the sizes attribute, we have chosen to use sizes="(min-width: {img.width}px) {img.width}px, 100vw" as a sensible default. However, this default value can and should be filtered by themes to meet their layout needs.

    Based on community feedback, we are choosing not to include a polyfill for non-supporting browsers directly in core. However, we would recommend that themes make use of Picturefill in order to provide responsive image support to the broadest set of users.

    While the plugin also includes experimental image compression settings for the Imagick editor (ticket #33642), we are not proposing that those enhancements be included at this time.

    Housekeeping and next steps

    This is a proposal and is subject to revision based on your feedback. If you haven’t already tried out the plugin, please download and install it from WordPress.org. You can review the current code and leave feedback at the project’s GitHub repository or in #feature-respimg on Slack.

    Many thanks to @mike for shepherding the project during this release cycle and @azaozz for his performance and security feedback. We’ve reached out to the accessibility team and received no objections, and we have reached out to @drew who will review the docs once a core patch is ready.

  • Pascal Birchler 5:02 am on September 30, 2015 Permalink |
    Tags: , , , ,   

    Feature Plugin Merge Proposal: oEmbed 

    For the past 6 years, users have been able to embed YouTube videos, tweets and many other resources on their sites through a nifty feature called oEmbed.

    Today, we (mainly me, @pento and @melchoyce) ask to consider extending this feature by merging the oEmbed API plugin into WordPress core. This plugin allows anyone to embed posts from your site by just pasting its URL. We’ve been working hard on it for months and are now eager to hear your feedback.

    Purpose & Goals

    While I initially built an early version of the plugin about a year ago, it was @melchoyce who kicked things off with #32522. Her idea was simple: When you can embed almost anything in a WordPress post, why aren’t we able to embed WordPress posts themselves in another WordPress post?

    That’s exactly what we’re aiming for. Our goal is to allow a big portion of the web to easily and securely embed such post previews.

    Have a look at this post to see the user flow for this feature (and a live demo!):

    Security Considerations

    Embedding content from a random source on your site depends on lots of trust. We take precautions to make the whole process as easy as possible. It’s worth noting that:

    • We use iframes with the sandbox attribute to enable extra restrictions on the content that can appear in the inline frame.
    • The host and the embedded site communicate via postMessage to allow resizing and clicking on links safely

    Browser Compatibility

    We successfully tested the feature with all major browsers on mobile and desktop. Since IE < 10 doesn’t support the sandbox attribute, we use the proprietary security attribute there to have similar security restrictions. This means no JavaScript inside the iframe is run, e.g. for the resizing. The most important thing, clicking, still works there though.

    Long story short, the feature works with all major browsers and degrades gracefully on older IE versions.

    Core Changes & Merge Implementation Details

    The plugin was developed in such a way that merging it into core eventually is as straightforward as possible. We are working actively on a patch that can be added to core within the merge window.

    There are two things that we need to change in core together with the merge:

    • When doing a redirect because of a changed post slug the rewrite endpoints need to be respected as well. See #33920
    • Attachment rewrite endpoints need to be fixed in core. See #19918
    • This feature only works with oEmbed discovery turned for every user, even those lacking the unfiltered_html capability. That capability check needs to be removed.

    Developer Notes

    This plugin adds a new /embed/ rewrite endpoint for posts, pages and attachments. We haven’t found any plugin in the directory using this endpoint, but if you already use that endpoint, you should consider renaming it or changing the oEmbed rewrite endpoint using the filters we provide.

    Note: There’d be a separate post for this after the merge.

    What about the REST API?

    The plugin works well on WordPress 3.9+ and uses a simple class to return the oEmbed API responses. However, with the REST API officially proposed for a core merge, we built a controller class for it. This class does exactly the same and follows the REST API best practices.

    We could definitely profit from the REST API and built upon it when merging into core. Not needing a fallback means no duplicated code and easier maintenance.

    In case you missed it, here’s the REST API merge proposal:

    Remaining Issues

    There is currently one issue with Slack not displaying the oEmbed output correctly. It simply displays the JavaScript as plain-text instead of removing it. We’ve reached out to them to see if they could fix that and at least white-list WordPress.org in the meantime to properly display the embeds in Slack channels.

    Besides that, there are also some small layout quirks we still need to work out. Meanwhile we’re continuing to improve the codebase and inline documentation.

    Future Plans

    We’re looking into improving support for different response types in addition to regular post content, depending on the feedback we receive from users.


    While I’ve been the lead developer of the plugin, a ton of valuable input and contributions have come from others in the community.

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

      Two things came up in a chat with this and a co-worker.

      1) Speed – What happens if I’ve oembeded a slow site? Will this slow down my site? What will I see as a placeholder when slow-embed loads?

      2) Changing extant content – If someone has a page with a link on it’s own line, it’s going to become an embed. This may not be what they wanted at all.

      • Pascal Birchler 10:42 am on October 4, 2015 Permalink | Log in to Reply

        1) With slow iframes you’ll still see your site load normally. The onload event is only triggered when all iframes are finished loading though (you can see that your browser is still loading something). That means there could be a delay with other JavaScript being executed. When an iframe is loading you just see empty space with the size of the iframe.

        2) With the way we’ve implemented it now this is not going to happen. Links to non-whitelisted sites not using iframes or not supporting oEmbed won’t turn into links. The behaviour doesn’t change.

    • mrpritchett 1:36 pm on October 1, 2015 Permalink | Log in to Reply

      Maybe late to the party, but I’d like to ask why this needs to be in Core? Is this really something that will be used by 80%+ users? I know that is a rule of thumb not a hard and fast rule, but this seems like a great plugin, not a core feature. I think Pascal and team have done some very cool work with this, but I’d like to ask the question (as I do internally on all the features I see come across here, but perhaps need to ask more often out loud)? :)

      • Gary Pendergast 1:50 pm on October 1, 2015 Permalink | Log in to Reply

        Yes, I really think it will be, but it needs time to grow. To be most useful, the feature needs to be ubiquitous – it needs to get to the point that you can paste a URL for a WordPress site, and know that it will be embedded in your editor.

        For comparison, WordPress.com sees an average of about 1.5 oEmbeds used per post – the concept of oEmbeds have clearly been absorbed by the vast majority of WordPress users, so we can assume that they’ll quickly come to see how oEmbed can work for any WordPress site.

    • Pancho Perez 1:32 pm on October 1, 2015 Permalink | Log in to Reply

      Could support post formats ? I mean have different layouts depending of the post format.

      • Pascal Birchler 2:39 pm on October 1, 2015 Permalink | Log in to Reply

        Hey Pancho! Post formats aren’t supported out of the box as this is usually an area where themes implement things very differently. Thanks to various hooks and filters adding post format support should be rather easy. though

    • Helen Hou-Sandi 12:15 am on October 1, 2015 Permalink | Log in to Reply

      I would like to see a text fallback (e.g. a link) provided in the oEmbed response, much like the way Twitter includes a blockquote. I wouldn’t want to see more text from the site, but the title/site name would probably suffice.

      • Pascal Birchler 10:18 am on October 1, 2015 Permalink | Log in to Reply

        Thanks for bringing this up yesterday. We will add such a fallback when people don’t want to use iframes. In this case we can use the link oEmbed response type which WordPress currently just transforms into a simple link. We can add the title + site name to that though.

    • Alex Mills (Viper007Bond) 10:19 pm on September 30, 2015 Permalink | Log in to Reply

      Nice work everyone. When this idea was first proposed, I was hesitant to think that it could be done securely and safely but I’ve read through the code and I really like how it works. Nice job!

    • Aaron Jorbin 7:58 pm on September 30, 2015 Permalink | Log in to Reply

      I noticed that there are currently PHP unit tests, but no JavaScript unit tests. Have you explored making the limited JavaScript unit testable and writing tests for it?

      • Pascal Birchler 8:03 pm on September 30, 2015 Permalink | Log in to Reply

        You noticed correctly, those are indeed missing. I’ve been looking into this recently, and with a little bit of help from someone with more experience in writing JS unit tests, we can get those in pretty quickly.

    • Ipstenu (Mika Epstein) 6:28 pm on September 30, 2015 Permalink | Log in to Reply

      After that, it’s nothing else than embedding a regular site in an iframe many times.

      Actually yes it is different :) The included iFrame means you’re making multiple calls to load the content from the same server. Trust me, it matters. You’re asking WP to make multiple htaccess calls, as well as multiple loops back to the DB there. That’s why including RSS is a nightmare. Too many self-referential calls.

    • Ipstenu (Mika Epstein) 1:39 pm on September 30, 2015 Permalink | Log in to Reply

      Has this been stress tested on a local multisite? That is NOT .com but something else? Right now, the fastest way to crash a multisite remains including an RSS feed from site B in site A on your own network. This, since it does some rendering, sounds like it could have similar ramifications.

      • Pascal Birchler 4:28 pm on September 30, 2015 Permalink | Log in to Reply

        I haven’t experienced any unexpected problems with multisite when embedding dozens of posts and loading the site hundreds of times.

        The good thing is WordPress caches the embed code it receives from the endpoint, so any discovery for a specific URL only happens once.

        After that, it’s nothing else than embedding a regular site in an iframe many times. Of course if you do this thousands of times the load times will be higher.

        A small difference is that we use postMessage to communicate with the iframes. Even here I didn’t encounter any problems as the JavaScript is pretty lightweight.

        • Scott Taylor 6:57 pm on September 30, 2015 Permalink | Log in to Reply

          has the idea of rendering posts from the local site without an iframe been discussed? the iframe makes complete sense for external sites, but what about *your* site, could it just just be rendered by an embed handler as inline HTML with no JS, etc?

          • Ipstenu (Mika Epstein) 7:16 pm on September 30, 2015 Permalink | Log in to Reply

            Or maybe v1 is no embedding your own site? What’s the use case for that anyway? Besides my multisite example…

            • Scott Taylor 7:36 pm on September 30, 2015 Permalink

              We use “Article Embed” in blog posts at the NYT. Like, preview cards or promo cards to other articles. I use an embed handler to do it.

          • Gary Br 4:57 pm on October 1, 2015 Permalink | Log in to Reply

            I pointed this earlier today in the comments, look at my comment 10:32 am on September 30, 2015

    • Samuel Wood (Otto) 12:39 pm on September 30, 2015 Permalink | Log in to Reply

      Does it have an off switch?

      As in, I never want WordPress posts to embed into my posts, even by accident, and I never want to allow my posts to be embedded anywhere else.

      If it lacks an off switch, then I vote no.

      • Pascal Birchler 1:34 pm on September 30, 2015 Permalink | Log in to Reply

        One can easily disable the various moving parts through filters, see https://github.com/swissspidy/oEmbed-API#developer-reference for details. There’s no UI.

        The most simple solution is to disable embedding using add_filter( 'embed_oembed_discover', '__return_false' ); and disabling the oEmbed discovery (e.g. not telling others they can embed your post) using remove_action( 'wp_head', 'wp_oembed_add_discovery_links' );

        We can also create 1 single filter to disable everything (rewrite endpoint, query vars, etc.) if really necessary.

      • Arunas Liuiza 2:04 pm on September 30, 2015 Permalink | Log in to Reply

        You can’t completely stop people from embeding your content anyway. If you have OpenGraph tags, Content Cards plugin will allow people to embed your posts to their content. Or they can use Embedly. Or build their own solutions. All oEmbed API does, is provide another way make that work.

        • Samuel Wood (Otto) 2:06 pm on September 30, 2015 Permalink | Log in to Reply

          No, but I absolutely can stop them from iframing my sites on their own, if I so choose.

          • Arunas Liuiza 2:08 pm on September 30, 2015 Permalink | Log in to Reply

            Hmm, do you have the same feeling about REST API? Because the way I understand the merge proposal, that would also be on by default after a couple of releases?

            • Samuel Wood (Otto) 2:11 pm on September 30, 2015 Permalink

              Different case. The REST API would be something I would be likely to use, via apps and other things accessing it. It also would not be public, you would have to authenticated to access it.

              On the other hand. this is something I would not use, and most definitely do not want. Therefore I want to be sure that there is a solid and reliable and future proof way to make sure it’s turned off.

            • Arunas Liuiza 2:18 pm on September 30, 2015 Permalink

              Ottp, You might feel that way, but other people might have very contrasting view on that. If I don’t use the REST API, I might not want to load additional 4000+ lines of code and have another door to guard in my WordPress install.

              On the other hand, as a writer I’d like to have an option to use a nice embed instead of a naked link in my texts. Web is increasingly visual these days, so embed options like that is something I’d want to use.

              Policy should be consistent on these things.

    • petermolnar 12:39 pm on September 30, 2015 Permalink | Log in to Reply

      There’s oEmbed Provider plugin, working great as well; so why go with this one instead?

      • Pascal Birchler 1:26 pm on September 30, 2015 Permalink | Log in to Reply

        This plugin is somewhat limited as it doesn’t output iframes and only makes WordPress an oEmbed provider, but doesn’t allow embedding of other WordPress sites.

        Luckily, the author of oEmbed Provider has been working on our solution as well!

    • Gary Br 8:39 am on September 30, 2015 Permalink | Log in to Reply

      I installed the plugin. seems to work great.
      Many users (include me) don’t like to use Iframe in website.
      My question is: Is it possible to add a seting that will add the preview into the source of the page, not with iframe?

      • Dion Hulse 9:55 am on September 30, 2015 Permalink | Log in to Reply

        For security and styling, iframes are the only real viable option. iframes shouldn’t be seen as dirty in the way of the past, used correctly for the right things, they can be far more useful.

        Most of the common existing oEmbed providers use iframes (including Youtube and Twitter) for this very reason.

        It’ll definitely be possible for a plugin to remove the iframe and output the content directly, but that really isn’t in the best interests of the vast majority of WordPress sites.

        • Gary Br 2:32 pm on September 30, 2015 Permalink | Log in to Reply

          I forgot to mention that i wrote about cases when the plugin used in the same site, Its bad for SEO because the lframe is not part of page.
          To show content from a different website, no doubt iframe is the best option.
          It will be a valued option for who that wants to use the plugin to display nice links with preview to other pages in the site.

      • Arunas Liuiza 10:35 am on September 30, 2015 Permalink | Log in to Reply


        If you want control how embeds look at your site, you can use Content Cards plugin (https://wordpress.org/plugins/content-cards/) – it does not rely on external website having oEmbed enabled, but instead looks for OpenGraph data (the same that Facebook uses to generate nice link previews).

        Cards are generated and inserted on your site, as a div, so you have full control on styling. And the OpenGraph data is cached, so it shouldn’t take down the site if a link gets embeded somewhere popular, too :)

    • Arnan de Gans 8:21 am on September 30, 2015 Permalink | Log in to Reply

      Content stealing/duplicate content/copyright hell, here we come.

      Not to mention all those scraping sites now don’t even have to grab RSS anymore for their shit, all they need is permalinks. They’ll get better results, too.

      And even worse, other wrong do-ers don’t even have to actually go to your site now, they just embed your urls a million times to take down your site/server.


      • Dion Hulse 9:52 am on September 30, 2015 Permalink | Log in to Reply

        Not to mention all those scraping sites now don’t even have to grab RSS anymore for their shit, all they need is permalinks. They’ll get better results, too.

        I don’t think it works how you’re thinking it does, it embeds within an iframe, with the source site (yours) offering up the content for that frame. As such, by default it includes only the excerpt and an obvious source link – exactly as it appears at the start of this post.
        The SEO benefits gained by the embedding site should be minimal as well.

        And even worse, other wrong do-ers don’t even have to actually go to your site now, they just embed your urls a million times to take down your site/server.

        That’s something they can already do. All they need to do to DDOS with that method is to add a million iframes of your site to a popular page on theirs, this doesn’t make it any easier or riskier, it just adds the iframe automatically.

      • Arnan de Gans 8:24 am on September 30, 2015 Permalink | Log in to Reply

        Also what will this do with (Google/Piwik) analytics?
        Does a embed count as a pageview? Will it be seen as referrer spam?
        Did you test that?

    • Ahmad Awais 8:05 am on September 30, 2015 Permalink | Log in to Reply

      Looking forward to oEmbed merger.

    • Piet Bos 5:45 am on September 30, 2015 Permalink | Log in to Reply

      Isn’t this the same as scraping? But then not just the title and excerpt, but instead the entire post?

      And how will this work in terms of Duplicate content?

      And is it possible to not allow my blog content to be embedded in other sites?

      I really hope that you have taken this kind of worries/issues into consideration!

      • Piet Bos 5:47 am on September 30, 2015 Permalink | Log in to Reply

        And I forgot to add how about the images, will they be served from the domain where the post is embedded from or will they hop over to the new domain?

        I think both scenarios are far from desirable.

      • Gary Pendergast 5:58 am on September 30, 2015 Permalink | Log in to Reply

        Isn’t this the same as scraping? But then not just the title and excerpt, but instead the entire post?

        Not really. It’s more like a more visually appealing link, with some extra context.

        It doesn’t embed the entire post, just the_excerpt().

        And how will this work in terms of Duplicate content?

        It’s within an iframe, so I imagine search engines won’t attribute the content to the wrong host. But, it’s worth making sure, (and adding noindex), so here’s a bug report. Thanks for bringing this up. :-)

        And is it possible to not allow my blog content to be embedded in other sites?

        Yep! You can disable all of the embeds and related output. Sending the X-Frame-Options: SAMEORIGIN header will also block all sites except your own from embedding your site.

        And I forgot to add how about the images, will they be served from the domain where the post is embedded from or will they hop over to the new domain?

        They’ll be served from the embedded domain, same as other similar oEmbeds WordPress supports, like Twitter or Tumblr.

    • leehodson 5:27 am on September 30, 2015 Permalink | Log in to Reply

      I love the idea. Have a couple of questions, though:

      1) If I launch a DDOS on a non cached site with embedded content, will that bring down the source site of the oEmbed? Will there be a failsafe to restrict requests to the content to so many hits per second and/or will embedded content snippets be cached on the source server in, say, wp-content/cache/oembeds/ ?

      2) Can the source site control where the content can be embedded via a whitelist / blacklist where?

      3) Can the source site control the display of embedded content such as snippet size, feature image to display, backlink anchor text etc..?

      4) How will oEmbeds work with sites that use iFrame busters?

      • Gary Pendergast 5:43 am on September 30, 2015 Permalink | Log in to Reply

        1) If I launch a DDOS on a non cached site with embedded content, will that bring down the source site of the oEmbed? Will there be a failsafe to restrict requests to the content to so many hits per second and/or will embedded content snippets be cached on the source server in, say, wp-content/cache/oembeds/ ?

        A DDoS will bring down the source site. It’s not cached at all, this is the same behaviour as, say, a site making the front page of Reddit. It’s up to the source site to install an appropriate caching plugin.

        2) Can the source site control where the content can be embedded via a whitelist / blacklist where?

        There’s no WordPress-specific mechanism for this. $_SERVER['HTTP_REFERER'] will contain the embedding URL.

        3) Can the source site control the display of embedded content such as snippet size, feature image to display, backlink anchor text etc..?

        Yes! Everything can be filtered, including replacing the entire output with your own template!

        4) How will oEmbeds work with sites that use iFrame busters?

        Due to the use of the security attribute on the iframe, iframe busters are not able to break out – there’s no concern about a rouge embed stealing your visitors.

        If a site implements their own iframe restrictions (for example, by sending X-Frame-Options: SAMEORIGIN on every page), we also send a X-WP-oembed: true header on the embed page, so they can conditionally disable that.

        If the site admin choses not to allow embedding, we respect their wishes, of course. :-)

    • Ryan McCue 5:05 am on September 30, 2015 Permalink | Log in to Reply


  • 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 …)

  • Robert Chapin 3:42 pm on September 29, 2015 Permalink |
    Tags: , ,   

    Shortcode Roadmap Draft Two 

    This is the second draft of the Shortcode API Roadmap. It describes in broad terms the changes that might take place across versions 4.4 through 4.7. This roadmap gives notice to plugin developers that significant changes in plugin design may be needed for compatibility with future versions of the Shortcode API. This roadmap also identifies steps taken to minimize the impact on plugin developers to allow most plugins to continue working with only small changes.

    This roadmap is based on decisions made at the meeting in #feature-shortcode, as well as feedback on previous posts, and consultation with the core developers.

    Our need for a roadmap arose from specific problems in the old code.  There are performance problems in parsing shortcodes, and we need to fix those problems with backward compatibility in mind.  Recent security patches illustrated the problem of not being proactive about security hardening.  Bloat in content filters is another big problem in itself.

    Please comment on this new draft.  We will have another meeting next Wednesday at 17Z, which is 2015-10-07 1700. Trac tickets that were nominated for closure at the last meeting will be closed today, with references to this draft.

    4.4 – Introduce Multiple Enclosures

    The two items on the 4.4 Milestone help us move toward our goals of security hardening without breaking websites.  A new delimiter in the shortcode syntax will enable plugin authors and users to always place their HTML between the shortage tags rather than inside of them.  At the same time, the names of registered shortcodes will be slightly restricted by disallowing angle braces in shortcode names.  It should be possible to implement both of these changes immediately with no impact on existing content or plugins.

    New Delimiter

    A new addition to the shortcode syntax along with documentation of how it works will be created in the 4.4 development cycle.  Its purpose is to allow more than one HTML enclosure in a single shortcode. Use of this new delimiter is optional or as needed.

    Enclosure Delimiter:  [parent:attr=]
    Usage:  [shortcode] Content HTML [shortcode:name=] Attribute HTML [/shortcode]
    Example:  [photo link_to="twentysixteen/"] Here is <b>my</b> caption. [photo:media=] <img src="00.twentysixteen-260x300.png" width="260" height="300" /> [/photo]
        delimiter   =  begin code-name middle attr-name end
        begin       =  "["
        code-name   =  1*( ALPHA / DIGIT / unreserved / %x80-FD )
        middle      =  ":"
        attr-name   =  *( ALPHA / DIGIT / "-" / "_" )
        end         =  "=]"
        unreserved  =  "!" / "#" / "$" / "%" / "(" / ")" / "*" /
                       "+" / "," / "-" / "." / ";" / "?" / "@" / 
                       "^" / "_" / "{" / "|" / "}" / "~"

    In the examples above, the “name” part of the new delimiter works the same way as an attribute name. The main difference when using this new style of attribute (the enclosure) is improved support for HTML inside the value text. One basic reason why this works better is because our HTML filters do not need to understand how to look in the middle of individual shortcode tags. All of the HTML is located between shortcode tags, making the shortcode and HTML codes easy to process separately.

    (More …)

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

      Bother… We need to rethink this a little with regards to HTML attributes.

      Not allowing shortcodes as html attributes means we will outright break some plugins. I remembered a plugin like this: https://wordpress.org/plugins/relative-site-url-on-content-save/

      So I dug deeper and hit https://wordpress.org/plugins/post-link-shortcode/screenshots/ (which has a nice example of _doing_it_wrong() right there)

      I think this may be bigger and deeper and really messier than we’d hoped. If we were just breaking some edge cases I’d be worried but that’s tolerable. Now we’re talking about a bit more.

      Also there’s a plugin called shortcoder – https://wordpress.org/plugins/shortcoder/ – that uses the colon.

      • Robert Chapin 3:28 am on October 3, 2015 Permalink | Log in to Reply

        I’d still like to get HTML attributes as an opt-in only feature. I mean, if we can’t do anything then we can’t, but I’m open to alternatives.

        The colons should be no problem. No plans to block or conflict with that in most cases.

    • bonger 3:22 pm on September 30, 2015 Permalink | Log in to Reply

      The HTML-centric thrust of the Shortcodes Roadmap – which appears to be driven by security issues – seems wrong to me. The latest 4.3.1 security update caused me to do some research on the history of the security issues, and it seems to me – based on my no doubt partial understanding – that the approach adopted in 4.2.3 (and continued in 4.3.1) to fix the issues was wrong. Obviously that’s a bold, probably foolish statement, but even if it’s wrong the explanation of its wrongness will be useful.

      The proper response to the security issues was to 1) add capabilities to shortcodes, with KSES-like checks on their attributes, 2) use placeholders for shortcodes, 3) fix comprised content in the database.

      1) Capabilities need to be added to shortcodes (this idea comes from @Kleor in https://core.trac.wordpress.org/ticket/33116#comment:25). Everything’s become skewed by the fact that untrustworthy contributors/authors can insert shortcodes into their content. Thus shortcodes supposedly have to operate in an untrustworthy environment. This is wrong. By default all shortcodes (default capability ‘unfiltered_html’) should be ignored in such content, except for specially hardened shortcodes whose capability (‘edit_post’) allow it, and who undergo a KSES-like check. This should be done on post save, same as KSES, not at run-time. The vast bulk of other shortcodes can then assume that they operate in a trustworthy environment – which they do implicitly anyway.

      2) Parsing is a security issue. Taking shortcodes and their messy attributes out of the equation is needed to ensure real future-proof security. Shortcodes need to be parsed first, without regard to HTML, and replaced by placeholders. This can be made to work seamlessly with the current set-up. So the HTML parsing focus of the Shortcodes Roadmap – and current implementation – is wrong. (Note that this step is separate to the do_shortcode execution of shortcodes, whose priority is unaffected and remains moot.)

      3) The remaining problem is the stored comprised content, entered by untrustworthy contributors/authors, which presumably exists on sites and is patched to be harmless by the changes introduced in 4.2.3 and 4.3.1. This will need an elective database update to fix – elective so that sites with trustworthy contributors/authors can either elect not to update or whitelist their shortcodes first to avoid getting them messed about. (Patching databases is a yucky thing to have to do – so perhaps this was a major contributing reason as to why the current approach was chosen??)

      The restrictions on shortcode attributes introduced (and planned) for security reasons can then be lifted, and the new attribute syntax becomes a good-to-have feature, which can be used to make shortcodes more expressive, but is not a particularly immediate concern.

      • bonger 3:59 pm on September 30, 2015 Permalink | Log in to Reply

        *comprised === compromised

      • Robert Chapin 1:47 am on October 2, 2015 Permalink | Log in to Reply

        I can only assure you that all of these ideas were explored either publicly or privately before we started drafting the roadmap. Saying that the current approach is “wrong” will not accomplish anything.

    • jadpm 2:56 pm on September 30, 2015 Permalink | Log in to Reply

      Juan from the Toolset dev team here.

      I agree with the comments above: the first draft for this changes was a little scary, but this one is indeed quite nice. From our point of view, there are two main things to consider here:

      First, the solution to kind of allow HTML in attribute values is clever. Having multiple enclosures is fantastic, and enables all sort of new posibilities since they wrap actual HTML output. I am thinking on shortcodes for conditional output with else statements. Realy cool, and looking forward to be able to use it.

      Second, although we do depend on shortcodes being used in nHTML attributes, we do understand also that this opens the door to all kind of security issues. We will have plenty of time until 4.7 to update our shortcodes, and provide ways to avoid such structures (maybe even using the feature above). Hopefuly the cron jobs will be enough for us to update existing content.

      We will be keeping an eye on the progress of this, and we might even give a hand. :-)

    • chris@vendiadvertising.com 2:20 pm on September 30, 2015 Permalink | Log in to Reply

      The first draft was quite honestly very scary. This new draft is spot on! Thank you everyone for the hard work on balancing convenience and security!

    • Scott Fennell 1:14 am on September 30, 2015 Permalink | Log in to Reply

      Nice progress here, thank you for your work on this!

      I still find the syntax in this proposal to be awkward, by my primary concern is preventing shortcodes on hundreds of live sites from breaking.

      Let’s say I have offending shortcodes in widget text fields, widget titles, and post excerpts. The shortcodes are offensive both for having shortcodes in HTML attributes, and for having HTML in shortcode attributes. Given this situation, I’m intrigued by the point you mentioned,

      “This will allow plugins to easily register a WordPress cron that will scan all posts in small batches and convert the shortcodes in old content.”

      Can you go into more detail on how robust the core support for this might be, and how one might extend it to capture fields other than just post content?

      • Ipstenu (Mika Epstein) 1:32 pm on September 30, 2015 Permalink | Log in to Reply

        There was no way to do this without the syntax being slightly awkward to some degree. We’re trying to back port in something shortcodes were never supposed to use, so the balance of security vs usability was really hard. This was the best version we were able to come up with, while still addressing all the concerns :/

        Shortcodes in html, like wrapping a-href around a shortcodes, won’t be changed.

        HTML in shortcodes is what’s going away, and the core support for the cron job isn’t written yet, so we can’t tell you how robust it will be just yet. Is there a particular feature you’re concerned with?

        • Scott Fennell 4:39 pm on September 30, 2015 Permalink | Log in to Reply

          “core support for the cron job isn’t written yet, so we can’t tell you how robust it will be just yet. Is there a particular feature you’re concerned with?”

          Forgive me for being a little out of sorts here: I’ve been using WordPress at a relatively large scale across many client sites for about 5 years now, and this thread is the first occasion where a core initiative has threatened to break many of my sites upon update. So, I’m not sure what a realistic expectation might be.

          In an ideal world:
          1) I write a small plugin where I feed a list of shortcode names and also a list of field names (example idea: post[‘content’], post[‘excerpt’], widget[‘title’], user[‘description’], some_type_of_object[‘some_meta_key_for_that_object’] ) to a cron function.
          2) I network-activate the plugin.
          3) In cron-land, wordpress core sweeps through all of those fields on all of my sites and does whatever it has to do such that my pages look exactly the same way they did before.

          This ideal-world solution would cure what ails my shortcodes both in the case of html tags in shortcode atts, and shortcodes in html atts.

          This seems like an impossibly tall order. I’m trying to “play the character” (if you will) of someone who’s exposed to a massive amount of breakage on this initiative, who’s hoping for as much support from core as possible.

          • Robert Chapin 5:10 pm on September 30, 2015 Permalink | Log in to Reply

            This ideal-world solution would cure what ails my shortcodes both in the case of html tags in shortcode atts, and shortcodes in html atts.

            Hi Scott, shortcodes in HTML attributes are not something that can be converted within the core API. At best, we can offer ways to find those codes. We need to hear about the expected impact if the codes stop working. We need to know if the 4.7 Milestone is a reasonable deadline for plugin authors to write their own updates.

            • Scott Fennell 5:22 pm on September 30, 2015 Permalink

              Thank you for helping explain that more specifically. I appreciate it!

              The breakage I’m talking about might be something like a link href that would then 404 upon update — a link or two or three on hundreds of sites.

              4.7 is a reasonable timeline to write plugin updates, sure — that’s not the question.

              The question is, what is a reasonable timeline for my staff to log into hundreds of sites and update shortcodes in all the possible text fields where they might occur? I would argue (from my ideal podium in my ideal world) that there is *no* realistic timeline for that.

              “At best, we can offer ways to find those codes.”
              That would go a long ways, and might even get me to shut up 😀

              However, this thread still makes me very uncomfortable. I consider myself to be a half-decent plugin developer. I don’t hack core, I use core methods, and I read the docs and the source code before using core methods. Yet I am now in the position of having a mess. It’s actually pretty embarrassing for me at work — I feel like I’ve exposed the rest of my agency to a massive loss of goodwill if we have client-facing errors on update.

              If this initiative goes through, you’re now in the position of saying, “WordPress is pretty good as long as you have enough staff to fix stuff by hand upon updating core”. That’s not how I currently think of WordPress. I think that would be a sad turn of events.

              I know I have huge expectations from core — thanks for entertaining them!

            • Ipstenu (Mika Epstein) 6:47 pm on September 30, 2015 Permalink

              But shortcodes within HTML isn’t going to break is it?

              I can still do img src=SHORTCODE if I wanted to. I mean, I’m weird, but I could do it.

            • Scott Fennell 7:01 pm on September 30, 2015 Permalink


              I’m weird but I also want to do that! This is a very common use for us:

              <a href='[client_url]'>some text</a>

              Perhaps I am mis-reading, but by my reading, that use case is in jeopardy:

              “To fully enforce the separation of shortcodes and HTML codes, the shortcode API of version 4.7 would also ignore any shortcode tag or attribute that exists inside of an HTML attribute.”

            • Robert Chapin 7:12 pm on September 30, 2015 Permalink

              But shortcodes within HTML isn’t going to break is it?

              They are highly restricted since 4.2.3. In hindsight, they should have been totally blocked since the beginning. This is a “doing it wrong” situation where we just don’t have many options.

            • Ipstenu (Mika Epstein) 7:13 pm on September 30, 2015 Permalink

              Ugh. Obviously I missed that somehow. Multiple times.

              <a>some text</a> would have to become [client_url text='some text']

              Obviously you’d have to update the shortcode there, but a regex search COULD do that:

              Search: <a>(.*?)</a>
              Replace: [client_url text='%1']

              http://wp-cli.org/commands/search-replace/ for example but also https://github.com/interconnectit/Search-Replace-DB can help with that.

            • Scott Fennell 8:26 pm on September 30, 2015 Permalink

              Thank you for those suggestions, Ipstenu.

              However, if that were to go through, you’d be in the position of saying, “WordPress is pretty good, but you can only use it at a large scale if you are willing to run large DB search & replaces upon some core updates”. I don’t care for the sound of that.

            • Ipstenu (Mika Epstein) 9:32 pm on September 30, 2015 Permalink

              @scofennellgmailcom Not exactly :)

              WordPress is pretty good, and you can use it at a large scale if you’re fully aware of what your plugins and themes are doing, and they’re doing things the right and intended way to start with. Some core updates will be made in the name of security and some edge cases will always be adversely impacted. If your company lives and dies by your WP site, it’s in your best interest to do exactly what you are doing now :) Keep in touch with issues like this and fix your site WELL ahead of any planned deadline changes.

            • Scott Fennell 10:19 pm on September 30, 2015 Permalink


              That’s a fair interpretation. I agree with you.

              Certainly, there are things I’d rather do with my staff hours than worry about shortcodes breaking, but also I’m worried about the WP community taking a hit. There have to be a lot of agencies like us, but very relatively few of them monitor the core blogs like this.

              WordPress can’t be everything to everyone, but here’s my voice: I want WordPress to not break stuff. I don’t care if the source code is bloated and carries lots of deprecated API’s. I just want it to not break stuff. If I wanted the leanest, most non-legacy, most modern block of code, I’d build sites on whatever HTML9 Responsive Boilerstrap JS happens to be popular this week.

          • Robert Chapin 5:34 pm on September 30, 2015 Permalink | Log in to Reply

            At the next meeting, I think we should explore the possibility of making the HTML attribute parser an opt-in feature that is disabled by default. This would at least give us some middle ground between performance and breaking things.

            • Scott Fennell 5:40 pm on September 30, 2015 Permalink

              Absolutely. In our situation, it’s a “trusted network”. Meaning, we would never have a situation where arbitrary members of the public can register as a user, not even as a subscriber.

          • Ipstenu (Mika Epstein) 10:21 pm on September 30, 2015 Permalink | Log in to Reply

            @scofennellgmailcom – Oh I 100% agree we shouldn’t break things. The problem is the name of the game isn’t ‘deprecated’ or ‘bloated’ but ‘unsafe.’ :/ (Believe me, I’ve been fighting not to break things this whole way, I was very vocal in the first round of this).

            • Scott Fennell 10:48 pm on September 30, 2015 Permalink

              I realize there are some naive assumptions here, but if you’re able to humor me: Given the assumption that we trust all of the users on our network, would you be able to explain in more detail what the security issue is?

            • Robert Chapin 10:50 pm on September 30, 2015 Permalink

              It’s almost a footnote at this point, but where it says

              Implement security context in API

              This is an idea that would give “trusted” capabilities to shortcodes. Currently we do not have that feature. At all. The downside is that would definitely create an inconsistent experience for different users. But it’s still on the table as a possibility.

            • Ipstenu (Mika Epstein) 1:57 am on October 1, 2015 Permalink

              Two things

              1) Even on a trusted network, you can’t trust people not to be stupid

              2) Inconsistent experiences are bad.

              The first one is a big issue, frankly. You may trust your users. I don’t trust my users to know right and wrong when it comes to technical things. That’s not their job, it’s not something I would ever expect them to learn. That’s MY job, to save them :)

              I do not, never have, never will trust my users to know “Don’t paste the random code you picked up on the internet!”

            • Scott Fennell 11:07 pm on October 1, 2015 Permalink

              I hear you, but can you go into more detail on what sort of vulnerability it is? A user could deface their own site, or something worse?

            • Robert Chapin 1:09 am on October 2, 2015 Permalink

    • Sallie Goetsch 11:01 pm on September 29, 2015 Permalink | Log in to Reply

      This seems much more usable and comprehensible than the last proposal.

    • Stanislav Khromov 8:48 pm on September 29, 2015 Permalink | Log in to Reply

      Will this roadmap bring support for nested shortcodes that use the same base? For example:


    • Mike Nelson 6:35 pm on September 29, 2015 Permalink | Log in to Reply


    • Greg Ross 4:58 pm on September 29, 2015 Permalink | Log in to Reply

      A fabulous second draft. It was great to see everyone participate in the meeting and the feedback from everyone considered and explored!

    • Arunas Liuiza 4:27 pm on September 29, 2015 Permalink | Log in to Reply

      Now that’s something that might actually work! Good job, guys.

    • J.D. Grimes 4:14 pm on September 29, 2015 Permalink | Log in to Reply

      First, thank you so much for your continued hard work on this.

      I do have one point of clarification: will this mean that : will not be allowed in a shortcode or attribute name? I only ask because I think I have seen it used before (although I can’t find an example at the moment).

      • Robert Chapin 4:19 pm on September 29, 2015 Permalink | Log in to Reply

        The plan is to allow : in shortcode names, but with the caution to avoid name collisions. If my shortcode is named caption:title= then I can expect some serious technical problems in the future.

  • Pascal Birchler 3:32 pm on September 28, 2015 Permalink |
    Tags: , , ,   

    oEmbed Update: September 28th 

    As of today, the current version of the oEmbed feature plugin is 0.9.0. These are the biggest changes since last week:

    • There is now an is_embed conditional tag to more easily target embedded posts.
    • New: Support for embedding video and audio attachments.
    • You can now copy the whole embed code and not only the post’s URL in the sharing dialog.
    • There were major JavaScript improvements. It is more robust and also a bit faster too.
    • We now show a read more link instead of the word count in the excerpt.
    • Improved input sanitization.

    These were all areas discussed in last week’s chat and I’m happy with what we achieved. The plugin has been installed on WordPress.com, although it has been temporarily deactivated 🙁. Nonetheless I’m looking forward to publishing another post regarding the plugin tomorrow…

    There are only some smaller issues left, so now is a great time to test and review the plugin! Our weekly chat is today (September 28 2015 9pm UTC) in the #feature-oembed Slack channel

    Note: We received some feedback regarding weird link previews in Slack for WordPress.org links. This is a Slack bug and not our fault. We already reached out to them and hope it gets fixed soon.

    As always, the latest version of the plugin is available on the plugin repository. Errors and suggestions can be either reported on GitHub or our #feature-oembed Slack channel.

    Next chat: October 5 2015 9pm UTC

  • Ryan Boren 3:26 pm on September 26, 2015 Permalink |
    Tags: awareness, dogfooding, empathy, , has-screenshots, kibbling, needs-screenshots, post-commit-flow, vizox, workflow   

    #needs-screenshots, #has-screenshots, and multi-device dogfooding of visual change 

    I’m attempting to provide before and after screenshots for all (most) visual changes that land in trunk, on multiple devices. These screenshots are used in visual changelogs such as the Today in the Nightly posts. The goals of this effort are to increase awareness of our usability (particularly touch/mobile), make ui review easier, establish a visual archive, and dogfood visual change on multiple devices.

    To create the Today in the nightly posts, I work my way through the latest commits looking for visual changes to UI. From the changesets, I visit the tickets. If the tickets don’t have before and after screenshots for both a desktop and a phone (at least), I take screenshots as I test. I upload those screenshots to the ticket. I comment on the ticket with any bugs I find in the process. I often find bugs, especially on phones. If I don’t have time to provide all screenshots, I tag the ticket with needs-screenshots so I can get back to it later. If I see flow problems while testing, I post a visual record to make/flow and crosslink it with the ticket.

    If a ticket has at least one screenshot, I tag it has-screenshots. Once all screenshots are collected, needs-screenshots is removed, leaving has-screenshots.

    Now that I have tickets with screenshots that are all tagged with has-screenshots, I collect the shots and publish them as “Today in the Nightly” using the tool we’re all making together, WordPress. The process of dogfooding all visual changes, taking screenshots as I go, and turning the screenshots into posts is fantastic recursive dogfooding that reveals bugs, bad flow, and mobile brokenness. Triage, recursive dogfooding, visual archiving, visual awareness, change awareness, flow awareness, and useful posts are products of this virtuous process. My pet names for these acts of recursive dogfooding and visual archiving are kibbling and visual oxygen (VizOx, a riff on the communication is oxygen mantra of p2).

    needs-screenshots and has-screenshots are part of a post-commit lifecycle that hasn’t existed before on core.trac. Historically, once a ticket was closed as fixed, it was done. However, diligence remains. has-screenshots and needs-screenshots are applied after a ticket is resolved as fixed and are used as testing signals by flow patrol. We may need other post-commit workflow keywords, but for now I’m seeing how this has/needs pair works out for visual change testing.

    If you’d like to help collect visuals, we want before and after screenshots on at least two devices, with one of them preferably being a phone. We’re increasing our mobile/touch awareness by testing and capturing all visual changes on phones. Provide whatever screenshots you can. The Flow Patrol team will handle the remainder. Developers, taking screenshots of your patches and commits as you test really helps ui/ux review and flow patrol. This process is an engine for empathy and awareness.

    I’m focused on visual change and usability, but other teams with other focuses might want their own post-commit lifecycle keywords. Commit is not the end of the process.

    Obligatory recruiting pitch: If you’re interested in nurturing a QA mindset in a continuous integration, continuous dogfooding environment, help the Flow Patrol team continuously dogfood flow. Some of our duties are listed in the Flow Patrol handbook. Ideally, every component and feature team has someone continuously dogfooding, patrolling flow, publishing visual records, and helping teams meet merge criteria.

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