Gallery 3.0 Alpha-1 Feedback

@Fjelsten: How that works depends entirely on the theme. Some themes may do it the way you want, some may not. The default theme will probably consider the full-size image separately, after all most full size images barely fit using the entire screen. Doesn't sound like a dealbreaker to me, but perhaps you have other problems with G3.

Well, I was thinking about a workaround with 2 different sizes one of which was the "full screen" since you (to my disappointment) have done away with resized versions.

I think it's important to show pictures as best they can and that would include "as large as possible on the screen" but people's screens are different. I like the PBase way of remembering the size.

I scale all images before upload.

@cj_nza: We will almost definitely implement table prefixes so that you can have multiple installs in the same db. Just haven't gotten around to it yet

Would appear twas a case of a dirty parent object when stepping out a level of recursion. Reloading the parent before adding the next album fixed the problem Now I have a working add_from_server which I now just need to write a UI for :D

i get the "Framework erroe" when installing

"Please check the Kohana documentation for information about the following error."

how to solve?

AjantaKVS

I am facing same problem here, Did you find any solution to this, please let me know how you over come this problem or is it still persists ?

It appears that some people are putting bugs here. I hope this is the right area to do it.

I'm attempting to install Gallery 3.0 Alpha 1 on my VPS for testing. I'm running PHP 5.2.6, Apache 2.2.11, and MySQL 5.0.67.

When entering in my MySQL data, the first time I try it, it says that it has an error connecting to the database. However, I know the information is correct. Subsequent attempts then give me the error:

"The database you provided already has other tables in it. Continuing with the install might overwrite an existing Gallery install. Please go back and choose a different database."

The only table in there is one named access_cache.

I've tried making several blank databases and all fail as stated above.

Assistance would be appreciated. I'm really wanting to see what G3 looks like.

Thanks.

Hello.

I wanted to test drive Gallery 3.0 Alpha-1. The installation went well.

But: When I try to visit the gallery I get the following error:

Fatal error: Cannot access empty property in D:\web\galleri3\kohana\libraries\drivers\Database\Mysqli.php on line 122

Technical information:
OS: Windows Vista Home Premium.
Web-server: XAMPP for Windows v. 1.7.0 (Apache/2.2.11, MySQL/5.1.30, PHP/5.2.8).

Address: http://web.brr.no/galleri3/
My Gallery 2 installation which works great: http://web.brr.no/galleri2/

Hopefully some have a problem solution?

***
Bjørn Roger Rasmussen - http://www.brr.no/

If I'd like to do the localization work, should I wait the i18n UI or I can do it now on the kohana\i18n\en_US folder?

I've been poking at a local import as well. Started it awhile ago, but had other g3 modules to write.

http://www.timalmdal.com

Adding images doesn't gracefully detect image file errors.

I was importing a large number of files with the scaffolding and Gallery3 would crash with Framework Error

Please check the Kohana documentation for information about the following error.

kohana/libraries/Image.php [92]:

The specified image, /srv/www/vhosts/base/gallery3/var/albums/152244923.jpg, is not an allowed image type.

When I try uploading the same image with the Flex uploader, it uploads, but doesn't show any thumbnails or alternate sizes.

After some sleuthing, I discovered that the file is actually a bmp file that somebody changed the extension to jpg.

I don't expect Gallery to work around this, but could it do some simple checking upon regular ingestion and warn of an improper file type or somesuch?

@JadeDragon: Ah, that's an issue with the way we support IE in alpha-1. Try the latest code from svn, that should be fixed now.

@advicepig: good catch, we'll be making the uploader more robust in alpha-2 and beyond.

@trumpy81: we're going to make the uploader more robust and will resolve that issue. The latest code uses a flash based uploader that's much easier to use. We've also hidden the add comment form.. it flies open when you click on it. As for the square thumbs module, we don't have plans currently, but it should be possible as a 3rd party module if there's interest.

Just had a really odd error in an SVN build (r20121)

