- 🇨🇦Canada mandclu
The configuration for that vocabulary is provided by the module, and should have been imported when the module was installed. Did you encounter any errors during install?
Actually, looking at the module's code I believe I see the problem. For the import of the configuration to work as expected the taxonomy module needs to be installed, but it isn't listed as a requirement in alerts.info.yml. I will update to fix that, but that won't help a site where this module is already installed.
If you're still having this problem I would suggest manually importing the taxonomy.vocabulary.alert_severity.yml configuration file.
- Status changed to Fixed
about 1 year ago 7:15pm 18 April 2024 Automatically closed - issue fixed for 2 weeks with no activity.
- First commit to issue fork.
- Merge request !3Solution for Error: Call to a member function getString() → (Open) created by shyam-sawhney
- 🇦🇹Austria shyam-sawhney
Hello @mandclu
It's a very nice module thanks for it. But this issue is not related to import.
install YML are working perfectly and creating Taxonomy and field once we are installing it. It's a issue in fetch. The field_color is not considering the default untill you hit a save on individual Taxonomy.
error is in alerts.module
a possible easy fix is.
$colors = [];
foreach ($terms as $tid => $term) {
if($term) {
if( $term->get('field_color')->getValue()){
$color = $term->field_color->first()->getString();
$colors[$tid] = '.alert-severity-' . $tid . ' { background: ' . $color . '; }';
}
}
}created a MR
- 🇦🇺Australia nigelcunningham Geelong
Oops. I accidentally replaced the issue summary. I couldn't find an archived version so I've put back a minimal summary. Apologies!
What I was going to add...:
I've come across this issue after installing the module on my dev environment (without problems), running a config export and committing it, then downloading a DB dump from production and doing a config import.
The vocab and the terms are created but the error is triggered because the colour field doesn't initially exist. After a couple of additional config import runs, the field exists and the error goes away but all the colours are configured as black.
It looks like the issue is triggered by not running the install hook, so you'd need to do a
drush deploy
rather than just a config import. - 🇦🇺Australia nigelcunningham Geelong
I've found that the error happens because the color field value is empty, but I'm not yet sure why the colour doesn't get successfully saved. I've spent long enough on this, and will just add a deploy hook to my own module to set the values so I can get on with things. Sorry for not supplying a proper solution (I have a large database so reloading it to retest takes a while).
- 🇦🇺Australia nigelcunningham Geelong
There's a patch implementing a deploy hook that works for me - I can download and restore a database backup, run drush deploy and see the Alerts module installed via config and then the colour fields fixed via the deploy hook. I don't propose this as a long term solution - it seems more likely that the data structure given when creating the terms in the install hook needs some tweaking.