2

I am creating a module that I would like to submit to the drupal.org repository. In the admin section of the module there are various input fields where the user is able to enter classes and ids for various elements that appear on specific nodes. It's basically a module that enables the user to do theming that would otherwise require custom code.

Since I'm not a Drupal rock-star in any way, and I have only worked in custom code and website specific modules, I have a very important question:

How do I store the classes/ids that the module's user will submit?

I guess that there are 3 options here:

  1. Store the classes/ids in a module-specific table in the database
  2. Store the classes/ids in the "Variable" table of the database
  3. Store the classes/ids in a file, in the module's directory

I have some pros/cons in mind about each case (e.g. I don't like the idea that a theming element would be stored in the database) but I would like your input too: which one of the methods above is the best and drupal-friendly? If I missed an option, please feel free to list it.

Improve this question

3 Answers 3

Reset to default
2

Saving the classes in a Drupal persistent variables would make sense if the module just need to save a few classes; if the module allows the user to save an undefined number of classes, then saving them in a custom database table is what I would do.

As far as I remember, modules are not allowed to write in their own directory. Saving in a file data that needs to be retrieved seems less performant than using the database, though, especially if the code needs to get specific data, and not all the saved data.

Improve this answer
3
  • Is there any rule of thumb for the number of classes that will not significantly undermine the performance? Also, do you happen to know if it is viable to give the user the option to choose between the variable table and a custom table? Do you happen to know if a module has already followed this method? Thx a lot for the reply.
    – F1234k
    Commented Jun 16, 2011 at 19:07
  • @F1234k If you are going to allow the users to save an (virtually) unlimited number of classes, then you should already consider using a custom database table. There isn't a thumb rule for the number of items that should be saved in a Drupal variable. For example, the User module saves in Drupal variables the content of the emails sent to the users in specific moments; the number of the messages saved is limited, but the content of those emails could be theoretically unlimited.
    – avpaderno ♦
    Commented Jun 16, 2011 at 19:20
  • If you limit the number of classes a user can set, then 10-12 classes would be fine to be saved in a Drupal variable. As far as I know, no module allows the user to set where the module values are saved. It would not make sense to let the users decide where to save the data, as it is the developer of the module who knows how the data will be used from the module; supposing the module needs to filter out the data, or make a join between those data and the data contained in a database table, how can the user know that?
    – avpaderno ♦
    Commented Jun 16, 2011 at 19:24
2

Of your three options, 2 would be a huge burden to a site in performance, and 3 will likely be a security issue. So I'd go with 1.

For reference, see the Block Class module.

Improve this answer
2
  • With mem cache #2 will give the best performance.
    – googletorp
    Commented Jun 16, 2011 at 19:00
  • Depends on the amount of such classes. Drupal has a huge memory footprint problem, due to all these large "load everything into a static cache" caches, like variables, schema, views. Every single added variable makes it a tiny bit larger, doesn't matter if memcached or not.
    – Berdir
    Commented Jun 17, 2011 at 9:27
1

I recommend option 1 too. Why shouldn't classes be in the database? That is node related context information, just like some comment related flags per node (show comments, allow comments, ..) for example.

You can store it in a separate table and reference it to the nid.

Then implement hook_entity_prepare_view() (better than hook_node_load(), because only invoked for nodes which are actually going to be displayed) and load those classes in a single query for all $entities if $type is node.

The variables table is loaded into memory on every request (completely), you should only store information there that you need frequently.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.