Télécharger Gravity Perks – Conditional Logic Dates v1.2.22

Quoi de neuf (Journal des modifications - Changelog) dans Gravity Perks – Conditional Logic Dates version 1.2.22

## 1.2.22 | 18 novembre 2024


• Correction d’un problème où la logique conditionnelle ne s’évaluait pas correctement si les entrées minute ne contenaient qu’un « 0 » au lieu de « 00 ».

## 1.2.21 | 27 août 2024


• Refactorisé pour utiliser ‘GP_Plugin’ comme classe PHP de base.

## 1.2.20 | 17 juillet 2024


• Correction d’un problème à cause duquel l’utilisation de dates antérieures au 1er janvier 1970 dans les calculs ne fonctionnait pas comme prévu car il s’agissait de l’époque Unix.

## 1.2.19 | 28 juin 2024


• Correction d’une régression à cause de laquelle certains formats de date ne fonctionnaient pas correctement.

## 1.2.18 | 26 juin 2024


• Correction d’un problème où les dates logiques conditionnelles ne fonctionnaient pas avec le [Field to Field Conditional Logic snippet](https://github.com/gravitywiz/snippet-library/blob/master/gravity-forms/gw-field-to-field-conditional-logic.php).

## 1.2.17


• Correction de l’avertissement PHP. (Crédit : [@navidabdi](https://github.com/navidabdi), [@sun](https://github.com/sun))

## 1.2.16


• Correction d’un problème où l’utilisation de « supérieur à » ou « inférieur à » pour comparer un champ de date avec une valeur vide ne fonctionnait plus. Bien que cela rétablisse cette fonctionnalité, veuillez la considérer comme obsolète. Utilisez « est » ou « n’est pas » pour confirmer si un champ Date a une valeur.
• Correction d’un problème à cause duquel les valeurs de règle vides pouvaient générer une erreur fatale lors de l’utilisation de l’opérateur supérieur à ou inférieur à.

## 1.2.15


• Correction d’un problème qui empêchait la vérification d’un champ Date vide via la logique conditionnelle de ne pas fonctionner comme prévu.

## 1.2.14


• Mise à jour des références restantes à ‘String.prototype.format()’ pour utiliser ‘String.prototype.gformFormat()’ car l’ancien est supprimé dans Gravity Forms 2.8.

## 1.2.13


• Ajout de la variable ‘%nextYear%’ pour permettre d’inclure l’année suivante dans un modificateur {today}. Exemple : ‘{today :first Monday of September %nextYear%}’

## 1.2.12


• Mise à jour des références à ‘String.prototype.format()’ pour utiliser ‘String.prototype.gformFormat()’ car l’ancien sera supprimé dans Gravity Forms 2.8.

## 1.2.11


• Ajout d’un nouveau [`gpcld_use_visitor_timezone`](https://gravitywiz.com/documentation/gpcld_use_visitor_timezone/) crochet de filtre.

## 1.2.10


• Correction d’un problème avec le clic volant de la logique conditionnelle.

## 1.2.9


• Correction d’un problème de performances lors de l’utilisation de nombreuses règles de logique conditionnelle basées sur la date.

## 1.2.8


• Correction des avertissements PHP 8.

## 1.2.7


• Correction d’avertissements potentiels de PHP 8.

## 1.2.6


• Ajout de traductions allemandes. Crédit : Florian Rinnhofer de sportunion.at

## 1.2.5


• Correction de l’avis généré lorsque la propriété d’ID de champ d’une règle n’était pas un ID de champ numérique.

## 1.2.4


• Correction d’un problème d’affichage d’opérateurs non valides pour les règles de logique conditionnelle en temps courant.
• Ajout de la prise en charge de la propriété ‘gpcldBaseDate’ pour prendre en charge notre nouveau [Auto Rule Groups](https://github.com/gravitywiz/snippet-library/blob/master/gp-conditional-logic-dates/gpcld-auto-rule-groups.php) extrait.

## 1.2.3


• Ajout de la prise en charge des conditions de traitement si les champs de date sont des entrées de date HTML5.

## 1.2.2


• Correction d’un problème à cause duquel les règles de date/heure de logique conditionnelle pour le bouton suivant n’étaient pas enregistrées de manière fiable.

## 1.2.1


• Mise à jour de la version minimale de WordPress de 3.4.2 à 5.3.0.

## 1.2


• Correction de notifications PHP potentielles si des champs ont été supprimés.
• Mise à jour du comportement par défaut du frontend pour utiliser le fuseau horaire du serveur plutôt que le fuseau horaire de l’appareil du visiteur, car la logique du backend a toujours été validée à l’aide du fuseau horaire du serveur.
• Correction d’une conversion incorrecte du fuseau horaire lors de l’utilisation du filtre JavaScript ‘gpcld_enable_utc_timezone.