Should Support Threads Auto-Close After 6 Months?’s support forums are a vital resource and communication tool for users supporting their own sites and developers extending the software. Visiting the forums often means users have gotten stuck somehow and need to have a successful support experience in order to continue on their WordPress journeys. They are looking for help deciphering the meaning of error messages, migrating sites, debugging their sites after an update, and many other common struggles of self-hosting.

A ticket on Meta trac, which was opened three weeks ago, proposes that remove auto-closure from support forum threads and instead add a warning that the thread is old. Threads currently auto-close six months after last reply, unless manually closed sooner than that.

Amber Hinds, plugin author and CEO of Equalize Digital, made a case for instances where it is necessary to respond to an old thread:

  • As a plugin dev, we forgot to subscribe to a plugin’s forum and only saw support threads many months later. Currently, there is no way to provide assistance on these threads.
  • If a user requests a feature that is not currently available and you release it many months later, it would be nice to update their support request and let them know.

Hinds referenced a conversation on Post Status’ Slack where Matt Mullenweg recommended removing the closure for old threads completely and adding a warning in its place:

Let’s move away from auto-closing to just having a warning that you’re replying to an old thread

Not all participants in the discussion are in favor of leaving support tickets open. Several contributors contended that this approach can lead to unproductive replies piling up or multiple people jumping in on threads with similar unrelated issues, making it difficult for developers to solve the original request.

“Old topics mostly attract spam, me-too-pile’ons and random replies,
its very rare when an actual reply is needed to something that has no activity for six months,” WordPress support forums moderator Yui said.

“Current policy is to leave such topics closed, however, making an exclusion and manually reopen it at request can be made possible when the reasons for it are compelling (It can be discussed on Support team weekly chat, if needed).”

WordPress accessibility contributor Joe Dolson is in favor of giving plugin authors the ability to determine when a thread gets closed, a modification that partially addresses the issues at play.

“It would help alleviate it to give plugin authors the ability to close a thread,” Dolson said. “Though when you have thousands of open support threads, that would still be a pretty significant potential burden.

“I think there should be a better way of handling closed support threads – it’s a problem that auto-closed threads literally *cannot* be re-opened because they’ll just auto-close again. But I’m dubious about just leaving them open.

“At the least, I think that removing the auto-closing *must* come with some ability for plugin authors to close threads; otherwise this would become totally unmanageable.”

Changing thread closure policy could also impact the metric displayed on plugins, indicating how many issues have been marked as resolved in the last two months. If more people are allowed to jump in on threads with them open, the resolved threads metric may not be as meaningful.

Hinds recommends a hybrid approach, keeping auto-close in place but allowing plugin contributors to reopen threads, restarting the clock for auto-closure.

“I discovered 12 support tickets yesterday on a plugin I had not realized we were not subscribed to, which I want to at least comment on to see if they still need help,” Hinds said. “I can’t do this. It’s a frustrating experience for me and clearly a poor user experience for the original poster or anyone else who encounters that thread with a similar problem.

“Another option might be to auto-close them but add a button that allows them to be reopened by plugin contributors that sets another six-month (or maybe a shorter time period) timeline before auto-close.”

It’s easy to forget that most people do have a vast network of WordPress professionals available to answer questions for them on Twitter or other networks, so the forums remain an important lifeline for users. Contributors have not yet come to a decision about whether leaving threads open for longer will provide a better experience or not. The discussion on changing the auto-close policy continues on Meta trac.


5 responses to “Should Support Threads Auto-Close After 6 Months?”

  1. As mentioned in the post, there’s definitely a need to respond to older threads. And I think over time, the more people comment on a thread, it helps quantify the problem for many plugin authors.

    To me, I think it’s more important to have this conversation about Plugin Reviews becoming dated very quickly. Humans can leave low reviews because of a specific issue. But even after the plugin author fixes the issue, the review stays. This can lead to an unfair view, in my opinion.

    It would be great to have a review flag for the author to say the problem has been fixed. Or in the very least, attribute the plugin version number to the review if possible. Right now it’s only the date, but what if the user is somehow running an outdated plugin and leaving a review about a problem that’s already been fixed. It’s a tangled road.

  2. As a plugin developer, I feel that the support forums are geared toward WordPress’s software itself, but individual plugin forums that assume the same features are cumbersome to work with, to say the least.

    The auto-closing of support threads, the inability to tag and quickly sort the topics, the lack of moderation tools, being dependent on ambivalent moderators, and the auto-deindexation of old threads for which I spent hours researching are frustrating.

    I hope we can someday close the plugin forums and redirect the support button to GitHub Discussions — or, at least, borrow their features.

  3. As a user, those old posts can be helpful when I am looking to solve an issue, but I can see why auto-closing is important for developers—there is no need for me to be able to add to the post, I can start a new one and cite the old one if that seems useful. The ability for the developer to reopen an old post makes sense, but I am sure that it is the exception, rather than the rule, so I would not change auto-closing, just give developers a way to override as needed.

  4. I’d like to see a “re-open” this thread button. I think that’s a good idea, but I’d also leave that to the person who wants to post something new, as well. As a plugin developer, it’s going to be hard for me to decide which thread to re-open. Might as well give that right to the user and the right to close a thread and suggest to open a new thread to the plugin developer, who can then close threads after a year, if they so choose.

  5. Two quick clarifications:

    Currently support forum threads auto-close after 6 months, not a year.

    The auto-closure to replies is different from marking the thread as “resolved,” which impacts plugin ranking. – a plugin contributor or thread starter can mark threads as resolved and it does not stop people from replying to them or close them to comments. A thread can also be marked as resolved at any time, even after the comments are closed. This is something that perhaps is not intended, but plugin dev’s can change the resolved status at any time – it’s a dropdown separate from the comments form.

    In my case, on the plugin that I had failed to subscribe to and could not reply to the 12 support threads, all were “unresolved” which hurt the plugin’s ranking. I ended up going through and marking them all as resolved, because I don’t think the plugin should be permanently lower in search because of something that is no longer an issue (me not getting notified of the threads). It might be gaming the system a bit, but since dot org doesn’t allow me to actually help the original posters, it’s the best I could do for the plugin.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: