Gallery 3.0.5 Feedback Thread

Hmmm, it seems that something is going wrong on the web servers, runs on the ports different from 80.

There are settings (under Advanced) for apple_touch_icon_url and favicon_url, use those instead of constantly re-replacing default icons.

I have been very tense for the past several days preparing myself for this upgrade, but alas it was nothing.
My host has Softaculous software, and it did everthing in one minute. All is good.

I upgraded to gallery 3.05, but had to undo a Kohana patch and run under PHP 5.2.17 rather than PHP 5.3.10 in order to be able to get it to work. I posted details on the troubleshooting forum, but have had no response yet.

Hey everyone,

Re: the Kohana / Zend Guard Loader issue...

The fundamental problem here is that:
- Gallery v3.0.5 is based on the Kohana v2.4 framework
- Kohana v2.x is (in general) incompatible with Zend Guard Loader
- Zend Guard Loader is installed by default on many PHP 5.3 installations, even though many things (incl. Gallery) don't use it.

This explains why downgrading to PHP v5.2 often "fixes" the problem - it's not PHP; it's Zend Guard Loader.

So, there are two solutions:
- Modify Kohana v2.x to be more compatible. This was the approach we took, and it does work better on some installations.
- Turn off (or turn down) Zend Guard Loader. The gentlest way to do this is to change the "zend_loader.obfuscation_level_support" variable in your root php.ini. Default is typically 3, off is 0, and 2 typically works with Kohana. Note that this can't be changed in directory-specific php.ini files (i.e. the php.ini in Gallery won't do it).

Best of luck!

Take care,
Shad

Hi Brian,

One thing you might try is to set the permissions of the ffmpeg file to 0755. Gallery tries to do this itself for things found in the /bin directory, but perhaps it's getting blocked by your server?

Take care,
Shad

Thanks a lot for that fix. We set the zend variable in php.ini to '2' and reverted our patch in Bootstrap.php and Kohana.php and used the files that came with G3.0.5 and it worked like a charm.

The only issue we have now is that when you upload one album via server_add, the thumbnail gets created but if we select more than one album, it does not creates the thumbnails.

But we are still super happy that atleast the server_add started working again

@BrianO - re: ffmpeg, that's really strange. Gallery's autodetection isn't terribly sophisticated, so it's hard to see where it could go wrong:
- Look in a few places for a file called "ffmpeg" (among them is the gallery3/bin directory)
- See if it's executable. If not, and it's in the gallery3/bin directory, try and fix the permissions.
- Check again if it's executable. If so, report as detected.

Is the file named something besides "ffmpeg" ? Note that Unix filesystems are case-sensitive, so "FFmpeg" won't work.

Thanks,
Shad

@BrianO - if you've removed the modules, and there are no other patches you manually applied somehow, then it should be fine.

Here's a more surefire test: upload ffmpeg to the directory, ensure its permissions are set correctly, then open up a terminal window, cd into the directory, and run "./ffmpeg". You should get the standard help stuff dumped out into the terminal. If not, then there's something non-Gallery-related that's wrong...

Take care,
Shad

Just wanted to move my 5000 or so pics to a new server with Gallery 3 after having used Gallery 2 for years. But now I found out that Gallery 3 does not support links, insists on copyng every file into its file store. This is really a step back into the stone age. Particularly for larger collections it is critical that files are not copied unnecessarilly umpteen times while still being able to show them in multiple albums (e.g. a collection of pics of Joe collected over years, and separate albums of all birthday parties where Joe was just one of several friends).

Personally I really don't care whether this is done by putting links into the database record to the location of the file on the disk, or whether this is done by symbolic links. But without a way to keep only one copy on the disk in its original location and still be able for it to show in multiple albums, and a way to translate that from a Gallery 2 installation into the Gallery 3 solution, this is really a huge step back.

For now I-ve deleted Gallery 3, will continue to use Gallery 2 until I find an alternative which does provide what is needed to manage large collections.

arthur-p,
Sorry to here that you are disappointed with this version. Others seem to like it.
We understand that G3 is not for everybody and you are welcome to stay with G2. It is stable and secure.
Gallery 2 does many things for many people and this diversity has made it unhealthy. The code base is too complex and over-engineered because it was designed to fix every single thing that was wrong with Gallery 1.
We understand the not all people will be happy with G3 and are not forcing people to migrade from G2 to G3.
If G3 had all the features and complexify of G2...then we would still have G2.

Dave
____________________________________________
Blog & G2 || floridave - Gallery Team

I ran into the same situation. I think it was something leftover in the database. In any case, I resolved it by copying those modules into the 3.0.5 installation, thus making them appear on the Modules page. I deactivated them and then deleted the folder from the Modules folder. Worked for me.
Brian

You might try actually installing them, then removing them. But I am certainly no expert, so perhaps someone will be around shortly that can provide a better answer. Good luck.
Brian

Floridave --

I truly appreciate all the work you and other developers have put into both G3 and G2. And I love some of the modules you've created. But isn't it kind of naive to think that new users won't automatically opt for G3, and then discover all the things it won't do? After all, the home page of the Gallery website really *pushes* G3 as the latest and greatest. There's talk that G3 is so much faster, etc. As for not "forcing people to go to G3" well, honestly, isn't that de facto what is being done, since, from what I can tell, development work has come to a virtual halt on Gallery 2? Who wants to opt for software that is rapidly becoming obsolete and thus may become a security liability?

