Closed (won't fix)
Project:
Drupal.org security advisory coverage applications
Component:
module
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
8 May 2012 at 17:25 UTC
Updated:
30 Dec 2012 at 21:44 UTC
Project page:
http://drupal.org/sandbox/javek/1567510
git
git clone --recursive --branch master javek@git.drupal.org:sandbox/javek/1567510.git javek_uploader
This module allows you to embed a file upload form on your Drupal site as a block.
The form allows people to securely send you large files using the Public Buckets feature of a Javek client portal. In order to use the plugin, you must have a Javek subscription. You can sign up for Javek here: https://www.javek.com/sign_up.htm.
For information on Javek, please visit http://www.javek.com.
Drupal 7.x.
| Comment | File | Size | Author |
|---|
Comments
Comment #1
thyssimonis commentedFirst take a look at: PAReview
Read Drupal coding standards.
Comment #2
targoo commentedHi and welcome,
As installation and usage instructions are quite important, so please take a moment to create a README.txt that follows the guidelines for in-project documentation.
Here is some manual review :
1) only list files in the info file that contain classes or interfaces
2) you should create a .install file to delete all variables you are using (javek_uploader_subscription_url).
3) you are not running check_plain() on the '$subscription_name'. Not a big deal as the value is set up by trusted users but still..
See http://drupal.org/node/28984
We do really need more hands in the application queue and highly recommend to get a review bonus so we will(/can) come back to your application sooner :
See also #1410826: [META] Review bonus
Best,
Comment #3
javek commentedThank you both for the comments. I have switched to a 7.x-1.x branch and commited the following updates:
- added a README.txt file
- removed the files[] declaration from the .info file, as I am not declaring any classes or interfaces
- created a javek_uploader.install file to remove the "javek_uploader_subscription_url" var on uninstall
- added check_plain() to sanitize output of $subscription_name in javek_uploader_code(), called in javek_uploader_block_view()
I know you guys could use extra hands in the review process, I'll try to find some time to participate.
I'm not completely clear on branch naming - should I be calling this 7.x-1.0 instead of 7.x-1.x?
Comment #4
olmeta.david commentedHello,
You could add the package where the module has to be displayed too.
You delete the "javek_uploader_subscription_url" variable on uninstall step. This variable could be defined on the hook_install() I think.
Finally, you can put your JS code into a JS file and passes you Drupal parameter to JS ($subscription_name) with Drupal JS settings.
Regards,
Comment #5
javek commentedThank you for your suggestions. I don't think this module fits the criteria for adding package info as outlined here http://drupal.org/node/542202#package. Anybody else have opinions on whether or not a package should be declared in the .info file for this module? If so, which one?
I refactored the js to only load an external file.
Comment #6
olmeta.david commentedHi Javek,
It's true that the package information is optional, but, in my opinion, it's a pity to see a module in the "Other" package you know.
Maybe it could be attached to an existing package (I don't know if a "Javek" or "Uploader" package exist) ?
Comment #7
javek commentedHello olmeta.david,
I actually agree with you, "Other" is not a very useful designation. However, after reading http://groups.drupal.org/node/95984 and seeing that people's opinions are all over the place as far as how they would like package names to be used, I'm just going to throw my hands up and ignore the issue. Maybe I will add a package name with an update if some kind of clarity is found on this :)
Comment #8
misc commentedI really do not know if this module is big enough to give you access to do full projects on drupal.org (without the help text it is 107 lines of code - see http://groups.drupal.org/node/195848), but you could apply for promoting it as a single project.
With that said a short manual review:
drupal_add_js('//widgets.javek.com/widget.public-bucket.v1.min.js', should you not have http?Comment #9
javek commentedThank you for your response. Can anyone provide more detail, or a place to read more, on "promoting as a single project"? I currently don't have time to contribute to drupal itself, so I don't have any need or desire for full access at this time. All I am looking for is to host this module on drupal.org. Is this what promoting as a single project does? How do I do that?
About the url: a url "//www.example.com/index.html" is relative, in that it will adopt whatever protocol (http, https) the current page uses, just like "/index.html" will adopt the current domain.
This is a "company" account, in that I will only use it for company projects.
Comment #10
cvangysel commentedManual review of your module:
- The module is quite small-ish, however it seems like it adds a significant amount of functionality to warrant a new module.
- Your use of the t-function is a little abusive and just plain wrong in some cases.
You should try to create a single translatable string out of these. You are currently adding four extra strings that need to be translated to the system; you also don't really need to create a new paragraph so often. Links shouldn't be translatable, see here.
The following is even worse; you are actually adding partial sentences to the system:
You also don't need to wrap the description in another paragraph; that's more the responsibility of the theme. Your default value will return NULL if it is not set, might not be the best option.
Comment #11
cvangysel commentedComment #12
klausiClosing due to lack of activity. Feel free to reopen if you are still working on this application.