Gallery 3.0 Alpha 3 is ready!

Four weeks ago we released Gallery 3.0 Alpha 2 and we're happy to say that the response continues to be overwhelmingly positive. The community support and feedback about features that you'd like to see in the product has been outstanding, and you've helped us track down many issues large and small in the code. To encourage your continued support and patience we're releasing Alpha 3 which has significant improvements!

Intended audience

The Alpha 3 release is still intended for enthusiasts, designers and module developers. This is the right time to do a test drive with the improved user interface and to start developing feature extensions and designing new themes.

Note there is still no upgrade path from Gallery 2 to Gallery 3, nor is there an upgrade path from earlier Gallery 3 Alphas to Alpha 3. Yes, an upgrade is coming but no, it hasn't been a high enough priority yet.

Security warning

This is a technology preview of Gallery 3.0 and as such it is not intended to be installed on public websites yet. The application has undergone a professional security audit, which has identified some security vulnerabilities and will be fixed before the final release. Please resist the temptation to share your test drive with the world and wait for the final release first!

Let's get the download

With the disclaimers and warnings out of the way, here it is: Download Gallery 3.0 Alpha 3 (1.1 MB) or retrieve directly from the SourceForge repository:

svn co http://gallery.svn.sourceforge.net/svnroot/gallery/gallery3/trunk

The Gallery 3 Philosophy

Let's have a closer look at Gallery 3.0 to see why it's so easy and fun to customize. Our user centric development process ensures that the user interface is not an afterthought.

  • Scope and target audience - Before starting development on Gallery 3.0, the target audience and the scope of the application have been clearly defined. Gallery 3 is not a general purpose web application handling any file format you throw at it. And it's not supported on every web platform that exists.

    Prudent decisions helped to simplify the product at a very early stage. For instance, there are no longer item-level permissions. Permissions are managed on an album level. This simplification extends from the database up to the user interface.

  • Simple to use - We're glad to have usability and user interface experts on our team, designing and prototyping interfaces that just make sense, avoiding the dreaded text deserts. The emphasis is on making simple, frequent tasks quick and easy. To see an example of this, check out the admin dashboard and the user/group administration page.

  • Size matters - Gallery 3.0 is currently a mere 4.1MB (uncompressed on your disk), with all its features. Compare that to the 16.5MB of Gallery 2.3's bare bones minimal package. Leaving out some levels of abstraction really helps to lose some weight!

  • On the shoulders of giants... - Gallery 3.0 wouldn't be possible without the great advances of recent years.

    • Gallery 3.0 is built on top of Kohana, a PHP 5 framework that makes PHP application development a breeze. Kudos to the folks from Kohana for their support and for providing this first class application framework!

    • Kohana's prowess in elegance and simplicity couldn't be achieved without the vast improvements of PHP 5 over PHP 4. We're glad we can finally seize the full power of PHP 5. Adios, PHP 4!

    • Remember the days before jQuery? We don't want to look back either :-) It has never easier to add interactivity, AJAX or other custom behaviors to your user interface than it is with jQuery. We use jQuery and jQuery UI widely and UI development couldn't be more hassle-free.

  • Simple to customize - Gone are the days of learning 4 different languages (HTML, JavaScript, Smarty, PHP), many different APIs (theme and core API, Gallery 2 smarty tags) and 10 step tutorials to create your own theme. With Gallery 3, you can create your own theme just by copying an existing theme to a new folder. No further changes necessary to make it work. How's that for easy? There's no templating language to learn other than HTML and PHP.

  • Simple to extend - We've exercised great restraint in keeping things simple and it shows in the small size of existing modules. For instance, it takes a small fraction of the code to create a slideshow or comments module for Gallery 3 than it took to implement the same feature set in Gallery 2.

  • Supported configurations - Gallery 3 is supported on Linux / Unix servers, running MySQL 5 and an Apache 2.2 web server with PHP 5.2. Emphasis on supported, not necessarily required. It may well work with MySQL 4.1 on MS Windows as well, but the Gallery team is going to focus its energy on making the best possible product on the supported configurations.

Currently Implemented Features

We resolved 58 separate issues in this alpha 3 release including:

  • Support for database table prefixes (alpha 3)
  • Random image block for the sidebar (alpha 3)
  • Module administration view (alpha 3)
  • Added translation server and localization client (alpha 3)
  • Reimplemented the Flash uploader using SWFUpload (alpha 3)
  • Album sort orderers (alpha 3)
  • Add photos directly from the web server (improved in alpha 3)
  • User/group/permissions management UI (alpha 3)
  • Auto-login at the end of the installer, with a welcome page (alpha 3)
  • Moved Google Maps and Polar Rose modules out of the official package into the community repository (alpha 3)
  • Localized UI with built-in editor (server side support is not finished) (alpha 2)
  • RSS feed for comments (alpha 2)
  • RSS feed for new images or movies (alpha 2)
  • EXIF read support (alpha 2)
  • Add photos directly from the web server (alpha 2)
  • Support for uploading and viewing FLV movie files (alpha 2)
  • Ability to view full size photos (alpha 2)
  • Boolean and full text search (alpha 2)
  • Album browsing
  • Item commenting, comment moderation
  • Spam protection with Akismet and Recaptcha
  • Image toolkit support for ImageMagick, GD, and GraphicsMagick
  • Theme system, including separate admin theme.
  • Module system to extend the functionality, and a series of existing modules
  • Basic metadata boolean search with relevance ranking
  • Flash-powered slideshow (Cooliris)
  • Album media RSS feeds
  • Quick edits of item metadata
  • In place item deletion and rotation
  • User group management (drag & drop interface)
  • Basic user permission management
  • Admin dashboard with drag and drop blocks

Missing Key Features

These features are yet to be added and will be part of the final 3.0 release:

  • Bulk editing of albums and photos
  • A migration path from Gallery 2
  • Improved permissions UI.
  • Basic embedding hooks / instructions
  • (opt-in) Stats collection (helps us to improve the product)

Roadmap

Gallery 3.0 has received a professional security audit from our good friends over at Gotham Digital Science. They've dissected the code and probed it for security vulnerabilities, and then reported back to us. We have not yet addressed all of their concerns in this release, but we will resolve all security issues they discovered before the final release. Your security is important to us!

You can track development on our Trac roadmap.

Got feedback?

If you have any overall feedback, please visit the Gallery 3.0 Alpha 3 Feedback forum topic and let us know! If you have questions, please visit the Gallery 3 Wiki, the future home for Gallery 3 documentation.

johndbritton's picture

/me installs G3 alpha 3 for a test drive

--
www.johndbritton.com

Localization Features:

Note: The UI for the language settings / admin menu for languages & translations isn't polished yet. It isn't very easy to understand and needs too many clicks. Please bear with us, we'll improve it. :)

Installing Translations:
1. As admin, you first need to select the languages, that should be available to your users.
To do that, go to admin -> settings -> languages. Select the language that should be available and save the selection.
This setting controls which languages are listed in the user settings dialog.

2. Install (=download) the selected translations. At admin -> settings -> languages, click "Get Updates".
This might take a while.

Changing your language preference:
Every user can select a language preference. When logged in, in the upper right corner, click on your username to get the dialog for your user settings. If the admin has installed more than 1 language, this dialog will show a language preference list.

Note: We'll add a language preference option for guests (users that are not logged in) as well.

Note: At this moment, there are just 5 or so translated messages (some Spanish, some German). So even when you change your language preference to something other than English, your Gallery will still show pretty much everything in English.
This will change as we get more and more translations.

Adding translations:
Translating is really quick and easy with Gallery 3.
1. Switch your preference to the language you'd like to translate to. I.e. ensure the language is installed and change the preference in your user settings.
2. Enable the translation mode. Click admin -> settings -> start translating.
3. Browse to a page that has some text that is still in English.
4. At the bottom of the page, in the right corner, click "Translate Text"
5. Scroll down, select a message that you'd like to translate on the left, then enter the translation on the right and click save to save it.
6. Select another message, translate it, etc.
7. Reload the page to see the page with your newly added / modified translations.

Contribute! Sharing your translations:
While translating can be fun, it's still a lot of work if you have to do it all by yourself. So we made it really quick and simple for you to share your translations such that the next user who clicks on "Get Updates", gets all your translations as well.
Initial setup:
1. To share your translations, go to "admin -> settings -> languages".
2. The first time you do this, you need to get an "API key." So you need to follow the link that it displays.
Once you followed the link, it will ask you to register a (free) account on this website here, http://gallery.menalto.com.
Once registered / logged in on http://gallery.menalto.com, it will show you the API key, something like "8373:12121gf21fgf212" (that's just an example, it won't work with this one :) you need to use the one that is shown to you).
3. Copy that API key and paste it into the form field in your gallery "admin -> settings -> languages". and hit "save settings".

Now you're ready to share your translations. To share them:
1. Go to "admin -> settings -> languages"
2. Click "Submit translations".

Note: The "Submit translations" button only appears when you added or modified at least one translation with the translation interface yourself. And it only appears if you've saved the API key some time before.

Customizing / changing text in the user interface:
You can use Gallery's translation system not only to translate all user visible text, but also to customize labels / text. E.g. if you want to change the label "Search Gallery" to "Search Eva's Gallery", then just use the translation UI for that.
1. ensure that the language preference is set English (e.g. in the user settings dialog).
2. Then browse to the page that shows "Search Gallery" and open the translation interface. Select "Search Gallery" in the listed messages, enter "Search Eva's Gallery" as translation and hit save.
3. Reload the page to see the changes take effect.

AdrianB's picture

What is the difference between Import photos from the local webserver (alpha 2) and Add photos directly from the web server (alpha 3)?

