Broken Gallery3 (probably PHP 8)

[James Strickland]

Greetings All, 

I have neglected my gallery for over a year... probably 2+. Seems my webhost upgraded to PHP 8. My gallery3 is showing an HTTP ERROR 500. 

I don't recall what version of Gallery3 I am on, and don't recall how to check. 

My PHP version is: 

PHP Version 8.1.25
System
Linux durkee 4.14.117-grsec-grsec+ #1 SMP Fri May 10 17:15:47 PDT 2019 x86_64
Build Date
Nov 13 2023 22:41:53

Can someone please point me in the right direction to get things back up and running? 
https://strickstuff.com/photo

I thought I had done this before years ago, but I could not find the thread in the search. 

Hope everyone had a good Turkey day! :) 

Thanks,
James

[James Strickland]

I tried following the directions for the upgrade, but to no avail. I still get the HTTP ERROR 500... 

i'm still searching and reading. 

[James Strickland]

I rolled my PHP version from 8.1 to 8.0 and it seemed to have fixed everything. 
now I can work on upgrading from 3.1.3.

-James

[J.R.]

James,

I'm sorry to have to tell you that it might now be very difficult for you to get your old gallery back up and running, since you do not know which version you were using before your server went to PHP 8. There are a couple of options I will talk about below, but honestly it would be easier for you to get an account with one of the online gallery services like www.flickr.com, www.pinterest.com, www.google.com/photos or even www.facebook.com. You can upload the pictures that were in your old gallery into one of these online photo galleries. The benefits of an online photo gallery is that, going forward, you will not have to worry about any PHP updates or any other issues affecting your pictures in the future.

If you don't want to do that:

Get your webhost's tech people on the phone and see if they can temporarily set your web hosting account back to using any version of PHP 7. If they will do this, then you can *try* to upgrade the old gallery installation to the latest version of Gallery (which will work under PHP 8). If the upgrade works, then you would be able to tell your webhost techs to set your hosting account back to PHP 8 and things will work again. For now. But who knows about the future? PHP is changing rapidly to meet the threat of global hacking.

If the webhost will not do that, then you need to get access to the pictures you had in your old gallery. Do you have a copies of the pictures in your old gallery available on your computer? If not then -- if you have administrator cpanel access to your webhosting server account -- you can download the pictures you had in your old gallery to your computer. Here's how: Once you have got into your webhost's cpanel navigate to the folder where you have the old gallery installed. Usually this will be a folder named "gallery". Go into that folder and look for a folder called "var" -- inside the var folder you will find all of the original pictures you installed in your old gallery and can download them to your computer for future use. If you can't seem to find the folder where you had gallery installed all you can do is start searching every folder in your hosting account to find the one which has the "var" folder inside it so you can get hold of your pictures.

You need to have your pictures available on your local computer whether you want to go with an online photo gallery like Flickr.com  or if you want to try going through the long, arduous process to try to "save" your old gallery (with no guarantee you will be successful). So, confirm you have your pictures.

-- J.R.

On Friday, November 24, 2023 at 7:29:49 PM UTC-5 James Strickland wrote:

Greetings All, 

I have neglected my gallery for over a year... probably 2+. Seems my webhost upgraded to PHP 8. My gallery3 is showing an HTTP ERROR 500. 

I don't recall what version of Gallery3 I am on, and don't recall how to check. 

My PHP version is: 

PHP Version 8.1.25
System
Linux durkee 4.14.117-grsec-grsec+ #1 SMP Fri May 10 17:15:47 PDT 2019 x86_64
Build Date
Nov 13 2023 22:41:53

Can someone please point me in the right direction to get things back up and running? 
https://strickstuff.com/photo

I thought I had done this before years ago, but I could not find the thread in the search. 

Hope everyone had a good Turkey day! :) 

Thanks,
James

