[Imc-drupal-dev] instructions to set up a new drupal indy site

[David Gehrig]

Andrew -- thanks for your comments.  Indymedia's way of handling
hidden posts was the biggest challenge to getting this site set up.

As far as "feature" vs. "promoted to front page" -- if there's a distinction
here between the way dada worked and Drupal does, I haven't seen it.
Is there one?

As far as the difference between "unpublished" and "hidden," the only
distinction I know of between how dada handles it and Drupal does
(once you've made the modification) is that there's no option to hide a
comment so that it's not viewable even if you follow the "Hidden" link.

http://new.ucimc.org/?q=node/1

http://new.ucimc.org/?q=node/1&hidden=1

Note that there's a php block at the bottom of story pages that
automatically creates the "Hidden comments" link.

It's possible to set up a filter in a view to create a page of hidden
stories; you can take a look at http://new.ucimc.org/?q=hidden
to see it in action; this is a paging page with a list of unpublished
stories. But that doesn't get you to hidden comments, and that's
why I had to hack comment.module.

I should note that I didn't make the decision to hack comment.module
lightly.  The problem is, there isn't a hook in the right place in
comment.module to allow a hook_nodeapi call to intervene the way it
needs to if hidden comments are to be viewable.  Writing a whole new
module, however, just for comments, just so that three lines of code
can differ, struck me as taking the long way around.  I'm aware that I've
given myself a new task every time there's an upgrade, but it seems
a better solution than (a) not allowing hidden comments to be viewable, or
(b) postponing the switchover until I could come up with a comprehensive
new module that does everything comment.module does, despite
the fact that it would mostly parallel comment.module in functionality.

The general paradigm in drupal is to create new node types through
new modules, and I looked at that pretty hard before convincing myself
that it made more sense to use drupal's own data structures rather than
create a parallel structure beside it.

Thanks for the tip on robots; I hadn't looked into that and should do
that now.

@%<

On 10/3/06, Andrew McNaughton <andrew at scoop.co.nz> wrote:
>
> David Gehrig wrote:
> > We at UCIMC are just in the process of switching over to a Drupal site
> now,
> > where now = this week (I hope; we're also in the middle of a server
> move,
> > so things are a little hectic).
> >
> > What I'd like to do as soon as we're up and running is encapsulate it in
> a way
> > that makes it easy to deploy.  Setting up a Drupal site is not that
> > difficult, but
> > there's lots of configuration you have to do once the site is up and
> running
> > in order to get all the little bits working -- displaying a lit of
> > current local stories
> > in the side bar, that sort of thing.
> >
> > Here's a few useful things I've learned:
> >
> > The drupal counterpart to feature stories is "promoted to front page";
> > those stories are also the ones that get syndicated in your rss feed.
> > That means changing the defaults for stories so that they don't all
> > automatically get "promoted to front page", leaving your editorial
> > collective to decide which ones get promoted.
> >
> > The drupal equivalent of "hiding" posts and comments is to make
> > them "unpublished."  The problem is that this makes them invisible
> > to all users who aren't also editors.
> >
> This stuff is probably the single biggest decision to make in deciding
> how to implement an indy site using drupal. The drupal mechanisms you've
> identified above don't quite map to the way indymedia sites generally
> work. Maybe they're good enough for you, or maybe you want to implement
> these things differently, probably by tagging content with vocabulary
> terms specifically for this purpose.
>
> ie You'd have terms like 'hidden' and 'feature'. To make that work, you
> then need to customize some of the index display stuff so stories get
> listed amongst features when appropriate, and get left out of listings
> where appropriate.
>
> A major reason you might want to do that is that drupal stories that are
> unpublished are not viewable, which isn't really the way indymedia tends
> to work. OTOH, if you make 'hidden' stories viewable, you need to make
> sure that there's something to stop search robots indexing these pages.
> (eg a <meta robots="noindex"> tag in the html head section).
>
>
> > Following advice from ekes on this list, I made three simple changes to
> > the comment_render function of comment.module to allow for users
> > to see hidden comments.  I will be posting the documentation shortly
> > and will give a pointer to it here.  This is the only actual change in
> the
> > drupal code base I had to make, and it's three lines.  (Plus a few
> little
> > changes in the Drupal theme we're using, to be able to indicate to
> > the style sheet that it should shade hidden comments a certain way
> > when displaying them.)
> >
> > I've been asked to create, for comments and stories, a
> > third kind of hiding, for particularly noxious trolls and for those
> > countries whose hate speech laws aren't satisfied by the "unpublished"
> > status; I haven't done that because (a) don't know how yet, and (b)
> > I haven't yet found a solution that doesn't involve modifying the
> > database structure, something I'm very reluctant to do unless there's
> > global agreement -- this is the kind of change that could cause
> > incompatibility between IMC Drupal sites, so I'm more reluctant to
> > go there then I am to make tiny code patches (and I was pretty
> > reluctant to do that).
> >
> Writing a little code is to be expected, but it should be possible to
> avoid modifying the drupal core. Almost everything can be done by
> writing some custom modules, and you'll be really glad not to have to
> re-patch stuff every time a security update comes through for drupal.
>
> > We are using captchas for anonymous users posting comments.
> > We know there are good arguments to be made against captchas,
> > but our counterargument is that on our dada site we were pulling
> > out an average of 986 robospams a day for the better part of a
> > year now.
> >
> > http://www.ucimc.org/wiki/index.php/Drupal_Migration
> >
> Captchas are a necessity if you are going to allow content contributions
> from users who are not logged in. That's not just for indymedia sites,
> it's for pretty much any site these days.
>
>
> > On 10/2/06, ekes <ekes at aktivix.org> wrote:
> >
> >> Really we need to make a framework for a page that collects info about
> >> what sites have modified and installed so that others can learn from
> >> this... rather than making mods independently and not recording them in
> >> a central location.
> That sounds like a good idea. Something that went through and collected
> info on installed modules, and all the stuff in the settings area of the
> site would be really useful, and would encourage sharing info on how
> people are setting sites up. Sharing custom code stuff is also important
> though.
>
> Andrew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.indymedia.org/pipermail/imc-drupal-dev/attachments/20061003/22ba7033/attachment.htm