Wayback Machine
«MAR APR MAY »
Previous capture 8 Next capture
2019 2020 2021 »
0 captures
31 Oct 19 - 28 Oct 22
Close Minimize Help
Skip to toolbar

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 meeting is every Wednesday at 20:00 UTC in the #core channel on Slack. Anyone can join and participate or listen in!

#5-4, #field-guide

Make WordPress Core

Keyboard Shortcuts | Hide comment threads

WordPress 5.4 Field Guide

WordPress 5.4 is shaping up to be the best WordPress 2020 has seen!

As a user, you’ll see new blocks and enhancements in the block editor, new embeds, and improvements in the WordPress Admin experience.

As a developer, you’ll see 122 enhancements and feature requests, 210 bug fixes, and more! Of course, all those improvements mean code changes, which could in turn require you to make updates to your site, plugin, or theme.

So take a look through this Field Guide, and see what’s relevant to you and your users, among the many improvements coming in 5.4…

Accessibility

On the 14 updates related to Accessibility in 5.4, you’ll want to particularly note changes to the WordPress Admin Bar, to the calendar and recent comments widgets, on the Menu screen, and bugs reported by the WPCampus accessibility report.

Block Editor

The block editor has continued its rapid iteration since WordPress 5.0. Now it has Gutenberg version 7.5 bundled with WordPress 5.4; that’s ten releases all bundled into WordPress 5.4 (versions 6.66.76.86.97.07.17.27.37.4  and 7.5)! Bug fixes and performance improvements from Gutenberg versions 7.6 will also be part of 5.4.

The WordPress 5.4 Beta 1 post highlights a lot of new features and improvements across these releases, though you’ll also want to note the impressive achievement of 14% loading-time reduction and 51% time-to-type reduction (for a particularly long post of ~36,000 words, ~1,000 blocks) since WordPress 5.3.

Below you’ll find details on two new blocks, button component updates, block collections, default fullscreen mode for new installs/devices, custom keyboard shortcuts, general block editor API updates, new block variations API, a new gradient theme API, markup and style-related changes, and a new @wordpress/create-block package for block scaffolding.

Customizer

On the 14 updates of the Customizer component, WordPress 5.4 improves accessibility of focused elements as a follow-up to WordPress 5.3 Admin CSS changes, adds documentation of existing Customizer functions and hooks, removes apple-touch-icon-precomposed deprecated meta tags, and improves Menu items selection logic.

Please note that some unused Customizer classes are now formally deprecated:

Menus

On the 5 updates in the Menus component, WordPress 5.4 improves keyboard accessibility of the Menu items selection tab panel and streamlines the user interface.

If your plugins add custom fields to menu items, you’ll want to update your code to use the new wp_nav_menu_item_custom_fields hook:

Privacy

On the 15 updates in the Privacy component, you will want to specifically note:

  • Personal Data Export now includes Session Tokens, Community Events Location and Custom User Meta.
  • Personal Data Exports now include a JSON file and a Table of Contents
  • New filters for the headers of all Privacy-related emails
  • The privacy tables are improved for a cleaner interface
  • wp_get_user_request_data() function was replaced with wp_get_user_request() for better clarity

All those changes are in this dev note:

REST API

On the 22 updates related to the REST API, WordPress 5.4 now supports “OR” taxonomy relation parameter in Post Controller, adds selective link embedding and introduces some changes in the WP_REST_Server method. Read below for more details on these updates:

Shortcodes

On the 3 updates to the Shortcodes component, WordPress 5.4 introduces documentation improvements and a new function: apply_shortcodes. This function is an alias of do_shortcode, which is still supported.

Widgets

On the 9 updates to the Widgets component, WordPress 5.4 introduces accessibility and user interface enhancements on the Widgets Admin screen and changes in the Recent Comments and Calendar Widgets HTML markup.

Other Developer Updates

There are even more goodies in 5.4, like the new wp-env (a zero config tool for painless local WordPress environments), enhancements to favicon handling, better information about errors in wp_login_failed, a new site ID in multisite’s newblog_notify_siteadmin filter, a new TikTok video embed and removal of the CollegeHumor embed, storing the original URL of media attachments in _source_url post meta, improved accessibility by loading the Admin Bar with wp_body_open, avoiding duplicate IDs in the Recent Comments widget, a new parameter in the lostpassword_post action in retrieve_password(), theme headers supporting “Requires at least” and “Requires PHP” declarations, and the delete_posts capability won’t trigger PHP notices for custom post types. Read through the dev notes below to see details on all these changes coming in 5.4.

