But just how big is your Internet footprint? If you’re a conscientious user who goes out of their way to protect their information and avoid pointless trivia on the Web, it could be that you’ve only left a few grains behind you. But for the rest of us, those little titbits could very well be quite liberally scattered throughout the Internet, potentially accessible to just about anyone with the time and inclination. Whilst the content we’ve created ourselves might be relatively humble, today’s social web has ensured that all but the most camera shy can end up having their pictures online for virtually anyone to see, and references to us can be found with just a few simple searches. But our Internet footprint isn’t just limited to those relevant bits which appear when we’re Googled—which after all is as much dependent on the uniqueness of our names or the fields in which we work—but simply, how many little instances there are of us out there.
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.