#16 seems to have been fixed in https://www.drupal.org/project/backup_migrate/issues/3350436 🐛 Deprecation messages with PHP 8: Creation of dynamic property... Fixed .
Could you file a separate report for #17, please? A manual download may not have to do anything with FTP. Do link however to this report, as I cannot immediately reproduce your bug.
A patch needs to be applied, not installed.
Patches are a way for developers to publish code changes for review. When applied they change the files of the module. Here is the official documentation on how to apply patches → and here is a Stackoverflow question on how to apply patches.
Patching is not for the faint of heart but with a little technical knowledge, courage and perseverance it is doable. :-)
If things go wrong, just replace the files from a fresh module download.
The code in the patch is work in progress, so it may not work or may have adverse effects. Ideally you test the patch on a copy of your site. Please report any things that go wrong (assuming you have successfully applied the patch) in this issue.
If the patch works for you, you may wish to apply it to your production environment. Any updates to the module will overwrite the patch. If those updates do not (yet) contain the changes from the patch, you may need to re-apply the patch.
I just realised that since it doesn't matter which destination you use, the switch to SFTP may not be the culprit.
I currently have no way to test against PHP 7.4, so hopefully somebody else can look into this.
Thanks for the feedback. This is certainly useful. Regardless of what causes the corruption, you would expect the B&M module to not report the wrong file sizes if it can avoid doing so.
Plato1123 and Jvogt, if you look at the corrupted files with a text editor, do you see anything out of the ordinary? A file size of around 1 KB could mean something has written a plain text error message to the file. It might be useful to know that message.
-------
Some notes for whoever picks up this issue:
backup_migrate.module:backup_migrate_ui_saved_backups() (1453) is the callback for the menu hook for the Saved Backups tab.
includes/destinations.inc:_backup_migrate_ui_destination_display_file_list() (310) calls theme() to create the table on the Saved Backups tab.
includes/destinations.inc:backup_migrate_destination::load_files_info() (925) retrieves file size info from the accompanying .info file if it exists. This includes a field 'filesize'.
It seems this .info file is created upon back-up file creation. The PHP function filesize() is ultimately the source of its wisdom.
This suggests to me that even if, over time, the .info file and reality have gotten out of sync, there must have been a time where the back-up file actually had that size.
Perhaps also useful to know, https://www.php.net/manual/en/function.filesize.php suggests that:
- "[this function] may return unexpected results for files which are larger than 2GB"
- "The results of this function are cached."
And the comments add that:
- "If you recently appended something to file, and closed it then this method will not show appended data. You should insert a call to clearstatcache() before calling filesize()."
This patch seems to make all the above-mentioned messages except the desired one go away.
Turns out I had some time after all. This patch implements the suggestion of #5 and a small fix for a trivial problem where an error message wasn't shown.
The "host of [problems]" I was talking about in #5 were caused by me not having a proper FTP server to connect to. Those error messages went away when I introduced a working FTP destination. I will address them in a separate issue.
I can confirm that this bug is still present in Backup and Migrate 7.x-3.10.
I ran across it while trying to fix bugs caused by changes in PHP as of PHP 8.
Since over the years so few people appear to have encountered this bug, there may be special conditions required to trigger it. My guess is it may have to do with me developing under MS Windows (10 Home) and running a FTP-server on that platform to test against.
I won't reopen because I am not sure fixing it won't do more damage than leaving it alone.
@DamienMcKenna, do you have an approximate idea of what you would like browser testing to achieve?
Please do not change the version number when a) this is still very much a BAM for D7 problem en b) BAM 5 is a complete rewrite; even if it shares the same problem, it probably does so for completely different reasons.
I am marking this as a duplicate of FTP error with php 8.0 🐛 FTP error with PHP 8.0 Fixed , even though this issue is older and has perhaps a better title. Reason: the other issue has more comments.
I will edit the other issue to include your steps to reproduce.
If you open the file in a text editor, what does it look like?
I am asking because several browsers unpack a downloaded .gz file, but do not rename it when saving it to the local file system.
You will also get the favicon.ico message on Drupal sites without the BAM module and even on non-Drupal sites (in my experience), so I consider it unlikely that this has anything to do with your problem. You are correct in stating that the favicon.ico file is a resource/asset, not a page, but if that is a bug, it is a bug against Drupal core, not BAM.
Thanks for checking the log though, that is always useful.
If you use a different destination and remove the FTP destination for now (make a backup of your settings first), do you still get the blank screen?
I cannot reproduce this (Apache on Windows 10 Home, destination Manual Backup).
What is the operating system (name and version) you are running?
What is the backup destination?
I can confirm this error.
How to reproduce:
- Create an FTP destination.
- Go to admin/config/system/backup_migrate/backups.
What happens in includes/destinations.ftp.inc is that the function responsible for creating a connection first tests if a connection already exists.
It does this by calling drupal_ftp_connected() with an incomplete $ftp object.
When that happened in PHP 7, PHP's ftp_systype() function was perfectly happy to test a non-existent resource, but in PHP 8, the same function does not like it when it receives a non-existent FTP\Connection instance.
When I change line 200 (inside the drupal_ftp_connected() method) from
if (!@ftp_systype($ftp->__conn)) {
to
if (isset($ftp->__conn) && !ftp_systype($ftp->__conn)) {
(inserted: isset($ftp->__conn) &&), this particular problem goes away, but a host of new ones pop up.
Unfortunately I do not have the time right now to look at this further. It looks like the whole include needs to be looked at to get FTP working again.
The PHP manual says about ftp_systype():
Changelog:
PHP 8.1.0. The ftp parameter expects an FTP\Connection instance now; previously, a resource was expected.
I have not been able to reproduce this with either PHP 8.1 or PHP 8.2 following the instruction of the reporter.
The patch suggests that the problem is in the method set_url(), where so far error suppression (using the ampersand prefix in PHP) has been used instead of error handling.
I did manage however to reproduce the error by creating a fresh FTP destination. I haven't checked, but presumably the 'pass' field, when left empty, causes a problem here.
Applying the patch makes the error messages go away, while the database entry for this destination remains the same.
As an aside, in this particular instance (i.e. the FTP destination example) I get an additional error message: Warning: Undefined array key "old_password" in backup_migrate_destination_remote->edit_form_submit() (line 1341 of /drupal7/sites/all/modules/backup_migrate/includes/destinations.inc).
You might be able to use hook_watchdog() to delete the log entry before it gets saved to the database. However, it seems there might be quite some Drupal trickery involved in getting it to work (e.g. order in which hooks are called, calling a hook early in the bootstrap, forcing dblog_watchdog() to abort and so on). I haven't tried this myself, so I do not know if it would work, nor if it would be worth it.
According to https://www.php.net/manual/en/language.oop5.properties.php :
Dynamic properties are deprecated as of PHP 8.2.0. It is recommended to declare the property instead. To handle arbitrary property names, the class should implement the magic methods __get() and __set(). At last resort the class can be marked with the #[\AllowDynamicProperties] attribute.
(This is response to the person who was unsure about which PHP 8 version was causing the problem and also to highlight the available and the recommended solutions.)