Where’s the option to change the “uploads” path in WordPress 3.5?

Thanks for nothing, WordPress.

It’s not often that I complain about anything in WordPress, much less get genuinely angry about something I think is downright stupid, but today it happened.

I build a lot of WordPress sites for clients, and I frequently post them in a staging area on my server. Rather than having dozens of separate installations of WordPress filling up my server’s disk space, I set up a single installation (but with a separate database for each site), with some simple customizations to the wp-config.php file that tell it which database to use based on the domain name.

Please don’t bother to mention that I should “probably” be running WordPress-MU (or MultiSite or whatever they call it now). Ultimately these sites are going to be hosted elsewhere as standalone WordPress sites so I need to keep their databases separate.

One key to making this arrangement work nicely has always been the simple setting in WordPress that allows you to define a special directory for uploads, instead of dumping them all in the main uploads directory. By setting this to a subdirectory under wp-content/uploads named to match the site’s theme folder name, it was easy to keep everything separate.

It’s been a while since I’ve set up a new site on the staging server, at least since before I updated to WordPress 3.5. But I was doing one today, and I had to do a sanity check as I scoured the settings to try to find where in the hell you set the custom uploads path. I was sure it was under Settings → Media but I couldn’t find it there.

Because they took it out.

Yes, they took it out. Why? Well, apparently there’s a rational explanation, but frankly no explanation would satisfy me because it seems incredibly disruptive to take something like this out, even if it was a bad idea to implement it as it was in the first place.

Fortunately, there’s still a way to do it. You just can’t do it in the admin interface anymore; you need to edit the wp-config.php file directly to add a constant. No problem, I’m already doing that anyway.

Here’s what you need:

define('UPLOADS', '/your/custom/path/under/wordpress/root');

If you’re just putting your uploads into a subdirectory under the main uploads directory, like I am, it would look like this:

define('UPLOADS', '/wp-content/uploads/yourdirectory');

Just remember, if you’re doing this because you’re running multiple sites from a single installation like I am, this constant should be set in the same conditional where you’re setting which database the site should use.

Easy. Not as easy as it was, nor as easy as I think it should be, but…

Microsoft Word’s formatting garbage, quantified

Anyone who’s spent any amount of time working on the web dreads it: content delivered in Microsoft Word format. Word adds tons of formatting garbage that results in bloated files and messes up the presentation when content gets brought into HTML.

When Microsoft released Office 2007, they touted switching to an XML-based document format for all of the apps. But all XML is not created equal.

Case in point: I am currently working on a project that is going to involve receiving content for a number of web pages in a tabular form, either in Word or Excel format. A spreadsheet, essentially (if not technically), with each page represented by a row, and its text content in a cell. I will be writing a PHP script to parse the spreadsheet data and generate a set of HTML files with the content loaded in them.

I’m currently trying to determine if Word or Excel would be the better format to receive the content in, which involves opening up .xlsx and .docx files in BBEdit and looking at the raw data stored within them. I’ve managed to identify the embedded XML files in each that hold the actual content. These files store the same actual text content, but their XML schemas vary based on the needs of Word and Excel.

So… how do they match up? The XML file I pulled out of Excel is 14 KB. The one from Word is 202 KB. For the mathematically inclined amongst you, that’s a little more than 14 times larger. Yes… another (perhaps more hyperbolic) way you could say it is that the Word document is exponentially larger.

That’s just ridiculous.

What makes up the difference? Well, the Excel file’s XML is nothing but basic tags. There are no attributes on any of the tags, as far as I can tell. It’s pure semantic structure. The Word XML, on the other hand, is almost nothing but attributes. And there’s nothing smart about them either. Most of them are assigning fonts to the text. The same font names, over and over and over again throughout the file.

That’s… beyond ridiculous.

Can a developer use an iPad as their only portable “computer”?

I am at a crossroads in my work situation. Since 2008 I have worked as a freelance web developer, which naturally meant using a laptop as my primary/only computer. I worked mostly from home, but I would frequently go to coffeehouses, and occasionally work on-site at client offices. A portable computer was a must.

The same week that Steve Jobs announced the 11-inch MacBook Air, I went out and purchased one. It was exactly what I wanted: a full-blown Mac, (almost) as small as an iPad (which of course I already owned as well, but mainly used for testing, occasional gaming, and watching all six seasons of Lost in the span of a month on Netflix, not for “real work”). I loved the MacBook Air. I said it was the best Mac I’d ever owned, though I admitted it was a tad underpowered. Enough so that when SLP needed a new computer 6 months later, I gave her my MacBook Air instead and bought myself a new, slightly more powerful version of the same.