But Wait, There is More!

Over 198 bugs, 121 enhancements and feature requests, and 8 blessed tasks have been marked as fixed in WordPress 5.4. Some additional ones to highlight include:

  • Bootstrap/Load: Enhancement to favicon handling (#47398)
  • Bundled Theme: Twenty Twenty: Add social icon for WhatsApp (#49098)
  • Comments: Add “In response to …” before threaded comments in comment feed (#43429)
  • Comments: Add “in reply to” in comment moderation email notification (#43805)
  • Embeds: Embed support has been added for TikTok (#49083) (Gutenberg#19345)
  • Embeds: Removal of CollegeHumor embed as the service doesn’t exists anymore (#48696) (Gutenberg#18591)
  • Login and Registration: Clearer information about errors in wp_login_failed (#49007)
  • Login and Registration: new parameter passed into the lostpassword_post action in retrieve_password() (#38334)
  • Networks and Sites: Site ID has been added to the newblog_notify_siteadmin filter for multisite installs (#48554)
  • Networks and Sites: switch_to_blog() and restore_current_blog() reuse switch_blog action (#49265)
  • Media: store the original URL of the attachment in the _source_url post meta value (#48164)
  • Menus: Make tabs panels more accessible for keyboard users (#49211)
  • Posts, Post Types: Use delete_posts without triggering PHP notices in every post type (#30991)
  • Post Thumbnails: Make sure get_post_thumbnail_id() returns an integer, to match the documented return value (#40096)
  • REST API: Expose all theme supports and changed permissions in /themes endpoint (#49037)
  • Site Health: Theme headers support “Requires at least” and “Requires PHP” declarations (#44592)
  • Toolbar: The Admin Bar is now loaded with wp_body_open when available (#47053)
  • Widgets: Avoid duplicate IDs in Recent Comments (#46747)

Please, test your code. Fixing issues helps you and helps millions of WordPress sites.

Props to @jeffpaul and @marybaum for contributing to this guide.

#5-4, #field-guide

JavaScript Chat Summary: April 7, 2020

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.

Consent API

(Slack conversation)

Context: http://wayback.fauppsala.se:80/wayback/20200408152750/https://github.com/rlankhorst/wp-consent-level-api/issues/50

Feature Proposal: http://wayback.fauppsala.se:80/wayback/20200408152750/https://make.wordpress.org/core/2020/04/01/feature-plugin-proposal-wp-consent-api/

Discussion: What is the ideal JavaScript interface for accessing, updating, and responding to changes in consent? In what ways could we leverage the existing data module?

Discussion Points:

  • Is data module supported on sites running Classic Editor plugin? Is it otherwise tied to the block editor?
    • While it is developed in the Gutenberg repository, it’s intended to be general-purpose to support a variety of use-cases.
    • For example, WooCommerce plugin is using the data module outside of the editor context.
  • A primary value of the data module is API consistency in retrieving and updating data.
  • There is a need to support expiration as part of the requirements of the Consent API.
    • @nerrad has done some experimentation around this and would be happy to help contribute to the discussion.
  • @youknowriad shared a code example for how a basic consent implementation could be achieved using the data module.
  • There could still be abstractions on top of the data module.
    • For example, the blocks module uses the data module internally, but still exposes its public API as wp.blocks.registerBlockType, etc.
    • Ideally these would still follow the convention of groupings under the wp global (wp.consent).
  • Another advantage of the data API is that it provides future-proofing if blocks or future UIs are built with the Consent API in mind.
  • There’s a general desire to develop new APIs as following consistent and established patterns.
  • There may need to be enhancements to the data module in order for it to be most useful:
    • Subscribing to changes in a specific store value is currently cumbersome.
    • Expiration.
    • Persistent storage using cookies.
      • The current data module or persistence implementation can support this, but it may still need further enhancements so as not to break expectations that preferences may still need to save to localStorage for the near future.

#core-js, #javascript

Thanks for hosting us @aduth it was really interesting to understand how the wp.data module can be leveraged for additional uses in core and plugins.

Editor Chat Agenda: Wednesday 8 April, 2020

Note taker and facilitator: @itsjusteileen

This is the agenda for the weekly editor chat scheduled for Wednesday, 8 April, 2020, 10:00 AM EDT / 2:00 PM UTC

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

Gutenberg 7.9 Update
Planning for WordPress 5.4.1
Monthly Plan & Weekly Priorities
Task Coordination
Open Floor
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, #editor-chat

Task coordination: working on Navigation Block-related tasks, I realised that currently submenus in that block are almost unusable on mobile devices. I have created a PR: 21471 to fix them.

A potential talking point: There seems to be a lot of (potential) crossover between Global Styles and Theme/Block Color Palettes. Is this something there’s been discussion about?

A couple of issue/PR’s could use some attention.
The Embeds issue and PR could use some feedback. http://wayback.fauppsala.se:80/wayback/20200408152750/https://github.com/WordPress/gutenberg/issues/21029
http://wayback.fauppsala.se:80/wayback/20200408152750/https://github.com/WordPress/gutenberg/pull/17413

This PR from the new contributor Kiril Zhelyazkov could use a code review.
“Scheduled posts display the correct url.”
http://wayback.fauppsala.se:80/wayback/20200408152750/https://github.com/WordPress/gutenberg/pull/21410

Btw
I also want to mention that a lot of ideas have been shared in regards to improving Drag & Drop. http://wayback.fauppsala.se:80/wayback/20200408152750/https://github.com/WordPress/gutenberg/issues/21391

XML Sitemaps Meeting: April 6th, 2020

Meeting Recap: March 24th & 31st

For reference, check out the previous blog post from March 24th:

Things that have been discussed in the last two meetings:

  • Plugin Conflicts (#146)
    We discussed the rewrite rules conflicts that might currently happen with certain plugins. A consensus hasn’t been reached so far, but it could actually be declared a non-issue: if plugin A overrides the default sitemap functionality, that might be intended behavior.
    Current status: needs decision.
  • Rewrite Rules (#147)
    A change was proposed to improve the way rewrite rules are registered for sitemaps. This would avoid having to flush rewrite rules when custom providers are added.
    Current status: needs contributors.
  • Last modified date (#145)
    The PR to remove all traces of lastmod has been updated to include documentation.
    Current status: needs reviews.
  • Filterable query args
    #137 has been closed in anticipation of an improved solution to filter query arguments.
    Current status: needs PR.
  • Private sites (#138)
    Current status: PR needs some work
  • Roadmap
    WordPress 5.5 is ought to be released in August. We need to continue working on the feature plugin so we have something merge-able in May or June. The tentative roadmap would be:
    • Fix remaining big issues – April
    • Refactor code to be closer to WP core standards, add safeguards so nothing breaks after merge – April
    • Publish Merge proposal – May

Agenda: April 6th

The next meeting will be held on Tuesday, April 7, 2020 at 03:00 PM UTC.

Today’s agenda is rather straightforward so far:

  • Plugin conflicts
  • Last modified date (#145)
  • Road towards WordPress 5.5
  • Currently open issues and pull requests
  • Open floor

Want to add anything to the above? Please leave a comment here or reach out on Slack.

This meeting is held in the #core-sitemaps channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #feature-plugins, #feature-projects, #xml-sitemaps

JavaScript Chat Summary: March 31, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript). Many thanks to @cbravobernal for compiling these notes!

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

TypeScript Types from Packages

(Slack conversation)

WordPress packages will now ship with their own first-party TypeScript types!

Pull request: http://wayback.fauppsala.se:80/wayback/20200408152750/https://github.com/WordPress/gutenberg/pull/18942

The types (declaration files) will be published with the packages, so folks using the packages via npm will have access without doing anything else.

The type generation is built into the existing package build/publish flow, so things should remain largely the same from the perspective of Gutenberg development (hopefully with better information in our IDEs!)

npm run build:package-types is the script that generates them.

Awesome job! Kudos!

Action:

JSX support for wordpress/scripts

(Slack conversation)

Link to the issue

PR proposing it for formatting command.

There is a small discussion about seeing if it is necessary to discourage or not jsx files. Noticing that changes to accept jsx are quite simple. And are even accepted in some code already. There are different opinions, so the team prefer to continue the discussion.

Action: 

Open Floor

Updating Jest Error

@gziolo had issues upgrading Jest with the last version. See pull request. Asks if is it a good reason to refactor them to use the React Testing Library?

@aduth comments that is Enzyme related issue. That expects a DOM to exist.

Airbnb transferred the project to the community. Seems that everyone is going to switch away from Enzyme.

Also they comment that Jest, Babel and Puppeteer should be upgraded, and would be nice to have some strategya arount all that. The project seems to have too many dependencies.

Action:

  • No action defined.

News Roundup

This roundup contains a few links for Gutenberg and JavaScript related news curated (and commented on) by @nerrad.

#core-js, #javascript

Auto-updates feature weekly meeting agenda – April 7th, 2020

Next meeting is scheduled on Tuesday, April 7, 2020 at 06:00 PM UTC and will take place on #core-auto-updates Slack channel with the following agenda:

  • Version 0.5 scope and timeline
  • Homework: @pbiron asked attendees to think about how can we avoid conflicts with third party plugins
  • Discussion/decision concerning AJAX handling in the Feature Plugin
  • Discussion about the labels used for enabling/disabling auto-updates
  • Daylight Saving Time: should we move the meeting time?

See you tomorrow!

#agenda, #auto-update, #feature-plugins, #feature-projects, #feature-autoupdates

It would be great to have some design folks join the chat so we can discuss the labels used for enabling/disabling auto updates.

Good point, thanks!
It’s on the agenda

5.4 Retrospective – Call for feedback

WordPress 5.4 “Adderley” was released on March 31, 2020.

In order to prepare a retrospective post, I would like to ask everyone to leave some comments below with things they would like to bring up. To help, here are some questions to ask yourself:

  • What should WordPress start doing as a part of the development process?
  • What should WordPress stop doing as a part of the development process?
  • What should WordPress continue doing as a part of the development process?

Please note that I am looking for feedback specifically on the development and release process.

Please share your thoughts in the comments below! 

If you rather not give your feedback in a public space, please reach out to me (@francina) or @davidbaumwald, in Slack. We are available to collect your feedback in a safe space, with no judgement and use it in the retrospective in an anonymous form.

Remember when commenting to keep the discussion professional and focused on ways the process of creating WordPress is either already working great or can be improved.

#5-4, #retrospective

Create a content creator testing group. Not folks who are devs and designers (much respect for those folks but they have different gifts and perspectives) but folks who are daily content creators. Let us get in there and play around before it goes live.

I appreciate the design team reaching out on Twitter for some poles and opinions, but there’s nothing that matches getting your hands on it.

Hi Laura,

You can install the WordPress Beta Tester plugin on a local site and do content creation testing at any time before a release is made.

If you have any questions about how to use that plugin, feel free to open a Support Topic.

In this version I saw more tickets about bugs addressed and fixed since 5.0.
So I think that we should continue on review tickets with patches about bugs.
I got as I can remember 3-4 personal patches approved and this was very thrilling because this doesn’t happen usually.
I hope that in the future here is more attention about bug fixing and not only adding new features (adding new hooks for me is a bug fixing).
Another thing we have to continue is doing the refactoring of wordpress and improving the coding standard.

For me stopping the actual release cycle like every 2-3 months that is very few for who maintain a lot of websites, especially if there are so many new features to test.

CSS Chat Summary: 2nd April 2020

Full meeting transcript on Slack: http://wayback.fauppsala.se:80/wayback/20200408152750/https://wordpress.slack.com/archives/CQ7V4966Q/p1585861240051700

I (@isabel_brison) facilitated the meeting. 

CSS audit updates

  • @notlaura tested Parker, a stylesheet analysis tool, with results documented here.
  • @joyously suggested CSS Stats as another potential tool.
  • The a11y team had a look at the audit tickets at their weekly meeting and had a few recommendations.
  • Based on a11y team feedback, we agreed to add notes to the audit on any CSS properties we find that are unhelpful for accessibility.

Open Floor

@joyously requested we add a channel topic to #core-css, with the time of our weekly meeting, which we did.

@joyously asked if the audit would include editor CSS, or only wp-admin pages. The current audit includes only wp-admin pages, but there was agreement on auditing both the editor and the default themes CSS at a later stage.

That was all for this week!

Next week @notlaura will be taking over the running of this meeting, due to daylight savings changes.

#summary

Showing Online WordCamps in the Events Widget

TLDR: Should online WordCamps be added to the Events widget? If so, who should they be shown to?


Background

Many WordCamps are transitioning from in-person events to online events, due to COVID-19.

At the moment, those events don’t show up in the News & Events widget on the dashboard, because they don’t have a physical location. The widget was originally designed to show the user local events, because cultivating local, in-person bonds is an essential element of our community’s success.

Online events aren’t being intentionally kept out of the widget; it’s just an unforeseen side-effect of the temporary shift to online events. Online meetup events still appear in the widget, because in the absence of an explicit event location, the Meetup.com API falls back to the location of the group.

Questions

  1. Should online WordCamps show up in the widget?
  2. If so, who should they be shown to? Here are a few potential criteria:
    • The same people who would have seen the in-person event. i.e., anyone within a 400km radius of the venue.
    • Everyone within the same country. Would this apply equally to countries that host a small number of camps, and those that host a large number? Would it apply equally to countries that often see people from neighboring countries traveling to attend the event, and to countries where that is not common?
    • Everyone within an increased radius, e.g., 600km. If so, what would be the best distance?
    • Everyone within the same timezone, plus-or-minus a few hours.
    • Everyone who speaks the same language — or locale? — as the host city.
    • A combination of the above? Some other criteria entirely?
  3. Should the timezone and/or language of the event be displayed in the dashboard?

+make.wordpress.org/community/
+make.wordpress.org/meta/

#events-news-widget, #meetups, #online-events, #wordcamps

In an ideal world, I’d say community-wide, so long as platforms we’re leveraging can handle a global audience.

However, even if the platform can, this can flood the chat with a ton of comments and questions. If the event is a replacement for a geolocation, I’d want that community to have the opportunity to interact with presenters and not have their local community event taken over.

I’d lean towards keeping the event feed to the current distance, even if attendance is open to all. Eventually all content will make it’s way to WP.tv, so this is really about creating community experiences that are valuable to specific locales — the whole community will have access eventually.

Yes, online WordCamps should appear in the widget to the same people who would have seen the in-person event. i.e., anyone within a 400km radius of the venue.

The same people who would have seen the in-person event

Yeah, this. Until online-only events become the new normal, this is a fine first step, and any further transitions to different idea can be done later, if necessary or appropriate.

Yes, they should show in the Events Widget.

The same people who would have seen the in-person event. i.e., anyone within a 400km radius of the venue.

This is the obvious choice, it should be using the “Host City” as the location to base it off, the same as meetups currently.

Everyone within the same country. Would this apply equally to countries that host a small number of camps, and those that host a large number?

This is what I want to see happen however. It doesn’t make much sense in the USA, but in countries where there’s a smaller number of events (But that are not contained within the 100/400km radius for physical events) I’d like to see online events shown to that entire country. The 400km limit should still apply so that a city just inside a border would advertise to it’s neighbours, but an online event in the North of a country should be shown in the south 600km away when that country has a low density of events.
That would effectively make events National events rather than Local events, but given online transcends borders, a city hosting an online WordCamp is really representing that country.

I agree with everything here except for “a city hosting an online WordCamp is really representing that country.” I have a philosophical quibble with that, but it’s probably due to me living in the US. 😉

@dd32 Are you suggesting that, other than in the US, we should make all online WordCamps visible to everyone in a certain country and/or a 400km radius of the local community organizing the event? And then for the US & Canada, do you suggest showing online WordCamps by timezone and location? Or just location?

Your understanding is correct! 🙂 And yes, I agree that an individual City doesn’t represent a country of 300+ million, but if they’re the only event in that country at the time, then they effectively will be for an online audience. I could see that being the case with online WordCamps being more country-centric than city-centric just by nature.

In retrospect, 400km covers the size of most countries, except US/CA/AU/India/Brazil/African countries and a handful of others.
Using your wording:

other than in the US, we should make all online WordCamps visible to everyone in a certain country and/or a 400km radius of the local community organizing the event?

For US/CA, Depending on how many WordCamps are actually being held, timezone or a larger radius would work well I think, but I’d have to dig into the actual list of events.

In retrospect, 400km covers the size of most countries, except US/CA/AU/India/Brazil/African countries and a handful of others.

I did actually come up with a list of many countries where a 400km radius is not enough if we see the cities where their WordCamps are usually happening. Just for the EU, I quickly counted Finland, Sweden, Norway, UK, Germany, France, Italy, Spain, Poland, and Ukraine…

And I know that organizers in at least of three of those countries have talked about organizing the virtual countrywide virtual event.

After looking at these countries where 400km radius isn’t enough, I actually start leaning towards the same timezone and locale approach. The wider radius of 600km wouldn’t be enough for some countries listed.

Another vote for “The same people who would have seen the in-person event. i.e., anyone within a 400km radius of the venue.”

Coming out of this, at least most of these same groups will transition back to in-person events. So it makes sense to use online events to strengthen relationships and community within the group, even if technically anyone could attend.

I understand the value of maintaining the local community feel of these online events. And, I think there’s a chance that maintaining the current radius criteria will mean that a lot of places, especially that are less densely populated and/or have fewer meetup groups, won’t see any events in the widget at all.

I pulled some numbers from WP’s Meetup Pro account, and compared the number of events per group in the chapter program between this year and last year. March 2020’s events per group is 45% lower than March 2019. April will probably be even lower. My takeaway from this is that there are already many places that are “WP meetup deserts” because the local communities don’t have the resources/time/desire to run an online event.

For these places, seeing an upcoming online WordCamp in the dashboard that is in their language and near their timezone would be really valuable. Watching recordings on WP.tv later doesn’t fully replace being able to interact with folks in real time, especially now when everyone is physically and socially isolated.

If part of our goal here is equity, and we want to make sure that everyone in the global WP community has access to community events, I think we should change the criteria.

That’s a very interesting number, Corey, thanks! I wonder how many groups will “bounce back” with online meetup events in May and afterwards.

I like Corey’s idea of showing online WordCamps based on language and adjacent time zone very much. Not sure how we’d implement the language part, but I think it’s a good idea.

🤔, I think that’s a good point, but I also wonder how confident we can be about that assumption, and what the long-term impacts are of weakening the local relationships that smaller events build. I don’t see county-wide events forming the same kinds of bonds that local events do.

It seems possible to me that organizers are adjusting to the shock, and we may see a significant portion of those numbers return once everyone adjusts.

It’s also possible that organizing an online event might be more accessible to some people who’d like to organize, but haven’t been able to in the past.

One of my favorite parts about the widget is that, if there aren’t any events in your area, it shows you a message encouraging you to start one. Sometimes you have to let a problem be noticed so that people will step up to solve it.

I do share you worry about event deserts, though. It’ll definitely be important to keep an eye on those numbers, thanks for thinking of that.

I don’t see county-wide events forming the same kinds of bonds that local events do.

That’s partially true, but many communities have started using Slack which does help with maintaining bonds even tho those might not be as strong as the ones formed in local events.

What I’ve seen, countrywide events can be very inspiring to attendees coming from an area that doesn’t have WordPress events and might set a spark to start organizing events. For new hesitant organizers, it’s encouraging to get to know with other organizers in same country before starting a new event. For example; in Finland, many local meetup groups have started after WordCamp’s gathering attendees from the whole country. Coming to what I try to say; online events can also be the starting point to many new local communities and events after the current situation is in the past.

That’s a fair point.

It may also be more accurate to look at attendance numbers rather than event numbers, since it sounds like some groups are combining events with other cities in their region/county.

Hello, I’m Rocío, deputy of the Global Community Team and mentor of WCEU and many Spanish speaking WordCamps in Latinoamerica and Spain 🙂

Should online WordCamps show up in the widget?

Yes!

If so, who should they be shown to? Here are a few potential criteria:

Short answer: Let our users choose what they want to attend! 🙂

Long answer: With this new situation, many organizers around the globe are joining forces and organizing online events for anyone who wants to join. We have several cases where our communities are joining by their native language: WordCamp Spain Online, the German WP event: WPconf.net, the Centroamerica community organizing online Meetups every week from a different country/local community, for Spanish speakers…

1) This is a unique and temporary opportunity to create stronger bonds across communities around the world by uniting them around WordPress! We can better support this by removing limits around visibility of the events.

2) Organically, most people tend to attend any WP event that happens in their native language or in a second one that they can speak fluently.

3) I’d not filter the visibility of the event by timezone because the availability of our attendees can vary depending their personal situations, for example, many people are working in the morning and would not attend an online event in the morning, but would be happy to attend an online event in “the other side” of the world because it’s in their evening and they can do it during their free time.

4) There are only four scheduled Virtual WordCamps in 2020 at this time: 2 in the US, 1 in Spain and WCEU Online. It’s not that we’re going to overwhelm our users with so many online events, let’s show them the next online events and let’s let them choose!

Let’s help to spread WP knowledge without any borders! 🙂

****My proposal****

1) (My favourite): Show in the widget all next Online WordCamps (right now it’s only four!)

2) If you think the proposal above is “too much”, let’s add a selector, so users can choose between two options:

  • “Show me all next Online WordCamps”
  • “Show me next Online WordCamps in my languages” (they can choose 2 languages)

Btw, are we looking solutions on API level or something that would need Core changes?

Related question: is the amount of events shown limited by API or Core?

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
:)