wilmerlm11

No worries!
Glad to help!

I really tried in different ways to completely uninstall the plugin, but I guess deleting the old table is not part of the removal routine.
That’t why I did that manually and it worked like a charm.

Thanks for your response and kindness.
You and the support team have been really solicitous anyway.
5 stars.

Hi,

For those who are facing this problem…

SendInBlue support will only ask you to delete and reinstall the module.
It won’t work and you will still have to reintegrate it with SiB.

The root cause for this issue is that some previous installation left a table name “sib_model_contact” there, while a new installation, created “wp_sib_model_contact”.
With that, the code will see this “sib_model_contact” table and will try to rename it to “wp_sib_model_contact”. Since this table already exists, it will throw an error.

In order to fix it, just remove the former table.
DROP TABLE sib_model_contact;

Just check if any data migration is needed first.

Thank you! Just did! ??
I’ll let you know if this error comes up again.
Otherwise, thank you very much for your fast reply and even faster fix.

regards,
Wil

Hi @mbrsolution !
Thanks for the response. It’s PT-BR, but I think the issue is regardless of that.

Now that I figured out the root cause, I think the best title of this post would be:
“Description texts get stored in the Transactions database already translated”

So 2 problems I see on the transactions table mgmt:

1: Description field: when the plugin will store a new record, it generates a translated description, meaning if I don’t have a translation yet or if I decided to change it later, it won’t update the already stored information.
I think the best approach would be storing only the data and turn that in a full translated sentence only when displaying it to the user. (Allowing this formatting to be overridden as well)

2: Type and Status fields: the plugin stores this information as strings and builds the logic over this strings, so I cannot translate that.
Maybe the plugin could a enum ID or key to store in the database and translate the corresponding values when displaying that to the user.

Let me know if that makes sense.
Regards

I’ve just figured out why…

These formatted strings go (supposedly) translated to the database.
So if I add/change the translation afterwards, the previous records are not affected at all. OUCH!!

I don’t think this is the best approach though.
The plugin should only store the raw data in the DB and then get the translated output when displaying it to the user. Even better if we can override how the plugin formats it so we can have our custom display for that particular string.

Does it make sense?