Instance Upgrade

[kclearylcmc]

Hello again, Gibbon community,

I have recently completed a migration of our Gibbon instance to a new VPS. I needed to upgrade to Ubuntu 22.04 (from 20.04) and Php 8 (from 7.4) and my efforts to manage that in place were creating irreconcilable dependency issues. The good news is that I managed most of the migration without any trouble. There are just two issues I cannot seem to resolve on my own.

The first concerns student applications (using form builder) that have been accepted. When I navigate to Admissions–>Manage Applications and select the pencil icon to edit an accepted application, I get this message.

It only seems to happen for accepted applications (rejected ones can be viewed without complication) and it does not happen on the old installation. I’ve checked folder permissions thoroughly and don’t see any reason for the problem. Any suggestion is appreciated.

The second issue is smaller and concerns languages (System Admin–>Manage Languages). As near as I can tell, I have all my US English settings the same as on my previous installation. The new installation, though, still uses Timetable instead of Schedule, and Form Groups/Year Groups instead of Grade Level/Graduating Class. I had grown to prefer those translation terms and cannot figure out how to return to them. (I’m sure I’m missing some installation step, but I’m not seeing it right now.)

Thank you as always!
Kevin

[tiekubd]

Hello @kclearylcmc

For your second issue, I think you’ll find an explanation here:

v25 User status options.

Oh, I have figured it out! It’s related to the English US locale. It appears that a well-meaning translator had translated every instance of the word Left into the word Graduated, without realizing the nuanced use-cases for the Left status. I have corrected this in PoEditor and GitHub. The best way to ensure this is updated for existing installs is to delete your en_US folder from the i18n directory, then use System Admin > Manage Languages to re-install it.

Regards

[kclearylcmc]

Thank you so much for this post, @tiekubd! I remember doing something like this in the past to get a language change to take, but I had forgotten about it.

Unfortunately, this specific suggestion did not solve my problem. It gave me another idea, though. I pulled the gibbon.mo file (from the en_US folder) from my old server and put it on the new server. That was the fix! Somehow, the language file I had on the old server was correct (or at least familiar) and the one that’s getting pulled by Gibbon is not.

I appreciate your help on this!

Kevin

[kclearylcmc]

I just looked at your entire thread, @tiekubd. I didn’t realize that the en_US changed to maintain consistency.

Either way, this was an informative and helpful post. Thanks again!
Kevin

[kclearylcmc]

Just a heads up that my first issue in this thread (accepted student applications being inaccessible) has been resolved after my upgrade to Gibbon 26. I assume it was some kind of database issue, but either way it is good news!

Kevin

[kclearylcmc]

Hello again, everyone!

I just undertook a server migration and seem to have everything working as expected on my new gibbon installation.

There is one place, however, where I am consistently running into the “Oh No! Something has gone wrong: the Gibbons have escaped” error message. When I go to System Admin and run a System Check, this message pops up every time. I have tried chmod and chown changes in folders, replacing the systemCheck.php file in System Admin modules, and every other adjustment I an imagine, but the message always pops up and I cannot run the system check.

One other note–the original system I migrated was on Gibbon v26. Once I moved it, I upgraded to v27. Again, this is the only thing I have found that is failing at this point.

Any thoughts or suggestions are deeply appreciated as always!
Kevin

[tiekubd]

Hi @kclearylcmc

Do you have access to the php error logs? That would be the place to start.

Tieku

[kclearylcmc]

Thanks for the reminder, Tieku–I forget how much information I can pull from error logs! Here is what I found that seems to refer to this error.

[date removed] [php:notice] [pid removed] [client removed] Uncaught Exception: UnexpectedValueException - RecursiveDirectoryIterator::__construct(/var/www/[personal directory]/uploads/snapshots): Failed to open directory: Permission denied in /var/www/[personal directory]/modules/System Admin/systemCheck.php on line 59, referer: https://[personal directory]/index.php?q=/modules/System%20Admin/update.php

I also looked at systemCheck.php, but I don’t know php syntax well enough to determine if anything is off. (The code is identical to that on the old server, where this works fine.) Here’s that entire sequence in case it helps.

// File Check
$fileCount = 0;
$publicWriteCount = 0;
[Line 59] foreach (new RecursiveIteratorIterator(new RecursiveDirectoryIterator($session->get(“absolutePath”))) as $filename)
{
if (pathinfo($filename, PATHINFO_EXTENSION) != ‘php’) continue;
if (strpos(pathinfo($filename, PATHINFO_DIRNAME), ‘/uploads’) !== false) continue;
if (fileperms($filename) & 0x0002) $publicWriteCount++;
$fileCount++;
}

Thoughts or feedback are welcome!
Kevin

[sandra]

Hi @kclearylcmc Sorry for the wait for a response it’s been a busy start of the school year, did you find a solution to this? “Failed to open directory: Permission denied” sounds like a file permission error, either on the directory itself or perhaps the parent directory. Be sure that the user your server is running under (often www-data for Apache servers) has access via user or group permissions. Hope this helps!