Copy the Gallery 2 files to a directory on your webserver. There are several alternatives for this step:
The BEST place to start is /gallery2/README.html. If you wish to jump ahead and start the install, you can point your browser at /gallery2/install/ instead. If it's your first time, you will need to visit the README.html in order to find database setup instructions.
Gallery 2 requires many of the same things that G1 required. A web server, php and some graphics manipulation programs. You probably already know these things... but there is ONE new requirement: a database. Right now, there is support for MySQL 3,4, PostgreSQL and Oracle 9/10. Of course, the other requirements are a web server (apache, iis, zeus?), php (4 or 5) and some graphics manipulation packages (netpbm, imagemagick, ffmpeg, gd). Space for the images is probably one of the more obvious requirements :)
The GaphicsMagick package on Fedore Core 6 on both x86 and x86_64 currently has a flaw in it where the thumbnail creation process causes a segmentation fault. There is a detailed bug logged to Fedora on this reference (BugID 237803). this FAQ will be updated once the Fedora team has evaluated and fixed this issue. This will also be tested on Fedora Core 7 and updated if appropriate.
You can download the latest official release of G2 from the sourceforge download page. Official packages usually released not more than two times in a year, thus they might miss the latest features and improvements.
There are two ways of keeping current any time, using nightly builds or using Subversion.
Chetan Sarva, Jesse Mullan and Gallery2.EU both offer nightly builds.
The instructions for using Subversion can be found here . You can also find instructions for using TortoiseSVN here .
To get the SVN version of Gallery, see the next FAQ item.
That is up to you, I would suggest Subversion if you are comfortable working with it or don't mind learning. Once you get the original source from Subversion, updating is as simple as going to your G2 directory and typing "svn update".
Subversion keeps a second copy of every file so commands like "svn status" and "svn diff" can run quickly, without going over the network. This does double the space required.. if you like the convenience of "svn update" but aren't doing development so you don't use status/diff much, then vote for this feature and hopefully subversion will support it someday. For now we offer a script called svnSlim.
See: Upgrading Gallery 2
Gallery 2.1+ has a "Maintenance mode" feature. Edit your config.php file using a text editor and find this section. It has instructions for turning on this mode. Example settings (use only one of these lines):
$gallery->setConfig('mode.maintenance', true);
$gallery->setConfig('mode.maintenance', '/maintenance.html');
$gallery->setConfig('mode.maintenance', 'http://myothersite.com/');
Site administrators may still use the application while the site is in maintenance mode.
Typical upgrade process:
If a upgrade did not complete successfully, there might be a line in your "versions.dat" file located in the base folder of your albums directory that says "maintenance-mode". If this is the case, remove the line, and connect to your site's main page where the upgrade will start from the beginning.
It is possible that it is planned. See this list of requested features. Also see the feature request section on sourceforge . If you don't see your idea listed you can file a feature request on sourceforge and/or start a discussion about your idea in the G2 Development forum. If you do see your idea listed it may still be a long time before it gets implemented so if you or someone you know can help out with development, please do!
Start with G2 Developer Starter Kit . There you will find reference to how our team works and where to find the needed documentation. First link there is the G2 Developers Guide which is a must-read before you start. Not every detail is described there yet and some stuff is outdated, but there you will get the general "feeling" on how and why our architecture is how it is. The API for all classes is self-documented with phpdoc in the code, which is extracted to the G2 API Documentation (last link in the Starter Kit). If you are on Windows and have trouble with the Makefiles to generate stuff for you, have a look at virshu 's howto Building Gallery 2 on Windows.
For basic integration, you can edit the theme templates to show Gallery 2 inside your own page with your header / footer / menu etc. Please see Visual Integration HowTo as well as the Theme and Template docs.
For application level integration (embedded G2) see the Integration HowTo and the Embedding & Integration Forum for existing integrations and to discuss your plans and issues.
The Makefiles are only needed by gallery2 module developers. If you are just using G2, you don't need to "make" anything. For developers, the Makefiles automate boring tasks such as:
1) generate compiled translation files (.mo) from source language files (.po), 2) generate database schemas from entity definitions, 3) generate interfaces to access members of entities.
If you have manually dropped your DB or some of the files are not deletable by you (for instance, they are owned by the webserver's user) you might find Bharat's Cleanup Script useful. You can also point your browser to /gallery2/lib/support/ or /gallery2/lib/test/tools, the former is for those with any package but the dev package. The latter is part of the dev package.
Also, the G2 installer can "clean" your g2data directory. That is, it removes everything and then it adds the basic structure again, just with empty subdirectories. For this, you have to make sure there is a versions.dat file in the g2data directory and then advance to the Database Setup Step (step 5) and after hitting save, you should see the option "Erase".
Gallery 2.3.1 has updates for PHP 5.3.x compatibility. This release should still be compatible with PHP 4 as well, but if you encounter any problems then try switching back to Gallery 2.3.
Gallery is NOT designed to work with safe mode. You can see the sticky thread in the G2 development forum for an in depth discussion. Also see this topic and this topic for details of some experiments in getting G2 to work with safe mode.
The upload limits are enforced by the PHP / webserver configuration and not by Gallery 2/3.
In short: The administrator can change the upload_max_filesize and post_max_size directives in php.ini (the PHP configuration file). Also, you can try to override the system-wide default settings in a .htaccess file. Example, add this to your .htaccess file in your gallery/ folder to set a upload limit of 10 MegaBytes:
php_value post_max_size 10M php_value upload_max_filesize 10M
This can result in a "Internal Server Error" (error status 500) on all your Gallery pages. If you get an error after this change, remove your changes. That means that your webhost doesn't allow such changes in .htaccess.
An alternative that works for some users: Add a php.ini file in your gallery/ folder with the following contents (notice the difference, here we have a = and no php_value):
post_max_size = 12M upload_max_filesize = 12M
This may or may not work. You can check if these changes have actually changed your limits by browsing to your add items -> from browser page.
Changing to bigger value "memory_limit =" might also help. Note though that the memory_limit does not have to be exceed the file size of the files that are uploaded. memory_limit plays a bigger role when using GD as your image toolkit module. More on that topic can be found in other FAQ entries.
If you're using Apache 2, especially with something like RedHat, you may need to edit another directive, LimitRequestBody, as described in this forum post. Setting this directive to 0 (i.e. LimitRequestBody 0) will allow you to upload as big a file as you want (until you hit upload_max_filesize and/or post_max_size -- see the above email link for more information).
Dreamhost customers (and perhaps customers of other providers) should try searching for specific instructions on how to accomplish this. In the case of Dreamhost, they provide a wiki page describing exactly how to accomplish it here. I have personally tested it and it works. It boils down to creating a cgi-bin directory, copying their cgi php handler and setting it to be your default php handler. They also provide information on how to create a script that keeps php.ini and php.cgi up to date, but with your settings instead of theirs.
The default Apache configuration on Debian Lenny: put something like this into your Apache configuration if you are using G3:
<Directory /var/www/gallery3/>
AllowOverride All
</Directory>.
Another option is to ftp to a folder on the local server and use the "Add Item" -> "From Local Server" option. You may need to rebuild the thumbnail for that item. This works on the 1and1 servers.
You are exhausting the available memory that PHP has access to. In php.ini there is a config variable named memory_limit that by default is set to 8MB. Edit php.ini and increase it to a larger value (restart Apache afterwards). If you don't have access to php.ini, you can add this line to your .htaccess file in your gallery2 folder. Usually, unless you are the owner of the server, you don't have access to change php.ini. If there is no .htaccess file yet, you can create one (it's just a text file with the name '.htaccess').
php_value memory_limit [new memory limit]
To change it to 24 MB, write:
php_value memory_limit 24M
If the .htaccess method does not work or if you get an internal server error after adding this line, remove the line from the .htaccess again. You can also try to change the memory_limit by adding the following line right after '<?php ' in install/index.php and in main.php:
ini_set("memory_limit","32M");
If there's no "memory_limit" parameter in your phpinfo page, then all PHP/Webserver processes are limited by the per process max memory limit. You'll have to ask an administrator to change the limit in this case. On linux/unix, you can check the limit with the following command in the shell:
ulimit -a
Or with PHP with a script check.php
<?php print system('ulimit -a'); ?>
It would appear it does, point gallery remote at the base url of your gallery. For instance, I would point it to "http://my.gallery.domain/gallery2/"
Note: Gallery Remote doesn't work with Gallery 2.2.1 - nor does iPhotoToGallery... yet
Yes. The basic strategy is that you install and configure a copy of Gallery 2 right next to your copy of Gallery 1, then you use the migration module to import all your Gallery 1 data (users, albums, photos, metadata) into your Gallery 2. This will make a complete copy of your data in Gallery 2 and then you're free to delete your Gallery 1 install. It will even give you mod_rewrite rules that can redirect all your old Gallery 1 urls to the correct places in Gallery 2. If you don't have enough free disk space to migrate it all at once, you can migrate a few albums at a time.
Please refer to the detailed migration guide if you have any problems.
You can find links to NetPBM and jhead on the Gallery Download Page. You might also find Image Magick binaries here. The ImageMagick binaries are installed on /usr/bin which is the default when you configure Gallery after the one-click install.
You can find them here , but keep in mind this is a 3rd party site not under Gallery's control.
If you remove a local/*.tpl file it won't switch back to the *.tpl file due to smarty caching. You can get it to switch back to *.tpl by clearing the smarty cache manually on the filesystem, running the Flush Templates task in Site Admin/Maintenance, using Cache Maintenance found in the /lib/support/ page or by doing 'touch filename.tpl' which causes the last change time to update.
Here's a step by step guide:
$gallery->setConfig('data.gallery.base', 'some/path');
(Replace 'some/path' with the correct value.)
Save config.php, and you're done.
To save time, you don't need to move everything in the storage folder. Specifically you can leave behind the contents of the cache folder *except* the cache/derivative folder, which you do want. Everything else in the cache folder will be recreated by Gallery as needed.
Here's a step by step guide:
$gallery->setConfig('data.gallery.base', 'some/path');
If you use a multisite install, you also have to update:
$gallery->setConfig('galleryBaseUrl', );
Save config.php, and you're done.
If you are using a PHP accelerator (see List of PHP accelerators), you may need to clear its cache before the new settings take effect. Old installation paths may still be present until they are cleared.
Here is a step by step guide:
Unfortunately, there's no tool to export/import data from one G2 installation (source) to another (target). But there are a few methods that may solve your problem.
Permissions are handled on an item by item basis, not an album by album basis. Just because "album01" is private, doesn't mean that "album01/album02/image3" is also private. This is by design and intentional, BUT the problem is in the interface which does not mention or explain this in any way. Someday the permissions UI will be improved.
By default Gallery 2 uses flock for locking and this is known not to work over NFS. Go to Site Admin / General and switch to database locking instead.
You're probably not imagining it. There are three main areas where Gallery 2 is going to be slower. Gallery 2 uses a database for its storage. This means that even the most trivial operations require communication with the database to get answers. In comparison, Gallery 1 stores everything in fairly small flat files and it loads all the data into memory and then operates on it. For small Gallery installations on hardware that is 3+ years old, you're going to find that Gallery 1 runs a fair bit faster. However, Gallery 1 will not scale as effectively so as you start to get up to having 5-10K photos, you'll find that Gallery 2 is much more efficient. Having a database also allows other applications to interact with Gallery data, which is a big advantage over Gallery 1's proprietary data format.
Gallery 2 provides complete image security. If you restrict a photo based on its permissions, no outsider can get to it. This is in contrast to Gallery 1 that merely creates urls to images that an outsider could browse to, if he or she knew the url. However, this security comes at a performance cost. We are considering different approaches, including the possibility of allowing you to lower or remove this security threshold to increase your performance.
G2 is a much larger framework than G1. It's designed to be incredibly flexible and maintainable. This leads to having a lot more code and because of the nature of PHP, this causes pages to load a little slower. However, this also means that PHP accelerators like (see List of PHP accelerators) can effect very substantial performance increases when properly used in conjunction with G2. We recommend this option, if it's available to you (i.e. if you have full control over the PHP installation on your server).
Performance is an important factor to us. We have introduced caches at strategic places and are working on ways to improve all of the issues above to increase performance. It is secondary to making a fully-featured product for now, but as we get closer to the official release date it will gain higher priority for the development team.
For further tips, be sure to check out Gallery 2 Performance Tips.
Note: There's a known bug in the 2.0 release where if you import a large number of albums from Gallery 1, it can fail to optimize the permissions table leading to really bad performance (2-3+ second response times for a page load). If that happens, you can fix it. Just change any permission anywhere in your G2. You may have to do this a couple of times because each time you change a permission it has a 50% chance of re-optimizing your permission table. If you want to check the before/after, you can run this query
select count(*) from g2_AccessMap;
Before and after the permission change. If the number of rows drops dramatically (like from 2000 rows down to 30) then you've fixed the problem.
G2 has some fundamental differences from G1. In G1, thumbs and sized images were created at image upload. In G2, these items are not created UNTIL they are accessed/needed. This means that the first time you view a sized image or album, it may take a while for the images to be generated. Of course, subsequent visits should be much faster because they already exist. I believe there are also plans for the ability to generate the needed images at upload or when ever the user wishes, independent of viewing them for the first time. Update: There is now a check box present during import and upload that allows for the generation of thumbs/sized images right then. Using this will increase the time it takes to upload/migrate, but will take care of it immediately instead of when a user first requests the image.
First- when the configuration asks for the path it is not asking for the path to the gallery2 module (like gallery2/modules/imagemagick). These directories are G2's interfaces to these programs and not the programs themselves. You need to find or install the binaries on your system, make sure they are executable, and enter the appropriate path in the configuration.
See: http://codex.galleryproject.org/Installing_an_Image_Processing_Library
Using windows: set the permissions correctly; http://galleryproject.org/node/75599#comment-269778
Add a line like this in config.php before the ?> at the end:
putenv('TZ=PST8PDT');
Replace PST8PDT with the appropriate timezone string. For more information about appropriate timezone strings, see this Wikipedia entry on Zoneinfo. For actual acceptable values, see this list on Wikipedia. On PHP 5.2 or higher the preferred method is a date.timezone setting in the php.ini file, or a line like this before the ?> at the end of your config.php file:
date_default_timezone_set('America/New_York');
To use a different main php file after G2 is installed follow these steps:
define('GALLERY_MAIN_PHP', 'filename.php');
As of 2.0-rc-2 you can also do define('GALLERY_MAIN_PHP', ''); to set the default document to / hiding all reference to index.php or main.php. You'll also need to set baseUri, the now second-to-last line in config.php, to '/' (for example for a domain-level install of gallery).
If your system does not accept ".php" as an extension for PHP files and requires ".php4" then follow these steps:
function generateUrl($uri, $print=true) {
Just after that line add:
$uri = str_replace('index.php', 'index.php4', $uri);
And change upgrade/index.php to upgrade/index.php4 in main.php4.
PHP 5.x versions older than 5.0.4 have a very important bug (bug id 32290). This bug affects object oriented software like G2, and the libraries that G2 uses (Smarty, ADOdb). We know of at least two features that don't work because of this bug (advanced search, publishxp). There may be many other problems, including data integrity issues.
Bottom line: PHP 5.0.3 has a grave bug. Gallery cannot reasonably work around it. Upgrading to PHP 5.0.4+ should resolve it.
If you must stick with PHP 5.0.3 you can remove the PHP version check that prevents you from installing G2 by changing a few code lines in install/steps/SystemChecksStep.class and upgrade/steps/SystemChecksStep.class. You can also fix the advanced search and publishxp, it's described in this forum topic.
A full backup consists of your 'g2data' directory, database, /gallery/config.php and /gallery/.htaccess. NOTE: If you don't use the URL Rewrite module you won't have a .htaccess file.
Gallery needs these prefixes (/v/, /d/, ...) to detect different types of requests. /v/ for album and photo "view" pages, /d/ for download URLs, etc. You can change this prefix in Site Admin -> URL Rewrite. You can even remove the prefix for the view pages (/v/). However, you should be aware that if you remove the /v/ prefix, you may no longer have top level albums which have the same name as one of the directories in the Gallery directory. In other words, creating a top level album "lib", "themes", "modules", "install", .. is ok when you have a /v/ prefix, but it will result in problems when removing this prefix. There's a maintenance task to check that there's no conflict like this in your Gallery (Site Admin -> Maintenance).
You would like to show your Gallery 2 images in another website or forum (bulletin board) or you would like to add a link on another website to a specific image / album of your Gallery 2.
To start with, updating to the latest code is a good idea. It is possible that it is already fixed. Next you should probably look around the forums to see if the problem has already been posted. Try your luck with the search function in the forums. If that doesn't help, you probably want to ask for help in the support forum. Include as much information as possible in your support request.
When you create a new topic in the support forum, please include the following information:
1. On your desktop, create a new text file 2. Open the text file and copy'n'paste the following: <?php phpinfo(); ?> 3. Save the text file and rename it to phpinfo.php (or any other file with the extension .php) 4. Upload the file to your gallery2 directory on the server
Getting the error message from debug output is particularly important for ERROR_STORAGE_FAILURE errors, as this is the only way to get the detailed error message from the database.
The more information you provide, the more likely we can help you and the faster the issue can be resolved.
Browse to http://www.example.com/gallery/upgrade/index.php or http://www.example.com/gallery/install/index.php and advance to the System checks step. Make sure there are no warnings, and especially that the file integrity check passes (no missing / modified files). If there are missing / modified files, read this FAQ entry to fix it.
Even if Gallery has already been installed, you can access the upgrade/ or install/ wizard at any time. Just advance to the "System Checks Step" and don't go any further. This step will show a warning for missing or modified files in the "integrity check". If there is a problem, you can click on the "+" sign to see a complete list of affected files.
Either you don't get any thumbnails / resized images at all or you get a "broken image" placeholder.
G2 constructs links to other G2 pages using the baseUri parameter in the config.php (you'll find it at the end of the file). If you set this parameter to blank ("") then all links in a page are built with the same hostname as the request was made to. So you can use two different names and the pages served for both will remain consistent.
G2 depends on the system it runs on to switch to other languages than English. G2 needs php with gettext support and each language you want to switch to in G2 needs to be installed on your system. If you have command line access (ssh / telnet) to the (unix, linux) server, you can query for supported languages by `locale -a`. If only "C/POSIX" is returned, no other languages are supported and you need to reconfigure the locales and then restart apache.
Also try several variants of locales corresponding to your language. For example, fr_FR.iso885915@euro seems not to be supported by G2 while fr_FR.iso88591 works fine. Also, if you have a language variant installed (ex fr_CA), make sure you also have the "main" language (ie fr_FR) installed on your system.
Also, there is a bug if you use Gallery2 with Drupal 4.6.x using the gallery.module module Look here for this issue (fixed in 4.7.x integration).
If the installer gives you an error like "Client does not support authentication protocol" then the MySQL support builtin to your PHP is using an older password scheme than your MySQL database. See here for more information and a workaround to get you up and running without having to recompile or upgrade your PHP.
If you see this error while installing the Core module:
Specified key was too long; max key length is 1000 bytes
then you need to switch the database character set to something other than utf8. Currently some indexes we use exceed this default MySQL limit if the charset is utf8.
Some hosts setup a query limit on your MySQL database. This is usually a per hour limit and would be restored in time. Floridave believes that a reasonable value for this would be 50-70k, but some hosts might set it as low as 10k. See if your host will bump it up a little bit perhaps. A workaround is to create several users of the database and randomly use those users to connect:
A totally blank screen usually means that a php error has occurred. In normal operation all error messages are deliberately hidden, as a security feature to avoid revealing information about your website to a potentially hostile user who comes across the error. In order to reveal any messages you should follow the instructions below about how to display errors, and repeat the actions that cause the error. Having enabled error-reporting it is the report of errors now displayed instead of the blank page that is most likely to shed light on the problem; the often very long debug log shown with the page before the problem occurs is much less likely to be useful. Bear this in mind when asking for help in the Gallery Forums.
You can also look in your webserver's error logs for entries contemporaneous with the blank page being displayed. (contact your hosting provider if you're unsure how to do that.)
There are also generic things to check too: your PHP memory limit and other PHP configuration parameters. In most cases, G2 requires a memory limit of at least 16 MB, if you are using GD, it may require even a higher limit.
Please see:
Probably your PHP memory limit is too low. Increase your PHP memory limit to at least 16 MB. If the problem persists, you should activate immedate debug mode in config.php and report the problem in the forums.
If NetPBM is given a file that it can't support, it may try to put up a dialog box telling you about the error before continuing. Since your server can't display those error boxes, the rest of the image processing operations wait for you to click an "OK" button that you can't see. This may also result in G2 hanging for 30 seconds since it is waiting for the image processing to complete also. ImageMagick does not appear to have this problem.
If there is a warning for missing or modified files in the installer or upgrader, you should take it seriously. Neither the install or upgrade process nor G2 as an application can work correctly with missing or modified files. Upload the modified / missing files again to your server until the warnings disappear. Possible reasons for missing / modified files:
If you are a svn user, a warning for a few missing or modified files in the installer / upgrader systemcheck step is the norm. But if you experience any problems, this is surely one of the first places you should look into.
You need to give permissions for IIS to be able to read and execute the command interpreter ("cmd.exe"). Without it, Gallery won't be able to call external executables (like ImageMagick). Required steps:
1. Open a cmd-prompt with "Start", "Execute", then type "cmd.exe". Hit ENTER. 2. At the prompt, type: C:\> cacls %COMSPEC% /E /G %COMPUTERNAME%\IUSR_%COMPUTERNAME%:R
This adds the "read" permission to the IIS-user for the cmd.exe. Close the prompt and then try activating the imagemagick module again. More Info
If you use mod_layout with Apache, make sure it is disabled for gallery files. Gallery sometimes sends binary data back from a php file, so adding a header or footer to these requests will corrupt the data! Adding the following lines to your apache config file or your .htaccess should fix it.
# Disable layout header and footer for Gallery2 LayoutIgnoreHeaderURI /path/to/gallery2/*.* LayoutIgnoreFooterURI /path/to/gallery2/*.* # PHP Gallery2 overide Layout <Directory /path/to/gallery2/> LayoutHeaderOff LayoutFooterOff </Directory>
Edit your config.php and turn on buffered debug mode by changing this line:
$gallery->setDebug(false);
to
$gallery->setDebug('buffered');
Then try again. This time, you'll get quite a lot of debug output when you get the error. Look towards the bottom of the debug output and scan backwards for anything that looks like an error, then report that in the support forums. Usually that will give us enough information to work with. If you can't understand what you're seeing, err on the side of posting more info. If it's going to be more than 30-40 lines of output, you should save it into a text file and publish it on your own website and post a link to it here (so that the forum remains readable).
Some operating systems report invalid character sets to PHP leading to errors when trying to convert system-generated content (like day/month names in dates) to UTF-8. Work around this problem by placing the following in config.php:
$gallery->setConfig('systemCharset', 'ISO-8859-1');
Replace 'ISO-8859-1' with the appropriate character set for your system (other popular charsets include 'UTF-8').
An invalid locales config normally causes uploads to fail, with the Upload Applet error message Upload error: Upload failed: ". after each uploaded item and the From Web Browser just uploads one item with the status message Successfully added 1 file.
require_once(dirname(__FILE__) . '/modules/core/classes/GalleryCapabilities.class');
GalleryCapabilities::set('systemCharset', 'ISO-8859-1');
So you tried to install G2 but you get an error, probably in the install core module step. See the list of frequent installation errors.
If you are using PHP 5.0.3 or earlier PHP 5 versions, this is probably because of a bug. Therefore, these PHP 5 versions are not supported by G2. Either change to PHP 4.1+ or to PHP 5.0.4+.
This bug should occur in advanced search, in the publishxp module and in other places of G2.
If you see this error message, either the username or the password that you've entered is incorrect.
Does it say your user account is "disabled"? (since G2.2)
If you see this error message, then you either ignored the CAPTCHA image or you CAPTCHA is enabled but no image is shown.
This error message is shown if you didn't interpret the CAPTCHA image correctly.
Are you able to login manually? You can try to login manually with http://www.example.com/gallery/main.php?g2_controller=core.UserLogin&g2_form[formName]=UserLogin&g2_form[action][login]=Login&g2_form[username]=admin&g2_form[password]=secret (replace "secret" with your own password).
Copy and paste the stuff in bold. Don't forget to change secret to your password. If you've also changed the admin username from admin you'll need to change that as well.
If you have this problem it may be difficult to tell unless you are familiar enough with G2 to know where to expect progress bars to appear. Examples are upgrader and G1 migrate.. if you don't see a progress bar at all or it just flickers quickly on the screen when the request has completed then PHP's output_buffering mode may be enabled. Check php.ini and make sure output_buffering is set to off and no output_handler is configured.
If you are running Apache it can be configured with the deflate or gzip module and this will buffer all the output also. You can check by going to http://www.whatsmyip.org/mod_gzip_test/ and putting in your gallery url and it will tell you if the deflate or gzip module is being used.
You can try this patch.
Probably you use the G2's short URLs which are generated by G2's URL rewrite module. If you have a .htaccess file in your gallery2 directory, this is the case. You have two choices:
And if you decide to use the URL rewrite module, you have to activate the module while accessing it from the correct / chosen vHost / (sub-)domain. To change it, access G2 from the URL which you used to install it. Deactivate and uninstall the URL rewrite module. Then access it from the URL that you prefer and install and activate the rewrite module again.
Technical background: When using the URL rewrite module, G2 has to store the path to the G2 main.php file in the database and in the .htaccess file. E.g. if the 'normal' URL is http://www.example.com/gallery/gallery2 it stores '/gallery2' in the .htaccess file and in the database. If you then want to access it from a vHost that points directly to the gallery2 directory, e.g. http://mygallery.com/, then it would generate wrong redirects and URLs since G2 still assumes it is installed in a subdirectory '/gallery2' of this domain. You may notice that this doesn't apply to two different domains which have the same webroot.
Most probably you are running PHP 4.4.0+ and use the PHP Zend Optimizer (see phpinfo). This is a Zend Optimizer bug. See http://galleryproject.org/node/36605#comment-133101 for some explanations.
Solution: Use a newer Zend Optimizer version, e.g. ZendOptimizer-2.6.2 or later versions.
If you run PHP 4.4.0 but don't use the Zend Optimizer, then most probably you're using a G2 version which is older than G2 Beta 4. You should upgrade to the latest stable release of G 2.0.
If you or your host is unwilling to disable or upgrade the Zend Optimizer to a fixed version or change the PHP version, there's a workaround (solution discovered by Mark Scott, 13/10/2005, "I've found that removing optimization pass 1 removes the notices caused by optimizing away the variable that should be referenced and returned.") In php.ini replace:
zend_optimizer.optimization_level=15
with:
zend_optimizer.optimization_level=14
You can also just suppress all PHP warnings but there's no guarantee that G2 actually works as expected:
/* in index.php, main.php and install/index.php */ error_reporting(E_ALL &~ (E_NOTICE | E_WARNING));
Related links:
The reason for this is explained and several solutions are presented on this page: MySQL Reference Manual: A.2.3. Client does not support authentication protocol. Specifically, look for the instructions after:
Reset the password to pre-4.1 style for each user that needs to use a pre-4.1 client program.
This can be done using the SET PASSWORD statement and the OLD_PASSWORD() function:
mysql> SET PASSWORD FOR 'some_user'@'some_host' = OLD_PASSWORD('newpwd');
Possible reasons (GR = Gallery Remote, G2 = Gallery 2):
If this error shows up when trying to login to your G2 in the Publish XP wizard, then you probably have a problem with cookies in Internet Explorer. Delete the cookie cache in Internet Explorer and then start Publish XP again.
Two common "mistakes" when you don't have a dedicated -nix server.
-nix server: When using a screen highlighting copy/paste action it's quite easy to inadvertently grab a preceding space (ie in front of the /home/). It can almost drive you to drink chasing apparently 'unaccepted' permissions...
Possible reasons:
(replace www.example.com/gallery2/ with the URL of your own Gallery2 installation)
For versions before G2.2, use this URL instead: http://www.example.com/gallery2/main.php?g2_controller=core.AdminModules&g2_moduleId=rewrite&g2_action=deactivate
If you get a Error (ERROR_PERMISSION_DENIED), then you're not logged in into your G2 and thus can't access the admin pages. In this case you have to login first and then use the above link. If the login view doesn't work, you can try to login manually with http://www.example.com/gallery/main.php?g2_controller=core.UserLogin&g2_form[formName]=UserLogin& g2_form[action][login]=Login&g2_form[username]=admin&g2_form[password]=secret (replace "secret" with your own password)
If you still get an error (ERROR_MISSING_OBJECT), go to http://www.example.com/gallery/lib/support/. Click the "Cache Maintainance" link, and clear all your db caches except for g2data/cache/derivative. Then, try the login link above, and finally, the deactivation link above that.
You can find out whether this is the case by looking at the http://www.example.com/gallery2/lib/support/phpinfo.php page, look for the values of HTTP_HOST and HTTP_X_FORWARDED_SERVER. If HTTP_X_FORWARDED_SERVER is missing, that's fine. If HTTP_X_FORWARDED_SERVER or HTTP_HOST have another value than the real host name (the part after http:// of your G2 URLs), then this is a problem.
If you or your admin can't change the webserver configuration (hostname in httpd.conf for HTTP_HOST for apache webservers) such that it returns a correct value, you can hack modules/core/classes/GalleryUrlGenerator.class function getCurrentDomain() to return the correct value or to ignore HTTP_X_FORWARDED_SERVER, what ever you need.
If you have more than one theme active and your current default theme doesn't allow you to access site admin -> themes to change the default theme (for whatever reason), then you can try to change the theme back to matrix, the official G2 theme, with the following URL: http://www.example.com/gallery2/main.php?g2_controller=core.AdminThemes&g2_form[action][saveDefaults]=1&g2_form[default][theme]=matrix
This will only work if you are already logged in as administrator. See another FAQ entry on how to manually login if the normal login method doesn't work anymore.
This can have several reasons.
If you're using MySQL 5.x on Windows and you can't get past the Database Setup Step in the installer and get a message like
The database privileges test did not complete successfully. Failed to create a DB test sequence.Check the returned error message and README.html for missing privileges and clean up the database.
Then you most probably have a MySQL InnoDB Engine issue. To resolve it, try: Delete BOTH your MySQL DATA and LOG files at the same time and restart the server.
C:\Program Files\MySQL\MySQL Server 5.0\data\ib_logfile* C:\MySQL Datafiles\ibdata*
If that doesn't work for you, change your default MySQL engine from "innodb" to "myisam" in your mysql configuration. Thanks to G2 users bzink5 and tippex for the solutions. The issue is dicussed in a forum topic.
There can be several possible reasons why you may not pass the authentication step of the installer:
| Problem | Solution |
|---|---|
| A movie is not playing in Firefox but it plays in Internet Explorer | Probably you're dealing with a .avi video. Microsoft has not supported Windows Media in FireFox until recently. You have several options to fix this: |
| When the apache2 mod_deflate module is enabled, movies most likely don't start playing in Internet Explorer (and possibly also in other browsers).
The Apache2 RemoveOutputFilter directive removes any output filter associations for files with the given extensions. This allows .htaccess files in subdirectories to undo any associations inherited from parent directories or the server config files. The extension argument is case-insensitive, and can be specified with or without a leading dot. More info on this: Apache2 documentation |
Put a '.htaccess' file in your g2 root directory with the following line in it:
RemoveOutputFilter wmv avi mpg mpeg
|
| Without the ffmpeg module active, movies are not playing inline, you only see a Download link. | Go to "edit movie", and set movie dimensions manually. If dimensions aren't set, the embedded movie player feature will not work for this item. |
| Movie dimensions are set in Edit Movie etc but you only see the Download movie link. | Your browser isn't configured to play movies embedded in the browser. You need to configure Firefox/Internet Exploret/ to play movies embedded in the browser (browser plug-ins). |
Use phpmyadmin / your mysql shell to execute the following query to change the default theme back to the matrix theme:
UPDATE g2_PluginParameterMap SET g_parameterValue = 'matrix' WHERE g_pluginType = 'module' AND g_pluginId = 'core' AND g_parameterName = 'default.theme';
Afterwards, delete the db cache by browsing to http://example.com/gallery2/lib/support/, enter your password, click there on cache management and delete the db and template cache. Of course you need to replace example.com/gallery2/ with the actual address of your Gallery.
Probably you chose the wrong package for your upgrade. Only the full package has all official themes and modules. Another reason could be that you were using non-official / 3rd party modules / themes and you forgot to keep them in your modules/ or themes/ folder.
If you can't get the latest version of a specific module / theme and nothing helps, the following SQL query can help you to get at least through the upgrade wizard:
delete from g2_PluginMap WHERE g_pluginId = 'PGtheme';
If a theme that is now unavailable was used as default theme or for one of your albums specifically, you will also have to update the g2_PluginParameterMap database table to change the default theme, e.g.
UPDATE g2_PluginParameterMap SET g_parameterValue = 'matrix' where g_pluginId = 'core' and g_parameterName = 'default.theme';
And do the same for specicic albums (set the g_theme = NULL in the table g2_AlbumItem for those rows that have a theme that is no longer working in your G2.
If after removing incompatible modules you see errors when editing items in your Gallery like this:
in modules/core/classes/helpers/GalleryFactoryHelper_simple.class at line 208 (gallerycoreapi::error) in modules/core/classes/helpers/GalleryFactoryHelper_medium.class at line 59 (galleryfactoryhelper_simple::newinstance) in modules/core/classes/GalleryCoreApi.class at line 124 (galleryfactoryhelper_medium::newinstancebyid)
, check the g2_FactoryMap table in the database for references to the removed modules.
If this still don't solve your problem, a last resort would be to delete the cache directory located inside your g2data directory (this is where all the photos are stored so don't go and delete the folder album!!! Just the one named cache)!
To crop the thumbnail for a very large image you may need to increase the memory limit for java. Java needs a parameter like -Xmx512M (this sets the limit to 512MB). In windows you can add this parameter in Control Panel / Java / Java tab / View.. for Java Applet Runtime Settings / Java Runtime Parameters.
If you get the error
Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE)
then you are probably using a buggy MySQL version. MySQL 4.1.16 and later as well as 5.0.17 and later have this bug fixed. Please see: http://bugs.mysql.com/bug.php?id=10446 . If you get this error during upgrade from G2.0.x or older to G2.1 or newer, please see: MySQL Upgrade Issue - UTF-8.
You have to modify the database manually. (You can use some web based tool do it, e.g. phpmyadmin) Login to your g2database, choose (g2_)PluginMap table. Here you have to modify the line of the rewrite module to deactivate it. To do this you can either: - manually select the line where g_pluginId is "rewrite", and turn the value of the g_active column into 0. or - run the following sql query:
UPDATE g2_PluginMap SET g_active=0 WHERE g_pluginId='rewrite';
After this, you might be ready, but you might also need to flush the cache manually. This can be done by visiting http://yourgalleryurl.com/lib/support/ and choosing the "Cache Maintenance" option. If you couldn't access this directory either, go inside your g2data/cache folder on your server, and delete everything inside it, except derivatives dir.
In a mysql database this could be a problem with the g2_SequenceId table. To fix this in phpMyAdmin, find the g2_SequenceId table and click "Browse" to see the rows. If there are multiple rows click "Delete" for each row except the one with the largest value. If there is a single row then click the "SQL" button in the very upper left.. in the popup window type:
select max(g_id) from g2_Entity
and click Go. Find the largest id in the query results. Now go back to "Browse" for g2_SequenceId and click "Edit" for the one row there. Change the value to be one larger than the maximum id reported in the query. Note that the errors received previously may have left directories and files inside your g2data/albums directory that are not displayed by Gallery. To complete the cleanup from this problem the items not shown when browsing the gallery as a site admin should be removed (backup first!).
The error can also occur if your mySQL is configured to only allow a certain amount of updates each given interval. The actual mySQL-error is 1226: User 'xxx' has exceeded the 'max_updates' resource (current value: xxxxx), but it's this ERROR_STORAGE_FAILURE that is shown in Gallery2. See: I seem to be running into some sort of MySQL query limit
The only thing you can do is to clean up (like it's explained above) and wait untill you can send update to your mySQL-server again.
If the error occur while displaying the gallery, check if you don't have any dead mysql process by stoping mysql and looking with ps -ef. If yes, simply kill the processes with kill -9 and start mysql.
Most probably the filesystem permissions for your G2 storage folder (usually 'g2data') are incorrect. See: How can I fix the filesystem permissions of the Gallery storage folder?. In some cases the host has moved some files around and the G2data folder is in a different place. Verify that the correct path to the G2data directory in config.php.
$gallery->setConfig('data.gallery.base', '/Verify/this/path/to/g2data/');
If in some cases you try to add items and get a ERROR_PLATFORM_FAILURE turn debug on
Usually you get either an ERROR_PLATFORM_FAILURE or the upgrade wizard reports that the filesystem permissions are wrong for your storage folder, i.e. it can't write to all files and subfolders in that folder anymore.
Error (ERROR_PLATFORM_FAILURE) : in modules/core/classes/GalleryTemplate.class at line 270 (gallerycoreapi::error) in modules/core/classes/GalleryTemplate.class at line 200 (gallerytemplate::_initcompiledtemplatedir)
In that case, if the above suggestions do not help, please try to delete g2data/smarty/templates_c/ folder via FTP or whatever tool you use to upload / manage files of your website.
This can have various reasons.
Error (ERROR_BAD_PARAMETER) : something/gallery2/modules/core/classes/helpers/../../../../themes/matrix/theme.inc
If you get this error, then something went wrong when uploading Gallery to your server.
This indicates that PHP cannot communicate with your MySQL server. Check to make sure that MySQL is running, and verify that it's actually on the server where you think it is. If MySQL is running on your local system try using the IP address for your host (which should be 127.0.0.1) instead of "localhost" for your database and see if that fixes the problem. For other diagnostics you can try, take a look at http://dev.mysql.com/doc/refman/5.0/en/can-not-connect-to-server.html
Gallery depends on PHP's __FILE__ directive to return the absolute filesystem path of the current file. Due to a bug in PHP, __FILE__ returns a relative path in older PHP versions.
Gallery caches some data that doesn't change very often in its storage folder. This includes templates, data from the database and other things. To clear the template cache: login as admin, click site admin, click Maintenance, beside Delete template cache click run now.
To clear the cache in case something bad happened, browse to http://www.example.com/gallery/lib/support/index.php, (change example to your proper url) enter your Gallery setup password, select "Cache Maintenance" and delete the caches. Usually, selecting all but the Thumbnails and resizes (derivative) cache is a good idea (repeat: do not select the Thumbnails and resizes cache for deletion, rebuilding it takes quite a while for large Galleries).
With the introduction of template caching in G2.3, you might find that editing a template file will not have an effect. Login ad admin -> site Admin -> Performance, uncheck 'Enable template caching', click save. Click the Clear Saved Pages button. Reverse when completed with template editing.
Your Gallery runs as a PHP application on a webserver and when there is a fatal error, e.g. due to insufficient resources (memory, diskspace, execution time, ..), there is no chance Gallery can recover since the web-server just terminates the request. Symptoms usually are:
Webservers usually save such error events in their error log. This is very helpful to diagnose problems since the error log usually contains more information than what the symptom might reveal.
Apache stores this log as a file. As a webhosting customer, you can usually view the error log in the administrative section of your website (cPanel, Plesk, ..). If you can't find it, please ask your webhost / administrator for help.
If you installed Gallery with the Pre-Installer, you need to first open the modules/ and themes/ directory for access before you can upload a theme or module manually yourself.
When diagnosing a problem, you want to be sure that you notice all hints that there might be. That's why you need to ensure that PHP is configured to display and log errors in such cases.
Also see: * How can I view the error log of the webserver?
The rest of this section applies for older versions of Gallery and is unlikely to be relevant to anyone operating Gallery 2 in the modern era. It is retained here strictly for archaeological purposes:
By browsing to your Gallery's phpinfo page at http://www.example.com/gallery/lib/support/index.php -> PHPinfo, you can find all the configuration details of PHP we're interested in. And these are:
You can ask your webhost to help you to put PHP into a configuration that is useful for debugging. Or you can open Gallery's main.php file in a text editor and replace:
<?php
with
<?php
ini_set('display_errors', 1);
ini_set('log_errors', 1);
ini_set('error_log', dirname(__FILE__) . '/error_log.txt');
error_reporting(E_ALL);
And then you need to put an empty textfile into your gallery folder and chmod it to 666 (give read+write permissions for everyone).
PHP errors, if any occur are then logged to that file.
Once you're finished with diagnosing and debugging your problem, you should remove those lines from main.php again and delete the error_log file as well.
We check the filesystem permissions of your storage folder before we start the actual upgrade process. There are three common reasons that make this system check fail:
See Upgrading a G2 that has been installed with the Pre-Installer
If that fails, you have to modify the database manually. (You can use some web based tool do it, like phpmyadmin).
UPDATE g2_PluginMap SET g_active=0 WHERE g_pluginId='captcha'; DELETE FROM g2_FactoryMap WHERE g_implModuleId='captcha';
If you move servers or hosts, it is possible that you may encounter a "Database Error" screen, with the text "An error has occurred while interacting with the database.". If you're using Gallery2 with MySQL, this may be caused by having a different MySQL client library on your new machine/server. To attempt a fix, editing your config.php changing the line
$storeConfig['type'] = 'mysqli';
to
$storeConfig['type'] = 'mysqlt';
