Recent Updates Toggle Comment Threads | Keyboard Shortcuts

• 

  Ryan Boren 1:31 pm on November 13, 2014 Permalink | Log in to leave a Comment  

  Dev Chat Summary, November 12th 

  https://wordpress.slack.com/archives/core/p1415826068000473

  Misses

  • Beta 1, 2, 3
  • Feature plugin merge window

  Decisions

  • Focus will merge and default to on during beta.
  • Sessions UI will be reduced to a button to log out of all other sessions and be merged.
  • Shiny updates will not be in 4.1.
  • Merge tonight (Wednesday) and aim for beta 1 around lunchtime GMT tomorrow (Thursday)
  • Friday’s bug scrub (starting 4PM GMT) will be flow focused. https://core.trac.wordpress.org/query?status=!closed&keywords=~make-flow

  Uncertainties

  • There was debate over whether Focus should be on by default. It will be on during beta and feedback will inform the final decision.
  • Twenty Fifteen has an issue with expanding navigation that currently lacks an elegant solution. Fallbacks discussed. https://core.trac.wordpress.org/ticket/30208

  Assignments

  • johnbillion will merge Focus
  • johnbillion will merge sessions UI
  • john billion will aim for beta 1 tomorrow
  • ocean90 will update the patch for 29395
  • iamtakashi will make a patch that unsticks the sidebar if there are child menu for #30208

  Links Mentioned

  https://make.wordpress.org/core/2014/11/11/focus-v2-demo-video/

  https://core.trac.wordpress.org/ticket/30264

  https://core.trac.wordpress.org/ticket/29395

  https://make.wordpress.org/core/2014/11/12/an-update-on-the-taxonomy-roadmap/

  https://make.wordpress.org/

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

  https://make.wordpress.org/flow/

  http://ioshacker.com/how-to/use-quicktime-record-screen-iphone-ipad-ipod-touch-running-ios-8

  https://meta.trac.wordpress.org/ticket/482#comment:12

  https://core.trac.wordpress.org/ticket/29979

  https://core.trac.wordpress.org/ticket/30208

  https://core.trac.wordpress.org/ticket/29979

  Beta 1

  johnbillion [15:04]
  So the main question on everyone’s lips is probably beta 1

  johnbillion [15:05]
  Unfortunately several members of the core team have been preoccupied with 4.0.1, hence we’ve slipped a bit

  johnbillion [15:05]
  The current plan is thus

  …

  johnbillion [15:38]
  On that note, I’m aiming to get some merges made tonight and aim for beta1 around lunchtime GMT tomorrow

  johnbillion [15:38]
  That may shift a little depending on nacin’s availability as I believe he’s doing some talks tomorrow

  Focus

  johnbillion [15:06]
  I will be merging in the editor focus changes that the focus team have been busy working on. Mark posted a good overview video on make yesterday.

  https://make.wordpress.org/core/2014/11/11/focus-v2-demo-video/

  So this is *in* for 4.1

  eric [15:07]
  will it be on by default?

  johnbillion [15:07]
  It will most likely be on by default with an upcoming admin feature pointer to point it out

  ipstenu [15:09]
  I’d vote for on for beta and see how people react. If Beta goes “woah awesome!” reconsider leaving it on for realz.

  johnbillion [15:09]
  Yep this is a simple toggle and we can decide based on feedback during beta

  Sessions UI

  johnbillion [15:20]
  So the other merge item is the user session UI, which, after discussion during last week’s meeting, has been simplified by @jorbin to just a button which displays when a user has more than one active session, which will log them out of other sessions when clicked

  johnbillion [15:20]
  This removes a whole lot of complexity and UI fluff for what is essentially a power user feature

  johnbillion [15:21]
  It also mirrors what several other services do, primarily Slack because we all love Slack

  johnbillion [15:21]
  So that is also *in* for 4.1

  johnbillion [15:21]
  Like everything else, we can iterate on it at a later date

  mark [15:22]
  Are we still capturing IP data for later?

  johnbillion [15:22]
  Yes we will be capturing IP, user agent, timestamps

  johnbillion [15:23]
  See jorbin’s latest patch on #30264

  WordPress Trac [15:23]
  #30264: Users should have a UI for managing sessions

  https://core.trac.wordpress.org/ticket/30264

  Shiny Updates

  johnbillion [15:28]
  So unfortunately due to the work that some core folks have been doing on 4.0.1, the improvements that were slated for the plugin and theme install (and update) screens has not progressed past mockups, so that has been shelved for 4.1

  johnbillion [15:29]
  This has a bit of a knock-on effect on #29395
  #29395: Site Language: Install translations on the fly

  https://core.trac.wordpress.org/ticket/29395

  obenland [15:29]
  Is this planned to be developed plugin first?

  johnbillion [15:29]
  @obenland: Yeah possibly, although @pento and @nacin (not here) pointed out that dealing with installs and updates via a plugin is a hassle, and working directly on core via patches could end up being easier

  ocean90 [15:31]
  For 29395 the plan was to ignore FS credentials for 4.1, is this still okay?

  johnbillion [15:31]
  29395 now has a need for some form of filesystem credentials interstitial, whether it be a modal window or an interim screen, for users who want to install a new language from the general settings screen.

  Yes @ocean90, I think that will end up being the case

  mark [15:32]
  So, it will fail if FS creds required?

  ocean90 [15:32]
  @mark There will be no option to install a translation on these systems. (edited)
  Would be the same as in <4.0. (edited)

  johnbillion [15:34]
  @ocean90: When do you think you’ll have an updated patch ready?

  We can roll with the current patch for beta1 if necessary

  ocean90 [15:37]
  I have already started, maybe in the next 2 hours. Otherwise end of tomorrow.

  Taxonomy Roadmap

  johnbillion [15:41]
  So hopefully most of you have seen the awesome work @boone has been doing on the taxonomy roadmap. He posted an update earlier today: https://make.wordpress.org/core/2014/11/12/an-update-on-the-taxonomy-roadmap/

  johnbillion [15:42]
  I believe this puts us in a good position to think about splitting shared terms in 4.2 and beyond

  boone [15:43]
  Yeah. 4.1 does a lot of the unsexy work required for more exciting taxonomy development in, say, 4.3+.

  johnbillion [15:43]
  And as boone pointed out, this actually needs to happen across releases due to the nature of schema changes on multisite

  boone [15:43]
  Shared terms will be split starting in 4.1, when they’re updated. So the most painful part of shared terms – updating one and having others changed unwittingly – will go away right away.

  But we’ll wait until the schema changes have been rolled out (say 4.2) to force all terms to be split (ie, outside of `wp_update_term()`).

  Mobile Flow

  johnbillion [15:48]
  Next up, @boren has expressed some concerns over lack of improvements to the mobile workflow, mostly with regard to media, but also for post editing etc

  johnbillion [15:48]
  Which I tend to agree with

  I’m not sure what the best way to tackle this is. Maybe we should use Friday’s bug scrub time as a chance to talk through some high priority mobile stuff rather than bug scrubbing?

  johnbillion [15:49]
  Thoughts?

  We need a bit of focus here, rather than just “mobile stuff”

  boren [15:50]
  A flow scrub, perhaps. Pick a flow, clean some stuff up.

  eric [15:51]
  there’s a lot of good ideation on mobile media going on in the Image Flow group; not sure what easy wins can be picked up for 4.1 for that though.

  boren [15:51]
  There are also the make-flow tagged tickets.

  azaozz [15:51]
  Good start would be to go through https://core.trac.wordpress.org/query?status=!closed&keywords=~make-flow

  stephdau [15:52]
  yeah, the trac tag is probably the focus you’re looking for. The leg work has been done (edited)

  boren [15:52]
  The image flow stuff is looking good, but picking small things from that for 4.1 would be difficult. Getting rid of the media modal sidebar on phones would be awesome, but that opens a big can.

  mark [15:53]
  Should we maybe try to direct attention to low hanging fruit elsewhere (in mobile flows)?

  boren [15:54]
  Those make-flow tickets might be the best bet. Several annoyances in there like admin bar behavior.

  netweb [15:56]
  Adding /flow to https://make.wordpress.org for greater exposure and/or contributions would also be beneficial (edited)

  boren [15:58]
  I haven’t done it because it’s been a one person show. But now that @mark has posted. :simple_smile:

  johnbillion [15:58]
  I don’t think that would increase exposure a whole lot. We just need to talk about it more.

  mark [15:58]
  Also, if anyone wants to be able to post on /flow, /msg me here.

  stephdau [15:58]
  johnbillion: it can’t impair it either

  johnbillion [15:58]
  Agreed

  mark [15:59]
  The “Ryan makes an impassioned personal plea” approach worked well for me. :laughing:

  stephdau [15:59]
  maybe it’ll be lucky 13(th box on the page)

  boren [15:59]
  I have a “Be an Alan Lomax of flow” speech that I won’t go into here. :simple_smile:

  mark [16:00]
  For anyone with iOS 8 and OS X Yosemite, you can tether and record the screen.

  mike [16:00]
  It’s also a bit strange, since I’m not sure it’s a “contributor group” in the same way the others listed on the root are.

  obenland [16:00]
  I was wondering how you did it :simple_smile:

  boren [16:00]
  That’s another reason its not listed.

  mike [16:01]
  Not that it’s not important, or doesn’t need more exposure; just feels like a different thing. (edited)

  mike [16:01]
  :simple_smile:

  stephdau [16:01]
  @obenland: http://ioshacker.com/how-to/use-quicktime-record-screen-iphone-ipad-ipod-touch-running-ios-8 (edited)

  netweb [16:01]
  See https://meta.trac.wordpress.org/ticket/482#comment:12, icons already added, /flow just needs adding as a listing

  WordPress.org Meta Trac [16:01]
  #482: Add Training to “Get Involved”

  johnbillion [16:03]
  Ok so Friday’s bug scrub (starting 4PM GMT) will be flow-focused

  Twenty Fifteen

  johnbillion [16:06]
  Twenty Fifteen is moving along nicely, although I must admit I’m not sure of the current status of the separate scrolling sidebar

  Ah looks like that’s been resolved in #29979

  #29979: Twenty Fifteen: Long sidebar produces double-scrollbars

  https://core.trac.wordpress.org/ticket/29979

  iamtakashi [16:07]
  The scroll bar is gone now

  iamtakashi [16:08]
  we still have an issue with expanding navigation though

  johnbillion [16:08]
  Expanding the submenu items?

  iamtakashi [16:08]
  #30208

  #30208: Twenty Fifteen: expanding a sub-menu when the sidebar is fixed needs to conditionally unfix the sidebar

  https://core.trac.wordpress.org/ticket/30208

  iamtakashi [16:09]
  I don’t have an elegant solution yet.

  johnbillion [16:09]
  So @azaozz and I briefly chatted about this at WCSF

  iamtakashi [16:09]
  I really don’t want to lose sticky sidebar if it’s short

  johnbillion [16:09]
  We have a similar situation with the admin menu

  azaozz [16:10]
  Yeah, no good solution exists :disappointed:

  iamtakashi [16:10]
  At the very last resort, we have to unstick all the time.

  mark [16:11]
  Do we need to get some brains together to think it through? Or is it 100% at an impasse?

  azaozz [16:11]
  The current behavior seems pretty logical: after expanding the menu, the user would click on it to go away or can close it to reach the bottom

  iamtakashi [16:13]
  But if there are only, say, just three menu items that have twenty child menu items, there is no way to reach some of child menu items.

  mark [16:14]
  Current behavior on http://twentyfifteendemo.wordpress.com is quite problematic.

  Idea…

  mark [16:15]
  What if, upon expanding down beyond the bottom, it unpins, but it doesn’t re-pin until it is small enough to fit, AND is scrolled to the top?
  So that way, when contracting a menu, it wouldn’t suddenly jump.
  To the original fixed position.
  But once it got to that position naturally, it would stick again.

  johnbillion [16:16]
  You’d need to scroll back up to fix it again

  azaozz [16:16]
  If you are scrolled half-way through long page, the menu will “dissapear” when unpinned

  johnbillion [16:17]
  So as Takashi mentioned, unpinning the menu completely is still an option

  mark [16:17]
  @ozz I don’t follow

  mark [16:17]
  Oh, maybe I do. But we could work around that.

  mark [16:18]
  By not letting it unpin to the top.

  mark [16:18]
  But letting it unpin in its current location.

  azaozz [16:18]
  The sidebar is `position: fixed` :simple_smile: RIght, workaround would be to add all the pinTop/pinBottom stuff.

  mark [16:18]
  I’m just thinking of it acting like two panes.

  mark [16:19]
  When it fits, it sticks. When it doesn’t, it flows naturally. Until it fits again.

  iamtakashi [16:19]
  I think what azaozz is talking about this: https://cloudup.com/cCxgCbrWaWv

  mark [16:20]
  Yeah. it shouldn’t go to the top on unpin.

  iamtakashi [16:20]
  But as mark says, if we can resolve this issue, that’d be great :simple_smile:

  mark [16:23]
  Solvable technical issues? Tricky technical issues? Or conceptual issues?

  iandstewart [16:23]
  All the old patches are in #29979

  WordPress Trac [16:23]
  #29979: Twenty Fifteen: Long sidebar produces double-scrollbars

  https://core.trac.wordpress.org/ticket/29979

  mark [16:25]
  Is there a partial punt solution? Like not sticking if there are submenus?

  iamtakashi [16:27]
  The current approach is much simpler than any of patches in the ticket and I kind of like unstick when we have child menus.

  johnbillion [16:28]
  I think this needs to simmer for a while, see if anyone comes up with an idea

  mark [16:29]
  I don’t think we can sit with what we have. It creates menu items you can’t access.

  iamtakashi [16:29]
  we can continue on the ticket #30208

  WordPress Trac [16:29]
  #30208: Twenty Fifteen: expanding a sub-menu when the sidebar is fixed needs to conditionally unfix the sidebar

  johnbillion [16:29]
  How about a complete un-sticking of the menu as an interim solution

  mark [16:33]
  No-pin-if-child is a punt, that allows pinning in some situations. Addresses usability issues, while allowing it to be nice an pinned for some sites.

  johnbillion [16:35]
  Is someone on the theme team able to spend some time on this in the next couple of days or do we need a volunteer?

  iamtakashi [16:35]
  I’ll try to make a patch that unstick the sidebar if there are child menu.

  iandstewart [16:35]
  @mark just to be clear, you’re using “punt” for no-pin-if-child in this case, as in “this’d be a good enough fix”? (edited)

  mark [16:36]
  iandstewart: it would solve the accessibility issue. So it no longer blocks release for that reason.
  @iandstewart: whether it’s a functional dealbreaker is another question. I would say… probably not.

  mark [16:37]
  It’s less than ideal, because in my mind there is a JS solution that would be perfect. But it’s a good chunk of JS work. And we’re running out of time.

   

  Reply Cancel reply

  You must be logged in to post a comment.

• 

  Boone Gorges 2:50 pm on November 12, 2014 Permalink | Log in to leave a Comment
  Tags: 4.1 ( 18 ), roadmap ( 4 ), taxonomy ( 3 )   

  An update on the taxonomy roadmap 

  In 2013, @nacin laid out a potential roadmap for the WordPress taxonomy component. Progress on this roadmap has necessarily been deliberate and, as a result, somewhat slow. But some important steps have been taken in the last few months.

  Improvements in 4.1

  Recall the problem. Since 2.3 – when WP’s taxonomy schema was first introduced – terms have been “shared” between taxonomies when they happen to share the same slug. This architecture was designed to enable serendipitous connections between bloggers writing about similar subjects, especially when combined with “global” terms, which are shared across a multisite network. However, as WP has developed as a CMS and taxonomies have been put to much broader use than originally envisioned, this feature has ended up causing more problem than it solved. Shared slugs in particular have caused a good deal of frustration for users and developers. A notable example is the infamous #5809: changing a term in one taxonomy (say, ‘Chicago’ in the taxonomy ‘cool_cities’) would update all terms that happened to share the same slug (say, ‘Chicago’ in the taxonomy ‘cool_bands’).

  Fixing this behavior has required a series of carefully staged maneuvers. Here’s what’s happened during the 4.1 cycle:

  • Unit test coverage has been improved for wp_insert_term(), wp_update_term(), and term_exists() ([29798], [29830], [29875]).
  • We fixed a few edge-case bugs in term_exists() #29589 #29851. These fixes, plus the increased test coverage, have made us confident in our ability to prevent the creation of unwanted duplicate terms in most cases, a prerequisite for the next item.
  • We removed the UNIQUE index from the ‘slug’ column in wp_terms #22023, and added some failsafe logic to avoid duplicate term creation in certain edge cases [30238]. This step is small but critical. “Splitting” existing shared terms means creating a new row in the wp_terms table for each item in wp_term_taxonomy that currently shares its ‘term_id’ with another item. But when we split these terms, we cannot change their slugs, or we’ll break backward compatibility with things like taxonomy archive permalinks. That is: example.com/cool_bands/chicago and example.com/cool_cities/chicago must continue to work. So the ‘slug’ column of the terms table must not enforce uniqueness.
  • We stopped creating new shared terms #21950. This means that each new item inserted into wp_term_taxonomy will correspond to a new row in wp_terms, even if the new item shares its slug with an existing term.
  • Updating a shared term will cause it to be split into two separate terms #5809. This addresses the primary pain point of shared terms: you can now change ‘Chicago’ to ‘The Windy City’ without your readers thinking that you’re confused about the artists behind this hard-rockin’ hit.

  In short, while 4.1 won’t completely remove shared terms from WP – see below – it should alleviate the pains they inflict.

  Looking ahead

  The continued existence of shared terms in the database means that we still have to deal with the translation between ‘term_id’+’taxonomy’ and ‘term_taxonomy_id’, a requirement that limits the cool things we can do with terms. As such, cleaning up existing shared terms is a top priority. #30261 lays out some suggestions for how to expunge them from the database. This step isn’t practical for 4.1: we can only split existing terms when the 4.1 database schema change has been applied #22023, and schema changes are not immediate in multisite enviroments. But we can consider it for 4.2.

  Once term_ids and term_taxonomy_ids are in one-to-one correspondence, we can start on some of the more exciting items that Nacin outlined. Termmeta #10142 becomes a viable possibility once we can rely on unique term_ids. And collapsing the wp_terms and wp_term_taxonomy tables #30262 will allow us to simplify and streamline the internals of our taxonomy functions. These are tasks that we can start exploring for 4.3 and beyond, at least one version after we’ve split existing terms on all installations. These tickets are a good starting place for people who are interested in following (and contributing to) the future of taxonomies in WordPress.

  Manny Fleurmond, leemon, Mark Jaquith, and 7 others are discussing. Toggle Comments

   
  • 

    Marko Heijnen 3:46 pm on November 12, 2014 Permalink | Log in to Reply

    It would be an awesome command to have in WP CLI that can split all shared terms.

    • 

      Boone Gorges 4:05 pm on November 12, 2014 Permalink | Log in to Reply

      You could write a script that calls `$ wp term update` on each existing term (without actually changing anything).

      • 

        Boone Gorges 4:28 pm on November 12, 2014 Permalink | Log in to Reply

        (Or just wait until 4.2, when WP will do it for you )

    • 

      Mark Jaquith 9:56 pm on November 12, 2014 Permalink | Log in to Reply

      I think we can actually do this with existing WP CLI commands piped together. Might be nice for some bigger sites to be able to run this on command line in the middle of the night.

  • 

    Stephane Daury (stephdau) 3:49 pm on November 12, 2014 Permalink | Log in to Reply

    Nice work!

  • 

    Pippin Williamson 3:53 pm on November 12, 2014 Permalink | Log in to Reply

    Beautiful.

  • 

    Zach "The Z Man" Abernathy 3:59 pm on November 12, 2014 Permalink | Log in to Reply

    First, great song. Second, great work. Very stoked about the progress made in one of the biggest pain points that currently exists. Definitely looking forward to the end result down the road.

  • 

    Frank Klein 4:29 pm on November 12, 2014 Permalink | Log in to Reply

    This is great, congratulations to everybody for their work on this.

  • 

    dcavins 8:46 pm on November 12, 2014 Permalink | Log in to Reply

    I look forward to being able to fetch the terms in the ‘cool_bands’ taxonomy via the meta query ‘members_contributed_to_soundtrack’ = ‘Karate Kid’. Until then, I’ll try to fill the emptiness somehow.

    • 

      Boone Gorges 8:53 pm on November 12, 2014 Permalink | Log in to Reply

      Your site sounds awesome.

  • 

    leemon 11:28 am on November 13, 2014 Permalink | Log in to Reply

    Awesome! Big thanks for moving this forward! Those of us who use WordPress as a CMS really appreciate these fixes.

  • 

    Manny Fleurmond 3:44 pm on November 13, 2014 Permalink | Log in to Reply

    With split terms, maybe we won’t need to prefix the terms for the post_format taxonomy. Can’t wait for the road to object to object connections. It can only be a good thing

