Bug #10648

Error 'The "i18n" object does not exist in the current context'

Added by Nick Wilkinson over 3 years ago. Updated about 1 month ago.

Status:VerifiedStart date:12/07/2016
Priority:HighDue date:
Assignee:-% Done:

0%

Category:Installation
Target version:-
Google Code Legacy ID: Tested version:2.3
Sponsored:No Requires documentation:

Description

During AtoM install, if the admin restarts the server after installing PHP, but before running the web based AtoM setup, when AtoM setup is run it will fail after completing the "Configuring Search" page with the error 'The "i18n" object does not exist in the current context'. This affects 16.04 installs but I haven't tested anywhere else - I suspect it affects any OS where ticket 8887 is deployed.

This has been reported in the forums:
https://groups.google.com/forum/#!topic/ica-atom-users/m_JXLWB6jt0
https://groups.google.com/forum/#!topic/ica-atom-users/Guab2J2rXtQ

This appears to be triggered here:
https://github.com/artefactual/atom/blob/28675e4124705502ef3ff6bd33b4dfda69215cf1/plugins/sfInstallPlugin/lib/sfInstall.class.php#L459
...and is related to ticket #8887

The first message in this forum post contains the full trace for the error:
https://groups.google.com/forum/#!topic/ica-atom-users/m_JXLWB6jt0

It was found that if a user encounters this error, they can work around by:
- restart fpm (sudo systemctl restart php7.0-fpm <-- in the case of Ubuntu 16.04)
- restart the install (dump and recreate db, delete and set up the atom application folder again)
- the install will now proceed cleanly.

If the user just tries again without restarting fpm, they will repeatedly run into the same error during install.

A coded fix has not been implemented yet and this is not directly related to Ubuntu 16.04.

settings-yml-wiped-to-0b-during-web-installer-run.png (80.7 KB) Dan Gillean, 03/27/2020 11:31 AM


Related issues

Related to Access to Memory (AtoM) - Feature #8887: Add individual user-friendly access statements per PREMIS... Verified 08/28/2015
Related to Access to Memory (AtoM) - Bug #13051: AtoM Web Installer 504 timeout issue Verified 05/23/2019

History

#1 Updated by Nick Wilkinson over 3 years ago

  • Description updated (diff)

#2 Updated by Nick Wilkinson over 3 years ago

  • Related to Feature #8887: Add individual user-friendly access statements per PREMIS Rights Basis added

#3 Updated by Nick Wilkinson over 3 years ago

  • Assignee set to Steve Breker

#4 Updated by Dan Gillean over 3 years ago

  • Category set to Installation
  • Target version set to Release 2.4.0
  • Tested version 2.3 added

#5 Updated by Steve Breker over 3 years ago

Clear PHP opcode cache. This was added to correct issue where occasionally
during installation, the cache will contain the vendor skeleton .yml
files, which override the AtoM config files that should be written to the cache
folder during install. This prevents the i18n and Qubit helpers being
loaded (from apps/qubit/config/settings.yml) triggering the i18n errors
during the installation process.

https://github.com/artefactual/atom/pull/509

#6 Updated by Steve Breker over 3 years ago

JGC code reviewed and gave thumbs up.

https://github.com/artefactual/atom/pull/509

#7 Updated by Steve Breker over 3 years ago

  • Status changed from New to QA/Review
  • Assignee changed from Steve Breker to Nick Wilkinson

This will be difficult to test as the issue does not trigger in every case.

Testing should at least comprise of checking to ensure that the install process proceeds as expected.

#8 Updated by Nick Wilkinson over 3 years ago

  • Assignee changed from Nick Wilkinson to Dan Gillean

#9 Updated by Nick Wilkinson over 3 years ago

  • Assignee changed from Dan Gillean to Santiago Collazo

Hi Santi, can you attempt a clean install with this fix on a VM running Ubuntu 16.04?

#10 Updated by Steve Breker over 3 years ago

Let me know how this test goes. Once complete, I would like to pick this for stable/2.3.x.

#11 Updated by Jesús García Crespo over 3 years ago

Let's do this!

#12 Updated by Santiago Collazo over 3 years ago

  • Assignee changed from Santiago Collazo to Steve Breker

Tested with stable/2.3.x with cherry picked 18ca74cd3cbbcaeff673f8b0cc9556b4553 , and everything worked fine.

#13 Updated by Steve Breker over 3 years ago

I have completed picking this change to stable/2.3.x.

#14 Updated by Steve Breker over 3 years ago

  • Assignee changed from Steve Breker to Nick Wilkinson

#15 Updated by Nick Wilkinson over 3 years ago

  • Assignee changed from Nick Wilkinson to Dan Gillean

#16 Updated by Dan Gillean about 3 years ago

  • Status changed from QA/Review to Verified

#17 Updated by Dan Gillean 4 months ago

Note for future troubleshooting: this has come up again for a user in the forum upgrading from 2.5.2 to 2.5.3. The suggestions on this ticket did not resolve the issue. See the thread for more details and eventual (we hope) resolution:

#18 Updated by Dan Gillean 4 months ago

Going to re-open this issue as it seems to be recurring.

In terms of resolving it, see especially the last user post in this thread: https://groups.google.com/d/msg/ica-atom-users/_fXHZuID6Vg/Gb2xqQ7rBgAJ

Before running the web installer it [the settings.yml file] has the same configuration at the tmpl. By the time it reaches the Search settings page, the settings.yml file becomes a zero-length file. Somewhere in between starting the web installer and Search settings page, the file is being wiped!!!

I replaced the settings.yml file using the template in the same directory and checked that the correct permissions were applied. Then I continued from the point above. The web installer completed without fault and the upgrade appears to be complete. I have ported the old data across and I'm done.

See the attached CLI image for further context.

See also: internal issue #11572

#19 Updated by Dan Gillean 4 months ago

  • Related to Bug #13051: AtoM Web Installer 504 timeout issue added

#21 Updated by José Raddaoui Marín about 1 month ago

  • Status changed from New to QA/Review
  • Assignee set to Dan Gillean

Tested in Ubuntu 18.04 following the install docs, with 2.5.3 and 2.5.4. Tried with various browsers at the same time, with different cache engines, with existing config files and clean AtoM folders, with two installations on the same machine and restarting processes and clearing cache in the process. In any case, I couldn't make the settings.yml file to lose its contents.

I can only hope the fixes from #13051 improve the situation in 2.5.4 and later versions.

#22 Updated by Dan Gillean about 1 month ago

  • Status changed from QA/Review to Verified
  • Assignee deleted (Dan Gillean)

Okay, thanks for doing this. If you can't reproduce it, then let's close this issue and hope that #13051 has helped address it. If it reoccurs, we'll open a new ticket.

Also available in: Atom PDF