Pods: Le bogue avec les gestionnaires de vignettes PDF WP 4.7.1 {@_src} passe par pods_image_url ajoute le suffixe de l'image

Captures d'écran oubliées. Voici ma configuration de champ Pod, le modèle de Pod et une partie de la sortie.

Il semble que nous ayons besoin d'un meilleur gestionnaire pour les liens sans image vers les fichiers joints.

https://github.com/pods-framework/pods/blob/2.x/classes/Pods.php#L1452

En ce moment, _src et _src.{size} passent par la fonction pods_image_url() .

Je ne veux pas être un parasite, je me demande juste s'il y a du mouvement à ce sujet. Je ne suis pas moi-même un développeur de plugins, j'ai juste été dirigé ici depuis les forums WP pour attirer l'attention là-dessus.

Aucun progrès sur un correctif pour cela, nous avons travaillé dur sur la préparation des Pods 2.7 pour la version bêta. J'ajouterai ceci à ma liste pour y revenir quand j'aurai un moment libre dans les prochains jours.

@portlandian, vous pourrez peut-être utiliser la solution de contournement dans #3376 pour transmettre l'ID du fichier joint à une fonction et utiliser https://codex.wordpress.org/Function_Reference/wp_get_attachment_url contre elle, c'est-à-dire :

{@test_result_pdf.ID,wp_get_attachment_url}

@portlandien
Je me demandais simplement pourquoi n'utilisez-vous pas simplement {@test_result_pdf} ?
Cela renvoie l'URL du PDF lorsque je le teste ici. Il n'est pas nécessaire d'ajouter ._src ou quoi que ce soit.

Des termes tels que full ou large sont tous liés aux types d'images, ils sont simplement affichés car il s'agit d'un champ de fichier Pods général. Vous n'en avez pas besoin pour les types de champs autres que les images.

@sc0ttkclark
Merci pour la réponse rapide et j'attends avec impatience 2.7

@jimtrue
Merci pour la solution de contournement. Je n'étais pas au courant. Heureusement je n'en aurai plus besoin depuis...

@JoryHogeveen
Seulement parce que je ne savais pas que cela fonctionnerait. Je me réfère uniquement à http://pods.io/docs/build/using-magic-tags/ chaque fois que j'utilise les modèles, et je n'ai jamais vu cela dans la section sur les balises pour obtenir les URL des fichiers. S'il est là et que je l'ai raté, c'est mauvais, mais peut-être qu'aborder les fichiers non-image dans cette section pourrait être une bonne idée. J'ai changé mon modèle pour utiliser cette balise et maintenant cela fonctionne. Problème résolu.

Vous êtes super les gars !

@portlandian Heureux d'apprendre que cela fonctionne !

peut-être qu'aborder les fichiers non-image dans cette section pourrait être une bonne idée.

@jimtrue C'est peut-être une bonne idée ! :)

Bon point, mais oui, on pourrait penser que @_src obtiendrait simplement l'URL du fichier. Fondamentalement, en n'utilisant pas l'un ou l'autre, en utilisant simplement la balise elle-même pour le fichier, vous obtenez la "sortie du fichier" comme d'habitude. Je ne suis pas sûr que cela fonctionnerait si vous aviez plusieurs fichiers et que vous deviez [chaque image_file][/each] à travers eux, car à ce stade, il n'y a pas de "tag" à appeler pour l'URL autre que {@_src}, nous devons donc encore traiter et corriger cette sortie. C'est encore un bug.

Plus précisément des notes de Scott :
Il semble que nous ayons besoin d'un meilleur gestionnaire pour les liens sans image vers les fichiers joints.

https://github.com/pods-framework/pods/blob/2.x/classes/Pods.php#L1452

À l'heure actuelle, _src et _src.{size} passent par la fonction pods_image_url().

@jimtrue
Très bon point sur les chaque boucles. #4111 corrige cela.

@ sc0ttkclark Remarque : j'ai fait le PR contre 2.x.

Oh et @jimtrue .
Commenter dans le PR (peut-être quelque chose pour les docs)

Lors de l'utilisation de shortcodes avec des pièces jointes PDF, ._src renvoie une image depuis WP 4.7.
Avec ce correctif, il renverra l'URL du PDF.
Obtenir des images générées au format PDF (WP 4.7) est toujours possible en utilisant ._src.image_size ou ._img.

Noté!! Je vais les ajouter à la fois aux anciens et aux nouveaux documents

Cela a été corrigé à partir du #4111

