In the admin area, you can create custom thumbnails for your images. An image is supposed to pop up that you can drag a thumbnail over. But for some reason, when I opened up the window to create a thumbnail, the image didn’t appear. The image was coming up blank, like if you link to an image that isn’t there.

The actual image was there on the server, so that wasn’t a problem. I followed the trail a bit and figured out that the image for the thumbnail creation process was created by a script, nggshow.php (part of the Nextgen plugin). The script itself was working. It fetched all the information, put it in an object, and then it was supposed to spit out an image.

The problem was that the final output is supposed to be a jpeg. But, some white space was added at the top of the file, so the output was corrupted. The jpeg was there, but the browser couldn’t render it because of the added white space at the top of the file. I don’t know where exactly that was coming from, but it was added in somewhere in the Nextgen Gallery plugin files.

I tried to go through, eliminate any extra lines outside the php tags, and get rid of the white space. I eliminated one of the two newline characters that was in the output, but I couldn’t find the second. After pulling my hair for a while, I realized that I was working with an older version of Nextgen Gallery (1.5.3). I updated to the most recent (1.5.5), and it worked fine. Doh.

So… simple solution. Upgrade to the latest version of the plugin.

But I digress. WordPress is awesome. You can have a blog, like this. You can set it up more like a static site (see this portfolio site, Olinda Gibbons Photography). You can do… just about whatever you want if you get a little creative with the template.

What’s more, there are tons of useful plug-ins waiting for you, so you don’t have to spend as much time custom coding stuff. One simple task I needed a solution for was backuping up my WordPress database and files. I used to use WordPress Database Backup, but I don’t think it’s compatible with WordPress 3.0 and it didn’t actually fulfill all my needs.

After some searching, I finally found a suitable replacement this morning: Updraft.

How I Use It

The cool thing about Updraft is that it doesn’t just backup your database. What good is the database if all your uploads are gone? You’re gonna have a lot of wholes in your posts where there used to be pictures!

Updraft takes this into account and backs up four things – your database (pretty important), your plugins (which you might not have locally if you installed them all automatically), your uploads, and your themes (well, you should have this saved locally for development purposes anyway).

You can schedule the back-ups. You can select a custom folder to save it in (anywhere on the server; not just in the wp-content folder). If you have a cloud file storage service, you can send the files there. And you can specify how many backups it should retain, so you don’t end up with a hundred backups floating around your server by the end of the year.

This solution is perfect for me.  I set Updraft up on all of my WordPress sites so that it automatically backs everything up. It dumps it into a folder above the public_html folder (something like /home/backups). From there, I can set up SyncBackPro with a scheduled backup to download the backups from the server and store them locally on my external hard drive.

So what are you waiting for? If you don’t have a backup plug-in installed already, go get Updraft. Hopefully you’ll never need it… but it could be a life saver.

I just launched Digital Photography How To.

It’s a blog aimed at beginning to intermediate digital photographers. More about my reasons for writing it here, but the idea is to help me organize my thoughts about photography and hopefully provide a resource for other beginners that are looking to get into photography.

Aside from articles about photography, another of my goals is to maintain the Picture of the Day section. Although I’ve toyed with 365′s and 52′s (taking a picture every day or every week), they’re a lot of work and commitment. Instead, my goal here is to look through flickr for at least a few minutes every day, pick out a nifty photo, and explain what I like about it. You can’t become a better photographer without looking at other people’s work, can you…?

To get things started, I took a stab at developing a website for her: olinda-gibbons.com.

I’m not 100% happy with the theme, but we kind of had to launch it under short notice so that we could post/sell images from a few events that she worked. I’ll probably re-vamp the theme over the summer when I have free time, but at the moment there are some really cool things in there that I want to show off.

Auto Portfolio with a jQuery Gallery

One feature I definitely wanted to have was a portfolio page with some kind of nifty jQuery functionality. I looked through some options on this list of jquery gallery plug-ins, and I liked the galleria plug-in. Although I think it might now be out of development, I was able to get it working to my satisfaction with a static html demo.

Of course, I wanted to be able to easily and automatically create and change portfolios with WordPress, and the NextGEN Gallery plug-in for WordPress made that possible. I created a custom template file to display a gallery with the mark-up necessary for the Galleria plug-in to work. Now all I have to do is upload the pictures to a gallery, insert a piece of short code, and instant portfolio page. Nice.

There are two samples on the site now: Olinda’s portrait portfolio and her events portfolio.

Integrating PayPal Web Payment

The second thing I needed to do was integrate PayPal’s web payment system so that we could accept payments and then print/ship pictures after events. Portrait sessions can be handled through invoicing and other payment methods, but PayPal makes it really convenient to handle larger groups of people more efficiently.

