Wayback Machine
«JUL AUG SEP »
Previous capture 18 Next capture
«2020 2021 2022 »
0 captures
31 Oct 19 - 28 Oct 22
Close Minimize Help

WordPress.org

Welcome!

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:

Communication

We use Slack for real-time communication. Contributors live all over the world, so there are discussions happening at all hours of the day.

Our core development meetings are every Wednesday at 20:00 UTC in the #core channel on Slack. Anyone can join and participate or listen in!

Make WordPress Core

Keyboard Shortcuts | Hide comment threads
Dan Farrow 8:53 am on August 18, 2021

CSS Chat Summary: 12 August 2021

The meeting took place here on Slack. @notlaura facilitated and @danfarrow wrote up these notes.

CSS Custom Properties (#49930)

1
2
3
4
5
6
7
--wp-admin--theme--primary--step-10: #1a5686;
--wp-admin--theme--notification: #d63638;
--wp-admin--theme--notification--contrast: #fff;
--wp-admin--theme--success: #00a32a;
--wp-admin--theme--info: #72aee6;
--wp-admin--theme--warning: #dba617;
--wp-admin--theme--error: var(--wp-admin--theme--notification);
  • @robertg asked a question about where new custom properties should be defined. @ryelle answered that they should be in custom-properties.css, in the body selector so that they can be overridden by colour themes later

How should box-shadows be handled?

Working time

  • @notlaura started the 20 minute session where contributors can work on the project while having help available in the Slack channel
  • @robertg asked if the :hover and :focus pseudo-classes should have separate custom-properties. @ryelle answered that one custom-property can be defined for --hover and also used for :focus
  • @wazeter asked about the timeline. @notlaura replied that for the 5.9 release we would be aiming for the end of August. @ryelle clarified that this is the target for “early“ consideration. We’ll know the target for the completed project when the real cutoff has been announced but she expects it to be around early-mid October
  • @notlaura added that next week’s meeting (August 18) is the last scheduled week for working time
  • @wazeter asked where questions about quirks should be addressed. @notlaura replied post in the #core-css channel or comment in the PR
  • @robertg asked if we are just targetting color, background-color, and border-colors for now. @notlaura added box-shadow, noting that this will need some additional discussion

CSS Link Share / Open Floor

Thanks everyone!

#summary

Sander 12:41 pm on August 18, 2021

Unfortunately we can’t consider HSL as an option at this stage

Can you clarify why not, for those of us who don’t have access to Slack? hsla is supported in all browsers, even IE9

Dan Farrow 1:04 pm on August 18, 2021

Sure! I asked about switching to hsla in a chat last year and @youknowriad posted the following response:

HSL works but it would force us to have an API based on HSL colors, we want to have a more generic API where users just define a single variable no matter which format.

And @ryelle posted this response in last week’s chat:

we probably won’t switch to HSL palettes because the color palate we have is already defined – if we switched to an algorithmically defined-HSL we would be introducing a whole new color set.

Paal Joachim Romdahl 7:45 am on August 18, 2021

Editor Chat Agenda: 18 August 2021

Facilitator and notetaker: @itsjusteileen

This is the agenda for the weekly editor chat scheduled for Wednesday, August 18, 2021, 04:00 PM GMT+1.

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

If you are not able to attend the meeting, you are encouraged to share anything relevant for the discussion:

  • If you have anything to share for the Task Coordination section, please leave it as a comment on this post.
  • If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#agenda, #core-editor, #core-editor-agenda, #meeting

Francesca Marano 7:32 am on August 18, 2021

Dev Chat Agenda for August 18, 2021

Here is the agenda for this week’s developer meeting to occur at Wednesday, August 18, 2021 at 08:00 PM UTC.

Blog Post Highlights

Bringing to your attention some interesting reads and some call for feedback and/or volunteers

Components check-in and status updates

  • Check-in with each component for status updates.
  • Poll for components that need assistance.

Open Floor

Do you have something to propose for the agenda, or a specific item relevant to the usual agenda items above?

Please leave a comment, and say whether or not you’ll be in the chat, so the group can either give you the floor or bring up your topic for you accordingly.

This meeting happens in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #core, #dev-chat

David Ryan 1:04 am on August 18, 2021

CSS Chat Agenda: August 19, 2021

The next weekly CSS meeting is Thursday, August 19 at 21:00PM UTC in the #core-css channel in Making WordPress Slack.

CSS Custom Properties (#49930)

Focused on substituting existing colors throughout Core stylesheets, the CSS Custom Properties project aims to make working with Admin Themes & Admin Color Schemes easier and more reliable both in Core and Plugins.

The #core-css team is looking for contributors interested in adopting a stylesheet (a process outlined here).

No prior contributing experience is required — we’re happy to assist anyone who would like to participate!

Meeting Agenda

  • Welcome (21:00PM UTC)
  • Announcements & Housekeeping
  • CSS Custom Properties (#49930)
    • Overview
    • How to Get Involved
    • Status Check-In & Blockers
  • Open Floor
  • Working & Collaboration Time
  • Huddle Up & Closing Discussion (21:50PM UTC)
  • CSS Link Share (Bring neat examples & helpful tools!)

#agenda

Francesca Marano 6:57 pm on August 17, 2021

Upgrade/Install Meeting Notes, August 17

On August 17, the Upgrade/Install component met to discuss the proof of concept that builds on the rollback update failure plugin to prepare it to merge in Core. Slack logs.

In the post and during the meetings a number of concerns and potential improvements were mentioned, so here are the next steps:

  1. @aristath will write steps for manual testing, in time for the next Test scrub (Friday, August 20).
  2. @francina will liaise with the Test Team and Hosting Team (aka cross post 😇) so the PR can be tested.
  3. @sergeybiryukov will do the code review once there is a good amount* of testing.

The conversation led to other two topics

  1. Unit tests for the updater classes. They don’t exist. Should they exist? Yes. But it’s a big task and it needs a dedicated initiative. Let’s take one step at a time.
  2. #51928 is independent from the auto-updates/failures/rollback items, but closely related. As @pbironmentioned, failure data can give information about areas in the updater that could use more error checking/recovery logic, etc. The results are anonymous and seen only by the .org system folks.

If you have input on any of the above, please leave a comment – here or on the relevant PR/Tickets.

Thanks!

#core-auto-updates, #updater, #upgrade-install

Jb Audras 6:57 am on August 17, 2021

A Week in Core – August 16, 2021

Welcome back to a new issue of Week in Core. Let’s take a look at what changed on Trac between August 9 and August 16, 2021.

  • 33 commits
  • 31 contributors
  • 43 tickets created
  • 5 tickets reopened
  • 37 tickets closed

Pending the appointment of the WordPress 5.9 team, a number of tickets have been fixed, waiting for the next minor release(s).

Ticket numbers are based on the Trac timeline for the period above. The following is a summary of commits, organized by component and/or focus.

Code changes

Build/Test Tools

  • Add schema reference to PHPUnit config files – #53363
  • Declare two TestCase classes as abstract – #53363
  • Enable running the tests on PHP 8.1 – #53891, #53635
  • Hard deprecate WP_UnitTestCase_Base::checkRequirements() – #46149
  • Hard deprecate WP_UnitTestCase_Base::checkRequirements() – #46149
  • Make the polyfills loading more flexible – #46149
  • Remove Unicode character from PHPUnit version check message – #53363
  • Revert [51602] for now to investigate test failures on PHPUnit < 7.0 – #46149
  • Simplify the PHPUnit test workflow – #53891
  • Add unit tests for the wp_nonce_ays() function – #53882
  • Fix failing i18n unit tests for block metadata – Follow up for #53238
  • Rename classes in phpunit/tests/formatting/ per the naming conventions – #53363
  • Use correct comparison in do_enclose() tests – #53635

Code Modernization

  • Check the return type of _get_cron_array() in wp_schedule_event() – #53635
  • Check the return type of parse_url() in WP::parse_request() – #53635
  • Correct handling of null in wp_parse_str() – #53635
  • Rename the readonly() function to wp_readonly() – #53858
  • Replace strftime() and gmstrftime() usage in unit tests – #53897
  • Silence the deprecation warning for missing return type in phpunit/tests/compat.php – #53635

Documentation

  • Add a @see reference to the wp_mail_content_type filter in wp_staticize_emoji_for_email() – #53399
  • Add a @see reference to the xmlrpc_enabled filter in wp_xmlrpc_server::set_is_enabled() – #53399
  • Correct @since version for the wp_parse_str filter – #53399
  • Fix typo in the get_block_editor_settings() description – #53922
  • Improve documentation for a few functions per the documentation standards – #53399
  • Synchronize documentation for wp_get_attachment_image_attributes filter callbacks in bundled themes – #53878

Editor

  • Preserve the original template keys when preparing a list of page templates – #53898
  • Add support for variations in block.json file – #53238

General

  • Restore (un-deprecate) the sanitize_url() function – #53876

Themes

  • Make sure the theme API response is not an error before operating on it in themes_api() – #53913
  • Twenty Seventeen: Add support for wa.me links in Social Links menu – #51946
  • Twenty Twenty: Add support for wa.me links in Social menu – #50542

Upgrade/Install

  • Update sodium_compat to v1.17.0 – #53907
  • Use consistent capitalization for “web host” in setup messages – #53926

Props

Thanks to the 31 people who contributed to WordPress Core on Trac last week: @jrf (17), @SergeyBiryukov (7), @swissspidy (4), @hellofromTonya (4), @pbearne (3), @sabernhardt (3), @mukesh27 (3), @lucatume (2), @Ipstenu (1), @thomasplevy (1), @Toro_Unit (1), @aadilali (1), @Mamaduka (1), @jorgefilipecosta (1), @youknowriad (1), @ayeshrajans (1), @haosun (1), @jeherve (1), @desrosj (1), @schlessera (1), @gwwar (1), @pierlo (1), @ankitmaru (1), @bradparbs (1), @tmatsuur (1), @dkarfa (1), @carepsules (1), @macmanx (1), @pedromendonca (1), @iluy (1), and @knutsp (1).

Congrats and welcome to our 3 new contributors of the week! @aadilali, @carepsules, and @iluy ♥️

Core committers: @sergeybiryukov (31), and @gziolo (2).

#5-8-1, #5-9, #core, #week-in-core

Francesca Marano 8:53 am on August 16, 2021

Upgrade/Install component meeting agenda for August 17, 2021

The next meeting is scheduled on Tuesday, August 17, 2021 at 05:00 PM UTC and will take place on #core-auto-updates Slack channel.

The aim of the chat is to check the status of the rollback for failed plugin/theme updates and decide if it is ready for a merge proposal.

Got something to propose for the agenda? Please leave a comment below.

#core-auto-updates, #updater, #upgrade-install

Matias Ventura 4:50 pm on August 13, 2021

Preliminary Road to 5.9

This is a quick overview of the main areas and features currently underway for 5.9 in Gutenberg. Some are in more advanced stages than others, but together they paint a picture of what we are looking forwards to.

To dive deeper into concrete tasks and areas of work, this tracking issue is the best place to follow.

Blocks + intrinsic web design

Collection of various patterns displayed at mobile resolutions.
  • One of the biggest points of friction for pattern and theme builders are the lack of responsive tools available at a block level. This needs to be solved in a way that doesn’t disproportionally increase interface complexity.
  • The block model is a good case to apply some intrinsic design principles, since a block can occupy a place in many different layouts and containers, for which prescriptive media queries that don’t take context into account are inflexible.
  • Each block area should be intrinsically responsive allowing blocks to compose together, wrap, stack, and organize themselves to fit the different spaces and screens. For this to work well, container blocks need to absorb more layout controls. (Container queries might help expand this further in the future.)
  • Typography tools need to become more fluid and internally support algorithmic clamping. Whenever possible, patterns should just work and accommodate themselves.

Patterns

Mosaic galleries showing different design patterns.
  • With the initial rollout of the new directory there’s a growing need to expand the inserter integration to accommodate broader categories of patterns and the experience of browsing them.
  • There’s more work to be done within the setup flow of single and multi-block selections. This also includes improving the mechanisms for transforming to and from patterns, which are still nascent.
  • Creation flows with patterns also need expanding from template parts and blocks to pages and templates.

Navigation Menus

  • The navigation block and navigation screen projects have been underway for quite some time and are a main target for 5.9. With the principal tracking issue about to be completed, a large part of the remaining work is to improve the user experience, reduce complexity, and test as much as possible on themes.

An interface for theme.json.

Global Styles panel showing the main area and the background color section.
  • 5.8 introduced the scaffolding necessary for themes to take the reins over how various aspects of blocks render and how the interface is controlled. The natural next step ahead is to develop the user interface that will allow users to interact with these style properties. This goes by the project name “global styles” and an updated design is currently in prototype stage.
  • It should be appreciated how important it is to leverage the global reach of CSS rules as we combine it with the power of blocks. The current structure deals with two large groups of design targets: blocks and elements. Elements represent things that can be styled globally and across blocks (such as “text”, “links”, “captions”, etc).

Design Tools: Colors, Typography, Spacing, Layout

Series of panels showing different configurations of the typography tools.
  • The effort to bring better and more consistent design tools continues to progress. These tools need to integrate smoothly with both the block API (through the “supports” mechanism) and theme.json. One of the main goals is consistent access to similar tools across blocks, including third-party ones.
  • Running parallel to this effort comes the work on the WordPress components system, refinements to color tools, interactivity, accessibility, etc.

Formalize editing flows for block themes

Displays templates as small cards in a mosaic, connecting diagrams with the different flows.
  • A large percentage of the infrastructure and features needed to build block themes are established. The UX and design needs the most attention, though, starting by mapping into a clearer information architecture all the possible flows that are to be supported (editing templates, parts, styles, pages, etc).
  • Continue to process and take into the design process all the feedback gathered from users and theme builders.
  • Begin defining transition flows from existing widget areas to block areas when appropriate, and explore the various aspects of theme switching.
  • Finalize and commit all remaining blocks under the “theme” category.

#5-9, #gutenberg

Jon Brown 5:22 pm on August 13, 2021

Lack of responsive controls is by far my biggest frustration with core blocks (and why I almost never use them). I’ve been advocating for this being in the block API since the beginning, rather than encouraging the diversity of UIs to develop independently. It’s really a mess already with each block doing something a little different. FWIW, Ultimate Add-ons for Gutenberg does the best job I’ve seen of providing mobile responsive settings without being overwhelming.

In terms of Design Tools, one thing I’d also really like to see in core however is something like color palettes for typography. Give theme developers the ability to pre-define a dozen typography combinations. The free form “lets pick any font, size, color and style” by end users very quickly leads to absolutely disgusting looking sites.

I’m not advocating that things like typography always be locked down to a theme’s prescription, although obviously on well-managed sites that will often be needed. Average users ought to still have a path to overriding those pre-defined styles.

Matias Ventura 6:11 pm on August 13, 2021

It’s possible already for a theme to specify typography presets and restrict blocks to only choose among those (no custom font size, for example). Something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
"typography": {
    "customFontSize": false,
    "customLineHeight": false,
    "fontSizes": [
        {
            "slug": "normal",
            "size": 16,
            "name": "Normal"
        },
        {
            "slug": "big",
            "size": 32,
            "name": "Big"
        }
    ]
}

With theme.json it can even be done on a per block type basis, so you can allow custom font sizes for the site-title block but lock it down for others. More examples here: http://wayback.fauppsala.se:80/wayback/20210818144401/https://developer.wordpress.org/block-editor/how-to-guides/themes/theme-json/#settings-examples

Phil 9:57 am on August 15, 2021

Is it possible to disable the new navigation menu page for those that want to keep the current system at ‘Appearance > Menus’? Much like with the new widget editing page in 5.8 by setting the ‘use_widgets_block_editor’ filter to False.

annezazu 4:04 pm on August 16, 2021

@probablynotphil a filter is on the list to tackle before introducing this new editor to the world: http://wayback.fauppsala.se:80/wayback/20210818144401/https://github.com/WordPress/gutenberg/issues/24683 It will likely take a similar approach as you mentioned as widgets 🙂

deborah86 11:59 am on August 15, 2021

This update is not going to be that exciting because a lot of basic features are missing from core that the WordPress team refuses to address. The team just relies on plugins or complicated workarounds for features that should be included in core. It is 2021, not 2000. My biggest concerns are security, SEO, and ease of use.

1. Ability to sort items in the Media Library by Categories and Tags.

2. Basic SEO features
a. Meta Title and Descriptions for posts and pages
b. Ability to set links as no-follow
c. Ability to set pages, posts, and media files as no-index
d. 301 redirects
e. Ability to add structured data to pages and posts

3. Better ways to secure content.
a. The option to set pages, posts and media files to only be viewable by logged-in users. Requiring only logged-in users to access pages is more secure than using a password to protect pages and posts. A password can be shared by many people and there is no way to tell who shared the password.
b. Built-in ability to prevent image hotlinking.
c. The ability to restrict authors and contributors to view only and manage the files they upload to the Media Library

4. Easy way to delete orphaned plugin and theme files from the database. A deleted plugin or theme file database entries should not be allowed to stick around forever. Plugin and theme developers don’t always do a clean uninstall.

5. Improve the search for plugins and themes. The search is a nightmare.
a. I know WordPress likes to boast how many plugins and themes it has but it needs to remove plugins and themes that haven’t been updated in over 2 years. This opens new users up to security vulnerabilities.
b. Add better filters and tags.

6. WordPress needs to be new-user friendly like Wix, SquareSpace, etc. The average person should be able to use WordPress without having to hire a developer.
a. Many settings need better descriptors added to them
b. Make it easier for a user to get to the support for their theme or plugin through the WordPress dashboard by creating a new support section directly in WordPress Core
c. Only show plugins and themes compatible with the user’s version of WordPress unless they want to see everything so a new user does not download a plugin that might break their website.
d. Get rid of the Hello Dolly plugin on all new installs. It serves no practical purpose for creating a website. It is just extra unneeded code. I know there is sentimental value but if someone wants the plugin on their website, they can install it themselves.
e. Users should be able to create a website comparable to what is offered by Wix, Weebly, Squarespace, etc without the use of 10+ plugins. The transition from one of these websites to WordPress should be easy.

There is a lot more I can say on how WordPress needs to make big changes to improve its experience for users. Updating Gutenberg is great but WordPress Core needs major improvements also.

deborah86 6:45 pm on August 15, 2021

I forgot to add the option to disable right-click on embeded images.

indysigner 11:16 am on August 16, 2021

Amen to that, Deborah! So many core features that should be part of a CMS right from the start, that still are missing.

nimmolo 6:27 am on August 16, 2021

Amen @deborah86, the Core php code is in a woeful state of technical debt and leaderless drift.

You listed many user-facing improvements, and there are just as many developer-facing code improvements that need solutions IN CORE. I cannot believe this has gone on this long without real leadership from Automattic.

deborah86 12:48 pm on August 16, 2021

@nimmolo From what I understand Matt is the issue. Look at the state of Automattic’s products for reference. WooCommerce doesn’t even use Gutenberg even though Matt is pushing Gutenberg development in WordPress. Also, didn’t WooCommerce have two major security breaches this year?

WordPress will use resources to push CRT and woke politics rather than pushing the development of great code and tools for developers. There is always some long discussion on some social issue but there are no long discussions they open up to users or developers on how they can improve WordPress core. WordPress is a CMS and should stay out of politics period.

WordPress used to be an inexpensive way for someone to build a website, now it is the most expensive way to build a website. The line between themes and plugins has become blurred and themes with good designs are hard to find in the directory. All that is left is a bunch of themes with a ton of features but no quality design. The highest quality themes are those made by WordPress or Automatic but those theme developers refuse to update their themes with new features or fix the bugs in the themes. I reported bugs with the base themes. It is almost 3 months later and those bugs haven’t been addressed.

The majority of the features in the themes don’t work unless you upgrade to the premium version. So, to have a nice-looking website like the theme’s preview or to brand the theme, you need to install a premium version of the theme. Those themes are just like a trial of the main theme. The theme directory does not do a good job of separating premium themes from free themes.

Plugins in the plugin directory are mostly previews. Then you have to pay yearly to get the full features of the plugin plus you have to pay for basic support. The plugins that were free with robust features are outdated and not compatible with the latest version of WordPress. They seem to have been abandoned. The directory does not filter between premium plugins and free plugins. If you download a trial plugin, you are bombarded with ads to upgrade to the premium version. The only way to get rid of these ads is to download another plugin.

The WordPress core team relies too much on plugins rather than building a great CMS. Basic SEO features, security features, protecting your content, and simple functionality that will make WordPress beginner-friendly should not be plugins.

One of the biggest issues creators face with the websites is stolen content. In order to fix this issue, 2-3 plugins are needed with an annual cost of $300-$500 dollars. That is just to prevent someone from stealing your blog content and pictures and putting it up on their website.

There are a bunch of hidden costs with WordPress. The cost of a theme for about $40 – $100 a year just for a single website. Hosting can be about $10 a month. Then there is the cost of plugins for basic functionality. That ranges from about per plugin $100 – $300 a year for a single website.

To have a functioning website, a user might spend $500 to $1000 a year, That is way more than someone would spend with Wix, Weebly, SquareSpace, etc for the same features. Plus using those CMS you only have to deal with customer service from one company so you can get better and quicker help for your website.

It is no surprise WordPress is such a mess. If you see how Auttomattic’s business model is (high price, missing or charging more for basic features that similar products have, lack-luster support) you can understand why WordPress is in the predicament that it is in.

There is a lot more I can say about the handling of WordPress Core. I am sure a multitude of users believes the same way.

The Gutenberg team is great and they are dedicated to improving WordPress. I appreciate all the work they have done.

jtolleouw 2:56 pm on August 16, 2021

Some of these comments are ridiculous, and I hope they do not discourage you. But they do have a some points, and the WP teams should still try to see through their anger and pick out the important bits of what they are trying to say.

Thank you for your continued hard work on these products.

Lara Schenck 3:36 pm on August 12, 2021

CSS Chat Agenda: August 12, 2021

This is the agenda for the upcoming CSS meeting scheduled for Thursday August 21 at 21:00PM UTC. The meeting will be held in the #core-css channel in the Making WordPress Slack.

This week, we will be continuing with a supported working session for new contributors! Please see this post with our call for contributors and more details. Our agenda is as follows:

  • Welcome
  • Housekeeping
  • Discussion around the CSS Custom Properties project (#49930)
    • Brief Overview
    • How to Get Involved
  • Open Floor
  • Working Time
  • 21:50PM UTC – Circle back, closing discussion, CSS link share

#agenda, #core-css

s
search
c
compose new post
r
reply
e
edit
t
go to top
j
go to the next post or comment
k
go to the previous post or comment
o
toggle comment visibility
esc
cancel edit post or comment
0
:)