Still on Drupal 7? Security support for Drupal 7 ended on 5 January 2025. Please visit our Drupal 7 End of Life resources page to review all of your options.
I want to design an output filter that converts external URLs in all nodes to a format like "/exit.php?go=$URL", where exit.php is a PHP script that maintains statistics on what external URLs my visitors go to.
I looked at filter.module and it seems the HTML/PHP filters are all built in. I don't want to patch the filter.module though, if it can be avoided. How would I go about designing such a module? Where do I need to plug in?
Would anyone see a benefit in the creation of a module that automates the process of installing modules?
Every time i need to add a module I go about the the same process, and it seems like there is already a standard "packaging" that each module must adhere to, so why not automate this process with a module?
Almost all modules (that require more than drag-drop) include:
directory: /
db script: .mysql (sometimes a .pgsql --- this could be handled too)
module: .module
---
etc: some other stuff that I don't care about.
I'm running an intranet site on v4.4 which mainly uses Drupal's CMS capability. We've just been assigned a task to extend this site to a near full-blown intranet site. The first thing in order is to create a meeting room booking system. I was thinking of using a calendar's month-view as the main interface where users can see all the booking in a bird's eye view; then zoom in to a day where the actual booking is made.
Not sure if this belongs here, or in the "Core Development" forum, as it might involve some changes to core as well.
But we need some advanced group funvtionality added to drupal.
Here is a sketch of what we have in mind:
We need thousands of users (ok, at least more than 1000, but probably not more than 100 000 at the moment..)
These should be organized in one or more of a few hundered groups.
Some users are only memeber of a single group.
Some users are members of several groups.
The groups are somewhat hierarchical. IE. we might have
Organization A
Department X
Department Y
Workgroup 1
Workgroup 2
Department Z
Workgroup I
Organization B
List C
(...)
Some of the groups should be "self managed". IE, they should work more or less like the "og" module today. Some should be managed from a parent, some should only be managed by the administrator, some should allow other users to apply for memeberships, and some would require an invitation.
Example:
Manager of Org. A is allowed to add users to any of its department groups, but is not allowed to add new departments.
Dept. Y is allowed to add new workgroups.
Workgroup 2 is allowed to accept or decline new users who apply for this group
Org. B can add as many departments or workgroups as it wants