@JoryHogeveen @pglewis Malheureusement, cela est toujours en panne. Je peux confirmer que {@_src} fournit toujours le lien vers les vignettes régénérées pour les PDF.

Veuillez consulter la conversation dans ce ticket à partir de : https://github.com/pods-framework/pods/issues/4580#issuecomment-354883021 vers le bas.

Cela semble être lié au fait que l'hôte crée des vignettes de PDF. My Local by Flywheel ne le faisait pas, il était donc correctement lié aux fichiers PDF, mais sur WPEngine (qui génère des vignettes), la balise {@_src} pointe _uniquement_ vers la vignette de l'image, pas le PDF. Très ennuyant.

@brian-milnes a fourni une très bonne solution de contournement qui permet d'accéder directement au bon PDF, alors peut-être que c'est quelque chose dans notre gestionnaire pour _img et _src est le problème :

Nous avons fait une solution de contournement en utilisant
{<strong i="14">@ID</strong>,wp_get_attachment_url}

S'il s'agit d'un problème d'environnement, nous devrions d'abord créer un environnement similaire à reproduire.
Je sais que WP Engine a son propre plugin indispensable, par exemple.
Pouvons-nous faire une liste pour cela?

@JoryHogeveen Je pense que le problème pourrait être que nous passons toujours par le gestionnaire 'image' pour {@_src}; Je ne sais pas pourquoi WordPress privilégierait les vues miniatures d'un PDF par rapport au PDF lui-même, mais c'est peut-être l'un de ces cas où nous avons besoin d'une balise {@_file} à la place, si {@_src} est acheminé via pods_image_url. Nous avons besoin d'un moyen de les acheminer vers get_attachment_url.

Je suis bon pour faire une liste, mais je ne sais pas sur celui-ci s'il est logique de créer une nouvelle balise uniquement pour les pièces jointes (parce que je suppose que nous rencontrerions également cela avec d'autres fichiers) ou si nous devons rendre _src {@_src} plus intelligent.

Mon intuition : {@_img}, _img et tout _src.size devraient renvoyer les vignettes des images. _src doit toujours renvoyer l'URL du fichier.

@sc0ttkclark Pensées ?

Oh et sur l'environnement de test, oui, nous en avons un avec themer.pods.io ou nous pouvons en créer un autre sur notre hôte WPEngine pods.io si cela aide @JoryHogeveen

Maintenant, le bon lien #4964 - est aussi un bon exemple !

hum maintenant, il semble que ni {@_src} ni {@permalink} ne fonctionnent dans un [each] :/

@quasel Fournissez votre exemple de modèle ? Je le fais tout le temps et j'en ai plusieurs en ce moment qui fonctionnent parfaitement.

Juste pour confirmer, les gestionnaires d'images ont changé dans les dernières versions. Est-ce un problème actif ?
@quasel Avez-vous un test rapide disponible pour vérifier?

Juste pour confirmer, les gestionnaires d'images ont changé dans les dernières versions. Est-ce un problème actif ?
@quasel Avez-vous un test rapide disponible pour vérifier?

C'est toujours un problème à partir de la version 2.7.22, j'ai mis à jour mon code de modèle / avec la solution de contournement pour le moment, mais j'essaie toujours de lier les vignettes pour les PDF.

mais il essaie toujours de lier les vignettes des PDF.

@zushiba Qu'entendez-vous par "tenter" ? Pouvez-vous partager un cas d'utilisation qui serait une sortie incorrecte ?

mais il essaie toujours de lier les vignettes des PDF.

@zushiba Qu'entendez-vous par "tenter" ? Pouvez-vous partager un cas d'utilisation qui serait une sortie incorrecte ?
J'ai un champ de téléchargement multi-fichiers, il est utilisé par mes utilisateurs pour télécharger des documents PDF qui sont ensuite répertoriés sur une page via le modèle suivant.

<h1>{@post_title}</h1>
<ul>
[if form_files]
[each form_files]
<li><a href="{@_src}">{@post_title}</a></li>
[/each]
[/if]
</ul>

Lors du téléchargement de 2 PDF aujourd'hui, un de mes utilisateurs a découvert que lorsque leur PDF a été téléchargé, le lien résultant sur la page est allé à la vignette .jpg du PDF, et non au PDF réel. J'ai pu confirmer que les fichiers PDF étaient téléchargés sur le serveur et que dans l'interface du tableau de bord de l'élément de pod, il renvoyait au bon fichier, mais le lien lui-même allait vers la vignette jpg.

Problème résolu dans #5854
Si les utilisateurs souhaitent tester ce patch, ce serait génial !