WordPress Frustrations: It does almost everything, eventually

I bought my first computer in 1983.  Don’t laugh.  It was an NEC HO2.  It had an 8086 processor, 128 KB of RAM, two  eight-inch ONE-MEGABYTE floppy drives, an eight inch monochrome green screen, and weighed around 40 pounds.  It was already out-of-date the day I bought it  figured, correctly, that no one would ever try to steal it.

It also came with Wordstar (yes, Wordstar), Lotus 123 precursor Supercalc, dBase II, and a bunch of the programs and cost me around $8,000, if memory serves correctly.  (I also remember a $16,000 figure but I think that was for the brand-new Dodge Omni GLH turbo I bought two years later. Yes, my computer cost around half as much as my next car.)

I know. If you’re under 40, you really can’t relate to these specifications, unless you happened to be my son, who was born in 1981 and grew up with The Green Monster.

By 1985, several computers later, I had taught myself various flavors of computer programming and had already launched my first software company, so I’ve been writing software for around 35 years, beginning with “expert system” software packages which were just moderately sophisticated database management systems but were credible precursors to artificial intelligence.

By the late 1980s, I was designing customized bulletin boards, creating what would become known as websites a few years later, all of which were hand-coded. My first commercially successful website was a retail mortgage site that did very well for itself while I was there to manage it.

That’s the problem with custom coded websites. Once the developers disappear, die become senile, or price themselves out of the market, the website is completely dependent on the original author for maintenance, upkeep and improvements.

I didn’t actually throw in the towel on hard-coded websites until 2005, when I took one look at Facebook and realized that I could never write enough code to match what they were doing.

That’s when I took up with WordPress, which I selected from among the other website authoring and management packages because it was already the frontrunner in that marketplace. (Always go with the frontrunner. It’s safer that way because no one can fault you for going with the most popular package.)

Since then, it is has been and up and down relationship.  Once you understand how WordPress works, you can (and I have) designed some very sophisticated websites (and, to be honest, some real clunkers) without writing any code agt all, except for a moderate amount of CSS required to customize certain page.

For my latest (and last) website, which happens to be the one you are looking at right now, my partner, Rob Pannier, and I wanted to design a public access website (sort of but not really just like Facebook) that would be more sophisticated than Facebook in terms of being able to custom design posts with multiple design features that Facebook doesn’t give you.

The caveat for that aspiration was that I needed a way to make sure that everyone who was submitting posts (we call them “articles”) was conforming to certain design standards and content protocols.

And here’s where I got into some complications that should have forced me to resort to writing hard code….but I was committed to designing a website that someone else could maintain after I shuffle off this mortal coil (which could be any day now the way things are going. If you actually happen to know me in real life, don’t worry. I’m not really sick. If I die of anything soon, it will probably be political apoplexy.)

So, the question arises:  how do you make sure that your contributors ALWAYS  insert a “featured image” into their posts. Without the featured images, the website’s pages will look like shit. (You may think they look like shit anyway, but opinions are like assholes….)

The featured image in your calling card. It attracts the reader’s eye to your article. The more interesting the featured image, the more views your articles will earn.

The most important variable, however, is the category.  Each article on our website must have one and only category because that’s how articles are assigned to their respective pages on the website. Now, if you look at The New York Times website, you will see multiple iterations of the same articles in several different locations on the home page, which seems very amateurish to us. (We sometimes have two iterations of the same article on a given page, but never more than two.) \

One of the box, the theme we are using (Newsy from Themify, which is no longer available because it required more support than the average theme, we think)  would allow users to chose, two, three or more categories. Some authors will do that as a mater of course, which means that they figure the most categories that post to the more views they will get. That might be true, but that behavior would also result in a very unattractive website filled with constant repetitions. Not acceptable.

What we needed, then, was a plugin that would restrict the users to selecting just one category.  We found one called PublishPress Checklist that would prevent users from posting articles if more than one category was selected. It also controls a number of other variables. It will prevent users from posting articles if the articles are too short (under 500 words,) or if it has too few or too many tags (we insist on at least one tag but no more than eight,) verifies that the article comes complete with a featured image, and makes sure that it includes a custom excerpt (which are the blurbs that you see attached to each article.)

That sounds like the perfect solution, except for one little glitch.