Le moulage de champ personnalisé est-il affecté par la mise à jour récente ?

Dev
1

Plusieurs rapports de bugs concernant le plugin événements ont été signalés au cours des deux derniers jours, et ils semblent tous être liés à des problèmes de cast de type avec des champs personnalisés. Le plugin événements n’a pas été substantiellement mis à jour depuis quelques mois.

Le fichier plugin.rb cast event_start comme un entier :

Topic.register_custom_field_type('event_start', :integer)

L’erreur est levée ici :

def has_event?
  self.custom_fields['event_start']&.nonzero?
end

L’erreur elle-même suit ce format :

NoMethodError (undefined method `nonzero?' for [1563127206, 1563127206]:Array)

À ma connaissance, register_custom_field_type devrait garantir que le champ personnalisé retourne toujours le type défini (peut-être que je le comprends mal).

En examinant le concern has_custom_fields.rb, plusieurs modifications ont été apportées au cours de la dernière semaine et pourraient avoir affecté cela, en particulier :

@eviltrout, des idées à ce sujet ?

2

Si c’est bien ce bug qui cause les problèmes, voici les conséquences que j’explique (cela peut rendre votre site inutilisable) :

3

Il s’agissait d’un bug connu lié aux champs personnalisés.

Dans des conditions très spécifiques, il enregistrait la valeur plusieurs fois, créant ainsi un tableau, alors que vous ne souhaitez qu’un entier.

Vous pouvez corriger cela en vous assurant qu’il n’y a qu’une seule ligne par champ personnalisé dans la base de données.

4

Oui, cela s’est produit à plusieurs reprises par le passé. Cette dernière vague semble coïncider avec les récents travaux sur le concern has_custom_fields.rb, il y a donc peut-être quelque chose à revoir de ce côté.

Cela ne le corrige pas, mais aide à le gérer s’il se produit :

5

Ma recommandation générale ici est que, en tant qu’auteur de plugin, vous devriez toujours ajouter des index dans une migration pour appliquer correctement la contrainte. En fait, la majorité des plugins que nous écrivons aujourd’hui évitent les champs personnalisés sauf en cas de besoin absolu et préfèrent utiliser des tables personnalisées, qui sont beaucoup plus faciles à comprendre.

Dans ce cas précis, vous voulez un index de :

create unique index idxStartEvent on topic_custom_fields(topic_id) where name = 'start_event'

Je ne suis pas sûr de ce qu’il y a d’autre à faire dans le noyau ici. Nous avons envisagé une refonte des champs personnalisés, mais nous sommes quelque peu inquiets à ce sujet. Une chose que j’envisage est simplement de supprimer la prise en charge des tableaux des champs personnalisés, car ils causent énormément de problèmes depuis des années.

6

Désolé de faire remonter ce sujet, mais l’une des conditions se produit lorsque vous utilisez un index de symbole, par exemple custom_fields[:hello], lors de la mise à jour d’une valeur existante. Au lieu de la mettre à jour, un autre champ est ajouté, ce qui donne un tableau. À mon avis, il s’agit de la seule condition.

Cela devrait très certainement corriger l’effet secondaire causé.