WPTracSearch: An Elasticsearch-Powered Search Interface for WordPress Trac Tickets
WordPress Trac is one of the more utilitarian and uninspiring interfaces that many contributors have to contend with in the process of giving back to the project. After growing tired of Trac’s mediocre search functionality, William Earnhardt set out to improve it with a new project called WPTracSearch that gave him an opportunity to play around with Elasticsearch and React.
WPTracSearch provides an alternative Elasticsearch-powered interface for searching WordPress Trac tickets. It performs a full text search of all of the fields, delivering more accurate results, even for basic queries, thanks to Elasticsearch’s relevance ranking. The results can be easily filtered based on milestone, component, focuses, usernames, and more criteria, making it easier to find specific tickets.
The search interface also supports fuzzy matching, adding to its ability to deliver more relevant results. Even if a term is misspelled (either in the search or the ticket) it will still yield results, as in the example below:
Earnhardt is a WordPress core contributor and a developer at Bluehost. His core team has the discretion to work on whatever they want for WordPress core and the community.
“This fit in nicely with that, but was also just something fun to tinker with,” he said. “It started as a fun experiment with Elasticsearch last fall. I built an index on my local machine and played around with it but got busy with other stuff pre-5.0 push and it sort of fell by the wayside.
“Then early this year I had a few times come up where it would have been helpful, so I threw together an interface for it and got it online.”
If you want to use WPTracSearch but are not sure how current the ticket index is, Earnhardt said it’s nearly constantly in sync:
There is a PHP script that parses all the information about a ticket in Trac using the XMLRPC api and puts it into an Elasticsearch index. There is a bash script that runs on a cron every minute to find any tickets updated since the last run and then uses the PHP script to reindex them. So it stays pretty constantly in sync.
The project uses a React interface that relies on the Reactivesearch library to query the Elasticsearch index. Earnhardt also borrowed some code from Ryan McCue’s Not Trac to help with some of the UI that deals with parsing TracLinks and code blocks.
WPTracSearch is an evolving project and Earnhardt has lots of plans for improving it. The two highest priority items on his roadmap are indexing meta Trac and making a search UI for it. He also wants to make the individual tickets have navigable URLs instead of being modal pop up windows when you click on the summary in the search results.
“I do it that way because it’s a lot faster to stay in this interface than jumping back and forth to core.trac.wordpress.org when browsing tickets, but you can’t link directly to a ticket and forward/back doesn’t work,” Earnhardt said.
“You can also query the Elasticsearch index directly without using the React interface if you know Elasticsearch Query DSL. This allows pretty complex queries to be built. I’ve thought about creating some charts using that. It could help with the core triage team effort to better understand churn and progress toward bringing that open ticket count down. There are a lot of cool possibilities.”
WPTracSearch is available on GitHub if anyone wants to contribute ideas or code to improve it.