I've noticed now with a couple of my clients websites that when I update to a new version of the MailChimp module, the block seems to partially reset or change itself. By reset, I mean that the title in the block often changes. In this update, the block title has changed from 'Newsletter:' to 'Sign up for Newsletter:' - this could have been a title I used when I originally created the block but changed afterwards.

Now with this recent update (hasn't occurred before), the block is being displayed in the set region even though when I look at the block admin page, the block is no longer active, if I enable the block again to that region, I now see two of the newsletter blocks on the page.

Does anyone know why this is happening? Is this an update issue with the database or a caching issue? I have cleared the site cache but it doesn't seem to make any difference. Or has something changed in the recent update that I've overlooked?

The only way I have managed to resolve these anomalies in the past updates is to remove the block and start again but now i'm not sure if I can do that if Drupal thinks the block is already disabled. Is anyone else having problems like this when they update?

Comments

areikiera’s picture

areikiera commented

Updating affected all my existing mailchimp blocks. They all appeared to be disabled, even though I could see them on my site, the titles were changed as well, and a partial string from either the title or the description was being appended to the beginning of the description in the block. No idea what happened, and unfortunately am unable to troubleshoot or document it better today (launching the site i had the problem with). Just wanted to add I experienced similar problems.

Had to revert to 7.x-2.4.

munkyonline’s picture

munkyonline commented

The title is set on line 461 of the mailchimp_lists module:
'#markup' => t('Sign up for %title', array('%title' => check_plain($list->label))),

You can use hook_form_alter in a custom module to override this title in the mailchimp freeform block:

function MODULENAME_form_alter(&$form, &$form_state, $form_id) {
	switch ($form_id)  {
		case 'YOUR_FORM_ID':
			// Use dsm($form) here to see what you can change if you have the devel module installed
			$form['mailchimp_lists']['mailchimp_SITENAME']['title']['#markup'] = 'YOUR TITLE MARKUP';
		break;
	}
}

Get the form ID by viewing the source code of the <form> (replace hyphens with underscores).

munkyonline’s picture

munkyonline commented

In regards to the duplicated block issue, in the database I can see that I have a block for module 'mailchimp_lists' which has been assigned to a region, delta is set to 1 and status is set to 1. This is the original block but is not visible on the block admin list even though I can see it when I view the page.

I can also see another block for module 'mailchimp_lists' which has not been assigned to a region and has delta set to 2, status is set to 0. I do not know what this is for - I have only one active freeform mailchimp block. I may have created more than one when I set the module up - it appears this one hasnt been removed from the table when I deleted it?

The new duplicated block which appeared after the update from 7.x-2.4 to 7.x-2.5 is also for module 'mailchimp_lists' but the delta is not numerical, the delta for this block is the Drupal sitename in lowercase and status is set to 0. This is the block which is displayed on the block admin list.

bvanmeurs’s picture

bvanmeurs commented
Priority: Normal » Critical

I confirm this issue and want to set the priority to critical. The block_info hook of the mailchimp_lists module was changed, so that the delta was previously the list id (numerical) and now the list 'machine' name (alphabetical). The previous blocks (keyed by id) will still be around and will continue to function but they won't get an 'info' message assigned to them any more. That's why they can't be found in the block list, and are only reachable by directly editing them via url.

The new blocks are visible in the block list (as disabled). This would cause confusion in practice.

It is not advisable to change the delta of created blocks between an update. But if it is really necessary (why would it be?), then the old style should still be supported by block_info. I is not a good idea to do this update because the update protocol was not implemented well.

This was introduced because of the following patch: http://drupal.org/node/1369472. I posted a reference to this issue there and am hoping for a fix.

antipex’s picture

antipex commented
Status: Active » Fixed

Checked in a fix for this which updates the block deltas upon updating.

bvanmeurs’s picture

bvanmeurs commented

Thanks!

Status: Fixed » Closed (fixed)

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

bvanmeurs’s picture

bvanmeurs commented
Status: Closed (fixed) » Active

I've finally had time to review the fix. I still am unable to update, because other modules depend on the delta. Furthermore, the fix didn't work. The block settings were not copied for my website, even after clearing the cache. I am not sure why but am not going to spend more time on it.

I don't think it's a good idea to change the block delta's within a minor version change. This change should have been kept for the next major version. Please learn from this.

I guess I am forced to using 7.x-2.4 for the rest of this module's life cycle.

Kind regards,
Bas

levelos’s picture

levelos commented
Status: Active » Closed (fixed)

Bas - We appreciate your opinion but respectfully disagree. For that matter, it's not clear what you mean by a major version change. Starting a new development branch to change block deltas is not an accetpable solution. Simply replacing your blocks, as a worse case scenario, is fairly trivial. There are also nearly 10000 people happily using this module and only a fraction have had any issues at all. I don't see why you are reopening this ticket without a clearly stated issue, proposed solution, etc. Suggesting that we learn from this experience is not helpful and rather condescending. I would encourage you to contact me directly if you'd like to discuss this further.

bvanmeurs’s picture

bvanmeurs commented

Levelos, what I said was that a minor version change shouldn't break previous implementations whereas a major version change (7.x-3.0) could. That this change has broken my previous implementations is a fact, as blocks appeared double and not with the correct stylesheets applied (class changes). Fixing it is not easily done in an update script. I think that being a module maintainer also brings some responsibility to take into regard these existing implementations. Especially as developers might be using a single Drupal core codebase for multiple websites this is an annoying issue. I am very thankful for your work on this module and am one of the 10000 people happily using it. But the fact that this fix has come after the original change means that no one thought about the consequences of existing block configurations in the first place. Now a semi-fix has been applied that doesn't work in practice, and because the changes were released it is even more problematic to revert the change.

I hope that you take this into regard the next time someone makes a suggestion and perhaps move the idea on the roadmap to the next major branch. No offense meant, but if all remarks were positive they would be pretty useless.