Week in Core, May 17th – 23th 2017

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

  • 56 commits
  • 75 contributors
  • 70 tickets created
  • 7 tickets reopened
  • 71 tickets closed

Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

Code Changes

Accessibility

Administration

  • Fix some HTML validation errors. [40823] #37004
  • Update the docs for wp_check_browser_version(). [40822] #40839
  • Dashboard: Change the cache key for dashboard RSS widget; remove the unnecessary database upgrade routine. [40803] #40702
  • Dashboard: Append the current locale to dashboard RSS widget cache key in wp_dashboard_rss_control(), for consistency with the changes to wp_dashboard_cached_rss_widget() in [33183] and [33192]. [40802] #32804, #40702
  • Dashboard: Don’t trigger an Events search when the search field is empty. [40799] #40816
  • Dashboard: Improve the Events widget spinner position after [40789]. [40794] #40735
  • Dashboard: Improve the handling of locations determined by geolocating the IP address and by entering a city name. Fix couple of edge cases, and some names. [40790] #40702
  • Dashboard: [40789] #40735
  • Dashboard: Combine methods to retreive IP [40781] #40702
  • Use consistent spacing for form elements in the Discussion Settings screen. [40779] #31594
  • Dashboard: Document request proxy for events. [40777] #40702
  • Dashboard: Properly localize data for events [40776] #40702
  • Dashboard: Always pass the IP when getting events [40774] #40702
  • Upgrade: Use correct commit no. to trigger upgrade [40773] #40702

Build/Test Tools

  • Remove mentions of HHVM from the test infrastructure on Travis for the 4.6 branch. [40818] #40548

Bundled Theme

  • Twenty Seventeen: Remove uneccessary return statement [40795] #40516

Customize

  • Docs: Improve phpdoc for WP_Customize_Manager, WP_Customize_Control, WP_Customize_Setting, and WP_Customize_Selective_Refresh. [40804] #39671
  • Docs: Add missing @since tags and phpdoc descriptions to the Custom_Image_Header class. [40788] #21785, #40231
  • Run a partial’s fallback behavior (full refresh) when selective refresh fails due to a script error. [40771] #27355, #40658

Help/About

I18N

  • Dashboard: Use get_user_locale() for the news feed cache key. [40793] #40417

Login and Registration

  • Add some margin to notices on the login screen so multiple notices remain separated. [40778] #39971

Media

Misc

  • Themes: Skip tests if ReflectionMethod::setAccessible is unavailable [40826] #
  • Post-4.8 Beta 2 bump. [40820] #
  • WordPress 4.8 Beta 2 ([40807] again) [40819] #
  • Revert [40807] unbumping from 4.8 Beta 2 back to Beta 1 due to aborted release. [40808] #
  • WordPress 4.8 Beta 2 [40807] #
  • Updates for 4.6. Merge of and to the 4.6 branch.

Quick/Bulk Edit

REST API

  • Fix changing parameters with set_param() for some requests. [40815] #40344
  • Avoid sending blank Last-Modified headers with authenticated requests. [40805] #40444
  • Do not set X-WP-Deprecated* headers as often. [40782] #40787

Themes

TinyMCE

  • Fix selecting the link node after creating a link by pasting an URL. [40801] #40818
  • Editor: When stripping paragraph tags, and there is a <br> at the beginning or the end, merge them and keep the paragraph, not the <br>. [40787] #37066
  • Fix pasting while an image with caption is selected. The image and the caption should be replaced with the pasted content. [40786] #40809
  • Provide styles for link and code boundaries. [40783] #40767

Users

  • Multisite: Handle both role change selections in site-users.php. [40780] #40113

Widgets

  • Further refine WP JS coding style in media widgets code. [40821] #32417
  • Remove core embedding support for WMV and WMA files since MediaElement.js has discontinued supporting them. [40813] #39994, #39995, #40819
  • Clarify some context information for translators. [40812] #32417, #39993, #39994, #39995
  • Remove unused JS variable to fix JSHint error introduced in [40640]. [40811] #39994
  • Introduce isHostedVideo method on VideoWidgetControl to allow plugins to extend for recognizing services beyond YouTube and Vimeo. [40810] #39994, #40808
  • Revert [40251] pending more accessible solution for showing default widget titles rather than using placeholders. [40806] #39909
  • Ensure title field for media widget will update with sanitized value after change event in addition to input event. [40785] #32417, #40805
  • Use “Add Audio” for button in Audio widget instead of generic “Add File”. [40784] #39995, #40797
  • Media: Trim whitespace in URLs provided for external embeds. [40772] #40771

Thanks to @4nickpick, @abhishekfdd, @adamsilverstein, @adamsoucie, @afercia, @arena, @arshidkv12, @azaozz, @BharatKambariya, @bradyvercher, @bridgetwillard, @coffee2code, @coreymckrill, @darshan02, @dd32, @desrosj, @emirpprime, @gma992, @iandunn, @iandunn, @iseulde, @Italian polyglots team, @iv3rson76, @jenblogs4u, @jeremyfelt, @jjcomack, @jnylen0, @joedolson, @joemcgill, @joen, @johnbillion, @juhise, @ketuchetan, @kraftbj, @leewillis77, @LiamMcArthur, @matveb, @melchoyce, @michalzuber, @michelleweber, @mihai2u, @MikeLittle, @mikeschroder, @mp518, @mrahmadawais, @netwe, @nitin, @kevadiya, @nobremarcos, @obenland, @ocean90, @odysseygate, @pento, @postpostmodern, @rellect, @rensw90, @rianrietveld, @riddhiehta02, @rmccue, @ryelle, @sagarjadhav, @sagarprajapati, @Samantha Miller., @sami.keijonen, @SergeyBiryukov, @sloisel, @sstoqnov, @stubgo, @swissspidy, @tejas5989, @timmydcrawford, @TimothyBlynJacobs, @topher1kenobe, @truongwp, @westonruter, and @zinigor for their contributions!

#week-in-core

Editor Experience Survey Results