(Yeah, I'm lazy, the answer is probably in Trac.)

florin_andrei's picture

The user interface is being refined - that's great news, G2 was pretty dorky if you ask me. :-)

But I still have a few complaints:

Let's say I'm creating a new album. I click on "Add an album", and the dialog pops up, with three fields:
- Name
- Title
- Description

Huh? Name and title? What's the difference? No, no, don't send me to the documentation please, that's the wrong, G2-style, answer. G3 should be as user-friendly as Flickr, otherwise why bother doing it? I am a dumb non-technical user (well, just pretending) so this whole business of having names and titles sounds kind of redundant to me.

Okay, after poking around, I figured that Name is the string that goes into the filesystem path, while Title is the stuff displayed on the page for the user to see. From a usability perspective, this is redundant - no, more than that, it's mistaken. Don't take me wrong, you folks made great progress with G3, but you're still dragging a few "G2itis" symptoms after you, which need to be cured.

All the user cares about is the Title. The software should auto-generate the Name, pretty much like Drupal does with the Pathauto module: the author enters a title for the node entry, and Drupal/Pathauto generates the URL automatically. G3 should do the same.

As a supplement, for power users and whatnot, there should be an option to tweak the Name afterwards. But having both Name and Title on the first dialog pop-up is confusing.

Please remove Name from the album creation pop-up and allow the user to optionally alter the Name after the album is created. Name should be autogenerated from Title when the album is created.

Thanks,

--
Florin Andrei
http://florin.myip.org/gallery2/

florin_andrei's picture

By the way, don't even call it Name. Call it what it really is, Path or something like that. And throw it in the Edit Album bin, don't expose it too prominently on the album creation pop-up.

--
Florin Andrei
http://florin.myip.org/gallery2/

florin_andrei's picture

I added a few photos and I'm testing the UI. Wow, this looks waaay better than G2! Holee molee, this is great!

The slideshow is actually usable. Not just that, but it's pretty nice-looking. Sweet!

The interface overall is clean and much more user-friendly.

As the owner of the site / album / photo I need to control the slideshow app, whether it advances automatically through the pictures, or whether it waits for user input to go to the next picture. Whether it cycles back to first picture by default, or whether it stops at the end. This is something I want to set at the site level, or album level.

The buttons in image view (show large, album view, add comments, slideshow, etc.) are nice, but you need to put tooltips (mouse over) explanations on them. Or let the admin configure G3, whether the buttons are image-only (the current situation), text-only, or image and text - but even then tooltips would be nice.

When I'm logged in, and I'm inside an album, I want the Add photo button to be more prominent, not hidden in a menu. I was looking at the album kind of confused, until I realized I need to dig through menus to upload pictures. That's not nice. I'm logged in, I'm in an album, I have the rights to upload, then please put a nice big Add Photo button somewhere so I can see it. (remember, I'm the non-tech first time user who is familiar with Flickr or with Apple interfaces, so I expect the same smooth friendly experience from G3)

G3 lets me edit / delete / etc. any picture when I'm viewing the album, but after I clicked on a picture and I'm viewing it, those edit / delete / whatever buttons disappear. This is counter-intuitive. Keep them in both places.

When I edit a picture, it's the same issue like when I create an album: G3 shows me Name, Title, and Description. I understand Description, but Name and Title??? What is that?
The user, in 99% of the cases, only wants to edit the Title. The Name is usually irrelevant. I would even take that option out if I could. If you disagree with that, at least make the "Name" change less prominent, and inform the user that it's actually the File name that it's going to change. Yeah, go ahead, call it "File name", it won't confuse the non-techies, it's actually going to explain the function better.
Name and Title are too similar in meaning and are confusing.

You guys need to push that Name thing down everywhere and make it less prominent - in album creation, image editing, Photo Info block, everywhere. It's irrelevant for most users. Title is what they are looking for. Name is a technicality.

Uploading the pictures with "add a photo" failed with error 500. Server logs provide no clue. I enabled "add from server" and that one worked. This is Ubuntu 8.10, G3 was installed from the command line.

I configured G3 to resize all photos to 1024 pixels instead of the default 640, and it does, but it still displays them scaled at 689 pixels. Maybe it's a theme issue?

Once G3 goes stable, I am going to replace G2 immediately. Good job, folks!

--
Florin Andrei
http://florin.myip.org/gallery2/

florin_andrei's picture
florin_andrei wrote:
Uploading the pictures with "add a photo" failed with error 500. Server logs provide no clue.

Some clues:

