Why I Changed the Licensing of My Photos on Flickr to Creative Commons BY-NC-SA

I just got through changing almost all of my 1200+ photos on Flickr from an all rights reserved license (the default) to the CC BY-NC-SA license. That is, Attribution (BY), Non-Commercial (NC), and Share Alike (SA). Breaking that down, this quite simply means:

  1. Attribution: If you use my work, you must attribute it to me.
  2. Non-Commercial: My work may not be used for commercial purposes.
  3. Share Alike: If you create a derivative work based on my work, you must release that under this or a similar license.

Why on earth would I simply give my work away like this? My primary motivation is exposure. I feel that releasing my works like this will bring more attention to my work. Plain and simple. I’ve been inspired by artists like Nina Paley and musicians who share their music on sites like Jamendo — all under Creative Commons licensing.

I chose this particular license because I feel it is the most fair to all parties involved. For example, I do not collect model releases from any of my subjects. This would be quite difficult in situations such as the Des Moines Farmers’ Market or shooting on the streets of places like San Francisco. Therefore, the Non-Commercial clause is pretty much required.

Attribution to me is the very least anyone can do to repay me for my work, and it is all I ask from these photos I present on Flickr and this blog.

Share Alike, while a restriction on the freedom to use these works, is also a small price to pay for remixing my works and creating your own from them. Think of it as paying it forward. I gave freely of my work, so you must do the same.

Finally, my intention of seeking attention is without ambition. I’m simply sharing my work and hoping for a greater audience.

Migrating from Textpattern to WordPress


I’ve been happily running this site on Textpattern (version 4.2.0) for a couple of years now with no issues or concerns. It has been a solid platform and I found a good template which I was able to customize to my liking. Recently, however, my wife has expressed interest in starting her own blog (more on that to come), and she wanted to use WordPress primarily because she had used it before.

Over the past couple of months, I’ve been working a lot with WordPress in support of Lori’s effort to bring her blog to life. We’ve been running an internal development site during that time to find the right theme, customize that theme, play with different post presentations and build some content prior to launching. She’s very serious about taking this blog live, so I figured I should probably get serious about learning as much as I can about WordPress.

This post is all about my experience converting from Textpattern 4.2.0 to WordPress 3.0.4.

Finding a Theme and Testing Migration

The first thing I did was install WordPress 3.0.4 on my internal server so I could play with different themes and test migrating my old content. Since I’ve been doing a lot more photography recently, I tried to find a photo-centric theme. After looking at four or five different themes, I settled on F8 Lite by Graph Paper Press. I’m a big fan of its clean, simple grid presentation and the focus on photography.

During my initial testing I discovered that the standard process for creating a child theme under which to make your customizations did not work. I’ve not figured out why it breaks, so for now I’m working with a full copy of the original theme. I’ll have to keep track of what I’ve customized so I can re-apply those customizations when an updated version of this theme comes out (hopefully that won’t be often).

Another issue I found while researching migration from Textpattern to WordPress is that the built in tools for Textpattern migration have been broken for quite some time. Some people have developed some work-arounds, but it seemed the process was hit or miss depending on the versions of each platform in use. I noted, however, that there was a generic import tool which would utilize the old site’s RSS feed to import posts. I tested this out and it worked very well. All the post content was imported (some caveats on that later) and only some minor formatting issues were introduced.

After playing with the F8 theme and my imported content for several hours I decided to go ahead and start the process of migrating my live site.

Migration Preparations

Any successful migration starts with a full backup of the old site so you can restore it should something go horribly wrong. Textpattern, just like WordPress, is a MySQL/PHP based site, so there really are just two things to back up: the database and the site files.

First, I backed up the database with the following:

mysqldump -u root -p txp_database | gzip -9 > 20110116_textpattern.sql.gz

Breaking that down, I called mysqldump with a root account, prompted for that user’s password (-p) and dumped the database called txp_database. Since mysqldump outputs to standard out, I piped that through gzip with -9 for maximum compression, then re-directed it into the final file. I like to put the date as the first part of a backup filename so it is easier to distinguish later if I have a bunch of backup files in the same location.

Next it was time to back up the textpattern site files. This contained all the PHP code plus all of the customizations I’d made to that code and the site graphics. After changing to the directory under which all this lives (varies by server configuration, but could be /opt/textpattern or /usr/share/textpattern) I then issued the following:

sudo tar -czvf /tmp/20110116_textpattern_files.tgz ./

Breaking down this sequence, I escalated my privileges to root with sudo, issued tar to create (-c) a compressed (-z with gzip, use -j for bzip2), with verbose output (-v), file with the given name (-f) containing the contents of the current directory (./). Note that I placed the output file in a different location than the current directory to avoid any problem with the tar process trying to recursively include its output file in the input. It would also be a good idea to move both the MySQL dump and this backup file to a common location for safe keeping — leaving either under /tmp is a bad idea because some systems clear the contents of that folder upon rebooting.

At this point, I could completely mess up Textpattern and I would be able to utilize the contents of these two files to restore it all back to its current condition.

Migration and Importing Textpattern Content

Once all the backups were out of the way, it was time to move the WordPress files and database from my development site to my “live” Web server. This was the tricky bit, as I discovered some of the initial setup was migrated with the database and there was no easy way to re-configure those settings. Most notably, the site URL kept re-directing me to my local dev site after I migrated the files. I ended up starting with a fresh copy of the database, but using my modified WordPress files. I had to re-configure the site and re-import the Textpattern content, but that was easy to do since I already had a dump of the rss feed.

First, I wrapped up my WordPress development files in a tar/gzip file, similar to backing up by issuing the following after changing to the root of the WordPress folder on my development server:

sudo tar -czvf /tmp/20110116_wordpress_files.tgz ./

I then copied that tgz file up to my server and uncompressed it to a WordPress folder by changing to that folder and issuing:

sudo tar -xzvf /tmp/20110116_wordpress_files.tgz

Next, I issued the following sequence to get into MySQL, then issue SQL statements to create a fresh database:

mysql -u root -p
create database wordpress;
grant all privileges on wordpress.* to 'wp_user'@'localhost' identified by 'wp_password';

Breaking that down, the first line opens a MySQL command prompt with root privileges. The next line creates the wordpress database. The third line simultaneously creates the user ‘wp_user’ with the password ‘wp_password’ and grants that user full access to the wordpress database. The last line quites the MySQL interface.

At this point, my old Textpattern site was still live, but I had to configure the WordPress site. I decided to quickly switch over to the WordPress site and finish up the configuration. To do this, I simply had to edit my /etc/apache2/sites-available/default file so it pointed to the location of the WordPress site instead of the Textpattern one. All the rest of the settings in that file remained the same.

Once that was done, I hit the wp-admin URL to complete the site setup and create a site administrator user account. I then logged in as the site administrator and fired up the rss-importer plugin, which I had already installed as part of my development site, and it came over when I copied those files. But first, a word on getting that RSS content out of Textpattern. . .

The rss-importer plugin takes as its input an RSS XML file. In order to generate such a file from Textpattern, I had to go into the site settings and set the RSS feed to present all of my posts in the feed and set it to place the entire contents of each post in that feed. Once that was set, I visited the site and right-clicked on the RSS link, saving that link as a file called rss.file. Within my WordPress development site, I was then able to upload the contents of rss.file into the rss-importer plugin. Here are my caveats about this method and why it worked for me, but might not work for you:

  1. My Textpattern content was all code/text. All of my images were hosted from my Flickr account. I don’t believe site embedded pictures would have transferred with this method.
  2. There is a 2 MB file upload limit in WordPress. I only had 108 posts in Textpattern and the RSS XML file was under 500 KB. I believe you can increase the 2 MB limit, if needed.
  3. The import wasn’t perfect. Some formatting was lost. I spent a significant amount of time going through each of the 108 posts and adjusting the formatting. A better import method may have preserved this formatting.
  4. The categories did not import either. I had to go through all posts and assign categories and tags. I’m not sure if any of the other import methods would preserve categories. I wanted to re-work these anyway, so this wasn’t a big loss.

