Closed (fixed)
Project:
Drupal.org security advisory coverage applications
Component:
module
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
14 Jul 2013 at 00:29 UTC
Updated:
18 Sep 2013 at 23:51 UTC
The module implements the unveil.js javascript libarary, which is a library for lazyloading images. The module is very simple, and i hope to add more features as they are needed.
Project link:
https://drupal.org/sandbox/lorique/2019407
Git link:
git clone --branch 7.x-1.x http://git.drupal.org/sandbox/lorique/2019407.git unveil
Comments
Comment #1
sprice commentedThe nice PAReview.sh script. A few things to fix. But, there is a larger problem with the review process for now.
The Project application checklist states
Right now, the module is at 92 lines. I'm marking this as "needs work" because I'm new to reviewing projects, but it seems like the guidelines want more code in order to be able to grant this permission.
---
Below is from the PAReview.sh script.
Results: http://ventral.org/pareview/httpgitdrupalorgsandboxlorique2019407git
Here are the results for now:
--------------------------------------------------------------------------------
FOUND 0 ERROR(S) AND 2 WARNING(S) AFFECTING 2 LINE(S)
--------------------------------------------------------------------------------
4 | WARNING | Line exceeds 80 characters; contains 190 characters
7 | WARNING | Line exceeds 80 characters; contains 278 characters
--------------------------------------------------------------------------------
Comment #2
lorique commented@sprice
Thank you for reviewing my module. This is my first module, so im learning too. I hope we can learn this process together :)
I have made some changes, and now that i know that the tool exists, i have used it to make sure my module has no errors. As for the 150 lines, i have added some functionality, which i was adding anyway, to the module which means the module now stands at 167 lines.
Comment #3
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 #4
feolius commentedHi!
I'm not an expert in reviewing, but what I found is that you ask user to copy unveil library to sites/all/liibraries folder (please fix double "i" symbol in your readme file) which is usually used by Libraries API module. So, it would be better to use this module in your case, because it provides a proper way to include external libraries like Unveil.js. So, you could replace this codeblock
by something using libraries_get_path('library_name') function. Another thing, are you sure that this piece of javascript code cannot be executed from the file? You should try to implement it in separate file using Drupal behaviors concept (see info about it here). If this is impossible, then you can use inline js code.
It would be better to use drupal_static() function instead of static construction.
Thanks. Good luck!
Comment #5
lorique commented@feolius
Thank you for your review.
I like the idea of using the libraries module for this, and its a solid improvement to the module. So I've implemented it, and added a dependency to the module.
Using drupal_static makes sense, even if i don't see any other modules ever needing to check the static without calling the method in which the static is currently used. The change is minor, so i implemented it anyway because i see the point you make.
As for the JS:
Its currently implemented the way unveil.js specifies itself. Creating a behavior for it would be unnessary, although i understand why drupal prefers behaviors. The issue is that it would simply add more lines of code to the module, without actually adding any benefit to the implementation. In my mind it would simply over complicate the module.
I am moving this issue back into needs review.
Comment #6
feolius commentedThanks for your response.
One thing, if you use drupal_static function you nee to insert & symbol before it (i.e. &drupal_static('unveil_js_added')) to get variable by reference.
It would be better to remove info about location of the library, because some of users will use 'all' folder instead of domain. Btw, you could implement hook_requirements() and check if library exists here. It would be proper way, I think.
As for js: according to the description of drupal_add_js() function: "This should only be used for JavaScript that cannot be executed from a file." Behaviors allow other modules to override or extend your js code, and this will add some flexibility to your module. It is not big deal, of course. But I'd say that in most cases creating behavior is unnecessary, but nevertheless people use it there.
Thanks.
Comment #7
feolius commentedComment #8
lorique commented@feolius
I had a talk with a good friend of mine, who set me streight on the JS. He made a very good point, which is "what if views uses an ajax pager, how will that work with your implementation". I told him that he was a moron but that he had a point dammit. I will add a js file with a drupal behavior for the unveiling.
As for the & in front of drupal_static, i dont mind doing it, but can you tell me why its required?
I had some bad experiences with hook_requirements in the past, which makes me nervous about implementing it. That said, I will consider it.
Comment #9
lorique commentedSo i made som adjustments.
The js is now a Drupal behavior, with a js file to follow. Very simple, and very effective. I tested with a view using ajax pager, and it works as intended.
As for using hook_requirements, im not going to. I don't like the hook, and i think it causes more trouble than its worth.
Comment #10
lorique commentedComment #11
swim commentedHey Lorique,
Just a suggestion but I'd look at adding the t function to your forms to allow multilingual support.
Example,
Your also storing a lot of variables but I don't see any unveil.install to allow for uninstalling them upon module removal. This would be implemented using hook_uninstall.
As such;
Cheers,
Comment #12
swim commentedUpdated status to needs work.
Comment #13
lorique commented@hapax legomenon
I implemented both suggestions. Thank you for your review.
Comment #14
gauravjeet commentedHi,
I suggest you to remove ventral.org bug :
Some bugs:
file - unveil.module
-- line 109
There is no need to specify
'function' => 'theme_unveil_image',as drupal theme engine will identify this function itself, if neitherfunctionortemplateis given-- line 153
I installed the module, downloaded unveil library, enabled checkbox in admin/config/development/performance and when i opened a node i found this error message :
Unveil js library missing. It should be located at %location_1% or %location_2%The variables in t() and its second parameter array should be same, found different variable names - %location_1%, %location_2% and %location%_1 , %location%_2
Comment #15
gauravjeet commented..
Changing status to needs work
Comment #16
lorique commented@gauravjeet_singh
Thank you for your review! I'm embarrassed to say that it was sloppy work of me not to add the docblock and to miss that the variable names were off.
As to the theme function, i know its not strictly required, but i prefer to be as explicit as possible, because it makes it easier to read the code for inexperienced people.
Comment #17
feolius commentedThanks for implementing proper js.
But I'm really interesting which problems does hook_requirements cause? it seems logical to check requirements in hook_requirements. Your module needs unveil library to be installed, right? So, what is the reason to not check if library missing or not in hook requirements?
Thanks.
Comment #18
lorique commented@feolius
I have several objections to hook_requirements. But first, the issue i had with it was an implementation of hook requirements which required a piece of javascript, then read that js to find out what version of the js it was and then objected in such a way that made it impossible for me to run update hooks. This ofc was a wrongfully implemented hook, but it showed me just how fragile, and disasterous hook_requirements can be.
The hook is executed every load, like hook_init which in itself is bad for your performance because it should only be run when you actually need the code. In this case, i only want it to check if the code is there when i actually need the js library - which is every time theme image is called. I personally never use hook_init, and never will unless all else fails. The same goes for hook requirements, simply because there are other more graceful ways of handling it - the most graceful being that browser consoles log it as an error and whenever there is a missing js. Incidently, i had a discussion at a BOF in drupalcon London, with some core developers, and asked why it was that drupal_add_js does not watchdog log missing files added to add_js and add_css. I was enlightened by the group, that access logs on a webserver are usually set up so they log 404's whenver something in missing. Hook requirements, then, becomes superfluous (Word of the day: http://dictionary.reference.com/browse/superfluous) in 2 ways and does nothing more than help ease debugging. That documentation is provided with the module (in terms of the installation instructions) and i can see no way of making them more clear and no way of making hook requirements make it more clear.
In conclusion, i would say that hook_requirements makes sense for something like the updates module. For something like this, i would hardly want to check if it exists before adding it, the only reason i do is actually because of that BOF in London, and because you should always check if something exists before adding it. At least, thats what i was taught at school, and by experience i add a little help text because its just polite. If it is required to get the module accepted, i will of cause add the hook, but unless someone can show me why i am wrong about this i will strongly object to adding the hook to my module.
Comment #19
feolius commentedI think that your approach is too serious. You shouldn't check version of js library. At least, you don't do this in your current implementation in unveil_add_js() function. So, you shouldn't do this in hook_requirements too. I mean that you can implement something like this:
That's would be enough. And then you could remove this check from unveil_add_js() function.
As for executing of hook_requirements, I think there is some misunderstanding. Hook_requirements is not executed for each page loading (in contrast to hook_init()). You can implement this hook and check it. It fires only during install, update and runtime processes. So, if you check that library is in the directory in hook_requirements once during the installation process, you don't need to check it at every time when the library is needed. In this case you even speed up your code, because you remove the whole if{..}else{...} construction=)
For my opinion, it is not necessary to check some static things like existence of the library. It should be checked only once and then it should be used without any worries. If somebody removes this library from the server... so, it is his fault and you can punish him=)
Thanks.
Comment #20
lorique commented@feolius
So i implemented the hook_requirements, against my better judgement, just in order to see what happens. I messed around with it for a bit, and found it very fickle as i remembered. Its there now, and seems to work as intended. Its implemented for runtime and install phases.
I also discovered that i had forgotten to implement the usage of the unveil distance variable, which i then proceeded to implement.
Looking forward to get this module approved so i can add the first stable version of it, but if you wish there is an issue which i created for the module which i would appreciate someone else's view on. You can find it here: https://drupal.org/node/2041637
Comment #21
alberto56 commentedI enabled and tested your module on a test site, using devel_generate (part of devel) to generate a bunch of content with images, then a view to display them. Here are some notes:
(1) On the admin/reports/status page, when the Unveil library is not installed, the link to the README.txt file only works if you have clean URLs turned on and you are looking at the site in the default language. If not, you might get a link to something like ?q=fr/sites/all/modules/unveil/README.txt, which does not work. Furthermore, with the module installed properly in an environment without clean urls and in a foreign language, I am getting a javascript error in the console: "GET http://localhost/?q=fr/sites/all/modules/1805074/modules/unveil/image_pl... 404 (Not Found)"
(2) The README file says "The unveil js libarary should be located at sites/all/libraries/unveil". I think it is common practice to "reassure" users by giving example path to an actual file, thus adding something like, "so that jquery.unveil.js is at sites/*/libraries/unveil/jquery.unveil.js"
(3) When unveil.js is installed, I'm getting the error Notice: Undefined variable: requirements in unveil_requirements() (line 179 of /path/to/drupal/sites/all/modules/unveil/unveil.module); plus there is no line in the requirements confirming that I installed it correctly. I would suggest not putting your requirement in an if block. If the requirement is met, then reassure the user and say so (I read your qualms about hook_requirements(), which IMHO are not founded -- I have production sites with hundreds of requirements, and everything works fine -- if you still are having problems with hook_requirements, please open an issue for the drupal project, and provide a link to it here).
(4) I'm not sure if this can be remedied, but on a local server the image loading process is fast that one can't readily tell the difference between a site with your module enabled or not. I'm afraid some users might simply think your module is not working at all, so I would add in the README.txt, something like: "To see how this works, open Chrome, then turn on Developer tools (view > developer > developer tools), and use the Network tab to see exactly when your images are being loaded. Scroll along the site and notice that your images are being loaded only when needed".
(5) The README.txt is a bit too succint. I would suggest that the part about disabling unveil.js (a) be in its paragraph, and not in the same sentence as how to enable it; (b) an example be given of how to add "exclude_unveil to the image settings using preprocess" (otherwise you'll have issues filed asking exactly that question).
(6) I wouldn't mind having a bit more documentation on js/unveil.behavior.js.
(7) Finally, I'm curious as to why you don't enable this by default when the module is on. Why do we need to set it in the performance page? If someone enables this module on a site, I would prefer it to "just work".
Probably the only show-stoppers here are clean urls and foreign language prefix support, so I'm setting this to Needs Work. Other than that, good work!
Albert.
Comment #22
lorique commented@alberto56
I have updated the module as requested can you please try the module again?
Resetting this for needs review.
Comment #23
googletorp commentedThis looks good.
Comment #24
kscheirerI'm not quite sure why there is a checkbox for
unveil_preprocess_imageon both the performance page (via form_alter) and the unveil settings tab (via unveil_settings_form). Also, they have different default values, 0 in the first case, 1 in the second case - they should at least be consistent. There are also a few issues to take care of listed here: http://pareview.sh/pareview/httpgitdrupalorgsandboxlorique2019407git.That's not a blocking issue though, the module looks good!
Thanks for your contribution, lorique!
I updated your account to let you 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 get 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.
----
Top Shelf Modules - Crafted, Curated, Contributed.