There seems to be issues when running drush updb on code that enables a feature which creates a taxonomy. We have a hook_update_N() which happens to enable a module which creates a new taxonomy via features. We are seeing the following error when we run drush updb:

$ drush updb

XXX_master  7191  Enable XXX module.

Do you wish to run all pending updates? (y/n): y
WD rules_config: ReflectionException: Class [error]
Drupal\smartling\Settings\SmartlingSettingsHandler does not exist in
ReflectionClass->__construct() (line 959 of
/mnt/www/xxxx/docroot/sites/all/modules/contrib/inject/vendor/symfony/dependency-injection/Symfony/Component/DependencyInjection/ContainerBuilder.php).
Class Drupal\smartling\Settings\SmartlingSettingsHandler does not [error]
exist

I looked at the stack trace and found that the error is generated by smartling.module: smartling_entity_update() which is called from features on call to taxonomy_vocabulary_save().

Basically the issue is that when running a drush command tha class loader doesn't seem to find that class. Upon investigation of the smartling module I noticed that there is a function called smartling_register() which registers the class path. This funtion gets called from smartling_init() on every page load. We did some debugging and it seems that drush does not trigger hook_init() and therefore the autoload paths are never registered.

For the moment I can't seem to find an appropriate hook to implement that will be called from drush so I can't provide a path. Maybe someone with more drush experience knows how to solve this issue. I will be happy to help with writting a patch and testing once we have a good idea how to fix this problem.

CommentFileSizeAuthor
#5 smartling-error_drush_update-2697205-5.patch594 bytespatpluspun
#4 smartling-error_drush_update-2697205-4.patch813 bytespatpluspun

Comments

cesarmiquel created an issue. See original summary.

  • Soul88 committed 5c21b83 on 7.x-2.x 
    Workaround for the case, when DB is being updated with drush and...
soul88’s picture

soul88
Primary language Ukrainian
Location Ukraine
commented

Hello, Cesar.

I refactored log entries so they were less scary and more useful: http://drupalcode.org/project/smartling.git/commit/265e0da + added a workaround mentioned above: http://drupalcode.org/project/smartling.git/commit/5c21b83

Unfortunately I didn't figure out how to make smartling.settings service available at this point.

I tried to implement hook_drush_init

function smartling_drush_init() {
  smartling_register();
}

but it didn't seem to help.

patpluspun’s picture

patpluspun commented
StatusFileSize
new smartling-error_drush_update-2697205-4.patch813 bytes

Hi everybody,

I think I've found a workaround to this situation. Since the Smartling settings object is not always available, I have replaced the check with a direct call to Drupal's variable_get() function to check if smartling_entity_update() should be run or not. This does not invoke the Smartling.settings object when entities are updated via hook_update().

Please review if this works for all cases, and consider rolling into a future release if necessary.

patpluspun’s picture

patpluspun commented
StatusFileSize
new smartling-error_drush_update-2697205-5.patch594 bytes

Whoops, the above patch has an extra unnecessary change. Please check this patch:

cesarmiquel’s picture

cesarmiquel commented

Hey guys! I was sure I had responded to Soul88 to thank him for his quick response and give him some feedback but it seems I never hit the Save button :/. Anyway, Soul88's solutions worked fine. He made a commit to the develop code (http://drupalcode.org/project/smartling.git/commit/5c21b83) which provides a work around. It only throws a warning saying "Presumably DIC or one of core Smartling services were not available at this point".

That fix will not work if the user needs the Smartling service during an update. For our case catching that exception was good enough. Thanks for the help.

soul88’s picture

soul88
Primary language Ukrainian
Location Ukraine
commented

Hi, patpluspun, thank you very much for your effort. Unfortunately this approach won't work. The reason for that is that we use DIC further in the code in some functions like: smartling_get_entity_processor() or smartling_translate_fields_configured(). And if we apply your patch the only thing that will change is that we'll get similar exception later in the hook.

cesarmiquel, as for you concern the answer is yes, we won't be able to execute our hook_entity_update(). But in my opinion it's more of inconvenience rather than something critical. Because what this action does is watching if some of the entities were changed (among the entities that are translatable with Smartling). And if such thing happened, we will reschedule this entity for upload to Smartling. So that we have up to date version of content.

What happens with current version of code is that if some translatable part of the entity (like the "title" or the "body" field that we translate, and not like the "published flag" that we do not translate) was automatically updated during hook_update_N - we will miss this update. And so content editor will have to re-schedule these items for upload manually.
I totally agree, that it is some sort of inconvenience, but it doesn't seem that this issue was critical to any of our clients in over a year now, when we introduced DIC to our code. If this changes I think we'll come up with a better plan to solve this issue.

soul88’s picture

soul88
Primary language Ukrainian
Location Ukraine
commented
Status: Active » Postponed

  • Soul88 committed 5c21b83 on 7.x-3.x 
    Workaround for the case, when DB is being updated with drush and...
cobadger’s picture

cobadger commented

We experienced this issue when enabling the smartling_translation_context module via database update.