Posted by thomas on Sat, Nov 18, 2023 - 11:15pm

greetings people , 

After I made a backup I got error messages : 

  • Deprecated function: Creation of dynamic property backup_migrate_filter_utils::$saved_site_offline is deprecated in backup_migrate_filter_utils->take_site_offline() (line 217 of C:\xampp\htdocs\modules\backup_migrate\includes\filters.utils.inc).
  • Deprecated function: explode(): Passing null to parameter #2 ($string) of type string is deprecated in backup_file->set_file_info() (line 521 of C:\xampp\htdocs\modules\backup_migrate\includes\files.inc).

The sequence of events unfolded after I discovered the ability to select the display levels of error messages, namely: None, Errors and Warnings, and All Messages. Opting for "Errors and Warnings," I made this choice.

I'm uncertain about the default setting following a fresh backdrop installation; I believe it might be "None," but my memory is a bit fuzzy on that.

Has anyone else come across similar messages? Moreover, I'm curious about why the message indicates that the function is deprecated. Is it commonplace for deprecated functions to be visible? And what's the rationale behind having deprecated functions within the backdrop's system?

Your insights would be greatly appreciated.

 

 

 

 

Accepted answer

Thomas, thank you for posting all this info. I'm the maintainer of backup_migrate, and just discovered the bug that prevented you from restoring from a file by using "upload". The issue was not the lack of an info file, but something else related to the unarchiving of the tar file for restoring. I'm working on fixing this.

BTW, yes, by copying both the gz and info files and putting them in the Manual directory, you bypassed the upload step (BM finds and lists those files in the restore step). So that means that the restore proceeds correctly in those cases. So, the "restore from upload" is not really functional at this point, but I have found a solution I'm implementing.

Most helpful answers

Hey Tomas. I can try to help

Hey Tomas. I can try to help you, but I will need much more detailed, step by step directions to try to reproduce your problem. Adding snapshots of the screens can also help.

As for subthemes, the current, active theme is not stored in the DB. Like many configurations in Backdrop, it's store in a configuration file, specifically in system.core.json inside files/config_XXX/active.

 

Comments

Sun, Nov 19, 2023 - 6:24am by argiepiano

Hi Thomas. Thanks for posting, and welcome to the forum!

Do you have the latest version of Backup and Migrate, released about 2 or 3 days ago? Can you please check? That fixed a bunch of these deprecated warnings.

The deprecated warning for dynamic properties is common when using PHP 8.2 and some contrib modules of Backdrop. We've been fixing these, but apparently we missed this one in backup_migrate. If you confirm you are using the latest version,  I'll open an issue in the issue queue.

The recommended setting for Errors and Warnings in Backdrop is "None", so that your site visitors are not bothered with php warnings. Still, it's important to check the error log regulary to catch these problems.

Sun, Nov 19, 2023 - 11:19pm by thomas

HI argiepiano , 

Thank you very much for your response . I have the latest backdrop version of backdrop and the latest "Backup and Migrate" version . Today i made a new backup and again this came up" 

  • Deprecated function: Creation of dynamic property backup_migrate_filter_utils::$saved_site_offline is deprecated in backup_migrate_filter_utils->take_site_offline() (line 217 of C:\xampp\htdocs\modules\backup_migrate\includes\filters.utils.inc).
  • Deprecated function: explode(): Passing null to parameter #2 ($string) of type string is deprecated in backup_file->set_file_info() (line 521 of C:\xampp\htdocs\modules\backup_migrate\includes\files.inc). " 

Sun, Nov 19, 2023 - 8:04am by argiepiano

Thomas, I have 2 pull requests that should fix this problem. Do you know how to patch contrib modules? Could you patch backup_migrate in your local deployment of your site (do not use your production site!) using both PRs here:

https://github.com/backdrop-contrib/backup_migrate/pulls

and test locally? Can you post on the issue queue if they work or don't?

Fri, Nov 24, 2023 - 2:33am by thomas

oopss..missed this one.To answer your question: I can not patch the backup module . 

Besides the error messages I got and still have there is another problem with the backup module . I wanted to restore the site with the backup it made .Turns out the backup is refused . messages say that it is because manifest is not present in my backupfiles and a database not present . This happens even after a fresh install of backdrop . Made backups with all the available compress possibilities . Each backup has a manifest and a database file . Also the subtheme directory is present in a backup . When I try to restore my site copying by hand the directories of the backup into the subtheme directory on the server together with the database restored to phpmyadmin no succes . When I do that backdrop wants to start a fresh install . Could you tell me where in the database it can be found that there is a subtheme present and load that subtheme ? 

