Enabling module using drush causes WSOD for admin/config/people/accounts. Drush pm-disable module restores admin/config/people/accounts to normal operation.

Tried drush up / updb and drush cc. Still no joy. Running i18n multi-language and various translation modules.

I'd really like to be able to use this module.

Comments

iva2k’s picture

iva2k commented
Status: Active » Postponed (maintainer needs more info)

Please post here:
1. confirm if this problem happens (or not) if enabled on the modules page
2. What entries are found in the dblog when WSOD happens (you may need to enable error logging to db)
[UPDATE] 3. do you have any modules at older version than module's page recommended?

Anonymous’s picture

Anonymous (not verified) commented

Hi iva2k:

First off, thanks for the quick response! I really would love to get access to this module as it sounds like the perfect solution to getting control of the login form.

The 7.19 core site modules are all up to date. I routinely perform "drush up" and "drush updb". Many modules are in dev release and there are hundred(s) (lost count) of them.

Tried enabling from the /modules page and looks like it goes straight to trying to update translations. This is a problem with my site and is hanging. Not sure if the action is specific to your module? I don't recall any other modules initiating a translation update on enable? I usually use drush when updating languages and did not notice the hang condition before, could be related?

Is there a specific reason your module initiates translation update on enable?

Anonymous’s picture

Anonymous (not verified) commented

1. confirm if this problem happens (or not) if enabled on the modules page

Same treatment, WSOD at admin/config/people/accounts. I note that as soon as the module is enabled from the modules page a batch process begins to update translations. I have some sort of site bug with batch processing. Can't figure it out. Started when I migrated to new server and problem likely has something to do with new setup (.htaccess, my.cnf, God.Only.Knows!).

In any case, I wonder if this has something to do with it? I usually install and enable modules using drush, updates etc also with drush, hence the batch processing bug is not a big deal, until now.

2. What entries are found in the dblog when WSOD happens (you may need to enable error logging to db)

Absolutely nothing unusual. Tried every enable/disable, visit admin/config/people/accounts scenario I could think of, standard warnings, etc in dblog that had nothing to do with this module, entries that would occur whether it was enabled/disabled/not installed.

[UPDATE] 3. do you have any modules at older version than module's page recommended?

No, everything (very) up to date.

iva2k’s picture

iva2k commented
Status: Postponed (maintainer needs more info) » Active

Thanks for additional info. I think I know what needs to be done now.

I need to review and update the translation code as the API has changed for variables translation. I did this recently for Site Disclaimer. Will need to find time to sit down and transfer new code patterns into iTweak Login.

Anonymous’s picture

Anonymous (not verified) commented

I disabled variables translation module, then enabled itweak login module. Translation updates proceeded and I am now able to use the module. Module still working after re-enabling variable translation module.

iva2k’s picture

iva2k commented
Status: Active » Fixed

I updated the 7.x-1.x-dev code to operate with new variable_translation module API.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.