The Editor Experience Survey results are in! There were a total of 2,563 responses which were gathered anonymously through PollDaddy. There was a big focus on asking multiple choice questions to keep the survey manageable. I tried to provide images where relevant and ask actionable questions as I could.

Thanks to: @iseulde, @karmatosed, @melchoyce, @joen, @designsimply, @azaozz, @chanthaboune, @samuelsidler, @codebykat and many more for helping me organize this survey.

Let’s jump in.

How do you use WordPress?

This question was pulled from the annual WordPress survey which helped reveal the backgrounds of the respondents. I was hoping for a more diverse group from a variety of backgrounds using WordPress, but this sampling should provide decent insight. Keep in mind that respondents were allowed to answer more than one.

Developers clearly dominated the survey. Because of this, I wanted to break this stat down a bit more. This chart displays each category outside of “Developer”. The blue represents the amount of respondents that selected that category, but did not select “Developer”. The red represents the amount of respondents that chose “Developer” plus that category.

The total respondents that selected “As a Developer” in this survey was 1,703 out of 2,563 total responses.

How often do you use the Editor?

This questions was written in an effort to make sure the results were from respondents that used the Editor. As can be seen, 89% use the Editor weekly or more.

Do you use the markup text Editor?

Is the Text Editor an important part of people’s workflow while using WordPress? It was interesting to see that over 85% of respondents use the Text Editor sometimes or more.

“Only one wish: please don’t remove the plain text/mark-up editor.”

 

“I’m a huge fan of the text editor. I like the ability to use raw html when necessary.”

 

“Would really appreciate syntax highlighting in text view.”

 

Do you use the markup buttons?

While a vast majority of respondents use the Text Editor, almost half never use the markup buttons.

Do you use the distraction free writing mode?

The distraction-free writing mode seems to be often overlooked or just ignored in the respondent’s flow when using the Editor. Could it be that the button to initiate the distraction-free writing mode is a distraction itself?

“I love the distraction-free writing option but wish it offered a wider column for editing purposes and easy size-adjusting for easier reading/editing.”

 

“I like distraction free mode when I remember it’s there. Would be cool if choosing to edit a post/page from the front end invoked something like distraction free mode as a modal overlaying the page, allowing for quick editing and committing.”

 

“[Would like] better Distraction Free (not just hiding surrounding menus, but expanding the actual text area)”

 

“I like the distraction free mode a lot. It makes it easier to write directly in the editor in a clutter-free way.”

 

“‘Distraction free’ is depressing due to the large gray area and limited writing space for desktop.”

 

“Distractions free mode is an utter joke.”

 

“Would like to see a full screen version. Distraction free just removes the menus, full screen would allow the menus on top and bottom but still give the complete screen width.”

 

“I wish the distraction free mode was how it used to be with bigger fonts and centered.”

 

Installing plugins that added features to the Editor

Exploring these questions might help reveal which features respondents are looking for in the Editor itself. The majority answered that they had installed plugins to add features. The most common features are graphed below.

Current Editor ease-of-use and organization

On a scale of 1 to 5 (5 being Very Easy or Very Organized), the majority of respondents found the current Editor’s ease-of-use and organization to be sufficient or better.

Editor Accessibility

105 respondents use a screen reader. 94 of those people feel the screen reader experience is sufficient or better. Other assistive technologies used by the respondents include: On-screen keyboards, alternative input devices like wands & sticks, voice recognition programs, screen enlargers, text to speech synthesizers, and braille embossers.

 

Some quotes from the survey question about accessibility issues with the Editor:

“You need to add more notifications for screen reader when somethings change on the page.”

 

“I reached and pressed the Publish button and forgot that there are meta boxes after that. So then I had to fill up the category and tags then shift + tab to go back to Update the post.”

Is there anything in the Editor you never use?

I was hoping to discern some of the less used items in the Editor. This question is not intended to provide for support for eliminating any elements within the Editor, but rather to help with visual hierarchy in the new Editor. By far, the main element never used was the “Text color” dropdown, followed closely by the “Special character” button, the “Insert Read More tag” button, and the “Distraction-free writing mode” button.

Is there anything else about the Editor you’d like to share?

The last question yielded 37 answers. I’ve pulled a few interesting ones below.

 

“Please make the editor to seems as an a4 paper it is best for authors :)”

 

“Add a no follow option in the link editor.”

 

“I’d like to see the bullet points/numbers to go along with the text if I increased or decreased indentation.”

 

“Would be way better if you could edit directly on the site instead of having to open the dashboard and find the content somewhere there.”

 

“Better implementation of shortcodes would be a real benefit.”

 

“I would like that to see an easier way to bring the cite tag to the editor to use with blockquote.”

 

“Wish there was better support for content columns.”

 

“I would love much better WordPress support for writing in various apps and then posting to WordPress. […] In particular I’d like to see it in a lot more text editors / note taking apps, […]. Writing in a web page in a browser is never going to be comfortable, or at least never as comfortable as a “native” experience, so I recommend focusing on letting people use the native experiences with which they’re most comfortable.”

 

Conclusion

The Editor Team is working hard on redesigning the Core Editor experience to be something WordPress users could enjoy using daily. If you feel anything important was not represented in this survey, please comment below. If you have any feedback regarding the results or future work on the Editor, please feel free to comment as well. I look forward to the improved Editor experience in Core!

 

 

 

#core-editor, #survey

Dev Chat Summary: March 1st (4.7.3 week 5)

This post summarizes the dev chat meeting from March 1st (agendaSlack archive).

4.7.3 Schedule

  • Reminder of plan to release 4.7.3 as bugfix and maintenance release on Monday March 6, 2017
  • RC is available so please test