Again, this was made possible by the NextGen gallery plug-in. I marked up a custom template to include the html mark-up for the PayPal payment buttons. Now, I just upload the proof images to a gallery and with one piece of short-code I have an instant ordering page.

This is a place where I definitely want to work on a better design, but I was working under short notice and just wanted something functional…

Example: William Paterson Fashion Show proof album.

How Did I Do It?

I plan to write up some detailed guides to how I designed those pages. I’m not sure if I’ll post them here or start up a blog section on olinda-gibbons.com and post it there. Either way, I’ll post about the guides here because I think they’ll be valuable for anyone looking to develop a site for a photographer. The more I work with it, I’m really impressed with the combination of WordPress and the NextGen gallery plugin.

But the good news? There’s no new infection. No script hijacking. No iframe injection. See my previous post for more details.

Fuck you ixwebhosting. That’s all I’ve got to say.

I don’t see any other explanation except that IXwebhosting’s servers are compromised, and their weak security was in turn compromising my site. I’ve had no problems with HostGator, and I love it.

I ultimately chose ixwebhosting.  Two years later, I’m not sure why.  I’m pretty sure I read reviews and determined that they would be a reliable host.  That estimate turned out to be… dead wrong.

In the first year, I experienced a lot of issues with ixwebhosting.  Despite a “99.9%” uptime guarantee, there were times when a problem with the sql server rendered my sites (all database driven) completely inaccessible.  In my second year, these issues seem to have been worked out, but that first year left a real sour taste in my mouth.

Then, over the past year, I’ve been battling various infections to my website.  At first, they were iframe injections that would periodically crop up.  For a time, I wasn’t maintaining any of these sites (although they were still getting a trickle of traffic), and the iframe injection got me blacklisted from Google.  Eugh.

After I sorted that out, I got hit with something like a gumblar infection.  The research I did suggested that this was a local issue – that my computer was compromised and that some kind of trojan was sending my ftp information to a remote server, which then injected script elements into my website.  I cleaned everything up, cleared my ftp information out of filezilla, and then used the web-based control panel with ixwebhosting to change my ftp password.  Still, these script elements kept coming up.  I also put a fresh install of Windows 7 (which I love, btw) onto my desktop.  If there was some kind of local infection, this would have wiped it out – and it didn’t stop the problem.

By this time, I was convinced that something was wrong at ixwebhosting.  They told me that my computer was compromised and that this led to the injections, but it just doesn’t add up.  I tried several different virus/malware scans, and nothing was found.  I changed my ftp password (and never used it in my ftp client).  I even put a fresh install of Windows on the machine.  There’s no way it’s a problem on my side.

This month, my hosting account with ixwebhosting ran out, and I dumped ‘em.  I switched to HostGator and paid for 6-months up front.  So far, I’ve got no complaints.  But it’s only been a week, so I’m not quite ready to pass judgement on them just yet.

As for IXwebhosting?  I’m ready to pass judgement on them.  They suck.  Stay away.  I signed up for two years when I bought my hosting from them, and within a few months I regretted it.  If I hadn’t been locked in for two years, I would have dumped them long ago and switched to a new host.

Initially, I had problems with iframes popping up on my pages. I cleared the themes and deleted the iframes, and periodically they would re-appear. This was annoying, and it was also damaging to my sites (although not a huge concern, since I didn’t update them regularly anymore and I wasn’t really expecting to earn much profit/traffic from them). Then, I noticed that script tags were appearing in the pages, and the whole situation got even more aggravating.

I would remove all of the script tags and clean up the entire server (replacing three wordpress installations and cleaning up three wordpress templates). A few days later, the script tags would be back.

What the heck? I eventually found some reading on the topic – start with this post about Gumblar and then look around Unmasked Parasites. I repeatedly scanned my computer with different virus programs, but I was unable to find any kind of parasite that would transmit my ftp information to a remote server.

Nonetheless, I decided that something like this had to be the problem. I again cleaned up the server, replacing all three wordpress installations and cleaning up the templates. I then cleared all of the passwords out of my FTP client (Filezilla). Finally, I went to my hosting account through my web browser and changed my FTP password to something new and never used it in Filezilla.

So far, so good. It’s been a week or so, and the virus hasn’t cropped back up. Oh, I hope it stays away…

I wanted to make a website for the yearbook club and post some of these photos in galleries. It’s a great way to promote the yearbook and the kids like seeing themselves online. There were some legal issues that I’m working out with the administration, but there were also some technical issues.

Although I obviously can create and host my own website, I don’t have access to web space with php hosting for the yearbook club. I didn’t want to mix school stuff with my own stuff, so I didn’t want to host it here. The simplest solution for me (which I also use for class blogs) was a free blog hosted on WordPress.com.