--
WHEN USING AN EMAIL PROGRAM to reply to this message, click REPLY TO LIST or REPLY TO ALL so your reply goes out to everyone in the group. If you click REPLY or REPLY TO SENDER Google will *only* send your reply to the original author (not recommended).
 
To post a NEW MESSAGE to the group, send an new email to:
gallery...@googlegroups.com
 
To view or sign in to this group on the web, use this URL:
https://groups.google.com/forum/#!forum/gallery-3-users
---
You received this message because you are subscribed to the Google Groups "Gallery 3 Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gallery-3-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/89d434c4-f154-4e03-b160-d8bdd05e5ef3n%40googlegroups.com.

[J.R.]

James,

I sent my first reply before I saw this one. Good that you are now running Gallery under PHP 8.1 -- first thing to do is sign in to your gallery as admin and look at the dashboard page. Somewhere (usually the upper right of the page) it should say which version Gallery you are running. Let us know.

-- J.R.

--
WHEN USING AN EMAIL PROGRAM to reply to this message, click REPLY TO LIST or REPLY TO ALL so your reply goes out to everyone in the group. If you click REPLY or REPLY TO SENDER Google will *only* send your reply to the original author (not recommended).
 
To post a NEW MESSAGE to the group, send an new email to:
gallery...@googlegroups.com
 
To view or sign in to this group on the web, use this URL:
https://groups.google.com/forum/#!forum/gallery-3-users
---
You received this message because you are subscribed to the Google Groups "Gallery 3 Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gallery-3-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/820d803b-40ef-4b00-9678-31093f629042n%40googlegroups.com.

[James Strickland]

I ended up just renaming the folder and reinstalling the lastest gallery3. What is the most efficient way to import 8200 photos. 

