Welcome to the official blog for the WordPress Support team.
Need help with a WordPress issue? You can find help with your WordPress problem by posting in the support forums or asking on the #wordpress IRC channel.
Want to get involved?
Answering a question in the support forums or on IRC is one of the easiest ways to get started. Everyone knows the answer to something!
We have a detailed handbook to help contributors learn how to work with the forums and IRC.
Weekly Meetings
As well as discussing support issues here on the blog, we use Slack for group communication.
Our weekly meeting is held every Thursday 17:00 UTC, with the first meeting of the month being office hours, and the next will be at Thursday, 17:00 UTC(your time zone) in #forums on SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..
This is where news that are relevant or good to know for the team from across the community are brought up and shared.
WP 6.0 is coming
Oh, so many changes coming on the 24th (or so). Discuss.
The Rosetta Forums
This is the section where we reach out to the non-English speaking parts of our community, to see how they are doing, if there’s anything we can help each other with, or just interesting things going on that it would be nice to share with others.
There’s no requirements for previous participation or “fame” to share here, anyone is welcome, and we encourage newcomers to participate!
Unable to make the meeting, or maybe meetings just aren’t your thing? We would still love to hear how things are going in other non-English speaking parts of our community. Please feel free to let us know via the comment section below, in your own time, if there is anything you’d like to share, any questions or concerns you have, ort just to let us know you’re doing ok!
We will make a habit of putting this callout with every agenda post going forward, so that everyone has a chance to join in.
Open floor
This part of the meeting only happens if there is time, the team aims to cover the pre-planned topics first in any given meeting.
When open floor starts, any topic posted either as a comment to this agenda post will be looked at, or as many as there is time for. If there is still time left after this, then meeting attendees may step forward with questions, comments, remarks, anything relating to the support team that they’d like to handle.
It is also important to note that not everyone is comfortable posting things publicly, there is complete understanding of this, and users are welcome to contact the team representative (@sterndata) via direct messages on Slack with whatever they wish the team to look at together.
For any other items to discuss, please add them to the comments below, or bring them up in the meeting.
At the April 21 meeting, we discussed off forum support:
It may be just me, but it seems that there’s an increasing number of author/dev replies to support requests that send the OP directly to the author/dev’s website for support. This may be to get around asking for credentials, but in cases where it’s not, it also seems to me that it goes against the community aspect of support. The (often poorly formed) question is asked publicly and the solution is private. This does not help the community.
Overall, I worry about the forces pulling apart the community (like the MasterWP post suggesting wordcampWordCampWordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. speakers and orgainizers be paid). Support is a vital part of the glue holding together the community.
Should we always push back when an OP’s first reply is “please contact us via our website” or “fill out our contact form”?
It was noted that there’s a guideline at https://developer.wordpress.org/plugins/wordpress-org/using-the-forums/#you-may-request-users-open-tickets-on-your-own-system, but it’s more of a recommendation than a guideline.
It seems that we’ve chosen to encourage authors/developers to provide support in the forums. “Users still have an expectation that support will happen here, so if you’re not doing that, it’s in your best interest to stave on snarky users by documenting [this clearly in your readmes and pinned messages].”
Moderators will post encouragement messages when the dev/rep reply to the OP is immediately “Please contact us on [this private site].”
This led to a discussion of the “resolved” checkmark/status, which creates some anger among users. A scenario was proposed that there will only be two ways for someone to resolve topics:
you created the last reply and you are the OP
you created the last reply and you are the dev/rep
After a bit more back and forth, only OPs and the dev/rep (and mods) should be able to resolve or unresolve a topic at any time, but a resolved topic is a “closed” topic, allowing replies only from the OP or dev/rep. Wording above the reply box (or the closed to replies message) should indcate that the topic can be re-opened by un-resolving (if it’s within the time-to-close-topics window).
The full discussion is at https://wordpress.slack.com/archives/C02RQC6RW/p1650561045439379
Please reply here to discuss before we work this up as a metaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. ticket.
This is where news that are relevant or good to know for the team from across the community are brought up and shared.
WP 6.0 is coming
Oh, so many changes coming. Discuss.
Off-forum contact requests
It may be just me, but it seems that there’s an increasing number of author/dev replies to support requests that send the OP directly to the author/dev’s website for support. This may be to get around asking for credentials, but in cases where it’s not, it also seems to me that it goes against the community aspect of support. The (often poorly formed) question is asked publicly and the solution is private. This does not help the community.
Let’s talk about this and see if we can develop a consistent policy that makes sense to the support team, dev/authors, and users alike.
The Rosetta Forums
This is the section where we reach out to the non-English speaking parts of our community, to see how they are doing, if there’s anything we can help each other with, or just interesting things going on that it would be nice to share with others.
There’s no requirements for previous participation or “fame” to share here, anyone is welcome, and we encourage newcomers to participate!
Unable to make the meeting, or maybe meetings just aren’t your thing? We would still love to hear how things are going in other non-English speaking parts of our community. Please feel free to let us know via the comment section below, in your own time, if there is anything you’d like to share, any questions or concerns you have, ort just to let us know you’re doing ok!
We will make a habit of putting this callout with every agenda post going forward, so that everyone has a chance to join in.
Open floor
This part of the meeting only happens if there is time, the team aims to cover the pre-planned topics first in any given meeting.
When open floor starts, any topic posted either as a comment to this agenda post will be looked at, or as many as there is time for. If there is still time left after this, then meeting attendees may step forward with questions, comments, remarks, anything relating to the support team that they’d like to handle.
It is also important to note that not everyone is comfortable posting things publicly, there is complete understanding of this, and users are welcome to contact the team representative (@sterndata) via direct messages on Slack with whatever they wish the team to look at together.
For any other items to discuss, please add them to the comments below, or bring them up in the meeting.
The upcoming release of the Health Check & Troubleshooting pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party will contain various changes which affect users, and support providers alike, which is why we’re sharing what’s to come early.
What’s changing
The Site Health status screen on a WordPress 5.1 installation
The features that are now part of WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., and have been since version 5.2, are being removed. Maintaining them two places makes no sense, and is an added burden on the plugin maintainers. To make the transition as smooth as possible though, it’s being done in stages.
With the release of the plugin version 1.5.0, the elements found under Tools > Site Health will use core, and extend on it where possible, instead of adding a separate menu point for the plugin it self.
For users on older versions of WordPress, they will still get the custom plugin menu point, but the Site Health check screen will now instead provide them with details on why this feature has been removed, and providing them with an upgrade path to instead update their version of WordPress.
This leaves the Debug section still in the plugin, but the intentions here are to remove it as well in an upcoming release. That said, the extended output from phpinfo() which was accessible form there, has now been moved to the Tools menu item within the Site Health screen instead, to be more in line with the plugin standing on its own feet.
Why these changes?
Maintaining the same behavior across both WordPress core, and the plugin, was not scalable. For this to work the plugin would have had to be a first class citizen, where all new checks and debug data landed first, before even being considered for core. As this was not the case, core sped ahead of the plugin, leaving plugin users with a poorer experience.
As this was not ideal, and made for a lot of needs to create backwards compatible functions for features core had introduced, which were not there in older releases, a decision had to be made.
On the positive side of things, not having to maintain these specific areas gives a lot of room for improvements on the various other features of the plugin which have also taken a back-seat for a while. Although features like the Tools section for PHPPHPPHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. Compatibility checks, and the Troubleshooting Mode function right now, they could be improved on to make for an even greater user experience, and to account for even more scenarios, and that is where the focus will be going forward.
🚀 So off we go, into the horizon, great things ahead!