That MacBook Air has been my only computer ever since. In fact, shortly after switching to it full-time, I wrote a glowing review of it right here. But last April I moved my business into a storefront studio space. I’m not going to coffeehouses anymore. Now, more often than not, clients come to me instead of the other way around. And all of this time I’ve been sitting at a desk, with that same 11-inch MacBook Air hooked up to an HP 23-inch LCD. (Yes, HP. I may be a self-proclaimed Apple fanboy, but even I can’t justify the expense of one of their Cinema Display monitors.)

It’s in this context that I’ve finally really become aware of the performance limitations of the 2010 MacBook Air. It’s unbearably slow with Adobe Creative Suite apps. It’s even unbearably slow running Panic’s Coda. And no computer today should choke up on what is essentially a glorified text editor. (That said… As much as I love Coda, it does seem bloated and slow almost everywhere I’ve used it. There’s no comparison to the blazing speed of BBEdit, which I also love, but Coda has some features I prefer, so it remains my main coding tool.)

Over the past few months, as my workload has increased and my patience has diminished, I can no longer pretend that the 2010 MacBook Air’s performance is adequate for my needs. I know the 2012 Airs are at least 3 times faster than the one I have, and I’m sure this year’s will be even faster, and maybe even have a Retina display, and therein lies the problem: I’ve been desperately wanting to upgrade my Mac, but I couldn’t bring myself to buy one of the current 11-inch Airs (the only portable I will consider) when they’re getting so close to a refresh.

At the same time, I have a major crunch at work over the next 3 months. I couldn’t afford to wait on my creaky old Air anymore. So last weekend I settled on a compromise, borne of the fact that I almost never touch my MacBook Air outside of the studio anymore. I got a Mac mini for the studio. I went with the more powerful quad-core i7 model, which is rated on Geekbench as at least 6 times faster than my old MacBook Air, and almost twice as fast as the current ones.

I’ve already noticed a huge difference. Adobe Creative Suite is way faster, almost to the point of no longer being infuriating. (But that’s another story.) Coda is still occasionally sluggish, but that may have more to do with the fact that I’m working with files on our local file server over a questionable WiFi connection. I should try putting the files directly on my hard drive to see if it makes a difference.

But now I am faced with a weird dilemma. This is the first desktop computer I’ve owned since the Dell I had back in 2001, and the first Mac desktop since even before that. (It was a Bondi blue G3 tower, if you were wondering.) The dilemma is this: in a world of iPads, where I am already pretty much never touching my MacBook Air outside of work, do I really need a portable Mac at all?

I still have the Air, of course, and have continued to lug it around next to my iPad in my Tom Bihn bag this week. But why? In the two meetings I had this week at client offices, I only used my iPad. Maybe the iPad is really all I need. Maybe?

I have a few months to find out. I won’t consider buying another MacBook Air until the new models are out, so in the meantime I will experiment. I will try only using the iPad for any and all computing tasks outside of the studio. I’ve begun that today, by typing this blog post on it as I sit at the kitchen counter with my Saturday morning coffee. It’s been a bit of a challenge. I gave up on using the WordPress web interface and switched to the (marginally better) dedicated iPad app. And I’ve made lots of typos… some that iOS auto-corrected, some it didn’t, and some false positives it shouldn’t have. (C’mon, iPad… use some context, would ya? Why would anyone ever write “you we’re”?)

The biggest challenge will be if I have to write some actual code. But it’s a far different world for that than it was even a year ago. I have a handful of coding apps on my iPad, though nothing I have could be more valuable than another pair of apps from Panic: Diet Coda (great name, BTW) and Prompt, a terminal app. I haven’t had much call to use either of them… yet. But I’ve been comforted knowing they’re there.

At the end of this month we’re planning a family vacation to Utah. That may prove to be the ultimate test. Do I dare leave for a week with only my iPad? Honestly, I’m not sure I can. It will depend on the state of my various work projects at that time. But I’d like to be able to give it a try.

I’ll post follow-ups here as the experiment continues.

Building a centered gallery grid with flexible column count for responsive web pages

