Over the past year, I’ve been thinking of ways to improve how companies, agencies, and open source developers in general tackle support on WordPress.org, and over the past few months, I’ve been building something to improve just that.

The problem

WordPress.org is a community, and support is provided both by those who publish plugins and themes there, but also by the broader userbase. This makes it very important to provide a hybrid solution that allows the forums to remain community driven forums, but still provide extenders flexibility beyond what a forum can provide.

This kind of flexibility would be things like gathering private information, leaving notes for their colleagues, proper filtering to discover topics that still need support (WordPress.org has a few custom views here, but far from the flexibility that one needs).

And of course, well-oiled machinery need some data to also ensure they have the right people on at the right time.

These are for the most part elements that do not lend them selves naturally to a forum-focused endeavour.

The solution (hopefully)

So with this knowledge in mind, and a decent understanding of the WordPress.org ecosystem in general, I set out to build a solution to this, I had a few key criteria in mind:

• WordPress.org is free, the data this system builds on is freely available, so users should also have access to it for free (more on that later).
• It should bridge the gap between commercial ticket needs, and community needs, by presenting everything in a ticket-fashion, but interacting in a forum way under the hood.
• It should foster my own belief that good support comes from treating each other as individuals having a conversation and finding a solution together

And that’s how I came up with my new support platform; WP Support Hub; A one stop place to monitor, sort, interact with, and analyze, your support needs.

Technical approaches

As many of those wanting to build tools for, or aimed at, WordPress.org will know, there are not a lot of opportunities for integrations, that means that the entire setup is a combination of clever scraping mechanics, triggering in various fashions and at various times.

By default, all scraping interactions are done in a way that would let WordPress.org’s caches roll at full capacity, think “anonymous user reading a topic they found from a search result”, which they check up on every so often (the older the topic, the longer they wait before they check if someone has posted a new reply, up until they are automatically closed by the forums, and there’s no longer a need to look for new updates).

There are some notable exceptions to this though, for example the forums offer a field labeled “The site I need help with”, which is only available to signed in users, or if there’s a need to get all historic data for a plugin or theme, where an anonymous user is limited to just the first 50 pages of topics (that’s 50 pages, times 30 topics per page, so still a lot, but some of y’all have been around for many years, and have amassed hundreds of pages… I apologize to the WordPress.org systems team in advance 🙏). These two scenarios introduce a very interesting hurdle, and means you need a logged in session to both look at the topic to fetch the page URL, but also to be able to paginate beyond page 50.

To do this as elegantly as possible, I chose to perform anonymous scraping initially, if I detect that there’s no URL stored in the system for a topic, but the topic has one, an authenticated session is instead triggered to fetch that page.

The same happens for paginated results, I create a new authenticated request to fetch the link to all the topics on a page, followed by anonymously checking each of those topics, and once that range of 30 has been checked, the system will check the next page for topics. Of course once it knows what topics exist, it’ll stop as soon as it recognizes a topic (this is thanks to the forums listing topics chronologically, and not by last reply, which was a change introduced in the migration to bbPress 2.x).

In keeping it free

As I mentioned, the data is free, I am freely using WordPress.org to populate the service with crucial data, so it should be freely available to users. This is great, but there’s obviously an operational cost involved in this as well, so some of the features that require more processing on my end are locked behind a subscription.

I will, however, pledge here and now, that if the service generates revenue, that a percentage of that will be given back to the foundation for resources used.

What this means is that anyone can sign up for free, they will get asked if they would like to join the WordPress.org Organization, alongside their own desired organization (they can of course decline this, but I wish to encourage others to help support the plugins and themes developed by the WordPress community), but some functionality won’t be visible to them at all.

So what did I lock down?

I’ve tried to approach this in a way where any feature crucial to providing reliable support is always free to all, this means you can monitor as many plugins or themes as you’d like (take note that the Terms of Service dictates you should only be adding your own plugins or themes, if not your account may be terminated, because that’s a lot of unnecessary additional processing 💸), filtering of incoming tickets (yes, I called forum topics for tickets in the system to cater to a more professional market), requesting private details and notes.

I even included one piece of statistical reporting too; The ability to get a report of who has been responding to users and helping them out in your plugins or themes, to help you identify your ambassadors, and maybe even future hires.

But what do those that pay get, if the important base features are there already? I’m glad you asked! I am in part hoping that those with the means to pay for services, see the value both in what they get for free, what is provided to the community, but also in the features that are locked behind that paywall;

• Review monitoring (watch for new reviews to respond to, but also see historical data when a review has been updated, and see in which direction a review change is taking you)
• Slack notifications (don’t rely on RSS feed or email subscriptions, get notified via a Slack Webhook)
• The ability to import historical data (by default, only the 30 latest topics, and any new ones created after this, are added to the system when a new plugin or theme is added for monitoring)
• The ability to increase the frequency in which checks for new requests are performed within a given window (great if you are planning a release, and want to stay on top of things)
• The ability to invite other users to your organization (got a support team? Awesome, invite them all!)
• And more stats;
  • View ticket trends for ticket resolutions
  • Monitor how long you usually need to resolve a request
  • Monitor which days, and times of days, see more or less requests being created (or maybe even check how the dates surrounding a release got affected)

What more?

Well, time will tell. Those who know me know that support is one of my passions, and anything that will help companies, or volunteers, provide better support is on the table moving forward, obviously this is something I am doing on my own time, and its operation relies a fair bit on users taking advantage of the paid portion of my service to cover the cost of operation, and potential expansion into further tools as part of it going forward.

Hopefully this little blog post does a better job at explaining the concept than my attempt at a landing-page on the actual service it self 😅

But yeah, go check it out https://wp-support-hub.com – Made with ❤ for all the wonderful people doing WordPress support.