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:
WordPress 5.9.1 was released yesterday. This maintenance release features 82 bug fixes in both Core and the block editor.
Async key project updates
We used to exchange key project updates synchronously during the chat. However, many of the key Gutenberg projects sustain a regular cadence of updates on their tracking issues on Github.
This week we tried async updates. The attendees are encouraged to read the latest updates directly from the following tracking issues at everyone’s leisure:
Highlighted: Move post/page title to the top bar as a good issue that will help a lot of users on various levels. @vdwijngaert Koen worked on it but has not had the time to followup on it.
Is working on various issues that he gives design feedback to.
There are a lot of people who work on custom themes who are struggling with some of the style and markup changes in 5.9 and don’t understand the roadmap for the future-compatible theme customization.I’m working on a proposal for one way to handle this that should be out later this week, but I want to just get it onto folks’ radar ASAP. In many ways, I don’t think there has to be a huge change in direction, but some new standards and an adjusted block approach to settings could go a really long way in supporting custom themes.
and later also added this follow up:
@luehrsen added to the above that any feedback on the discussion above would be very appreciated.
Staying on top of the new features coming to the WordPress open-source project is one of the main barriers expressed by developers.
The Make Coreblog has a heavy emphasis on meeting notes for the various core teams, rather than highlighting new features. This makes it difficult for developers who are not contributors or who just occasionally contribute to find the relevant information among the team-related posts.
To achieve one of the big-picture goals for 2022 (“Create a developer-focused communications site“), this is a proposal for creating a Developer News blog. The content focuses on updates for developers, extenders creating plugins and themes, and those who work with WordPress at an agency or as freelancers.
Preliminary Timeline
Proposal and request for comment period: February 25 – March 18, 2022
Coordinate with Design and Meta Teams for theme (the News theme would be spectacular)
Brainstorm meeting with team representatives: End of March
Content creation and first post: early April 2022
Start-up phase: Through mid-July
Review and expansion to regular topics for developers: Fall 2022
Problem to be Solved
The current developer.wordpress.org holds a ton of comprehensive documentation with examples, tutorials, getting started guides, and more. That being said, there are various improvements that could be made to make the site much more impactful. Some of these areas for improvement are outlined below.
What’s missing:
There is no changelog to signal various changes including when pages are updated or when new APIs appear or existing ones are augmented with new filters, hooks, and configuration.
There is no mechanism to subscribe to updates. A blog would provide this feature.
Outside #core-editor meetings and GitHub, there is no single place to keep up with ongoing discussions. For example, to learn about the new styling engine, a developer needs to visit three sites: Discussion, Tracking Issues, and the first PR.
Start-Up Phase
As a first step, the Developer News can tackle the above pain points by:
Surfacing updates to documentation,
Highlighting new tutorials, and,
Providing a way for developers to subscribe to stay up to date
The Developer News blog can also be added to the Planet WordPress feed, so post titles also appear in the WordPress News Widget in the WP Admin Dashboard.
This initiative requires cross-team collaboration among contributors from the Documentation, Core (core-css, core-js, core-editor etc.), Training, and Support teams.
These teams could use an existing WP Slack channel for synchronous meetings, such as #docs or #core. During the meeting, team reps and other contributors can make editorial suggestions for topics and links that could be included in the next edition of an update post.
An editorial calendar can be an early agenda item for the meetings.
After the initial start-up phase, the blog would be extended to regular topical posts relevant to developers.
Possible Ideas for Future Expansion
Summaries from GitHub Discussions
Excerpts from meeting discussions for distribution to a wider audience of developers
A post consisting of a summary of multiple dev updates
Useful questions/solutions found on StackOverflow/StackExchange
Reviews of existing documentation to identify gaps
A possible future expansion would include a regular revision process to update content with new information and changelog recording.
I recommend that contributors to this initiative comply with the Make Core Post and Comment Guidelines. Should the editorial group decide to also include highlights of example plugins or themes, all products must adhere to the Community Team’s guidelines regarding GPL compliance of the products, including premium products.
As mentioned above, these are just some initial steps to get processes and contributors in place. Reader comments and discussion in the Slack channel will surface opportunities for further enhancements.
What do you think?How could this proposal be improved? Please share your comments, your thoughts, and content ideas. If you’d like to contribute to the Developer News, mention this also in the comments. The comment period on this proposal will end on March 18, 2022.
Props to Dion Hulse (@dd32), Destiny Fox Kanno (@piyopiyofox), Tara King (@sparklinerobots), Anne McCarthy (@annezazu), Tonya Mork (@hellofromtonya), Daisy Olsen (@daisyo), Dan Soschin (@dansoschin), and Anjana Vasan (@anjanavasan) for fruitful collaborating on this proposal. Props to Mary Baum (@marybaum) and Jean-Baptist Audras (@audrasjb) for final review
@annezazu announced a call for testing that revisits the headers workflow, which has changed a fair bit since the original call. Note also that her announcement marks the return of the project’s usual calls for testing in the FSE Outreach Program.
The first Gutenberg Developer Hours was a great success! Huge thank you to Tammie, Fabian, and Nick! 86.7% of survey takers rated it as Excellent. All 15 responders would place their recommendation into the likely half with 80% rating it a 10 (very likely)
These answers to open questions stood out:
What did you like:
Interesting topics, knowledgeable participants
Conversation. The different points of view.
Best practices, expert advice, very relevant to work we’re doing
What didn’t you like:
Too Short
Probably a challenge to have different experience levels at once, but that was well handled.
If any of these Meetups should have been recorded of the dozen or more I’ve attended, it was this one. The live transcript is very valuable, and its absence a noteworthy lack of planning.
When there are many topics, it becomes a bit too diluted, and it felt like maybe not everything was said before continuing to the next question.
How did you hear about the event?
53% Meetup
33% Gutenberg Times
13% Make Blog
6% Twitter
6% WPVIP
Below are topic suggestions for more Social Learning spaces.
Based on your feedback, the producers have already enabled live captions for future events. They will record the sessions, too, so you can revisit them or catch up if you have to miss one. FOMO is real.
Here are the details.
Of 38 participants, 15 filled out the survey
What did you like about the event?
Direct and honest interaction with those in the know
Best practices, expert advice, very relevant to work we’re doing
The knowledge of the panel members. So much info!
Knowledge of the panel and their easy-to-understand explanations
My question was answered after I joined, I was quite late in joining and I was worried my question might already have been covered, but you waited till I joined and I’m very thankful you did. And of course it was great to get my question answered by several of the people in the meeting, and I also got a very useful link from Fabian which was great.
The panelists were the most knowledgeable group thus far on the Social Learning Meetups. Fabian and Nick were excellent.
The way the three panelists answered the questions.
Experts opinions
I got lots of links and advice on gutenberg
Interesting topics, knowledgeable participants
Conversation. The different points of view.
Discussion on Block-based themes.
Knowledgeable answers to questions. Good links. Good chat comments.
Learning new things about block themes.
All doubts were cleared
What did you dislike about the event?
It would be nice to have more questions & participation
I loved the event
too short! Not clear where the copied code is pasted when Nick said to “copy and paste.”
Not recorded so that we can go back and review information presented
I was late in joining so I didn’t get the full experience, but I think it might be good if future events can be recorded in case anyone misses it, or in case people who did view it live wish to watch some of it again.
If any of these Meetups should have been recorded of the dozen or more I’ve attended, it was this one. The live transcript is very valuable and its absence a noteworthy lack of planning.
Not really a dislike, for the first installment it was a great event. I think I’d prefer to have the Developer Hours be focused on a specific topic, so either block development, block theme development, or specific new functions, for example template locking.
Recording not available but it’s been discussed and hopefully from next Meetup
too short
When there are many topics, it becomes a bit too diluted and it felt like maybe not everything was said before continuing to the next question.
Nothing to report here.
Timing (just kidding :D)
Nothing I disliked. Probably a challenge to have different experience levels at once, but that was well handled.
Nothing in particular. Not a Zoom fan.
Nothing 🙂
How did you hear about this event?
Email from Meetup
from Brett Harris at VIP
email from Meetup (I go to other WP social meetups)
meetup notice of upcoming events
Gutenberg Times newsletter
I’ve been a member of the Meetup group since it started.
Twitter / Make Blog
Searching Gutenberg meet-ups
WordPress meetup
On WordPress.org and from Birgit
Gutenberg times, podcasts, meetup
From wp.org
Gutenberg Times
Your newsletter.
Through meetup.com
What topics should we cover in future Gutenberg Developer Hours?
I halfway answered this in the “what did you dislike” question, continuing from there:
For these, maybe some demo time would be nice, so one of the panelists can explain things via screen sharing and then attendees can ask questions around that topic.
So like best practices, how to work with theme.json, what part of the theme.json has which effect in the editor, block development (static vs dynamic blocks).
In general I’d like to see some deeper going content, however I believe that squeezing this into one hour will be quite challenging.
Creating custom Gutenberg blocks
More gutenberg
I think it may help if the topics were limited to maybe 3?
Developer centric topics and case studies of unique site
FSE related topics
Multiple Answers:
How to monitor tracking issues.
How to find up-to-date information on plugin development (much is very old, every course and book seems out of date).
How to get the most out of reading the Gutenberg code. Ryan Welcher seems to be almost the only regularly updated source of current developer-level info, so this is an underserved area.
Gutenberg best practices.
Font loading in block themes.
Building child themes for block themes.
FSE theme best practices — color naming and style conventions.
The second event took place February 22, 2022. A recording is now available on YouTube and a follow-up post will be available next week. This time we didn’t close the event and 100 people registered of which 47 attended, 40% repeat participants.
Any plugin that requires another plugin (i.e., a dependency) is on its own to make sure admins install the dependency. After all, the plugin will not work without it. But with more than 55,000 plugins in the repository, that means there are potentially 55,000 plugins capable of resolving the dependency.
It would be a lot simpler for users and admins, and plugin developers, if there were a consistent way to handle dependencies in Core. Among other things, that approach would entail a clear method of determining when a plugin needs a dependency and what that dependency is.
Improving the plugin experience.
There’s a whole category of plugins that are designed from the ground up to add new abilities to other plugins. Think of shipping and other add-ons for commerce plugins, and one-click checkout for event plugins that sell tickets.
The situation there is a lot like the relationship between parent and child themes. Without their relationships to the bigger plugin, those dependent plugins can do very little. As noted above, every plugin developer is on their own to code a solution to resolve the issue. And, as noted above, the single most common example is WooCommerce, which is a dependency for hundreds, if not thousands, of WooCommerce add-on plugins.
What’s more, this is not a new problem. Across the WordPress ecosystem, people have been looking at it for at least nine years—starting with #22316.
The original scope listed in #22136 was the following.
Plugins list WP.org slugs of their dependencies in their readme.txt, or perhaps better their plugin’s header.
When you go to install a plugin via the plugin directory UI in the admin area, the WP.org API returns a list of dependencies along with the data about the plugin being installed. WP would say like “these following dependencies will also be installed”. This means it’s seamless to the user — they install a plugin and the other plugin(s) that are needed get installed too.
No versioning support. It’s too complicated and what if one plugin wants an older version of a dependency than another plugin does? If your plugin is listing another as a dependency, then it’s your job to make sure it stays compatible with the latest version of the dependency. On the flip side, hopefully plugins that get listed as dependencies are made to be forwards and backwards compatible.
Probably not allowing the disabling of plugins that are dependencies while their dependents are active. This seems better than disabling the dependents when the dependency is disabled (“why did Foo get disabled? I only disabled Bar!”).
On plugin re-activation or on activation of a plugin uploaded via FTP, make sure it’s dependencies are already installed. If not, offer to install them. If installed but disabled, just enable them for the user.
The last bullet point implies automatic installation and/or activation, after previous discussions, it was thought this should be discouraged in the name of preventing a very jarring user experience.
Fundamentally there should be a simple, clear method for identifying and installing plugin dependencies. Any plugin that requires a dependency should degrade gracefully if that dependency is not present. This is the responsibility of the plugin developer.
Design/Discovery
There are hundreds of comments, ideas, and decisions that have been discussed on #22316 and on some of the PRs below. I will attempt to summarize.
This is not an attempt to create a plugin package manager.
This is not an attempt to integrate Composer into WordPress or use Composer.
The agreed upon interface is via a plugin header, Requires Plugins, containing a comma-separated list of plugin slugs.
The most agreed upon UI for notifying users of a missing dependency requirement is via an admin notice.
There is no attempt at version control. The current plugin version in the dot org repository will be used.
There is no automatic installation or activation of the dependent plugin.
If the dependency requirements are not met, the requiring plugin cannot be activated.
Dependencies outside of the dot org repository are not supported. Out of scope at this time.
This is only for plugin dependencies that are required not recommended.
Plugin dependencies for themes is out of scope at this time.
Current Suggested Solutions
There are currently two approaches to handling plugin dependencies.
Similarities
Both use a plugin header, Requires Plugins, that contains the plugin dependencies within a comma-separated list of dot org plugin slugs.
Both show the user an admin notice if there are plugin dependencies should be installed.
Users must actively install and activate the dependencies.
Users will find they cannot delete or deactivate installed and activated plugin dependencies without deleting or deactivating the plugin that requires the dependency.
Relevant messaging in the dependency plugin row of the plugins page. (Formatting differs between approaches)
Neither approach makes any attempt at dependency version control. Most recent version of dependency from dot org is used.
Differences
The differences in the two approaches are subtle, but they do exist.
A single admin notice alerts the user to unmet dependencies in any plugin. If multiple plugins have dependency problems, the notice compiles all the notices in one place. This notice persists until all dependencies have been installed.
Adds dependencies using a new view/tab/filter on the plugins-install.php page.
On the plugin card, shows which plugins require which dependencies.
Once a particular dependency is installed, shows a list of plugins that require it at the end of the plugin’s description in the plugin row.
Adds relevant messaging to the plugin’s description.
Automatically deactivates any plugin that has unmet dependencies and informs the user in an admin notice.
Lets the user deactivate or delete a dependency if the requiring plugin is not active.
Some of the screenshots below may be slightly outdated.
Screenshots from PR
When attempting to activate a plugin with unmet dependencies.Dependencies tab info
Further Discussion
Pertinent discussions about the best way to implement this are still needed. It doesn’t have to be one of the above approaches, but they are certainly starting points.
The weekly developers chat takes place in the Make WordPress core channel on Slack at 20:00 UTC every Wednesday. Everyone is welcome to follow along and take part.
Want to reassess the interest for this as a focus group
Please re-vote on the focus group spreadsheet here by adding/removing your WP.org username from the groups that you want to work on in Column D, Contributors wordpress.org username
Please only enter your name on two or fewer groups. If you’ve already voted and want to revise, remove your name from other areas.
@sergiomdgomes: Continued discussion around embeds and how we could avoid the performance impact some of the larger ones, like YouTube, through façades or other approaches in the context of blocks; welcome thoughts and feedback
@mitogh: Should we introduce composer and namespacing before the release to prevent naming conflicts? We do use prefix but it seems like a workaround and not a long-term solution.
@flixos90: No because that’s not established in core.
@mitogh: Agreed, but the majority of the code will change when transitioned into core anyway.
@flixos90: Yes, but will be easier to migrate and review if we stick to core conventions as much as possible.
@pbearne: Suggest that we work on taking care of some low-hanging fruit outside of the main focus areas
@tweetythierry: A prioritization exercise of those items would be helpful
@flixos90: Always okay to bring those up here and ask for feedback, but be sure that we’re paying the most attention to focus area items to keep them moving, since we decided that they were the most important. Let’s be conscious of the performance impact, especially.
@adamsilverstein: One idea would be to run a bug scrub for existing Trac issues tagged with performance as an ongoing effort
You must be logged in to post a comment.