Requirements
- A working Gallery plugin to contribute
- A perl interpreter on your development platform
- The developer install of Gallery
- write access to the gallery-contrib project on Sourceforge
Steps
- Import the files to your Subversion client. There's information on using Subversion with Gallery at Gallery:Using Subversion although that page is mainly concerned with the Gallery core code. You should definitely use the [autoprops] settings suggested before you import new files, otherwise you'll spend a long time tracking down and editing svn properties on your files by hand later.
- If it's an entirely new module, check in the code to the repository on Sourceforge. The url for a new module is https://gallery-contrib.svn.sourceforge.net/svnroot/gallery-contrib/trunk/gallery2/modules/<module-name>
- For existing modules it should suffice to commit your changes ("svn commit") - make sure you've added any new files first and deleted files that are no longer to be part of the module.
- Gallery 2.2.5 and previous: Update the MANIFEST file for the module: assuming you have your up-to-date code in a real Gallery installation somewhere, run the makemanifest perl-script from the Gallery root directory:
perl lib/tools/bin/makeManifest.pl -p modules/<module-name>
- as of Gallery 2.3, makeManifest has been re-written in php, so the command would be:
php lib/tools/bin/makeManifest.php -p modules/<module-name>
- (G2.3) If this is the first time the script is used on a module then it throws a couple of errors (related to no existing MANIFEST file) but appears to complete ok. Also if there's no revision tag in the MANIFEST file yet (hasn't been checked in to Subversion) then there's another random error. Just ignore them. I have, and it appears fine.
- commit the updated MANIFEST file.
- Wait. There's a process that runs on the GMC server, scheduled at 00:00, 06:00, 12:00 and 18:00 PST (that corresponds to 01:00, 07:00, 13:00 and 19:00 GMT), which updates from the Sourceforge archive, scans MANIFEST files and if all is well makes the the new/updated module appear in the downloadable plugins page, under the community repository section.
- You can check the last time the repository was updated at this URL: http://galleryproject.org/repository/status
What can go wrong
The scheduled process on the GMC server that tracks changes to the gallery-contrib project scans through the modules to generate the data that's downloaded by the Add More Plugins page. It runs every six hours, and until it has successfully scanned your module (or updated module) you won't see the changes tracked on the Add More Plugins page. Unfortunately, the process fails silently, so if there is a problem with your submission you may only find out because the new version hasn't been made available. Essentially if it hasn't turned up by the next day, suspect a fault with what you committed - or with what someone else committed ... if any uploaded module causes an error then the whole service stops. You can see what time the last repository update was at the url above.
Potential pitfalls include:
- Wrongly set props on the code files. Make sure that all the files that you edit have the svn:eol-style set to 'native' - otherwise you can run into issues with CRLF vs. CR line terminators when your files are checked in/out of windows and *nix systems. This can cause them to fail the checksum integrity tests. This applies to .tpl, .inc, .txt, .xml, .class files - see the [autoprops] section at Gallery:Using Subversion for full details.
- The cron job on the GMC server loads the module information (title, description etc) from the module.inc file, so the module.inc needs to load cleanly. If there is a problem (syntax error? unmeetable external dependency?) in the file then the cron job will halt and the entire plugin update process will cease.
- .po files need a $id $ tag in the first line to be able to build language packs
- Don't forget to include a comment (svn commit -m "update MANIFEST" ...) when you check in your revisions.
Testing the module packaging process, and running your own G2 Repository
The code that packages modules for the repository and the repository code itself is also included with the G2 distribution - point your browser at the /lib/tools/repository/ directory on your Gallery.
