Category Archives: Zenphoto

Website Changes for July 2015

Blog

My blog was updated to WordPress v4.2.3 a couple days ago. Backed-up the files and database like usual and clicked the update button. This post is also a test to make sure everything still works correctly.

Galleries

Updated both my galleries to Zenphoto v1.4.9 a few days ago. Followed their upgrade instructions and backed up the themes and zp-core directories as well as the database before copying over the new files.  I then used Windiff and code comparisons in PSPad to integrate any new changes in the default Garland theme into my custom Garland theme.

Mysstie’s Website

Well, the folks at EverQuest II introduced new Time Locked Servers. As such, I created a character on the PVE server, Stormhold, called Mysstie and updated Mysstie’s Website to reflect the addition (Mysstie on Stormhold).


Well, that’s all I’ve got for now. If I think of anything else I’ll add to this post. :)

Galleries Upgraded to Zenphoto v1.4.8

Well, since I didn’t say much about upgrading my galleries to version 1.4.7, I figured I’d talk about upgrading them to Zenphoto v1.4.8. I followed their upgrade instructions with some slight deviations. Following are the steps I performed:

  • I downloaded and unzipped the archive and then re-zipped it only including the zp-core and themes directory as well as the files in the root folder.
  • Backed-up the database to my local MySQL server. Actually, I backed-up both my local development database on my PC and my production database on the web server to my local MySQL server.
  • Made a backup copy of index.php (since I had some custom code in it) and copied the zp-core and themes directories to zp-core147 and themes147, respectively.
  • Deleted the zp-core directory and the standard themes from the themes directory while leaving my custom ones.
  • Unzipped the new files into my gallery’s directory, replacing all files.
  • Re-added my custom code into index.php and /zp-core/zp-extensions/html_meta_tags.php.
  • Compared the changes between the Garland themes in version 1.4.7 and 1.4.8 using Windiff and saw that no changes had been made. Thus, I knew I did not need to update my customized Garland theme to incorporate any changes.
  • Refreshed my browser so that Zenphoto’s setup would run. Saw there were no problems on the initial setup screen and clicked the Go button.

I then tested it in my development copy before changing my production one and did uncover one bug. When editing a single image from the front-end, it would go into batch edit mode after clicking “Apply” to save the changes made. I posted 1.4.8: Single Image edit mode bug that returns to batch edit after apply on their GitHub Bug Tracker. Their latest master support version has corrected this bug. I basically performed the same steps with the support version. Since I had already backed-up the database and files, I just re-deleted the zp-core and themes directories.

After I verified everything worked correctly as far as I could tell with my development gallery, I proceeded to upgrade the galleries on the web server. Both gallery.markheadrick.com and gallery.mysstie.com have been running version 1.4.8 for several days now. :)

Oh, for those curious, my custom code in html_meta_tags.php was to change the image being referenced in the og:image meta tag:

198
199
200
201
202
203
204
205
206
207
208
         case 'image.php':
            $pagetitle = getBareImageTitle() . " (" . getBareAlbumTitle() . ") - ";
            $date = getImageDate();
            $desc = getBareImageDesc();
            $canonicalurl = $host . getImageURL();
            if (getOption('htmlmeta_og-image') || getOption('htmlmeta_twittercard')) {
               // mrh use the normal sized image since Facebook has a 200x200 minimum.
               //$thumb = $host . getImageThumb();
               $thumb = $host . html_encode(pathurlencode(getCustomImageURL(NULL, 520)));
            }
            break;

Website Changes for March 2015

All Sites

After running various website speed tests (Pingdom, Google PageSpeed), it told me that I should enable compression (gzip) and take advantage of the browser’s cache. So, I started to do some research on how to turn those on at my webhost. For compression, I finally noticed an “Optimize Website” option in cPanel after I had tried some things in .htaccess that were not working. There I was able to enable it for the following mime types: text/html text/plain text/xml text/css application/javascript. The results were rather dramatic. A 40K html file would be compressed down to 10K or something.

For the caching part, I found the following piece of code to be placed into the .htaccess file in my highest level directory:

<IfModule mod_expires.c>
          <FilesMatch "\.(jpe?g|png|gif|js|css)$">
                      ExpiresActive On
                      ExpiresDefault "access plus 1 month"
          </FilesMatch>
</IfModule>

And, hey it worked! Files of those types are now set to expire after 1 month. Before, Firefox was caching things based on how recently the file was modified. I found an explanation here: Two Important Differences between Firefox and IE Caching. After making these changes, the response headers coming from the server were now like:

Cache-Control: max-age=2592000
Connection: close
Date: Wed, 11 Mar 2015 23:02:20 GMT
Etag: "1410-419260a0e3ec0"
Expires: Fri, 10 Apr 2015 23:02:20 GMT
Server: Apache

These changes affected the behavior of all my websites. I was also advised to make the connection keep-alive but I think my webhost has that disabled for performance reasons.

Main Website

I modified most of the main pages to show a last modified date in the central time zone. A lot of pages still show an eastern timezone (DVD pages mainly). It’s a difference between the date being generated via SSI (server side include) and PHP which has been configured for the central timezone even though the server itself is in the eastern timezone.

Blog

My Blog was updated to WordPress v4.1.1. Backed-up the database and file structure and clicked the update button. Not that big a deal. I also figured out how to add a function that would tell me how much memory PHP was using in the Admin section without changing any of the core files:

###########################################################################################
function memory_stats()
{ // BEGIN function memory_stats
   if ($_SERVER['REMOTE_ADDR'] == HOME_IP) {
      echo '<p style="clear: both;">Memory used: '. number_format(memory_get_usage(true)). ' bytes.<br />';
      echo 'Peak Memory used: '. number_format(memory_get_peak_usage(true)).' bytes.</p>';
   }
 
} // END function memory_stats
 
