Opened 8 years ago

Last modified 7 years ago

#4002 assigned Feature/Enhancement Request

"MF/PL Member" drupal block for easy self-identification by members

Reported by: Owned by:
Priority: Medium Component: Outreach
Keywords: membership identification drupal Cc:
Sensitive: no


I was working with one of our members yesterday and an interesting idea cropped up. I thought I'd pass it along. What if our standard Drupal installations populated the footer with a block that said something like "May First/People Link Member" instead of or in addition to the default "Powered by Drupal" block?

As far as I know, we do not have any standardized way for MF/PL members to identify themselves as such. I think this would be a good addition to our Drupal installs.

What do others think?


Change History (16)

comment:1 Changed 8 years ago by

  • Keywords drupal added

This seems like a reasonable thing to me. Could it be set up as a module in the stock MF/PL drupal installation?

That way, the member would only need to enable that module to "opt in".

comment:2 Changed 8 years ago by

  • Summary changed from MF/PL Member Block to "MF/PL Member" drupal block for easy self-identification by members

comment:3 Changed 8 years ago by

In my view, it could be a module enabled by default, i.e. part of MF/PL Drupal core. If users want to remove or move the block, they could do so in the block interface as they would with the "powered by Drupal" block. Since by the very fact of installing Drupal via red, one must be a MF/PL member, I don't see any problem with this being in 'our' core installation, except, of course, for the ironic fact that I'm now arguing for a bigger footprint. ;)

comment:4 Changed 8 years ago by

I'm wondering why you think "opt-out" makes more sense than "opt-in". My instinct is to lean toward conscious choices about this sort of thing. Maybe it could be an initial decision made via the control panel when the webapp is set up? (though hmm, if we keep that around as state, that might get out of sync -- to be clean, it would probably need to be a bit of ephemeral data passed to the primary host at webapp setup time, and then discarded from the control panel, which (a) just be more confusing to the user, and (b) not be worth the effort).

If we do set it up as "opt-out", what happens to existing drupal web sites? Do they get this enabled retroactively?

comment:5 Changed 8 years ago by

As far as conscious choices go, any installation of anything makes certain decisions ephemeral, and since it's a default Drupal installation, this would simply be an obvious default setting, obvious in the sense that there would be a "I'm a MF/PL member" block. For any theming from that point forward, members could make the conscious decision to either keep that block, move it, or remove it.

I think if we set it up as "opt-out" the only change for current users is access to the module. My thinking is the full 'opt-in' only happens as a part of the installation process. So the install script enables the module and makes the necessary db_queries to enable the block in the footer. But for current users the module isn't enabled at all.

comment:6 Changed 8 years ago by

OK, that makes sense for me. Barring any objections from other people, it's now a SMOP. :P

This ticket is currently assigned to alfredo. Alfredo, are you going to work on this?

comment:7 Changed 8 years ago by

I think it's a great idea. It's a bit of work to create and maintain, but well worth it.

Alfredo is auto assigned any ticket coded as outreach, however, I think this is more of a tech issue. The first step would be to write one or several sql statements to create the block and enable it by default - this would have to be tested against Drupal 6 and Drupal 7. If someone wants to step forward with those sql statements - I would be happy to put it into red.


comment:8 Changed 8 years ago by

  • Owner changed from to

comment:9 Changed 8 years ago by

jamie -- why SQL statements? Why not a very simple drupal module instead as ross suggested?

The advantage of the drupal module is that it would be trivial for site admins to enable or disable it, and for members maintaining non-stock drupal instances to adopt it.

comment:10 Changed 8 years ago by

another advantage of a module is that a well-crafted module that sticks to documented interfaces seems less likely to cause a maintenance headache.

comment:11 Changed 8 years ago by

Oh maybe I misunderstood. I thought we would make a module, and have red make the necessary db modifications to enable it on install?

comment:12 Changed 8 years ago by

I think our goals are:

  • Easy for user to disable
  • Easy to maintain

I suggested using SQL statements rather than a module because I think it meets both goals more effectively.

For users - getting rid of it means going to the block admin page and deleting the block (which cleanly and completely removes everything) or disabling it.

If it's a module, you could go to the block admin page and disable the block, but the module is still being included. You could go to the admin modules area and disable the module, but it's still in your file system (or at least a symlink is still there).

For maintenance - yeah, a sql statement could easily break between Drupal versions - more easily than a module. On the other hand, it's one or at most two lines of code to maintain - unlike a module which will definitely be more than that.


comment:13 Changed 8 years ago by

I will accept your ease of implementation argument. I think you're right about that. The one thing it doesn't do is give existing members access to the block. SQL statement also limits our ability to offer any display other than a line of text. Maybe this isn't bad, but it then makes me think that we should add some html code somewhere on the MF/PL site that says, "Create your MF/PL Member block" with a number of styles (tiny icon, horizontal banner, etc.).

I'll write the sql queries, and we can move from there.

comment:14 Changed 8 years ago by

Good point on the html - I'm not sure how we'd display anything other than text without changing the input formats which seem pretty intrusive and hard to maintain.

But the sql approach does give members access to the block in a way that a module doesn't. If you add a simple block via SQL the user can click the edit button to edit it (unlike blocks provided via modules).

As for the code somewhere on the MFPL site: I wrote it about 3 years ago. Not sure if anyone has actually read it or done it.


comment:15 Changed 8 years ago by

Here are the sql statements for Drupal 6. I've included the full html input format so that the span class and styles can be specified. My guess is this may not be considered best practices, but it seems better to have some formatting than none at all. I'll have to review the D7 code to get the correct statements.

UPDATE blocks SET status = 0 WHERE module = "system" AND region = "footer";

INSERT INTO blocks (visibility, pages, custom, title, module, theme, status, weight, delta, cache, region) VALUES (0,'',0,'','block','garland',1,0,1,'','footer');

INSERT INTO boxes (body,info,format) VALUES ('<span class="mfpl-member" style="font-size:10px;color:#995e26">Member of <a href="" style="color:#995e26">May First/People Link</a></span>','MF/PL member block',2);

comment:16 Changed 7 years ago by

  • Owner changed from to
  • Status changed from new to assigned

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.