Aftermath and Conclusion

So, yeah, I had to touch every post and fix some formatting. I also had to set up new Categories and set tags on each post. Good thing I’m not a terribly prolific blogger, or I would have had some tough choices to make. As it was, 108 posts weren’t too bad. The later posts were more complex, requiring more attention. As the posts got older, there was less to do, so the last half to one quarter went a lot quicker.

Overall, I’m happy with the look of the site and the way this theme integrates with WordPress. As mentioned before, I still need to work out the child theme issue, but hopefully I can figure that out in my development site soon. I’m also going to dig into the CSS of the site and change up some of the colors. I don’t like the red article link headers and hyperlinks, and I want some of the fonts to be just a bit larger.

My work on this site will never be done, but that is the way of the blogger. . .

Better things coming soon. . .

I’ve got a couple of ideas boiling in my head, building up pressure. I’ll be letting them out on this site over the next month or so. In the mean time, here are some updates on older posts.

  • 420 Picture Of The Day# is up to 23 pics.
  • CIALUG meeting minutes for April are missing ‘cause there wasn’t much discussed.
  • For Good Places to Eat in the Des Moines Area add Daddy O’s to the list. Close to my home, and they have Yam Fries! Yummy!
  • Tip: Catching up on podcasts at 2x speed works, but only if you don’t get too far behind. Had to perform some triage on my back log of podcasts this week.
  • SomaFM donation required me to sign up again for PayPal. UGH. Guess that just shows how much I like SomaFM, right?

Site reset to use GMT +0 time stamps

Just changed the site to use Greenwich Mean Time instead of my time zone. The DST function on the site was not working, so rather than try to fix it, I’m opting to use GMT which does not observe DST.

On a side note, I used to wear a wrist watch which I set to GMT. How lazy is that? I’d rather do a quick calculation in my head than reset my watch twice a year. . .

Bump for bump’s sake!

OK, 26 days is a bit long to go without an entry. I’m in danger of falling into my old habit of firing off a bunch of posts, then letting the site languish in my absence.

So, this is a obligatory “bump” post to make sure the site still works.

I should give you, the reader, something to make your visit to this site worth your while. Here goes (it isn’t much).

I’m not usually a big fan of non-fiction, but I recently picked up “Scar Tissue,” the auto-bio by the Red Hot Chili Peppers’ front man, Anthony Kiedis (ISBN 1-4013-0101-0). Wishing to remain brief and not spoil anything, I’ll simply say that this book is a view into a life in struggle against addition. This book must have been good therapy for Anthony, and serves as a warning sign post for anyone who thinks perusing a rock star drug addict lifestyle sounds like a good idea.

That’s all for now. I promise a better story next time — My (Recent) Experience with PayPal and eBay. . .

Demo FAIL, but ReciPants GO

Well, my demo of the Linux Gamers Live DVD didn’t go so well. My crappy old computer did not perform very well, so we ended up borrowing someone’s laptop to perform the demo. Wasn’t too exciting. I just brought up each game on the disk and played them for a bit. We also discussed some other Linux-friendly gaming.

After that FAIL, I needed some success. I finally got some relief with the ReciPants database issue. The problem seems to be with my method for transferring the database from the old server to the new. Here’s a brief synopsis of what I did to get it to work:

Migrated from the old server (with MySQL 3.23) to a virtual machine running CentOS 3 (also with MySQL 3.23).

On the old server:

  • Exported the database with the following command (no extra options used, my mistake was exporting with —opt and/or —add-drop-tables):

mysqldump -u root -p ReciPants > ReciPants-database.sql

On the “new” server:

  • Set up ReciPants v1.2 on the new server, per the Web site instructions — including running the SQL scripts tables-mysql.sql and ref_data.sql.
  • Once I confirmed that worked OK, restored the data from the old
    server with the following command (the -f is necessary, as there is a
    non-critical error early on that will halt the process):

mysql -u root -p -f ReciPants < ReciPants-database.sql

Again, I need to test the above method on MySQL 5.x, but I believe it will work just fine.