If I add a new ad slot to the bottom of the list, everything works OK. But if I put a new ad slot in the middle of the list, the new ad and all ads below it take their block settings (such as page visibility and region) from the ad that had previously been in the slot. For example, if I have 5 ads and add a new one in the second-to-last spot (which is now the 5th slot), the new ad slot will absorb the block settings of what had previously been in the 5th slot, and that existing ad (that had been in the 5th slot and is now in the 6th) will lose all of its settings.
The solution is that your module should allocate block settings based on the name of the ad slot, rather than the ad slots position in the list.
I'm creating almost a hundred slots to do targeted advertisements on different pages, and I would like to be able to manually alphabetize the list. Now, I can't, and I can't remove any obsolete ads from higher in the list, without screwing up the settings of everything below.
I'd be happy to send you $100 via PayPal if you think you can fix this bug. Thanks!
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | update.txt | 38.06 KB | dankohn |
| #6 | after.pdf | 248.97 KB | dankohn |
| #6 | before.pdf | 234.26 KB | dankohn |
| #3 | google_admanager.module.624284.patch | 4.51 KB | jaydub |
| #1 | google_admanager-block-delta.patch | 3.34 KB | toemaz |
Comments
Comment #1
toemaz commentedFind attached a patch to solve this issue. I haven't tested this patch at all, just wrote it out quickly. It has an upgrade path as well, since the block delta's will become the ad slot name instead of the index number.
Comment #2
toemaz commentedPatch needs review.
Comment #3
jaydub commentedAttached is my version of this patch. A few differences:
In google_admanager.install:
- Original patch update function doesn't appear to actually update {blocks} with new deltas. Patched to pull existing ad_slots and convert ad_slot name to a lowercased 32 char string to use as the new delta (the delta column in the {blocks} table is max 32 chars so for consistency the calculated delta from the ad slot name is truncated at 32 chars).
In goolge_admanager.module
- Original patch adds a form submit handler for the admin settings page. However the admin settings page uses system_settings_form() which means that a custom form handler is not called. As a result the google_admanager_admin_settings_form_submit() submit handler in the patch is not called. For simplicity sake I kept the system_settings_form() and added a hook_form_alter() to add an additional submit handler so that google_admanager_admin_settings_form_submit() is now called. I removed the variable_set() calls from the custom submit handler as they are now redundant given system_settings_form().
- As in the install function I've set the hook_block implementation to lowercase and truncate to 32 chars the block delta.
Comment #4
toemaz commentedApplied to the 6-1 branch. Needs testing.
Comment #5
toemaz commentedNo problem reports so far. Changing status as fixed.
Comment #6
dankohn commentedThe upgrade on this broke, as about a dozen of my ad blocks lost their description. It is not yet ready for production. I'm using views_block to track my ad blocks. Attached PDFs of my ad blocks before and after the upgrade.
If you're interested and available, I'm happy to give you an admin account on my development server, where you can test the upgrade against my 102 ad blocks. I'm also happy to let you take a look at my database, to try to figure out why some of the upgrades failed.
Thanks again for the great module.
Here are the results from drush update:
Comment #7
dankohn commentedThe upgrade on this broke, as about a dozen of my ad blocks lost their description. It is not yet ready for production. I'm using views_block to track my ad blocks. Attached PDFs of my ad blocks before and after the upgrade.
If you're interested and available, I'm happy to give you an admin account on my development server, where you can test the upgrade against my 102 ad blocks. I'm also happy to let you take a look at my database, to try to figure out why some of the upgrades failed.
Thanks again for the great module.
Attached are the results from drush update.
Comment #8
toemaz commentedThanks for the report.
It seems to fail because the delta, i.e. the ad slot name, is not unique for each block.
This is something I didn't anticipate and indeed an obvious bug. I will need to give it a thought how to solve this.
Comment #9
toemaz commented@dankohn can you explain the use case of having 2 or more blocks with the same ad slot? Or is it simply a typo which I expect is not the case.
Comment #10
dankohn commentedI believe it came from when I tried to change the order of my ad blocks in the past. I think I might also have some ad blocks that are active in different themes. You can see from my before PDF that in my active theme, I only have one version of each ad, however,
Once I got things working, I stopped messing with it, because I have a lot of ad blocks and did not want to have to re-enter all the visibility info. That's when I opened this bug report.
Comment #11
toemaz commentedThe solution might be to use
md5($ad_slot)for the delta of the ad_slot blocks, instead of the actual ad_slot name.This will also solve #694276: Database-Field to short for some adslot-names
If someone can cook up a patch, I'll be happy to commit it to the dev release.
Comment #12
dankohn commentedCould you please update the patch in #3 to work with the latest -dev release? After updating to fix the #351214 block caching bug, I now have about a dozen "dead" blocks that I cannot edit. When I remove them from the text list in the manager, I can no longer add them back.
Comment #13
jcisio commentedThat's because the patch in #3 has critical issue with long adslot name. A quick fix is this patch:
About upgrade path available, dankohn, could you just use the same principle for it and test if it works?
Comment #14
jcisio commentedI hope that this critical issue get fixed with some code I've just committed.
Comment #15
jcisio commentedAs the code is committed, I'm marking this as "fixed". Feel free to reopen if it is not fixed.