• 

  Mark Jaquith 5:57 am on November 11, 2014 Permalink | Log in to leave a Comment  

  Focus v2 demo video 

  Here is the current state of the Focus v2 project, a re-think of Distraction Free Writing:

  I would like to propose that we immediately merge this into core for 4.1.

  Some of the bullet points:

  • Current Distraction Free Writing (DFW) interface is too much of a transition.
  • Current DFW doesn’t give you quick access to everything (you feel trapped in it).
  • Current DFW isn’t very discoverable.
  • New DFW (Focus v2) triggers on keyup (discoverable).
  • New DFW transition is seamless. Things you don’t need while typing just go away. Your scroll position is maintained. It’s the same editor, whereas before it was a separate one.
  • New DFW gives you instant access to all your meta boxes and everything else, with a wag of the mouse, a TAB press, or a tap.
  • Best of both worlds!

  Not mentioned in the video is that the old DFW button now is a disabling toggle for this mode. So it’s Auto/Off, instead of On/Off.

  Ionel Roiban, Gary Jones, Helen Hou-Sandi, and 32 others are discussing. Toggle Comments

   
  • 

    Ansel Taft 6:19 am on November 11, 2014 Permalink | Log in to Reply

    It looks grrrrrreat!

  • 

    Andrew Ozz 6:29 am on November 11, 2014 Permalink | Log in to Reply

    Works great, lets merge!

    • 

      Janneke 11:15 am on November 11, 2014 Permalink | Log in to Reply

      Haha

  • 

    Mickey Kay 6:32 am on November 11, 2014 Permalink | Log in to Reply

    Looks awesome. One suggestion would be to expand editor to full width. I realize this might cause more distractions with text wrapping changing on the transition, but it might be nice to try going full width and really taking advantage of ALL the real estate.

    • 

      Michael Arestad 10:25 am on November 11, 2014 Permalink | Log in to Reply

      It’s super distracting if the field you start typing in moves at all. I would love it if there was later work done to ensure that the editor is always centered on the user’s screen.

    • 

      Janneke 11:26 am on November 11, 2014 Permalink | Log in to Reply

      If the content is smaller than the editor (most cases), it doesn’t make any difference, you juts have more white on your page. If the content is larger than the editor it’s most likely more difficult to read and write something.

    • 

      Timothy Bowers 2:49 pm on November 11, 2014 Permalink | Log in to Reply

      Ya it does look awesome.

      I too would personally love to either see the editor expand or at minimum centre, but I get how that might be distracting for some.

    • 

      fredhead 3:07 pm on November 11, 2014 Permalink | Log in to Reply

      This definitely is an improvement. Maybe the option to make the editor full width while typing could be a future option and enhancement. It’s also true the left and right columns of the editing page are fixed width. Widening the browser window before you start writing expands the default editor width before the rest of the editing elements disappear, something not obvious in the video. The empty right column in the video looks wider than it is in most cases for me.

      I happen to like the current DFW scheme but would want to add the top buttons and the word count to that all white background. I didn’t mind clicking in/out. But this solution works for me.

  • 

    Peter Luit 6:54 am on November 11, 2014 Permalink | Log in to Reply

    @Mickey: no full width (does not represent the actual display), but more focus on WYSIWYG, playing with typefaces etc.

    Still the editor does not represent the actual display of what is to be expected. The ‘preview’ button is an ‘in-between’ solution, but I would like to see a real WYSIWYG editor. So removing distractions with this feature is fine, but for me it is just a beginning of a complete new focus on the editor.

    • 

      Janneke 11:21 am on November 11, 2014 Permalink | Log in to Reply

      There’s no way to do “real” WYSIWYG on the back-end, at least not with this UI. If you want a WYSIWYG editor, install a front-end editor plugin. The back-end editor is *not* a WYSIWYG editor, it’s a visual editor for HTML.

  • 

    Luke Carbis 6:56 am on November 11, 2014 Permalink | Log in to Reply

    +1

  • 

    Hassan 7:33 am on November 11, 2014 Permalink | Log in to Reply

    I like it!
    Will there be an option to disable this though for those who might find it annoying? User-specific maybe?

    • 

      Janneke 11:22 am on November 11, 2014 Permalink | Log in to Reply

      Yes, there already is. Just click the fullscreen button on the right and it will disable it for the current user.

  • 

    Philip Arthur Moore 7:46 am on November 11, 2014 Permalink | Log in to Reply

    Goodness gracious this is nice.

  • 

    SiamKreative 8:30 am on November 11, 2014 Permalink | Log in to Reply

    I never actually used the DFW mode so it’s a great news!

  • 

    chzumbrunnen 8:32 am on November 11, 2014 Permalink | Log in to Reply

    Nice! Would kind of an opposite “forgiveness” be cool or do you think this would add distraction back?
    What I mean is: if you don’t write for a certain amount of time, bringing the metaboxes back.
    Probably, if someone needs it, he will move the mouse there but I thought maybe someone could miss it and not know where to search.

  • 

    Ryan Hellyer 8:50 am on November 11, 2014 Permalink | Log in to Reply

    Am I the only one who doesn’t see the point in this? I assumed anything dedicated to distraction free writing would need to be opt-in and full-screen. The benefit I saw in the distraction free editor was that it was full-screen. Just hiding some admin Chrome doesn’t seem very useful to me.

    I’m sure I’ll get used to it once it’s baked into core though

    • 

      Andrey "Rarst" Savchenko 8:59 am on November 11, 2014 Permalink | Log in to Reply

      The typical DFW formula includes opinionated enforcement of minimal environment, not just providing it. In that way current DFW is genuinely such.

      This feels more like solution to bulky admin interface than genuine DFW editor. It’s good in it’s own way, but more like Distraction Light, not Distraction free.

      PS I suppose can use browser’s functionality to get full screen part.

      • 

        davdebcom 2:15 pm on November 11, 2014 Permalink | Log in to Reply

        +1

    • 

      Dave Clements 3:43 pm on November 11, 2014 Permalink | Log in to Reply

      Nope, you sure aren’t. I’m really not seeing what all the fuss is about yet. Once it lands, I may come to love it, but I certainly don’t (yet) see it as a feature that I would want, need or use.

    • 

      Mark Jaquith 6:24 pm on November 11, 2014 Permalink | Log in to Reply

      DFW was never full screen. It was full-ish window. Same as this. We’re height limited by the window, which we’re using to good effect in both. We’re width limited by $content_width anyway, so making the editor wider isn’t going to change anything (unless we get rid of the concept of $content_width limiting, which would be a big decision).

  • 

    dimitris33 11:13 am on November 11, 2014 Permalink | Log in to Reply

    is this for 4.1?

  • 

    mindctrl 1:48 pm on November 11, 2014 Permalink | Log in to Reply

    This is great work. Question: why does the menu bar on the left do a slide transition while everything else fades nicely? The slide is distracting and doesn’t feel right, and it doesn’t match what happens to the rest of the interface. Why can’t it fade like everything else?

    • 

      davdebcom 2:15 pm on November 11, 2014 Permalink | Log in to Reply

      Agreed, fade out/in of menu bar seems less distracting than the current slide.

    • 

      Mark Jaquith 6:26 pm on November 11, 2014 Permalink | Log in to Reply

      Because the fade was way more distracting. We all had the same instinct you did, and tried it two separate times. But because it starts almost-black and fades to almost-white, the “color distance” of the fade proved to be very distracting.

      Also, “sliding” is sort of a known paradigm with the menu, as it has the expand/contract feature that implies horizontal motion.

      • 

        mindctrl 12:13 am on November 12, 2014 Permalink | Log in to Reply

        Interesting. Thanks for shedding some light on that.

      • 

        Gary Jones 1:02 am on November 13, 2014 Permalink | Log in to Reply

        Was there any discussion about sliding the admin bar up, rather than just darkening the text (which is a third animation type happening at the same time as the slide left and fade)?

  • 

    davdebcom 2:28 pm on November 11, 2014 Permalink | Log in to Reply

    1. In current DFW saving the article does not refresh the page, so you have almost infinite “CTRL Z” history which is pretty nice! I would really miss that in this new version. The video does not show how saving works now, but I assume it refreshes the page like the current post edit page?

    2. I actually liked that it was a transition to get into and out of DFW, because you make a conscious step to go into that writing mode. Maybe keep the current “real” DFW, and add these improvements as part of the non-DFW normal writing mode. Instead of replacing the current DFW, improve the current normal writing mode?

    • 

      Mark Jaquith 6:29 pm on November 11, 2014 Permalink | Log in to Reply

      1. We had that in until recently, but (a) it wasn’t working correctly and (b) was slipped in without much discussion, and is kind of a big change on the main post screen, so should have real discussion. Maybe a separately investigated change?

      2. A lot of people just didn’t know about it, and a lot of people wanted to try it (and did), but then stopped using it because the transitions were so onerous.

    • 

      Helen Hou-Sandi 9:27 pm on November 12, 2014 Permalink | Log in to Reply

      FWIW, cmd-S actually triggers an autosave. It’s not really exposed anywhere, and isn’t the same as the button, but could be of interest to you.

  • 

    leemon 4:14 pm on November 11, 2014 Permalink | Log in to Reply

    Will we be able to toggle this feature off?

  • 

    Michael Beil 5:26 pm on November 11, 2014 Permalink | Log in to Reply

    Interested to see where this pushes the editor in the future.

  • 

    Matt Mullenweg 5:35 pm on November 11, 2014 Permalink | Log in to Reply

    How does this work and look on mobile?

    • 

      Ryan Boren 6:05 pm on November 11, 2014 Permalink | Log in to Reply

      I wanted visual records showing post creation and edit from front page to published, with and without adding media and with and without focus turned on, for all devices. I’m doing a little touch device testing with the plugin version of Focus, and it seems to be properly disabled. The Focus button brings up the old DFW interface. Regardless, I personally wouldn’t let any feature plugin merge without visual records, especially a feature sitting at the heart of our most important flows.

      Using the editor is a bad experience on an iPad. That doesn’t appear to be the fault of Focus, but vizrecs are still needed. We should baseline this bad experience without Focus and then vizrec with Focus to make sure Focus isn’t making anything worse.

    • 

      Mark Jaquith 6:31 pm on November 11, 2014 Permalink | Log in to Reply

      On mobile, you already have a full width editing experience, so this doesn’t affect mobile. But as Ryan says below, our mobile editing experience needs its own round of TLC.

      • 

        Ryan Boren 6:32 pm on November 11, 2014 Permalink | Log in to Reply

        Saying it doesn’t count. Showing it with a visual record does. You know how little thought is given to mobile. Let’s change that.

        • 

          Mark Jaquith 7:16 pm on November 11, 2014 Permalink | Log in to Reply

          Chastened; hastened.

          https://make.wordpress.org/flow/2014/11/11/post-editing-experience-on-iphone-6/

  • 

    Davide 'Folletto' Casali 5:43 pm on November 11, 2014 Permalink | Log in to Reply

    My visceral reaction seeing that is “omg please turn it off” — even if my technical reaction to that is “that’s amazingly well executed”.

    So… I’m very skeptical about this. Our mind already naturally spaces out if the context stay fixed. If you animate it out… you’re actually creating movement that will attract the attention focus.

    If I want distraction free, I want that explicitly. I use that when I want to focus, but when I do, it’s explicit. That’s why the previous distraction free for me was excellent (even if I agree that could be improved). So I’m also sad to see that mode actually go away, even if I’m glad and I find clever that I can disable it so simply (we probably need a better icon if it lands, tho, I guess). I guess that it’s important to make that toggle now to stick between sessions, since it’s not a mode anymore but a configuration feature on the same page.

    That said, I’m ok in trying it. Maybe in the end what it does it’s not enough to trigger the perception and won’t create too much discomfort when using WordPress as a CMS.

    • 

      designsimply 3:36 pm on November 12, 2014 Permalink | Log in to Reply

      I guess that it’s important to make that toggle now to stick between sessions, since it’s not a mode anymore but a configuration feature on the same page.

      I think this part is already done. I tested the toggle setting to off and that setting seems to already be sticky between sessions for me. I tried logging out and logging back in and clearing cookies and logging back in and the setting was still disabled after the first toggle.

  • 

    hearvox 7:30 pm on November 11, 2014 Permalink | Log in to Reply

    I work w/ journalists who often have lots of metaboxes that need values (CFs, taxonomies, etc.). The current DFW never caught on b/c there’s too-much back and forth — it feels like an entirely separate editor/screen. Focus makes it feel like just a little different view of the editor you’re already working in. Pretty sure that’s the feel the folk I work with want.

  • 

    NodleRedoy 8:45 pm on November 11, 2014 Permalink | Log in to Reply

    I wonder if a menu type approach to the “post settings widgets” (publish, tags, categories, etc.) could make the editor area a bit cleaner.

    What I mean is this… if you would take these “post settings widgets” and put them into a menu on the right side of the page, so that they would fly out when activated (clicked/hovered over) could you remove some of the standard editing page “clutter” and possibly compliment the DFW changes shown in the video.

    I do like the looks of where this is going!

  • 

    johannesfosseus 9:50 pm on November 11, 2014 Permalink | Log in to Reply

    Please, don’t. We (and many others) use WordPress as a “plattform” and we have more then half of the content in meta boxes. In that perspective it’s becomes very odd if content disappear when you type in the default post area. Not great if the distraction free writing becomes a distraction for non bloggers!

    • 

      Andrew Ozz 10:53 pm on November 11, 2014 Permalink | Log in to Reply

      This is a JavaScript based feature. Once it is merged you will be able to completely disable it by deregistering the script, and/or possibly by using a PHP filter (by completely I mean the users won’t even know it exists).

  • 

    Patrick Steil 1:57 pm on November 12, 2014 Permalink | Log in to Reply

    Seems like a great default. As long as a user can easily turn this off if they don’t like it, then I think it will make sense for most users. And there should be a way to turn it off site-wide as well…

    Would love this in core… great work!

  • 

    LittleBigThings 4:06 pm on November 12, 2014 Permalink | Log in to Reply

    I think this would make a nice addition to user experience in the backend editor, thanks.

    I was wondering about whether the idea has come up to add a delay of “a couple of seconds” before the interface fades away. Even if the fade starts only on typing.

    I think people often want to correct a word or set something in bold, … or do just a small change for which the fade does not have an added value. Distraction free writing is required for a state which you enter after some time you have started to write. It would save some fade out and in.

    Just a thought, great work though!

  • 

    siteshack 8:11 pm on November 12, 2014 Permalink | Log in to Reply

    Looks really great. 1 issue that I noticed that I though could be potentially annoying. Around 4:36 in the forgiveness section you had the cursor ready for typing moused over to categories and the text scrolled down. You therefore lost the position of typing and would have to scroll back up and find it.. Now I haven’t played with v4 yet so this maybe my lack of experience with this. It’s great though

  • 

    Ionel Roiban 2:40 pm on November 13, 2014 Permalink | Log in to Reply

    Wonderful! I realize now why our editors don’t ever use DFW. This is a real improvement. How soon are we going to see this in the core?

