This is an attempt to explain a pattern of troubleshooting WordPress through a specific event and perhaps reinforce the need for me to be humble in all interactions with people.
So even if you never have this problem this might be useful.
An admin for one of our sites using FeedWordPress and suddenly can’t see any feeds in her syndicated sites view for that plugin. She sends me an email. I drop into the site and check. All looks good to me.
Sadly. Sadly. Sadly. I respond to her and say it seems to be working on my end . . . has she tried another browser, computer, login/logout/restart etc. It’s easy to end up assuming the person reporting the problem is wrong by default. I get a fair number of emails. Many of them, probably most of them, report problems that are more human than mechanical. It’s easy to fall into a trap of assuming it’s a human issue, especially if a superficial inspection confirms that suspicion. It’s also called a trap for a reason. Avoid it if at all possible and if you fall into it please attempt to climb out.1
A bit later she indicates that she has done these things and the problem persists. I go back to the site. It still works for me.
I now do what I should have done the first time. I assume her account permissions using User Switching. This plugin really lets you assume the role of the human you’re trying to help. You see what they see. Their restrictions are your restrictions. Instant empathy?
Presto. I am now seeing the error. At some point as I switch between my account and her account . . . my own account loses the ability to see the feeds. That is both a good and bad thing. Good in that I can now more easily replicate the issue without changing roles back and forth. Bad. In that the disease is spreading! Worse. The issue travels with me to other sites where I have FeedWordPress running.
I invite Matt and Jeff to try with their super admin accounts. Matt can see initially but loses that ability. Jeff somehow remains infection free. I even ask Twitter what’s going on. Jeff does some mysql table repair/verifications. No dice.
— Tom Woodward (@twoodwar) September 5, 2017
So now I sort of know some things. The issue is not site specific. The issue travels with the user account to other sites.
That really makes me think something has somehow been set at the user level. That data is stored in the wp_usermeta table. I take a look in there and find that I have a lot of stuff there. My initial impulse it delete everything that isn’t in the default table description in the codex but I take a minute and scan for a bit . . . and find two rows with feedwordpress in them.
Deleting those two lines heals my account. I go to the faculty member’s account and find the same thing. I delete them and she is healed as well. I celebrate in a quiet way as it is nearly 10PM and my kids ought to be asleep.
In further experiments with Matt this AM, it looks like we could have just deleted the metabox hidden row. I’m also still not sure how this setting was set but I’m taking it as a victory for now.
I need to work harder on putting humans first and taking the time to make sure I’m assuming they are right and have good intentions. It’s easy to let that slip when lots is happening. It is easy to get frustrated doing technical support. No self-flagellation here, I think I do a good job of that most of the time but I need to stay on top of it. I don’t want to end up a bitter tech troll at the bottom of a bit cursing the sun and the humanssssssss.
And technically, if issues follows specific users, but not all users, between sites check the wp_usermeta table sooner rather than later.