One Album Page Blank and Rearrange Does Not Work

Transfers by "next" or "previous" to the 2nd of 3 pages of sub-albums within an album return a completely blank page.

Attempts to "Rearrange" the subject album also return a completely blank page; although "Reorder" does work normally.

The following information is from the host server log with explanations from me:
ERROR WHEN TRYING TO REARRANGE ITEMS IN ALBUM
[09-Oct-2009 13:28:08] PHP Warning: Invalid argument supplied for foreach() in /home3/managek2/public_html/gallery/modules/core/classes/GalleryStorage/GalleryStorageExtras.class on line 134 [09-Oct-2009 13:28:08] PHP Fatal error: Call to a member function getId() on a non-object in /home3/managek2/public_html/gallery/modules/core/classes/helpers/GalleryEntityHelper_simple.class on line 79

ERROR WHEN TRYING TO ACCESS PAGE (OF ALBUMS) IN SAME ALBUM RETURNING COMPLETELY BLANK PAGE
[09-Oct-2009 13:29:23] PHP Warning: Invalid argument supplied for foreach() in /home3/managek2/public_html/gallery/modules/core/classes/GalleryStorage/GalleryStorageExtras.class on line 134 [09-Oct-2009 13:29:23] PHP Fatal error: Call to a member function getId() on a non-object in /home3/managek2/public_html/gallery/modules/core/classes/helpers/GalleryEntityHelper_simple.class on line 79

My gallery is www.kenspicture.info. The album in question is private, but I can set up a temporary login to view it.

I have moved my gallery to a new web host (BlueHost.com)this past week, and have had many problems getting it up and running. One of the last things I have done is increase the memory through php.ini to 100M. Generally, it seems to be in good shape; most of the other problems I have found I can handle. The gallery contains almost 11,000 photos and a few videos with the likelihood I will add 3000 to 5000 more.

The following is the system information for my gallery:

Gallery URL = http://www.manageknowledge.us/gallery/main.php
Gallery version = 2.3 core 1.3.0
API = Core 7.54, Module 3.9, Theme 2.6, Embed 1.5
PHP version = 5.2.9 cgi-fcgi
Webserver = Apache/2.2.13 (Unix) mod_ssl/2.2.13 OpenSSL/0.9.8k DAV/2 mod_auth_passthrough/2.1 FrontPage/5.0.2.2635
Database = mysqli 5.0.81-community-log, lock.system=database
Toolkits = Thumbnail, ArchiveUpload, NetPBM, Gd, Exif
Acceleration = none/0, none/900
Operating system = Linux box660.bluehost.com 2.6.28-10.7.intel.IGB.BHsmp #1 SMP Thu Aug 13 21:52:24 MDT 2009 x86_64
Default theme = matrix
gettext = enabled
Locale = en_US
Browser = Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Rows in GalleryAccessMap table = 151
Rows in GalleryAccessSubscriberMap table = 10499
Rows in GalleryUser table = 13
Rows in GalleryItem table = 10496
Rows in GalleryAlbumItem table = 349
Rows in GalleryCacheMap table = 0

Before making the change you suggested -- which I did make -- I had done a workaround of the problem.

My original plan was to create a temporary new album and move the 26 sub-albums to it from the album with the problem. The new album still got a blank page for its page 2. In fiddling with things I noticed a one-item album that contained only an AVI file and suspected it was the problem, since it would probably always be on page 2 regardless of how I might switch things around. The first thing I did was move all the sub-albums but the one I suspected back to the original source album: BAD IDEA. The target was now the only sub-album in a one-level-higher album that contained 9 sub-albums, so the only page of the next higher album would only produce a blank page now. That made navigation a potential impossibility.

As the next step in my saga I created an album with 9 empty sub-albums. I was able to get to the original sending album (which now contained its original 25 sub-albums) by doing a Broken Image Analysis which gave me a pointer to one photo in the original. I used that to temporarily move 9 albums into the temporary target. I used a Broken Image analysis again to get a pointer to a photo in the target. Once there I moved the offending album to the album with 9 empty sub-albums. Since it was the 10th album it went to page 2 that did not appear, but page one did appear. It allowed me to go to the top level album, select the album with the 9 empties plus the one BAD ONE and delete the whole album. After that I was home clear, I could move things back to where I wanted them, get rid of the temporary target that didn't work and go on with processing.

To emphasize, I had no problems with this large gallery until I moved to a new web host. I had followed the guidelines for moving to a new host, but I guess there are always unexpected anomalies that occur because of settings inconsistencies with the new host. Also, I found the suggested processes to move to a new host to be sloppy and to produce uncertain results at best.

I know nothing about php and mySQL programming, but I'm setting a goal for myself to eliminate that hole in my knowledge.

Thanks for the responses.

--Ken

Is there something about the problem I documented that jumps out at you as caused by a restriction of the new host? The former host used a vDeck server; the new one uses a cDeck server. I liked the old one better because I was used to it. The new host accommodated all my requests for changes with the exception they would not change file permissions to 777 -- I don't have my own IP. I found a way around having to make that change.

I don't know what caused each and every one of my problems, but I do know the conversion process caused some of them. When the transfer did not result in a functioning system, it was necessary to transfer files more than once. I used FileZilla that I like and trust to transfer the data files, yet I discovered the transfer was not always what I expected. For example if it is transferring directory A with a sub-directory B to replace the same structure on the target host, the result on the target was sometimes not A with a sub-directory B, but instead A with a sub-direcory B that then also had its own sub-directory B.

Sloppy was a poor choice of words and an incorrect choice made in haste as I wrote. The instructions describe a reasonable process. They are quite succinct, appear to presume a somewhat level-headed, technically capable user, but yet do not describe questions that are likely to arise (such as whether to use upgrade instead of install, etc.) I suspect they would increase markedly in size were they to cover all that might occur during the process and I wouldn't want to attempt to make a draft of such.