The Meta team is responsible for maintaining and managing WordPress.org websites. Our work is mostly done on the meta trac. If you see a bug, file a ticket!
We’re currently working on these fine projects, with more in store.
Check out our handbook to learn how to get involved.
This ticket scrub will happen on Thursday, February 20, 2020 at 06:00 PM UTC in the #meta-wordcamp channel.
The focus is on Meta tickets with the WordCamp Site & Plugins component.
Comment below if there’s a specific ticket or topic you’d like to discuss.
+make.wordpress.org/community
The Meta team makes WordPress.org, provides support, and builds tools for use by all the contributor groups. If you want to help make WordPress.org better, sign up for updates from the Meta blog.
@tellyworth, @sergey, @valentinbora, @clorith, @poena
Facilitator: @tellyworth
Note taker: @valentinbora
Thursday, February 27, 2020 at 10:00 PM UTC (see all #meta meetings here)
@valentinbora mentioned he found it very gratifying to work on Meta due to changes potentially going live faster than with Core, and wanted to find out whether new contributors could be encouraged to consider joining the effort
@sergey shared an interesting WordPress.tv talk he liked on the topic
@tellyworth went on to say that the Meta dev environment is a bit difficult to set up and would like to see the barrier for entry lowered.
@valentinbora confirmed that was the case but not as difficult as it looked at first sight. He suggested simply improving the documentation first, while working on a more fully-blown means of local setup
@poena mentioned they had a theme triage earlier and the attendees didn’t know what the meta environment was or what the Meta team was responsible with
@valentinbora stressed out the goals to be lowering the barrier to entry and increasing motivation for new contributors to join
@tellyworth mentioned a decrease in the overall number of Meta tickets, which is commendable
@valentinbora raised awareness to #5017, #5018 and #5015 while emphasizing the last two to cause some friction in the migration process. See more details about it by checking the Summary for Docs Team Meeting: February 10, 2020
@valentinbora also mentioned #5008 and #5013 to be awaiting feedback from Design
@tellyworth emphasized the Support Forums as being the component with most open tickets and @valentinbora praised @clorith for the helpful Bug Scrub held recently
@clorith stressed the importance of defining a focus area ahead of time for a good scrub in order to avoid getting lost in details and opinions across some of the lengthier tickets
@clorith and @tellyworth agreed that an approach where we’d ask a committer to quickly review and close a well-defined set of tickets would make a lot of sense to improve delivery
CampTix is the plugin used on WordCamp.org sites to sell tickets to WordCamp events and manage attendee data. Since 2012, when it was first built, it has also been distributed as a standalone plugin in the WordPress.org plugin directory.
WordCamp.org has always run the same CampTix code as that found in the plugin directory. A few months ago, however, it was necessary to add some functionality from other parts of the WordCamp codebase into CampTix. Copying that functionality into the standalone plugin would have created confusing duplication on WordCamp sites, and added a lot of complexity to the update. Instead, CampTix was integrated into the WordCamp.org codebase itself, which essentially created a fork. Since then, the WordCamp version of CampTix has changed in ways that have not been ported back to the standalone version.
As of now, the standalone version of CampTix will no longer be distributed via the plugin directory, and its original GitHub repo has been switched to “archive” mode.
Show full postWhy stop supporting the standalone plugin?
Supporting the standalone plugin takes away from the time available to develop and maintain tools for WordPress community organizers. Maintaining two versions of the plugin doesn’t seem like a wise use of the limited dev resources available.
How will WordCamps sell tickets now?
Sites on WordCamp.org still use CampTix. It is part of the codebase now, rather than an external plugin.
I found a ticket-related bug on a WordCamp site. Where do I report it?
You can open an issue on the WordCamp.org GitHub repo.
On WordCamp sites, the session times have been saved as a unix timestamp in UTC, regardless of the site’s timezone. We’ll be fixing this across all WordCamp sites, but this requires changing the session time for all sessions on all sites to include the timezone offset. This should not affect organizers or attendees, but anyone using the timestamp directly from the API will see a change.
You can see how we’re fixing this on GitHub, and if you have any input, please leave a reply. There was also some discussion on slack.
We were saving timestamps as if they were in UTC, regardless of the site’s timezone, which lead to technically-incorrect timestamps.
For example, if you have a site in EST, and you save a session for March 1st at 4pm, it will actually save it as “March 1st 2020 16:00 UTC”, which is not actually when that talk is. In most places this has been fine, because php’s date also assumed UTC, but as of WordPress 5.3, we have timezone-aware date functions. Additionally, these timestamps are causing headaches for using these values outside of PHP, like in JavaScript (for gutenberg) or 3rd parties developing apps.
If you’re an organizer, attendee, or someone else who just uses the WordCamp sites, no 👍🏻
If you have an app that uses the WordCamp REST API to get session info (including the time), you might need to update your code.
For apps using the the v1 endpoint still, ex wp-json/posts/?type=wcb_session, the legacy timestamp will still be returned (but please update to v2 😉).
For the current endpoints (ex wp-json/wp/v2/sessions), the meta._wcpt_session_time value will now be the correct timestamp. If you’re manually calculating a timezone offset to display the “right” time, you can remove that code. If you can’t change right away, add ?wc_session_utc=true to your requests, and it will return the legacy timestamp.
I want to run the script to convert these times next week (Feb 12th), Feb 18th and these values will change immediately. You can add the legacy query to your request now, and it will not do anything until the change is made.
+make.wordpress.org/community
So, it was saving the wrong timestamp because of incorrect time zone assumptions and this is correcting it to be the correct UTC time? If so, I approve. Best to get everything on the same page. 👍
yeah, exactly 🙂
Thank you, @ryelle!
This ticket scrub will happen on Thursday, February 6, 2020 at 07:00 PM UTC in the #meta-wordcamp channel. Note this is one hour later than our normal time.
The focus is on Meta tickets with the WordCamp Site & Plugins component.
Comment below if there’s a specific ticket or topic you’d like to discuss.
+make.wordpress.org/community
I’ll try to attend and discuss the approach on #333
This ticket scrub will happen on Thursday, January 16, 2020 at 06:00 PM UTC in the #meta-wordcamp channel.
The focus is on Meta tickets with the WordCamp Site & Plugins component.
Comment below if there’s a specific ticket or topic you’d like to discuss.
+make.wordpress.org/community
@valentinbora This is great! Thanks.