Can I just move /var/albums/* to the current var folder & import with server add. I moved the contents of /var/albums to /photo/uploads/ and used serveradd, but it seemed to hang up. Maybe I should do 1 sub folder at a time, but that may take a while. 

Thoughts?

-James

[J.R.]

James,

Every time I've tried to manually move the /var folder or any of its sub-folders I have run into trouble. Looking at the internal structure of the Gallery database I see it is made up of 25 separate tables. I've found that some of those tables contain "cross links" to information/locations the /var folder, which break when a /var folder is moved. There may be another, but the only approach that was successful for me was to start with a fresh install of Gallery 3, testing it to make sure everything was working, then delete the few test photos I had uploaded (not manually, but using the built-in "delete photo" function). This keeps the different tables and fields in the database "in sync" with no pictures installed when the test is done. Then I used server add to import the photos from the old /var into the new (empty) one... but one sub-folder at a time, not trying do too many at once, too fast as this will tend to cause a lock up (apparently a PHP processing/buffer overload issue). It's a bit tedious with thousands of photos but still better than doing it one photo at a time.

Bottom line: the photo storage and database-retrieval system in Gallery cannot be bypassed manually without causing database problems. Server add was specifically designed to "automate" the usual manual "add photo" process and so makes all the correct entries in the different database tables as it does the import.

Not sure what you were trying to do where you said: "I moved the contents of /var/albums to /photo/uploads/ and used serveradd, but it seemed to hang up". Server add will only work when it is trying to import photos into an existing Gallery installation /var folder. If you want just to create a copy of the /var folder for backup purposes, then simply using the cpanel to do that should work, but again, trying to do it in "one gulp" seems to be problematic in your system. I would just create the empty /photo/uploads/ folder on your server, the open the /var folder and select each sub-folder one at a time and copy each folder to into the /photo/uploads/ folder one at a time.

-- J.R.

To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/9cb76d07-65ed-4b92-b2bf-59a4c03fdaa7n%40googlegroups.com.

[James Strickland]

I created a folder in the root dir called upload, and I added that path to 'server add.'
then, using server add to entire contents of the upload folder it seemed it did not complete the job. 

See the aftermath screenshot & the directory structure of my uploads folder. The directories are in the albums and there are subdirs (sub albums) within some of the folders.

This is after a fresh install, recreated database and all.

Thanks,
James

[Who IsThis]

I had a similar issue.  Hosting provider took out all versions of PHP  except 8.1 and above.  I had 3.1.3 installed (simply because I recorded it; not that the version appears to be hidden in the code base anywhere) and it did not work under 8.1.  I checked the 3.1.5 release against the installed 3.1.3 and found few changes. So simply created a new folder  with 3.1.5 and movedvar/ over to that new area. And I got similar to the above.  The ones not appearing seemed haphazard.  Did not seem to be related to permissions or any other settings.  I changed the graphic processor from ImageMacick to GD and back.  No effect.  I rebuilt images (maintenance menu or from the theme) and that did not seem to affect things.

Looking further, I notice that all albums that do not appear have an .htaccess file in them. It seems to have been created about the time of the rebuild.  So odd in that this problem was before the first rebuild.  The content of that file in every case is:
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule (.*) /gallery/index.php?kohana_uri=/file_proxy/$1 [L]
</IfModule>
<IfModule !mod_rewrite.c>
  Order Deny,Allow
  Deny from All
</IfModule>

I removed one of the .htaccess files and that folder image thumbnail appeared.  As well as all below it. Removed them all in the resizes/, thumbs/ and albums/ folders (only) and everything is back to normal. (note: there are different and important ones in tmp/, uploads/ and logs/)
find var -name .htaccess -print        # To see where they exist (not, some are there that need to remain)
find var/{albums,resizes,thumbs} -name .htaccess -exec mv {} {}-old \;      # to rename the "bad" ones to .htacess-old and make them ineffective. 
# Note: you could use "rm {} \;" for the exec command if you felt comfortable with doing that (deletes instead of renaming the files)

The files do not appear in my backups. Not sure why or when they were added.  Suspect during one of the "rebuild images".  Most are dated after the last of two rebuilds I forced.  Maybe a rebuild was triggered when I first started the code after the overlay.  In any case, it fixes the issue. 

 Now to figure out why HTML code is no longer being processed in album descriptions. But more importantly, likely need to put more focus on migrating away as JR recommends :) Over 28 k entries and every migration script I have found does not take along the description / title fields added to most images. Key being naming people in the photo that most I am not sure about. Others being dates set. Not the EXIF date of when it was scanned. Biggest issue also is I had made mods to allow PDFs, MPG TXT and similar file entries in the older gallery.  Still looking for a manager that allows more than just JPGs, PNGs, etc.

[Adrian London]

 I have this in an ".htaccess" only in the root of my /var/{albums, resizes, thumbs} directories.  The sub-directories don't have that file, and I have rebuilt thumbs and resizes more than once.

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule (.*) /gallery/?kohana_uri=/file_proxy/$1 [L]

</IfModule>
<IfModule !mod_rewrite.c>
  Order Deny,Allow
  Deny from All
</IfModule>

As for the album descriptions - do your photo descriptions work?  Do you have the "purifier" module installed?  I believe that's needed to understand html codes.

[RandyH]

I did not have them at the top level of each folder when I found them buried down lower.  Adding them there does not seem to affect the gallery usage as it did when lower; that I can tell.  The file does turn off module access except for the rewrite module at that level. I believe such files are usually restricting direct access to the folders when given in a URL as a path. When trying to do something like http://yourdomain.com/gallery/var/albums/.... -- this would be blocked. Not clear to me why the behavior when plaved farther down versus at the root makes a difference.

They appeared in the same subfolders in all three folders and in only 12 of the hundreds of folders.  But it knocked out a lot more folders and files. Because it did not allow access to the images at or below that point. Even though it did display a placeholder for all images and folders even down multiple levels.

Was simply trying to offer something to look out for. My 3.1.3 installation was fine up until this week and the forced change from 7.2 to 8.1. When overlaying 3.1.5 code on 3.1.3 and revisiting the site, the issue cropped up. So thought what I found would help explain the original posters last reported issue as my behavior was similar but fixed.

HTML does not work in an album description nor photo description anymore.  I do not have the purifier module nor does it appear I ever have.  The HTML codes in descriptions had been working flawlessly up until now (so was fine in PHP 7.2 and Gallery 3.1.3 without purifier).  But I will look for that module to see what it does and if it helps.

[RandyH]

Scratch that. If I add them at the top level of each folder, I disable some of the lower folders again.  I had done it in my backup area and not the working area. So I cannot have var/{albums,thumbs,resizes}/.htaccess without reintroducing the problem.  Oddly, not in all places. Maybe a cache issue?

[Adrian London]

If there’s anything you want me to check, let me know.

I have those “.htaccess” files in the roots of /var/albums etc., running PHP 8.3, and everything’s working.  If you haven’t already, check the logs to see if it’s maybe an issue with Gallery checking user access to those albums.

If things go screwy, I restart my browser (Firefox - configured to delete all caches/cookies on restart) and then I empty the “caches" table in the G3 database.  I’m not sure that does much apart from make me feel better, but it’s worth it for that :)

[J.R.]

Adrian,

Yes... one thing I decided even back in Gallery 3.0.9 was that there should only be that one ".htaccess file" in the /var directory. It provides "blanket permission coverage" for all the  sub/directories image albums. So like you, I removed any other .htaccess files I found floating around in my Gallery installation (and there were quite a few scattered here and there) and since it has run like a Swiss watch, even with the move to php 8.1 and version 3.1.5.

-- J.R.

--
WHEN USING AN EMAIL PROGRAM to reply to this message, click REPLY TO LIST or REPLY TO ALL so your reply goes out to everyone in the group. If you click REPLY or REPLY TO SENDER Google will *only* send your reply to the original author (not recommended).
 
To post a NEW MESSAGE to the group, send an new email to:
gallery...@googlegroups.com
 
To view or sign in to this group on the web, use this URL:
https://groups.google.com/forum/#!forum/gallery-3-users
---
You received this message because you are subscribed to the Google Groups "Gallery 3 Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gallery-3-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/ddaa68b5-1ea7-4d21-bed7-fc8fc0b55e67n%40googlegroups.com.

[RandyH]

FYI, the .htaccess files outside the var folder have very different purpose and content. Here are the ones that exist today in my release (after having done the previous removal):
  $  find . -name .htaccess -print
  ./var/logs/.htaccess
  ./var/tmp/.htaccess
  ./var/uploads/.htaccess
  ./bin/.htaccess
  ./vendor/.htaccess
  ./.htaccess
Attached is the original listing of .htaccess files as taken from my backup before upgrading to 3.1.5.  So they were there before the upgrade from 3.1.3 but did not seem to affect things then.

Here are the .htaccess files in the 3.1.5 and 3.1.3 release zips themselves. Of course, more could be created by the PHP scripts. Obviously var/ folder entries are because that folder is not in the release itself:
  $ find . -name .htaccess -print
  ./.htaccess
  ./bin/.htaccess
  ./vendor/.htaccess

The .htaccess files in the var area outside the ones I removed from albums, resizes and thumbs contain the following:
  DirectoryIndex .htaccess
  SetHandler Gallery_Security_Do_Not_Remove
  Options None
  <IfModule mod_rewrite.c>
  RewriteEngine off
  </IfModule>
  Order allow,deny
  Deny from all

Which is very different from the ones I removed as given in my original post.

I can confirm that the (HTML) purifier module in the 3.0 github folder just breaks the system as it exists today.

I cannot see any changes in the code made by Brad that would break the html use since the 3.0 release.  Am guessing it is a PHP 8 thing; likely done for security reasons. Maybe requiring a feature be disabled or turned on. If i get a chance, I will look into it more after creating a system with PHP 7.2 like I had earlier.