Support

Site Restoration

#37788 Error — Cannot use object of type AModel as array

Posted in ‘Site restoration’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

PHP version
8.0.23
CMS Type
Joomla!
CMS Version
4.23
Backup Tool Version
9.3.0
Kickstart version
n/a

Latest post by nicholas on Tuesday, 04 October 2022 00:32 CDT

gdsd

Hi,

when trying to restore site, the script says:

-----

Akeeba Backup Site Restoration Script v.9.3.0
Application Error

Please submit the following error message and trace in its entirety when requesting support
Error — Cannot use object of type AModel as array

/homepages/htdocs/strawberrytour/installation/angie/views/main/view.raw.php::L56

#0 /homepages/htdocs/strawberrytour/installation/framework/view/view.php(530): AngieViewMain->onBeforeMain()
#1 /homepages/htdocs/strawberrytour/installation/framework/controller/controller.php(548): AView->display()
#2 /homepages/htdocs/strawberrytour/installation/framework/controller/controller.php(553): AController->display()
#3 /homepages/htdocs/strawberrytour/installation/framework/controller/controller.php(510): AController->main()
#4 /homepages/htdocs/strawberrytour/installation/framework/dispatcher/dispatcher.php(263): AController->execute('main')
#5 /homepages/htdocs/strawberrytour/installation/framework/application/application.php(176): ADispatcher->dispatch()
#6 /homepages/htdocs/strawberrytour/installation/index.php(129): AApplication->dispatch()
#7 /homepages/htdocs/strawberrytour/installation/index.php(244): mainLoop()
#8 {main}

-----

I can click next but after I finalize the process, the website is now completely gone. Error 404.

 

 

gdsd

After restoring original htaccess the website works again, however the script error should still be dealt with.

nicholas
Akeeba Staff
Manager

I cannot reproduce this issue. Moreover, the code in question has been there, unchanged, since February 2016.

The only way your issue can be reproduced is if I delete the files installation/angie/models/main.php and installation/platform/models/joomlamain.php. These files are included in the backup archives taken with Akeeba Backup, there is nothing to fix on our side. It looks like something went wrong when extracting the backup archive. It was partially extracted, hence the error.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

gdsd

"something went wrong" ... Yes, but what?

If it was only "partially extracted", then why does it even let me get to this step? Does the restore function not work with incremental backups? (Full site, incremental files)

nicholas
Akeeba Staff
Manager

I will preface this by stating the obvious. I am a software developer. I do not divine solutions to problems. I work on the information I am given to make logical deductions which will help us arrive to the root cause of the issue so we can fix it. It is of paramount importance that you understand this and that you give me enough information to do said troubleshooting. Without any information, or with inaccurate / partial information, I either cannot help you or I will be misled into a troubleshooting path which does not apply.

Based on your replies so far here's what I understand. Do tell me if I have guessed anything wrong.

> After restoring original htaccess

This means that you have enabled the optional Stealth Mode. The description of this feature reads:

Visitors to your site coming from a different IP address than yours will be temporarily redirected to installation/offline.html, a file telling them your site is currently under maintenance. Only works on servers which support .htaccess files. Please read the documentation for more information.

Since you already figured it out before I replied I did not comment further, I just want you to know that I did catch that anyway.

> Does the restore function not work with incremental backups?

You seem to be using the integrated restoration, not Kickstart. Not that it matters. Both of them run the same archive extraction code. Moreover, the restoration script that you are having trouble with is included in the backup archive at backup time. What you're using to extract the backup archive may only become important if we exhaust all other troubleshooting avenues.

Furthermore, this tells me that you never told me until now that you are using a backup archive taken with the “Full site, incremental files” backup type. Luckily, it does not matter for the purpose of this troubleshooting. The “Full site” and the “Full site, incremental files” backup types run the same code, the latter ALSO running a bit of code which automatically excludes from the backup all files with a last modified date and time after the date and time you took the last backup with the same backup profile. For the purpose of our troubleshooting you could use either and it'd be exactly the same.

> "something went wrong" ... Yes, but what?

As I told you, something seems to be missing from your installation folder (and I told you what). 

Here's what I have in mind with the information you have provided so far. If you closed the browser window during the archive extraction, or you lost network connection, or received a server error and then possibly tried to reload the page you would have a partially extracted installation folder. If you already had a leftover installation folder from a previous restoration attempt but some of its folders were unwritable because of ownership/permissions, a server error etc you could end up in the same situation. If your server failed to write the extracted files in part or in whole because of a server error beyond our control (in PHP, in the Operating System or the hardware) you would again end up with this error. Even a badly configured OPcache would cause this problem. It's even possible that when you last installed / updated Akeeba Backup, Joomla failed to copy one of the files which contains the Joomla-specific code for the restoration script which is embedded in the backup archive. In the latter case the files would have not been included in the backup archive at all, hence the problem.

