Breaks admin theme

I can confirm; when i enable the B/M module.. i lose my admin theme.. very odd.

just tried lasted -dev and it seems to fix the issue.

nope, my bad.. not fixed in latest dev.

changing priority

I have run several tests with this issue and I can confirm it is clearly when Entity Translation and Backup and Migrate are used together. No other combination presents this symptom. It happens in a variety of circumstances but typically when you save settings in the admin UI whether it be a content type, a field, the modules page etc... It's fairly random too which makes it pretty elusive.

deleted since already mentioned xpost above

Been a while, but is this still an issue?

I have run into this problem also so it's still exists.

I noticed that the static (admin) theme variable gets lost when a call to drupal_theme_initialize() is made from the l() function. Based on comments in the l() function I found a workaround. In a custom module add this line to an implementation of hook_init

variable_set('theme_link', false);

But do this only if you don't want to use a theme function for outputting links.

I found this bug (possibly same). If open admin/structure/taxonomy and edit any vocabulary, admin theme is switched to site theme. But, if you change in backup_migrate/includes/destinations.inc:73

'description' => t('Save the backup files to a bucket on your !link.', array('!link' => l(t('Amazon S3 account'), 'http://aws.amazon.com/s3/'))),

to

'description' => t('Save the backup files to a bucket on your <a href="@link">Amazon S3 account</a>.', array('@link' => 'http://aws.amazon.com/s3/')),

then problem is gone. Patch attached.

After deep debugging I also think that the Amazon link on destinations.inc:73 is the problem.

Patch provided by @Andrew #8 fixes the issue, at least for me.

Thank you!

Well, problem remains in other drupal pages, like drupal_commerce (when saving product type)

Dunno if it's related to the same bug of this module

Would it be possible to upgrade to the 7.x-3.2 version released September 27, 2017, to see if this resolves the issue? The 2.x branch hasn't received a code update in 4 years, but the 3.x branch is being maintained.

@DamienMcKenna has proposed that the 7.x-2.x branch be marked as unsupported once the upgrade path to 7.x-3.x is verified. See this issue: Verify 7.x-2.x -to- 7.x-3.x upgrade path, mark 7.x-2.x as unsupported

Correcting to "postponed" and updating version since the bug may or may not exist in the latest code.

Closing after more than two weeks with no activity.