Even tho I did my homework and researched the differences between G2 and G3, the deciding factor was that it seemed to me G3 was going to continue development and G2 was not. But now, after I've loaded 2,000 images in my G3 installation I find out it will never support .PDF format (that was NOT something mentioned in the feature comparisons, by the way, and probably would have been a deal breaker for me if it had been prominently pointed out). Then we get the 3_0_5 upgrade and reading this forum I find out I have to get deep into techy tweaks to insure a decent upgrade -- or try to get my hosting company to change basic PHP settings and 'tune down' Zend Guarder?

C'mon, this is not something the average user can do -- and I'm not an average user -- I'm an coding techy with 20 years experience, but it is still not something I *want* to have to do just to upgrade my gallery installation. So now I have to jump through all these hoops to keep my software current? Sheesh... I could have just gone with Gallery 2 if I wanted to find myself in that situation.

Finally, I simply cannot understand why any development team would opt to use a framework that is incompatible with something as common and universal as the Zend Guarder Loader. I mean, why go looking for trouble?

Right now I can't help thinking I made a very bad decision to go with G3 -- and that the Gallery Team pushed me towards making that decision.

Ugh, I went looking for an easy way to install these modules (so that I could then uninstall them) and what I get is pure source trees in github. Not precisely easy.
So I did it the "hard" way - six MySQL statements. Okay, the warning is gone.

But I'm still a bit bothered that this apparent bit of corruption slipped through the upgrading process. Those modules simply aren't there. They weren't there in my prior 3.0.4 installation either.

The thing that drove me up to G2 to G3 was database corruption which ultimately caused me to lose a LOT of work. I had backups, which were not restorable because I didn't have the precise version of Gallery2 code which made the backups, and G2 backups were not restorable to anything but the very same version of code (and even modules in some cases, I think).
If G3 is going to starting showing database rot, I'll be very scared
(I do much better backups now, but, still...)

Shad,

Thanks for the info, you've taken a load off my mind. You see, I actually am not yet "having trouble". I learned many moons ago to wait at least a few weeks on any upgrade until others have taken a bullet... um, I mean, until I have read feedback on what others more adventurous than I have experienced

So, I'm more than willing to wait to upgrade for ver. 3.0.6 if it is coming soon. And it's great news that you may soon have a module to make adding .PDF files to the gallery easier -- I was more disappointed by that lack than anything else (and yes, I did read about the workarounds, but none of them sounded very satisfactory). I can understand and agree with the basic idea of striving to keep the core of G3 a lean, mean, image machine. G2 did grow into quite a handful. But for such a universal file format as .PDF (which I really don't like but sadly am stuck with) there really needs to be a module available for those who want to take the hit to be able to post that ungainly resource-hogging format.

Overall, I like G3 very much. I spent a month evaluating every major gallery software package out there and in the end felt G3 was the way to go -- but after I loaded 2,000 images and only then discovered the .PDF issue, I was just getting jittery, I guess.

@J R S - the PDF module is out! http://codex.galleryproject.org/Gallery3:Modules:pdf

Take care,
Shad

Gallery 3.0.5 is broken for sites that run on non-standard (ie, not http/80 https/443) ports. Redirects to the reauthenticate page, url() attributes inside the 'combined' CSS files strips the port number, and probably other things as well. This results in browsers spinning for a very long time on each page load until they timeout trying to contact the server over port 80.

I consider this a major regression, so much so that I'll have to revert back to 3.0.4 to make my site functional again.

It doesn't, actually. I saw that commit between 3.0.4 and 3.0.5, and would have assumed that would have fixed it. I also tried creating local.php and setting site_domain and site_protocol in $config[] to no avail.

I'm still seeing combined CSS files with things like this in them:

.g-password-strength0 {
  background: url('http://gallery.phalengard.com/modules/user/css/../images/progressImg1.png') no-repeat 0 0;
  width: 138px;
  height: 7px;
}

And the logout link is still being generated as:

<a id='g-logout-link'     class="g-menu-link "
     href="/logout?csrf=aab26336568f092e4be7d4d39f1b7bf0&amp;continue_url=http%3A%2F%2Fgallery.phalengard.com%2Fandy"
     title="Logout">
    Logout  </a>

Yessir, I commented out the site_* options I had set in local.php. I just moved it out of the way to be sure.

Now I'm getting an even more odd behavior, using your most recent code. Page source is showing the breadcrumb navigation links as being relative, but clicking them takes me to a url with the port number stripped.

See for yourself: http://gallery.phalengard.com:8000/andy/

Nope.

I ran:

find . -name '*.js' -exec touch {} \;
find . -name '*.css' -exec touch {} \;

Time/date on all .css and .js files have been modified. Still not working.

I have a problem with this upgrade. I just upgraded from 3.0.4 --> 3.0.5 with no errors, but now the index page is completely empty of albums. I have an Album Tree module installed which still lists all the albums in the sidebar. I can click on an album and the album opens and looks fine, but on the index page there is nothing, it's empty of albums. Any ideas? I had to revert back to 3.0.4 to keep it working properly.

Yes, I did that at one point I disabled all modules, but it still didn't display albums on the index page.

Looks like it's ok now. I think it was the New Item module that was making it barf. Looks good now!

Comments are now locked for this topic.