• 

  Ryan Boren 1:28 pm on November 10, 2014 Permalink | Log in to leave a Comment
  Tags: open-update-thread ( 2 )   

  Open Update Thread, Week of November 10th 

  Let’s try this again. How are those meeting assignments going? How goes feature plugin merge and beta 1 prep? Which tickets do you have your eye on? What’s on your mind and on your todo this week? Let it out in the open update thread.

  Boone Gorges, Ryan Boren, Gary Pendergast, and 3 others are discussing. Toggle Comments

   
  • 

    Ryan Boren 1:39 pm on November 10, 2014 Permalink | Log in to Reply

    Watching the make-flow tickets.

    Psyching myself up to do lots of flow testing and visual records, particularly for Focus. Watch make/flow.

    Hoping to cajole all feature plugins slated for 4.2 to do a release to the plugin repo and show signs of life. It is the time for feature plugins to start behaving like feature plugins. press-this, json-rest-api, how about it?

  • 

    Stephane Daury (stephdau) 3:48 pm on November 10, 2014 Permalink | Log in to Reply

    Had an epic hangout with my team and @nacin to debrief us on the WordPress.org coding infrastructures (past/present/future) late last week. Putting this to good use towards internationalized/localized plugins directories. Hoping to have something to show this week.

  • 

    Ian Stewart 4:36 pm on November 10, 2014 Permalink | Log in to Reply

    Twenty Fifteen is ready for a beta. (Open tickets here.) We’ll be doing our regular weekly meeting for it tomorrow at 15:30 UTC in #core-themes in Slack. If anyone wants to check in on tickets with core theme contributors and help us get the number to zero, join us.

    Exciting developments from last week:

    • Using postMessage to update color schemes; so fast, so nice.
    • Tons of work from testers and patch-contributors in knocking out ticket after ticket to get us down to one minor defect and a handful of enhancements.
  • 

    Nick Halsey 4:58 pm on November 10, 2014 Permalink | Log in to Reply

    Customizer Updates:

    • #21483 now has a commitable first-pass patch that makes media in the Customizer significantly better.
    • #29988 is almost complete – we’ve cleverly implemented postMessage support for color schemes in Twenty Fifteen with a JS template used both for saving and previewing, #27355 is punted accordingly and could potentially change based on the results of this experiment in Twenty Fifteen. One more patch awaiting commit. Also, about screen idea
    • #28032 (for widgets), and #25571 (for headers/backgrounds) are ready for commit and closure. #25569 can then also be closed as fixes once #21483 lands.
    • #29949 and #28504 are ready for commit and closure, or may be punted if there are any strong feelings against them from UI folks.
    • #28542 is ready for commit.
    • #29572 has one more patch ready for commit, then can be closed.
    • #28709, #28650 need new patches to address a couple minor bugs, that can happen during beta.
    • We’re planning on splitting up `wp-admin/js/customize-controls.js` once everything else lands, right before or early on in beta. #30277.

    @ocean90 usually handles most of the Customizer-related committing, but I’m sure he’d appreciate some help if anyone’s available, since we have a lot of commit-ready tickets waiting for final review and commit.

    Also,

    • Once #21483 lands, I’m planning on writing a make/core post on the new API for rendering Customizer controls from JS/Underscore templates, with the color and upload/image controls as core examples.
    • Once we hit beta we’ll probably do another make/core post summarizing all the Customizer improvements in 4.1.
    • Once we’re done with 4.1 Customizer stuff I’m planning on circling back to the Menu Customizer project, and will be looking for lots of help to try to get that ready for 4.2.
  • 

    Gary Pendergast 11:33 pm on November 10, 2014 Permalink | Log in to Reply

    Shiny Updates is sadly looking less likely, we’ll probably need to punt this to 4.2, as it hasn’t advanced beyond the experimental/planning stage.

    This week will be split between some wpdb improvements, and the WP.com merge, so I expect to be opening and closing many tickets.

    • 

      Ryan Boren 4:38 pm on November 12, 2014 Permalink | Log in to Reply

      On the bright side, the credentials screen mockup is looking nice.

      https://cloudup.com/c16zW2uPrha

  • 

    Boone Gorges 7:02 pm on November 12, 2014 Permalink | Log in to Reply

    Spent time this week on the speed of our phpunit suite. Total running time has been cut by about 50%. See #30304, #30284, #30017, [30277].