Community Summit

  • Working to review submissions on Planning for Community Summit 2017 post on Make/Core as well as submissions to the Make/Summit team via the Community Summit 2017: Sign-up Request post
  • Between now and Friday, March 5th the Core team needs to come up with:
    • 1) a list of topics for the summit
    • 2) A list of representatives to attend the Community Summit
    • 3) One or two contributors who are willing to help with the organization of the event
  • “participating” generally means being physically present for the discussions in Paris, France days prior to WCEU this summer for the Community Summit
  • Each topic facilitator will do both a pre-summit and post-summit Make/Core post. @jbpaul17 to confirm timelines with @_dorsvenabili to help prep those facilitators for those post timings.
  • Javascript in core [will submit to CS]
    • “what we hope and imagine for the future with the REST API, and how we hope to get there… what we have in core now and how we can improve it and how we can attract more JavaScript first developers to build on WordPress and especially contribute to core… How the REST API relates to wp-admin.” Submitted by @adamsilverstein to attend and volunteer to help in whatever role is most helpful.
    • “REST API admin usage: Where we can start moving things to using the API (and maybe even get a couple of them done at the summit)” Related submission from @chriscct7, recommended to include @rmccue
    • @kadamwhite: A heavy dependency on “the future of JS in core” and that discussion should originate from the broader WP community, not be mandated by the REST API group
  • Technology version support policies [will submit to CS]
    • @jorbin: (versions of PHP, MySQL, Browsers, Screen Readers, other AT, etc.) Let’s come up with some concrete plans for when we intend to deprecate things and how we want to handle it. People Who would be good to have in this discussion: @dd32 (to help with stats) @pento (to help with messaging) @afercia and @rianrietveld ( to help formulate AT support policies if they don’t exist already), @westonruter ( as maintainer of the largest JS component) @azaozz ( as maintainer of tinyMCE component) @matveb ( as dev lead of new editor)
    • @getsource, @boonebgorges, and @matt as additional reps for this topic
  • Improved management of contributors with time to spare [will submit to CS]
    • @johnbillion: This topic is particularly focused on pre-existing contributors who are paid to contribute to WordPress (eg. those whose time is sponsored by their employers), but also pre-existing contributors who aren’t sponsored but who do want to contribute a significant and/or consistent amount of time, and also potential contributors in a similar position.
      As a project, we need to manage these people’s time much better. These people need to be project managed in one way or another to avoid repeats of situations we’ve had in the past where a contributor is literally being paid to fix things in WordPress and the project is failing to enable them to do so effectively, or even at all. I’d (@johnbillion) like to attend the summit, and I’d be happy to jointly lead this discussion with someone who has good project management experience and some ideas about how WordPress might be able to better manage contributors, but at the same time do it in such a way that retains the fun and interesting aspects of contributing without turning it into something that too closely resembles “work”. [Side note from John: Worth noting that this doesn’t only apply to core, but it’s a good place to start.]
    • @helen did a survey of time availability a while ago, sent list to John to use for this topic
    • @aaroncampbell, @getsource, @jorbin, @boonebgorges, and @logankipp as additional reps for this topic
  • On-boarding experience for new contributors [will submit to CS]
    • @joemcgill: Lots of people who want to get involved have no idea where to focus their efforts.
    • @kadamwhite: Speaking for myself this is hugely related to the future of JS in core and the REST API, since those pieces really need the energy new contribs would bring
    • @getsource: I am willing to participate or lead, although I don’t know what leading it means besides guiding conversation at this point. @aaroncampbell also willing to lead.
    • @peterwilsoncc, @flixos90, @logankipp, @jorbin, @johnbillion, and @stevenkword as additional reps for this topic
  • Communicating changes to WordPress Core [will NOT submit to CS]
    • @jorbin: For the past few years, core has produced a field guide and worked with the meta and plugins team to email plugin others about changes to core. Each release though triggers a number of people who don’t know about changes until after the release. Challenge: How can we help ensure changes that aren’t worthy of user marketing promotion are known by a far greater percentage of WordPress developers?
      Might also impact or benefit from input from +make.wordpress.org/plugins +make.wordpress.org/themes +make.wordpress.org/marketing +make.wordpress.org/meta.
      Even when we get the field guide out on time, issues come up post release.
      two ideas:
      1) Translating the field guide (is this reasonable if the posts that it links to aren’t translated?) Also means polyglots should be in the discussion
      2) Using the new release email mailing list to announce RC
    • @helen: I think it’s worth at least starting the conversation earlier, even if it ends up still being valuable to continue something in person.
    • @desrosj: There may also be some great ideas from people who cannot attend in person. It would be a great opportunity for them to have their ideas heard and contribute, even if they are not able to follow through with the discussion in person at the summit.
    • @jorbinI’m going to withdraw the communication topic as my proposal for the summit with the note that I might want to resubmit it depending on how the virtual discussion goes
    • @azaozz and @sergey as additional reps for this topic
  • Security [will submit to CS]
    • @chriscct7: The process of a security ticket from report through triage through disclosure. Aaron Campbell (security czar) has made it clear this needs to be discussed at some point and I feel like the community summit would provide a good venue as many of those on the team will be there in person and we can mirror the conversation easily for those who are not. Recommend including @aaroncampbell
    • @aaroncampbell: This is actually a good idea, although I don’t think it’s because “those on the team will be there” but rather because I’d love to get input from some other people too, and security is generally sensitive enough that a place like the summit seems useful
    • @rmccue, @kadamwhite, @matveb, @joen, @westonruter, @melchoyce as additional reps for this topic
  • Collection of Anonymous data [will NOT submit to CS]
    • @chriscct7: If core is interested in doing it, I think my experience with doing it for a trac ticket (settings reduction) might prove to be useful to add to the discussion. Recommend including @drewapicture
    • General agreement to NOT include this topic since this is currently opt-in and the issue is finding an owner of this topic
  • Bootstrap/Load [will NOT submit to CS]
    • @schlessera: Opening up the WordPress Core Architecture to make it flexible enough as a platform so that it can:  * serve both novice end-users as well as large-scale enterprise installations in an optimized way;  * quickly adapt to changing external requirements, to keep up with the accelerating pace of the web. Recommend including @rmccue
    • General agreement to NOT include this topic since it does not need to happen in-person, already has discussions underway, and should be scheduled in next couple of weeks
  • Code editor [will NOT submit to CS]
    • @georgestephanis: Code Syntax Highlighting implementation and accessibility concerns — how we can get CodeMirror or whatever better library there is implemented and rolled out for both Customizer Custom CSS, Theme/Plugin Editor, and Content Blocks. Recommend including @afercia @westonruter
    • General agreement to NOT include this topic since it does not need to happen in-person and should happen sooner than the CS.
  • REST API authentication [will NOT submit to CS]
    • @georgestephanis: Third-party authentication with the REST API.    Between OAuth 1.0a, OAuth2, central application brokers, Application Passwords, or some other system — there’s a lot of possibilities here, and it’d be really nice if Core could pick something and move forward with it before folks start spoofing cookie authentication in applications to integrate with core.
    • Relevant chat summary from the last time we had one
    • This really needs an owner, otherwise it’ll continue to be punted. There’s fundamental differences on what the direction should be.
    • @samuelsidler: I don’t think core can decide until someone has documented the possible options, along with their strengths and weaknesses, then had some discussions on what would be best for core and why.
    • @georgestephanis, @rmccue, @logankipp volunteered post on Make/Core to move this topic along
    • We will table this idea and maybe propose it for the summit based upon how the near term discussions go
  • Front-end Editing [will NOT submit to CS]
    • @westonruter: Frontend editing powered by bootstrapping the customizer onto the frontend, with inline direct manipulation of elements on the page and the controls sidebar being lazy loaded to slide in from the left as needed. Editable elements include post content and site configuration (sidebars, menus, options, etc). Recommend including @celloexpressions
    • General agreement to NOT include this topic since it depends on too many other things we won’t know by then, so we will pass on that topic (at least for now).
  • Nextgen Widgets [will NOT submit to CS]
    • @westonruter: Next generation of widgets which harmonize with content blocks in the editor.
    • General agreement to NOT include this topic for the CS, but good conversation for the contributor day.
  • Feedback on Core focuses [will NOT submit to CS]
    • @georgestephanis: Six months in, how are we feeling about shifting away to a more top-directed set of focuses for the year?
    • General agreement to NOT include this topic as it’ll be hard to say until/unless we’ve shipped a core release by then (we likely won’t) and is a conversation that should happen in public.
  • Complete list of representatives nominated to attend the Community Summit: @matt, @nacin, @adamsilverstein@rmccue@kadamwhite@chriscct7, @dd32@pento@afercia@rianrietveld@westonruter@azaozz@matveb, @getsource, @boonebgorges@aaroncampbell, @jorbin, @logankipp, @peterwilsoncc, @flixos90, @johnbillion, @stevenkword, @azaozz, @sergey, @karmatosed, @joen, @westonruter, @melchoyce, @jnylen0, @ipstenu, @joemcgill, @joehoyle, @rachelbaker, @michael-arestad, @petya, @danielbachhuber, @ocean90, @samuelsidler, @afercia@desrosj, @iseulde, @jjj@celloexpressions
  • We’re still searching for 1-2 contributors who are willing to help with event organization, so please comment here or reach out to @jbpaul17 if you’re interested
  • @jbpaul17 will send the Core team responses to the Community Summit team by Friday, March 3rd.

Browser support

  • Please take a look at @desrosj’s post: The New Editor and Browser Support
  • This will be a topic of discussion at next week’s devchat.
  • Please leave your thoughts there as comments, and bring them along next week as well.

#4-7, #4-7-3, #community-summit, #core, #core-customize, #core-editor, #core-restapi, #dev-chat, #summary

Dev Chat Summary: February 15th (4.7.3 week 3)

This post summarizes the dev chat meeting from February 15th (agendaSlack archive).

4.7.3 Schedule

  • Completed first pass on all tickets in the 4.7.3 milestone, @jnylen0 is reviewing those that “need” to land in 4.7.3, and identifying a release date for 4.7.3 in the coming week

Customizer team update

  • #23601 (Use ACE Code Editor for Theme and Plugin editors) and #12423 (Include Ace (or similar) as default code editor)
    • Topic of discussion is a code editor library to be used in Custom CSS, WP content editor HTML view, file editor, and any other place that code is modified
    • Had planned to go ahead with CodeMirror since it is what Jetpack uses in its Custom CSS module, but @afercia pointed out accessibility problems
    • So we’re looking for insights into best of breed accessible code editor libraries
    • @afercia: looking to to understand if (1.) there’s consensus about introducing some sort of syntax highlighter library (plus other functionalities) and (2.) if it is going to completely replace the current WP content editor HTML view
    • @jorbin: Once one is decided upon, would like to encourage reaching out to the project maintainers and opening a dialogue about things like security and backwards compatibility
    • @helen: each area (Custom CSS, WP content editor HTML view, file editor) needs individual consideration and rationale
    • Goal is to provide a better user experience for when users edit code in WP
    • Custom CSS:
      • #38707: Customizer: Additional CSS highlight, revisions, selection, per-page, pop-out
      • @westonruter this is what #core-customize is most interested in, but picking a code editor library should be done ensuring that it doesn’t cause headaches if code editors are implemented for HTML view and file editor. i.e. the same library should be used throughout core.
    • WP content editor HTML view:
      • @joemcgill: the text editor now is not technically an HTML view, but is a plain text editor that is parsed into HTML. For instance, breaks are turned into `<p>` tags, shortcodes can be typed, etc., so a “code editor” is something slightly different.
      • @helen: per @iseulde and lots of discussions over time, is a little more complicated in that it’s not an actual HTML editor, so is getting rid of wpautop() is a requirement
      • @mike: I’d love to see code highlighting in the HTML view.
      • @afercia: If both the visual editor and the text editor are going to be replaced by Gutenberg and some sort of CodeMirror-like, well the level of accessibility for both is still uncertain and there’s the danger to introduce an accessibility barrier for the main scope of WordPress: entering content.
    • File editor:
      • @jorbin: I seem to remember that having been replaced with something fancier than what is in place now, but that having been ripped out
      • @helen: File editors really raise the question of whether users should be made more comfortable in them vs. being encouraged to use something else.
      • @brechtryckaert: security-wise I’m not a fan of the ability to edit files from the backend, people who are comfortable enough to edit code usually have a prefered editor
    • @jorbin: We already have our agreed upon accessibility coding standards that state:
      • All new or updated code released in WordPress must conform with the WCAG 2.0 guidelines at level AA

    •  @westonruter: if CodeMirror fails this test, as it seems to, then we need input on GPL-compatible code editors that are accessible.
    • @afercia: I propose to discuss this at the next accessibility meeting on Monday, invite people to do research, and possibly involve the testers group.
  • #38900 (Customize: Add REST API endpoints for changesets) and #39634 (Customize: Add REST API endpoints for panels, sections, controls, settings, and partials)
    • Thanks to @kadamwhite we have an initial (empty) feature plugin repo for the REST API endpoints for customization
    • Feel free to watch that repo and be apprised of developments
    • Next steps are to design the endpoints, write the failing tests for them, and then  go about writing the endpoint controllers
    • @kadamwhite: this is the first major effort within other areas of core that are turning up inconsistencies like #39805 (Expose featured_media property on post resources in “embed” context) so I’m excited to see what other improvements we can make as this work continues

