Customising Gallery 3

Having selected this particular photo gallery as the one that most suited my needs the next step was of course to customise it to blend into the site I wanted to use it on. This involved both changing the appearance of the pages and for this particular implementation I also wanted to use an existing membership login and not the user login provided by the script.

The ease with which each of the changes could be implemented varied but all are possible and all can be done without interfering with any of the rest of the script.

Simplest to implement is any desired changes in appearance. Gallery 3 determines the appearance of the public pages and also the appearance of the admin area by using two themes. There are a number of themes available so the obvious first step is to check through the available themes and find the one (or two if you also intend to change the appearance of the admin area) that is closest to the way that you want your gallery to look and implement that onto your gallery. If this still doesn't meet your exact needs then the next step would be to make a copy of that theme and make the amendments you require within the copy. You can then implement your modified theme.

For what I wanted the the Browny Wind theme was closest and also has a corresponding admin theme so I implemented the browny wind admin theme as supplied for the admin area and made a copy of the browny wind theme to modify for the site. As the admin area will only ever be visible to one or two people the absence of the main site identifiers is unimportant as there is a link to go back to the main gallery. The main changes that I wanted to make to the way the Gallery looked was to wrap the Gallery inside of the header and footer of the membership site I was adding it to. This mainly involved adding that HTML into the page.html.php file and also commenting out some CSS that clashed with that of the main site.

Now there would be two approaches to integrating Gallery 3 into an existing membership site with respect to identifying who is logged in. The way someone really familiar with Gallery and not so familiar with the membership site (or equally familiar with both) would probably use would be to write a replacement identity module to substitute for the user module in Gallery.

As I was relatively unfamiliar with Gallery (having just found it) but knowing exactly how the membership site works (since I wrote it) I took the alternative approach of making a minimal change to one file in the user module (to return a supplied user number for the guest login), replaced the user table with a view that provided the equivalent information from the existing member table, and created a local.php file that reads the currently logged in member to set the field for the guest call to use and which inserts and/or deletes user/group records based on what the membership system identifies that member is allowed to access in Gallery. I don't think the local.php file was built into the script for this particular purpose but it does work quite well. Once I was sure the member access worked properly I then modified the admin_users.html.php file in the users module to remove all the add/edit/delete links. Effectively that page now serves as a way to find out how many photos each member has posted and which members have actually accessed the Gallery.

At some point I may create a replacement identity module that applies these changes without needing the original user module to be changed but it doesn't really seem worth the effort as basically I am not using most of the functionality of that module anyway. I just need to make sure it doesn't get accidentally overwritten if the original module is ever updated.

The way I implemented the member/user interface broke a part of the validation in the Comment module. In this instance I decided to make use of the correct way that Gallery provides for changing the way modules work by creating my own module and including the changed file there instead of in the original Comments module. I then implemented the Module Order module and used it to give my module the highest priority. Now I can add whatever additional modules I like to the Gallery and if there are any conflicts between the newly added modules and the way my membership/user implementation works I can simply add modified copies of the necessary files to my module.

Apart from the way I replaced the user login option all of the other changes I applied to Gallery are done the way the script intends and so the option remains open to apply all future updates to the script with minimal chance that the updates will conflict with my implementation (except for possible updates to the user module). So I can have the latest version of this script running with whatever features that it makes available with a minimum of maintenance effort on my part.


This article written by Stephen Chapman, Felgall Pty Ltd.

go to top

FaceBook Follow
Twitter Follow