The only way for me to know what happened is to start by knowing if the two files I mentioned exist or not. So, do installation/angie/models/main.php and installation/platform/models/joomlamain.php exist when you extract the backup archive?

I will tell you what happens next after you give me this information.

If they do not exist I will ask you for the backup log file so I can see if the files were included in the backup archive to begin with.

If they were not included I will ask you to install Akeeba Backup twice in a row, without uninstalling it before or in between, which fixes Joomla's long-standing problem of sometimes forgetting to copy some files on extension update.

If they files are included I would ask you to take a video of the restoration so I can see if you are receiving an error or warning you may have missed. If there are errors or warnings I will guide you from there (there are too many possible branches to write them all here).

If there are no errors and warnings I would then ask you for access to the site to see what is going on; there's a server error unrelated to our software but I can at least help you find out what.

So, I need information to help you.

> then why does it even let me get to this step?

Software — any software, not just ours — will try to execute. If it's unexpectedly sabotaged (a piece of it is removed before or while it's running) it might break in unpredictable ways. Try removing a DLL from a Windows application which is only used for one feature. You can use the application just fine up to the point where you try using the feature which uses the missing DLL. Then, the application crashes.

> Does the restore function not work with incremental backups? (Full site, incremental files)

It does.

I already told you I tried taking a backup and restoring it before answering your ticket, just in case. Yes, with the same PHP, Joomla and Akeeba Backup version — and I tried both with the integrated restoration and Kickstart because your original ticket was non-specific on that front.

Just to be extra sure, I took a new “Full site, incremental files” backup on Joomla 4.2.3, PHP 8.0 using Akeeba Backup 9.3.0 before posting this reply. I tried both the integrated restoration and Kickstart. Sure enough, in both cases the backup archive does restore correctly.

So, at this point we are certain that this is not a bug in the software. There is something happening in the software installation / upgrade which is handled by Joomla OR a server issue during the archive extraction process OR a server issue when you run the restoration. I will need more information (see bold type above) to start going through the possibilities.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

gdsd

"/installation/angie/models/main.php" does not exist

There is a "main.php" in
"/installation/angie/models/base/"
and in
"/installation/angie/controllers/base/"

"/installation/platform/" directory does not exist
No other file with the name "joomlamain.php" seems to exist in "/installation/"

I downloaded the latest version (pro) from your website and installed it twice via the Joomla dashboard (upload). I did not uninstall.

I took another backup.

"/installation/platform/models/joomlamain.php" does exist now.

"/installation/angie/models/main.php" still does not exist. I did a search in the log-file, it does not mention a "models/main.php".

Side note: one thing I noticed about the timestamp in filename of backup-archive and log-file: The shortcode "[DATE]" of backup-archive name uses correct local time, the corresponding log-file is two hours behind, seems to use UTC.

Example:
backup-archive: "backup-strawb-20221003-211508cest..."
log-file: "akeeba.backend.id-20221003-191508..."

 

nicholas
Akeeba Staff
Manager

> Side note: one thing I noticed about the timestamp in filename of backup-archive and log-file: The shortcode "[DATE]" of backup-archive name uses correct local time, the corresponding log-file is two hours behind, seems to use UTC.

It is UTC, as documented. There's a different variable which uses the timezone set up in your site's Global Configuration and you can also override the timezone in the Options. Please read the documentation.

> "/installation/angie/models/main.php" does not exist

> "/installation/platform/" directory does not exist

Okay, this means that something went wrong at backup time. I triple-checked the package we ship and the files Joomla installs out of it but there is no problem. So let's try to figure out what happened there.

First, check your original site and tell me if the following files exist:

  • administrator/components/com_akeebabackup/installers/angie-joomla.jpa
  • administrator/components/com_akeebabackup/installers/angie-joomla.json
  • administrator/components/com_akeebabackup/installers/angie.jpa
  • administrator/components/com_akeebabackup/installers/angie.json

The archives contain the installer files. The JSON files contain the instructions for assembling the installed out of these files. They are used at backup time to put the installer into the archive. Based on what you described so far it looks like one or both of the angie-joomla files are not present or unreadable. That's what I am trying to determine.

Also go to Components, Akeeba Backup for Joomla, Configuration and find the “Embedded restoration script” setting. What does it read?

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!