• 

  Eric Lewis 1:55 pm on November 7, 2014 Permalink | Log in to leave a Comment  

  Documenting JavaScript in Core 

  We had a lively session on JavaScript in WordPress core at the Community Summit last week. Topics were varied, but I’d like to sum up a few threads that point towards an actionable goal: better documentation in JavaScript.

  New Feature JavaScript is complex

  WordPress’ internal JavaScript “libraries” are hard to understand, if not impenetrable for many core developers. For example, the 8000+ lines of code that power the 3.5+ media experience. The JS here hasn’t been written for other developers to consume, so architectural decisions end up being expressed only in code, often without documentation.

  As feature development has become much more JavaScript-driven, we should do whatever we can to make our code comprehensible for fellow core developers. Comprehensible code takes many shapes, but one that everyone can agree on is documentation. Up until now, JavaScript documentation has been an afterthought. We need to make an about-face in this respect.

  Adopting JSDoc

  Core is adopting the JSDoc standard. Last year, WordPress standardized PHP inline documentation. Inline documentation surfaces relevant information to developers about code. This is very helpful (necessary?) when you’re wondering what arguments are to be passed into a class constructor that’s seven levels deep in inheritance (!).

  Picking a documentation standard also makes parsing code possible, to extract this structured data. Our bespoke PHP parser feeds inline documentation into the new WP code reference. Choosing a JS documentation standard makes an auto-generated Javascript code reference a possibility later down the line.

  @kpdesign, @adamsilverstein, @drewapicture and I have been drafting a page on JavaScript Inline Documentation Standards, which will land in the core contributor handbook very soon.

  Let us rally around JS documentation, and get a DocBlock on every JavaScript function. Consider this your battle cry.

  Supplemental Documentation

  Aside from inline docs, we need a place for high-level architectural explanation of our JavaScript to live, probably in the core contributor handbook.  Many at the summit noted that with a few key insights, internal libraries are much easier grokked. @gcorne and I started on documentation for media. We’ll see how this goes.

  Also, insightful tidbits which would have no place in inline documentation could be answered here, to answer questions like why and when we provide no-js fallbacks.

  Follow-up Meeting

  We will discuss JSDoc in the weekly Inline Docs meeting in the #docs channel on November 12, 2014 20:00. Join us!

  Adam Silverstein, Ozh, Amy Hendrix (sabreuse), and 1 other are discussing. Toggle Comments

   
  • 

    Stephane Daury (stephdau) 3:45 pm on November 7, 2014 Permalink | Log in to Reply

    I’ve used JSDoc in previous projects of mine, in parallel with PHPDoc, and it has served me well.
    I haven’t used/configured any software to process an output in years though.
    https://www.npmjs.org/package/gulp-jsdoc seems nice, since many already use Node.js for other things, like grunt, etc (in VVV, etc).

    • 

      Stephane Daury (stephdau) 3:48 pm on November 7, 2014 Permalink | Log in to Reply

      Caveat, but not a stopper, especially if we eventually contribute: it’s alpha5+

  • 

    Amy Hendrix (sabreuse) 4:23 pm on November 7, 2014 Permalink | Log in to Reply

    This is huge — looking forward to helping as much as I can.

  • 

    Ozh 6:29 pm on November 7, 2014 Permalink | Log in to Reply

    That’s neat. Too bad JSDoc uses “@param {object}” instead of simply “@param object”

  • 

    Adam Silverstein 3:14 am on November 8, 2014 Permalink | Log in to Reply

    Thanks for the excellent post Eric! Looking forward to helping with the effort.

