Josepha 6:54 pm on July 8, 2019
Tags: ,   

X-post: Updates to the WordPress User & Developer Survey

X-comment from +make.wordpress.org/updates: Comment on Updates to the WordPress User & Developer Survey

Timothy Jacobs 11:36 pm on July 7, 2019
Tags:   

Rest API Chat Summary: June 27

This post summarizes the weekly REST API chat meeting for June 27, 2019. (Slack transcript). Weekly REST API component office hours are held every Thursday at 18:00 UTC in the #core-restapi room in the Make WordPress Slack.

Ticket Review

#43691 is close to being ready for commit. @timothybjacobs raised the question of how strict WordPress should be about enforcing the use of the 204 status code. @kadamwhite agreed that core shouldn’t be that stringent.

#43392 has received some more feedback. @timothybjacobs is working on a refreshed patch. @spacedmonkey wanted to know how the ticket would impact #43941. @kadamwhite didn’t think they’d conflict and whichever ticket landed first would require the other to be adjusted.

#47443 came up in a recent REST API bug scrub. It touches post type capabilities which can be tricky. Feedback from developers with post type capabilities experience would be very helpful.

Menus Endpoint

@spacedmonkey has continued work on the Menus Endpoint. A discussion ensued about how to get better feedback on open PRs. Johnny is planning on writing up some basic test instructions. Subsequent PRs will hopefully be smaller and easier to test in the future.

The Menus Location endpoint was discussed. In particular, what endpoint should be responsible for assigning a menu to a menu location. @spacedmonkey‘s gut reaction is that menu-locations are like categories. You assign a category on the post endpoint, so a menu location should assigned on the menu. @kadamwhite and @timothybjacobs had similar initial thoughts.

@kadamwhite brought up that it’s a bit of a flip from the existing UI model, where you start with a location and then add a menu to it.

@timothybjacobs suggested modeling it after the existing posts controller, at least for the first iteration.

Upcoming Meetings

#rest-api

Jorge Costa 11:13 am on July 4, 2019
Tags: , ,   

Editor chat summary: Wednesday, 3 July 2019

This post summarizes the weekly editor chat meeting on Wednesday, 3 July 2019, 14:00 WEST held in Slack.

The agenda followed can be found here.

Task coordination

Note: If you’re reading this summary outside of the meeting, please drop a comment if you can/want to help with something!

@nerrad

Implemented the first pass at a potential solution for the element interpolation i18n problem https://github.com/WordPress/gutenberg/pull/16374.

@youknowriad

  • Worked on some performance related PRs. Mostly tried to make the getBlock selector more performant as it’s the bottleneck in terms of typing performance.
  • Reviewed a bunch of PRs. One of the most important is the Customizer Panel to edit block-based widget areas PR by @epiqueras.
  • Plans to land the block reordering animation soon.

@aduth

Made a few small pull requests, reviews, focusing mostly on “custom” sources for blocks (reimplementing meta to start)
https://github.com/WordPress/gutenberg/pull/16402.
Referred that the issue with the publish button https://github.com/WordPress/gutenberg/pull/16303 has a significant impact and might be easy to review if someone wants to take a look.

@danr

Continues working on table block tasks. Has a couple of PRs ready for review:

Has a PR which changes the way the blocks.registerBlockType filter works. Would be happy for more testing on it: https://github.com/WordPress/gutenberg/pull/16348

@welcher

Worked on some PRs related to SlotFill with https://github.com/WordPress/gutenberg/pull/13361 being the highest priority, followed by https://github.com/WordPress/gutenberg/pull/16384, in his opinion.

@kjellr

Has been posting some work on revised, less-intrusive tips:
https://github.com/WordPress/gutenberg/issues/16315.

He is hoping to get PR https://github.com/WordPress/gutenberg/pull/14961 merged, once we can figure out the mysteriously-failing test.

Did some initial work on the Patterns API, and hopes to get that posted until the end of the day: https://github.com/WordPress/gutenberg/issues/16283

@getdave

Has been working to allow any Block to be registered to handle “Grouping” interactions. Received non-consensual feedback some people think that it is a good idea while others think the opposite.
Additional feedback is welcome:
https://github.com/WordPress/gutenberg/pull/16278.

Has been working on Block Previews component along with @joen to allow it to dynamically resize and handle scale a lot better: https://github.com/WordPress/gutenberg/pull/16113.

@nadir

Continues the work on Snap to grid RFC.

@jorgefilipecosta

Answered & debugged some issues and submitted bug fix PR’s. Reviewed some PR’s, including the blocks in the customizer and the custom parser options. Proposed a simple mechanism for themes to register styles and did updates to the image Link UI refactor PR, which was recently merged.

@chrisvanpatten

Has been doing some light PR reviews and issue replies… Is aiming to schedule a Gutendocs bug scrub session next week; if anyone has specific days/times that work and you want to join, feel free to comment! @chrisvanpatten would love to get good attendance.

Agenda: Non-code contributions

@youknowriad introduced the topic by referring that the idea is that we value code contributions (or PRs more precisely) more than other types of contributions: PR reviews, triage, discussions in issues… The consequence is a growing list of unreviewed PRs and untriaged issues.

@epiqueras proposed some ideas to explore:

  • draft documentation for what is good triage and reviewing, why it’s important, and where new contributors should start.
  • highlight some good live PRs to review for people to take a look at.
  • recognize these types of contributions so that their value is more obvious.

@karmatosed referred that design / technical feedback should be added to the previous list.

@youknowriad a small first step today was that he tried focusing more on “non-code” contributions during the Task Coordination and tried to highlight this work more.

@karmatosed noted that we could expand beyond ‘did you review PRs’ to say ‘did you leave feedback or offer insights’.

@nadir shared that:

being a new contributor, based on my experience in trying to review PR I would say it was really hard for me because sometimes you really need to understand the codebase, things that are agreed upon, the norms and what’s not.

the only PR that I could review are related to things I already solved issues on or had PR related to, but I felt that I wasted a lot of the core team time reviewing basic problems like how to document eslint disable rules and how to write code that matches the core team theme

@karmatosed made an essential point that every single moment investing in someone as awesome to try and contribute isn’t a waste

@mcsf thanked the share made by @nadir and said:

I think that’s a very real issue for anyone coming to the project. I have a suggestion for easing into reviewing other people’s work: recognise that you can still provide helpful feedback even when you’re not an “expert”. This, to me, means that you could define the scope of your review, or your abilities: “I can only speak about this component”, or “about the overall readability”,
Concluding by saying that a newcomer’s eye can reveal a lot of blind spots in PR’s.

@aduth also thanked the share made by @nadir referring that he is inclined to say that we need more documentation for the things @nadir referred. Followed with a set of questions: Is this documentation as it’s organized today very effective? Do you have any thoughts on what might be an effective way for you to become aware of norms and such?

@karmatosed continued the conversation by stating that: Docs are just docs. It’s surfacing and being in the right place counts.

@nadir added that triaging was also an excellent way for him to contribute since he worked on two components when he started (button & snack bar), filtering issues & PR by those components gave him a good ability to review and understand what is happening

@brentswisher joined the conversation and supported the idea of “draft documentation for what is good triage and reviewing”.

@youknowriad proposed a welcome bot that comments PR’s of new contributors. The discussion went on with people sharing insights regarding that idea and how a concrete bot implementation could like.

@karmatosed shared the following actions points as a discussion summary:

  • Recognize and highlight non-code contributions more during weekly meetings
  • Surface the docs better (how?).
  • Improve the docs. (can we create an issue to discuss what needs to be improved and how)
  • Add thoughts to welcome bot and project board: https://github.com/WordPress/gutenberg/projects/24#card-17518302
  • Consider what role of welcome contributor could be.

And ended with a reminder: “We are all human.”

Open Floor

The open floor started with a question by @joyously: How the editor can better support themes? She added:

The old editor has an easy interface to add “Formats” with a simple PHP filter that makes a button in the editor. When can we have that again? Why change the interface to the theme? (new API)

@youknowriad answered by saying:

I think there’s a difference in the paradigm that makes applying “random classNames” to “random HTML” not a good fit for the block editor. While in TinyMCE we’re adding content as HTML, in the block editor we’re adding content as blocks which means any markup we add should be meaningful for the block.

So the idea is that we have two use-cases here:
– Apply a style variation to the block (known block) (className + stylesheet)
– Apply an inline style variation (inline class name) in RichText. We don’t have an API for that one because it’s less common, but I think you should feel free to open an issue about this “Custom Format” (talking about the RichText Format API ).

#core-editor, #editor-chat, #summary

David Baumwald 10:21 pm on July 3, 2019
Tags: , ,   

Dev Chat Summary: July 3

In @chanthaboune scheduled absence, @davidbaumwald served as the facilitator for the chat.

Announcements

@desrosj called attention to the Site Health component that was added to WordPress Core earlier this week. Congratulations and many thanks to all involved in the project, and special thanks to the maintainers. If you’d like to learn more, you can read the announcement here. To get involved, join the new Slack channel for Site Health, #core-site-health.

Upcoming Releases

Minor Release (5.2.3)

Currently, there are only three tickets milestoned for a potential minor before 5.3. There was no further discussion or decision making during this week’s chat for 5.2.3.

Major release (5.3)

The schedule and potential features and focuses for 5.3 has yet to be determined. No further discussion was had related to 5.3 during this week’s chat.

Calls from component maintainers

@kadamwhite brought attention to #core-restapi Bug Scrubs being led by @timothyblynjacobs, in the run-up to 5.3. Those who can are invited to participate. Recent scrubs have been happening at 1800 UTC on Tuesdays, and they are usually announced ahead of time on the Make WordPress Core blog.

It was also announced that there will be no formal #core-restapi chat this week.

Finally, @sergeybiryukov called attention to a recent make/hosting post requesting feedback regarding a change in the recommended PHP version for WordPress. If you have additional data or an opinion you’d like to share, please comment on that post.

Open Floor

@pers requested movement on ticket #46197 for potential inclusion in the 5.3 release.

@mikeyarce mentioned ticket #34560, and asked for direction on next steps. @adamsilverstein offered to review the ticket, and will respond there.

Lastly, @justinahinon called attention to the recent creation of ticket #47644.

The next Dev Chat is scheduled for July 10, 2019 20:00 UTC in the #core Slack channel.

These notes were taken by @davidbaumwald and proofread by @sergeybiryukov.

#5-3, #devchat, #summary

pbrocks 6:59 pm on July 2, 2019  

Editor Chat Agenda: 3 July 2019

Note Taker: @pbarthmaier

This is the agenda for the weekly editor chat meeting on Wednesday, July 3rd, 2019, 6:00 AM PDT.

  • Tasks Coordination
  • Open Floor

This meeting is held in the #core-editor channel in the Making WordPress Slack.

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below. #agenda, #core-editor, #editor-chat

David Baumwald 6:26 pm on July 2, 2019
Tags: , ,   

Dev Chat Agenda: July 3

Here is the agenda for the weekly devchat meeting at July 3, 2019 at 20:00 UTC.

  • Announcements
  • Upcoming Release Discussions
    • Point release
    • Major release
  • Calls from component maintainers
  • Open Floor

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

This meeting is held in the #core channel in the Making WordPress Slack.

#5-3, #agenda, #devchat

Omar Reiss 3:11 pm on July 2, 2019
Tags: , , ,   

JavaScript chat summary, June 25th + July 2nd, 2019

Below is a summary of the discussion from the JavaScript chat of the last two weeks (agenda June 25th, Slack Transcript June 25th, agenda July 2nd, Slack Transcript July 2nd)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda: E2E Test infrastructure for Core

Slack Conversation June 25th

A ticket was created by @youknowriad which seeks to incorporate Gutenberg’s end-to-end test setup into WordPress core: https://core.trac.wordpress.org/ticket/45165. The patch has been reviewed by multiple members of the Core JS team and was eventually committed. @youknowriad wrote a devnote here:

Introducing the WordPress e2e tests

Agenda: E2E Tests – next steps

Slack Conversation July 2nd

With the e2e framework now in core, we can start adding testcases. A few good next steps were raised:

  • Encouraging people to write tests, anytime we notice a regression or an important feature. Some coordination would probably help. Who could help lead/organize it?
  • Try to run the Gutenberg e2e tests (maybe not all of them) in Core’s CI as well. This would allow upgrading the npm packages from Gutenberg in Core with more confidence.
  • Extending the framework to be able to run tests across PHP versions could definitely be helpful for smoke testing pages, checking there are no warnings, etc.
  • Improving the documentation with regard to e2e test would also be valuable.

These points could best be raised in Devchat as well, as they transcend the realm of Core JS.

Agenda: Build all Core JS with WebPack

Slack Conversation

A new patch was uploaded by @herregroen to build all core JavaScript with Webpack: https://core.trac.wordpress.org/ticket/43731. Building all JS in core with WebPack means we can have a single consistent build process for all JS, rather than having different build tools for Gutenberg and the media library versus everything else. It also allows us to start reusing WordPress packages in the JavaScript that is already present in core. Some more review and testing is needed.

Open Floor: Request for feedback

Slack Conversation

There is some exploration going on around possible solutions for interpolating React elements in strings in this Gutenberg issue: https://github.com/WordPress/gutenberg/issues/9846. @nerrad has requested some feedback to some recent considerations he’d proposed in that issue. Input is welcome!

#core-js, #corejs, #javascript, #meeting-notes

Jonathan Desrosiers 2:14 pm on July 1, 2019
Tags: site-health   

New Core Component: Site Health

During Contributor Day at WordCamp Europe 2019, the newest WordPress Core component was created, Site Health. After many months being tested as a feature plugin, Site Health was merged into WordPress core in versions 5.1 and 5.2. Below are several changes that were made during Contributor Day to help organize tasks and efforts around Site Health moving forward.

New Slack Room

The Site Health feature is just one tool that is empowering site owners and hosts to upgrade to more modern versions of PHP. Because of this, most of the discussions around Site Health have happened in #core-php to this point.

However, now that Site Health is in WordPress Core, it’s time to give that Slack room back to the folks discussing how PHP is used in Core (upgrades to patterns, discussing guidelines, style guides, etc.).

All Site Health discussion moving forward will be held in the new #core-site-health channel.

Component Maintainers

The following people have played incredibly important roles in the Site Health project so far and were asked to be component maintainers. All accepted:

Action Summary

Here is a brief summary of the actions taken to facilitate this change:

  • A Site Health component was created in Trac.
  • A Site Health component was created and added to the Make WordPress Core Components page.
  • All open tickets with the site-health keyword were moved into the Site Health component (tickets effected).
  • All open tickets with the servehappy keyword were moved into the Site Health component (tickets effected).
  • All closed tickets with the site-health keyword were moved into the Site Health component (tickets effected).
  • All closed tickets with the servehappy keyword were moved into the Site Health component (tickets effected).
  • The site-health tag has been created for this blog. All Site Health related posts will utilize this tag.

Note: The site-health and servehappy keywords are now obsolete and should not be used moving forward. but they will remain on old tickets.

#site-health

marybaum 6:13 pm on June 27, 2019  

Dev chat summary: June 26

Another relatively quiet devchat, with folks returning from WCEU and getting into holiday mode here in the US.

We had one announcement: Gutenberg 6.0! Props @karmatosed and all the core-editor and Gutenberg contributors. It looks amazing!

@desrosj led a brief discussion of when and how we might release a 5.2.3. Two tickets in Trac have that milestone, but one of them, #47561, is a layout issue and not a functionality issue.

So over the next few weeks, we (you the reader, the community, the component maintainers and I the copywriter) will see how the scheduling for 5.3 shakes out and let that inform the point-release decision.

Meantime, @desrosj suggests we all just keep working on our tickets until we learn more about the specifics of 5.3.

In open floor, @joyously noted that there are a lot of meta tickets to improve the SEO of the .org site. She suggests that some of those be incorporated into WP, to fix it for everyone.

@garrett-eclipse asked for a committer to review ticket #37782.

@davidb will lead next week’s devchat.

I’ll be back July 10, and @chanthaboune will be back after that!

Riad Benguella 12:12 pm on June 27, 2019
Tags: , ,   

Introducing the WordPress e2e tests

The purpose of e2e (end to end) testing is to simulate the real user scenario and validate the different flows. In concrete, running an e2e test involves setting up a production-like environment, opening a browser and interacting with the application as it was a real user manipulating the interface. This is one of the best testing methodologies to avoid regressions.

Gutenberg has been successfully using this kind of tests for some time now. Reusable packages to setup and run e2e tests have been built in the repository. Starting today, this setup was brought into WordPress and included in our CI pipeline.

Local Environment

The e2e tests require a production-like environment to run. The current setup relies on Docker to provide a built-in environment.

You can run the environment locally on your own WordPress Core clone.

First, make sure you have Docker installed (instructions on this link).

Then, you should be able to run the environment by running these commands on your own WordPress repository clone.

npm install
npm run env:start

This command will make sure you have the right node/npm versions installed, triggers docker containers for your web and mysql servers and installs WordPress using the build folder.

You can also reset the environment with a testing website using:

npm run env:reset-site

You should be able to access your environment on http://localhost:8889. The default username is admin and the password is password.

Running the e2e tests

Once your environment ready, you can launch the e2e tests suite by running:

npm run test:e2e

This will run the test suite using a headless browser. For debugging purpose, you might want to follow the test visually. You can do so by running the tests in an interactive mode.

npm run test:e2e -- --puppeteer-interactive

you can also run a given test file separately

npm run test:e2e tests/e2e/specs/hello.test.js

Writing e2e tests

The e2e tests live in the tests/e2e/specs folder and should be follow the following naming format my-file.test.js.

The e2e tests use Jest as a testing/asserting framework, and rely on Puppeteer to communicate with the browser.

A typical e2e test looks like that:

// Load utilities from the e2e-test-utils package.
import { visitAdminPage } from '@wordpress/e2e-test-utils';

// Name of the test suite.
describe( 'Hello World', () => {

	// Flow being tested.
	// Ideally each flow is independent and can be run separately.
	it( 'Should load properly', async () => {
		// Navigate the admin and performs tasks
		// Use Puppeteer APIs to interacte with mouse, keyboard...
		await visitAdminPage( '/' );

		// Assertions
		const nodes = await page.$x(
			'//h2[contains(text(), "Welcome to WordPress!")]'
		);
		expect( nodes.length ).not.toEqual( 0 );
	} );
} );

e2e test utilities

When writing e2e test, you’ll notice that some actions are repeated across tests. Things like:

  • Login into the dashboard
  • Go to a page
  • Activate/Deactivate a plugin
  • Create a new post
  • Create a dummy page

A number of these utilities is already available in the @wordpress/e2e-test-utils package, in the Gutenberg repository. You’re encouraged to use and share reusable utilities across tests.

In addition to these utilities, you can checkout the Puppeteer API Docs to manipulate the browser.

We need you

Please give it a try, the more we add tests, the more stable our releases will be. If you need support, ask in the #core-js Slack channel.

#core-editor, #core-js, #testing