Editor team update

  • Working full steam on prototypes, notably the Gutenberg UI prototype
  • The related GitHub repo has quickly become wonderfully active
  • Looking to discuss browser support for the new editor
    • @georgestephanis: So long as it can fall back to something that doesn’t utterly die, it should probably be fine.
    • WP Admin currently supports IE 8
    • Current browser market share
    • @jorbin: I would love to see us not drop support for anyone if possible
    • @joemcgill: Alternately, if we’re going to bump the browser requirements at any point, now is probably the time.
    • @joen: flexbox was mentioned as being nice to use in context of editor UI
    • flexbox support
  • The agenda for the Editor chat today was to discuss how using the UI prototype felt in the past week, and deciding where to take it next
  • We are looking for people to use and provide feedback the prototype, so please take a look if you can!

REST API team update

  • The REST API team has no significant updates since last week.

#4-7, #4-7-3, #core-editor, #core-restapi, #dev-chat, #summary

Customization Meeting Notes: January 23, 2017

From today’s #core-customize meeting:

Thanks @iandstewart for help with notes. Drop by #core-customize next week on Monday at 1:00pm EST for the next full meeting, or join us at the same time tomorrow for ticket triaging.

Editor Technical Overview

As we start looking at the editor from a technical perspective it’s important we identify the main obstacles and requirements we face before we start conjecturing solutions. As @matt wrote before, the editor focus aims to make writing rich posts effortless. This has taken the path of treating a post as being composed of distinct pieces of content called blocks. These pieces should be easy to insert and manipulate, providing rich and contextual interfaces to interact with as you craft a post.

So how do we go about turning this into a reality? Content in WordPress is, fundamentally, HTML-augmented text; that is to say, it has no inherent data structure. This has been a very important aspect of WordPress and a force for the open web—it speaks to the sense of ownership and freedom WordPress gives you, since it’s always easy to get the full content of your publications—yet the lack of structure gets in the way of the goal to treat content as composed from individual pieces. (This reality also became an issue for the development of post formats a few years ago, but I digress.)

It’s relatively easy to add structure, but it’s not trivial to do so in a way that doesn’t harm data integrity, portability, and the cohesiveness of the post_content. So let’s lay out a first requirement:

① Shape of the Data: Portable Text

To ensure we keep a key component of WordPress’ strength intact, the source of truth for the content should remain in post_content, where the bulk of the post data needs to be present in a way that is accessible and portable, while still providing additional structure on top of HTML semantics for our editing tools. Data needs to be praised and respected. This additional structure would hopefully be invisible to the document’s display context, as it ensures the rendered content is viewable in situations that may not be aware of blocks at all. (Think of email clients, RSS, older editor versions, mobile editors, database dumps, etc.)

Storing things separately means post_content becomes either a pointer or duplicated data, which fragments the source of truth since they can get out of sync easily. (A few content block plugins do this by storing structured data in postmeta and pure data in post_content.) On the other hand, storing things together means structure can become gibberish if it’s not formatted properly before display.

How can we then offer users a great experience when creating or manipulating content without sacrificing the spirit of integrity and data reliability that is expected from WordPress? Good representations of the data would also make it easier to develop robust collaboration tools in the future by allowing us to lock things in a more fine grained way. I believe this is important to figure out soon to allow us to prototype quickly, so I’ll follow up with an initial proposal by the end.

Honouring HTML leads to a second requirement:

② Simplicity and Semantics of Representation

Unless we are improving the semantics of the document we should minimize what markup we add to identify a block; for example, avoid adding extra DOM elements or attributes, both for simplicity and standards sake. WordPress has been a champion of web standards, and we should not venture away from this quality. How can we add structure in a way that remains invisible to the output (as meaningful content as possible) but gives the necessary hooks to infer a structured view for editing purposes?

While we discuss how to structure the content to include invisible demarcation of blocks, the aspect of their nature leads to a third requirement:

③ Static & Dynamic Blocks

Blocks can be either static or dynamic. That is to say, some blocks can be stored with all the necessary aspects needed for their display, while others need to be processed before generating their final output (shortcodes, embeds, widgets, etc). This distinction is important because the most common two blocks people will naturally use are text and images. We should not break their clarity as we treat them as blocks.


 # Static
Here’s some text.

# Dynamic
[text id=123] // Pulls "Here's some text" from somewhere.

This conceptual separation of blocks is useful for designing our project, yet they generate abstract complexity which users should not be exposed to, leading to a fourth requirement:

④ Consistent Experience

One of the biggest benefits of blocks is that composing a post becomes more intuitive and reliable. Everything is inserted under the same assumptions; discovering what can be inserted is a natural part of inserting content. To the user all blocks behave in a consistent and familiar way, even if they provide tailored UIs for their controls.

