The ticketing and organization tool for WordCamps has become outdated after several years without changes, prompting a proposal for its update.
Remember that you can listen to this program from Pocket Casts, Spotify, and Apple Podcasts or subscribe to the feed directly.
Program transcript
Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community.
In this episode, you’ll find the information from June 9th to 15th, 2025.
One of the pillars supporting the organization of WordCamp events throughout the years has been CampTix, the ticketing management system that has enabled organizers around the world to plan and run events efficiently. However, as the expectations of both organizing teams and attendees evolve, this system is beginning to show its limitations. Current tools, although functional, aren’t fully aligned with modern needs for usability, analytics, and control. And this leads us to a necessary reflection: how can we improve the WordCamp experience through the technology that supports it?
The challenge is clear: CampTix requires structural revision that not only fixes minor issues but transforms it into a truly useful and modern tool. Organizers demand more valuable statistics, better control over tickets, and clearer purchase flows. Attendees, on their part, need simpler processes and options to manage their own tickets without involving third parties. All of this is exacerbated by the lack of active maintenance for the system and the learning curve for those wanting to contribute to its development.
Facing this scenario, an open proposal has been launched by the WordPress Community team to prioritize improvements to CampTix. Specific ideas are suggested: better integration of data for analytics, redesigning the purchasing process, facilitating refunds, and allowing more autonomy for attendees. Modernizing currency management and optimizing the use of discount codes are also recommended. This proposal is not just technical, but organizational too: it involves actively listening to those who use the tool daily and collaboratively creating a roadmap.
The next steps will be decisive. A process is open to collect ideas through comments on the official blog and in the #meta-wordcamp Slack channel. From there, tasks will be prioritized based on impact and feasibility, inviting developers, designers, and organizers to join this joint effort. Because improving CampTix isn’t just a matter of code—it’s about investing in the community experience that makes WordCamps unique.
In Gutenberg 21.0, an option was added to select the HTML element for the Button and Separator blocks, allowing users to choose between <a> or <button> for buttons and <hr> or <div> for separators from the Advanced panel, improving accessibility and semantic control of content. Additionally, there was an extensive refactoring of the ToolsPanel that unifies the configuration interface for multiple blocks—including Button, Embed, File, List, Navigation, Post Title, and RSS—providing a more consistent and orderly editing experience.
Accessibility and usability were enhanced with improved keyboard navigation and focus management on key blocks such as Button, Columns, and Details, ensuring a smoother workflow for users relying on assistive technologies. Numerous bugs related to block controls, gallery captions, and internationalization of social links were also addressed, reducing interruptions and improving the overall stability of the editor.
During the Core team’s committers meeting at WCEU 2025, several key topics for the future of WordPress development were discussed. One main area was improving the onboarding experience for new contributors, with proposals such as clearer documentation, active support channels, and mentorship. It was also suggested that committers take a more active role as reviewers, not merely as code mergers.
Additionally, there was discussion about optimizing the release cycle, including possibly working with feature branches to ease review of significant changes and improving planning to avoid rushing before the feature freeze. Lastly, emphasis was placed on maintaining a focus on core maintenance, including enhancements to automated testing, better management of Trac tickets, and cross-team collaboration, particularly with documentation and accessibility.
The AI team is already exploring clear ways to indicate when content has been AI-generated or assisted, focusing on transparency for users and editors. One key proposal is to include a visual notice or signal that distinguishes this content within the WordPress editor without interfering with the reading experience. It’s also suggested to provide a straightforward way for users to review and confirm generated content, explicitly noting human intervention as part of the editorial process.
Additionally, discussions were held about using tags (metadata) within content to register AI-tool usage, and potentially adding an interface that informs users if content was generated or modified with AI assistance. Other proposals include exploring how these systems can integrate into the block editor workflow—not to automate editorial decisions but to help propose improvements or drafts.
The group agreed to continue these efforts along three fronts:
- Prototyping visual elements (notices, tags, blocks) to identify AI-generated content.
- Technical exploration on storing AI usage metadata without impacting performance or compatibility.
- Open discussion to define prioritized use cases (writing assistants, automatic summaries, revision support, etc.).
The Playground team introduced a new SQLite driver for WordPress, designed to integrate more natively with the system and facilitate development environments, testing, and local use without relying on MySQL or MariaDB servers. Unlike previous implementations, this driver leverages the database driver architecture introduced in WordPress 6.4 and is fully compatible with core abstractions, avoiding invasive modifications to the codebase.
The main objective is to provide a coherent and functional experience with SQLite from the outset, opening new possibilities for tools like Playground, educational environments, rapid plugin or theme development, and automated testing. Although still experimental, the community is encouraged to test it, report bugs, and contribute to its evolution, with the intention that it officially becomes part of the WordPress ecosystem in the future.
The Accessibility team wants to kick off the Accessibility Documentation project, involving the transfer of existing accessibility documentation to the WPAccessibility repository on GitHub. The goal is to keep up-to-date information on how to design, develop, and test to meet accessibility standards in WordPress.
An open process of contribution and review, managed by the accessibility team, was outlined, with practical examples, clear guidelines of dos and don’ts, and a dedicated section showcasing accessible code examples for developers, making it easier for the community to contribute and ensuring quality and compliance with AA standards.
The timeline includes project setup and initial content transfer from June to August 2025, followed by rewriting, restructuring, and establishing a review system during September and October. Then, from November onwards, documentation will be maintained, contributions reviewed and merged, and more people invited to collaborate, with bi-weekly progress reports published on the accessibility blog.
And finally, this podcast is distributed under a Creative Commons license as a derivative version of the podcast in Spanish; you can find all the links for more information, and the podcast in other languages, at WPpodcast .org.
Thanks for listening, and until the next episode!
Leave a Reply