Random albums showing up blank

I have been having the same problem as BillWill with random albums not showing their contents. The info is there but not showing. The problem started with the upgrade to 3.0.4. You can search for a photo in the blank album and it will show as a search result.

Other than the random blank albums, the rest of the gallery works fine. I can add photos, label photos and move photos.

Operating system: Linux 3.2.1-gentoo
Apache: Unknown
PHP: 5.3.8
MySQL: 5.0.91
Graphics toolkit: imagemagick
Graphics Toolkit: ImageMagic
Albums: 822
Photos: 18342

After upgrading to version 3.0.3 I noticed that some searches would show an empty album, even though I know there should have been results. I thought that this was just a bug in the search module.

When I try to 'Organize' one of these empty albums, I get the message 'An Error occurred, consult your system administrator'

I have tried dissabling all unnecessary modules with no luck.

This is a typical error that I retrieved from the log file when I get a blank album:

2012-06-17 09:00:38 -04:00 --- error: ORM Validation has failed for items model
#0 /htdocs/gallery3/system/libraries/ORM.php(755): ORM_Validation_Exception_Core::handle_validation('items', Object(Validation))
#1 /htdocs/gallery3/modules/gallery/models/item.php(773): ORM_Core->validate(NULL)
#2 /htdocs/gallery3/system/libraries/ORM.php(778): Item_Model_Core->validate()
#3 /htdocs/gallery3/modules/gallery/libraries/MY_ORM.php(34): ORM_Core->save()
#4 /htdocs/gallery3/modules/gallery/libraries/ORM_MPTT.php(79): ORM->save()
#5 /htdocs/gallery3/modules/gallery/models/item.php(523): ORM_MPTT_Core->save()
#6 /htdocs/gallery3/modules/gallery/models/item.php(291): Item_Model_Core->save()
#7 /htdocs/gallery3/modules/gallery/models/item.php(138): Item_Model_Core->relative_url()
#8 /htdocs/gallery3/themes/browny_wind/views/album.html.php(18): Item_Model_Core->url()
#9 /htdocs/gallery3/system/libraries/View.php(318): include('/data/23/2/84/1...')
#10 /htdocs/gallery3/system/libraries/View.php(260): View_Core->load_view('/data/23/2/84/1...', Array)
#11 /htdocs/gallery3/modules/gallery/libraries/MY_View.php(75): View_Core->render(false, false, false)
#12 /htdocs/gallery3/system/libraries/View.php(226): View->render()
#13 /htdocs/gallery3/themes/browny_wind/views/page.html.php(128): View_Core->__toString()
#14 /htdocs/gallery3/system/libraries/View.php(318): include('/data/23/2/84/1...')
#15 /htdocs/gallery3/system/libraries/View.php(260): View_Core->load_view('/data/23/2/84/1...', Array)
#16 /htdocs/gallery3/modules/gallery/libraries/MY_View.php(75): View_Core->render(false, false, false)
#17 /htdocs/gallery3/system/libraries/View.php(226): View->render()
#18 /htdocs/gallery3/modules/gallery/controllers/albums.php(77): View_Core->__toString()
#19 [internal function]: Albums_Controller->show(Object(Item_Model))
#20 /htdocs/gallery3/system/core/Kohana.php(331): ReflectionMethod->invokeArgs(Object(Albums_Controller), Array)
#21 [internal function]: Kohana_Core::instance(NULL)
#22 /htdocs/gallery3/system/core/Event.php(208): call_user_func_array(Array, Array)
#23 /htdocs/gallery3/application/Bootstrap.php(67): Event_Core::run('system.execute')
#24 /htdocs/gallery3/index.php(113): require('/data/23/2/84/1...')
#25 {main}
2012-06-17 09:00:38 -04:00 --- error: Validation errors: Array
(
[name] => illegal_data_file_extension

This is a typical error that I retrieved from the log file when trying to 'Organize':

2012-06-17 08:42:58 -04:00 --- error: ORM_Validation_Exception [ 44 ]: ORM Validation has failed for items model
/htdocs/gallery3/system/libraries/ORM_Validation_Exception.php [ 20 ]
#0 /htdocs/gallery3/system/libraries/ORM.php(755): ORM_Validation_Exception_Core::handle_validation('items', Object(Validation))
#1 /htdocs/gallery3/modules/gallery/models/item.php(773): ORM_Core->validate(NULL)
#2 /htdocs/gallery3/system/libraries/ORM.php(778): Item_Model_Core->validate()
#3 /htdocs/gallery3/modules/gallery/libraries/MY_ORM.php(34): ORM_Core->save()
#4 /htdocs/gallery3/modules/gallery/libraries/ORM_MPTT.php(79): ORM->save()
#5 /htdocs/gallery3/modules/gallery/models/item.php(523): ORM_MPTT_Core->save()
#6 /htdocs/gallery3/modules/gallery/models/item.php(276): Item_Model_Core->save()
#7 /htdocs/gallery3/modules/gallery/models/item.php(184): Item_Model_Core->relative_path()
#8 /htdocs/gallery3/modules/gallery/models/item.php(207): Item_Model_Core->thumb_path()
#9 /htdocs/gallery3/modules/organize/controllers/organize.php(66): Item_Model_Core->thumb_url()
#10 [internal function]: Organize_Controller->album_info('8013')
#11 /htdocs/gallery3/system/core/Kohana.php(331): ReflectionMethod->invokeArgs(Object(Organize_Controller), Array)
#12 [internal function]: Kohana_Core::instance(NULL)
#13 /htdocs/gallery3/system/core/Event.php(208): call_user_func_array(Array, Array)
#14 /htdocs/gallery3/application/Bootstrap.php(67): Event_Core::run('system.execute')
#15 /htdocs/gallery3/index.php(113): require('/data/23/2/84/1...')
#16 {main}
2012-06-17 08:42:58 -04:00 --- error: Validation errors: Array
(
[name] => illegal_data_file_extension

Thank you for any help or light that you can shed on this problem

Not using 'about this album'

Paul

Maybe a little demonstration will help.
Go to http://www.pjg.com/gausgallery3/ (I have changed the url since this post)

Pick 'Carl Gaus Photos'
Pick '1919 and Earlier'
Note the blank album (There are 45 pictures in this album).

Now 'Search' for 1919, and/or 1915 and/or 1890.
You will see pictures that are in the '1919 and Earlier' album.

Most of the other albums work like you would expect. I have found about a dozen albums (out of 800+) so far with this same problem.

Like I said, I can add photos, label photos and move photos with no problem unless it involves one of the defective albums.

One more example: Follow this one; pick Carl Gaus Photos, then 1950's, then 1954. This is a 2 page album......go to the second page.

Paul

I have run the fix your gallery several times.

Paul

The size difference can be accounted for by the caches table I bet.

I'm at a loss for the original issue.

Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team

Did a restore to the day before the upgrade. I am back to normal.

I am having a similar problem with searching. I will start another thread in the next week or so. Thank you for your effort.

Paul

I hope I am not speaking too soon. I think my problem is solved.

I reinstalled Gallery 3.0.4 from scratch today. I noticed while the files were uploading that a couple of errors occurred. I uploaded a second time, overwriting each file. No errors occurred. (I had to answer 'overwrite the file' for each file)

I went through the update process with no glitches. It all seems to work properly.

It may have been that some of the files did not upload properly or completely the first time I tried a couple of weeks ago.

I am keeping my fingers crossed.

Thanks, pjgaus. Did a fresh install, but still getting the same thing. Will start a new thread.

I'm having the same problem as indicated in this thread. I'm trying to decide whether to try to downgrade (I have a db backup but not a full file backup) or just disable the site and watch these threads to see what ends up happening.

I didn't look to see if there was an upgraded HTML Purifier addon when I upgraded to 304 so I just tried disabling that. Some of the photos seemed to return, but not all - so probably just coincidence.

I rebuilt images, updated search index and used "fix your gallery" and nothing changed.

I'm running G3 on a Linux/Apache2/MySQL platform. (I switched from a Windows platform specifically for G3.)

The photo stream on the dashboard page doesn't work properly, nor does the "random image" addon. (I tried disabling that addon and it made no difference.)

My server runs on a computer in the basement and I have a few other PHP applications which use the MySQL installation and they're not having problems. I have very minimal traffic on my web server, which is probably why it's taken me so long to find out about this problem.

EDIT (edit later edited as well /sigh):
Well, did find that the php.ini for PHP itself had been changed at some point (possibly by an "auto" Ubuntu upgrade of PHP?) and the date.timezone variable removed. But everything else seemed unchanged. (So perhaps I just never set this variable? Thought I had though...) Fixing that solved a time problem I had noticed, but not the problem at hand. I did notice in the PHP log in the /var directory I'm getting "error: File not found: rss%2Ffeed%2Fcomment%2Fitem%2F5530". I don't know how to fix this error and don't know if it's related to the problem at hand. (Perhaps it was caused by the date.timzone problem.)

I attempted to downgrade my install back to v303 by just deleting all the files and folders except the var directory and replacing them with the v303 files. The admin page indicated I was running v303, but the problem described in this thread was still apparent. I don't recall if the upgrade to v304 changed anything in the database or not, so I don't even know if a downgrade in this manner is even possible. I run on a virtual machine so it wasn't a big deal to try though. I can verify that this was not a problem when I was running v303, but I do not whether the problem became apparent as soon as I upgraded to v304 for sure.

Most albums show up fine, some photos inside albums show up fine but others just show blank space. If I hover over the blank space I can see the title information for the photo which normally shows up underneath. If I click on the "blank photo" I get a blank screen. Also, if I click on a photo I get a blank screen as well (instead of the normal size version of the photo.)

I guess for now I'll just leave my site in maintenance mode until we get somewhere with this. The only error which consistently shows up in my G3 logs is the one I mentioned above about the rss file not being found. It's a different filename each time though.

I just had one thought... Ubuntu has recently updated one or more of Apache, PHP and MySQL. Is it possible this could have caused a problem? Per the Dashboard I'm running Apache 2.2.22 (Ubuntu); PHP 5.3.10-1ubuntu3.2; and MySQL 5.5.24-0ubuntu0.12.04.1.

One other thing, on any page in G3 with photos, the it takes a long time for the page to finish loading (like the browser is waiting for files which aren't being uploaded by the web server) before many (but not for every photo) placeholders show up. I tried switching the graphics module from ImageMagick to GD. I have tried accessing the site via Chrome, FF and two different versions of IE. I have also tried accessing it locally and from work. I have also tried turning off all firewalls to my network - all to no avail.

Could anything on the page linked below be related? It shows some changes in a somewhat recent security release of PHP5 for Debian/Ubuntu. (I use Ubuntu 12.04 LTS.) Perhaps only Debian/Ubuntu users are experiencing this problem? (Reaching for straws here...)
http://www.ubuntu.com/usn/usn-1481-1/

Since downgrading to version 3.0.3, the site has been working perfectly. Many, many hours have been spent with no errors.

Gork, the method I used to downgrade differed slightly from yours, which may make a difference. I would do a clean install in a new directory for the v3.0.3 program. Then move the var directory into the new program directory. This is similar to the instructions for upgrading the program. The upgrade instructions do not call for copying files into the old directory. I did nothing to the database during the downgrade process.

I am glad I am not the only one who is having the problem. Like I said above, my conclusion is that there is a gremlin in the 3.0.4 code (or a conflict with my server settings). I just hope that someone who is knowledgable will be able to pinpoint the problem and offer a solution.

Good luck

@pjgaus
I followed your directions to attempt another downgrade to v303 and it didn't change anything. The Dashboard shows I'm now at v303 but the same problem is apparent. Is this exactly how you downgraded the last time? You didn't do anything which would have also restored a previous version of something else, say PHP for instance? Or did you perform a "restore" to "how it was before" on your web server?

If I think of anything else to try I'll do so and post back, otherwise it seems G3 is dead in the water on my system. Unless something else has been made available since the last time I checked, I guess it'll be back to a static photo site. Reliable, but SO time consuming! I'll give myself some time to see if I, or anyone else, can come up with any other ideas first though.

I'm still not convinced this isn't a clash with the latest Debian/Ubuntu PHP version as I posted previously, but figuring that out for sure is beyond my capabilities.

Hi, guys. Looking at @pjgaus's error it's because there's an item (photo or movie) in one of his albums that has an illegal file extension (a file extension is ".png" or ".jpg"). I'm guessing this is because you have an item which had one of these cases:

1) a file which contains more than one "." character
2) a file without an extension at all

I think those are the two extra security checks we made to the system. I'll go ahead and code up a new upgrade path that resolves those and get it checked in, then you can try again with a nightly build of 3.0.5 and see if that fixes it. I'll get back to you shortly - though in the meantime if you can look in your var/albums directory at the album in question, can you tell me which of the above issues you triggered? Fixing the "more than one dot" issue is easy, I'll just nuke the first one. But adding an extension if there's no extension at all is harder.

I filed this ticket: https://sourceforge.net/apps/trac/gallery/ticket/1894
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

I checked 2 of the albums that I remember that screwed up. Both had a file with 2 .'s in the name. One was named 'G1869 SSHerman..JPG', the other was named 'James G. Nitch JHS1954.jpg'. So far, I have no files without an extension.

I guess that I will have to check all of the file names and make changes before I upgrade.

I'll try to put together a database dump on the items table. I have to ge meet someone right now but I will do it when I get back.

@bharat
If there's anything I can do to help please let me know. I get no errors in any logs; my browser just waits for information until it times out when I visit my photo site. I can message/email you my URL, admin un/pw, database dump - whatever you think might be helpful. In quickly looking at filenames in a few directories this "illegal character" and "no extension" problem doesn't appear to be my problem. So unless such a filename anywhere in the albums directory will cause the problem even in a gallery directoy where there are no illegal filenames this doesn't appear to be the problem I'm having.

@pjgaus
Thanks, I guess that means it's possible some other "interfering" application (php? mysql? etc) could have been restored as well. ??

@bharat
I sent you a pm with the url to my gallery. My photos have long filenames and are riddled with minus, space and underscore characters. I'm wondering if maybe something in my filenames isn't allowed anymore. My original filenames, before using G2, also contained apostrophe and ampersand characters but G2 changed those to underscores.

I'm so glad you're concerned with this stuff - I was worried that maybe since it isn't affecting everyone it was shelved. Thank you.

Yes, I had many pictures with multiple "." characters.

Everything is ok in the latest build.
Thank you bharat

Unfortunately, upgrading to the latest nightly did not solve my problem - seems to be no change. The Dashboard shows Gallery 3.0.4 (build 236 on branch 3.0.x). I also tried disabling every module the program would allow me to, cleared cache, cookies etc - just to be sure.

I'm reversing the changes back to the normal 3.0.4 (saved the state in VMware) but will be happy to upgrade again per any further ideas. I've been kinda' wondering if my problem may not be the same as pjgaus because I can't find any multiple "." characters in filenames I've looked at, plus attempting to downgrade to 3.0.3 didn't solve the problem either. I never had the problem in 3.0.3 until after I upgraded to 3.0.4 though, but I'm not sure if the problem was apparent as soon as I upgraded to 3.0.4 or not. It seems like, though I can't be sure, it was working properly after my initial upgrade to 3.0.4. Heck, dunno' why I wouldn't have checked into it at least a little!

hm. i don't have any pictures with two dots (as per http://gallery.menalto.com/node/107580), but changing to the nightly channel (branch 3.0.x, build 237) fixed the issue.
probably other characters are affected as well?

thanks for the fix anyways!!

xxx@juggernaut:~$ php -v
PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch (cli) (built: Jun 13 2012 17:19:58)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

I just figured out at least part of what is causing this problem. Any photo with a space in the filename is not showing up properly. For testing, one of my photos had a filename of "A Lighthouse From Aboard the Ferry.jpg". This photo would not show up in the gallery, instead becoming a placeholder after a 10-15 second wait. When I renamed the file, through gallery, to "aaa.jpg" it showed up fine. When I then renamed it to "aaa aaa.jpg" it had the same problem as before and showed only a placeholder.

One other thing I noticed. When I tried to change the filename, it took a long time after clicking on EDIT before the edit window popped up - a good 20 seconds at least. And then after changing the filename and clicking on MODIFY it took another good 20 seconds for the change to take place and the edit window to close. It didn't seem to matter if spaces were contained in the filename or not with regard to this "20 seconds issue." EDIT: (I later observed that this "20 seconds issue" seemed only when the page was trying to load, before the photos with spaces in the filenames became "placeholders.")

Is there a reason why spaces in the filename would be causing this problem? And why if this wasn't a problem in v3.0.3 originally is it a problem now when I "downgrade" from v3.0.4 to v3.0.3?

I should add that photos used as an album cover show up properly in the thumbnail album cover. And also... Once and awhile a thumbnail of a photo with spaces in the filename does actually show up, but rarely. And even when it does, clicking on the thumbnail results in a blank large photo instead of the actual large photo.

I'm guessing this may also be what's causing my RSS feed errors in the log to, but I'll have to wait and see about that I guess.

Would someone using v3.0.4 mind temporarily renaming, through the G3 edit window, one of their photos to a filename with spaces to see if the same thing happens to them? (Actual filename in the filename field, not the description field or something else.)

EDIT:
(strikethrough) I received a PM from someone who was able to try this and they verified spaces in filenames didn't cause a problem for them. One step forward and two steps back? I just don't get it... Could this be due to something left behind since I imported my old G2 info into G3? Ugh.

Yeah, I used v3.0.3 and had no problems with my filenames - spaces or no. I can't figure out for the life of me why I'm having this issue now, especially when I have confirmation that spaces are working in filenames for others running v3.0.4 with the same PHP version I'm running as well.

I finally figured out and am in the process of solving my problem. I finally got enough data to sit back and try to compare notes - what possibilities could be ruled out by my own findings and information shared by others.

IT WAS MY FIREWALL DEVICE... I don't have the specifics yet, but I have narrowed it down to the ADP (Anomaly Detection and Prevention) settings. If I disable ADP altogether everything works as it should. I just need to try to figure out what part of ADP is causing the problem and decide on the best solution.

As time passed it seemed less and less like a coding problem, or problems between software, and with my last find that traffic to Gallery from my LAN (which goes through a swtich - doesn't touch the firewall device) led me down this path. I had disabled the actual firewall part of the device to test awhile back, but it dawned on me as I sat down to the computer just now that all that traffic generated per page, with odd filenames, could show up as an attack. Add to that the randomness of the photos which wouldn't work correctly and it kinda' fell into place.

Thank you to everyone for helping with this; sorry I'm such a dork! In the beginning I really thought what was happening to me was the same as what others posted but as it turns out I guess I accidentally hijacked the thread - not related at all.

EDIT:
My ZyWALL 20W UDP was identifying access to my Gallery3 install as an ASCII-Encoding Attack. It's basically an on or off situation for this specific ADP rule; no settings allow me to ignore it in only specific circumstances. So I switched that particular rule to allow and log and am moving on with my life. ;)