Regular users don’t know how to report issues to WordPress. I’ve seen many people on Twitter trying to report issues or find out how to do so.
We should provide a simple way for users to submit bug reports. A link in a footer, maybe, that goes to a form. It would go a long way.
It doesn’t have to be available in general release. It can be limited to beta and RCs.
There should also be an easy to spot link to support forums, too. I’ve directed hundreds of people from Twitter to WP forums because they didn’t know where to get support, so they tweet at WordPress thinking they will reply.
This is a great idea, if it can be done. It would make CP seem much more “personal” for users (provided it wasn’t like that “report this problem” message box that used to come up on Windows and you just knew it disappeared into the ether).
It’s good there is something. However, the 2 issues I see with it:
Once dismissed, where would user find this information again?
An average user won’t waste time creating Github account to submit a bug report.
The good thing about “see something, say something” campaign is that there’s an easy way to “say” something. Be it a phone number for anonymous tip or simply walking up to a police officer or someone similar and telling them. Similar approach would provide an easy way for average users to submit reports, without new accounts and such.
To resolve #1 point, we should have contact info available in the “help” tab - if it’s not already there.
This! I have been battling with GitHub on and off for years and I still find it perplexing. I wouldn’t have a clue how to submit a bug report. I think it needs to be super simple.
Consider that know wordpress use http://core.trac.wordpress.org/ that is more difficult to use and there are reports anyway.
Also consider that as in WP and many other projects sometimes bug reports are opened by the one that reply to a support request in the forum. So the non-skilled are helping because reporting their issues and from there the community help to find the bugs.
Also to submit a bug report in Github is more easy then wordpress because of the issue template that we have.
Also often bug report are only issues with plugins or misconfiguration and not a bug of the software so have a first level for non-skilled that is this forum is the best way to have the more skilled to do what they do and help the less skilled to achieve the same result.
Since I’ve been playing around with GitHub again today I’ve just gone in and looked at how I might go about submitting a bug report. It just looks daunting to me, and a little intimidating.
But maybe this is a good thing? I guess you aren’t really wanting anyone and everyone to be submitting their problems here. I see there is a link in the Welcome panel to the forum, so that’s probably all we need to give to users as an alternative (and somewhat more inviting) place to seek help.
Folks reporting issues on Trac are rarely average users, like a mommy blogger or a small business owner.
Here’s a perfect example from yesterday, someone DM our Twitter account and I thought for a second it might be a customer. But turns out they thought they were messaging WordPress directly. This is the stuff that we need to avoid, by providing easy means to report issues and getting support. It’s not just about making it available, but also highlighting it so anyone can spot it. When people are frustrated, they overlook things.
This is a average user, and more specifically average business user:
Reporting technical bugs well is not so easy. Generally you need to already know what’s going on behind the scenes, and provide clear steps for the developers to reproduce the issue. If what you’re reporting is a plugin conflict, or something else that won’t be fixed in the core software, then GitHub is not the right place for that.
Most user issues don’t look like this: often there’s a good bit of investigation and clarification needed, like in the example @viktor posted. The standard questions like “who’s your hosting provider? what version of PHP?” etc. This is fine, and getting that clarification here in the support forums works really well.
So I think I agree here: even though we build ClassicPress using GitHub, most bugs and support requests should start here in the forums.
We’ll look at making this wording clearer in time for the v1 release. Thanks everyone for the feedback!
I think we might have an advantage if we have something built into CP. Similar to software/OS crash/error reporting, you can attach logs and stuff to the report to make it more helpful.
So in CP, we can generate that debugging info that contains relevant information that users wouldn’t think to report: plugin list, themes, versions, php, etc. This can be a simple “copy this” information, so they include it with a bug report. Or, if we include a form to report a bug inside CP they can opt in to include this information with a bug report. This way every bug report would contain valuable information for troubleshooting.
This isn’t going to get done in time for version 1. For version 1, let’s just make sure we have a clear, obvious link to the support forums and other resources (we already have a starting point for this).
I think the Health check functionality it’s a good thing. At the end of the day it’s better to have a live site working without 1 plugin that is generating a fatal error rather then have it active and displaying the WSOD.
The problem isn’t necessarily just in the plugins or themes code, the other part of the problem is a manual intervention using the WordPress theme editor or the plugin editor. A simple syntax error, or an issue when saving it’s enough to cause that.
If that person doesn’t have FTP credentials the site will be down till someone with access will sort it, so I think it will be a positive feature.
That’s why we disable file editing on all sites. Not necessary if you know what you’re doing, and if you don’t you shouldn’t be editing files to begin with.
And that is the correct thing, for me I would also remove those options from the core.
The problem is users like the case you showed above, they have a problem and they don’t know who is their hosting or how to provide FTP credentials (they even don’t know what is that) so the only thing they have to provide to someone who is assisting in a specific plugin/theme issue is the admin credentials and then we all know what can happen.
There are already two petitions regarding this so it’s just a matter of time/code.
Just realized now reading the petitions comments that after WordPress 4.9 isn’t possible to save files that generate syntax errors thanks to Code Mirror. Good to know.
There is also an ‘extended’ version that gives a whole lot more information about all the config settings and hosting arrangements. Often when you ask for help on the forum they will ask you to copy and paste these. Not suggesting this for v1 of course, but maybe something to consider down the track.
One of the reasons I like Perch and use it is because of the really helpful support I can get through their forums. Might be worth considering this approach as a model. They have a very clear forum category that is simply: “I have a problem” - Perch Forum
So in CP, we can generate that debugging info that contains relevant information that users wouldn’t think to report: plugin list, themes, versions, php, etc. This can be a simple “copy this” information, so they include it with a bug report. Or, if we include a form to report a bug inside CP they can opt in to include this information with a bug report. This way every bug report would contain valuable information for troubleshooting.
I like this idea. WP-Spamshield has a plugin that works like that to make reporting problems easier.
I’m iffy on the Health Check plugin. I’ve tried using it twice now and had no idea what I was looking at or what to do with it. I would expect such a plugin to give diagnostics and explain what plugins are interfering with what code, etc. etc. Instead I’m just staring at a screen that lists plugins and put me on the wrong theme, with no indication of what’s going wrong or how to fix it.
