Javascript Chat Summary – December 4, 2018

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack Transcript)

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

Agenda: Holiday / WCUS scheduling

Slack Conversation

We agreed to cancel the #core-js meetings for December 11th (post-WCUS travel), December 25th (Christmas), and January 1st (New year). @aduth posted a cancellation notice here: https://make.wordpress.org/core/2018/12/04/javascript-weekly-chats-wordcamp-us-holiday-scheduling/

Agenda: Linting

Slack Conversation

A PR which extracts Gutenberg’s ESlint config to its own package by @gziolo has been merged. It’s set to be published to NPM as @wordpress/eslint-config. Publication is currently blocked by the 5.0 RC freeze, but is expected to land around contributor day together with a post outlining revisions to the JavaScript coding standards prepared by @aduth

We also discussed how to manage custom eslint rules. Some linting rules might not be useful outside of the context of WordPress core or Gutenberg. We decided for now to go the same path as the Jest eslint package. For the time being we will have one package with multiple configs, which will allow consumers to select the configs they need. 

Agenda: 5.0 Script Changes

Slack Conversation

With WordPress 5.0, a few vendor scripts (like lodash) are being included in core. For these scripts in particular, there is a chance for conflict if a plugin or theme registers their own copy of the dependency with the same un-prefixed name. There is a greater likelihood if there is a large version mismatch between the registered scripts.

Different approaches to prevent this were discussed. @aduth is working on a devnote to help integrators prevent these kinds of conflicts from happening.

#javascript, #meeting-notes

JavaScript Weekly Chats – WordCamp US & Holiday Scheduling

As discussed in today’s chat, the following meeting dates for the JavaScript Weekly Chat will be cancelled due to WordCamp US travel and in observation of upcoming holidays:

  • December 11
  • December 25
  • January 1

#javascript

PHP Meeting Recap – November 19th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

  • @joyously asked about the current state of Tide. @flixos90 added that he is not clear on where it currently stands, but once it is open for projects like Servehappy to integrate with it, it would make a great use-case. Automating the PHP version compatibility might be more reliable in the long run than requiring plugin/theme authors to manually keep that information up to date.
  • The topic of having a range of supported PHP versions for each plugin was discussed throughout the meeting.
  • Information of a maximum supported version of course helps the user to determine its compatibility, generally. However, it can also have negative implications on the PHP efforts: In case the maximum supported version information is not accurate, it will make site owners hesitant from updating PHP, for no reason. Particularly since this conflicts with the project’s goal, caution is required.
  • Neither the plugin/theme author nor an automated code-sniffing based tool can reliably provide compatibility information. Arguably, the latter will end up with more accurate results in the long run, but it still will include many false positives (or false negatives).
  • Due to this problem, there was mostly consensus that no tested up to PHP version should be exposed at this point. While both the minimum and maximum versions are not reliable, the maximum version is more likely to have a negative impact on the project’s efforts.
  • Another topic discussed was the safeguarding of such incompatible plugins and themes, when they are attempted to be used. A site owner should be prevented to interact with such an extension as early as possible, i.e. when installing it. If it is installed through a way that WordPress cannot control, such as uploading manually, then it should at least apply the same restriction on activation. A follow-up discussion to the meeting questioned whether this restriction should be enforced, or alternatively only suggested, for example by using indicative colors in the UI. 
  • In that regard, it needs to be ensured that the more experienced users are accounted for as well, in case they want to be informed of fatal errors in the more traditional way and get around the safeguarding mechanisms. An idea could be to provide a constant or otherwise configurable flag to disable the safeguarding mechanisms, which could cover both the extension restriction and the WSOD prevention. By default these should definitely be enabled, to account for the majority of users. This being configurable would allow to circumvent the hard restrictions, which are preferable for the common case.

Next week’s meeting

  • Next meeting will take place on Monday, November 26th, 2018 at 16:00 UTC in #core-php.
  • Agenda: Open floor.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #servehappy

JavaScript chat summary – November 20th

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack transcript).

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

We tried to keep the meeting succinct as many people are pushing out a Gutenberg release.

Correcting Package Global Names

Relevant context in a previous Slack discussion. Question: Should we “deprecate” wp.escapeHtml to wp.escapeHTMLwp.tokenList to wp.TokenList?

There was a bit of a back and forth whether this should be something that is addressed now. At the end we concluded to add this to the list to address in a 5.0.x release.

Npm packages publishing workflow

From last week, we discussed this very briefly to keep it in our mind space. Link to the relevant issue on the Lerna repository.

#chats, #javascript, #meeting-notes

PHP Meeting Recap – November 5th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

  • Note that, in order to maintain the original time in most parts of the world after the end of daylight saving time, the meeting time has been adjusted from 15:00 UTC to 16:00 UTC.
  • Due to the focus on Gutenberg and the resulting lack of activity in other areas, this and the following meetings should preferably be used for some “housekeeping”, reviewing the project roadmap and planning the next steps after 5.0.
  • @flixos90 asked to review the Servehappy feature project page, since that has not been updated in a long time. The page would later be updated to reflect some of the additional requirements that came up mid-2018 and to show the currently planned timelines for all features in the project’s scope, plus links to relevant resources and tickets.
  • @afragen brought up #44619 which had not been tagged with the “servehappy” keyword before, mentioning that the ticket is close to ready. @sergeybiryukov pointed out that it should receive design feedback first.
  • @joyously asked about the plans for themes requiring certain PHP versions. While nothing has been developed in this regard yet, themes should eventually be able to specify a minimum required PHP version, just like plugins. This information should be available through the Themes API, and WordPress core should implement techniques to restrict installation, updates and activation of such themes if the requirements are not met, again just how it has been worked on for plugins for the past couple months. However proceeding with this is currently blocked by the lack of theme readme support for wordpress.org, since the minimum requirements should be specified via the readme.
  • The Tide project could in the future be used as an additional means to determine PHP compatibility of plugins and themes.

Next week’s meeting

  • Next meeting will take place on Monday, November 12th, 2018 at 16:00 UTC in #core-php.
  • Agenda: Review future proceedings for the project and refine roadmap and priorities.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #servehappy

JavaScript Chat Summary – October 30th

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack transcript).

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

Meeting time adjustment

Due to DST and starting next week, the #core-js meeting time will be moved to 14h UTC.

Node 10.x LTS

A new LTS version of Node.JS has been released. As agreed upon on previous meetings, WordPress is going to follow the LTS schedule of Node.JS which means, we’re going to start using this new LTS version in local environments (Gutenberg and WordPress).

The systems team has been also notified to upgrade the WP.org servers to Node 10.13 LTS.

E2E Tests in Core

End 2 End tests are automatic tests simulating user interactions using a browser in a production environment. Gutenberg uses Google Puppeteer and a docker environment to run a suite of various e2e tests that include:

  • Creating and publish content,
  • Writing Flow,
  • Accessibility tests,
  • Extensibility tests.

We discussed during the meeting approaches to make the E2E Test setup and the test suite available for:

  • Plugin Authors:  to setup their own e2e tests,
  • Core: To validate that the Gutenberg integration is working properly and allow other parts of WordPress Core to be tested using this setup. 

Action items

  • Explore making the e2e test setup available as an npm package. cc @gziolo
  • Explore making a package containing the Gutenberg e2e test suite to be able to run it in Core.

Shorter-term, we discussed the possibility of duplicating the tests in Core to validate the Gutenberg integration and package updates. 

If you have some availability and would like to help with any of these items, please let us know in the comments.

#javascript

Javascript Chat Summary – October 23, 2018

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack Transcript)

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

Agenda: Should wp.hooks support the special all hook?

Slack Conversation

In Gutenberg#8602 it is raised if we should add support for an all action in wp.hooks in order to match feature parity with the current PHP hooks system in WordPress core. While there were no real objections raised in the chat, pretty much everyone present agreed with this comment:

If it is primarily intended for debugging, then it might be worth exploring optimizations to avoid any impact in typical usage, e.g. monkey-patching runHooks when an all hook is added.

@aduth

Actions

  • No interest was expressed in the issue. If anyone wants to take it on, there wouldn’t be any objections either.

Agenda: Ways to optimize the package updating process

Slack Conversation

The process for updating packages needs to be optimized further. Right now any fix on a package has to follows the cumbersome flow of Gutenberg PR -> lerna release -> core ticket -> update package.json -> commit. We need to make this smoother.

This problem would probably not exist once everything is merged into a single monorepo hosted on git. But that doesn’t seem feasible just yet. Could we maybe mimic the advantage of having a monorepo a bit by getting more tooling into WordPress core and build straight from Github source? That would at least decouple publication of packages from being able to consume their changes in WordPress core development. 

It was raised by @gziolo that installing Gutenberg straight from Github with npm is not an option because Gutenberg consumes local packages which can’t be resolved by npm. The solution proposed is to take a similar approach to how Gutenberg packages are updated for Drupal.

This is done with an install script that simply clones Gutenberg into node_modules and builds the scripts in Gutenberg itself. While not a very elegant solution, this could work and drastically improve the process of keeping the packages updated.

Actions

  • @atimmer will work on a proof of concept.

Open floor: JS i18n

Slack Conversation

Good progress is being made on JavaScript language packs. 🎉 @herregroen is working together closely with @nerrad, @swissspidy and @ocean90 to land this. There seems to be a great deal of consensus and the work is nearing completion.

#corejs, #javascript

Dev Chat Agenda: October 17th (5.0 Week 3)

This is the agenda for the weekly devchat meeting on October 17, 2018 at 20:00 UTC:

  • 5.0 planning
    • Gutenberg and REST API bug scrubs
    • Gutenberg documentation
  • Updates from focus leads and component maintainers
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, then please leave a comment below. Either way, we look forward to seeing you at the devchat this week!

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

#5-0, #agenda, #core, #dev-chat

Javascript Chat Summary – October 16, 2018

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript)

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

Agenda: “Props” for Gutenberg Merge

Slack Conversation

How are props being handled for the merge of Gutenberg code?

  • consensus was mostly reached on Github profile attribution for any involved in a pull request.
  • There were not concrete plans for technical process implementation of props yet.

Actions

  • Discussion can continue in the meeting notes, or revisited in a future meeting.

Agenda: “Internationalization”

Slack Conversation

  • Proposal for language packs
  • for v1, utilize `wp_localize_script` for loading/queuing translations.
  • for v1, generate translation file (po,mo,json…) for every single JS file

Actions

  • split this out into a meta trac ticket and create tickets/issues on different projects as necessary. (owned by @herregroen)

Agenda: Plugin and Block Scaffolding

Slack Conversation

There are some recently released projects designed to aid developer experience around plugins and blocks for Gutenberg:

  • https://github.com/youknowriad/wp-js-plugin-starter
  • Work also started on a solution based on the above which is purely JS based.

Action:

  • continue feedback/evaluation on the pull request

Agenda: Pending bump of Node’s LTS version from 8.x to 10.x

Slack Conversation | Context

Action:

  • probably only request a bumping of the relevant files with node version in them.
  • possibly some docs updating needed.
  • revisit in a following meeting.

#javascript

PHP Meeting Recap – October 8th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

  • We started discussing how themes should be approached in terms of the WSOD protection (see the Trac ticket / GitHub PR).
  • We noticed that, when the active theme is deleted, the frontend will simply show a blank screen, so there are no critical implications of what happens when no theme can be initialized. What needs to happen is therefore to just flag the theme as paused so that it isn’t loaded, with no further handling being necessary.
  • A Resume button for themes should be added to the Appearance admin screen, similar like there is one for plugins, displayed to those that have the resume_theme capability, which should map to the existing switch_themes.
  • An observation was made along the lines that the default PHP error output also renders with the frontend message that something broke. While path disclosure is a problem, such messages should never display on production sites that are set up with something like the ini_set( 'display_errors', 0 ) directive. WordPress does not take care of setting this itself, which can be discussed in a ticket, but is not related to our WSOD protection efforts.

Next week’s meeting

  • Next meeting will take place on Monday, October 15th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Discuss how the php-error.php template from the WSOD protection project and related efforts made in the PWA feature plugin can be implemented in a coherent way. @westonruter had highlighted that there were similarities, but also differences, and a common solution should be found.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #servehappy