add_action('in_admin_footer', 'memory_stats');

On average the admin portion uses around 40MB. I have PHP configured to 128M. I then noticed some CSS problems after one of my plugins updated and corrected that.

Gallery

I updated my galleries to Zenphoto 1.4.7. Actually, I’m using one of the master support builds due to some bugs I discovered that were corrected in the support version. I’m not going to go into detail about what all I did. Not in the mood right now and I doubt anybody cares LOL. Actually, it could be its own post if I wanted it to be.


Well, that’s all I have for now. :) If I think of anything else I’ll update this post or make another.

Galleries Moved from Gallery to Zenphoto Platform

This change was major enough to warrant its own post. Near the end of June, the Gallery Project announced it was going into “hibernation” with further development being stopped. So, I started looking around for something else. As you can guess from the title of this post, I finally decided on Zenphoto. I had tried Coppermine in the past but I didn’t like it then and it really hasn’t changed since. I also looked at Piwigo, but I didn’t like a few aspects of it. The main one being that its URLs were rather ugly and creating Apache rewrite rules, or internal PHP script handling, would be almost impossible to tell the search bots the new location of my images and pages.

The whole process took me a couple weeks but it involved a lot of behind the scenes work, much of which being specific to my situation so this post will mostly be a summary. Some individual steps could warrant a complete post themselves. Following is a brief (hmm, maybe not LOL) explanation of the steps I took for the switch:

  • Installed Zenphoto locally on my PC to test it out and get familiar with the UI (I have Apache, PHP, and MySQL installed on my PC). Decided on a supplied theme to use as a base (picked Garland) and what plug-ins I needed to do what I wanted.

  • Downloaded the full-size images from my current Gallery at my webhost and placed them into the Zenphoto albums directory. More specifically, I used Putty for shell access on my webhost to create a zip file of each main album and its sub-albums and then used FileZilla to FTP them to my PC and unzipped them. I already had the images locally but I wanted to make sure I was working with the actual files from my Gallery as the file names would prove to be crucial.

  • Created a test sub-domain and database at my webhost for Zenphoto and installed Zenphoto there. Since my webhost has Imagick installed, I changed the graphics option to use it instead. I prefer it over GD as it keeps all the EXiF and IPTC information intact. It was during this time that I uncovered a bug with the image quality setting having no effect with Imagick. Here’s the bug I filed on it and the solution. I changed the code and it’s working fine now.

  • The next phase of the operation is probably what took the longest. Zenphoto is file system based and creates its albums and such from the actual file structure and imports any EXiF and IPTC information it finds to be used as the image’s title, description, original date, tags, and so on. While I technically did not have to do this, I wanted to make sure all my images had the appropriate ExIF and IPTC information stored in them. Some had no information, some just the description and the newer ones had both the title and description (the Gallery software also imports these). Most did have the original (image taken) date in them but some were even missing that. None of the images had IPTC tags stored in them.  We’re talking about 100s of images, over 1,000 in one gallery.

    Initially I used a combination of Exifer, Irfanview, and Exiftool to manually update the images but quickly realized what a pain in the butt it was going to be and the amount of time it would take. Since laziness is the mother of invention, I decided to write a couple PHP scripts to cycle through the images of a specific album, look the images up in the Gallery database to get the image’s title, description, and tags and, using the command line interface of Exiftool, insert that information into the IPTC fields of the actual image (.jpg files). In order for this all to work, the file structure and file names on my PC had to match what was stored in Gallery’s database. I wrote one script to handle the title and description and another script to handle the image tags since those dealt with different parts of the Gallery database. Once I got this to work properly, I made pretty quick work of getting my images set with appropriate ExIF and IPTC information.

  • After getting my images updated, I decided this was the time to create any new albums and/or sub-albums. For example, in my main gallery, I divided up the old single Nature and Astronomy album into Animals and Plants, Astronomy, Mountains, and Weather sub-albums.

  • Created new zip files from the albums on my PC and uploaded them to the webhost in the Zenphoto albums directory. I then used shell access to unzip the files. The Zenphoto software recognized the new albums and images and imported all the ExIF and IPTC metadata from the images into the appropriate database fields. This saved me from having to manually tag the images and so on.  Some parts such as the album names, album descriptions, and image ordering were tweaked at this time.

  • The next process involved creating a set of Apache .htaccess rewrite rules in conjunction with some PHP code to redirect the bots and links that were out there to the new page and image locations. The PHP code was similar to what I had done in the old gallery where it intercepts the gallery’s 404 handling to see if the image actually does exist and, if so, what its new location is and directs the browser there with a 301 redirect. This only works when the image file names remain consistent and are unique. This PHP code also logs what it is looking for (the actual request and my parsed out image portion of the URL) and if it found it or not. If it doesn’t find a match it returns control to the gallery 404 processing. In the case of Zenphoto, I just insert a function call at the beginning of the theme’s 404.php file: if (found_missing_item()) exit; The benefit of this code is that I can also move images around and not worry about creating new rewrite rules.

  • The next step was to flip the switch and point my live gallery sub-domain to the Zenphoto directory and see what happened.

  • The final step was to update the various gallery widgets on my sites to work with the new gallery database and file structure.

Whew!! :) From this point forward I just kept tweaking various parts of the theme, and debugging my PHP code and Apache rewrite rules when I noticed certain things cropping up that I had missed. Like I said earlier, some parts of this could warrant their own post if I really went into the nitty gritty with code examples. If anyone wants to actually know how something was done in more detail, please make a comment. :)