• 

  Ryan Boren 1:42 am on November 6, 2014 Permalink | Log in to leave a Comment  

  Dev Chat Summary, November 5th 

  https://wordpress.slack.com/archives/core/p1415221327004284

  https://make.wordpress.org/core/2014/11/05/dev-chat-agenda-november-5/

  Misses

  • Beta 1
  • Feature plugin merge window

  Decisions

  • Extend the feature plugin merge window to Friday, or later.
  • Tag Beta 1 on Friday, or later.
  • Do a scrub of enhancement tickets this week, particularly customizer tickets. 1600 UTC tomorrow (Nov. 6) was suggested.
  • Hook recursion, #17817, will be discussed further after beta 1 with the aim of having it ready for early 4.2.
  • Pending the final call of @ johnbillion, the full UI for the session manager will come later (and will be moved into a plugin in the plugin repository). @jorbin will work up a patch that adds a “Sign out everywhere else” button along with killing all other sessions on password change and capturing data for a future UI.

  Uncertainties, Ambiguities, Do Betters

  • Shiny Updates may be punted in whole or in part. The necessary folks are preoccupied.
  • The Session Manager UI was debated and will likely change for 4.1.
  • “We need guidelines for how we handle feature plugins. It’s been really haphazard, and it has affected our ability to get the features in front of a lot of people.”
  • There is skepticism that merge and Beta 1 will happen this week.

  Assignments

  • @markjaquith will do a merge request post for Focus on make/core.
  • @jorbin will work up a patch that adds a “Sign out everywhere else” button along with killing all other sessions on password change and capturing data for a future UI.
  • @nacin will leave feedback on #29395
  • @drew will look at #21483

  Links Mentioned

  https://make.wordpress.org/core/2014/11/05/dev-chat-agenda-november-5/

  https://core.trac.wordpress.org/query?status=accepted&status=assigned&status=new&status=reopened&status=reviewing&type=!defect+(bug)&milestone=4.1&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone&order=priority

  https://core.trac.wordpress.org/ticket/17817

  https://core.trac.wordpress.org/ticket/29806

  https://make.wordpress.org/flow/

  https://core.trac.wordpress.org/ticket/30264

  https://github.com/johnbillion/wp-session-manager

  https://core.trac.wordpress.org/ticket/29820

  https://core.trac.wordpress.org/ticket/29395

  https://make.wordpress.org/core/2014/11/05/dev-chat-agenda-november-5/#comment-20904

  https://core.trac.wordpress.org/ticket/5809

  https://core.trac.wordpress.org/ticket/29890

  https://core.trac.wordpress.org/ticket/29808

  https://core.trac.wordpress.org/ticket/29988

  https://core.trac.wordpress.org/ticket/26268

  https://make.wordpress.org/core/2014/11/03/open-update-thread/#comment-20901

  https://core.trac.wordpress.org/ticket/21483

  Customizer

  drew [15:10]
  Seems like there’s more than a few Customizer-related enhancements. @celloexpressions: ya’ll have an idea about what could be close and what might need to be punted?

  celloexpressions [15:10]
  Most of the customizer stuff has been ready for/waiting for commit or further feedback for a while

  celloexpressions [15:11]
  A couple aren’t quite there, but we want to get in if we can because they enhance Twenty Fifteen

  Hook Recursion

  #17817: do_action/apply_filters/etc. recursion on same filter kills underlying call

  https://core.trac.wordpress.org/ticket/17817

  drew [15:18]
  This is quite likely 4.2-early, but could use eyes-on for unit test coverage and regression testing,

  jbrinley [15:19]
  To _briefly_ answer (as well as I can), the three questions in the agenda:

  jbrinley [15:19]
  Is there enough unit test coverage?

  I don’t know.

  jbrinley [15:19]
  Does it break plugins which interact with $wp_filter and $wp_actions directly (eg accessing the nested arrays)?

  The patch doesn’t touch $wp_actions. $merged_filters is removed. The $wp_filter array will contain WP_Hook objects instead of nested arrays. Those objects can still be accessed as an array, albeit with some of the quirks that come with the ArrayAccess interface (e.g., you can’t indirectly set elements).

  Does it “fix” any existing behavior which could be seen as a regression?

  Currently, let’s say you have a callback at priority 10. In that, you set another callback with priority 1. The latter ends up running after the former. This patch would change that. Similarly, if you have something at priority 10 and something at priority 11, but the priority 10 callback end up calling the hook recursively, the priority 11 callback won’t run for the outer loop. This patch would change that.

  nacin [15:20]
  As this is definitely not 4.1 (sorry @jbrinley! though I know you know that), can we sit on this until after beta is out and then chat more later this month? This is a good briefing of things as it stands, and I hope a few of us can pick it up soon, but there are lots of other things on everyone’s plate at the moment.

  drew [15:21]
  yep, sounds good @nacin

  Focus

  https://core.trac.wordpress.org/ticket/29806

  drew [15:23]
  @mark: Any update on posting the merge request update on make/core?

  mark [15:23]
  Got sidetracked yesterday. Will do that now.

  Since it’s such a visual thing, I’m just gonna make a video that shows it off and talks through some of the decisions.

  drew [15:24]
  Great. Sounds like the patch is looking pretty good too.

  azaozz [15:25]
  yes, patch is good. May need some more around interactions with the old DFW

  boren [15:25]
  Has it been flow tested on mobile lately, to make sure it doesn’t break anything?

  azaozz [15:26]
  New DFW is pretty much disabled on mobile because of the screen size

  janneke [15:26]
  azaozz: Right, I work on that. Also maybe move the button out.

  janneke [15:26]
  Yeah, it’s disabled…

  psoluch [15:26]
  joined #core

  ginsterbusch [15:27]
  @drew + @mark Hope it doesnt break a11y

  janneke [15:27]
  Don’t think so, but please test. :simple_smile:

  boren [15:28]
  A visual record of a mobile flow would demonstrate that it is indeed disabled for mobile.

  mark [15:28]
  We addressed keyboard accessibility. But please do advise if we missed something.

  azaozz [15:28]
  It doesn’t change anything for accessibility.

  mark [15:28]
  We addressed keyboard accessibility. But please do advise if we missed something.

  azaozz [15:28]
  It doesn’t change anything for accessibility.

  azaozz [15:28]
  For the UI outside of the editor

  boren [15:29]
  A feature plugin shouldn’t break mobile or accessibility the moment it lands.

  boren [15:30]
  I’m not too worried about mobile with Focus, but we don’t have a good record here and I’d like to improve it.

  azaozz [15:31]
  Ryan, right, DFW v2.0 is not loaded on mobile and on old browsers, IE < 9 (edited)

  gokejnr [15:31]
  joined #core

  boren [15:31]
  Someone tell me that with a visual record.

  boren [15:31]
  :simple_smile:

  mark [15:31]
  We just need to verify that for sure. Yup.

  mark [15:32]
  I learned you can tether an iPhone and record video on its screen, so I’ll try that.

  boren [15:32]
  Screenshots would probably be good enough for mobile in this case, but cool.

  ginsterbusch [15:33]
  @mark a11y is not just about keyboard. its also eg. about folks not being able to quickly shift *their* focus (viewing field) to something else. and reading through the ticket doesnt really indicate its an automated or a “click this button to”-feature right now.

  janneke [15:33]
  The button still needs to be removed I think, but I mentioned before I’ll redo that. :simple_smile:

  Sessions UI

  #30264: Users should have a UI for managing sessions

  https://core.trac.wordpress.org/ticket/30264

  jorbin [15:41]
  For #30264 – @johnbillion is supposed to be working up a patch. I’ll check with him and if he needs help, will take over. Otherwise I think the only piece we are waiting on is the API on wordpress.org that @nacin is still working on.

  jorbin [15:42]
  User testing of the feature at WCSF only identified some enhancments we can do to make it more mobile friendly, otherwise it was very well received. Note that it still works fine, but the experience on mobile can be made better (edited)

  drew [15:43]
  @jorbin: Were there still UI concerns with the single vs many sessions problem?

  boren [15:43]
  I know it is a small feature, but this thing wasn’t really a feature plugin. It’s not in the plugin dir, the slug collides with an existing plugin, and hearing “the experience on mobile can be made better” is a bit aggravating.

  jorbin [15:44]
  Not that I know of, but if there are it seems like something we can iron out in beta

  boren [15:44]
  Iron it out before merge.

  boren [15:45]
  Otherwise these aren’t feature plugins, they’re blobs of code on github that are merged without criteria.

  nacin [15:45]
  I’m still kind of tempted to bring it in as a single “Sign out of other sessions” button with no extra UI for 4.1, and continue to play with it for 4.2.

  nacin [15:45]
  Identifying browsers and locations is no small thing.

  jorbin [15:46]
  I hate that idea. I think it adds a button without any context for people to understand “why”

  mark [15:46]
  Context could be added.

  jorbin [15:46]
  The context is the other sessions

  nacin [15:46]
  Slack:

  • Sign out all other sessions *

  Lost your phone? Left yourself logged in on a public computer? Need a way to sign out everywhere except your current browser? This is for you.
  [ Sign out all other sessions ]

  mark [15:46]
  Was going to point to Slack, yeah.

  drew [15:47]
  That’s also not say that you can’t just specify the number of other session without spitting out the fine-grained details.

  mark [15:47]
  And the context could additionally be “You are signed into this site in %d other locations.”

  drew [15:47]
  ^

  chriscct7 [15:47]
  Yeah I like that idea

  drew [15:48]
  Either way, I agree with @nacin that continuing to flesh out the UI/plugin for a future release might be the smartest way to go. (edited)

  nacin [15:48]
  I think an actual number is possibly more confusing, because we can’t tell them context, and would consider just showing the Slack-like UI if it’s > 1.

  jorbin [15:48]
  That seems confusing to me. %d doesn’t really help me as nacin is pointing out

  jorbin [15:48]
  ok, so is the decision that we punt?

  nacin [15:49]
  I’m not advocating punting necessarily, I just saw an opening that would allow us to provide immediate user benefit and try to further improve the overall UX and data we can provide.

  mattheweppelsheimer [15:49]
  +1 to a Slack-like explanation without %d sessions, in 4.1

  drew [15:49]
  I think punt is still up to @johnbillion, but as it is now, that would be my recommendation (in terms of the detailed UI)

  georgestephanis [15:49]
  I’d like to see some user testing sessions on the ux of it to see if / how much it is confusing to normal users.

  stephdau [15:49]
  on the +1 side too. Seems the friendliest, while addressing an immediate need.

  nacin [15:50]
  Also, I’d suggest: “If you think you were compromised, you should change your password. This will also sign you out everywhere.” (And on password change, I don’t know if we clear out all of their sessions, but we should, since they’re dead at that point.)

  jorbin [15:50]
  If we go that route, we should start capturing the UA string and other data in 4.1 so that we have less “unknowns” displayed

  drew [15:50]
  @jorbin: Can you possibly work on a patch for the alternate approach?

  nacin [15:51]
  As a replacement for %d, something like this, perhaps something like this, so as not to completely terrify them: `<small>You are signed into this site in %d other locations. This could be a different browser on your computer, your phone, or another computer.</small>”

  nacin [15:51]
  I’m not against capturing more data now.

  boren [15:51]
  This is the correct repo, yes? https://github.com/johnbillion/wp-session-manager

  GitHub
  johnbillion/wp-session-manager
  Contribute to wp-session-manager development by creating an account on GitHub.

  drew [15:51]
  @boren yes

  chriscct7 [15:51]
  boren: yes

  boren [15:51]
  Last updated 23 days ago?

  jorbin [15:51]
  I can work up the alternate patch based on this discussion

  georgestephanis [15:51]
  @nacin: Or the same browser that had its cookies purged, even.

  boren [15:51]
  Not in the plugin repo.

  boren [15:51]
  Why are we even talking about it?

  chriscct7 [15:51]
  name conflict on it

  chriscct7 [15:51]
  its a feature plugin for 4.1

  georgestephanis [15:51]
  So let’s give it a different slug.

  georgestephanis [15:52]
  +lots to getting these things into the repo as early as possible.

  georgestephanis [15:52]
  Better discoverability for feature plugins would be super-handy.

  mark [15:53]
  We need guidelines for how we handle feature plugins. It’s been really haphazard, and it has affected our ability to get the features in front of a lot of people.

  jorbin [15:55]
  @johnbillion will need to make the final call, but it sounds like the decision is: Full UI will come later (and will be moved into a plugin in the plugin repositroy), I will work up a patch that adds a “Sign out everywhere else” button along with killing all other sessions on password change and capturing data for a future UI. Any objections to this plan?

  sabreuse [15:55]
  I’ve thought about session-by-session, and I agree that it feels plugin-like to me.

  sabreuse [15:55]
  But +1 for an easy “sign me out everywhere else”

  drew [15:55]
  @jorbin I think that sounds reasonable. If it’s not where we need it to be by Friday, we can wait.

  mark [15:55]
  If a feature plugin effort just results in a well-crafted plugin, that’s not a terrible outcome.

  stephdau [15:55]
  @mark @georgestephanis : we could at least use a standard prefix, to “ensure” slug uniqueness: wpf- or something

  Shiny Updates

  Smooth installation and updating of plugins and themes

  https://core.trac.wordpress.org/ticket/29820

  drew [15:57]
  It’s my understanding the decision was made at WCSF to go with shiny installs and leave shiny updates for later

  nacin [15:57]
  Correct. Updates can already be done in bulk, while installs cannot.
  However, all of the people most familiar with the updates code are tied up right now. Beta 1 is unlikely for what we want.

  It’s possible some stuff can be aligned by next week, and that’s up to John if he wants to accept some discrete changes.

  drew [15:58]
  @nacin: OK. So are you thinking punt for the whole thing?

  nacin [15:59]
  Right now, I’m not thinking about it. I may have a better idea come Friday.

  FS Credentials Modal

  #29820: Smooth installation and updating of plugins and themes

  https://core.trac.wordpress.org/ticket/29820

  #29395: Site Language: Install translations on the fly

  https://core.trac.wordpress.org/ticket/29395

  nacin [16:01]
  FS credentials is tied into updates/installs more than language.

  nacin [16:02]
  While it’s nice-to-have for language, if language installs can only happen with ‘direct’, I’m not going to cry.

  drew [16:02]
  Can you leave some feedback to that effect on 29395?

  nacin [16:05]
  Sure. @ocean90 is it already good to land, otherwise?

  ocean90 [16:06]
  If we can ignore the FS credentials, yes

  Taxonomy Roadmap

  https://make.wordpress.org/core/2014/11/05/dev-chat-agenda-november-5/#comment-20904

  #5809: Updating a term in one taxonomy affects the term in every taxonomy

  https://core.trac.wordpress.org/ticket/5809

  boone [16:09]
  I also created some new tickets and dug up some oldies to reflect next steps in the extended Taxonomy Journey

  drew [16:09]
  @boone: Is there a specific report where people can follow progress on that roadmap?

  drew [16:09]16:09
  Or just the Taxonomy component?

  boone [16:09]
  No. Taxonomy component is best for now.
  In the next week I’ll write up a make/core post with some updates and some thoughts about the future

  boone [16:10]
  that’ll have links to relevant tickets

  nacin [16:11]
  some of the stuff that went into this had to do with properly handling DB replication lag and such, just to give you an idea.

  mark [16:11]
  Yes, this is the equivalent of us building a rocket to go to McDonalds and then disassembling it while in flight.

  Twenty Fifteen

  drew [16:14]
  Apparently we’re looking pretty good as we approach beta.

  iandstewart [16:14]
  It’s looking pretty good
  we have one milestoned bug with expanding widgets that we’re still trying to figure out
  and there are some template tag and customizer enhancements that’d be nice to have solid
  but it’s in good shape
  @obenland: did you want to chime in on template tags?

  obenland [16:16]
  Sure. So there are only very few pieces left after a very productive few days at wcsf

  obenland [16:17]
  One is #29890 which @helen is looking at

  #29890: Make menu descriptions available to be displayed on the front-end

  https://core.trac.wordpress.org/ticket/29890

  obenland [16:17]
  Then we have #29808 with two proposed patches

  #29808: Post/paging navigation template tags

  https://core.trac.wordpress.org/ticket/29808

  obenland [16:18]
  https://core.trac.wordpress.org/attachment/ticket/29808/29808.8.diff fixing some some bugs and simplifying bits, as well as changing the screen reader text to an h2 as requested by the a11y team (edited)

  obenland [16:18]
  And https://core.trac.wordpress.org/attachment/ticket/29808/29808.9.diff which would add parity between post and comment navigation template tags (edited)
  Between 29808.9.diff and 29890 we could remove two callbacks from Twenty Fifteen
  and have a nice set of theme api improvements in 4.1

  iandstewart [16:22]
  #29988 would also be a nice improvement that depends on a few other patches outside of the theme (edited)

  #29988: Twenty Fifteen: Use JS/postMessage to update the color scheme instead of triggering a page refresh

  https://core.trac.wordpress.org/ticket/29988

  ocean90 [16:25]
  For the record, 29988.patch will not land in. We have new tickets for this where some are already fixed. But still needs some work. Or a review by me. (edited)

  westonruter [16:25]
  That’s right. The existing patch on 29988 is a standalone proof of concept.

  Bug Scrubs

  drew [16:27]
  We had kind of lackluster effort on the Friday bug scrubs the last couple of weeks due to WCSF/summit stuff.

  As discussed a little bit ago, I’d like to do an enhancement scrub tomorrow morning-ish to see if we can’t clear out some of those outstanding tickets. Any takers for probably 11:00 am EST tomorrow in here?

  drew [16:29]
  I guess 16:00 UTC

  Open Mic

  kraft [16:32]
  Would still love to see feedback on this UI adjustment for default categories: https://core.trac.wordpress.org/ticket/26268 :simple_smile:

  #26268: Add UI to Category page to indicate default category

  drew [16:32]
  I think @helen had some feedback on 26268 but she had to go. I’m not convinced that’s ready for primetime in terms of flow.

  chriscct7 [16:34]
  If a core committer has a couple minutes, got a running list of tickets that are ready to be committed here: https://make.wordpress.org/core/2014/11/03/open-update-thread/#comment-20901

  celloexpressions [16:35]
  #21483 would also benefit from feedback. In addition to UI and code, could use docs help from @drew, has an audio/video issue for @wonderboymusic

  #21483: Refactor Customizer Upload, Image, and Background Image controls to leverage the media library/modal

  https://core.trac.wordpress.org/ticket/21483

  drew [16:37]
  @celloexpressions: OK, I can take a look.

   
• 

  Drew Jaynes (DrewAPicture) 7:23 pm on November 5, 2014 Permalink | Log in to leave a Comment
  Tags: 4.1 ( 18 ), agenda ( 123 )   

  Agenda for today’s dev chat in the #core channel on slack (November 5 2014 21:00 UTC):

  • Beta/Merge Window – @johnbillion would like to extend the merge window and tagging the beta to Friday
  • Hook Recursion – #17817: @jbrinley is requesting some eyes on it (likely 4.2-early). Three main issues:
    1. Is there enough unit test coverage?
    2. Does it break plugins which interact with $wp_filter and $wp_actions directly (eg accessing the nested arrays)?
    3. Does it “fix” any existing behavior which could be seen as a regression?
  • Focus – #29806: Patch for editor focus v2 looks good. @markjaquith will be posting a merge request update on make/core. @johnbillion will decide whether to merge on Thurs/Fri
  • Sessions UI – Needs a ticket, #30264 decision for merge will be Thurs/Fri
  • Shiny Updates – #29820: Decision at WCSF was to go with shiny installs, leave shiny updates for a later release. Awaiting feedback from @pento/@nacin/@melchoyce about whether this still has a chance of getting done in time for merge
  • FS Credentials Modal – #29820: Also affects #29395 (installing languages from general settings screen)
  • Taxonomy Roadmap – @boone is on fire
  • Twenty Fifteen – Some discussion around smaller issues with the new template functions and color schemes, nothing that can’t be iterated upon during beta
  • Bug Scrubs – Continuing weekly bug scrubs on Friday this week, likely a mixture of a11y and 4.1 tickets

  Aaron Jorbin, Drew Jaynes (DrewAPicture), and Boone Gorges are discussing. Toggle Comments

   
  • 

    Boone Gorges 7:26 pm on November 5, 2014 Permalink | Log in to Reply

    Does anyone have a cure for my Jaynes Addiction?

    • 

      Drew Jaynes (DrewAPicture) 10:01 pm on November 5, 2014 Permalink | Log in to Reply

      *groan*

    • 

      Aaron Jorbin 5:11 am on November 6, 2014 Permalink | Log in to Reply

      This thread could easily become a BOONEdoggle if we aren’t careful.

  • 

    Aaron Jorbin 9:58 pm on November 5, 2014 Permalink | Log in to Reply

    RE: Sessions UI. @johnbillion will need to make the final call, but it sounds like the decision is: Full UI will come later (and will be moved into a plugin in the plugin repository), I will work up a patch that adds a “Sign out everywhere else” button along with killing all other sessions on password change and capturing data for a future UI.

• 

  Ryan Boren 8:15 pm on November 3, 2014 Permalink | Log in to leave a Comment
  Tags: open-update-thread ( 2 )   

  Open Update Thread 

  What’s going on in your core development world this week? Drop a comment. Let it OUT.

  Robert Chapin, chriscct7, John James Jacoby, and 9 others are discussing. Toggle Comments

   
  • 

    Ryan Boren 8:16 pm on November 3, 2014 Permalink | Log in to Reply

    Meeting notes were not posted for the last two meetings. Not good. Some important decisions were made last week, so I consulted the chat logs and threw together https://make.wordpress.org/core/2014/11/03/dev-chat-summary-october-29th/.

  • 

    Ryan Boren 8:24 pm on November 3, 2014 Permalink | Log in to Reply

    Only one of the feature plugins in consideration for 4.1 is available in the plugin directory, Focus. The session manager plugin is available only via github. Once you track it down and install it, updates are not available through the admin and confusion ensues since the slug it uses is already taken by another plugin.

    https://make.wordpress.org/core/2014/10/30/nightly-builds-for-feature-plugins/

    /wp-admin/plugin-install.php?tab=beta needs an analog on .org. We need something linkable.

    Press This and other feature plugins need to show signs of life in the plugin dir even when they are slated for future releases. Focus is the only feature plugin regularly updated in the plugin directory.

  • 

    Weston Ruter 8:46 pm on November 3, 2014 Permalink | Log in to Reply

    Biggest thing I’m working on this week for the Customizer:

    #27355: Customizer: Add framework for partial preview refreshes

    This is a dependency for:

    #29988: Twenty Fifteen: Use JS/postMessage to update the color scheme instead of triggering a page refresh

  • 

    Boone Gorges 9:17 pm on November 3, 2014 Permalink | Log in to Reply

    #5809. Pull that trigger.

  • 

    Janneke 9:18 pm on November 3, 2014 Permalink | Log in to Reply

    Working on merging Focus (#29806) and inline image toolbar (#30147).

  • 

    Ryan Boren 10:36 pm on November 3, 2014 Permalink | Log in to Reply

    Thinking about feature plugin merge criteria. We’ve never reached the standard set by mp6. Feature plugins need to court testing audiences. Notions:

    Feature plugins must…

    • Be present and up-to-date in the plugin directory.
    • Be as ready to go on mobile as they are on desktop.
    • Have visual records for major flows through all new interfaces on all devices.
    • Have mature UI that isn’t going to derail the release train.
    • Have a history of posting weekly updates to make/core.
    • Have a history of regular plugin directory updates.
    • Have a testing audience.
    • Publish a merge consideration post on make/core complete with visual records and other diligence.

    Even better, feature plugins must…

    • Exist for at least one release cycle. Plugins created at the beginning of a release cycle should not be considered for merge until the next release.

    More radical: Release beta 1s as core changes plus a one click installable set of feature plugins. Plugins merge to core as they prove themselves in beta.

  • 

    Ryan Boren 10:46 pm on November 3, 2014 Permalink | Log in to Reply

    With Focus being a desktop feature and none of the make/flow bugs getting fixed, what mobile improvements do we have in 4.1?

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

    • 

      Janneke 12:47 am on November 4, 2014 Permalink | Log in to Reply

      Patched two of those. Not sure if they need a refresh. Bug fixes can go in after beta though, features/enhancements can’t, so focussing on those first.

  • 

    Nick Halsey 1:06 am on November 4, 2014 Permalink | Log in to Reply

    I’m also working on the Customizer. We have several tickets that are awaiting commit, and I can follow up if anything comes up with them.

    In addition to keeping an eye on the tickets Weston mentioned, my primary focus is #21483: Refactoring the Customizer’s media controls to leverage the media modal. There’s lots of awesomeness happening here in terms of both code and UI/UX, but it would all benefit from testing and feedback.

    @ryan Customizer mobile improvements were slated for 4.1, but have been punted because there wasn’t enough time to devote to it, and the initial approach ended up being more applicable to larger-screen users. We could use more contributors in this area. #28784

  • 

    Konstantin Obenland 9:55 pm on November 4, 2014 Permalink | Log in to Reply

    Trying to bring Themes API enhancement over the finish line that is Beta 1.
    Still todo:

    • #29890
    • https://core.trac.wordpress.org/attachment/ticket/29808/29808.9.diff
  • 

    Ian Stewart 11:17 pm on November 4, 2014 Permalink | Log in to Reply

    Ran a twentyfifteen chat today, closed a bunch of tickets. Notes to come!

  • 

    Stephane Daury (stephdau) 5:07 pm on November 5, 2014 Permalink | Log in to Reply

    Deep in plugins descriptions internationalization projct, towards localized plugin directories/api (used in core plugin search/listings).
    Learning GlotPress & bbpress (orig) dev, brushing up on BackPress.
    Mulling solutions to propose. Will actually be buying a new whiteboard for this.

  • 

    George Stephanis 5:24 pm on November 5, 2014 Permalink | Log in to Reply

    Had a chat with @johnjamesjacoby @obenland @rmccue regarding a cluster of semi-related tickets — #13239 #18302 and #22355

    https://wordpress.slack.com/archives/core/p1415145724003933

  • 

    John James Jacoby 5:38 pm on November 5, 2014 Permalink | Log in to Reply

    upload_is_file_too_big(). Just kidding.

    Continuing to kick #30145 around, and had healthy discussion about the future of #22355.

  • 

    chriscct7 6:43 pm on November 5, 2014 Permalink | Log in to Reply

    Curating a list of ex-43 (ancient ticket query on trac), tickets that are either ready to be committed or just need unit tests:

    Ready for merge:
    #18946
    #13071
    #12725
    #17413
    #17520
    #19739
    #19918
    #18084
    #15520
    #16876 (nacin probably wants to be committer on this)
    #19064

    Ready for merge after unit tests:
    #27048
    #17450 (related to #10249)
    #10249 (related to #17450)

    Possibly a couple more by the time dev chat hits today.

  • 

    Robert Chapin 6:25 pm on November 6, 2014 Permalink | Log in to Reply

    Trying to get 4.0.1 finished before 4.1.0!

• 

  Ryan Boren 7:36 pm on November 3, 2014 Permalink | Log in to leave a Comment
  Tags: dev chat summary ( 2 )   

  Dev Chat Summary, October 29th 

  https://wordpress.slack.com/archives/core/p1414613658002331

  Misses

  • Beta 1
  • Feature plugin merge window

  Decisions

  • Beta 1 will happen next Wednesday.
  • One of the betas will be dropped to offset the beta 1 delay.
  • Select 2 will be punted to 4.2 due to touch problems and upstream rewrite concerns.
  • There will be an accessibility bug scrub on Friday. https://make.wordpress.org/accessibility/2014/09/17/wordpress-accessibility-ticket-priorities-for-4-1-early/

  Assignments

  • @markjaquith and @avryl will make a patch to merge Focus.
  • @johnbillion will make a patch to merge Session Manager.

  Links Mentioned

  https://make.wordpress.org/core/version-4-1-project-schedule/

  https://make.wordpress.org/core/2014/10/28/wordcamp-san-fransisco-user-testing-results/

  https://github.com/johnbillion/wp-session-manager/pull/14

  https://core.trac.wordpress.org/ticket/22229

  https://core.trac.wordpress.org/ticket/25277

  https://github.com/ivaynberg/select2/issues/1541

  https://github.com/helenhousandi/wp-19867-9864/issues/11

  https://github.com/ivaynberg/select2/milestones

  https://github.com/helenhousandi/wp-19867-9864/

  https://make.wordpress.org/core/2014/10/28/twenty-fifteen-chat-summary-october-28/

  https://make.wordpress.org/accessibility/2014/09/17/wordpress-accessibility-ticket-priorities-for-4-1-early/

  https://make.wordpress.org/core/

  Focus 2

  mark
  I think Focus v2 is ready to be turned into a core patch and be merged in. Over the last few days we have been working on making it less “twitchy” and narrowing the circumstances under which focus mode is triggered, so we are sure the user is focused on composition when it happens, instead of transiently moving through the editor or absentmindedly clicking.

  Session Manager

  nacin
  I think the session manager is ready with some minor UI tweaks (simplifications, really) and use of the geo IP API.

  johnbillion
  Yes the session management UI is in a similar position

  johnbillion
  I’m hoping to get that in patch form and ready to merge before the weekend

  Select 2

  johnbillion
  @helen @ericlewis Do you have time to look into the touch problems before Friday? I am very tempted to punt this if we can’t get this merged by early next week, and highly visible touch support problems will prevent it being merged

  johnbillion
  I think we can circle back Friday during the bug scrub and make a decision

  helen
  i am having bad gut feelings myself.

  jorbin
  I think the work @helen and @ericlewis have done is great, but there are too many unknowns (edited)

  rzen
  I side with withholding it for just one release. The benefits of waiting (potentially better codebase, more room to test accessibility, etc) far outweigh the benefits of including now (almost certain rewrites in the very near future, for one)

  eric
  I’d say cut it. It’s a minor improvement, not a make-or-break feature.

  nacin
  And with so many other things about to come in, it’s pulling resources in different directions a bit.

  helen
  “just one release” – i’ve been tinkering with this since february.

  rzen
  Fair point, very fair point

  helen
  but i am not worried about cutting it for 4.1. it is frustrating, but not worrisome.

  johnbillion
  Ok unless the situation with touch support changes in the next few days, we should consider this punted. I have also just been informed that there is a licensing issue which I was unaware of

  Twenty Fifteen

  johnbillion
  Twenty Fifteen is steaming ahead

  johnbillion
  @obenland @lancewillett @iamtakashi Anything of particular note you’d like to mention?

  iandstewart
  It’s looking good

  iandstewart
  @celloexpressions just did a great review

  iandstewart
  and doubled our ticket numbers :simple_smile:

  celloexpressions
  Well, that was just as much as I could do in an hour :simple_smile: but it’s pretty good overall, no huge issues. I’m still thinking about the color schemes implementation

  iandstewart
  Not much to report on beyond the update here https://make.wordpress.org/core/2014/10/28/twenty-fifteen-chat-summary-october-28/
  Make WordPress Core
  Twenty Fifteen Chat Summary October 28
  Notes for our weekly chat about Twenty Fifteen: Twenty Fifteen continues to feel pretty robust — thanks to everyone who’s been testing the theme, reporting bugs, and contributing to patches with co…

  obenland
  We had some new template tags land yesterday, I started a ticket for the new `title-tag` support and will publish a post on that later today

  obenland
  Also working on adding support for the navigational template tags

  Plugin and Theme Install

  johnbillion
  Lastly from me, the proposed updates to the plugin and theme install and update process haven’t had much traction lately, as I’ve already noted, due to @nacin @melchoyce @pento @avryl being busy on other things, but we have mockups and that group are going to plow through it starting this afternoon

  johnbillion
  So that is still scheduled for 4.1

  Feature Plugins

  boren
  Feature plugins need to be in the beta list. Only one of those discussed here is listed, Focus. /wp-admin/plugin-install.php?tab=beta

  nacin
  @boren: Roger.

  boren
  Does that page have a .org analog?

  nacin
  Negative.

   
• 

  Ryan Boren 6:49 pm on October 30, 2014 Permalink | Log in to leave a Comment  

  Nightly Builds for Feature Plugins 

  Notion: All feature plugins should be present in the plugin repository, kept up-to-date, and kept free of testing blockers. Delivering in-development interfaces to beta testers via WP’s built-in update mechanism is good ecosystem dogfooding.

  With the Beta Tester plugin, I am able to update my sites to the latest nightly build of core WordPress automatically. Feature Plugins should endeavour to do the same. A script for deploying from git to the .org plugin repository exists and seems a good place to start.

  While the tooling is worked out, I’d like to commit to making weekly releases of feature plugins, at the least.

  Ryan Boren, jmdarts007, Gary Jones, and 5 others are discussing. Toggle Comments

   
  • 

    Samuel Wood (Otto) 7:00 pm on October 30, 2014 Permalink | Log in to Reply

    There is a Plugin Beta Tester too. Perhaps the main Beta Tester plugin should be updated to also download selected feature plugins in the same manner.

    • 

      Helen Hou-Sandi 7:03 pm on October 30, 2014 Permalink | Log in to Reply

      I think there is more of an issue of things being developed in other places (typically GitHub) but not regularly getting synced over to .org for more typical users to be able to install.

      • 

        Samuel Wood (Otto) 7:11 pm on October 30, 2014 Permalink | Log in to Reply

        That’s not really an issue. You can make a plugin do an update from anywhere. Including Github, if you really want. Github can build and send ZIP files, I’m pretty sure.

        We don’t typically allow plugins to enable external updates like that in the plugin directory, but for official projects and plugins slated for core, it would be perfectly fine to do that, in order to assist with development and testing. Exceptions to every rule and so forth.

        • 

          Helen Hou-Sandi 7:13 pm on October 30, 2014 Permalink | Log in to Reply

          I think that’s missing the point – those plugins still won’t be available in the Beta Testing tab for plugin install. I don’t really want to make update exceptions for them.

          • 

            Samuel Wood (Otto) 7:16 pm on October 30, 2014 Permalink

            Okay, so, if you don’t want them to update from Github (or wherever), then you sync them back to plugins.svn on a regular basis (like weekly) and use code like the Plugin Beta Tester (but put into the main BT plugin) to download them from there.

            This seems like a problem which is easily solvable with about 40-60 lines of code and some whitelisting, is what I’m saying. All that would need to be maintained is the list of “feature plugins” somewhere.

        • 

          WraithKenny 7:16 pm on October 30, 2014 Permalink | Log in to Reply

          If I understand your suggestion, a very skilled person will make a plugin that will update other plugins from github, rather then say testers trying to write code to pull updates from github, right? I’m all for some very skilled person handling that, as it’s not a novice or intermediate level task.

          • 

            Samuel Wood (Otto) 7:20 pm on October 30, 2014 Permalink

            Basically, yes, except it isn’t that difficult. I’m at an airport bar and getting on a plane in a couple hours, but I’ll try to write up an example this weekend for you. You just have to hook into the update process and replace the API response with your own update information with whatever you want. As long as you can give it a URL to a working ZIP file, the built in core updater code will happily do an update from any URL. It’s not fixated on the plugin directory.

            I’m thinking that the Beta Tester plugin currently allows people to download trunk versions of core. There’s no reason it can’t be expanded to also allow them to download the latest versions of the known feature plugins slated for that same release. Yes, the BT plugin would need to be updated to do that, and to know/get the feature plugins list. That’s not a big issue, really.

          • 

            Gary Jones 8:12 pm on October 30, 2014 Permalink

            Already done, and fairly stable: https://github.com/afragen/github-updater

  • 

    Joe Dolson 7:01 pm on October 30, 2014 Permalink | Log in to Reply

    +1 to that – locating feature plugins and knowing when they’re functional is one of the big barriers I find in doing testing.

  • 

    Michael Arestad 7:25 pm on October 30, 2014 Permalink | Log in to Reply

    I know we have a plugin we use for alpha testing that allows you to stay up to date with the latest version on Github. It’s really not recommended for production, but it sure makes it easy to try and keep up with the bleeding-edge latest changes.

  • 

    Ryan Boren 7:29 pm on October 30, 2014 Permalink | Log in to Reply

    Some background: The plugin installer has a “Beta Testing” tab that features Feature Plugins. At the moment, only one of the feature plugins being considered for 4.1 is in that tab.

    https://cloudup.com/c2Zcz11HX1a

    That page needs an analog on wordpress.org so that we have something linkable.

    • 

      Samuel Wood (Otto) 7:51 pm on October 30, 2014 Permalink | Log in to Reply

      We can update that. Is there an official list being kept anywhere that we can refer to?

      • 

        Ryan Boren 8:18 pm on October 30, 2014 Permalink | Log in to Reply

        https://make.wordpress.org/core/features-as-plugins/

  • 

    Ryan Boren 8:07 pm on October 30, 2014 Permalink | Log in to Reply

    Related core channel chat: https://wordpress.slack.com/archives/core/p1414695067002796

  • 

    jmdarts007 11:21 am on November 2, 2014 Permalink | Log in to Reply

    I think that’s missing the point – those plugins still won’t be available in the Beta Testing tab for plugin install. I don’t really want to make update exceptions for them.

  • 

    Ryan Boren 6:38 pm on November 3, 2014 Permalink | Log in to Reply

    https://github.com/benbalter/Github-to-WordPress-Plugin-Directory-Deployment-Script

    Sounds like the plan is to locate that script at wordpress/plugin-directory-github-sync where @helen and @markjaquith can add their changes.

  • 

    Ryan Boren 4:48 pm on November 13, 2014 Permalink | Log in to Reply

    Scripts mentioned:

    https://gist.github.com/helenhousandi/6638467
    https://gist.github.com/markjaquith/4084290
    https://github.com/benbalter/Github-to-WordPress-Plugin-Directory-Deployment-Script
    https://github.com/ocean90/svn2git-tools/tree/master/automated-wordpress-plugin-deployment
    https://github.com/GaryJones/wordpress-plugin-git-flow-svn-deploy