2009-03-24 18:19:29 -07:00 --- debug: Global GET, POST and COOKIE data sanitized
2009-03-24 18:19:29 -07:00 --- debug: MySQLi Database Driver Initialized
2009-03-24 18:19:29 -07:00 --- debug: Database Library initialized
2009-03-24 18:19:29 -07:00 --- debug: Session Database Driver Initialized
2009-03-24 18:19:29 -07:00 --- debug: Session Library initialized
2009-03-24 18:19:29 -07:00 --- error: Uncaught PHP Error: Undefined index: extension in file core/controllers/simple_uploader.php on line 52
2009-03-24 18:19:29 -07:00 --- debug: Global GET, POST and COOKIE data sanitized
2009-03-24 18:19:29 -07:00 --- debug: MySQLi Database Driver Initialized
2009-03-24 18:19:29 -07:00 --- debug: Database Library initialized
2009-03-24 18:19:29 -07:00 --- debug: Session Database Driver Initialized
2009-03-24 18:19:29 -07:00 --- debug: Session Library initialized
2009-03-24 18:19:29 -07:00 --- error: Uncaught PHP Error: Undefined index: extension in file core/controllers/simple_uploader.php on line 52
2009-03-24 18:19:30 -07:00 --- debug: Global GET, POST and COOKIE data sanitized
2009-03-24 18:19:30 -07:00 --- debug: MySQLi Database Driver Initialized
2009-03-24 18:19:30 -07:00 --- debug: Database Library initialized
2009-03-24 18:19:30 -07:00 --- debug: Session Database Driver Initialized
2009-03-24 18:19:30 -07:00 --- debug: Session Library initialized
2009-03-24 18:19:30 -07:00 --- error: Uncaught PHP Error: Undefined index: extension in file core/controllers/simple_uploader.php on line 52
2009-03-24 18:19:32 -07:00 --- debug: Global GET, POST and COOKIE data sanitized
2009-03-24 18:19:32 -07:00 --- debug: MySQLi Database Driver Initialized
2009-03-24 18:19:32 -07:00 --- debug: Database Library initialized
2009-03-24 18:19:32 -07:00 --- debug: Session Database Driver Initialized
2009-03-24 18:19:32 -07:00 --- debug: Session Library initialized
2009-03-24 18:19:32 -07:00 --- debug: Global GET, POST and COOKIE data sanitized
2009-03-24 18:19:32 -07:00 --- debug: MySQLi Database Driver Initialized
2009-03-24 18:19:32 -07:00 --- debug: Database Library initialized
2009-03-24 18:19:32 -07:00 --- debug: Session Database Driver Initialized
2009-03-24 18:19:32 -07:00 --- debug: Session Library initialized
2009-03-24 18:19:32 -07:00 --- debug: request::method: get

--
Florin Andrei
http://florin.myip.org/gallery2/

kylehase's picture
AdrianB wrote:
What is the difference between Import photos from the local webserver (alpha 2) and Add photos directly from the web server (alpha 3)?

(Yeah, I'm lazy, the answer is probably in Trac.)

I'm also too lazy to check but it sounds like the first imports from the local file system and the other adds from a remote web server over HTTP.

Personally, I agree & disagree with the 2 previous comments. I agree its a bit confusing for those who are not used to the terms used to describe those fields. Title is pretty self explanatory, but URL (yoursite.com/(gallery install folder)/index.php/URL) sounds more logical than name.

I also like the idea of being able to determine this URL for each album upon creation as opposed to editing it later, but I don't think it needs to appear in the Album Info Block, nor the owner name. That is just my opinion.

As for this Alpha 3 Version... wow download a megabyte, extract it, upload it, run the installer page, upload pictures & have a working gallery in under 5 minutes in many cases...just amazing.

I would also like too see the header & footer text areas to accept some html. D'oh nevermind, I see that it does.

Seems to work smoothly. I am still not fond of those menus in the admin area, but I can always customize my own if the current ones are kept in the final release.

I will post again in I notice any bugs. Keep up the great work!

My Gallery 3 Alpha 3 install/demo ->
http://www.beeerlover.org/gallery3/index.php

bharat's picture

@AdrianB: The difference is that one of those lines in the news story was written by me, and one was written by talmdal. :-) We messed up-- I'll fix that shortly. Both of them are for the server_add module which lets you add photos that are already on your server (eg: stuff you've already ftp'd or otherwise copied to the server).

@florin_andrei: I agree with you about the name field. I've created ticket #179 to track it. I agree with your usability feedback; most of that is already slated to be addressed in the upcoming Beta 1 release. Keep an eye out for that. If you'd like, please feel free to file individual tickets for those items too so that you can be notified when we fix them. For the add photo problem, are you uploading a file without an extension? What's the name of the file that's causing the problem? The issue with having the resized photos show up at a smaller size is a theme decision; it's a fixed layout theme so we scale the resized down to avoid breaking the layout. You can clone the theme and remove that restriction if you'd like to play with it. THANKS for the feedback!

i love alpha3 and can't await the official release. i don't need all the thousand features of gallery2 and will immediately switch to gallery3 if the first official release is out with a working import-tool from gallery2 to gallery3. please don't forget to import the album-date, sort-order and the watch-conuter. thanks a lot :-)

some other points i noticed:

