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

Dev
1

There have been multiple bug reports for the events plugin in the last two days that all seem to be type-casting issues with custom fields. The events plugin hasn’t been substantively updated in a few months.

The plugin.rb file casts event_start as an integer:

Topic.register_custom_field_type('event_start', :integer)

The error is being thrown here:

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

The error itself follows this format:

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

As far as I understand register_custom_field_type it should ensure that the custom_field always returns as the defined type (perhaps I’m misunderstanding it).

Looking at the has_custom_fields.rb concern, there have been a few changes in the past week that could have affected this, in particular

@eviltrout Any thoughts on this?

6 « J'aime »
2

In case this is indeed the bug causing problems, here I explain the consequences (it may make your site unusable):

3

This was a known bug with custom fields.

In very specific conditions, it would save the value multiple times, thus creating an Array, when you only want an Integer.

You can fix this by making sure there’s only 1 row per custom field in the database.

5 « J'aime »
4

Yes, it’s cropped up a few times in the past. This latest rash seems to coincide with recent work on the has_custom_fields.rb concern, so there may be something to review there.

This doesn’t fix it, but helps to address it if it arises:

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.

3 « J'aime »
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é.

2 « J'aime »