There are plenty of examples out there of WordPress installs suddenly displaying blank pages—on admin pages as well as frontend posts—after changing themes, adding/removing plugins or updating the WordPress backend. Whilst there is plenty of good information out there covering most of the usual suspects, I just came across another which was fairly difficult to track down given the lack of information, though pretty easy to solve once I’d found it. If like me you’ve at any point tried to streamline your WordPress install by cutting down on a few unnecessary services, and reducing the number of calls to the database, you may have added some lines to your wp-config.php file like so:
Fairly innocuous, until you actually change your WordPress theme, in which case those long forgotten about resource savers will leave you with little more than a blank page to diagnose your problem. If this is the case though, just updating the lines or commenting them out will leave you with a workable system once again.
Many of us are probably familiar with the idea advanced in the early days of the Internet, that most users don’t know how to scroll through a website. Today that seems pretty unbelievable. The vast majority of websites, and indeed many of the most regularly visited, not only favour scrolling but to a large extent rely on it for navigation. So have the rules of the so-called ‘fold’ changed since the Internet’s inception? And what role should it play in decisions made regarding a website’s design today?
Viewing the web can be a very personal experience. Depending on your very own choice of browser, monitor or resolution, the web can look a very different place. If you’ve ever for some reason been forced to view one of your regularly visited websites on a much lower resolution monitor, for example, you’ll know what I mean. What once appeared spacious and easy to read suddenly seems squashed and cluttered. The cute little thumbnail images now take up good chunks of room and force you to scroll around them to get at the text. And should that site employ a fixed-width design that is wider than the current resolution, even more space goes to waste with the appearance of a side scrollbar.
Many of us have found ourselves in this position. Your business or group make use of an online system, such as a forum, wiki, blog etc., which you then wish to augment or combine with some other system. How you go about doing that, of course, depends entirely on your goals and the systems you’re trying to use together. Design and styling are usually the least of those worries.
The problem which consistently presents itself when attempting such a combination is what to do with the userbase. Whilst this issue can sometimes be simply ignored, in the hope that only a small number of the users of one system will need access to the second, this isn’t always the case. When it comes to one userbase requiring access to two or more systems, the first question that needs to be answered is whether the user information should be shared, enabling a unified login procedure amongst other benefits. Requiring users to sign up to various different pieces of the puzzle is a time-consuming process, and one that many will find confusing and unnecessary. And since different online systems often have conflicting requirements when it comes to usernames and passwords, for example, this can also lead to more lost password checks and work for the system administrator. However, programming such functionality oneself certainly isn’t within the realms of the abilities of all of us, and keeping such modifications functioning across various systems and versions can be a painful procedure.
After initially solving my database character encoding problems by ignoring the specific strings in the wp-config.php file, I was finally forced to alter the characters in the database during a recent reshuffle. Whilst there are two automated solutions available via plugin, namely g30rg3x‘s UTF-8 Database Converter and the Modified UTF8 Sanitize Plugin, sadly neither worked in my particular instance, and indeed the former is no longer supported for current versions of WordPress, though reports on the WordPress support forum suggest there should be no issues.
Whilst I normally steer clear of this kind of book, I saw it in a local library and thought I’d have a look, thinking there might at least be a few useful tips. Unfortunately, I was not only disappointed on the tips front, but in the general presentation of this book. Like a previous viewer, I was left rather perplexed as to exactly who the book is aimed at. The blurb suggests it is designed for people planning to build professional, rather than personal websites, and yet the content never quite seems to match up. At once Lopuck suggests that when providing designs for clients you should delegate to members of your team (also dummies, presumably?) so that the designs reflect different interpretations of the requirements, and a few pages later, something as mundane as copying and pasting images will be covered.
The book is so riddled with such strange juxtapositions that it really ends up being of very little use to anyone. Real beginners will be sorely disappointed by many of the chapters, which assume either a background in print design, or that the reader is already a member of a web design team (begging the question, why they should be reading a book purportedly for dummies), or perhaps that the reader already owns software such as Dreamweaver, Fireworks or Photoshop. More experienced readers may find a few useful tips, but I should imagine have already covered the key sections of this book elsewhere, and will only be insulted by the more mundane chapters on the vagaries of web adaptive palettes or font types.