A few weeks ago I wrote here how one misplaced single quotation mark managed to break an entire WordPress site, resulting in the dreaded WordPress White Screen of Death. The other day I experienced a somewhat similar mishap when putting some Google Adsense code – the underlying code behind Google text ads – here on this site.
It wasn’t catastrophic; it didn’t crash the entire site. But it had unintended consequences that took a while to track down, and finding the problem involved going through the code that WordPress generates.
Like most people who use WordPress, I just cut and pasted the Adsense code into a text widget and pasted the widget inside a sidebar, within the WordPress admin interface. I’ve done this before on other sites; it’s a pretty routine thing.
And yet, when I went to the Jeff Chappell dot com’s homepage, the result was the image you see here to the right. The Google Adsense ads were showing up, but the widget down below, WordPress’ meta widget with the standard login and RSS feed links, was broken – it displayed in my browser, but it’s supposed to have an off-white background as dictated by CSS. Only it was displaying transparent with the site’s background image was showing through.
At first, because I like to use Opera – I’ve been using Opera for years – I thought it must be a browser compatibility issue. But I checked the site in the latest versions of Firefox, IE and Chrome, and each displayed the same problem, so I couldn’t blame it on Opera. At the same time I thought it might be some weird caching issue; I use W3 Total Cache, which is a great WordPress plugin, very powerful – sometimes a little too powerful. But no, this wasn’t the problem either.
So it was time to start looking at the source code that WordPress was generating. To make a long story short, the problem was … wait for it … *insert snare drum roll* … the fact that I hadn’t included a heading or title in the widget housing the Adsense code.
When you use a text or any other widget in WordPress, there is a place to put a title. I left it blank, and as a result, it didn’t produce the necessary div tags when WordPress generated the html code for the page. Consequently the necessary calls to the CSS file weren’t taking place, resulting in the broken meta widget.
The problem lies in the fact that both widgets reside in the same part of the sidebar, bound together code-wise with div tags, specifically class “block.” A look at the code reveals the exact problem. Here’s what the first several lines look like — including the problematic ones — for the lower right sidebar on this site that contains the widget with the adsense code:
Paying the Bills
The key turned out to be the div class “widgetcontent” — or so I thought at first. As you can see from this snippet of code below, generated when I take away the title text in the WordPress widget window, without the corresponding div tags that handle the widget title being called upon in the code produced, the div tags with the widgetcontent class aren’t produced either:
It still bugged me though. After taking another look at the entire chunk of code enclosed by the “block” div tags, I figured out what was really going on. When we skip the widget title, we end up with one to many closing div tags, so while the Adsense widget is enclosed in the proper “block-content” div tags, the meta widget underneath is not, resulting in the transparent widget — a look at the CSS file reveals that it is indeed the missing block-content div tags for the widget on the bottom that give us the unwanted transparency.
Anyway, if you’re exceptionally nerdy and want to see for yourself, here’s the entire chunk of offending code. If you match up the div tags — easy to do in Notepad++, incidentally — it’s easy to see where the boo-boo occurs.
In any event, I hope this may help other folks in the future who encounter a similar problem. Who would have thought that skipping a widget title would create a hassle?
The Shakespearean Flaw in PHP Prompts
WordPress’ White Screen of Death
Thus conscience does make cowards of us all,
And thus the native hue of resolution
Is sicklied o’er with the pale cast of thought,
And enterprises of great pitch and moment
With this regard their currents turn awry,
And lose the name of action
— William Shakespeare, Hamlet, Act III Sc.1
Okay, maybe the potential fragility of computer language code, specifically PHP as utilized by WordPress, doesn’t quite compare with Hamlet’s dawdling and proto-angst or Macbeth’s murderous ambition – their fatal, tragic flaws, if you are a Shakespeare buff, or at least were paying attention in high school English. Indeed, exaggeration of Swiftian proportions, this. But this fragility can bring on the dreaded WordPress White Screen of Death quite easily when one begins modifying code (code that works just fine as it is) to customize it to one’s own wants and needs.
In fact, one misplaced apostrophe – or, rather, one misinterpreted single quote — can break an entire installation of WordPress, prompting the aforementioned White Screen of Death. Think of the thousands of lines of code involved in a Website, WordPress or otherwise, and then think about that. Here is this magnificent digital tower: a fortress of light standing staunchly at the crossroads of Gibson’s cyberspace, destroyed (albeit temporarily) by one tiny, misplaced, digital brick.
It’s not just tragic – okay, not really – but also ironic in that one of the great things about WordPress is that it’s open source, has lots of really knowledgeable coders working on it, and as such is really stable. Someone who doesn’t know jack squat about computers and the series of interconnected tubes can get WordPress up and running with relative ease and speed, joining their voice to the cacophony of the blogosphere. It’s actually quite hard to break WordPress, in point of fact. It’s like my old Subaru: until you go tinkering under the hood fixing stuff that isn’t broken, it works flawlessly.
Case in point: I was recently working on a site that will use WordPress and the Thirty Ten theme, which is a three-column version of WordPress’ own Twenty Ten theme, the default theme that comes with WordPress. I wanted something as simple and clean as Twenty Ten for this particular site, but, I wanted three columns. Rather than reinvent the three-columned wheel, I looked to Aaron Jorbin’s Thirty Ten theme.
This is exactly what I wanted: a child theme of Twenty Ten that adds a third column. Yay for Aaron Jorbin! I only needed to change the link colors and add custom text to the footer.
I wasn’t quite thinking when I attended to the latter; after all, what could go wrong, just replacing text? You can see the tragic Shakespearian downfall coming, yeah? PHP uses single quotes around text that will appear in your browser. For example, if we look at the footer.php file in Twenty Ten, there is this line:
<?php printf( __( ‘Proudly powered by %s.’, ‘twentyten’ ), ‘WordPress’ ); ?>
That line produces the “Proudly powered by WordPress.” line at the bottom of every page in the default Twenty Ten theme. Thirty Ten modifies this, along with some of the other default text that appears elsewhere in the Twenty Ten theme, with a file called text-wrangler.php – the beauty of a child theme is that it doesn’t modify the underlying parent theme files. Among my customized footer text were the word’s “Gecko’s Bark” – no, really. Now, an experienced Web coder would know that single quote, doubling as a possessive apostrophe in this instance, would have to represented by the proper code for its symbol, lest a browser interpret it as part of the actual PHP code. Specifically, I needed Gecko's Bark.
But I’m still a n00b, really – well not really a n00b, after all, I realized where my problem lay within minutes. But I obviously lack the expertise and instincts that someone that has coded all his her life, for a living. Ironically, if I hadn’t been a journalist all my life, being grammatically correct wouldn’t be instinctive and I probably wouldn’t have sweated the possessive. So there you go; my own tragically Shakespearean flaw in miniature.
Anyway, that little coding boo-boo was enough to completely break WordPress. I went to look at how the footer appeared with the changes, and … nothing. Zilch. Nada. It was a sea of white space in the browser. I tried to go to the WordPress admin page, but saw only more white space.
Yep. One little single quote caused a cascade effect that broke WordPress completely. Usually something like this will only cause certain pages not to load, or the site and/or the admin pages to look wonky. Or you get some sort of PHP-related error. But not this time; I tried different browsers and there was nothing but white space or the “can’t get there from here” error that Internet Explorer throws up. That little misplaced single quote caused my browser to subsequently misinterpret all of the rest of the underlying code that otherwise works fine.
Fortunately this wasn’t a live site (the beauty of having a local WordPress installation). I looked at the MySQL database and restarted Apache – typically the rare WordPress White Screen of Death involves issues with one these things – but neither one of these were the problem. I would have been surprised if either had; the site was working moments before I went to tinker with the footer text, now it was busted – doesn’t take Sherlock Holmes to logically deduce that I must have broke things messing around with that footer text. Sure enough, a perusal of text-wrangler.php revealed the problem.
This is where it’s nice to have a text editor that can represent different parts of code with different colors; in this case the telltale devil was in the pink text, or lack thereof. When looking at PHP code in Gedit, the text editor in versions of Linux that use the Gnome GUI, such as Ubuntu, it portrays text in between quotes — the text that will appear in your browser — in bright-pink-not-quite-fuchsia. A quick glance revealed my errant apostrophe and the subsequent line of text that should have been pink, but wasn’t.
No, not the stuff of Shakespearean tragedy. Not even comedy. But hopefully this will server as a warning and lesson to others who set out to customize WordPress. Be careful tinkering under the hood, lest your hubris cause your tragic downfall – or that of your Website.
To-morrow, and to-morrow, and to-morrow,
Creeps in this petty code from screen to screen
To the last syllable of re-coded line;
And all our yesterdays have lighted fools
The way to white screen death. Out, out, brief mon’tor!
Website’s but a walking shadow
– Jeff Chappell (with apologies to the Bard. To see the inspiration/original, consult Macbeth, Act V, Sc. V).
If you’d like more Shakespearean parody, please go here.
The Best Laid MySQL Databases and WordPress Installs Go Often Askew
The process of uploading/migrating this site from my local WordPress installation under Windows 7 to Dreamhost became an epic sort of nightmare. I’m not inexperienced at this; I’ve moved WordPress from a subdirectory to a site’s root folder, and moved sites from one host to another. It doesn’t always go easy; that first time a few years ago, moving WordPress into the root folder, was not without difficulty. But since then, I have not had very many problems moving WordPress installations around when necessary – particularly now that WordPress has the ability to import and export its data. That is, until the other night, when I decided the latest, greatest version of Jeff Chappell dot com was ready for prime time. It was a cluster … er, duck, yes, clusterduck of epic proportions (I decided there should be no swearing on the site that deems to represent my professional endeavors, not even in the blog – hence, clusterduck). Or a train wreck, if you will. I started out with the preferred method, as illustrated here in the WordPress codex for moving an install to a new server:
- I uploaded the WordPress files and the theme files from my hard drive to my webhost.
- I changed the URL settings from within WordPress on my local site, exported the MySQL database from my local installation.
- I imported/uploaded the database on my Web host, and uploaded a new wp-config.php file to WordPress’ root directory with the new location of said database and the login info.
- Initially, everything seemed to go fine. I apparently – I stress this word – imported the database without any problems. When I navigated to the site in a browser, I got the initial WordPress install screen. “Victory once again,” I thought.
But alas, victory would not come nearly so easily, in the end. When I actually got into WordPress, I could see all my pages and posts, but there were no tags attached with any post, nor were there any categories for links or pages. Now if this were a new site without any content, or just a few initial pages/posts, it wouldn’t be much of a problem. Easy to fix within WordPress. But, the whole point of this site is to house examples of my news writing and blogging; it’s essentially a post-modern clip file. As such, at the time of launch I had more than 70 posts and 19 pages; the posts use some 70 different tags and several different categories. I rely on both for organization. Needless to say, I did not want to have to go in and re-tag 70-some posts. So I deleted the database entries and tried using WordPress’ export plugin to export its data and uploaded/imported that into the new installation – that kinda worked. Everything seemed to be here, but I couldn’t get the theme files to work, and the pages rendered all sorts of screwed up when viewed in a browser. So I tried it one more time with a fresh installation of WordPress and imported the data using its import plugin (after clearing out the MySQL database one more time) – that seemed to do the trick; everything was where it was supposed to be. Then I uploaded my theme files, and with some minor tweaking everything was hunky dory. Doesn’t really sound like a nightmare in retrospect, but when it’s a half hour before you plan on hitting the sack, and the resultant snafus keep you up for several stressful hours beyond that, well … maybe it’s not an epic nightmare, or even a train wreck, but it’s a royal pain in the butt. But such is life and such are computers; it’s the nature of the beast. Part of the problem initially is that there is a slight version difference between the MySQL I have installed locally and the one that Dreamhost is currently using – at least that’s what I’m theorizing here. In the past, if I was able to import a database at all, I never had any problems after that. Another thing that may or may not have caused a snafu is that when I initially uploaded WordPress, I inadvertently uploaded the local .htaccess file. If I had thought of that ahead of time, I probably wouldn’t have had to resort to a fresh install of WordPresss. So, word to the wise, if you’re moving a WordPress installation, or uploading a local installation where you did your development up to your Web host:
- If a database import won’t work, try WordPress’ export/import plugin (you can find this in the left-hand menu inside WordPress, under tools).
- If your local WAMP and WordPress installation puts an .htaccess file in your WordPress folder, when you go to upload your WordPress files don’t upload that .htacess file. For more on what the .htaccess file is, here is Wikipedia and WordPress. Odds are, you won’t have to mess with this file, but, depending on your Web host, sometimes you may have to use this file to provide WordPress with the rights/permissions it needs. WordPress uses an .htaccess file for permalinks purposes, so moving it along with your WordPress files from a local install to a one on a Web host can muck things up.
Speaking of Permalinks and WordPress and Migrating an Install
I’ve used a couple of different plugins for updating links after moving an installation or uploading it from a local one. Velvet Blues Update URLs is the one I like best; it’s simple, straightforward and effective. As mentioned before, you’ll need to use a plugin of this sort – or go in and do it by hand – to update internal links in posts and pages because these will all link to something like http://localhost/ralph/whatever/. Obviously you’ll want to get rid of the localhost part of your links and replace ralph if that isn’t part of your actual live domain name; Velvet Blues does this. One thing to note though – Velvet Blues doesn’t update your links used in custom fields. A lot of themes use Timthumb and custom fields to manage thumbnails and featured images – as opposed to WordPress’ own Featured Image function – and you’ll have to go in and fix these manually. But this is usually just a handful of posts, so no worries. There may be other plugins out there that also fix these links; I’ve always used Velvet Blues because it’s simple and I’ve never had a problem with it
Speaking of Custom Fields, Where Did They Go in WordPress 3.1?
One more thing I would note about WordPress, specifically a change in 3.1. This was the first time I had done a clean install of WordPress in some time, as opposed to upgrading. The most recent local install I had installed from scratch was 3.0. Anyway, in 3.1, a lot of the screen options are turned off by default. That means things like excerpts, custom fields, slugs, etc. don’t show up when you go to an add or edit post page, or add/edit page page, for that matter. If you have these options on in an earlier version of WordPress and upgrade via WordPress’ internal automatic upgrade, these options remain ticked off. However when I first looked at my clean install of 3.1 for the first time, I was wondering why I couldn’t see my excerpt and custom fields – both of which this theme uses. It took a little digging for me to figure out the problem – I’m such an old WordPress user I remember when there were no screen “options.” At first I thought it was something to do with the string of other install snafus, but such was fortunately not the case. Just thought I might mention this should any other old users of WordPress perform a clean install of 3.1 and wonder where their Excerpt entry box disappeared to.
Pardon My Mess
Well, it shouldn’t look to bad, but we’re still in what I suppose I shall call beta for Jeff Chappell dot com; Gecko’s Bark Productions has been a bit behind schedule (namely due to the distractions of returning home after a year away, and the launch of Rift.
Anyway, I’ve got things — more-or-less — squared away here with the relaunch of this site, separating out the professional journalist and blogger Jeff Chappell from the raving lunatic Jeff Chappell. But there are still some things to do around here — sweep up the drywall dust, touch up the paint, etc. But migrating this site from my local installation onto my Web host proved to be a
nightmare from hell problematic; MySQL and WordPress just didn’t want to work and play well with others this evening
More on this later, but now it’s way past my bedtime. So if the new and improved Jeff Chappell dot com has a few rough edges, just bear with me.
A Local WordPress Install and the Windows Refugee Experience: chownED by Ubuntu!
This isn’t a tutorial per se, unlike these posts on setting up a local WordPress installation under Windows using WampServer. There are several comprehensive tutorials or sets of instructions out there on the Web about setting up LAMP – Linux-Apache-MySQL-PHP – along with WordPress on Ubuntu.
Furthermore, while I can’t say I’m a Linux noobert, per se, I would still consider myself a de facto noob. I find it easier to tinker under the hood in Windows, simply because I’ve been doing it for so long. I’ve only been using Ubuntu for the past year or so, however; prior to that the last time I saw anything resembling a Unix environment was 1997. Back then I installed FreeBSD alongside Windows 95, because I got tired of the latter’s constant crashing.
On the other hand, if I could successfully get FreeBSD and Windows 95 both working on a dual-boot configuration in 1997, I feel like there’s not much I can’t do. Where I lack in intelligence I compensate with considerable intuition and implacable, obdurate will; I’m stubborn to a fault – a good trait when it comes to tinkering with computer operating systems.
And it’s especially good coming to Linux from Windows. As my best computer nerd friend – he doesn’t bother using package managers; he does everything from the terminal off the top of his head – Linux is a “completely opt-in OS; Windows is the exact opposite.” I’ll get to what he means in a minute, Windows users. Just remember:
Anyway, Ubuntu’s own documentation on installing LAMP and WordPress, as well as its specific docs on installing Apache will likely get you up and running without too much problem, even if you’re a complete Linux noob. You don’t have to, but I would suggest reading the Apache docs too; particularly if you are security minded; the Apache doc will show you how to edit the ports.conf file so your Apache server is only accessible by your local machine — it will only dance with itself on Port 80, rather than looking all over the world for every type of girl in any ole’ port.
But I digress. These two docs are fairly comprehensive without telling you a bunch of stuff you don’t really need to know or care about (unlike me; I’m often wont to digress). Then there is Ubuntu Geek’s tutorial on WordPress and Ubuntu 10.4 specifically.
And if you are completely scared of a do-it-yourself install, then you probably shouldn’t be messing around with Linux. I think it’s safe to assume if you’re looking for information on how to run a local Web server on Ubuntu so you can, in turn, run a local WordPress installation for development purposes, you must be reasonably tech savvy.
But then, on the other hand, there are more and more laptops/nettops/netbooks/tablets/what-have-you gizmos running Ubuntu or some other variation of Linux these days, and consequently more and more WinD’oh!s users are finding it necessary to get familiar with it. Plus, I would guess there are probably some folks out there that just don’t want to shell out for a new Windows 7 system disk when Ubuntu is free and relatively easy (times are tough, after all).
Alert: stuff you may not need to know/care about: But then Windows 7 is actually pretty stable and much more secure than previous incarnations, and rather easy on old hardware, particularly if you turn off the Aero bells and whistles. I’ve seen it installed on a decade-old desktop with a whopping 512 megabytes of memory, a 10 gig hard drive, and a creaky-old Pentium 4 CPU, and it ran really well, barely taxing this ancient box; I wouldn’t have believed it if I hadn’t seen it myself. It even booted a lot quicker than my Win XP laptop with its 3 gigs of memory, dual-core Intel CPU and 100 gig drive – and I had my XP boot pared down to the bare essentials. So there you go.
But generally speaking, Ubuntu is lighter on the hardware than Windows – even Windows 7 – and considerably more secure (although Vista and Win 7 go a long way towards addressing Windows’ lingering security issues). Plus, did I mention it’s free? And it’s open source, and it’s been around a long time now, so there is plenty of support, third party apps and so forth out there.
Close Windows, Turn on the LAMP, Ubuntu and WordPress
So I thought I might just point out a few things for Windows users who have seen the Linux light and who also happen to work with WordPress and want to get a local installation of it up and running for Web site development purposes. Of course this reflects my own experience, and what what follows is what works for me on my hardware; your mileage may vary depending on your particular version of software and hardware.
First off – and this is one of those tangents you may not care about, particularly if you came here from Teh Google — one of the odd things for Windows converts in a Unix/Linux environment is its concept of users, rights and security. As my previously-referenced computer nerd pal puts it, “You have to tell Linux exactly what to do; it’s never going to assume anything.”
Up until Vista came along, if you had a login credential on a Windows machine – a user name and password – you could easily wreak havoc at will (and often inadvertently) in Windows. You were the God of the Keyboard; you could pretty much do whatever you wanted to (and so could anyone else). With Vista came the dreaded UAC, “user account control,” however, and notifications that you had to run various and sundry programs as administrator in order to do what you were trying to do.
I remember the first time I encountered this on a Vista box and thinking “WTF is this now? Did Microsoft steal a page from Apple’s playbook and just slap a fancy GUI over Unix and call it the new Windows OS? Or did they hire the Master Control Program from Tron?” Not quite either, of course, but still it reminds one of Unix.
The idea behind this is security; ostensibly if someone were able to remotely hack into your machine with bogus credentials (or were able to purloin your actual user name and password), the damage they could do would be limited, because they couldn’t run programs as an admin. They could not aspire to be the Keyboard God, but rather a minor, malicious cherubim or seraphim at best.
This may have been novel for Windows, but old hat for Unix, Linux and their various derivatives, of course. When you log into Ubuntu you’re a user and as such you don’t have admin or “root” privileges; you’re low man on the OS user totem pole. You can of course temporarily elevate yourself to root – using the sudo or su command – but not the Sussudio command — in conjunction with some other command in a terminal (think DOS window in Windows), for example.
Even when it comes to files and folders, you can encounter this issue; files and folders are owned by certain users and other users and groups of users are assigned various rights accordingly – a file’s owner has read and write permission, but another user may only have read permission, or perhaps not even that.
There’s mountains of more info on this out on the Intertubes; Google and Yahoo are your friends. However I would suggest this Wikipedia entry on file system permissions if this is a completely new concept for you. It’s a pretty good yet brief overview of permissions and rights for various operating systems, and details rights and permissions used in Unix – and consequently Linux – environments and their notations. You’ll be down with the 411 on the 755 in no time at all, not to mention the -rwxr-xr-x.
On the other hand, if you’re a reasonably knowledgeable Windows user who can tinker underneath Window’s hood without breaking it, then file system permissions in Linux are seemingly a pain in the ass sometimes – you’ll miss having the god-like powers that Windows entrusted with you (or at least used to). Sometimes it does feels like you’re Flynn and you have to outwit the MCP. On the other hand, it’s why Unix/Linux is so much more secure – it’s much more difficult to hack into remotely. Plus it’s difficult for your non-techie friends and family to accidentally eff up.
Um, Yeah, LAMP? WordPress? Don’t Worry, I’m Getting to the Point
This issue of users, rights, and ownership is important to keep in mind when setting up your WordPress installation in Ubuntu. If WordPress folders – let’s call them directories since this isn’t Windows – subdirectories and files don’t have the correct ownership, rights and privileges assigned to them, it won’t work, or at least not well. You may be able to navigate to your local site, but WordPress won’t be able to create new posts/pages. Or it may be able to do this, but when you try and navigate to that new page or post, you’ll get the 404-not-found error. Furthermore, you won’t be able to update WordPress automatically, install plugins, etc.
So, with this in mind, in the section in the Ubuntu installation instructions where it says this:
For automatic updates to occur, the folder and all its files and subfolders must be owned by www-data:
chown -R www-data /usr/share/wordpress
That’s REALLY IMPORTANT.
The “chown” command is shorthand for “change owner” and the -R means the change is recursive; it applies to all subdirectories and files. Who is this www-data user? It’s a system user account that your Apache Web server creates to do its thing. And since WordPress relies on Apache to do its thing, www-data needs ownership.
Apache’s Running, WordPress is Installed and Using the MySQL Database, but I Got Nothin’
I learned about www-data the hard way. I had installed WordPress a number of times on Windows, in both XP and Windows 7, so I didn’t really think there would be much to getting it up and running on Linux. I installed Apache, MySQL and PHP individually via the Synaptic Package Manger in Ubuntu on my laptop and verified it was all running correctly. So far, so good. Went to phpMyAdmin, set up my databases for the WordPress sites I’m currently working on, downloaded the WordPress files and installed them in the various directories for each site, and proceeded apace – pretty much the same process in Windows.
Only I couldn’t actually see or navigate to any page locally beyond each site’s index.php file. I could create a new page in WordPress, and it showed up in the database, but I couldn’t see it when I tried to navigate to it in the browser. I solved this by giving the whole world access to all of my WordPress directories and files – 777 – but then I noticed I still couldn’t update automatically inside WordPress. Files would download, unpack, and then the install would fail.
A little more research revealed my issue with www-data ownership. Moral of the story? When all else fails, read the effing manual.
So now WordPress works fine on my local machine under Ubuntu, and I didn’t have to invoke Keyboard God mode. Huzzah. Beyond this, installing LAMP and WordPress on Ubuntu isn’t that different than it is in Windows.
Update: Don’t Assume Ubuntu Works Like Windows
So I just learned something else about this directory ownership issue. I was setting up a new site that will use WordPress on my Ubuntu box. The theme I installed for this site comes with some dummy data – pages, posts and comments – to populate the site, allowing you to experiment with its appearance.
Everything was fine until I went to import this data in WordPress via an xml file. WordPress kept asking for ftp login credentials, which it shouldn’t have to, since www-data has ownership of this new subdirectory I made in my www folder – or does it? After some hair-pulling and cursing, I looked and nope, ownership and permissions were assigned to my user account.
WTF chownED by Ubuntu’s MCP. Again.
See, I’m a Windows refugee — well, not really, since I run Win 7 on my desktop box, and have no compelling reason to switch. Although the next time I order something form NewEgg or Amazon, I’ll probably order another hard drive and slap Ubuntu or Kubuntu on it. I guess you could say bi-curiOS.
Anyway, since I assigned ownership to the parent directory to www-data and made that ownership recursive, I assumed – and we all know what happens then – that any new subdirectories created in that folder would automatically inherit www-data ownership and the characteristics of the existing parent directory. In Windows, of course, you can set the characteristics of a file folder to be recursive, and any subfolders you add after that will assume – heh – those same characteristics – although there’s no ownership, per se – not in the sense that there is in Unix/Linux.
As the aformentioned friend noted, Linux never assumes; you need to tell it if you want ownership to differ from the user account used to create it – which in retrospect makes sense. But like I said, I’m a veteran Windows tinkerer, and I’m used to being the Keyboard God, and not having to outwit the MCP.
But if you’re reading this, then I hope that my frustration is your gain.