Migração do Magento 1: o Data Migration Tool não copia a pasta media

Por que a foto não vem junto

Não é opinião minha, está no arquivo. O config.xml.dist que a ferramenta distribui termina assim:

<source>
    <database host="localhost" name="magento1" user="root" />
</source>
<destination>
    <database host="localhost" name="magento2" user="root" />
</destination>

Origem é um banco. Destino é um banco. Não existe campo de caminho de arquivo, de FTP, de nada. Os três modos — settings, data e delta, nessa ordem — trabalham tabela por tabela.

Tem uma segunda pista, no settings.xml.dist: as configurações web/unsecure/base_media_url e web/secure/base_media_url estão explicitamente na lista de <ignore>. A ferramenta nem carrega a URL de mídia da loja antiga, porque a estrutura de pastas mudou.

E mudou mesmo. No Magento 1 as imagens vivem em <raiz>/media/. No Magento 2, em <raiz>/pub/media/. O que não mudou é o caminho relativo gravado no banco: a coluna value de catalog_product_entity_media_gallery continua guardando algo como /a/b/abc123.jpg, relativo a catalog/product. É por isso que o copia-e-cola direto funciona.

O rsync que resolve

Com os dois servidores no ar, rodando do servidor do Magento 2:

rsync -avz --progress \
  --exclude 'catalog/product/cache/' \
  --exclude 'tmp/' \
  --exclude 'import/' \
  --exclude '.htaccess' \
  usuario@servidor-m1:/var/www/magento1/media/ \
  /var/www/magento2/pub/media/

Três coisas que dão errado nessa linha:

• A barra no fim da origem. media/ copia o conteúdo da pasta. media sem barra cria pub/media/media/ e você vai passar meia hora procurando o erro.
• O cache do M1. A pasta catalog/product/cache costuma ser maior que todo o resto junto, e é lixo: são os redimensionamentos do tema antigo, que o Magento 2 não usa. Fora.
• Os .htaccess. O Magento 2 instala arquivos de proteção dentro de pub/media — na raiz e em customer, downloadable, custom_options, import, sitemap e theme_customization. É o que bloqueia execução de PHP ali dentro. Sobrescrever isso com os do M1 é abrir a porta que o pessoal de segurança passa a vida tentando fechar.

O que você precisa deixar passar: catalog/product e catalog/category (as fotos), wysiwyg (as imagens de CMS e de banner) e downloadable/files, se a loja vende produto para download. Esse último é o mais esquecido, e o cliente só descobre quando um comprador antigo tenta baixar de novo.

Permissão, cache e a conferência que ninguém faz

Arquivo copiado por rsync chega com o dono e o modo do servidor de origem. Aplique o padrão que a Adobe documenta, restrito à pasta que você acabou de mexer:

find pub/media -type f -exec chmod g+w {} +
find pub/media -type d -exec chmod g+ws {} +
chown -R :www-data pub/media
php bin/magento cache:flush

Troque www-data pelo grupo do seu servidor web. O g+ws nas pastas não é capricho: o bit s faz arquivo novo herdar o grupo, e é isso que evita o problema voltar na primeira imagem que o admin subir.

Agora a conferência. Em vez de abrir a loja e olhar, pergunte ao banco qual imagem ele espera e veja se o arquivo está lá:

SELECT value FROM catalog_product_entity_media_gallery LIMIT 5;

ls -l pub/media/catalog/product/a/b/abc123.jpg

Se o arquivo existe e a vitrine continua quebrada, o problema deixou de ser de migração e passou a ser de permissão, de cache ou de URL base. Se o arquivo não existe, faltou rsync.

Um último detalhe de tamanho: catálogo grande com muita foto pode levar horas nesse rsync. Rode uma primeira passada com a loja antiga ainda no ar, dias antes do corte, e uma segunda passada no dia da virada — o rsync só manda o que mudou, e a segunda vai levar minutos. É o mesmo raciocínio do modo delta do tool, aplicado a arquivo.