Je suis actuellement en train de migrer le contenu d'un site d'un ancien site pré 4.1 vers une nouvelle configuration et de rencontrer un problème avec le problème d'erreur d'arrondi # 18532 et le correctif correspondant .
Pour résumer cela a corrigé un mauvais comportement d'arrondi de longue date du côté de WordPress:
Imaginez que nous téléchargions une image avec 693x173 et la redimensionnions à une largeur de 300:
- avant 4.1: 300x74
- poste 4.1: 300x75
Le problème
Généralement, cela ne pose aucun problème car les fichiers existants ne <img>
sont pas touchés.
Mais lors de la régénération vous pouces ou des pièces jointes importation d'un fichier WXR ils sont générés différemment dans le système de fichiers laissant tous <img>
dans post_content
morts.
Vous cherchez une solution
J'ai pensé à différentes solutions:
Revenir au mauvais vieux temps
Changeset 30660 a introduit un nouveau filtre wp_constrain_dimensions
qui peut être utilisé pour simplement réintégrer l'ancien comportement d'avant 4.1. Cela résout le problème. Mais je me demande si cela pourrait causer des problèmes plus tard et en général, j'aimerais avoir le correctif, même si cela fonctionne, je le jugerais non idéal.
Les temps sont en train de changer'
Cela nous laisse donc un autre objectif: nettoyer la base de données et remplacer toutes les références aux anciens fichiers par des références aux nouveaux fichiers. La question que je pose actuellement ici est de savoir comment procéder. Je recherche une solution efficace et d'application générale car je soupçonne que ce problème affecte et affectera beaucoup de gens
Mon idée actuelle est la suivante:
- Importez, régénérez ou tout ce qui nous laisse avec les nouveaux fichiers et les balises cassées.
- Créer une liste A à partir de tous les fichiers redimensionnés du système de fichiers ou obtenir ces informations de la base de données
- Analyser cette liste et créer une deuxième liste B avec des noms de fichiers tous décalés d'un pixel comme ils le feraient avant 4.1
- Effectuez une recherche et remplacez l'ensemble de la base de données en remplaçant toutes les occurrences de B par l'entrée correspondante dans A
Je ne sais tout simplement pas si c'est la façon la plus intelligente et la plus efficace de gérer cette situation. Cela semble également un peu trop brutal. Donc, avant de le mettre en œuvre, je voulais juste vérifier avec la sagesse infinie de la foule WPSE;)
[edit] Après avoir lu la réponse de ck-macleod (merci!) je pense qu'un correctif devrait résoudre ce problème une fois pour toutes afin que vous n'ayez pas besoin de garder constamment ce problème à l'arrière de votre tête. [/Éditer]
[edit2] Je viens de trouver un ticket associé sur Trac . Ajout pour référence. [/ edit2]
error issue of #13852
dire#18532
? :)Réponses:
Il s'agit d'une autre approche que l'autre réponse qui fonctionne lors de l'importation de contenu avec l'importateur et corrige les URL une fois pour toutes. Encore une fois: ce n'est pas testé au combat, mais c'est la solution sur laquelle j'ai opté et cela a fonctionné.
Je préfère cela car cela résout le problème une fois pour toutes et si cela fonctionne, cela fonctionne. Comme vous ne laissez pas de trucs cassés dans la base de données et les réparez à l'écran, vous n'avez pas à vous soucier des trucs qui se brisent plus tard.
la source
Résoudre le problème globalement et parfaitement pour TOUS les fichiers d'image (et liens) dans un grand site - étant donné, par exemple, que des individus peuvent avoir parfois renommé des fichiers d'image en imitant manuellement le style WP - et d'autres variations étranges - pourraient être difficiles. Les opérations de recherche et de remplacement de bases de données impliquent également des complications (et des risques!).
Pourriez-vous gérer la grande majorité des erreurs - images cassées et liens d'images cassés, je présume - et obtenir le résultat final souhaité ou un fac-similé raisonnable, par la méthode suivante?
Identifiez la date avant laquelle toutes les images redimensionnées ont été redimensionnées par l'ancienne méthode "intval" plutôt que par la nouvelle méthode "round". (Un autre type de coupure pourrait également être créé, mais la date semble plus simple.)
Pour tous les articles publiés <= la date limite, exécutez preg_replace sur the_content () au moment du chargement / rendu, en capturant tous les fichiers image avec le ou les motifs de problème et en les remplaçant par le motif souhaité. La base de données resterait inchangée, mais la sortie serait sans erreur dans la plupart des cas. Je ne sais pas si la solution devrait s'appliquer à la fois au contenu de publication de page "singulier" et aux pages d'archivage et autres processus également.
Si une solution de ce type était utile, alors la question suivante serait de savoir si les modèles de problème et les remplacements pourraient être définis de manière adéquate. Il semble à partir de votre liste de solutions proposées que peut-être quelques schémas typiques pourraient en fait être isolés (peut-être tirés de paramètres de supports antérieurs produisant des miniatures et d'autres images).
J'ai déjà écrit une fonction plus simple que j'utilise (et je suis en train de devenir un plug-in), qui remplace globalement tous les fichiers image dans les répertoires désignés, jusqu'à une certaine date, avec une image ou un lien d'image par défaut, selon la méthode décrite ci-dessus. C'était pour un site où, par excès de prudence en matière de droit d'auteur, les opérateurs ont simplement supprimé toutes leurs images, ignorant qu'en plus de produire des résultats moches sur les anciennes pages, ils produisaient également des milliers d'erreurs, deux pour chaque image.
Si vous pouvez affiner le modèle de problème plus spécifiquement et les cas où la sortie devrait être modifiée, alors je pourrais voir comment le brancher dans mon format - ce qui n'est pas très compliqué, et qui pour un meilleur RegExer que je pourrais même être facile. D'un autre côté, je ne voudrais pas perdre votre temps ou mon temps si cette approche ne répond pas au problème pour vous.
la source
wp_constrain_dimensions
comme mentionné dans la question tout en faisant l'importation et s'abstenir de reconstruire les pouces serait plus propre.D'accord, c'est une approche de base pour remplacer les images cassées à la volée. Sachez qu'il s'agit davantage d'une preuve de concept que d'une solution éprouvée au combat. Il accroche simplement le
the_content
filtre, ce qui pourrait (probablement) avoir des effets secondaires indésirables dans certaines situations. Manipuler avec soin. :)Bien qu'il le dise aussi dans le code, je veux aussi créditer @Rarst pour cette réponse utilisée dans mon code.
la source