J'ai créé un module personnalisé qui effectue une gestion de formulaire et un style supplémentaires requis pour mon projet - tout fonctionne bien.
En raison de la taille du formulaire - 50 champs impairs - je configure un fichier Twig dans mon module pour l'écran de confirmation car il est beaucoup plus facile de le gérer dans mon IDE que d'utiliser l'interface graphique. Ma page de confirmation répertorie toutes les valeurs stylisées d'une manière spécifique et présentées d'une manière spécifique. Je l'ai techniquement fait fonctionner en utilisant hook_theme_suggestions_webform_confirmation_alter
et hook_theme
pour pointer vers mon modèle Twig.
Cependant, je viens de découvrir récemment que, en raison de Drupal 8 mise en cache de page interne étant si agressive pour les utilisateurs anonymes, la page de confirmation est mise en cache pour tout le monde indépendamment des valeurs de soumission réelles. le premier utilisateur obtient bien mais la deuxième soumission obtient alors la version mise en cache de la première.
J'ai lu dans d'autres endroits pour utiliser hook_preprocess_webform_confirmation
Et mettre $variables['message']['#cache']['max-age'] = 0;
. Cependant, cela n'est jamais appelé, ce qui, je pense, est dû à la façon dont j'ai utilisé mon modèle Twig mentionné ci-dessus).
Quelqu'un peut-il m'aider à me diriger dans la bonne direction ici? Suis-je censé configurer une sorte de route d'écrasement afin de changer le fichier de thème ou s'agit-il simplement de modifier ce que j'ai déjà fait?
Fonctions dans mon .module
fichier
function application_theme($existing, $type, $theme, $path) {
$info = [
'gib_application' => [
'render element' => 'form',
'template' => 'application-form'
],
'application_form_confirmation' => [
'template' => 'application-form-confirmation'
]
];
return $info;
}
Et
function application_theme_suggestions_webform_confirmation_alter(array &$suggestions, array $variables) {
if (empty($variables['header'])) {
$suggestions[] = 'application_form_confirmation';
}
}
MISE À JOUR
J'ai peaufiné mon hook_theme
fonction ci-dessous et également désactivée hook_theme_suggestions_webform_confirmation_alter
en supposant que ce n'est pas pertinent tant que hook_theme
définit le nom correct.
function application_theme($existing, $type, $theme, $path) {
$info = [
'gib_application' => [
'render element' => 'form',
'template' => 'application-form'
],
'webform_confirmation__application_form' => [
'template' => 'application-form-confirmation',
'base hook' => 'webform_confirmation'
],
];
return $info;
}
Voici les suggestions Twig:
<!-- FILE NAME SUGGESTIONS:
* webform-confirmation--application-form.html.twig
x webform-confirmation.html.twig
-->
Malheureusement, mon modèle Twig n'est pas du tout chargé actuellement (en raison de la suppression de hook_theme_suggestions_webform_confirmation_alter
.
Résumé de la réponse finale à mes questions originales.
hook_theme
Était toujours requis dans le module pour indiquer qu'il peut être utilisé pour les modèles Twig Twig.
function application_theme($existing, $type, $theme, $path) {
$info = [
'webform_confirmation__application_form' => [
'base hook' => 'webform_confirmation'
]
];
return $info;
}
hook_theme_suggestions_webform_confirmation_alter
N'était finalement pas requis une fois que hook_theme
Était correctement configuré.
hook_theme
Devait avoir le nom suggéré tel que proposé par le débogueur Twig. Twig a suggéré ces fichiers:
<!-- FILE NAME SUGGESTIONS:
* webform-confirmation--application-form.html.twig
x webform-confirmation.html.twig
-->
Les tirets sont convertis en traits de soulignement, c'est-à-dire que webform-confirmation--application-form
Est traduit en webform_confirmation__application_form
.
La seule variable associée à cette partie du tableau était base hook
. Cela indique d'utiliser la fonctionnalité de raccordement initial plutôt que de tout configurer à nouveau dans mon module - lire la suite ici .
crochet de base : utilisé uniquement pour les suggestions de thèmes: le nom du crochet de thème de base. Au lieu que l'implémentation de cette suggestion soit utilisée directement, le crochet de base sera invoqué avec cette implémentation comme première suggestion. Les fichiers du crochet de base seront inclus et les fonctions de prétraitement du crochet de base seront appelées en plus des fonctions de prétraitement de toute suggestion. Si une implémentation de hook_theme_suggestions_HOOK () (où HOOK est le crochet de base) change l'ordre des suggestions, une suggestion différente peut être utilisée à la place de cette suggestion. Si après hook_theme_suggestions_HOOK () cette suggestion reste la première suggestion, alors la fonction ou le modèle de cette suggestion sera utilisé pour générer la sortie rendue.
template
n'était pas nécessaire tant que le nom de fichier de mon fichier Twig correspondait à celui Twig le suggérait. Pour mon site, c'était webform-confirmation--application-form.html.twig
.
Avec les réglages ci-dessus, mon fichier Twig se chargeait correctement tout en utilisant toujours tous les crochets d'origine du module de formulaire Web.
L'autre problème était la page de confirmation mise en cache pour les utilisateurs anonymes. J'ai pu résoudre ce problème en utilisant \Drupal::service('page_cache_kill_switch')->trigger();
dans hook_preprocess_webform_confirmation
. Après avoir effacé le cache de Drupal, la page de confirmation ne serait plus jamais mise en cache.
function application_preprocess_webform_confirmation(array &$variables) {
\Drupal::service('page_cache_kill_switch')->trigger();
}
Cette même logique s'appliquera pour la mise à jour des modèles Twig dans d'autres modules également - il ne s'agit pas uniquement d'une solution de module de formulaire Web.
Il semble qu'il y ait deux problèmes différents ici:
(a) Chargement d'un modèle twig à partir d'un dossier arbitraire.
Pourriez-vous essayer de définir la propriété de thème path
et voir si cela permet de charger votre modèle twig?? Par exemple:
'webform_confirmation__application_form' => [
'template' => 'application-form-confirmation',
'base hook' => 'webform_confirmation'
'path' => \Drupal::moduleHandler()->getModule('application')->getPath() . '/templates',
],
(b) Modification des paramètres de cache pour une partie de vos variables de rendu.
Vous devez vérifier que les balises de cache remontent du tableau message
. Apparemment:
Vous devez rendre la variable de contenu pour vous assurer que ses balises de cache bouillonnent et finissent dans le cache de page.
comme mentionné ici => ( https://www.previousnext.com.au/blog/ensuring-drupal-8-block-cache-tags-bubble-up-page )
Donc, un point de départ serait d'essayer de rendre l'ensemble de la variable content
dans votre modèle twig, à condition que vous ayez dépassé (a)
Mise à jour: Vous pouvez également essayer d'appeler \Drupal::service(''page_cache_kill_switch'')->trigger();
afin d'éviter que le cache de page interne n'interfère avec la demande et le chargement de la page.
Un moyen simple de le faire dans un modèle twig utiliserait une approche similaire à ce module => https://github.com/stefanospetrakis/twig_killswitch_trigger
Bonne chance!
P.S .: Un exemple de code est également disponible ici => https://www.drupal.org/sandbox/stefanospetrakis/301161 , je peux le promouvoir en projet complet s'il y a un intérêt potentiel.
Vous pouvez ajouter l'instruction suivante à votre modèle Twig pour désactiver la mise en cache.
{{ {'#cache': {'max-age': 0}} }}