Good work on a very useful tool!

I'm really lazy so I want the option to download the module as the correctly named file...

Attached is a patch with my quick-n-dirty hack.

Thanks again!!

Comments

webchick’s picture

Hey thanks! This is a feature I really wanted to implement but never quite got around to it.

The only thing is I'm having some problems with the patch spitting out the *entire* page, not just the $output part. I can't figure out why it's doing this either; even when I specifically put a return $output; in that if ($edit['download']) { ... } block it still returns themed output. I will have a look again after I get some sleep. ;)

jsloan’s picture

Title: Download file Option » Download file Option fix
StatusFileSize
new1.02 KB

... the patch is incomplete; I must have broke it somehow. Here it is again.

jsloan’s picture

Title: Download file Option fix » one more change
StatusFileSize
new1.14 KB

... the check_plain() function on the output needs to be removed.

webchick’s picture

Title: one more change » Download file Option
Status: Needs review » Fixed

Great, thank you so much!! :D I committed a slightly modified version of this patch; it places a setting in the settings page for someone to select whether the checkbox should default to true or false (default is true). I was originally going to take out the option for textarea output altogether in favour of this, but Chris Johnson alerted me to the fact that people who develop remotely via SSH would like the convenience of being able to just copy/paste the code into their editor, as opposed to having to download a file, find it, open it, and then copy/paste the code in.

Some comments on code style. Not sure if you care, since as you said this was 'quick-n-dirty', but just figured I would point these out in case you didn't know or in case they help someone else. :)

1. Any text that will be displayed to the user (so things like #title, #description, etc.) should be enclosed in a t() function. This makes it so that translators can translate the user interface of your module.

2. Words in variable names should be separated_with_underscores, not runtogetherlikethis. It makes the code more readable, and also easier for non-native English speakers to be able to look up a word that they don't understand.

3. There were a few minor coding style things... Array elements should only be indented 2 spaces, concatenation should look like 'something' .'something else' (so the dot goes next to the thing you're adding, and there's a space between it and the main string), and you should generally use single quotes for strings unless a) there's an apostrophe in it or b) you need the variable interpolation that double-quotes affords you (like "hi, $name"). See http://drupal.org/node/318 for more info on coding standards.

Anyway, these are all very minor, nit-picky things but figured I would just mention them. Feel free to disregard. ;)

Thank you so much again, I think this feature will help out a lot of people. :D

jsloan’s picture

The code was just a quick cut-n-paste from php.net and it was submitted to suggest the feature. I'm glad that you incorporated it in your module. I too hold to these coding styles when writing code for Drupal but since this was a suggestion not a submission I did expect you to make the appropriate changes; I'll be more attentive next time.

webchick’s picture

Ah, cool. :) No problem, I thought I would point it out in case you weren't aware, which you are, so nevermind. ;) Thanks again!

Anonymous’s picture

Status: Fixed » Closed (fixed)