Closed (fixed)
Project:
Drupal.org security advisory coverage applications
Component:
module
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
30 Jan 2014 at 22:42 UTC
Updated:
18 Jun 2014 at 15:30 UTC
Jump to comment: Most recent
Comments
Comment #1
PA robot commentedWe are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and put yourself on the high priority list, then we will take a look at your project right away :-)
Also, you should get your friends, colleagues or other community members involved to review this application. Let them go through the review checklist and post a comment that sets this issue to "needs work" (they found some problems with the project) or "reviewed & tested by the community" (they found no major flaws).
I'm a robot and this is an automated message from Project Applications Scraper.
Comment #2
mehul.shah commentedThere are some warnings reported by automated review tools, did you already check them? See http://pareview.sh/pareview/httpgitdrupalorgsandboxmatthewmessmer2184823git
Comment #3
pijus commentedIn histogram.php -
Line 85 and 89: Functions should be called with no spaces between the function name and opening parentheses.
or die ("Cannot Initialize new GD image stream");or die ("Cannot Initialize new GD image stream");See the coding standard - https://drupal.org/coding-standards#functcall
Comment #4
matthewmessmer commented@mehul.shah
I saw those errors and they are a result of commenting out lines of code that before were resulting in unused variables. In the future, I am planning to use that code to extend some of the functionality. Does anyone have a suggestion on what is the best practice in this case?
If I uncomment the code, the same automated review tool shows different errors for unused variables.
When commented, some of the lines are over 80 characters long and this produces errors.
I suppose I could just make a different dev branch with that code and then remove it from the stable branch, is that the suggested course of action?
Comment #5
eft commentedMatthew,
Interesting looking module. This my first project review so bear that in mind :)
Hope this helps
Comment #6
mehul.shah commentedHi machostache,
yes you have to move that commented part to dev branch, and release only stable version for now.
Comment #7
webmorozov commentedHello, machostache!
Thanks for an awesome idea and module. It might be useful in some cases.
I have reviewed the module and I find some minor issues with it. But It works quite well and I can see possibilities on how it can be extended in the future.
I think the module can be promoted to full project, after small fixes:
1) histogram.php should be renamed to histogram.inc. php files by default executable, so it not safe.
2) Use theme_image in theme_histogram_formatter_default. Maybe somebody want to add additional class for your image or etc...
3) Why you work only with nodes? We should provide functions for all entities. For now you can describe those limitations and fix it in the future.
if ($instance['entity_type'] == 'node') {4) set_time_limit(50000) it's not great solution because we will have problems with performance. If it is a very difficult operation (need a lot of time) we should move it to the background (cron).
5) Please remove comments:
6) On uninstall process you should remove all variables that you created before:
foreach (variable_get('histogram_nodetypes', array()) as $type) {7) I found that png, gif files not work because you use only $img = imagecreatefromjpeg($source_file).
Could you handle other cases imagecreatefrompng(), imagecreatefromgif()?
Now about global approach:
I want to know why you use additional settings form admin/config/media/histogram/settings? I didn't get it.
I add field to that content type, so I want to render histogram. Why I should set double settings "Select nodetypes which should be enabled for histogram generation." here admin/config/media/histogram/settings.
In my opinion we didn't need create new field type. Why user should each time select "Histogram Type", "Force Single Channel Histogram" for each node? Are you realy need that fields?
I think you can just implement field formatter for standart image fields:
1) Move that settings to field formatter form
2) "Histogram Type", "Force Single Channel Histogram" it just VIEW, but not buisness logic.
3) We can just implement 2 different View Mode for that node and output "Stacked" or "Combined" histogram.
Other approach implement new image effect (image style effect) hook_image_effect_info:
1) Implement your settings in effect form
2) if you want you can create two image styles with different settings:
"Stacked"
"Combined"
"Image overlay (image + histogram)"
etc.
3) Image style will handle and store all files! You just implement effect
4) Apply that image style to standard image field. Image -> effect -> call your histogram_make_histogram with image as argument (see) -> your calculate histogram and override $image->resource.
As result you can implement histogram for all Entities, Multiple fields, etc. in more common drupal way.
Altogether a great module and it's working now.
This is just my thoughts on how it could be improved... If you want I can help you with it.
Best regards,
WebMorozov
Comment #8
matthewmessmer commented@webmorozov and everyone else
Thank you for your suggestions and comments. I have tried to fix all the outstanding issues with the module.
1) The file has been renamed to histogram.inc
2) I'm using theme_image now.
3) I agree that it work with all entity types, but I think this would require some more testing. For now, I have updated the documentation to note this limitation as you suggested.
4) The set_time_limit has been removed. I haven't found the script to take that much time to run, and it doesn't run every time the node is saved anyway.
5) I've removed all the unused variables.
6) The settings form at admin/config/media/histogram/settings was no longer serving any purpose so I removed it. So these variables are no longer set.
7) I changed this so that any .gif .jpeg .jpg or .png file should work now. I've updated the documentation to mention this.
One reason I created the module the way I did is that I wanted people to be able to specify default behavior for a particular content type (the field defaults for background color, histogram type) but be able to override this on a node by node basis. I'm not sure if this functionality could be preserved with the image style, could it?
Comment #9
matthewmessmer commentedComment #10
gbisht commentedHi,
For the 2nd point, you are calling theme function directly. For best practice instead of
theme_image($variables)you should usetheme('image', $variables).Comment #11
matthewmessmer commented@gulab.bisht
Thanks for the best practice tip. I've committed the change you suggested.
Comment #12
olivierg commentedChange is ok and the module works.
But when i generate a histo, i have 2 warnings:
Warning: Division by zero in _histogram_make_histogram() (line 115 of C:\wamp\www\neurones_import\sites\all\modules\histogram\histogram.inc).
Warning: Division by zero in _histogram_make_histogram() (line 116 of C:\wamp\www\neurones_import\sites\all\modules\histogram\histogram.inc).
The code in function _histogram_make_histogram() is too long, maybe can you create sub functions ?
Comment #13
deekayen commentedI'm approving this live in the mentor booth at DrupalCon.
Comment #14
klausiThanks for the review deekayen! Usually we only approve RTBC applications that have been verified by an additional pair of eyes.
And you should also post our nice welcome message from https://groups.drupal.org/node/184389#promote :
Thanks for your contribution, machostache!
deekayen updated your account so you can promote this to a full project and also create new projects as either a sandbox or a "full" project.
Here are some recommended readings to help with excellent maintainership:
You can find lots more contributors chatting on IRC in #drupal-contribute. So, come hang out and stay involved!
Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.
Thanks to the dedicated reviewer(s) as well.
Comment #15
deekayen commented@klausi, yes, I understand there should be more eyes and I counted myself as those extra eyes. I did a code review in person, gave him my commentary, promoted him, and stuffed the remaining issues into the project issue queue. I didn't see any reason to keep him waiting any longer.