-) the module "Add from server" should sort the content alphabetically, also if the beginning of the names are numbers like (20090315_xxxx, 20090316_xxx,...), at the moment they are all in random order, its not possible to find anything if you have a lot of folders :-(; and maybe it is possible to expand the window for the folderbrowser a little bit (20-30%). my typ. foldernames are like "20090315 15-03-2009 Skitour am Hochschwab mit Johannes Philipp und Marion"; if you have lot's of folders it gets confusing if every name is shown in 2-3 lines...
-) possibility to set default sort order for album and all subalbums
-) at the moment it is not possible to sort pictures depending on exif-data (exposure-date/time), but thats the normal case, people want to see the pictures in the order they were taken by the camera and not in the order they were uploaded (i think creationdate at the moment is the date, the picture was created in the filesystem)
-) possibility to see creation date (from exif-data or a date you can set in album-options) at bottom of each album/picture (it would be nice if it's possbile to configure your own "album-date", cause date of pictures can last over more than one day...this date should be shown under the album-item (configurable)

all together great work! if gallery3 is out, i promise i'll donate again...there is no comparable product at the moment!

Unable to upload pictures. Upload error: 403.
Anny suggestions?

hmmm... was unable to "Add from Server"...

I setup the server path, say A. To add some photos under the folder D /A/B/C/D/*.jpg, I drill down and select the folder D. It is taking forever.

Having to abort and found that it created an Albums A, inside it found album B, inside it found C. ... Have not been successfully adding any photo yet. :-(

Just found that ... without any photo loaded successfully, the folder var has tonnes of photos and is more than 14G in size. The source folder only has 12 photos (around 100M)

Will start a fresh install to test again.

bharat's picture

@eliasgruber: I filed https://apps.sourceforge.net/trac/gallery/ticket/184 about the sorting issue. The rest of these are feature requests that we will eventually get to, please file them, thanks :-)

@aalang: can you make sure you're not getting logged out during the upload process? If you are, try editing core/config/session.php and set the 'regenerate' value to 0.

@eliasgruber: Its not an issue with Server Add, but an issue with the default album sort order. Go to Options/Edit Album. Change the sort order to "title". The default sort order for albums is by the internal id. Which is based on what order things were added.

@cmjimmy: Let me know how you make out (pm if necessary). I'm using the svn version and I created a staging directory that had 5 levels: staging/test/b/c/d/e. I had about 400 images in these directories. I had no trouble loading the images. Need more information so i can figure out what's going on with your add from server.

http://www.timalmdal.com

@talmdal: I am from HK. This is already 1:30am here. I won't be testing until tomorrow later afternoon. I will provide more details after testing.

There are sooooooooooo many files under the var/albums folder now, it is taking age to remove them all. :-)

@talmdal: there are 2 problems (one feature request -> sorting by exif-data in albums) and the other maybe a bug. when i start the "Add From Server" then the dialog which opens to select folders and files doesn't sort the folders. my folder with all the pictures has about 15.000 subfolders which contains the pictures. all this subfolders are shown in random order, so i am definitly not able to find the last folder at the end. all my folders start with a numer (date) like "20090315_....".

@eliasgruber: yea, i just realized that was an issue. I just committed a change that will sort the directories and files separately and then merge them together so that the sorted directories appear first followed by the files. Sorry for being so dense :-)

@cmjimmy: no hurray, when every you get a chance.

http://www.timalmdal.com

florin_andrei's picture
bharat wrote:
@florin_andrei: If you'd like, please feel free to file individual tickets for those items too so that you can be notified when we fix them.

Slideshow control enhancement:
https://apps.sourceforge.net/trac/gallery/ticket/185

Tooltips for buttons:
https://apps.sourceforge.net/trac/gallery/ticket/186

Text, image and text/image modes for buttons:
https://apps.sourceforge.net/trac/gallery/ticket/187

Make the "Add Photo" button more prominent:
https://apps.sourceforge.net/trac/gallery/ticket/188

Allow user to edit picture while viewing it:
https://apps.sourceforge.net/trac/gallery/ticket/189

Quote:
For the add photo problem, are you uploading a file without an extension? What's the name of the file that's causing the problem?

No, the files are regular JPEGs:

florin@scout:~/Desktop/2009-03-10$ ls -l
total 18724
-rw-r--r-- 1 florin florin 5965924 2009-03-11 23:45 P1010642.jpg
-rw-r--r-- 1 florin florin 6150928 2009-03-11 23:46 P1010643.jpg
-rw-r--r-- 1 florin florin 7013499 2009-03-11 23:48 P1010646.jpg
florin@scout:~/Desktop/2009-03-10$

I tried to change the extension to .JPG but then the files were not listed in the file selection dialog.

--
Florin Andrei
http://florin.myip.org/gallery2/

bharat wrote:
@aalang: can you make sure you're not getting logged out during the upload process? If you are, try editing core/config/session.php and set the 'regenerate' value to 0.

No, I'm not getting logged out, meaning I don't have to log back inn after "upload". The upload progress bar indicates that the upload progresses normally, but when full it displays the error.(setting the 'regenerate' value to 0 did not solve the issue)

@talmdal:... have got the time to testing again. I have dropped the gallery3 database, removed the gallery3 folder. Recreated the gallery3 database and unzip a new gallery3 folder.

prompted to setup the database... which has no problem at all.

tested to add a photo from local... also working fine.

enabled server Add module. and setup the path.

Back to Gallery3, options => Add from Server.
expand the tree... select one photos under the level C (/Test1/Test2/XXXX/test.jpg). On finishing, I got albums with same depth... Album Test1, Album Test2, Album XXX.. but getting an error. Likely to be caused by the folder XXX containing non-english characters. (In Alpha2, the albums were not created, only the photos, thus did not hit this problem)

Re-tested with a folder contains only English characters, select the photo only... the photos loaded without problem.

Tested once again, select the folder instead of the photo... the folder contain 1 photo...also loaded without problem.

To summarize,
- when the photo being added is some folder tree, the whole tree is re-created in Gallery3. I would hope only the last branch containing the photos was created (like in gallery2).

- When the folders containing foreign characters, the album can be created but cannot be accessed.
Similar conversion problem exist in Gallery 2.3 (Not before that). When a folder contains foreign characters, the scripts return false rather than the correct folder name. The photos in that folder cannot be loaded.

Now in Gallery3,It got the error:

Page Not Found
The requested page was not found. It may have moved, been deleted, or archived.

kohana/core/Kohana.php [787]:

The page you requested, /Test1/Test2/20090222 - ��_泥頭- ��_��_, could not be found.

- with Gallery3, the photo being loaded will be copied to the Gallery3/var/albums folders. For me, I am keeping all the photos on the server, this is doubling the storage requirement. Not sure if there can be an option to use the shortcut (links only) as in Gallery2. For most of the time, we are only watching the thumbnails and resizes. this is quite a wastage of storage.

- Slideshow, Actually, I hate the Cooliris slideshow. I prefer the Jscript slideshow found in Gallery2.3

Cheers,

@cmjimmy: thanks for the update, it certainly explains why I had no trouble, but it wasn't working for you. I've added international characters in folder names to ticket 106 (http://gallery.menalto.com/gallery_3.0_alpha_3_released#comment-304060).

If you have have an enhancement request (i.e. links) you could add it on the sourceforge trac (https://apps.sourceforge.net/trac/gallery/newticket). I never really thought of links, as I tend to upload them to a staging directory and then delete them from the staging directory when I've imported them. It also might add some complexity down the road when trying to add the rearrange functionality having to worry about links and not actual pictures. No guarantees of course, but at least its logged.

http://www.timalmdal.com

I encounter a problem to add a new user.

---
An error was detected which prevented the loading of this page. If this problem persists, please contact the website administrator.

modules/user/helpers/user.php [73]:

Undefined variable: user
---

Does anyone have this problem?

florin_andrei's picture
cmjimmy wrote:
- when the photo being added is some folder tree, the whole tree is re-created in Gallery3. I would hope only the last branch containing the photos was created (like in gallery2).

I think it's a bit more complex than that, and perhaps there is no 100% correct answer in all situations. I noticed that myself but I was not sure how to report it, until now. I created a bug report describing the problem and offering a possible solution:

https://apps.sourceforge.net/trac/gallery/ticket/190

Bottom line: in some cases, creating sub-sub-sub-albums is a good thing, such as when you're importing a structure of images already organized hierarchically (sub-sub-folders are already "albums"). OTOH, if you're importing just a folder with no subfolders, then yes, the current behavior really is counter-intuitive, it surprised myself too.

It's up to the G3 UI people to make this decision.

--
Florin Andrei
http://florin.myip.org/gallery2/

florin_andrei's picture
florin_andrei wrote:
Bottom line: in some cases, creating sub-sub-sub-albums is a good thing, such as when you're importing a structure of images already organized hierarchically (sub-sub-folders are already "albums"). OTOH, if you're importing just a folder with no subfolders, then yes, the current behavior really is counter-intuitive, it surprised myself too.

OK, I figured it out: creating the parent directories as parent albums is wrong. That's what you don't like, that's what I don't like either.

But creating the child directories of the current imported directory might be good. Really, I think it is good and natural behavior. If the directory you're importing from server has sub-directories, those should be created as sub-albums. Just don't replicate its parent directories, all the way up to the designated repository on the server.

--
Florin Andrei
http://florin.myip.org/gallery2/

There is nothing saying that you are only allowed one authorized directory. If you don't want the whole directory tree then create another authorized directory that is more specific. It's non trivial to start monkeying around with not creating intermediary directories, but I will rethink it after beta 1. Changed to an enhancement request.

http://www.timalmdal.com

florin_andrei's picture
talmdal wrote:
For what its worth, I just closed ticket #190. There is nothing saying that you are only allowed one authorized directory. If you don't want the whole directory tree then create another authorized directory that is more specific.

Or, the user will have to create a dedicated upload directory on the server, and always use that one and only that one to put pictures in the gallery. Then delete the pictures from the "buffer" directory.

Both solutions are kind of clunky (multiple authorized directories will create "garbage" in the configuration, or stale entries for directories long gone; the single "buffer" directory requires the user to be more disciplined than strictly necessary and, indeed, than many of them are capable of), but the users may tolerate them in the end, I hope. :-/

Quote:
It's non trivial to start monkeying around with not creating intermediary directories.

Would you accept patches by a 3rd party? (assuming I find some time to hack the code myself and send patches to the G3 team for review)

I hope y'all don't mind me poking at the alpha and making comments here. I am wearing the "dumb user's hat", intentionally avoiding to look at the software from the perspective of a programmer. That's why I'm saying - sure, from a programmer's perspective it makes sense to create multiple authorized directories, but from the user experience perspective that's pretty sub-optimal. The unsuspecting user will probably authorize their entire home directory (or worse :-) you know how users are) and then expect the application to behave the way I described above.

I think G3 is moving in a very good direction - perhaps that's why it's important to nip all the "geeky" bits in the bud, and offer a uniform user-friendly and intuitive behavior.

--
Florin Andrei
http://florin.myip.org/gallery2/

BassKozz's picture
florin_andrei wrote:
By the way, don't even call it Name. Call it what it really is, Path or something like that. And throw it in the Edit Album bin, don't expose it too prominently on the album creation pop-up.

I second that motion
<--- Vote to change "Name" to "Path"

@florin_andrei: comments and feedback is always good and sooner is better when the API's are more fluid than later when it is more difficult to change.

Patches or suggestions are always welcome, at this point the coding standards are fairly simple: 2 space indent, no tabs, 100 char line limit, LF as line break, open brace on the same like as the statement. The closer you get to that the easier it is for someone on the team to integrate.

We have a long list at of fixes and enhancements, so any help to make that easier is always welcome

Tim

http://www.timalmdal.com

@andrei and Talmdal... much appreciated for having same thoughts about not to repeating all the parent folders. We all organize our photos in some way or the other. It doesn't make sense that Gallery must look the same as folder structure.

Though, I believe this is not a bug, and may not not required urgent resolution. In the end, I can still do the import, then move the new album into position and delete the "empty" parent albums, I hope.

@talmdal, In contrary, I really hope there is an option to load the photos as shortcut. I have tested, after loading the photo, change the photo under the Gallery3/var/album folder to a link (back to the original photo), there is not much difference in performance that I can sense.

Cheers,

talmdal wrote:
@cmjimmy: thanks for the update, it certainly explains why I had no trouble, but it wasn't working for you. I've added international characters in folder names to ticket 106 (http://gallery.menalto.com/gallery_3.0_alpha_3_released#comment-304060).

If you have have an enhancement request (i.e. links) you could add it on the sourceforge trac (https://apps.sourceforge.net/trac/gallery/newticket). I never really thought of links, as I tend to upload them to a staging directory and then delete them from the staging directory when I've imported them. It also might add some complexity down the road when trying to add the rearrange functionality having to worry about links and not actual pictures. No guarantees of course, but at least its logged.

http://www.timalmdal.com

@malmdal: I have just figured out about the character conversions. I have to enable the foreign language (in my case is Chinese) and then change it to be the default language. Browsing to the photos now seems to have no problem.... This is working different from Gallery2.... Cheers

Seems to be working well IIS 7 running FastCGI. Noticeably quicker than G2. Only query I'd have is why short tags are being used? I always thought using <?php instead of just <? was a matter of good coding practice rather than anything? Anyway, looking good, and more to the point, lightweight and fast!

bharat's picture

@brashquido great to hear that it's running fast on IIS7! We're using short tags because it means that the PHP in our template/theme code is a little tighter. For example, with short tags:

  <?= $theme->site_menu() ?>
  <a href="<?= url::site("albums/{$parent->id}?show=$item->id") ?>"><?= $parent->title ?></a>

instead of:

  <?php echo $theme->site_menu() ?>
  <a href="<?php echo url::site("albums/{$parent->id}?show=$item->id") ?>"><?php echo $parent->title ?></a>

The reason why short tags was deprecated, about 6 years ago (I remember when I ported Gallery 1 away from short tags!) was because the "<?" symbol interferes with the header in XML files. But in retrospect that was a mistake.. they should never have gone to a more verbose format for tags. Either way, we have yet to find a site that cannot support short tags and it makes our code more dense so we're going to stick with it until we find a compelling reason to switch away.

MrWerewolf's picture

What is going on with tagging? I can't see what tags are currently on a photo, nor remove a tag from a photo. I can only see photos associated with a tag when I click on the tag link and only delete the tag from the tag admin.

I would honestly like to break away from the album/directory style hierarchical categorization of my photos. I've never been quite happy with my hierarchical structures of organizing photos so I have been wanting to tag my photos and be able to group them based on tags.

Is anything like this planned?

Thank you.

aalang wrote:
bharat wrote:
@aalang: can you make sure you're not getting logged out during the upload process? If you are, try editing core/config/session.php and set the 'regenerate' value to 0.

No, I'm not getting logged out, meaning I don't have to log back inn after "upload". The upload progress bar indicates that the upload progresses normally, but when full it displays the error.(setting the 'regenerate' value to 0 did not solve the issue)

See the attached screen dump.
Anny error logs to check? Permissions to alter? Anny ideas?

bharat wrote:
We're using short tags because it means that the PHP in our template/theme code is a little tighter.

Well done on the effort on G3.

I can see what you say on the short tags but isn't it better to follow what the php folk recommend? My php 5 ini file says...

Quote:
; NOTE: Using short tags should be avoided when developing applications or
; libraries that are meant for redistribution, or deployment on PHP
; servers which are not under your control, because short tags may not
; be supported on the target server. For portable, redistributable code,
; be sure not to use short tags.

Now, I know the default is to have it on but as you say, it was depreciated six years ago. Why break with "standards" except for a massive payback which I doubt exists here?

I don't know enough to know whether the depreciation was an error or not but the fact is that people (me for one) expect to see "<? php". I'll suggest conforming with expected norms is always better when it comes to code.

I guess it might be an advantage while writing the code if you have grown with this system but I would suggest you consider doing a find and replace before releasing the official version.

Anyway, keep up the good work.

--
Gallery version = 2.2.6
Default theme = PGtheme 1.3.0
Web Site: dakanji.com

side note: depreciation (finance / accounting) != deprecation (used in software)

Thanks for the correction.

On the tags, The reason why I am suggesting that the standard form is used is that I would have thought that one would only stray away from standard forms only when there is an overwhelmingly compelling reason to do so.

Anyway, it is a minor issue and I guess you are correct that the vast majority of servers leave the default on. However, I can just see some poor soul banging their head against the wall trying to get this suite to work.

--
Gallery version = 2.2.6
Default theme = PGtheme 1.3.0
Web Site: dakanji.com

Hi there,

I've installed Gallery3 alpha3 few minutes ago, and I found that I can't add new user, click on the "Add a new user" is doesn't do anything, but I can add new group by click on the "Add a new group"(in Linux platform, but in Windows platform, the window shown to create new group is very small in "Name",textarea,submit button and "Cancel").[img]http://vwww.where-is-it.info/gal3apa3_addnewgroup.png[/img]

Is anyone have the same problem? or is anywhere I've to adjust or setup?

Thanks.

@Morse, the "add user" issue has already been reported (previous in this post) and fixed in the svn version.

I would encourage everyone to check the open tickets at http://apps.sourceforge.net/trac/gallery/report/1 to see what has been reported and what may have been fixed since the last release.

http://www.timalmdal.com

Quick comment for Usability. When setting up. I know you want to keep it simple, but the "root" folder is always called gallery. What about the idea of during setup, you ask, "What would you like the name of your gallery?" or something like that. Then when setup is finished, the "root" folder will not be called gallery but something that looks more personal. Maybe even just "username gallery" or something like that. Just trying to brain storm and throw out an idea.

BassKozz's picture
savo wrote:
Quick comment for Usability. When setting up. I know you want to keep it simple, but the "root" folder is always called gallery. What about the idea of during setup, you ask, "What would you like the name of your gallery?" or something like that. Then when setup is finished, the "root" folder will not be called gallery but something that looks more personal. Maybe even just "username gallery" or something like that. Just trying to brain storm and throw out an idea.

I could be wrong here, but I believe you can unpack the files to whatever directory (root) you want and then install.

No, thats not what I'm referring to. I'm talking about visually you see Gallery as the root bread crumb after install.

My point is why should I have to go and change that again. I would have thought that you could do that during the install and not have to manually change it.

I've tested Gallery 3.0 Alpha-3. It looks useful and clear looking.
I miss two features from Gallery 2 that I widely use.

1. size limiting - actually image downsamling of a picture that is being uploaded.

2. lightbox slide show
Yes, you have included Cooliris slide show. But the problem at Cooliris is that you cannot set a picture size - so the small pictures are stretched all over the screen and they don't look nice. I would just like to have them in an original pixels size (as it is in the gallery). Lightbox slide show gives me that option and that's why I prefer it. It also gives me the possibility to download pictures of an album in cache (or in advance) - which is useful because I have slow connection to the server.

jureb wrote:

2. lightbox slide show
Yes, you have included Cooliris slide show. But the problem at Cooliris is that you cannot set a picture size - so the small pictures are stretched all over the screen and they don't look nice. I would just like to have them in an original pixels size (as it is in the gallery). Lightbox slide show gives me that option and that's why I prefer it. It also gives me the possibility to download pictures of an album in cache (or in advance) - which is useful because I have slow connection to the server.

I shared this view with you... fully support. :-)

bharat's picture

@MrWerewolf: We'll be improving the tags ui and the ability to edit tags in upcoming releases. It's by no means done in its current state.

@aalang: 403 is a "forbidden" error which means that somewhere along the line there's probably a permissions error. If you can reproduce this in the next release (beta 1) we should investigate more deeply. In the meantime, you can look in var/logs or if you're fluent with PHP code, you might start with core/controllers/simple_uploader.php and track through the code to see where the 403 is coming from.

@dayo: We spent some time on the short tags issue and came to the conclusion that it is worth the win. I believe that the decision to drop short tags was hasty and underthought. I don't believe that support for it is going away (and clearly I'm betting on it with G3, although we could easily convert our templates to long tags if we had to).

@savo: we're aiming for a 1-click install. If the option can be set in the app itself, we are unlikely to put configuration for it in the installer. We'd much rather that you get into the app and administer the app itself instead of spending your time in the installer.

@jureb: slideshow is a tradeoff of time and energy vs. results. Using CoolIris gives us good results with a very small amount of effort. It would be very easy for the community to write a lightbox slideshow module, so we probably won't put core dev cycles on it.

Quote:
@jureb: slideshow is a tradeoff of time and energy vs. results. Using CoolIris gives us good results with a very small amount of effort. It would be very easy for the community to write a lightbox slideshow module, so we probably won't put core dev cycles on it.

Well for me a result is very significant, because Cooliris for now doesn't give me the possibility to choose actual size of picture and the picture doesn't look good. Beside that slide show gives me an option of downloading pictures in advance and I don't have to wait them because of slow server connection.

There is already a ticket for a LightBox-module and it looks like it is planned to be part of the Beta1 release, I am hoping that it will be implemented as I agree that this is an important function.
(The ticket was in the Alpha3 release but did not happen)

The Ticket is assigned to lvthunder, maybe he can give some input here on the status?

http://apps.sourceforge.net/trac/gallery/ticket/91

Hey,

I 'm new to this script but it looks nice!
Most of the work i do is concert photography.
I d like to know how deep the tree can go.
for example albums: music -> Fest/Event -> Band (photo)
Is this possible?

And any clue on when Gallery 3.0 is totaly ready?

Tnx a lot
Mathijs