Migrer depuis le type de contenu personnalisé ATImage (désormais obsolète)

Question

Nous avions toute une collection de sites Plone 3 avec un type d'image personnalisé hérité de ATImage. Cela nous a permis d'ajouter une mise à l'échelle d'image supplémentaire à la liste standard ("'logo':(454, 58)", utilisée par notre package de thème).

Alors que cela fonctionne toujours avec Plone 4, ce n'est pas vraiment la bonne approche maintenant que plone.app.imaging fait partie de l'ensemble d'outils standard. Cela peut définir des mises à l'échelle personnalisées à la volée.

Il semble que je puisse activer plone.app.imaging sur n'importe quel type hérité de ATImage en définissant simplement "sizes = None" pour la collection de mises à l'échelle personnalisées sur le type. Cependant, je me retrouve alors avec un sous-classe redondant de ATImage. À long terme, il serait utile de remplacer tous nos éléments de contenu existants "FalconImage" (au total des centaines) par des éléments de contenu "Image" standard.

Une brève expérience sur un site de test révèle que si je parcours simplement l'arborescence de documents en mettant à jour l'attribut portal_type de "FalconImage" à "Image", alors le contenu se comporte comme une "Image" : chaque objet acquiert soudainement un onglet Transform et toutes les mises à l'échelle définies par @@imaging-controlpanel.

Je suis sûr qu'il y aurait des conséquences d'une telle approche brutale. Existe-t-il une approche recommandée pour transformer un type en un autre ?

(Je suis prêt à ajouter du code source pour notre type personnalisé ATImage si quelqu'un pense que c'est pertinent. Il s'agit vraiment d'un ajustement très minimal de ATImage, avec une collection différente de tailles sur ImageField)

Answer 1

Oui, il existe une approche recommandée :

http://pypi.python.org/pypi/Products.contentmigration

La seule chose que vous avez à faire est d'écrire une migration personnalisée de FalconImage vers Image.

Au revoir, Giacomo

Answer 2

Vous avez besoin d'utiliser Products.contentmigration mais la documentation là-bas n'est pas un bon point de départ. Utilisez les docs sur plone.org pour un guide étape par étape sur la migration de contenu.

Answer 3

Merci à Giacomo et Ross pour les indications.

Au cas où cela serait utile à d'autres, mon code de migration a fini par ressembler à ce qui suit :

from Products.contentmigration.walker import CustomQueryWalker
from Products.contentmigration.archetypes import InplaceATItemMigrator

class FalconImageMigrator(InplaceATItemMigrator):
    walker = CustomQueryWalker
    src_meta_type = "FalconImage"
    src_portal_type = "FalconImage"
    dst_meta_type = "ATBlob"
    dst_portal_type = "Image"

    # Suivant volé à plone.app.blob.migrations, ATImageToBlobImageMigrator
    # migrer tous les champs sauf 'image', qui nécessite un traitement spécial...
    fields_map = {
        'image': None,
    }

    def migrate_data(self):
        self.new.getField('image').getMutator(self.new)(self.old)

    # ATFileToBlobMigrator réindexe certains champs. Sinon, nous
    # devons effacer et reconstruire l'intégralité du catalogue.
    def last_migrate_reindex(self):
        self.new.reindexObject(idxs=['object_provides', 'portal_type',
           'Type', 'UID'])

migrator = FalconImageMigrator
walker   = migrator.walker(portal, FalconImageMigrator)

walker.go()
print walker.getOutput()

Complications:

1. L'image est un peu étrange en tant que type de destination, car les données sont migrées dans le magasin de blobs.

2. Nous devons mettre à jour le catalogue afin que les liens "resolveuid/UID" générés par TinyMCE continuent de fonctionner. La méthode last_migrate_reindex() de la classe Migrator devrait être plus rapide que de vider et reconstruire l'intégralité du catalogue à partir de zéro.