Drupal Modules

Heute morgen bin ich im IRC auf einen Bildblog-Artikel aufmerksam geworden, der mal wieder bestätigt, wie einfach es sich Journalisten in der heutigen schnellebigen Zeit machen, indem sie einfach Texte ungeprüft übernehmen.

Zugegeben, der zusätzliche Name ist nun kein Weltuntergang und ich beziehe mich auch gerne auf Wikipedia, ohne weitere Quellen zu Rate zu ziehen, aber ich bin ja auch kein Journalist. Und natürlich könnte man auch diskutieren, ob bei allen Details einer Nachricht eine intensive Recherche notwendig ist oder ob man sowas triviales wie einen solchen (langen) Namen ungeprüft übernehmen kann, aber wenn die Manipulation von solchen Kleinigkeiten schon so einfach ist und so weitreichend übernommen wird, wie ist es dann um wichtigere Einzelheiten bestellt?

Häufig ist es doch so, daß Artikel von Journalisten nur noch aus den Agenturmeldung zusammenkopiert werden. Dabei passieren dann auch noch Fehler, die man bei einmaligem Korrekturlesen hätte entdecken können und die zeigen, wie schlampig in der Branche inzwischen gearbeitet wird. Das ist schade, weil es bei der Presse um eine wichtige Säule unserer Demokratie geht. Aber kritischen Journalismus findet man heutzutage nur noch äußerst selten. Leider.

Uncategorized

4 thoughts on “Drupal Modules

  1. I agree with you, this would be the way out (and probably it would be enough for me not to have worked towards this tool) on an individual sysadmin level – However, for site-wide Debian packaging, I do think it is in place to drop the modules in /usr/share/drupal$ver – The packages depend on Drupal, and should not conflict with core modules (and if they did, that would be an important bug to fix!). Drupal's mechanism to have available-but-inactive modules is IMHO enough not to have the modules available in sites you don't want to use them.
    But, yes, that's the best way out for a local administrator to follow. I probably didn't even consider it because I installed Drupal without any prior knowledge or analysis, and just had its need grow on me 🙂

  2. I would like to object! 😉

    Drupal is multisite-able, so we should keep an eye on this as well. Putting additional modules into /usr/share/drupal*/modules would make them system-wide available – but for exact this purpose /etc/drupal/6/sites/all is meant.
    Having modules available but inactivated slows down the administer/sitebuilding/modules page and might confuse the user with module he/she doesn't need.
    Additionally users could be confused what modules belong to Drupal core and which not.

    Another point is that you might have 3rd party modules that you don't want users to be seen, for example unexperienced users shouldn't use webdav module or others. Having those in Drupals core modules directory would mean that those users can see the modules and activate them.

    Although I agree with you that 3rd party modules shouldn't conflict with core modules at all, there's always Murphy and his law teaching us that something like this might happen at any time. So, keeping 3rd party modules physically away from core modules is a safe and easy way to ensure the integrity and security of your Drupal installation.

Comments are closed.