It took an untold number of fruitless Google searches and a couple of hours of trial and error to get this to work. I think part of the problem may have been that I simply didn’t really know how to describe what I’m trying to do in a way that would yield good search results. And so, I hope now that I have a solution, sharing it here might help someone else.

The situation: I have a web page that contains a gallery of square images. The page is responsive but the sizes of the images are fixed. I want the page to automatically show as many images across as will fit in the layout on any particular screen, creating anywhere from one to five columns as needed. And, it needs to stay centered.

I got all of this going pretty easily… all except the “it has to stay centered” part. I was able to get it to work if there was only a single line of images, but as soon as they wrapped to multiple lines, the container element went to a full width and the images became left-aligned. It took considerable effort to discover a solution, although that solution itself is embarrassingly simple. I was hung up on a couple of possible approaches that got me nowhere, which probably contributed to the problems I had finding the right way to do it.

So… here we go. We’ll start with an unordered list:

<ul class="gallery">
  <li><img src="image.jpg" alt="" /></li>
  <li><img src="image.jpg" alt="" /></li>
  <li><img src="image.jpg" alt="" /></li>
  <li><img src="image.jpg" alt="" /></li>
  <li><img src="image.jpg" alt="" /></li>
  <li><img src="image.jpg" alt="" /></li>
  <li><img src="image.jpg" alt="" /></li>
  <li><img src="image.jpg" alt="" /></li>
  <li><img src="image.jpg" alt="" /></li>
  <li><img src="image.jpg" alt="" /></li>
</ul>

And here is that embarrassingly simple CSS:

ul.gallery {
  text-align: center;
}

ul.gallery li {
  display: inline-block;
}

OK, that’s not really all of the CSS. Your li tag needs height and width properties, and you may want to give it margin as well. But those values are going to be specific to your project.

TinyMCE and the non-breaking space problem

Let’s get right to it then: TinyMCE is great, but I am annoyed by its willingness to take users’ multiple spaces literally! Collapsing multiple spaces is a basic characteristic of HTML, and allowing users to carelessly (or intentionally, which they still shouldn’t do) insert multiple spaces by converting every other one of those spaces into the &nbsp; (non-breaking space) character is BAD!

IMHO.

Anyway… start with a pinch of Stack Overflow, add a dash of the official TinyMCE documentation, along with a heaping tablespoon of reading between the lines, and I have a working solution to the problem. My installation of TinyMCE now automatically converts any &nbsp; characters in the text back into regular ol’ spaces.

It’s a bit draconian; after all there are legitimate uses for non-breaking spaces. But 95% of the times they’re inserted by TinyMCE are user accidents, and another 4.9% of those times are abuses like faked “tabs” that would be solved better by another approach altogether. (There are reasonable CSS-based solutions that work in some cases, but let’s talk HTML’s need for tabs another time.)

Anyway… here’s the gist of the solution. You need to create a callback function. Here’s mine:

function my_cleanup_callback(type,value) {
  switch (type) {
    case 'get_from_editor':
      // Remove &nbsp; characters
      value = value.replace(/&nbsp;/ig, ' ');
      break;
    case 'insert_to_editor':
    case 'submit_content':
    case 'get_from_editor_dom':
    case 'insert_to_editor_dom':
    case 'setup_content_dom':
    case 'submit_content_dom':
    default:
      break;
  }
  return value;
}

It may look like there’s a lot of extra stuff in here you don’t need; I included all possible values for type inside the switch to be prepared for the future. You do want to check for type == 'get_from_editor' though; otherwise your replace() is going to run under way too many conditions and may cause weird behavior like new paragraphs appearing when you just want to insert new text into an existing one, or browser-generated warnings about leaving the page when you try to save. (I ran into both as I was fine-tuning this.)

Now that you have your callback function, you just need to… you know… call it. That’s done inside tinyMCE.init(). You’ll need to include this line somewhere:

cleanup_callback: 'my_cleanup_callback',

Be sure to check if cleanup_callback is already declared somewhere, and also don’t forget the comma at the end, unless you’re inserting this as the last line.

Once you’ve got it all rolled out to your site, you’ll need to clear your cache. I’ve found TinyMCE’s configuration files can be annoyingly persistent in the browser cache.

Yes… you have correctly observed that I had to use non-breaking spaces myself in this post, to get the indents in the code samples to show. Pay no attention to the man behind the curtain. And remember my complaint about the lack of tab characters in HTML. Another day.