The user should also be able to edit a post in a different system (mobile, REST, older version of core, apps like Mars Edit, etc), even if they lose the advantages of block editing. That’s another reason why post_content as source of truth matters, compared to storing a JSON structure in postmeta. Having things in two places means they can get out of sync depending on what tool you used to edit.

These nuances of data, UI, and display lead to a final and more general requirement, which is understanding the system we’ll be crafting:

⑤ The System

The editor experience has three fundamental aspects to its system: the UI used to manipulate a block; the demarcation of the block; the rendered output of the block. These are all separate concerns, from the tools we craft to edit a post, to the document syntax that holds the data structure, to the way the final output is generated to be displayed as HTML. (With static blocks that last aspect may be of no significant concern since the document doesn’t care about the presence of static blocks, it just displays them.)

Picturing these concerns as connected but fundamentally separate would help us figure out the best design and technical solutions for each stage, while avoiding us taking aggressive moves by coupling expectations. For instance, JavaScript is a natural technology to look at when it comes to the ability to manipulate and interact with content blocks, yet it may not be the best at all when it comes to rendering the final post to a viewer. Avoiding painting the whole flow under the same light should allow us to focus efforts, because we don’t have to change everything.

❶ Coda

As a final coda, and following @joen‘s design exploration, let’s keep in mind that our first goal should be to set up a reliable foundation to allow us to iterate quickly and test assumptions. I propose we focus initially on a few static blocks (text, image with and without caption, quote) to limit scope of the project.

In which ways can we fulfil ① and ② from the above requirements?

Shortcodes fall short in that they are not invisible, they are opaque, not standing to the scrutiny of semantics, and are also painful to parse. Alternatives could be data-* attributes in the HTML elements or custom elements (paving the way for web components, perhaps), yet we need to be careful with adding cruft.

One other possibility is to look at HTML comments as a way to provide explicit demarcation to post_content without affecting the node structure of the document for something that is inherently spurious to the HTML semantics. WordPress already uses comments for the more tag (<!--more-->) and splitting content into pages in a way that has proven to be quite robust.

It could look something like this:

<!-- wp:image -->
<figure>
  <img src="/">
  <figcaption>A picture is worth a thousand words</figcaption>
</figure>
<!-- /wp -->

There are drawbacks, benefits, and implications with each that we should discuss separately. Are there any other possible solutions?

Please, join us in #core-editor if you are interested. We’re holding weekly meetings in Slack, Wednesdays at 19:00 CET.

#editor

Editor wish list for 4.5

#4-5, #editor

Editor Chat Tomorrow

Tomorrow we have our weekly editor chat (9 June 2015 21:00 UTC) in the #core-editor Slack channel. Here are some points we want to discuss. If any of these are of particular interest to you, be sure to attend. 🙂

  • Last week we added the text pattern plugin, please test! Are there any other patterns we should add? High on the list are for a block quote, #{1,6}  for headings and --- for a horizontal rule. #31441
  • What should happen to word count? Do we (re)move it? When and how should it be refreshed? Currently it only refreshes on enter and backspace, which is not ideal. In any case we also need to fix the counter itself (ignore more unicode ranges, shortcodes…) and this makes the counter slower. #30966
  • Inline linking. We’ve been talking about this for a while. There are some interesting mock ups from @joen, we should iterate on them and code it. Link text may go away. Should we keep “Open link in a new window/tab” in core? If you want to know more about the way it will work or help out, join us. 🙂 If there is consensus it may still make 4.3.
  • Another thing that should be coded asap is the caption placeholder. #32175

If there’s anything else you’d like to bring up that’s editor related, don’t hesitate to do so.

#editor

Editor wish list for 4.3

This is a list with improvement we’ve been planning for 4.3 and beyond. It’s open for suggestions and discussion, and it will continuously be updated.

  • Improve the editor on mobile. – #29923
    • Contextual floating toolbar.
    • Fix touch and focus issues. – #31247
    • Improve the spacing around the editor?
    • Combine “Add Media” with any buttons added by plugins. – #29989
  • Save and update without a page reload. For this we will need to look into nonce refreshing. – #7756
  • cmd/ctrl+S should work in the text editor and when the visual editor is not focussed. – #31655
  • Fix word count. – #30966
  • Bullet list shortcut. – #31441
  • Drag and drop linked images, captioned images and views. – #28272, #28003, #28826
  • Caption placeholder. – #32175
  • Add tests for our TinyMCE plugins. – #31596
  • Remove old Distraction Free Writing? – #30949
  • Improve editor scrolling.
  • Better default editor styles. – #31253, #32176
  • Inline link form. – Mock ups from @joen. One step done.
  • Leaving dialog. – #28566

Some things we started looking at for future releases:

  • Better structure for meta boxes. (needs tickets, mock ups)

Anything you’d like to see in this release or would like to work on? Please leave a comment.

#4-3, #editor

WordPress Core Weekly

Howdy! Sorry, I dropped the ball last week so this week’s Weekly Roundup is a double issue — it covers April 4, 2015 [32003] to April 18, 2015 [32140].

This week marks the release of RC1, which is the first release that many plugin authors and beta testers will test heavily. If you don’t already, now is a good time to check out the Alpha/Beta forums for any issues that crop up during this testing cycle.

We’re only days away from the release of 4.2; let’s finish strong! 🏃👏 Here’s the rundown of recent changes:

TinyMCE

  • Update to 4.1.9+. Changes:
    • Fixed bug where extra empty paragraphs would get deleted in WebKit/Blink due to recent Quriks fix.
    • Fixed bug where the editor wouldn’t work properly on IE 12 due to some required browser sniffing.
    • Fixed bug where formatting shortcut keys where interfering with Mac OS X screenshot keys. [32058] #31895
  • Disable the wp-autoresize plugin in iOS. All iframes there are already expanded to the height of the content document. [32095] #31937
  • Update the “Keyboard Shortcuts” modal. [32060] #29558
  • Fix our shortcuts on Mac, use Ctrl + Opt + letter. [32059] #29558
  • Use window.twemoji directly in the wpemoji plugin. Gives a chance to the browser to lazy load twemoji.js when reloading the page. [32142] #31901
  • Remove the empty paragraph that sometimes is left over after adding an image caption. [32141] #32003

