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.
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), 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
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
Let’s try this “office hours” format again! Next week, we’ll have an open hour for anything WordCamp.org related. If you’ve got a ticket you’re working on, or a problem you need help with, drop in during this time 🙂
This will happen on Thursday, December 19, 2019 at 06:00 PM UTC in the #meta-wordcamp channel.
Comment below if there’s a specific ticket or topic you’d like to discuss.
As mentioned in this week’s meta meeting, the draft guidelines for plugins submitted to the Block Directory are available for discussion:
Your feedback and suggestions are welcome.
As a general update on the Block Directory status:
💖
Is there any discussion going on regarding the potential nightmare of external frontend dependencies that installing single blocks from a block directory will open up?
The last thing we need is more copies of fontawesome or select2 being enqueued…
That’s a great question. It’s something we’re aware of but don’t yet have a clear solution to. It’s likely that it needs to be tackled as a Gutenberg architectural problem. It doesn’t only affect single block plugins, it’s an issue for all blocks (and indeed themes and plugins in general).
I’m not sure I agree with the guidelines surrounding naming and promotional links/messages.
While it makes sense to require the downloaded block itself provide features that don’t need any payment, why would a link to learn more about additional premium features (sales of which can help the developer support the free version) not be allowed? For example on the bottom of the block’s settings output? Having guidelines around taking over other parts of the UI or not including any admin notices above the editor would make sense, though.
Also if blocks should be generically named “Image Grid” how would a user differentiate one image grid block from another in the block listing?
I agree with this.
As it stands, the intention of the guidelines appears to be to keep the size of the block directory as small as possible by removing any commercial interests from the table.
Would the WordPress plugin directory have been as vibrant as it is if these guidelines were applied there?
I think not, and I don’t really understand why there has to be such a different standard applied here.
From my understanding, the purpose of the block directory is to make it easy and seamless to create content. That’s why it’s built into the block editor itself as part of the flow. Otherwise, it could just be a section in the regular plugin directory.
To that effect, any upsells here are the definition of obtrusive. (Which @ericdaams is forbidden by the theme directory, and that one seems to be doing just fine). Something that’s prompting you to leave the creation process.
Maybe there’s room to concede an upsell link in the info box before installing it sure, and dashboard notification spam, albeit hated by users, should be allowed too imo. But let’s please leave the content creation flow distraction free. No need to clutter up the block settings (ps: for donation links too – please keep them off post-edit page).
Personally I’d rather an in-context, relevant link when managing the block versus having all my blocks spewing forth dashboard notifications. 🙂
I get that aggressive upselling sucks and is distracting. But why is offering more features related to the direct functionality of the block considered harmful?
Consider also that a block is purely client side, with the bare minimum of PHP scaffolding to set it up. That means that some functionality is effectively impossible to build into the block plugin itself. Why then not allow for the possibility of a single block plugin that does what it says it does, but can be coupled with a more feature-rich partner plugin that provides enhanced functionality?
Wouldn’t that be a win for users?
I totally hear ya – dashboard spam is (almost) the worst.
To be clear, it’s not the act of upselling that I think it’s harmful – it’s the act of trying to send someone out of their workflow.
If a user is creating a post – let them. That’s not the time to be trying to get them to leave the page to install something else (even more ardorous if it’s premium, and requires you visiting a website, paying, and then uploading the plugin, all just to get back to editing).
PS: perhaps I’m just not imaginative enough, but while I can picture a block paywalling some of its settings, I’m struggling to imagine a ‘more feature-rich partner plugin’ that would somehow be relevant to the user once they’re already in the block editor. If so, there’s no benefit to the user for it being advertised in Gutenberg vs the dashboard.
Again it comes down to the purpose of the block directory (and Gutenberg in general I guess): it’s there to make content creation easy and immediate. IMO anything that gets in the way of that (be it a clickbait block that requires you to ‘unlock’ it to do what you want it to, a recommended block for something you’re not trying to use and thus didn’t search the block directory, or an upsell link taking you out of the editing process) is not a win for users.
(Reminder: I’m pro upsells for block directory plugins, just not in the editor itself).
I’m looking ahead to when the primary method of creating and editing a website is via the block editor, both in the front end and the back end. Because that’s not yet the case there are other opportunities for themes and plugins to upsell elsewhere in the dashboard.
If there is a premium version of the same block with additional features, and those features would allow them to do what they’re looking to do (ie. additional design or filtering options for content), showing a link in the block setting itself seems relevant.
Ideally there would be a way for them to seamlessly purchase and install the premium supported plugin without leaving the flow but I think that’s a long way off 🙂
What would be the best way to get an edit in place to be a little more inclusive of at least a subtle upsell link within the block settings itself?
@brianhogg You can leave comments on the PR at http://wayback.fauppsala.se:80/wayback/20200211120414/https://github.com/WordPress/wporg-plugin-guidelines/pull/68
There has to be some sort of middle ground here. If the current number of block plugins is any indication, the number of people willing to make blocks is pretty small. If you take away any possibility of making money off blocks that small number will drop even further.
The community needs blocks and unless someone is going to pay developers to make and maintain free blocks they need to have a way to be compensated for their time. We’ve trained users to believe that anyone who tries to make them pay for themes or plugins is bad and I think that’s a mistake. Guidelines like this just reinforce that belief. Companies wouldn’t have to resort to “dashboard spam” if there was an easy way to ask for donations and users weren’t conditioned to believe that they are entitled to get everything for free.
If it was me I’d let people do whatever they want on the block properties tab just don’t let them put crap anywhere else and I think that would be fine. It wouldn’t interfere with the use of the block nor would be cause undue interference with WordPress in general. I think a better solution would be to build in a mechanism that made is easy to ask for donations and better yet trained users that if they find something useful and want to see it continue they really should donate to the developers.
A first version of the directory has to be very restrictive, in order to define the thing in a way which makes sense. The idea here is to build a subset of the plugin directory with a very specific purpose and a very different interface. So yes, commercial interests are definitely not welcome in version 1. This is an open source project, if you’re expecting to use freely provided community resources as advertising, you’re not going to be welcomed to the new thing.
That said, first version. Multiple block plugins are also not welcome. Because that’s way more complicated and you don’t build a project backwards. You have to work your way towards the goal, one step at a time.
As for your suggestion that we condition users to expect payment mechanisms… “free software”. I think you need to examine the implications of that phrase. We allow some types of upsell in plugins. “Allow” being the important word there. We don’t have to do that.
We’re trying something a little different this month– instead of a formal ticket scrub, we’ll just have an open hour for anything WordCamp.org related. If you’ve got a ticket you’re working on, or a problem you need help with, drop in during this time 🙂
This will happen on Thursday, November 21, 2019 at 06:00 PM UTC in the #meta-wordcamp channel.
Comment below if there’s a specific ticket or topic you’d like to discuss.
Edit: This post was published with the title “developer office hour”, but the chat is open to everyone, so it was renamed.
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 🙂
+make.wordpress.org/community