This patch does several things to the adsense module.

I prefer to use default drupal systems, things liek node forms, permissions etc should be preferred above any self-made sstem

Thus i disliked the way you made your own permission system: Why does uid 1 get special treatment? I know a lot of implementations where uid 1 is not used for administration, but rather an administration role.
Also, you should best not use negativisms for permissions: do not use "hide adsense", but rather "view adsense".

And last, this patch removes the disable feature: IMO that one makes very little sense: there are a lot of ways to disable an ad: disable the block, disable the permissions or even disable themodule. Why introduce a fourth way to disable it?

this patch solves all these issues :)

Keep in mind hat i like the module, but just try to make it a little better :)

CommentFileSizeAuthor
adsense_permissions.patch2.22 KBBèr Kessels

Comments

kbahey’s picture

Hello Ber

Thanks for the patch. I wanted to do roles at some point, and this patch was a catalyst in getting it done.

A few comments though:

I prefer to use default drupal systems, things liek node forms, permissions etc should be preferred above any self-made sstem

Thus i disliked the way you made your own permission system: Why does uid 1 get special treatment? I know a lot of implementations where uid 1 is not used for administration, but rather an administration role.

Agreed. Hard coding User ID 1 is not optimal. However, the motivation is genuine. I wanted to exclude the browsing from the admin from Google's page and ad unit views.

So, I went with the permission system.

Also, you should best not use negativisms for permissions: do not use "hide adsense", but rather "view adsense".

I also dont like negativism, or reverse logic. However, in this case I think it is justified. The reason is, I want this module to be simple to setup and works out of the box. Also, hide adsense in a role will work as expected. For example if you have paying subscribers, you set hide adsense and they do not see ads. If I use 'view adsense' and the user is in more than one role, then it does not work as expected, since 'view adsense' is already in authenticated users.

The use of hide adsense works. A user can be authenticated and also in a role that hides adsense at the same time, and it does what as expected.

Also, since Drupal grants all permissions to the site admin (user 1) by default, hide adsense has the pleasant side effect of not showing ads to the site admin automatically.

And last, this patch removes the disable feature: IMO that one makes very little sense: there are a lot of ways to disable an ad: disable the block, disable the permissions or even disable themodule. Why introduce a fourth way to disable it?

I need the disable feature. The reason is, when I copy my web sites' database to my test server, I want to be able to flip a switch, and see only placeholders so I can theme the site, play with it, ..etc., while it looks close to what the visitors see. Call it test mode if you want, but I need it.

Keep in mind hat i like the module, but just try to make it a little better :)

Bèr Kessels’s picture

a note about the uid 1:
Drupal -core- is sudo safe: meaning that I can createa drupal root account AND an administrators Role. that role wil then get all privilges.
This is, for most sties, by far the best preactice. Eventhough lazy people maintain their blog as uid 1 it is not as safe, and certainly not a verygood idea. Think of hazards like DrupalID MIDM attacks etc. On top f that, i run a lot of sites where we have five or lmore administrators. they should be able to disable :) the qd too, then.

So, please re-consider using roles instead of a uid to not show ads to: your UID 1 fnuctuion will certanily not be usegfull for me on any of my sites, at all.

kbahey’s picture

I don't rely on uid 1 anymore with last night's commit. It is role based as I explained, but uses 'hide adsense' instead of 'view adsense' for reasons I outlined above.

Anonymous’s picture