wpView

  • Remove selected views when inserting content but not when loading all content, and remove the ref. to the selected view node on resetting the views. [32140] #31998
  • Resize sandbox iframes on load. [32056] #31480
  • Empty the content in the timeout, so it doesn’t render iframes twice. [32022] #31669

Build/Test Tools

  • During PHPUnit tests, don’t autodetect permalink structure during WP installation. [32139] #31994
  • Move the built media JS files up a directory to their previous location and naming convention. [32125] #31912 (see [31373])
  • Don’t reference underscore.js source map. [32065] #31477

General/Misc.

  • WordPress 4.2-RC1 [32137] [32138]
  • Use HTTPS URLs for codex.wordpress.org. [32116] #27115
  • Explain all placeholders in translator comment, not just the first one. [32111] #31675
  • Ensure post title input is not shortened for non-public post types. [32071] #30968
  • Improve handling of incomplete From and Content-Type headers in wp_mail(). [32070] #30266
  • wpLink: always show the URL field at the top. [32017] #28206
  • Force default avatar for HiDPI avatars on Discussion Settings. [32129] #31972

Translation and Strings

  • Merge strings that describe the same command. [32078] #31776
  • Update placeholder for FTP credentials. [32077] #31922
  • After [31941], use the decoupled strings from wp-admin/network/themes.php in wp-admin/network/site-themes.php as well. [32029] #28502
  • Correct grammar when referring to “a user” vs “an user” in several places. [32025] #31894

Administration

  • Fix flickering of the admin menu on over-scrolling. [32089] #30900
  • Dashboard: Ensure images other than avatars (such as emoji replacements) in recent comments are not incorrectly positioned. [32076] #31919
  • Admin menu: fix colors for focus state and in IE8. [32075] #31345
  • Dismissible notices: more precise positioning across browsers. [32068] #31233
  • Reset padding for buttons in theme details modal. [32128] #31963
  • Revert [32099] per discussion in #core. [32100] #30900
  • Remove z-index from #adminmenuback. [32099] #30900
  • Don’t print the custom-background class in body_class() when a default color is in use. [32081] #28687
  • Toolbar: Search item consistency for focus state and IE8. [32074] #31322
  • Pointers: Make the dismiss icon a consistent size. [32069] #31915
  • Update more instances of default admin blues and grays. [32051] #31234

Emoji and Smilies

  • Tweak which smiley matches which emoji. [32105] [32107] #31709
  • Update our few remaining smilies to better align with Twemoji, and add frownie.png until Twemoji provides a build containing it. [32104] #31709
  • The emoji JS files should be run through the script_loader_src filter, as they would be if they were registered scripts. [32097] #31938
  • Tidy up the wp_encode_emoji() regex, and clarify the function comment on Unicode 8 support. [32096]
  • Remove an errant / in Twemoji URLs. [32024] #31893
  • Remove executable bit from smilies. [32109] #31709

Themes

  • Twenty Fourteen: update editor styles to better account for adaptive images in small screens. [32094] #31934
  • Twenty Fifteen: update editor styles to better account for adaptive images in small screens. [32090] #31934
  • Theme Compat: Make string translatable and add translator comments. Added in [31941]. [32084] #28502, #31921
  • Move initialization of $customizeSidebar to api.ThemesSection.initialize() to prevent cases where the result can be undefined. [32119] #31793
  • Translator comment should just reference placeholder numbers, not the actual placeholders. [32112] #31675
  • Tell developers how to correctly silence register_sidebar() notices. [32110] #31675

Customizer

Theme Switcher

  • Fix some esoteric breakage in iOS Safari. [32103] #31794
  • Don’t deactivate section on empty search results. [32083] #31889
  • Remove “Add New” reference from customize-controls.js. [32004] #31837
  • Use text input for the search field to prevent double tap issues for Preview and Customize buttons on iOS. [32127] #31794
  • Don’t re-render a theme control if it has already been rendered.
  • Lazy load theme screenshots. [32088] #31793
  • Fix tabbing order if section is open. [32087] #31289
  • Fix preview URL for subfolder installs. [32086] #31896

Shiny Updates

  • Disable shiny updates from modal based on parent window [32082] #31739
  • Fix logic for details based shiny updates. [32080] #31739
  • Disable modal initiated shiny updates on wp-admin/update-core.php. [32067] #31739
  • Use dashes instead of dots as separator for jQuery events in shiny updates . is used for namespaces, so better to use dashes. [32063] #31819
  • Trigger events upon the completion of a shiny update. [32061] #31819
  • Remove Shiny Bulk Updates. Bulk updates don’t need to be ajaxified so let’s revert. [32053] #31770, #29820
  • Conditionally add AYS to leaving shiny updates. [32052] #31769
  • Enable users to initiate a shiny update from plugin detail modal. [32062] #31739

Media

  • Don’t allow whitespace-only image captions from the Media modal. [32079] #21848
  • Fix focus and selected state for the selected attachments set. [32072] #31898
  • Rename get_media_embedded_in_content_allowed filter tomedia_embedded_in_content_allowed_types. [32113] #26675
  • Bring back spinners, now without bouncing select elements. [32101] #22839, #30725
  • Fix the media modal Insert into post button on narrow screens by limiting the width of .media-toolbar-primary and .media-toolbar-secondary only inside .attachments-browser (the top toolbar). [32121] #31908
  • Insert from URL: Make sure the link text is actually used. [32055] #29476
  • Make sure the spinner in the media modal is visible on narrow screens (without affecting the media grid). [32120] #30725

Build Tools

  • Don’t override minified libraries included in core. [32066] #31477