That is, until I realized that I couldn’t easily embed slideshows from other websites (i.e. Picasa). Doh! The embed and iframe tags that are usually used to include slide shows gets wiped out by WordPress’ security.

I figured out a work around, though. http://www.slideshare.net/ allows you to create and host unlimited slideshows for free. They also offer an option to embed the slideshow into a WordPress blog, and its compatible with a free WordPress.com blog. This solved my technical problems and I don’t have to worry about storage space.

Shortly, I’m going to write up an article about this for Associated Content. I’ll link to it when it’s published. In the meantime, here’s a sample gallery. The pictures are just of my backyard. I’m still working on the legal issues, so I haven’t actually hosted any slideshows of students yet.

Quite some time ago, I gave up on maintaining my various sites – notably this one and Web Cash. I simply didn’t have the time to add new content, and I’d had trouble with the theme files getting infected with iframe injections.

Last month, I decided to clean up the files and, if nothing else, keep the sites alive as they were. They bring in a small bit of revenue from ad sales, and I don’t see any reason to pass up money that could be coming in if the sites were functioning properly. So, I cleaned up all the template files, changed all the passwords associated with my hosting account and FTP accounts, and thought all would be well.

But it isn’t!

For whatever reason, I can’t seem to shake this damn problem. And every time I notice it’s back, it raises my level of anger another notch.

The infections routinely affect three files in my template: index.php, header.php, and footer.php. Each file has a new line that creates an iframe, which inevitably loads some invisible links or malware. This iframe can also get your site blacklisted from Google (after cleaning up the files, my site was re-listed on Google and I’m getting some more search traffic).

I really can’t figure out how or why the files keep getting re-infected. I’ve repeatedly changed all the passwords associated with my web host and with WordPress. I’ve updated WordPress to the latest version. I’ve checked the file permissions, and they seem correct. Arg…!

Tonight, I found one potential problem that might have been the culprit. I installed the Antivirus plugin for WordPress, and it found a random script tag in my header file. I’m not entirely sure that a script tag could lead to these files being edited permanently, so I don’t know that it’s the culprit. But let’s hope… because I’m tired of checking on things and finding that the files have been tampered with yet again.

There are a number of things I like, but there is one thing that everyone can use: Google’s hosted Javascript libraries.

Last year, Google launched a project to host a handful of popular Javascript libraries. Among the initial offerings is jQuery – the Javascript library that I use on this site. They also have some other widely used options – like prototype and MooTools.

Basically, Google hosts the most recent (and some legacy versions) of the library on its server. You can then link the remote copy of the JS library to your site instead of hosting it yourself.

Why Should I Use Google Hosted Javascript Libraries?

Because it could be faster.

If two sites use the same Javascript library but host it locally, the user has to reload and recache the library for each site. jQuery.js on life-of-brian.com is different from jQuery.js on css-tricks.com – even if the file is exactly the same.

By pointing the user’s browser to the Google server, it will recognize that .js file in the cache and not download it a second time. So if life-of-brian.com and css-tricks.com both used the jQuery library on Google’s servers, the user would have to cache it once – and it would be preloaded when he or she visited the second site.

A secondary benefit (of concern only to large sites) is that it doesn’t put a strain on your bandwidth. This shouldn’t be a big deal for most people, but some high volume sites may find this comforting.

How Do I Load Google’s Hosted Javascript Libraries?

You could use the fancy load() function of Google’s AJAX API, or you could simply add a <script> element using the remote address on Google’s server.

I chose to go the second route with this site. I wanted to load both the jquery library and the jquery ui library (mainly for the tabs in the sidebar), so I included the following two lines in my header:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js" type="text/javascript"></script>
<script src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.5.3/jquery-ui.min.js" type="text/javascript"></script>

You can find a list of all the URLs on the AJAX API documentation page.

Why Not Do This?

I don’t see a lot of potential for harm, but there could be some drawbacks.

No version control. Presumably Google is going to keep hosting important legacy versions of each library, but this takes version control somewhat out of your hands. It also means you can’t use the development releases – only the stable releases are hosted on Google’s server.

No hacking the library. You won’t be able to introduce custom hacks into the library if its hosted on Google’s server. I don’t know how many people do that anyway. I’ve never jumped into to hack a compressed library file – I just use it as is and add any custom code to another .js file.

Google could sabotage your site. Unlikely, but I suppose it’s possible. If you’re paranoid, steer clear.

Check It Out

I’ve been using it for a week or so, and I haven’t noticed any problems. In theory, it’s a great idea, but it’ll only work if a large number of sites (especially highly trafficked sites in a variety of niches) opt to use it.

I’m going to do my part and point my users to Google’s servers. Why don’t you?