At the time I published this article, the not-named theme is not live but I’m ensuring that I’m deploying its basic framework using best practices, i.e. creating a WordPress child theme. After that’s done, I’ll proceed with the website redesign.
Why use a child theme?
WordPress allows you to install a theme from anywhere and you are allowed make modifications as you wish, in any method you see fit. However, as the adage goes, just because you can doesn’t mean you should. I was mainly concerned with theme updates and how changes by the original author would affect modifications by me.
Whenever you use an authored theme/template for any content management system, there most certainly will be updates released over time that address broken functionality, security issues, and feature enhancements. How you choose to make customizations to your website theme will ultimately affect how well (or poorly) your upgrade will happen. For example, if you dive right into the style.css file that is included with your WordPress theme, changes you make will be overwritten if you install any update from the original author.
With that in mind, child themes work well because you can, in most cases, keep your own custom tweaks to a WordPress theme when a theme update is installed. How is that possible? A child theme is a separate directory in wp-content/themes/ that contains overrides to the original theme you are using. Normally, this new directory will contain only a style.css and functions.php file. WordPress will first check your functions.php and use original theme’s code to render the website, while pulling in your style.css overrides on top of the original theme’s CSS.
Have you ever been asked, “is metadata really that important?” No, you haven’t? Well, of course not —nearly all photographers, videographers, digital asset managers, and media librarians understand that media metadata is crucial to organizing files. Can you imagine curating years of digital imagery by using some strange app to copy them all to a folder, which then proceeds to reset their creation date? OH, THE HORROR.
No one would ever seriously use such a disastrous DAM system but you’d be surprised how many mundane consumer tasks are capable of ruining your photos and videos. Simply changing the container type of your old .AVI videos can inadvertently mess things up when you finally decide to archive them. Using something like Samsung’s Kies app to transfer photos/video off a phone or camera could destroy metadata (I kid you not, it really does).
Why bad data is bad
How could incorrect date/times affect your photo/video workflow? Try importing those modified files into something like iPhoto or even flickr.com. For example, with EXIF/IPTC tags changed, the timestamps on all your historical DSC2491.JPG from June 2006, 10:52 a.m., will get uploaded with TODAY’s date and current time. Not quite convinced? Okay, now try searching for your photos taken in 2006. You can’t because the DAM or website will honestly reply that such media doesn’t exist. You also won’t be able to sort your photos/video by their origination date (when they were captured by the device).
How to easily screw up your multimedia timestamps
I had some BlizzCon 2010 footage shot using an old Creative Vado HD which I offloaded to a staging folder a while back. These videos are AVIs with an H.264 video track and AC3 audio track. It would be more ideal to have these stored as standard H.264 MP4 files with an AAC audio track, for the purpose of loading into popular NLE apps like iMovie or Final Cut Pro. Theoretically, you could just cram the AVIs as a batch into Handbrake and bulk transcode, but that would be like compressing a JPEG into a JPEG —you’d risk an unnecessary loss of visual quality, even if minor. The best thing to do is feed the file through FFmpeg, passing the video data along without conversion but allow it to transcode the audio track to AAC. Plan’s set, right? WRONG.
Even though I can easily batch all the videos through transcode/passthrough script, the output files would have TODAY’S timestamp, rather than that of the original footage. Imagine searching your DAM system for the BlizzCon media, which should be dated late 2010 …only to find out that they’re dated April 2014. WTF? Serious noob mistake!
Make things right
A simple addition to an FFmpeg script can fix the problems caused by creating a batch of new, properly transcoded files. My original script was called “vado.” Here’s what I started with:
This bash script in OS X (using a MacPorts variant of FFmpeg) pipes all AVI files found in a folder through FFmpeg, preserving the video stream but converting the AC3 track to AAC, and saving the results as files of the same name but with an .mp4 extension.
If your list of source AVI videos may look like this (sorted by timestamp):
Unacceptable! Note that the MP4 timestamps have a different date than the original files. If you’re organizing your multimedia by event date then this isn’t going to work. Here’s how to make things right. Luckily the source files have associated metadata which can be applied to the destination files. With the touch command I can copy the timestamp properties of the source files using the -r flag. The new vado script reads:
Perfect! Notice that the dates of the processed MP4 videos match up exactly to the original AVIs. Now I can import these MP4 videos directly into a consumer DAM like iPhoto or a video NLE with no metadata issues and they’ll end up in the correct spot in the media timeline.
Sure, there have been many tutorials done about how to replace the memory chips in Macs but doggone it, I just had to make one myself. This one is custom-tailored for the IT staff at the public agency where I work to demonstrate how simple the procedure is. Don’t worry guys, it’s a piece of cake!