I came back to the office after a day of productively loading, tagging, and organizing photos in Gallery 3. Since it's all testing right now, I'm running in a virtual machine on my desktop and the virtual machine was shutdown overnight. I started it up and got to work.

I tried deleting a photo and it sat there spinning the AJAX animation and the photo remained. I tried a few others, both in the main gallery and in sub galleries. All of three of which remained in a spinning AJAX state.

I logged into the logs directory and tailed them to see nothing terribly useful, but upon returning to gallery, I got an exception error.

exception 'Exception' with message '@todo MISSING_MODEL access_cache:60' in /srv/www/vhosts/base/gallery3/core/helpers/model_cache.php:27
Stack trace:
#0 /srv/www/vhosts/base/gallery3/core/helpers/access.php(90): model_cache_Core::get('access_cache', 60, 'item_id')
#1 /srv/www/vhosts/base/gallery3/core/helpers/core_theme.php(54): access_Core::can('edit', Object(Item_Model))
#2 [internal function]: core_theme_Core::thumb_top(Object(Theme_View), Object(Item_Model))
#3 /srv/www/vhosts/base/gallery3/core/libraries/Theme_View.php(172): call_user_func_array(Array, Array)
#4 [internal function]: Theme_View_Core->__call('thumb_top', Array)
#5 /srv/www/vhosts/base/gallery3/themes/default/views/album.html.php(16): Theme_View->thumb_top(Object(Item_Model))
#6 /srv/www/vhosts/base/gallery3/kohana/libraries/Controller.php(74): include('/srv/www/vhosts...')
#7 /srv/www/vhosts/base/gallery3/kohana/libraries/View.php(266): Controller_Core->_kohana_load_view('/srv/www/vhosts...', Array)
#8 /srv/www/vhosts/base/gallery3/core/libraries/MY_View.php(29): View_Core->render(false, false)
#9 /srv/www/vhosts/base/gallery3/kohana/libraries/View.php(244): View->render()
#10 /srv/www/vhosts/base/gallery3/themes/default/views/page.html.php(52): View_Core->__toString()
#11 /srv/www/vhosts/base/gallery3/kohana/libraries/Controller.php(74): include('/srv/www/vhosts...')
#12 /srv/www/vhosts/base/gallery3/kohana/libraries/View.php(266): Controller_Core->_kohana_load_view('/srv/www/vhosts...', Array)
#13 /srv/www/vhosts/base/gallery3/core/libraries/MY_View.php(29): View_Core->render(false, false)
#14 /srv/www/vhosts/base/gallery3/kohana/libraries/View.php(244): View->render()
#15 /srv/www/vhosts/base/gallery3/core/controllers/albums.php(64): View_Core->__toString()
#16 /srv/www/vhosts/base/gallery3/core/controllers/rest.php(95): Albums_Controller->_show(Object(Item_Model))
#17 [internal function]: REST_Controller->__call('1', Array)
#18 /srv/www/vhosts/base/gallery3/kohana/core/Kohana.php(270): ReflectionMethod->invokeArgs(Object(Albums_Controller), Array)
#19 [internal function]: Kohana::instance()
#20 /srv/www/vhosts/base/gallery3/kohana/core/Event.php(209): call_user_func(Array)
#21 /srv/www/vhosts/base/gallery3/kohana/core/Bootstrap.php(55): Event::run('system.execute')
#22 /srv/www/vhosts/base/gallery3/index.php(61): require('/srv/www/vhosts...')
#23 {main} 

At first, this took the place of what should have been the second photo, but upon page reload, it took the place of the first photo. It's worth noting that I did try to delete the first photo when this all started. Let me know what other info would be useful for debugging. I may spin up another virtual machine to keep testing on so we can keep this on in whatever state it's in.

@advicepig: That's odd. Sounds like your access_caches table is out of sync with your access_intents and items tables. If you've still got those tables, let's see if we can figure out what's going wrong. Try doing this query:

select i.id from items i left join access_caches ac on i.id = ac.item_id where ac.item_id=null;

Do you get any rows back? Try this query too:

