Problem/Motivation

We have #2695297: Refactor EntityFile and use process plugins instead in core now. But I need to be able to import a base64 encoded string into a file contents for a plone migration.

Proposed resolution

Code it. Model after #2695297: Refactor EntityFile and use process plugins instead

Remaining tasks

Review and test

User interface changes

API changes

Data model changes

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

heddn created an issue. See original summary.

heddn’s picture

heddn’s picture

  field_picture:
    -
      plugin: skip_on_empty
      method: process
      source: image_url
    -
      plugin: file_copy
      source:
        - file_name
        - '@destination_path'
        - blob
    -
      plugin: entity_generate
heddn’s picture

Status: Active » Needs review
FileSize
2.83 KB
4.86 KB
source:
...
  constants:
    destination: public://images/
...
process:
...
# image migration
 destination_blob:
   plugin: callback
   callable: base64_decode
   source: blob
 destination_basename:
   plugin: callback
   callable: basename
   source: file_name
 destination_path:
   plugin: concat
   source:
     - constants/destination
     - @destination_basename
 field_image:
   -
     plugin: skip_on_empty
     method: process
     source: @destination_basename
   -
     plugin: file_blob
     source:
       - @destination_path
       - @destination_blob
   -
     plugin: entity_generate
...
mikeryan’s picture

Status: Needs review » Needs work
  1. +++ b/src/Plugin/migrate/process/FileBlob.php
    @@ -0,0 +1,160 @@
    +    if ($this->putFile($destination, $blob)) {
    ...
    +    if ($this->putFile($destination, $blob)) {
    

    We should assign the result of putFile() to $destination, in case of rename.

  2. +++ b/src/Plugin/migrate/process/FileBlob.php
    @@ -0,0 +1,160 @@
    +    $fileName = basename($destination);
    

    Eager to apply #2648050: [policy, no patch] Stop disallowing camelCase for local variables / parameters are we;)? I'm actually for that, but I'd rather keep the module self-consistent for now - if we're going to go all camelCase that should be a distinct issue changing the whole module.

  3. +++ b/src/Plugin/migrate/process/FileBlob.php
    @@ -0,0 +1,160 @@
    +    throw new MigrateSkipProcessException("File $fileName could not be copied to $destination.");
    

    Actually, I don't think displaying the basename adds anything here - better to say something like "Blob data could not be copied...".

  4. +++ b/src/Plugin/migrate/process/FileBlob.php
    @@ -0,0 +1,160 @@
    +    return $destination;
    

    Are we sure an existing file is the only reason file_destination might return FALSE?

    Not sure it's right to always leave the destination untouched - the D7 FILE_EXISTS_REUSE permitted control over this.

heddn’s picture

re: #5
1. I removed rename as an option. It doesn't make sense with a blob. If we need to rename it, then use a previous process plugin to rename the destination path before passing into this plugin.
2 & 3. Fixed
4. file_destination does work that way. So the code should function correctly as coded.

Also of note, I changed the default from don't re-use to always replace. It seems to be the default in D7 and D8, so let's not provide any surprises to folks coming from other parts of Drupal.

heddn’s picture

Status: Needs work » Needs review

  • mikeryan committed bb54617 on 8.x-2.x authored by heddn
    Issue #2795879 by heddn: FileBlob process plugin
    
mikeryan’s picture

Status: Needs review » Fixed

Committed, thanks!

  • mikeryan committed bb54617 on 8.x-3.x authored by heddn
    Issue #2795879 by heddn: FileBlob process plugin
    

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.