Comparison of Node Limiter type modules

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!
public

There are a lot of modules which aim to limit the number of nodes that a user/role can create. Here's a brief roundup (please add more types or qualifications via comments).

create quota

  • Relies on rules
  • 6.x only
  • Claims to be extensible
  • Seems to require the implementer to write some code

Node limitnumber

  • 5.x only
  • Limits per content type per role

user_quota

  • Limits per user, per content type.
  • Users who are not limited on a content type can create as many of that type as they want.
  • Admin screen shows a history of each alteration of a user's quota and allows admins with "administer site configuration" to add (or subtract) from the quota.

nodefamily

  • 4.7, 5.x only
  • Creates relationships between nodes
  • Limits the number of nodes of a type that a user can create

node_limit

  • 6.x only
  • Allows for per-user, per-role, per-og, per-timeframe, per-timeinterval, per-taxonomyterm, etc limits (or any combination thereof)
  • Under active development

I have actually built yet another one of these which has limits per user per content type. If there is no limit for a uid/type then it allows the content to be created. If folks agree this is a not a duplicate of the existing nodes I'll contribute it and document it's difference from the existing solutions ;)

Is your UI significantly

dwees's picture
dwees - Tue, 2008-11-11 03:07

Is your UI significantly different than the Node Limitnumber module? It seems like you provide similar functionality, except that instead of limiting per role, you limit per user. How difficult would it be to extend the Node limitnumber module so that you could choose either role or user (or both) as options for limiting node creation?

This way we would be cutting down on duplication of modules.


pro/con

greggles's picture
greggles - Tue, 2008-11-11 04:43

A pro/con of nearly all of these is that they are largely unmaintained, so if I actively contribute patches it could be easy to vastly alter the module.

A real con of all but the create_quota is a serious deviation from coding standards/style which makes it painful to work with them :/

It looks like node_limitnumber provides this per-user-per-content-type facility at least somewhat (the install file shows support for users or roles, but none of the code seems to actually use it).

--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book


I know your pain with the

dwees's picture
dwees - Tue, 2008-11-11 05:17

I know your pain with the coding standards. Maybe we can specify a general procedure to follow then when taking over an unmaintained module.

  1. Apply to take over maintenance of the module.
  2. Run the module in question through the coder module.
  3. Make sure that every function is namespaced appropriately (with the module name as the prefix to all of the function names in the module).
  4. Now we can start adding functionality as desired.

If you are planning on creating a module anyway, or have built a module, it should be possible to take over/co-maintain one of these projects and steer it in the direction of your desired functionality.

That being said, I know of a few modules which are 'partially maintained' which means that if patches are supplied, the maintainer checks the patch and commits it to the project. I think most of my projects fall in this category.


True enough. Step 1 of any

dman@drupal.org's picture
dman@drupal.org - Fri, 2008-11-21 11:55

True enough.
Step 1 of any code change should be a non-invasive patch to bring it up to coder.module standards.
They are just no fun to touch/patch otherwise.

Step 2 is PHP strict compliance.

Then functional fixes or additions.

Then test cases :-)

... not that I always follow that myself, but that's how it SHOULD go if there was a responsive 'maintainer' or you'd been granted CVS.


resolution

greggles's picture
greggles - Tue, 2008-12-16 02:05

In the end I did post my slightly duplicate module (but it isn't a true duplicate since it is per user and per content type limits while these are mostly per role).

However, I got Doug Muth to let me put my project into the old user quota project. So, the net impact on the world is slightly positive
* -1: new duplicate module created
* +1: old abandoned module removed
* +.5: documentation clarifying all these duplicates created

--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book


Pros

andypost@drupal.org's picture
andypost@drupal.org - Tue, 2008-12-16 09:34

It's good idea to extend current "user_quota" module by implementing per user + per role + per content type

Cases (node type)
1) User profile node (only one)
2) User places (better to limit per role)
3) Photoalbums - limit per role + per user (for example if user gains enoght "userpoints")


There's also

joachim's picture
joachim - Tue, 2009-01-27 08:44

There's also http://drupal.org/project/quota_by_role
Not tried it, but according to the project page this allows quotas to be set per day.


NodeLimit: The final solution?

Rosamunda's picture
Rosamunda - Wed, 2009-03-25 03:52

There is a brand new addition to this, that maybe will be the final solution to all this mess: NodeLimit. It will made available to limit nodes, nodes per group, and even the creation of users.
It´s in dev version, and it´s facing a architectural challenge that needs help. Maybe someone here could help it out, as I´m not a programmer, my help is very limited.
Regards,
Rosamunda