Sat, Nov 25, 2023 - 6:49am by argiepiano

Hey Tomas. I can try to help you, but I will need much more detailed, step by step directions to try to reproduce your problem. Adding snapshots of the screens can also help.

As for subthemes, the current, active theme is not stored in the DB. Like many configurations in Backdrop, it's store in a configuration file, specifically in system.core.json inside files/config_XXX/active.

 

Tue, Nov 28, 2023 - 11:14pm by thomas

Thanks! I found a workaround to successfully restore the site using a zipped backup file. The process of restoring the site from a saved backup on the server went smoothly without any issues. However, when attempting to restore an uploaded backup file from the "downloads" folder in the Chrome browser, I encountered a problem – the file lacked an .info file. Unlike on the server, where a manually made backup is accompanied by an .info file, the uploaded backup was missing this crucial component.

To resolve this, I manually copied both the backup file and the associated .info file from the server to a USB drive. Upon copying these files back to the server, the restoration of backups proceeded without any problems. Problem was the lacking .info file  Case closed! :)

I've observed that user-uploaded content, such as a text file, isn't automatically deleted after removing the associated node form that was used for uploading the file. I tried searching online and it seems that this automatic deletion might not be a default feature anymore. My experience with Drupal 7 from five years ago doesn't provide a clear memory of whether Drupal 7 automatically deleted node-associated files.

I'm curious if there's a module available to address this issue in Backdrop or if it's a configurable setting. Although I attempted to use the IMCE module, it didn't function as expected. In my attempt to create a custom module, I suspect there might be an issue with the code as the automatic deletion of node files isn't occurring (no error messages were displayed). 

Any insights or suggestions on resolving this file deletion issue would be greatly appreciated!


function mymodule_node_delete($node) {
  // Check if the node type is the one i need.
  if ($node->type == 'mynodetype') {
    // Get the file field value from the node.
    $file_fid = $node->field_my_field['und'][0]['fid'];

    // Delete the file.
    file_delete(file_load($file_fid));
  }
}
 guess i need more practice 

 

 

 

 

Fri, Dec 15, 2023 - 11:37pm by thomas

Thank you for your guidance; it really helped me out . I followed your instructions to create another solution. I deliberately omitted the 'file_delete($file_fid);' to allow the file to persist on the server in a directory with the user's name to delete it manually later. While I acknowledge that my approach may not be perfect, as I'm not a hardcore programmer, I thought I'd share it in case it proves useful to someone else.

function deleteuploadedfiles_node_presave($node) {
  // Checking if the node type is the one  i am interested in.
  if ($node->type == 'mytype') {
    // Get the user information.
    global $user;

    // Check if the user is authenticated.
    if ($user->uid) {
      // Creating a directory based on the user's name within the existing directory.
      $directory_name = 'user_' . $user->name;

      // Building  my directory path.
      $directory_path = 'public://my_documents/' . $directory_name;

      // Checking  if the directory exists and if not create it.
      file_prepare_directory($directory_path, FILE_CREATE_DIRECTORY);

      // Check if the field exists and has value.
      if (isset($node->my field__file_upload['und'][0]['fid']) || isset($node->my field__file_upload['en'][0]['fid'])) {
        // Get the file field value from the node.
        $file_fid = isset($node->my field__file_upload['und'][0]['fid']) ? $node->my field__file_upload['und'][0]['fid'] : $node->my field__file_upload['en'][0]['fid'];

        // Loading my file object.
        $file = file_load($file_fid);

        // Checking if the file is not already in the user's directory.
        if ($file->uri != $directory_path . '/' . $file->filename) {
          // Move the file to the user's directory.
          file_move($file, $directory_path, FILE_EXISTS_REPLACE);

       
        }
      }
    }
  }
}
 

Tue, Dec 12, 2023 - 9:20pm by argiepiano

Thomas, thank you for posting all this info. I'm the maintainer of backup_migrate, and just discovered the bug that prevented you from restoring from a file by using "upload". The issue was not the lack of an info file, but something else related to the unarchiving of the tar file for restoring. I'm working on fixing this.

BTW, yes, by copying both the gz and info files and putting them in the Manual directory, you bypassed the upload step (BM finds and lists those files in the restore step). So that means that the restore proceeds correctly in those cases. So, the "restore from upload" is not really functional at this point, but I have found a solution I'm implementing.

Fri, Dec 15, 2023 - 11:41pm by thomas

Thanks once again for your assistance. I've encountered another issue—I've noticed that in my subtheme, JavaScript is not loading on the 'node/add' page where I specifically need it to load. Oddly enough, it seems to load correctly on the homepage. Do you think it's necessary for me to open a new issue to address this?