select ai.id from access_intents ai left join access_caches ac on ai.item_id = ac.item_id where ac.item_id is null; 

Thanks!

My thoughts, no order....

Ability to link directly to the image, easily. Would like it so you click thumb, see resized, text link or image click to full size directly, no HTML page wrapped around it.

Keep the watermark functionality. Keep original images available in seperate folder.

Remove the index.php from the mod_rewite
Remove the .jpg or extention from the mod_rewrite (full pages)
Minimalize php strings on pages. No ?&page=2 &size=large. New rewrites for all that or not at all.

Have the search pages display like gallery pages. Same columns, rows, text, styling.
Have choice to display albums first in search results.
Have the urls to the search results items be direct links to the item page, album page, not /items/whatever. Do it there. Duplicate content, and people will copy/paste those links in other places eventually, populating the internets with 404 links to your site when the sessions is done.

If you do the above, creating a text link such as /g3/index.php/search/televisions will provide you with the pretty/SEOd/relevant pages you need to link to anything (if the search rewrite is created). Really, this has SO much potential.

Tags - Make the url to tag results use the tag name. /tags/Sony+Televisions not tags/2.

Multiple Tag Groups / Custom Fields
- Need to be able to group items outside of hierchial category structure and pull those lists onto sidebar blocks in sorted order (alphabetical, max # or all). Example usage -

Tag Group - Televisions
Tag - Sony
Tag - Hitachi
Tag - Zenith
Tag - Vizio

Tag Group - Size
Tag - 30 Inches
Tag - 42 Inches
Tag - 46 Inches
Tag - 50 Inches

Going to those pages should lay out and look just like a regular album, but go to the original location. Hit back or re-click the tag/custom field to get to the place you were. No multi breadcrumbs.

Just labeling each entry in one giant tag list such as - sony, 50 inch, black, 2009 - etc will not work, no way to sort and present the data to people unless you hand code HTML.

If you use custom fields, and that can easily be referenced in a module via a php call, sorted and displayed, thats cool too. <?php pull list sort asc field2 ?> <?php for each list <li>listitem</li> ?> etc. Im no php coder.

A better reasoning for this - I wold like to display art from people, and be able to have one sidebar block for artist names. One for types of art they do. One for the years they were done in. Tags as they are can not handle that. And duplicating images into dozens of categorized sub-albums is silly.

These are issues I generally had with G2, based on what I saw in someone's installation of G3 so far. My temp hosting acct doesnt have php 5.2.6 installed, so I havent played with it yet. Will sound off after I install and work with things on primary server.

I also suggest creating a module creation forum and repository, with requests, in progress/final marking, supported/non-supported, etc. Get an environment like Vbulletin.org going, rather than just a download center.

And thanks, I hope G3 kicks ass and returns Gallery to the glory days. I may not post, but I have over 150,000 images spread across 9 G2 installations on one domain, and serveral other G1 and G2 installations. So I know its power and back end features, but also know that doing anything not readily available is next to impossible. So I'd like G3 to make those things (like above) possible. Either by default, or by modules being easy to code.

@2005: We'll do something sane with the full size image, but it's easy for you to do it differently in your own theme if you'd like. We'll fix up the short urls to remove the index.php (requires some fairly complicated mod_rewrite trickery to autodetect this properly) and probably append .html to the end of urls that aren't going directly to an image. We will probably keep some query param strings (?page=x, etc) at least for now. Rewriting all of those has significant complications. We probably won't get to doing the really SEO friendly urls in 3.0, maybe in 3.1.. but we will probably get to doing SEO friendly urls for tags. Multiple tag groups and custom fields won't show up in 3.0, and probably not even in 3.1 That's something where somebody could write a 3rd party module pretty easily. We'll be setting up forums for G3 modules as we get closer to release.

@stodds: As of r20315 I've changed the description column to be 2048 characters. Can you show me a non-pathological case where the exif values are > 255 chars? If so, I'll make the exif_keys.value column larger also.

@stodds good point. I've bumped the size of the value column in the exif_keys table up to 1k.