Docs

  • Remove unnecessary inline @see tags from a variety of parameter and return descriptions in wp-includes/wp-db.php. [32050] #31888
  • Remove unnecessary inline @see tags from the wpdb::process_field_charsets()DocBlock. [32049] #31888
  • Add a missing return description for has_header_image(). [32048] #31888
  • Fix a variety of inline documentation syntactical issues in wp-includes/taxonomy.php. [32047] #31888
  • Add a missing @access tag to the DocBlock for the WP_Meta_Query->$clauses property. Also adds a missing return description for WP_Meta_Query::get_clauses(). [32044] #31888
  • Add a variety of missing descriptions and fix syntax for wp_scripts(),_wp_scripts_maybe_doing_it_wrong(), and wp_script_add_data(). [32040] #31888
  • Remove an unnecessary inline @see tag and document the $wpdb global in two WP_Comment_Query methods. [32038] #31888
  • Add missing parameter and return descriptions to WP_Customize_Widgets->filter_customize_dynamic_setting_args(). [32036] #31888
  • Add parameter and return descriptions for WP_Customize_Widgets->get_setting_type(). [32035] #31888
  • Add missing @access tags to two DocBlocks in WP_Customize_Setting. [32034] #31888
  • Document the $theme property in WP_Customize_Themes_Section. Also adds a missing@access tag to the DocBlock for WP_Customize_Themes_Section->render(). [32033] #31888
  • Cleanup DocBlock syntax, add a missing parameter description for WP_Customize_Manager->set_post_value(). [32031] #31888
  • Add inline doc syntax fixes for WP_Customize_Manager->doing_ajax(). Also adds a return description. [32030] #31888
  • Add documentation for the $type and $theme properties in WP_Customize_Theme_Control. Also add some missing @access tags to various DocBlocks. [32028] #31888
  • Fix description alignment for the category_css_class filter docs. [32026] #31888
  • Add documentation for the $type, $mime_type, and $button_labels properties in WP_Customize_Media_Control. [32023] #31888
  • Clarify the DocBlock summary and parameter description forwp_edit_attachments_query_vars(). [32019] #31888
  • Add proper descriptions for the @global and @param tags in the wp_media_attach_action() DocBlock. [32018] #31888
  • Clarify the DocBlock description for wp_print_request_filesystem_credentials_modal(). [32016] #31888
  • Clarify 4.2.0 changelog entry, add global description to the DocBlock for WP_Users_List_Table->single_row(). [32015] #31888
  • Add missing @since versions from a variety of methods in WP_Press_This. [32014] #31888
  • Add missing DocBlocks for the _limit_array(), _limit_string(), _limit_url(),_limit_img(), _limit_embed(), and _process_meta_entry() utility methods in WP_Press_This. [32013] #31888
  • Add a return description to the DocBlock for WP_Posts_List_Table->is_base_request(). [32009] #31888
  • Add an @see mention for Plugin_Upgrader, plus spacing to the wp_ajax_update_plugin()delcaration. [32006] #31888
  • Add a more descriptive function summary for options_discussion_add_js(). [32005] #31888
  • Fix Docblock syntax for the taxonomy_parent_dropdown_args filter. [32003] #31888
  • Add a missing return description for wp_styles(). [32041] #31888
  • wp_install_maybe_enable_pretty_permalinks() should have a consistent @return value. [32027] #6481, #31888

Help/About

  • All strings are available for translation. [32132] [32135] [32136] #31929
  • Change the subhead strings on credits.php and freedoms.php to match about.php.
  • Link the Emoji Codex article in the emoji blurb.
  • Add a second sentence to the JavaScript Accessibility blurb.
  • Switch positions for the JavaScript Accessibility and Complex Query Ordering sections for balance. [32131] #31929
  • Update about page for 4.2. [32118] [32123] [32130] #31929

Upgrade/Install

  • Move wp-plugin-update-success event to after lock is released [32133] #31978, #31819
  • Use named function instead of anonymous function, making it testable and replaceable. [32126] #31964
  • When dbDelta() is checking whether an index is defined in a CREATE TABLE statement, don’t worry if MySQL has a subpart defined on an index, but the CREATE TABLE doesn’t. [32108] #31869

Script Loader

Press This

  • Do not show the bookmarklet upgrade notice when accessing directly press-this.php. [32122] #31968
  • Add mb_strlen() compatibility function. Works the same way as the existing mb_substr() compatibility function. [32114] #31951
  • Check the bookmarklet version and add the update notice from PHP. [32106] #31942
  • Add ARIA attributes to the alerts container. [32102] #31942
  • Fix focusing the Standard Editor link after saving draft, if the user has not focused another element. [32098] #31923
  • Change the link text to Standard Editor. [32093] #31923
  • When saving a draft change the text of the Save Draft button to “Saving…” [32092] #31923
  • Update documentation for press_this_save_redirect filter after [31992]. [32143] #31996

Taxonomy

  • wp_update_term() should check if get_term() returned null. [32117] #31954
  • Avoid an unexpected object error when syncing global terms. Pass the expected single value, rather than object, when recursively calling global_terms(). [32064] #31914, #31149

Editor

Thanks to @adamsilverstein, @afercia, @awbauer, @azaozz, @boonebgorges, @DavidAnderson, @dimadin, @dlh, @DrewAPicture, @ericlewis, @hauvong, @helen, @hugobaeta, @iseulde, @jamescollins, @jeremyfelt, @joemcgill, @joen, @johnbillion, @jorbin, @kraftbj, @lancewillett, @markjaquith, @mattheu, @Michael-Arestad, @mindrun, @morganestes, @nacin, @nitkr, @obenland, @ocean90, @pavelevap, @pento, @peterwilsoncc, @samuelsidler, @SergeyBiryukov, @siobhan, @sirbrillig, @slobodanmanic, @swissspidy, @tmatsuur, @Tmeiste, @tyxla, @valendesigns, @westonruter, and @wonderboymusic for their contributions!

#4-2, #week-in-core