Bring back "Description / note" field to quick save tab (as in Drupal 7 release)

There are still some major issues that need to be addressed with this module to make it functional for all users, and work is going pretty slowly. A new maintainer has been requested for months to help with the work, but no one so far with the skills to do so has come forward. So, I'm setting this feature request to a minor priority since there are so many other tasks that are huge as far as making this module viable in Drupal 8. If users are really interested in getting this feature for Drupal 8, it would be nice to see more followers and comments of support in this thread. Also, is someone able to adapt code from Drupal 7 to Drupal 8 and provide a patch for dev?

Patch attached.

We have a new maintainer now, Alex Andrascu and his team at Intellix, who are working toward making D8 a stable release. If you're still interested in this feature, it would be nice to have more work done on a usable patch. We are anticipating a new D8 release soon, so you might watch for that and then work on the patch from there. Also, you might want to mention this feature in the discussion at the D8 Backup and Migrate Roadmap.

+1 for notes.

I used this feature all the time with D7

+1 for notes - really miss this feature at the moment.

So you want the same thing in D8 just a log note?

Exactly like D7, whatever that was.

+10 to bringing back the add note to the backup :)

Such a handy feature - I miss it!!

Yes, this would be very handy! Especially when testing modules out to note at what stage the backup was taken.

+1 for this!

New patch arriving!

I added the description above the backup the title.
Btw I had to change the BackupMigrateInterface interface otherwise I would not be able to get the description as the backup method receives the $source_id and $destination_id only.

Here is a much simpler patch that there is no need to change the interface.

Nice work @paulocs and indeed quite simple with huge benefit :)

Only thing I'm unsure about is the need to escape these variables perhaps:

+      $col['description'] = [
+        '#markup' => '<div title="' . $backup->getFullName() . '" class="backup-migrate-description">' . $backup->getFullName() . '</div>',
+      ];
+
+      if (!empty($backup->getMeta('description'))) {
+        $col['description']['#markup'] .= ' <div title="' . $backup->getMeta('description') . '" class="backup-migrate-description">' . $backup->getMeta('description') . '</div>';
+      }

Afterwards they run through the renderer, I guess it's OK, but someone else should have a look for #markup security reasons to be 100% sure.

Hello @Anybody,
I've never done this before, how should this part of code look like?

@hmendes: I'm also unsure about this, as I wrote, so perhaps one of the others in this issue can help?

If it becomes RTBC'd, could be a good candidate for #3223059: Plan for Backup and Migrate 5.1.0?

@paulocs & @hmendes, here we go:
https://drupal.stackexchange.com/questions/184963/pass-raw-html-to-markup

I think inline_template would be nice and could also clean things up here with a {{description}} variable :)

I'm going to review this one!

Sorry should be "Needs work" as of #23

I created an issue fork and applied the patch from #19.

I don't think, we need any additional escaping for the markup, since it already gets filtered through Xss::filterAdmin. See Render API overview for further information.

EDIT:

Note that the value is passed through \Drupal\Component\Utility\Xss::filterAdmin(), which strips known XSS vectors while allowing a permissive list of HTML tags that are not XSS vectors. (For example, [script] and [style] are not allowed.)

I'm going to review it.

After applying the last patch, I could use the functionality of add a note at quick backup.

I could not find any phpcs errors and the code looks good to me.

I attached a GIF showing the note added to quick backup.

I'm moving it to RTBC :D

Thanks @Grevil for that additional information in #29! Great! :)

I agree with RTBC and would like to let @DamienMcKenna decide, if we can commit it this way or better put it into an inline_template. For me both is fine as we now know it's secure. :)

Thank you all! Would be cool to have this in the next release, as it's really helpful.

+1 to RTBC

inline_template would indeed be more restrictive (as an additional escaping for markup). It could be better (maybe), but would it be necessary for this issue's scope?

I think using #markup here is enough and if needed it can be improved in the future :)

Committed. Thank you all!

Thank YOU Damien that's great!! :) Small but very helpful.