06.12.13

Crowd-sourcing is not fault tolerant

Posted in Culture of Lickspittle at 1:41 pm by George Smith

As you’ve found DD blog was royally bricked for the past two days.

And it renewed my jaundiced view of WordPress and troubleshooting of errors by crowd-sourcing.

Adding a plugin on WordPress is always fraught with problems. They can crash the blog in an instant, making everything unreadable, the control panel impossible to reach. WordPress users have grown used to it, sort of like the citizenry of the US getting used to a life that guarantees nothing in a surveillance state.

When a plugin or add-on crashes the system you have to manually edit WordPress’s sql database and delete the hooks active plugins have put into the system.

That was done and the blog came back. But in the next hour or so it became impossible to get past the front page. Readers were presented with an error called “too many redirects.”

A quick Google search reveals how common it is and how people in the WordPress forums have very little idea about the cause, precisely, or how to get around it except by trial and error.

And the WordPress programmers have never seen fit to comment upon it. Crowd-sourcing technical help consigns people who need it to endless sifting of Google results, direction to pages and pages and pages of contributions by people who can neither write nor read well. And who are also often not even particularly capable of accurately describing the fault and what subsequent steps were taken.

Conversely, tech web-hosting solutions at my provider are entirely dependent on who you get on the telephone. If you get someone who knows WordPress, as I did on my first call after the blog crashed, they can fix it quickly. Indeed, two years ago when a serious problem crashed the entire thing two people at the company restored it from the provider’s server back-up, something they must have, but which the mega-firm likes to keep hidden from its users.

On a second call, a different person mumbled at me for about an hour, showed no knowledge of a WordPress install — which the ISP offers as a business enticement — and then recited a script that WP troubleshooting “was outside the boundary of our support.”

When told it had not been outside the boundary of support 24 hours earlier, the script was modified slightly to inform “that person was operating outside the boundary of our support.”

There’s really nothing to be said. I’ve covered tech support issues with Blogger, and also with WordPress, most famously here:

As for aid in WordPress support forums, one is dependent upon the pure milk of human kindness dispensed by others. If one is inexperienced, the help forums can be combed for clues which, on balance, tend not to accurately describe the fault and its implications. In two questions I posted, the general solution offered was to update [9] to the newest version of WordPress, which is not a fix at all, but a catch-all recommendation many people receive from the volunteer squad as a pro forma band-aid. Some people, naturally, resent it.

As with Blogger help, one not so infrequently sees the passive-aggressive treatment handed out. If there has been a fault, it’s because the user was not diligent. The software can do no wrong.

“Code is poetry,” is the WP motto. Here’s some poetry, ala Ogden Nash:

I once had a blog that was fit
But one day a server got hit
My site went upside down
And I floundered around
WordPress had dumped upon me a s—

The song isn’t quite the same but the rhymes were.

In any case, the fault lies somewhere in the implementation of the WP “permalinks” structure. I had what are called “pretty links,” set to conform roughly to post titles.

The pretty links option had to be reset to default and a spontaneous category change made in a post to force changes in what was in the database. With material rewritten to default links, which are given an ID number, things seem to be working again.

However, one cannot revert to the old style without causing the ‘too many redirects’ error to recur.

There were a lot of options I could have followed, none of them particularly palatable. At one point I seriously contemplating tossing the entire thing.

I’m certain the database error — it’s not really one, as the db passes checks — could be edited out. And while I’m not afraid to work on the sql database directly, I don’t have intimate knowledge of everything in the control section.

Another possibility is that the hosting provider changed something at the server level. I have found that inquiring about such things is never particularly fruitful.

That’s the story so far. So reset whatever you have to reset. I’m sorry, it couldn’t be helped.


Additional note: Links to old pieces with the long format produce the redirect error. That means most of the internal old links are busticated. I’ll change some of them, as time allows.

However, since tens of thousands do not use this blog, most will stay ruptured unless I can restore “pretty links” at some future point.

Yes, it’s an ache.


Comments also will stay moderated for the time being. Akismet plugin failure started the cycle that led to collapse. When I reactivated it in one last attempt to get it going, it worked once again. Shortly after which the real problems began.

2 Comments

  1. Christoph Hechl said,

    June 13, 2013 at 3:02 am

    I know this isn’t helpful but when i chose a software for my blog i had already gained some kind of distrust towards php.
    I started using Dotnetblogengine, which offers (among other options) a xml-database provider and thus gives me quite a lot of control over my data.
    In the meantime i have developed an intense disklike for all things php and am glad about the choice i had made, seeing that most providers are hesitant to install php updates which would be needed for newer software, but carry the risk of incompatibility with older programs.
    Since i have neither the money nor the nerve to run a root server of my own i think it’s best this way.

  2. George Smith said,

    June 13, 2013 at 10:04 am

    You make a good point. Now a good deal of my ‘intellectual’ content is tied up in php implementation and sql database so I’m stuck with trying to maintain this. When the bug hit I was still able to pull all of my posts from the database by using the editor so the content was not fried. But the idea of taking it all out piece by piece, deciding what to throw away and what to keep and what to take elsewhere, was daunting.

    When I abandoned blogger, at least the implementation allowed me to keep static html content on my site, and that’s all still there, very readable.