WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Michael Arestad 7:42 pm on February 18, 2015 Permalink |
    Tags: ,   

    Press This Revamp Merge Proposal 

    What is it?

    Press This is a redesign of an existing feature with a focus on automation, speed, and mobile usability.

    Download the plugin and check it out for yourself!

    Features

    One of the requirements of core is at least feature parity with the old version of Press This. Here’s a comparison chart of where the new Press This is.

    Feature Old New
    Drag & drop install on desktop Yes Yes
    Editor, including: title, image/gallery addition Yes Yes
    TinyMCE buttons (minus kitchen sink) Yes Mostly [1]
    Ability to publish or save as draft Yes Yes
    Post formats Yes Yes
    Categories Yes IYes
    Tags Yes Yes
    Content Scraping Yes Improved [2]
    Media Discovery Yes Improved [3]
    Alert before closing/navigating away Yes Yes
    Can add to bookmarks Yes Yes
    Responsive, clean design, updated icons No Yes
    Fast loading (speedy!) No Yes
    Mobile installation No Yes

    [1] A number of TinyMCE buttons are removed intentionally. Only necessary WYSIWYG buttons are shown now.
    [2] Not only is it included, but it’s quite a bit smarter than the previous one.
    [3] Now is actually quite exposed in the UI.

    More generally

    • Trimmed down UI for extra-speedy reposting of your favorite left shark gif
    • Core architecture of the plugin/tools is an as-pure-JavaScript-app as possible
    • Currently AJAX-driven, but ready to be switched to using the WP-API endpoints as they become available in the future
    • Backward compatible with the current version of the Press This bookmarklet as bundled in WP, but also bring its own, more powerful one with it
    • Can blog content from any web page found online
      • highlighted text gets pulled in as a blockquote
        • if nothing is highlighted, it makes a good guess as to what should be quoted
      • in-page images get pulled in to choose from
        • Said images are augmented with meta data to sort them in the order the site advertises to be best
      • audio, video, and and twitter embeds are also listed in the suggested media to insert at your whim
    • Saving draft sends you into the full editor (and saves) so you can do your fancier WYSIWYG-y things
    • Publishing is awesome and quick
    • Image side-loading
    • Ultimate (the best ever probably) WYSIWYG toolbar that’s trimmed down to just B, I, Blockquote, Link/unlink, undo, redo (and lists on wider screens)
    • 2 modes
      • Direct access: Like quick post, but awesome and totally usable on a fancy phone
      • Bookmarklet
        • Similar to the older Press This in use. Save as bookmarklet > Press a site for quick reposting of things
        • If no content detected (new tab), you can use it like a quick post application

    So which problems are we solving?

    • Outdated UI –> Updated
    • No responsive styles –> ultra responsive
    • Decent automation –> better automation (suggested media, blockquote, etc)
    • Pretty dang near impossible to add as a bookmark and use on a tablet/phone –> Added our own tool page (temporary) to add improved markup (still could use a bit of finessing)
    • Suggested media was hard to find –> Now is hard to miss
    • A bit rough and slow to use and compose with –> Pretty dang streamlined

    What brought us to this solution and what other potential solutions did we explore?

    When we were initially exploring designs and ideas, a few people suggested just improving Post New. The main reason we opted not to was speed. Post New comes with all of wp-admin and its files. It’s a bit of a beast. We wanted an extremely light, extremely fast (both in performance and in usability) way to post and keeping Press This was a good way to go. We can also pull the ideas and techniques we like back into Post New if successful and useful.

    We experimented with SVG icons (one less http request, but ultimately removed as Dashicons are required for the editor). We planned to use the upcoming API. We have trimmed down stylesheets and JS (only the styles necessary for a PT view). There is no extra UI that could get in the way of going from 0 to published post. Press This also has the luxury of being able to fall back to the full editor (via Save Draft) for those that have plugins and other features the need to set before posting.

    Usability testing (not user testing y’all)

    We did a couple rounds of usability tests. One for a11y and another with some new users.

    Both had tremendous difficulty in even adding the bookmarklet. @marcelomazza did a pretty solid job fixing up the add bookmarklet screen.

    We ran into a number of a11y issues and addressed as many as we could. Could still use another round of a11y testing.

    Once the new users figured out how to install it, they didn’t have many issues creating a post. I’d like to do more with ultra Space Jam pro users like yourselves.

     Mega thanks to everyone involved so far:

    @stephdau @azaozz @marcelomazza @ryan @kraftbj @afercia @iseulde @melchoyce @folletto @georgestephanis @helen @drewapicture @danielbachhuber @dd32 (for epic Github > SVN sync)

    And thanks to all the testers so far!

     
    • Jeremy Felt 8:00 pm on February 18, 2015 Permalink | Log in to Reply

      This has really turned out excellent. There’s been a ton of progress over the last couple weeks and as an “every once and a while, but hoping to use it more” user of Press This, the new UI is looking great.

    • Ansel Taft 9:51 pm on February 18, 2015 Permalink | Log in to Reply

      “Trimmed down UI for extra-speedy reposting of your favorite left shark gif”

      Nice reference. I actually spit coffee in a pop of laughter you awesome jerk.

      “Jerk” not meant seriously.

    • Ionel Roiban 10:42 pm on February 18, 2015 Permalink | Log in to Reply

      Will test and see if it can actually work as a bookmarking service, something like Pocket (or its Open Source version Wallabag), or for content curation, similar to what Scoop.it does.

      • Michael Arestad 10:58 pm on February 18, 2015 Permalink | Log in to Reply

        I’ve actually been testing it as a bookmarking service, but it’s a little tricky the way I was using it. (actual bookmarks).

        • Ionel Roiban 11:26 pm on February 18, 2015 Permalink | Log in to Reply

          How about a Chrome extension. “bookmarklet” to me sounds like a quick hack, although it really works, pulling the image and highlighted text.

          I would also take it further, to content curation, the hot 2015 trend for SEO.

          Congratulations for bringing this feature back to life!

    • Stagger Lee 11:47 pm on February 18, 2015 Permalink | Log in to Reply

      Do you guys (mis)use Amphetamines ? :)

      I have never seen so much activity in any CSM community. You really deserve No. 1 place in the world of CMSs.

    • Shaped Pixels 6:11 pm on February 24, 2015 Permalink | Log in to Reply

      A suggestion…. if Press This detects a Copyright meta tag, that it doesn’t allow any content from that source to be scraped.

  • Ryan Boren 5:05 pm on February 18, 2015 Permalink |
    Tags: , mobile-flow   

    Mobile Flow Update 

    Here’s the state of the open mobile flow tickets we’ve been calling out in the jumpstart posts.

    #29989 Hide Media Buttons on small screens

    I’ve really wanted this one for awhile. There was some good design momentum, but we’ve faltered as we moved to implementation. This ticket needs developer feedback. We really need these improvements to post-new.php for mobile.

    #31187 Allow swiping the admin menu open and closed on touch devices

    This one has gained some momentum. We need code review and testing. I’d really like to land this one.

    #29906 Submenus can’t be dismissed on mobile.

    During the first NUX meeting, the importance of the toolbar was called out by several. The toolbar needs help on mobile. There’s a working patch on this ticket that needs code review. There’s another case to cover that needs discussion and eventual patching.

    #29993 Media action links are cramped on small screens

    This needs a patch refresh and more discussion.

    #29992 Cramped tag action links on small screens

    This has a patch that needs CSS review and testing.

    #15930 Make trashed posts/pages still readable

    This is a possibly very simple patch that will remove a lot of frustration from certain flows. Read about one such flow.

    #31233 Dismissable admin notices

    This isn’t really a mobile flow ticket, but I like it enough to tack it on here as bonus. There’s a first pass patch on the ticket already. I’d love to see this go somewhere.

    More here:

    https://core.trac.wordpress.org/query?status=!closed&keywords=~make-flow

     
  • Jeremy Felt 5:50 am on February 18, 2015 Permalink |
    Tags:   

    Multisite Objective: Defining Network Types 

    We’ve been having a rolling conversation about the concept of different network types for a long while. @nacin covered it as part of the potential roadmap for multisite in 2013 and described two sections—“Registration and Open Networks” and “Trusting Users in a Closed Network”—that describe the overall intent of this conversation pretty well.

    At WCSF this year, we covered the topic a few times during the contributor days, trying to really nail down what “open” and “closed” meant or if “trusted” and “untrusted” were better words. We even committed wp_is_trusted_network() to core for about a month in #30145 as a guess at starting to figure out what it should do. :)

    This repeating conversation has usually started as one of confusion. We have different meanings for open/closed, so we can’t use that. We have different meanings for trusted/untrusted, so we can’t use that.

    How do we figure out what we’re talking about?

    While all of this discussion has been happening, we’ve been exploring the different ways of phrasing things. A use case discussion for network types on GitHub. A breakdown of open/closed network functionality. A categorization of every is_multisite() use in core.

    During our office hours today, we made some great progress.

    We’re going to skip our attempts at binary classification. The future we’re looking at is one in which installing a network is the choice of a pre-configured network type.

    Long winded intro aside—this thread you are reading is a place to have this discussion. We need to work out answers to a few questions so that we can move forward:

    • What network types are there?
    • Which of these should be pre-configured in core?
    • What are possible ways of managing these network types?
    • What kind of experience can we introduce during network installation that makes this simple.

    I’d encourage you to read some of the previous discussions linked above, especially today’s #core-multisite logs, and then refocus the discussion in the comments here. This will be our main topic in next week’s multisite office hours, so brainstorm away! The more input the better.

     
    • John James Jacoby 1:39 pm on February 18, 2015 Permalink | Log in to Reply

      Thanks for getting this started Jeremy.

      As far as network types go, the original (and current) vision for WordPress multisite was for it to easily enable anyone to create and manage a network of blogs, for blogging. The more modern use case for WordPress multisite is as a utility for managing multiple sites using one installation, sites that may-or-may-not be related to one-another. There are a few assumptions we can make about the differences:

      • Blogging networks likely have open registration & blog creation. Utility networks likely have closed registration & blog creation.
      • Blogging networks assume an untrusted user might “own” a site. Utility networks assume a trusted staffer, employee, or client are using a site on your network.
      • Blogging networks likely limit upload space. Utility networks likely should not be limited.
      • Blogging networks likely will have very few users on each site. Utility networks likely will have several to many. (Both installations could have millions of users in general.)
      • Blogging networks may-or-may-not allow access to control plugins. Utility networks likely have plugins and themes locked down.
      • Blogging networks mean relinquishing site control to your users. Utility networks mean a trusted group is likely in control of each site, and site-administrators provide as-needed access to wp-admin areas.

      You’ll see lots of “likely” and “may-or-may-not” here. This is because most of us have architected installations and designed experiences around some common directions, but have also deviated far and away from any beaten path for anything from intranets and social networks to complete application frameworks using sites only to store and retrieve data.

      As Jeremy eluded to, what to do about multisite has been a years long thought process, and our current conclusion is approximately as follows:

      • Define at least two network “types” – one being the blogging network we currently have.
      • Define future-proof verbiage for related functionality. wp_get_network_type() and such.
      • Maybe provide constant or UI for installing multisite and picking between network types.
      • Maybe provide API for registering network types as a “package” of predetermined network and site settings.

      Another thing to consider, is if what we are talking about is a “network” type or an “installation” type. Because WordPress multisite supports multiple networks (swoon) is one of our goals to allow each network to operate with its own unique restrictions? WordPress.org is kind-of like this now, with several different networks running on global user tables. I *think* the answer to this question is “yes” but I also think it’s a decision worth being more confident about.

      • Jeremy Felt 4:02 am on February 24, 2015 Permalink | Log in to Reply

        Blogging networks mean relinquishing site control to your users. Utility networks mean a trusted group is likely in control of each site, and site-administrators provide as-needed access to wp-admin areas.

        This is an interesting duality of sorts. I agree with this statement, though I’ll also point out that users of a utility network will often have a higher expectation of immediate capability than users of a blogging network. So, relinquishing mediated control of the full site (blogging network) and allowing full control of a mediated site (utility network). Maybe?

        Define at least two network “types” – one being the blogging network we currently have.

        My current thought is that 3 would be a perfect number. :)

        Maybe provide constant or UI for installing multisite and picking between network types.

        Tools -> Network Setup -> “Select Network Type”, done.

        Another thing to consider, is if what we are talking about is a “network” type or an “installation” type.

        I think network type is the way forward. At least in my multi-network use case, I have a handful of different types I could define at the moment.

    • John James Jacoby 1:56 pm on February 18, 2015 Permalink | Log in to Reply

      Functionally, this could start off using some global array of keys and values used to filter pre_option_ and pre_site_ calls the way bbPress currently allows.

      This gives us the opportunity to write some code as a plugin first, touch options directly, and create some predefined groups of them to later turn into “network types.” This exercise should help us determine what type of interface would be most useful for the type of user who will most likely be interacting with it.

      • Jeremy Felt 4:05 am on February 24, 2015 Permalink | Log in to Reply

        Your mention of wp_get_network_type() above brought me to thinking about a series of network_supports() checks throughout core that checked the current network type for its support of a concept.

        I like the idea of hooking in early with a plugin to test the concepts out.

    • Ipstenu (Mika Epstein) 4:23 pm on February 18, 2015 Permalink | Log in to Reply

      What network types are there?

      Today we have a loosely connected set of blogs that share a common potential user base, common possible plugins and themes.

      The ones I see people wanting the most (excluding the ‘shared media/posts’ which I think is out of scope, and yes that includes a multi-network-store site) would be as follows.

      • ‘Traditional’ Network – One super admin, each site admin has all the access they have today. They can run any plugin that’s installed and any theme that’s active. This is what we have today.
      • Blog Network – Same as traditional, starts with allowing new users AND users to create blogs. Sites would be unrelated. This is the WPCOM option :)
      • Sole Admin Network – One person running multiple different sites. Generally they have to log in as the super-admin all the time to get things done. Functionally this may be the same as traditional, but all registration etc would be locked down.
      • Company/School Network – Each site has it’s own admin, but the admin has limited rights. They cannot mess with plugins that may not be network activated (think plugins acting like themes do – network activated or available on a per-site basis).
      • Private ‘Family’ Network – Less restrictive than the company site, you make a network for your group of people and you maintain it, but you have closed registrations and limit things.
    • Mike Schinkel 4:24 pm on February 18, 2015 Permalink | Log in to Reply

      Following up on what Ipstenu said on Guithub, it seems that all these presumed “Network Types” are simply a collection of potential (programmer level) configuration options (so as not to violate the “Decisions, not Options” principle.) If we looked at all potential types, envisioned and not yet envisioned, we would come up with a finite list of (new?) configuration options.

      It would seem the first step then would be to identify and document all these potential configuration options at an atomic level. From there we could then “map” Network Types to their associated configuration settings.

      Even better, Network Types could then be registered just like how Post Types, Post Statuses and Taxonomies are registered which would make missing out on an important use-case in core much less problematic.

      With this proposed approach everyone both pro and con network types can get their cake and get to eat it too.

      • Gabriel Mays 9:37 pm on February 18, 2015 Permalink | Log in to Reply

        I agree. We could spend a lot of time thinking about different permutations that could exist, we’re better off just making it flexible.

        Each network type is just a collection of options with their corresponding values that make that network type unique. So as new popular use cases arise it’d be fairly simple to add new ones or let people add their own (i.e. import network type via XML).

      • Fabien Quatravaux 8:37 am on February 19, 2015 Permalink | Log in to Reply

        That’s a really great idea ! Let’s put power into the right hands (the developer ones).

      • MartyThornley 4:38 pm on February 20, 2015 Permalink | Log in to Reply

        You beat me to it! +100 for this. Core could define a few then plugins could create new types or option sets. I think of it as comparable to user roles and capabilities. There are network types which are like roles and options which are basically defining what that type is capable of.

      • Jeremy Felt 4:12 am on February 24, 2015 Permalink | Log in to Reply

        I think the concept of “registering” network types rather than defining all of the possible permutations is appropriate. We can decide on 2 or 3 very specific configurations that meet the “blogging network” vs “utility network” vs …. and then provide an easy way to filter that list of network types—through register_network_type() or something similar.

    • Mike Schinkel 4:25 pm on February 18, 2015 Permalink | Log in to Reply

      Another Network Type that I’ve seen is what I’d call the “Shared Server” network type. This is a network of completely unrelated sites, often developed by completely different people, but hosted on a single multisite because of a misguided opinion that this makes sense.

      I do not advocate this use-case and have even actively fought against it, but it seems there are business consulting firms recommending to IT shops at at least one Fortune 100 company the use of Multisite as a way to have one server host multiple WP sites in part so they can then bill out for IT services to each department that needs a site (in this particular case all sites were intranet sites.)

      I have also seen numerous people in forums, on mailing lists and at meetups advocating the use of a single Multisite for hosting all their unrelated clients sites. And I can only assume it is because they don’t understand the pros and cons of multisite. Ugh.

      So I would either like to see this made easier (i.e. by being able to export and elsewhere import a single site’s data and being able to have plugin that are limited to one site) or better yet, make changes in core that somehow make this use-case impossible in future versions and thus force new installations to use multiple single sites and an admin console instead of one multisite.

      • Jeremy Felt 4:18 am on February 24, 2015 Permalink | Log in to Reply

        While I agree generally that this is a misguided use of multisite, there may still be validity in helping to define boundaries for these types of networks. I don’t think it’s a network type that we should account for by default, but it could be cool to see someone create a plugin that helps to nail down problem areas.

        able to have plugin that are limited to one site

        This does need to happen. A+++++ I would like to see #14569 in 2015. :)

    • Mike Schinkel 4:29 pm on February 18, 2015 Permalink | Log in to Reply

      Regarding the “Social Network” type proposed by JJJ on GitHub, if we ignore that Multisite is a requirement for BuddyPress then nothing about a social network actually requires Multisite (other than potentially allowing them their own blog.) Thus it would be great is there is anything added that is not Multisite-specific to support the Social Network use-case would also be applied to Single site.

    • Paal Joachim Romdahl 4:39 pm on February 18, 2015 Permalink | Log in to Reply

      It seems we need a starter wizard that covers the most basic options when the user activates a new multisite. Options that also later can be adjusted.

    • Gabriel Mays 4:54 pm on February 18, 2015 Permalink | Log in to Reply

      For the starter wizard, here’s an idea of what it might look like along with the network settings (originally posted in slack): http://imgur.com/PCnU4rZ

      Idea with tabs is that it’s easy to add more settings in the future, i.e. a domain mapping tab, etc.

      Where the network types are just “bundles” of individual options. But I def think user reg settings and site reg settings should be separated, they’re combined now which is a bit confusing/limiting.

    • Gabriel Mays 4:57 pm on February 18, 2015 Permalink | Log in to Reply

      Regarding network types, I guess it comes down to how different are the network types from each other? I think we should only add a new network type if they are different enough that we believe it’d be complicated for a user to select the options pertaining to that particular type. If we don’t filter then in some way we’ll end up with too many.

      Additionally, just like the admin color schemes plugin there’s nothing preventing people from creating their own network types and letting others use them.

      • Ipstenu (Mika Epstein) 8:44 pm on February 18, 2015 Permalink | Log in to Reply

        In my head, the ‘types’ would pre-fill certain options. So for the wizard you’d pick what you want from the pre-defined ones, or click on ‘customize’ and be a wizard yourself. Or an elf.

        • Gabriel Mays 9:29 pm on February 18, 2015 Permalink | Log in to Reply

          I agree, but why would the “customize” option have to be on the wizard? If the user dismisses the wizard couldn’t we just assume they want to roll their own?

          And the “network type choice isn’t final, it’s just a set of options, which they can change anytime or “reset” to see the wizard (ahem, elf) again. And whether or not they choose a network type I think we expect them to customize at least something, whether it’s the network title, upload quota, welcome message, etc.

          As I understand it, all “customize” means is that at some point they decide to change a setting instead of using the install or network type defaults, which I believe is inevitable. The goal of the network types wizard is just to get them 80% of the way without researching what every option does, right?

          To make it more intuitive we could just call it “Multisite Quick Start” or something since they’re just bundles of recommended settings.

          • Ipstenu (Mika Epstein) 9:39 pm on February 18, 2015 Permalink | Log in to Reply

            Customize clicks you out of the wizard.

            As much as I hate to say it, I worry because of the NUX headaches with the Welcome Panel. Do you know how many people leave it alone? We need to make sure it’s ‘used’ or dismissed, and making an alternate to pick-a-setting may help.

        • Jeremy Felt 4:30 am on February 24, 2015 Permalink | Log in to Reply

          I’m wary of having a customizer wizard of sorts. I can see several plugins springing up to allow other network types to be registered, but it would be nice to avoid managing a lot of options.

    • Frank 9:38 pm on February 18, 2015 Permalink | Log in to Reply

      I see much benefits of the network types for different scenarios on real world examples, there I develop, create for customers. My idea is, that we not get a network type solution with settings ui and confining possibilities.
      I think a small solution like post types, taxonomies to register a custom network type is much easier to create and useful for a lot of scenarios.
      I think is not helpful for the default multisite to have much more settings, ui elements. Network types is sure a helpful type for custom solutions, in the first way for developers. I would see this feature in the core, but not visible on default and usable via the register network type functionality, like post type – no options, decisions.

      • Jeremy Felt 4:31 am on February 24, 2015 Permalink | Log in to Reply

        Completely agree! I think we can decide on a few defined network types and provide ways for plugins to register new types.

    • rosyteddy 2:21 am on February 19, 2015 Permalink | Log in to Reply

      “‘Traditional’ Network – One super admin, each site admin has all the access they have today. They can run any plugin that’s installed and any theme that’s active. This is what we have today.”

      This is so true and it holds good. And is so much needed and so much used.
      However, we need one more : one network plugin or network feature that lets any wordpress site using wordpress downloadable from wordpress.org do the following :
      1) login to wordpress site 1 with wordpress site 2 credentials, provided the sites have mutually enabled this plugin to be ON. (Drupal used to have this type of plugin)
      2) we can follow or befriend anyone on wordpress site1 even if I am a member of wordpress2
      for example:
      friends of userA@worpresssite1 : userA@worpresssite2, userA@worpresssite3, userA@worpresssite4…
      You get the idea
      3) userA@worpresssite1 can comment on a blogpost by userA@worpresssite2 on his site as userA@worpresssite1
      http://gnu.io/social/ diaspora and others already let you do this, same thing can be done if you have logged in using wordpress.com login and other sites also use wordpress.com login
      Just extend that from wordpress.com login to any wordpress site login
      4) Same about “likes”
      For example: This blog post has been liked by userA@worpresssite1, userA@worpresssite2

      Note: userA@worpresssite1 and userA@worpresssite2 are completely different users – the similarity in name is just coincedental :)

      If this can be done it will be a potentially useful and popular network, even larger than FB but only if implemented right now without the years of delay that Buddypress has done.

    • Fabien Quatravaux 9:23 am on February 19, 2015 Permalink | Log in to Reply

      I agree with @bueltge and @gmays : what I like the most in WordPress is that the admin UI is very simple (not so many options, all options are easily understandable), and real power is hidden for non-developers. For example, there is not UI to create new Post Types, taxonomies, or shortcodes, but that’s what make WordPress so flexible.

      We could write an infinite list of different network types and still missing some cases. So let’s just list the discrete options that should be available. Later, we could chose 3 or 4 network types to be present in core to ease the installation of popular network types.

      Here is my list of options :
      1. Allow new users to register (already available)
      2. Moderate new user registration requests
      3. Allow approved user to create a new site (already available)
      4. Moderate new site creation (with the option to automatically allow site creation for some user, the same way comments are moderated)
      5. Allow site admins to manage their site users (already available)
      6. Each theme can be provided to each site independently (already available)
      7. Each plugin can be provided to each site independently
      8. Site access restriction : public OR only to logged-in users OR only to site admin OR completely offline OR in construction (today only public OR completely offline options exist, and they are managed by super-admin not by the site admin)
      9. Add some filters to customize the `wp-admin/network/site-info.php` page : adding some site options, adding or removing tabs, …
      10. Allow access to admin area for each role (typical use case : subscribers will be able to log-in but won’t have access to admin area)

      And here is what the API could look like:

      {{{
      register_network_type( ”,
      array(
      ‘allow_new_users’ => ‘always’, // always, moderate or never
      ‘allow_new_sites’ => ‘always’, // always, moderate or never
      ‘admins_can_manage_users’ => true,
      ‘wp_admin_access’ => array( // list of roles
      ‘super-admin’,
      ‘administrator’,
      ‘editor’,
      ‘author’,
      ),
      ‘admin_menu’ => array( // list of default available menus
      ‘themes’ => array(‘twentyfifteen’), // list of default available themes
      ‘plugins’ => array(‘akismet’), // list of default available plugins
      ),
      ‘sites_options’ => array( // list of options available in the sites admin UI
      array(
      ‘label’ => ‘A site option’,
      ‘type’ => ‘checkbox’,
      ‘default’ => ‘checked’,
      // this part could be similar to the settings API ?
      ),
      ),
      )
      );
      }}}

    • faospark 10:18 am on February 19, 2015 Permalink | Log in to Reply

      “What network types are there? ”

      -Maybe we should start from what we have.
      In the network settings page, particularly the registration settings. right from there we can start to see of what is an example of Open Network and a Closed Network.
      the first two options in the registrations settings (i.e. disabled registrations and user accounts may be signed up ) essentially constitutes an example of a Closed Network while the two succeeding ones constitutes (i.e. users may sign up new sites, sites & user accounts can be Sign uped.)an Open Network.

      For the purpose of discussion i will refer to the default blog on multisite as the parent network and subdomains or sub directories as child sites or sibling sites.

      Closed Network Examples: Organizational Type/ Collaborative Type and Task Oriented Type
      In a Closed Network. what essentially fundamental to it is that everything that is happening is intrinsically from the Parent Network and the identity of the child sites is almost always attached to the Parent Network or its Sibling sites. In real world example the best way for you to visualize this is how an Organization with Chapters work. the chapters almost always has to collaborate with the parent org. will call this example as Organizational Type of Network or Collaborative Type.
      Furthermore. Child sites of Closed network can also Task oriented. where in by which a child site performs a very specific task. Examples are customer support on a sub domain,general forums on sub-domain. user account management on a subdomain. I would call this example as Task Oriented Type of Network
      The key thing about Closed Networks is that the creation of child sites is influenced by factors intrinsic to the parent network and the maturation of child sites does not necessitate of it being mapped on own domain.

      Open Network: Open Showcase and Moderated Showcase
      in comparison Closed Networks, in an Open Network, the creation of child sites is more influenced by an external factor. The main function of the parent network is a showcase site of its children sites.
      its only a matter whether it would moderated or free brawl. in an open Network, The maturation of child sites is very likely and child sites is almost independent content wise from its parent network and sibling sites.

      Summary :
      2 main network types : 1)Open 2)Closed
      Closed Network Examples: Organizational Type/ Collaborative Type and Task Oriented Type
      Open Network: Open Showcase and Moderated Showcase

      “Which of these should be pre-configured in core?”
      -I think we already have based from what i said above , but it would be a lot better if we make multisite installs by default a closed network type;

    • joesell89 10:27 am on February 19, 2015 Permalink | Log in to Reply

      First off, I am not a developer, but I do use multisite. I thought it may be useful to just contribute how I use multisite. Just to add to the mix :-)

      We use multisite to link websites and blogs within our company. We have a membership site a blog and an internal team website. Blog creation is closed but registration is open.

      In the future we would love it if when someone was given a role on one site and had it everywhere else on the network.

      Having a multisite network makes sense because it is easier to setup and configure a new or temporary site and many of the plugins and themes we use are shared anyway.

      Hope this point of view is helpful.

    • ivanblagdan 11:07 am on February 24, 2015 Permalink | Log in to Reply

      Im a developer on a few long term corporate multisite projects, and I’d just like to add my two cents here, even if it might be a little off track and late.
      To start off, I’d state that in my experience, multisite installations easily spiral out of control in terms of complexity. They require more effort and consideration, than in non-multisite, to corral client requests into something that doesn’t end up a mess to be maintained down the road. I’m talking about growing, long term site networks rather than a network of private blogs.

      Most of these have their blogs created by network admins, and in some cases allow user registration on specific sites for various capabilities (commenting, or uploading files, RVSPs etc.).
      Some of these networks are groups of site localizations that share 99% of configuration.

      I think that the use case for preset network options is rather weak and that a certain level of technical ability is to be expected from the person setting up/running the network. I’d rather see this get more flexible, but from the ground up on a API level.

      A few weak spots I encounter:

      • Media asset management, sharing and editorial permissions among specific sites.
      • General user and permission management
      • Configuration management of various sites.
      • Content/data exchange between sites

      All of these are certainly possible, and to a degree mitigated by a few great plugins, but in all honestly it always feels like hacking around something, not actually extending it.
      I feel much of the discussion here should trickle down to API requirements and modularization of these underlying mechanisms and allow flexibility to grow from there, in form of either replacing them by third parties completely or by plugin extensions.

      I also feel that looking at the code, this duality of WordPress in terms of blog/multisite is really apparent and disruptive to the overall architecture, and it would be made worse by introducing another fork in this code path with things like wp_get_network_type().

  • Jeremy Felt 11:40 pm on February 17, 2015 Permalink |
    Tags:   

    Multisite Office Hours Recap (February 17, 2015) 

    Multisite office hours are held every Tuesday at 21:00UTC in #core-multisite and are followed by a casual bug scrub / ticket conversation at 22:00 UTC.

    We covered two agenda items today:

    1. There was some group interest in hearing from wp.com folks about custom solutions in place for multisite. @tellyworth, @pento, @boren, and @johnbillion were around to provide some insight.
    2. How to start the open/closed (trusted/untrusted) (magic/science) network conversation. Defining definitions and first steps.

    Notes on Core hacks in use at WP.com

    Logs for wp.com discussion.

    1. wp.com allows you to set a different language for the admin area and your site, not available in core due to performance reasons.
      • Use case: allow “users who may want their admin in one language and various sites on the network in various languages“.
      • wpcom_switch_to_locale() exists
      • Used for HTML emails as well, send emails in proper locale based on user defined settings.
    2. An async jobs system is used in a few places to run slow tasks, similar to cron. This would be great to see as a “show your work” plugin (i.e. HyberDB).
    3. Handling of cross domain cookies, full SSL. How is that handled?
      • Load wp.com JS in the header, which checks for an auth cookie on wp.com and on the custom domain.
      • If there’s no custom domain cookie, do some magic redirects to auth and write the cookie.
      • General musings over issues with x-domain, x-protocol.
      • Possible lessons to be learned from work on Customizer with domain mapping, mixed SSL, CORS.
    4. Custom network admin pages. Sign-ups, moving users and blogs around, changing usernames.

    In general from @tellyworth“My plan with most is to try to get additional filter/action hooks in core. So if I list the candidates for that, maybe we can identify the custom plugin features we have that are of general interest and could be released open source.

    General takeaways on the wp.com convo:

    • A @tellyworth post on hacks that could go into core via actions/filters/plugins/etc would be excellent.
    • Some sort of example showing off async jobs would be really cool. Similar to HyperDB as a “this is how you do it”.
    • We should look at wp.com cautiously when exploring cross-anything login, but also think outside of the box.
    • Keep exploring what’s possible with multi-language. Performance considerations, etc..

     Open/Closed Networks

    Logs for open/closed networks.

    We quickly solved the first unsolvable question for open/closed networks in multisite: Is it worth trying to user better terms than “open” and “closed” when talking about open/closed networks?

    • Yes. Open/Closed is too confusing, Trusted/Untrusted is too confusing. We need a better way of referring to this conceptually.

    The second unsolvable question took a bit longer, but was also solved: How do we describe this in a sentence?

    • @jjj paraphrased a good discussion – “multisite is now a utility for managing multiple sites using one installation, where as the original vision was to enable blogging networks“.
    • @johnbillion – “So, to that end, how can we best provide that utility in a simple way?”
    • General conclusion: A future in which installing a network is the choice of a pre-configured network type.

    After this we covered what network types might look like in core and how that could be facilitated through config or UI or… It seems there is general support for selecting the type of network to install during the standard setup process.

    Next steps. Sit on the granular bits of today’s conversation for the week and open a discussion thread on Make/Core for brainstorming network types and needs as a follow up to the previous GitHub issue. A granular discussion of network types will be the main topic next week.

    Be on the lookout for another post today to start the network types discussion. Thanks to everyone for a lively meeting today!

     
  • Boone Gorges 6:57 pm on February 16, 2015 Permalink |
    Tags: ,   

    Taxonomy term splitting in 4.2: a developer guide 

    In WordPress 4.2, shared taxonomy terms – those items in the wp_terms table that are shared between multiple taxonomies – will be split into separate terms when one of the shared terms is updated. This change ([31418]) fixes one of WordPress’s most irksome bugs, and is a critical step in our ongoing taxonomy roadmap.

    Technical details and backward compatibility

    Each row in the wp_term_taxonomy table represents the dyad of a term slug and a taxonomy – say, the tag slug ‘mint’ and the taxonomy ‘herb’. Historically, terms in different taxonomies that shared the same slug would share a single row in the wp_terms table; thus, the ‘mint’ row in wp_terms could correspond to a term-taxonomy pair in the ‘government_building’ taxonomy as well as ‘herb’. Starting with 4.2, when you update a shared taxonomy term – wp_update_term( $mint_id, 'government_building' ) – WordPress will detect whether the term is shared between multiple taxonomies, and if so, will create a new row in wp_terms for the updated term and change all necessary term_taxonomy associations. term_taxonomy_id will stay the same, but term_id will change. This is a case of a shared term being split into separate terms.

    In most cases, term splitting will go unnoticed. However, there are some plugins and themes that store term IDs as static data. In these cases, a changed term ID has the potential to cause various sorts of problems.

    Who is affected?

    In brief, any plugin that independently stores term IDs in the database – postmeta, usermeta, the options table, etc. @mboynes and I looked over the top 100 most popular plugins on wordpress.org, and found eleven that will need changes in order to anticipate term splitting: Jetpack, WordPress SEO by Yoast, Google XML Sitemaps, All in One SEO Pack, Mailpoet, Advanced Custom Fields, Ninja Forms, Types, Custom Sidebars, Paid Memberships Pro, WordPress Download Manager. If you’ve written a plugin, theme, or other customization that stores term IDs in a static way, you’ll be affected too.

    What steps should you take?

    WP 4.2 will include a number of tools that developers can use for split term ID migration. The most important is the 'split_shared_term' action. Here’s a concrete example, taken from Jetpack. Jetpack stores a post_tag ID in the ‘featured-content’ option, and in some cases, the tag’s term ID may be shared with another taxonomy term. The following is a simple function that could be used to detect when the term is split, and to update the option accordingly:

    function jetpack_update_featured_content_for_split_terms( $old_term_id, $new_term_id, $term_taxonomy_id, $taxonomy ) {
        $fc_settings = get_option( 'featured-content', array() );
    
        // Check to see whether the stored tag ID is the one that's just been split.
        if ( isset( $fc_settings['tag-id'] ) && $old_term_id == $fc_settings['tag-id'] && 'post_tag' == $taxonomy ) {
            // We have a match, so we swap out the old tag ID for the new one and resave the option.
            $fc_settings['tag-id'] = $new_term_id;
            update_option( 'featured-content', $fc_settings );
        }
    }
    add_action( 'split_shared_term', 'jetpack_update_featured_content_for_split_terms', 10, 4 );
    

    In addition to the 'split_shared_term' action, 4.2 will store information about all terms that are split. Developers can access this information after the fact by using wp_get_split_term( $old_term_id, $taxonomy ). For more details on 'split_shared_term' and wp_get_split_term(), including a number of practical examples, be sure to check out the page in the Plugin Developer Handbook.

    What will happen if plugins and themes don’t update?

    The vast majority of terms are not shared between taxonomies; shared terms themselves are an odd edge case. The vast majority of plugins and themes do not store term IDs. And, moreover, WP 4.2 will only split terms when a shared term is updated (eg, when its name is updated in the Dashboard) – an infrequent event. (Though note that there are plans to force all shared terms to be split in a future release.) Even in cases where a plugin is technically affected, depending on the way the plugin uses its stored term IDs, there may be no perceptible effect at all.

    That said, there are cases where failure to account for split terms could result in fairly disruptive behavior. In the case of Jetpack, for example, Featured Content would stop displaying correctly if the term split were not caught properly. For this reason, it’s critical for developers to examine the way they store term IDs, and to update their plugins and themes accordingly, in time for 4.2 in April.

    Questions or concerns? Read over the practical guide in the Plugin Developer Handbook, or leave a comment below.

     
    • firebird75 7:24 pm on February 16, 2015 Permalink | Log in to Reply

      This is a major change. While I understand that there are some arguments for implementing this change. There are also some arguments for not doing it. 10% of plugins affected is a lot…

      You should add a hook to allow plugin to prevent the split.

      • George Stephanis 7:52 pm on February 16, 2015 Permalink | Log in to Reply

        All the discussions have been had long since over. This is a necessary change, and a prerequisite for a lot of pending things like taxonomy meta and the like.

        It needs to happen for the growth of the platform. It’s paying down some long-since held technical debt and resolving some old bugs where a common term if modified affects the same term in another taxonomy. So it’s at worst swapping one bug for another.

        It is a good change. Adding something to prevent the split would be a bad decision, and also not that useful as it’s assuming any plugins that hook into it would be installed and updated before the user updates core and the splits happen.

      • Boone Gorges 8:26 pm on February 16, 2015 Permalink | Log in to Reply

        Regarding the 10% point: it’s only 10% of the top 100 plugins. These plugins are also disproportionately large and complex, when compared to the average plugin. I’d wager that the percentage goes way down as you go down the long tail of plugins.

      • Brandon Wamboldt 1:26 am on February 18, 2015 Permalink | Log in to Reply

        I dislike this mentality. I think BC breaking changes are necessary for a platform like WordPress to progress. Nobody should expect a to be able to upgrade to the next major version of a platform without following a migration path.

    • George Stephanis 7:48 pm on February 16, 2015 Permalink | Log in to Reply

      Source for the `wp_get_split_term()` — https://github.com/WordPress/WordPress/blob/948f657ea3d2bf5a4b5f86891dc03ba8bf49f012/wp-includes/taxonomy.php#L4272-L4291 — if it doesn’t find one, it returns false.

      (figured I’d save some folks a search)

    • johnstonphilip 7:59 pm on February 16, 2015 Permalink | Log in to Reply

      Just to clarify, the “split” only happens if a post is “in” 2 terms-of-the-same-name AND also 2 different taxonomies?

      If not, nothing changes regarding the term id?

      • johnstonphilip 8:02 pm on February 16, 2015 Permalink | Log in to Reply

        For example: postX has the term “mint” in BOTH the taxonomy called “Government Buildings” AND the taxonomy called “Herbs”?

        Am I understanding that right?

        • Boone Gorges 8:28 pm on February 16, 2015 Permalink | Log in to Reply

          Not quite. It doesn’t have anything to do with posts. The split happens when a shared *term* is updated. (Term updating happens, for instance, at Dashboard > Posts > Tags, as when you change a term’s Description.) A term may or may not be associated with any posts.

    • dcavins 8:25 pm on February 16, 2015 Permalink | Log in to Reply

      Thanks Boone for shepherding the community down Andy N’s roadmap. I’m excited about a simplified data structure for taxonomies and excited about the possibilities of term meta.

      Thanks also for the `split_shared_term` action example, as several of my one-off BuddyPress group plugins refer to terms by id.

    • Chuck Reynolds 9:30 pm on February 16, 2015 Permalink | Log in to Reply

      Wow okay.. good to know..

    • Andrew Norcross 3:25 am on February 17, 2015 Permalink | Log in to Reply

      good stuff. this is one of those bugs that only affected me once or twice, but when it did, it caused hours and hours of headaches trying to hunt down why.

    • Mike Manger 11:17 am on February 17, 2015 Permalink | Log in to Reply

      Correct me if I’m wrong but it looks like all new terms are split by default (e.g. if I make a ‘Testing’ tag/category).

    • leemon 1:24 pm on February 17, 2015 Permalink | Log in to Reply

      Thanks Boone!!!

    • kkarpieszuk 10:43 am on February 19, 2015 Permalink | Log in to Reply

      @Boone I think I don’t see possible cases, could you help me to understand?

      So you say that if I will create new post tag with name “shared” and slug “shared”, it should be added as new row to wp_terms table, yes? (also new row should be added to wp_terms_taxonomy) OK, this is what I see.

      But now I am adding new category with the same name “shared” and slug “shared”. If I understand well what you described I should expect (in WP <4.2) that new row will be added to wp_terms_taxonomy BUT nothing new should be added to wp_terms?
      I cannot confirm that this is what I'm seeing: new row is added in wp_terms_taxonomy AND wp_terms. Please see the screenshot: http://awesomescreenshot.com/0b54fyc910 (I am using clear installation of WP 4.1)

      Could you provide steps which I should perform to see shared term between taxonomies?

    • Josh Eaton 6:22 pm on February 19, 2015 Permalink | Log in to Reply

      In case it’s helpful, I’ve written a plugin to find any shared terms on a site: https://github.com/jjeaton/wp-find-shared-terms

    • JeanPaulH 9:25 am on February 20, 2015 Permalink | Log in to Reply

      If I understand this correctly it won’t be possible in the future to do a wide tag search for – say – ‘cheese’ across multiple (custom) post types? Or is that a different issue?

      • Boone Gorges 6:41 pm on February 20, 2015 Permalink | Log in to Reply

        No, this isn’t quite right. This change does not affect post types at all, nor does it affect tax queries. It’s only an issue when there is a tag ‘cheese’ as well as a category ‘cheese’. And even then, normal taxonomy queries will continue to work as per usual, because these queries are always taxonomy-specific anyway. It’s only when plugins attempt to reference these terms by a stored term_id that any change might be noticed – an uncommon occurrence.

    • Lorelle 7:43 am on February 22, 2015 Permalink | Log in to Reply

      Trying to process this. Will it resolve the SUPER annoying dash-2 bug/issue? When there is a tag already listed, and someone enters the same word as a category, WordPress forces it to be unique with a dash 2 such as the slug dancing-2. It goes the other way, as well. Will this remove or stop the dash 2 taxonomy issues with category and tag slugs?

      • Boone Gorges 1:17 pm on February 22, 2015 Permalink | Log in to Reply

        The dash-2 issue, as you’ve described it, should not happen in 4.1+. Categories and tags are allowed to have the same slug – which is to say that WP will not try to make them unique by forcing a `-2` suffix. You’ll still get the suffix when attempting to create duplicate terms within a single taxonomy, or in certain cases where there are name clashes in a hierarchical taxonomy.

        Shared terms would occur (prior to WP 4.1) in cases where a category and tag shared a slug. So this doesn’t directly involve dash-2 terms, which are forced to be unique (unshared).

    • Shapeshifter 3 7:18 pm on February 26, 2015 Permalink | Log in to Reply

      I started using this now unavailable plugin over 3 years ago:
      https://wordpress.org/support/topic/plugin-wp-render-blogroll-links-custom-order .

      It created Term ID numbers which it used to maintain Categories of Links.
      With it , I also used these two additional plugins:
      https://wordpress.org/support/view/plugin-reviews/link-manager
      https://wordpress.org/plugins/hierarchical-link-categories/

      After uninstalling ALL 3 of the above plugins from my main site, I ran this search plugin I learned about on WP Tavern: https://github.com/jjeaton/wp-find-shared-terms . It informs me that I have mixtures of the following:

      Term Taxonomy ID=126, Term ID=20, Name=All, Taxonomy=Link Categories, Number of Posts=0

      Term Taxonomy ID=20, Term ID=20, Name=All, Taxonomy=Categories, Number of Posts=0

      I believer that the Hierarchical Link Categories create the “All” name back some time ago, and I can’t seem to get rid of it. Also, I believe that somewhere in my Database is a list of ID Numbers created by the WP Render Blogroll Links plugin which is now deleted. How do I find any possibly hidden list of Category Term ID numbers in my Database so I can delete them all individually (am I correct that this might be the reason I still have an “All” name?

      (Additional Information: I have created NO Posts on my main site…I use it for a display of only Pages and Links.)

  • Jeremy Felt 6:00 pm on February 16, 2015 Permalink |  

    Multisite Office Hours – Rescheduled to 21:00 UTC on Tuesdays. 

    During a discussion last week, we realized there was an opportunity to involve more people in the weekly multisite office hours by adjusting the time a bit. Starting tomorrow, weekly multisite office hours will be at 21:00 UTC Tuesday in #core-multisite. We’ll also follow that with a weekly multisite bug scrub at 22:00 UTC Tuesday.

     
  • Drew Jaynes 1:30 pm on February 16, 2015 Permalink |
    Tags: ,   

    This Week in 4.2: February 16 – 22 

    This is the jump-start post for the fifth week of the WordPress 4.2 release cycle.

    The feature plugin merge window is scheduled to open this week on Wednesday, February 18th, and close the following Wednesday, February 25th.

    Core Meetings this week:

    4.2 Feature Chats this week:

    Priority tickets this week:

    Accessibility

    • #26600 – Search installed themes input has no submit button
    • #30619 – The wpView toolbar is not accessible by keyboard
    • #30914 – WP List Table: improve table footer tab sequence
    • #30486 – Missing label associations throughout network admin

    Mobile:

    • #31187 – Allow swiping the admin menu open and closed on touch devices
    • #29989 – Hide Media Buttons on small screens
    • #29993 – Media action links are cramped on small screens

    Posts seeking your feedback:

    Notable updates from last week:

     
  • Gary Pendergast 12:26 am on February 13, 2015 Permalink |
    Tags: ,   

    Emoji Chat Meeting Notes, February 12, 2015 

    The full meeting archive is available here.

    1. Why we’re doing this

    So, here’s a bit of back story.

    As of r31349, WordPress partially supports emoji. ~60% of WordPress sites are running MySQL 5.5 or later (so can be upgraded to store emoji), and ~40% of browsers natively support emoji. Emoji are a wildly popular method of communication, so we can expect them to be heavily used as soon an they’re available. The problem is, 60%/40% means a really bad experience for a huge number of our users, who’ll try to use emoji, and fail.

    This is where the emoji feature plugin comes in to play. In order to help the 40% of WordPress sites that can’t be upgraded to store emoji natively, the wp_encode_emoji() function will turn them into HTML entities. Due to the unimaginable joy that character sets brings me, this will only be applied to sites using the utf8 character set, which accounts for the vast majority of WordPress sites – utf8 has been the default character set since r4860.

    To help the 60% of browsers that don’t display emoji natively, we’re using the Twemoji image set as a fallback. This lets us show emoji everywhere, without causing extra load where emoji are already supported, mobile browsers being the important example here.

    Now, there have been some concerns brought up previously that I’d like to address.

    “Is this really appropriate for core?”

    Yes. (Obviously that’s my answer, or we wouldn’t be here.) WordPress is is the business of making communication simple and accessible for all. Tech users everywhere have clearly chosen emoji as a means of communication, so it’s up to us to make sure they can do that within WordPress as easily as possible, or risk being left behind.

    “Should we be concerned about changing the images in the future? Wouldn’t we be altering users’ content?”

    No. By using Twemoji only when we can’t provide native support for emoji, it’s a pretty clear message that while the general appearance of emoji stays the same, the actual sprite used can differ significantly between platforms. (For example, every emoji set except Android uses a left hand for :thumbsup:.) As more browsers add native support for emoji, Twemoji usage will drop, reducing even further any impact we can have on users.

    And so, that brings us to today.

    2. The current state of the plugin

    The plugin is very close to done. The editor plugin needs some attention, which @azaozz will be providing soon. There are a few bugs to discuss, which are mostly around fallback behaviour in browsers that don’t support emoji natively. Apart from that, the basic functionality is pretty much how I would expect it to appear in core. It’s had a brief review from the accessibility team, with only some minor alterations needed. The Twemoji images won’t be included in wordpress.zip, as it’s a total of 3.4MB of images. They’re currently hosted on WP.com’s CDN, but we’re investigating other options for where to host them, probably the W.org CDN. Given that the wp-admin Dashboard also loads things from Google, I have no problem with hosting them on an external CDN. There will naturally be a filter on the URL, to allow local hosting for sites that don’t want to use the CDN.

    One of the major concerns at the moment is that we’re going to be splitting data formats, depending on if the site uses the utf8mb4 or the utf8 character set. utf8mb4 stores emoji natively, while utf8 requires us to HTML encode the emoji characters. In the futures, we’ll look at upgrading sites to utf8mb4 if they’ve upgraded their MySQL since WordPress 4.2, but that leaves the potential for mixed encoding – old posts having HTML encoding, new posts having the native characters. A post will be automatically updated to native upon saving, but do we need to consider upgrade routines, to go through all old posts and convert them?

    Export/import also needs thorough testing, particularly when importing and exporting between sites having different character sets.

    3. Unicode 8.0: the future of emoji

    To talk about the future of emoji, you need to know a little bit of history. At the basic level, emoji are all single characters defined within the Unicode standard. However, they also support modifiers. Modifiers are a second character following the first, which usually causes the two characters to be merged into a single character when rendered. A good example of this is flag emoji.

    The character G is U+1F1EC. The character B is U+1F1E7 (these characters are different to their ASCII equivalent). When used individually, they’ll display as that letter. When combined next to each other, they’ll display as the British flag.

    So, Unicode 8.0 will two interesting things: a set of 37 new emoji, and skin tone modifiers. When a skin tone modifier character is placed after any face or person emoji, the emoji will show with that skin tone. Unicode 8.0 is due to be finalised in August 2015, so we and (Twemoji) will be looking at adding support for these then.

    From a technical perspective, it just means we need to be aware that emoji are not always one character, and the methods for detecting multi-character emoji are about to get more complex.

    We’ll also be able to detect if a browser is able to render the new emoji and skin tones, and fall back to Twemoji if they can’t. I don’t have a timeline for when browsers will support the new emoji, so I think it’d be good for us to get ahead of the curve then.

    utf8mb4 stores anything in the Unicode address space, including unallocated characters, so I don’t expect any problems with storage of new emoji.

     
    • Ryan Hellyer 8:45 am on February 18, 2015 Permalink | Log in to Reply

      I’m not seeing any reason to host them externally. Why not just bundle an extra 3.4 MB into the zip?

      Even better, perhaps this should just stay as a plugin? Maybe I’m wrong, but this seems a very niche thing to me.

      • John James Jacoby 1:17 pm on February 18, 2015 Permalink | Log in to Reply

        Particularly in the US, I can anecdotally tell you that Emoji has had slow adoption for several years, but it’s becoming less-so with the native inclusion of it in iOS. See my comment below about smilies, which also very easily could have been a plugin (and may have originally been at one point?) but they’re so simple and commonplace now, it’s weird not seeing them rendered as images. :)

      • Gary Pendergast 8:26 pm on February 18, 2015 Permalink | Log in to Reply

        Why not just bundle an extra 3.4 MB into the zip?

        They’re compressed PNGs, so they won’t compress much further. They’d be doubling the size of the zip.

        Maybe I’m wrong, but this seems a very niche thing to me.

        Not so much. Emoji are a very popular method of communication by large groups of the the population. If anything, I’d say it’s an oversight that it’s taken us so long to get to supporting emoji.

    • John James Jacoby 1:15 pm on February 18, 2015 Permalink | Log in to Reply

      Something I don’t see mentioned is the current iteration of smilies.

      • Does Emoji support secretly allow us to nix old-school smilies and cut out an option?
      • Can/should Emoji support be tacked on-top-of smilies and work similarly to Slack and use a bunch of string-replacements?

      Understanding the approach and code behind each is different, they are identical to a typical end-user because – rather conveniently for us – smilies in core have no UI (though there are plugins that implement one.)

      I’m imagining either a new UI option for Emoji similar to smilies in writing settings, or having it use that same one, which led me to wondering how dissimilar the underlying functionality needs to be, or if this is an opportunity to update an old API.

      • Gary Pendergast 8:33 pm on February 18, 2015 Permalink | Log in to Reply

        Does Emoji support secretly allow us to nix old-school smilies and cut out an option?

        If I told you, it wouldn’t be a secret anymore, would it? ;-)

        Can/should Emoji support be tacked on-top-of smilies and work similarly to Slack and use a bunch of string-replacements?

        Nope. That’s a pretty niche usage, with native OS and browser support for emoji increasing, I’d prefer to keep that kind of hack out of core. It’d also be a super expensive search/replace to have happen at render time.

        Currently, there’s no plan to change/remove the existing smiley option – emoji will just work if you happen to use them, smilies will continue to be optional (but will be replaced by nicer images if you do use them).

        I would like to deprecate the smiley option at some point, but I haven’t given it enough thought to say when that could/should happen.

    • Paal Joachim Romdahl 11:54 pm on February 18, 2015 Permalink | Log in to Reply

      It seems adding emoji to core will cause some perhaps a lot of frustrations for people:
      http://wptavern.com/wordpress-4-2-on-track-to-expand-core-support-for-emoji

      As the comment seems to be they can add that feature to core but what about…..-insert feature-

      • Paal Joachim Romdahl 1:24 am on February 20, 2015 Permalink | Log in to Reply

        Another thought….. Call it a Easter Egg. Like in games that have hidden features. Press a combination of keys or go and do something special in a game and it unlocks something cool.
        I think each release of WordPress could include a Easter Egg (“just” for fun and unique use). Emoji is the first Easter Egg and fits perfectly as Easter is around the time of the 4.2 release.

        So when people ask why it was included in WordPress 4.2 one can say it is an easter egg. Meaning it was included “just” for fun (of course it has it purpose for being included).

  • Gary Pendergast 11:25 pm on February 11, 2015 Permalink |
    Tags: ,   

    Emoji Chat Agenda, February 12, 2015 

    Here’s the agenda for Thursday’s Emoji Chat in the #core channel on Slack.

    Time/Date: February 12 2015 23:00 UTC

    1. Why we’re doing this – @pento
    2. The current state of the plugin – @pento
    3. Unicode 8.0, and future plans – @pento
    4. Open Floor/ranting about the evils of emoji – everyone

    See you tomorrow!

     
  • Nick Halsey 11:00 pm on February 11, 2015 Permalink |
    Tags: , , ,   

    Customizer Theme Switcher Feature Plugin Merge Proposal 

    Ticket: #31303

    Customizer Theme Switcher brings theme-browsing and theme-switching functionality into the Customizer. By integrating themes directly into the Customizer, live-previewing workflows are greatly simplified, and the relationship between themes and theme/site options is clarified for the user.

    This plugin represents a significant step in moving all “Appearance” functionality into the Customizer, following Widgets. The future roadmap includes Menus, Theme-Install, and iterations on widgets that would allow the Customizer to entirely replace those admin screens for most users. Because the Customizer Theme Switcher plugin does not address theme-install, the admin page (themes.php) is fully intended to remain in use for now. We are proposing to redirect the front-end “Themes” link (in the admin bar) to the Customizer, as was done for widgets in 4.1.

    Technical Overview

    Customizer Theme Switcher is primarily about adding new UI for existing functionality using existing APIs, rather than introducing new functionality. The plugin operates entirely off of the WordPress 4.1 Customizer API, leveraging the new JavaScript API in particular. Themes is a custom section (that acts kind of like a panel). Each theme is a custom Customizer control.

    The code is heavily Backbone.js-inspired, leveraging JS-heavy portions of the Customizer API to do things like underscore JS templates for rendering theme data. Most of the code is directly adapted from the Backbone-driven themes.php system (and the theme data is retrieved with existing functions), but things like the search/filter are written from the ground up to leverage the Customizer API (in that case, conditionally activating/deactivating controls).

    In keeping with the goal to avoid back-end functionality changes, theme-switches are accomplished simply by leveraging the existing ability to pass a theme as a URL query arg when loading the Customizer; ie, the Customizer is simply reloaded to preview a different theme. Loading overlays are leveraged to make this process seem more instant. Unrelated 4.2 core work around Customizer Transactions could potentially improve how this works.

    Core Changes & Merge Implementation Details

    As outlined in the plugin’s readme there are several proposed technical and user-oriented changes that are best done as core patches (mostly in the merge patch):

    UX

    • Remove #customize-info for theme previews.
    • Change front-end admin bar Themes link to point to themes in the Customizer (deep-linked).
    • When a new theme is activated, go to the home page (front end), not the themes admin.
    • If user doesn’t confirm that they want to leave unsaved changes, remove the customize-loading body class (requires core patch).

    Code

    • Move custom section and control to class-wp-customize-control|section.php in wp-includes.
    • Merge all CSS into customize-controls.css, scope to .wp-customizer.
    • Move .themes-panel-back to the Customizer header, adjust JS accordingly.
    • Merge JS into customizer-controls.js, after the respective object types.
    • Merge customize_themes_template() into wp-admin/includes/theme.php, at the very end. Make sure that this file is included at the appropriate time as needed when adding the Customizer controls.
    • Merge remaining PHP (all in Customize Register callback) into register_controls() in class-wp-customize-manager.php.

    User Testing

    @designsimply has run four usertesting.com tests (see links in #core-customize), and we haven’t really seen any ongoing issues with the actual theme switcher. It has been difficult to get users to follow our instructions, but when they have used the themes-in-Customizer UI, the interactions have been fairly seamless and as-intended. Further testing could be beneficial after merge, but we think that in-person testing and feedback is generally going to be more effective for this particular plugin.

    Outstanding Issues

    The exact handling of the themes header display still needs some work – the backwards-sliding works well but the arrows to indicate it don’t. @folletto opened a ticket on core trac to work through some alternative options. Most of the accessibility issues have been fixed as well (@afercia please let me know if I’ve missed any), with the exception of the Themes section header, which will happen along with the UI changes there for everyone.

    Future Plans

    A future phase of this project will explore integrating theme-install in the Customizer and minimizing the distinction between installed and available themes. Due to the larger UI and UX changes proposed with that effort, we’ve decided to hold off on theme-install for now so that the basic theme-switching functionality could be built on a reasonable timeline for 4.2. This is similar to the manner in which the “THX” feature plugin team re-did themes in 3.8 and theme-install in 3.9.

     
    • bellfalasch 9:31 am on February 12, 2015 Permalink | Log in to Reply

      Looks good =) I personally would love something like a top positioned overlay with short text “You are previewing Theme X – [activate theme] – [cancel]”. Or wouldn’t that make sense in the customizer?

    • Andrea Fercia 1:52 pm on February 12, 2015 Permalink | Log in to Reply

      Thanks very much Nick and great job :) will review all your feedback on the accessibility issues list and will let you know.

    • codeinwp 9:10 pm on February 12, 2015 Permalink | Log in to Reply

      Looks really cool!

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel