The WordPress core development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
This post summarizes the weekly dev chat meeting held Wednesday, September 05, 2018, 20:00 UTC, including topic updates from the lively August 29 dev chat. Agenda | Slack Archive
@youknowriad mentioned it would be lovely for these two REST API issues to land in 4.9.9:
If you have other issues you’d like to see in 4.9.9, come on over to next week’s chat. We’ll keep the lights on for ya.
The fab JS team posted notes from their weekly chat. Thanks @matveb for posting the recap! Highlights:
tl;dr – This conversation has moved over to #core-http in Slack and is being self-organized by those involved. And yes we know that channel name is not secure!
That’s it! We’ll see you at <dev chat> next week: Wednesday, September 12 20:00 UTC in the #core Slack channel.
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.
Gutenberg has a policy where deprecated functionality is kept for two additional minor versions to allow time for plugin developers to move away. As we start deprecating functionality in the published npm modules, the idea of tying to Gutenberg version doesn’t make a whole lot of sense, as these packages could be used independently of Gutenberg or WordPress.
It was raised by many that our packages should just follow semver. The most likely scenario for the 5.0 merge will be that the JavaScript will still be maintained on Github and included in WordPress through npm. The aforementioned deprecation policy is mostly something that applies to the Gutenberg / WordPress context then. The initial idea in terms of flow looks somewhat like this:
deprecated to allow Gutenberg to define its domain-specific messaging (@aduth, @youknowriad)The build step that was introduced in #43055 seems to cause quite some friction for PHP development, since now you also need to build to see a change in the PHP reflected. This turns out to be a weird experience for PHP development, since there’s no real reason why it needs to be built. A solution that allows for building with symlinked PHP files was pursued in #44492, but seems to run into a dead end. @omarreiss is now working on a grunt build:dev task which allows to build into src after all and asked if anyone had any input / objections.
It was raised that some PHP files (ie. formatting.php) need to be built right now and this is really confusing. Since PHP is a dynamic server language, we should look if we can avoid any PHP from being built statically. Apart from this there seemed to be no objections to the approach.
@omarreiss will work on a patch.
Currently it’s not clear if plugin developers should consume WordPress packages through the wp global or by importing them from the @wordpress/ namespace. Documentation and guidelines about this are currently lacking. It was raised that different approaches are probably needed in different scenario’s. Factors that play a role are:
@atimmer will work on a guideline for the plugin development handbook in which he plans to document different scenario’s and approaches.
This is the agenda for the weekly devchat meeting on September 5, 2018 at 20:00 UTC:
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!
Our final update for August aims to add further clarity to some core interactions, as well as fixing many issues. Notably, we are expanding on the previously called “Fixed Toolbar” mode — now named Unified Toolbar — as an optional mode for a more traditional writing environment. In our testing, this mode tends to be preferred by more experienced users who don’t mind the disconnect between the tools and the content blocks. There’s also an additional setting which focuses the editing experience on a single block at a time, as well as de-emphasizing some of the block boundaries. These tools can be combined at will to better suit personal preferences and creative workflows.
There are many improvements to individual blocks, conversions, templates, and interactions. We want to say thank you again to everyone who is engaging, raising concerns or making suggestions, and collaborating in making the project better with each release.
preload attribute in Video Block.doAction when a deprecated feature is encountered.window in data registry.FocusableIframe component URL example.withSafeTimeout in compose.onSetup and getSettings as unstable APIs from RichText.core-data explicit.spec-parser package.stylelint to 9.5.0 and stylelint-config-wordpress to 13.1.0.contentSizeChange on Aztec component.Deprecations removed with this version.
Dark Mode has become a rapidly popular feature to many online tools and services in recent years and it’s about time WordPress joins in on this trend as well. Many websites such as Twitter, YouTube, Reddit and even macOS Mojave, Apple’s newest operating system have adopted this feature as one to help user’s who are looking at screens for long periods of time. Traditionally we’re use to seeing light backgrounds and dark text in a high contrast environment which can be damaging for the eyes.
If you have ever found yourself working on something late at night and having to make adjustments so the bright light doesn’t hurt your eyes so much, you’re in for a treat!
Dark Mode transforms the colours of the WordPress dashboard from bright white and grey colours to dark grey and black instead. This means you no longer need to squint or turn down your brightness setting trying to avoid things like headaches and eyestrain.
Whilst Dark Mode is a great way to personalise your setup, there’s a few things that it’s not. These include but is not limited to:
1. What is Dark Mode?
Dark Mode is a new option available for each individual user of your WordPress website to change the dashboard style to a darker design, steering away from the classic white and grey design we’re all use to.
2. Why should this be in Core?
WordPress has always made use of lighter colours within the dashboard. Whilst this may be fine for many, some users may find it harder to read text on the page and it gives people the opportunity to experience their settings in a much nicer, and more comfortable design.
3. How would this be maintained in Core?
As this affects the entire WordPress experience in the dashboard, it would require at least a small group of people to actively maintain it as a component and would need continuous input between developers and designers when new features are rolled out.
4. Will this support Gutenberg?
No, Dark Mode supports TinyMCE (not the theme editable areas) but will not support Gutenberg right now. This is something that should be worked on in tandem with the Gutenberg core team. It’s been decided that a merge proposal with Gutenberg support is the most beneficial way forward at the moment. This is partly due to the nature of rapid weekly updates and changes that Gutenberg is facing which would make it difficult to properly maintain at the moment.
5. Which plugins will be supported? / How can plugins support Dark Mode?
Please refer to the plugin compatibility guide on the GitHub repository for more information on this. For most plugins, this will be a case of using an action hook to include the third party plugin’s Dark Mode stylesheet which is triggered when the current user has confirmed they’d like to use Dark Mode.
Currently, the only plugin which is natively supported by the Dark Mode plugin is Gutenberg. This is because Gutenberg is a feature plugin which will become part of the WordPress core and must be supported by default. No other plugins are to be supported at this time. Plugin developers wishing to save themselves time should try to use the default WordPress UI elements as much as possible.
And for the most important and most asked question of all…
6. Why isn’t this a colour scheme?
Admin Colour Schemes, since being added in WordPress 3.x change the colour of the admin toolbar and the side menu within the dashboard. Colour schemes, generally (and should only) change these two elements and nothing else. Dark Mode doesn’t affect either of these two elements. In fact, the sole purpose of Dark Mode is to change the style of the main content area in the dashboard. This means you can have a custom admin colour scheme enabled alongside Dark Mode if you really wanted to.
Dark Mode has already been thoroughly tested but should have further testing before merging to ensure that every element is styled just right. As it currently stands, Dark Mode has been designed in a class model which enables it to be placed within core very easily with the use of hooks.
Whilst there may be some changes required to port it over into the core stack, the current files required for it to actually work are only 2. The PHP code to check the user preference and the CSS file containing the styles meaning the task of actually merging could be relatively quick.
If you do find any issues, please report them by opening a new issue on GitHub.
I would like to give a big thank you to everyone who has helped get Dark Mode to where it is today. The development of the the plugin started on the 3rd October 2017. Since then, the plugin has seen contributors of various levels assist in testing, coding and designing the product we have now. Yay for open source communities!
This is the agenda for the weekly dev chat meeting on Wednesday, August 29, 2018 20:00 UTC.
If you have anything to propose, to add to the agenda, or specific items related to the above, please leave a comment below. Either way, we look forward to seeing you at the devchat this week!
#4-9-9 #agenda #core #dev-chat
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.
What tasks do we need to complete on the core side to be ready for Gutenberg Merge?
| What? | Who? |
|
Experiment with the following steps to see how this works: WordPress side: – Gutenberg packages stay where they are – Gutenberg’s PHP (script registration and bootstrapping) move to core. – Webpack config to alias wp.* to npm dependencies moves to Core’s webpack config. Gutenberg side: – Kept as plugin for ease of maintenance, updates. – Plugin re-register’s the scripts (overriding wp’s registrations) – No more php bootstrapping in the Gutenberg repository. |
|
|
Some experimentation could involve consuming packages in WordPress core. Example: Usage of shortcodes.js could be replaced with @wordpress/shortcodes
|
|
edit-post needs to be moved to a package. |
|
Resolve componentsand block-library which have some code that lives outside packages. |
The following things were discussed:
No clear resolution to the above points was made in the meeting.
| What? | Who? |
|
Decision: Ship packages without any polyfills, then bundle all polyfills in WordPress core. Documentation will include something like this: This package assumes that your code will run in an ES2015+ environment. If you’re using an environment that has limited or no support for ES2015+ such as lower versions of IE then using core-js or @babel/polyfill will add support for these methods. Learn more about it in Babel docs. |
@gziolo |
lodash to lodash-es for distributed packages| What? | Who? |
| Continue discussion on the related issue. |
This post summarizes the weekly dev chat meetings held Wednesday, August 15 and 22, 2018 (August 15 agenda | August 22 agenda | August 15 “tidechat” Slack archive |August 22 Slack archive).
It’s a two-for-one chat notes bonus! Lucky you, Internet.
Most importantly, we are grateful that we’re receiving so much feedback, and genuinely empathize with the inevitable frustration that accompanies developing and using new features.
Unfortunately, we have to address some of the unproductive communication contained in some feedback submissions, even going as far as to personally attack Gutenberg contributors. It’s easy to submit negative feedback when you don’t have to look someone in the eye, but there are IRL humans with IRL feelings who receive and address those tasks.
If you are providing feedback please follow the WordPress Etiquette and Support Forum Guidelines. Utilizing respectful, productive phrasing is also a fantastic way to ensure your submissions are taken seriously and acted on swiftly.
So many enhancements and Guten-bug* fixes over the last few weeks:
Also, pay special attention to this issue overview on introducing and/or extending PHP APIs.
*You’re welcome.
More chats!
Tide 1.0.0-beta has come ashore!* What is Tide?
Tide is a series of automated tests run against every plugin and theme in the directory and then displays PHP compatibility and test errors/warnings in the directory.
– I copied/pasted this from here
The Tide team can be found at #tide in Slack, and welcomes input for release candidate inclusions for an eventual 1.0.0 release.
*I’m sorry.
It’s been awhile since we evaluated the weekly <dev chat> schedule, so here we are. Some options discussed included:
This is a call for a lovely person or two to help us coordinate a second/alternate <dev chat> time.
Comment on this post or message @jeffpaul and/or me in Slack.
The next <dev chat> will take place on Wednesday, August 29, 2018 20:00 UTC in the #core Slack channel. Please drop in with any updates or questions. If you have items to discuss, drop a comment on next week’s agenda post, so we can take them into account.
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.
WordPress.github.io/servehappy-resources, which is not very obvious for what it contains. A repository named update-php or update-php-resources would be a better alternative. Alternatively, a custom domain could be used. This needs to be carefully evaluated.This is the agenda for the weekly devchat meeting on August 22, 2018 at 20:00 UTC:
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!