Description
This module provides a specific attributes per product. Every product display can have different set of attributes and for this purpose you do not have to create another product type and manage product fields. Product Specific Attributes are stored on node level (product display level). I was searching for analog of this module very-very long and came up with my own module in the end which works pretty good for my commerce projects. Would be great to make it public and someones else eye to review it.
Use Case
What is the use case for such module? The answer is simple: Tickets Store. Every event like football game or rock concert might have:
- Unique set of dates;
- Unique set of ticket categories.
A combinations of those set values will provide unique type of ticket, but within same event. Every type of ticket might have its own SKU, stock amount, price and whatever Drupal Commerce provides.
Sandbox with description + screenshots
https://www.drupal.org/sandbox/nostop8/2232329
GIT
git clone --branch 7.x-1.x http://git.drupal.org/sandbox/nostop8/2232329.git commerce_psa
Reviews of Other Projects
- https://www.drupal.org/node/2341577#comment-9168981 - provided patch with found issues fixes
- https://www.drupal.org/node/2267323#comment-9253957 - also with patch of found possible code improvements
- https://www.drupal.org/node/2184079#comment-9257645
Comments
Comment #1
PA robot commentedThere are some errors reported by automated review tools, did you already check them? See http://pareview.sh/pareview/httpgitdrupalorgsandboxnostop82232329git
We 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
nostop8 commentedHi there! I've fixed several issues, particularly first issue with hardcoded field name of product reference field.
Also, there are new views handlers
1. to display PSA options on cart or checkout form view.
2. views element which you may add to cart form view and it will lead you to `edit options` form, fully nicely ajaxified (so, you do not have to go back to product display page in order to pick up different options combination)
Also, I've changed code formatting and started to add descriptions to functions. If anyone is interesting in this project, please review it. It does not have any analogs and might be really helpful for others.
Comment #3
gisleReversing an unwarranted priority upgrade.
Your issue summary is missing a git clone command.
PAreview is not happy: http://pareview.sh/pareview/httpgitdrupalorgsandboxnostop82232329git
Comment #4
nostop8 commentedUpdating description. Added use case, git clone --branch 7.x-1.x, titles h3
Comment #5
nostop8 commentedComment #6
gwprod commented2. Basic repository checks
2.1 Ensure the repository actually contains code.
Repository contains actual code.
2.2 Ensure you are working in a version specific branch.
Uses version-specific branch.
3. Security Review
3.1 Ensure the project does not contain any security issues.
I didn't encounter any obvious security problems.
4. Licensing checks
4.1 Ensure the repository does not contain a ‘LICENSE.txt’ file.
No LICENSE.txt
4.2 Ensure the repository does not contain any 3rd party (non-GPL) code.
No use of 3rd-party code.
5. Documentation checks
5.1 Ensure the project page contains detailed information.
Project page has detailed information.
5.2 Ensure the repository contains a detailed README.txt.
README.txt exists, but provides no useful documentation.
5.3 Ensure the code contains a well-balanced amount of inline-comments.
The code could afford to have more and better inline comments.
6. Coding standards and style
6.1 Run an automated review and ensure there are no major issues.
FILE: ...es/views/handlers/commerce_psa_line_item_handler_field_edit_options.inc
--------------------------------------------------------------------------------
FOUND 6 ERRORS AFFECTING 4 LINES
--------------------------------------------------------------------------------
8 | ERROR | Class name must begin with a capital letter
8 | ERROR | Class name must use UpperCamel naming without underscores
13 | ERROR | Visibility must be declared on method "construct"
24 | ERROR | Visibility must be declared on method "render"
31 | ERROR | Method name
| | "commerce_psa_line_item_handler_field_edit_options::views_form"
| | is not in lowerCamel format, it must not contain underscores
31 | ERROR | Visibility must be declared on method "views_form"
--------------------------------------------------------------------------------
FILE: ...iew_temp/includes/views/handlers/commerce_psa_handler_field_options.inc
--------------------------------------------------------------------------------
FOUND 5 ERRORS AFFECTING 4 LINES
--------------------------------------------------------------------------------
8 | ERROR | Class name must begin with a capital letter
8 | ERROR | Class name must use UpperCamel naming without underscores
13 | ERROR | Visibility must be declared on method "construct"
25 | ERROR | Visibility must be declared on method "query"
33 | ERROR | Visibility must be declared on method "render"
--------------------------------------------------------------------------------
FILE: ...var/www/drupal-7-pareview/pareview_temp/includes/commerce_psa.pages.inc
--------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
--------------------------------------------------------------------------------
65 | WARNING | Only string literals should be passed to t() where possible
--------------------------------------------------------------------------------
FILE: ...var/www/drupal-7-pareview/pareview_temp/includes/commerce_psa.admin.inc
--------------------------------------------------------------------------------
FOUND 4 ERRORS AFFECTING 4 LINES
--------------------------------------------------------------------------------
11 | ERROR | [ ] Class property $db_table should use lowerCamel naming
| | without underscores
12 | ERROR | [ ] Class property $db_pk should use lowerCamel naming without
| | underscores
13 | ERROR | [ ] Class property $db_parent_pk should use lowerCamel naming
| | without underscores
298 | ERROR | [x] There must be no space before the colon in a DEFAULT
| | statement
--------------------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
--------------------------------------------------------------------------------
FILE: ...ar/www/drupal-7-pareview/pareview_temp/includes/commerce_psa.common.inc
--------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
--------------------------------------------------------------------------------
194 | WARNING | Line exceeds 80 characters; contains 107 characters
--------------------------------------------------------------------------------
FILE: /var/www/drupal-7-pareview/pareview_temp/commerce_psa.js
--------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------
42 | ERROR | Files must end in a single new line character
--------------------------------------------------------------------------------
FILE: /var/www/drupal-7-pareview/pareview_temp/commerce_psa.info
--------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------
9 | ERROR | Files must end in a single new line character
--------------------------------------------------------------------------------
FILE: /var/www/drupal-7-pareview/pareview_temp/README.txt
--------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------
1 | ERROR | Files must end in a single new line character
--------------------------------------------------------------------------------
FILE: /var/www/drupal-7-pareview/pareview_temp/commerce_psa.module
--------------------------------------------------------------------------------
FOUND 2 ERRORS AND 1 WARNING AFFECTING 3 LINES
--------------------------------------------------------------------------------
186 | ERROR | Expected "if (...) {\n"; found "if(...) {\n"
216 | ERROR | Expected "if (...) {\n"; found "if(...) {\n"
247 | WARNING | Only string literals should be passed to t() where possible
--------------------------------------------------------------------------------
FILE: /var/www/drupal-7-pareview/pareview_temp/templates/edit-options.tpl.php
--------------------------------------------------------------------------------
FOUND 2 ERRORS AFFECTING 2 LINES
--------------------------------------------------------------------------------
1 | ERROR | [x] Whitespace found at end of line
11 | ERROR | [ ] Files must end in a single new line character
--------------------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
--------------------------------------------------------------------------------
7. API and best practices Review
7.1 Ensure you are using Drupals API correctly.
Adherence to the Drupal API seems to be good.
Specific Issues that I noticed.
using include_once 'includes... in module head may be an issue in certain circumstances. module_load_include is the preferred method.
in commerce_psa_module_implements_alter(), you shouldn't count on being able to put your hooks where you want in the invoke queue.
in commerce_psa_permission(), a short title and a longer description might be advisable, from a user's perspective.
in commerce_psa_line_item_handler_field_edit_options,inc on line 37, you add drupal's ajax.js directly, when you probably should do something like drupal_add_library('system', 'drupal.ajax');
Comment #7
nostop8 commentedHi there!
Big thanks for your review! I followed carefully all your suggestions:
1. Added as much as possible of useful information about the module to README.TXT
2. Fixed some issues with code from automated review. Issues that left, does not make any sense:
- Views handler is done on the basis of parent views handler with the same class/method/variable name standards, that's why it can't be an error;
- $form_state['values'] does not always provide actual values, that's why I had to use $form_state['input']
- yes, I'm using t() to translate attribute and option names. May be later I will have time to integrate it with i18n strings, but for now I think this option should be ok
3. removed include_once from global scope and added module_load_include where it is needed in the code
4. added description to PSA permission
5. swapped drupal_add_js('misc/ajax.js') with drupal_add_library('system', 'drupal.ajax');
What was not changes:
1. I have to use hook_module_implements_alter, otherwise some 2 parts of module won't work (this is commented inside this hook). In case there will be some issues with this in future, it can always be fixed. Using module weight, providing more issues I'm afraid.
2. As for commenting module's code. For now I did my best. There're no very complex implementations of code. I will do my best to comment what is not obvious in future.
Once again, thanks for review!
Comment #8
nostop8 commentedComment #9
gwprod commentedRegarding inheriting Views Handler and automated code review: Yes, you're right, and I think that can safely be ignored as a false positive.
Regarding $form_state['input']: It looks like you're trying to pass a non-form element as a form element, and that is why it's only available in $form_input. Consider refactoring to avoid doing this (if this is, in fact, what you are doing).
Regarding wrapping a variable with t(), I would do something like this:
Though I recognize that it's largely pointless to do so.
Comment #10
nostop8 commented1. Well, I've started with this module pretty long time ago (more than 3 months I think), that's why it is difficult to say 100% why I've used 'input' instead of 'values'. I've just made a small test (replaced 'input' with 'values'). One of the reasons might be following. Product Attributes and Attribute Options forms are fully ajaxified (add/remove/save actions). When I press `remove` next to any table row, 'values' array consist only of single row (remove button row) inside form submit callback. Not sure why it happens, because of '#limit_validation_errors' element option, or because it is on PSA row level. Anyway, because if this I can't rebuild form. This is an issue which I found in 5 min. I'm sure there're some more.
2. Well, if I do this, my attribute and attribute options simply won't be localized and I'm using t() because I need to localize them. Otherwise I wouldn't wrap them with this function :)
Comment #11
gwprod commentedWhen a button is pressed, the inputs are sent to the form processing function (which is why they are directly available per row in $form_state['input']), but they collide before getting to $form_state['values'].
If you insert
At or around line 114 and this
at line 45 in commerce_psa.admin.inc, then you should be able to address the data directly in $form_state['values'].
This isn't exactly trivial, since using $form_state['input'] directly is a security issue.
Comment #12
nostop8 commented1. I've tried your suggestions, but it did not work. As I were suspecting above, issue comes from '#limit_validation_errors' => array() inside remove button element. If I remove it, it starts to work OK with $form_state['values']. But, after this I get a lot of user experience issues, like can't remove row, which does not have value. That's why '#limit_validation_errors' => array() has to stay there.
Speaking about security issue. Let me disagree. First of all this admin menu callback has set permissions access. I do not think that this permission can ever be given to some user role from the street. Secondly, even if we take a look at imaginary situation where this user role has 'manage commerce psa' permission and will try to put some kind of `bad` data, anyway on the end it is inserted with drupal_write_record wrapper which should do all the sql escapes, etc.
2. OK, you win :) I've rebuilt it using i18n. Now it works even better, because with t() user has to input only English labels by default.
P.S. Finally fixed require_once in global scope. Somehow forgot about removing those lines, and module_load_include did not actually work, because I was passing incorrect path. Now everything fixed.
Thanks for review and all your suggestions!
Comment #13
nostop8 commentedUpdates:
1. Made readme.txt file even more descriptive
2. Updated module's page: https://www.drupal.org/sandbox/nostop8/2232329 with all the information you might need
3. Did several improvements and fixes (please, do flush all caches and rebuild file registry (drush rr), in case you were using module before).
Comment #14
gwprod commentedSo I just noticed something; why are your class methods magical?
Comment #15
nostop8 commentedAre you talking about method like "__buildForm"? It is just main methods and it was convenient for me to see them on the top inside class navigator. If that's something you do not like or it confuses you, I can change it to "_buildForm" or even "buildForm", whatever you like.
Comment #16
gwprod commentedyes, methods like __ are treated as magic by PHP. And the rule is, that they are not to be called in code. They're for PHP. (PHP's rule, I don't know if Drupal cares)
Comment #17
nostop8 commentedWell, I understand your point, and that this might confuse some developers. I do not even remember what I was thinking about when I used this double underscore prefix (could use only one underscore and that would be enough for my code navigator). Anyway, I removed those. Thanks!
Comment #18
klausson commentedThere are some more errors and warnings in PAreview - they are certainly worth paying attention to, but I don't think they should gate the release. Aside from the use case stated (events with two dimensions of attributes and the need to automatically create variants), there are plenty of other product categories that would benefit from this and make it easier to get Drupal Commerce acceptance. Any product that has a natural dimension of configurability would benefit from this (I'm running a web store for printed photography and we hard-coded a similar solution that is far less elegant).
For these reason: I am strongly in favor of promoting this module for the general public, ideally after fixing the outstanding PAreview items.
Comment #19
nostop8 commentedklausson, thank you for your positive feedback about module's possible usefulness. It's been already 3 months on review and I really do hope that it will get accepted asap.
As for the PAreview, I've fixed all issues that appeared recently. There're left only issues which were discussed previously with gwprod. I will comment them again:
1. This is views handler, which was done on the basis of parent views handler with the same class/method/variable name standards, that's why it can't be an error; this is a coding standard of views handlers.
2. $form_state['values'] does not always provide actual values, that's why I had to use $form_state['input']. See full information about this issue above discussed.
Comment #20
klausson commentedAutomated Review
http://pareview.sh/pareview/httpgitdrupalorgsandboxnostop82232329git (commit 1e2c82e) found 6 issues from Code Sniffer, none of which seem severe enough to hold the release. DrupalPractice found 5 issues that all come down to the use of "$form_state['input']" instead of "$form_state['values']". The latter should be easy to address and should indeed be addressed before release.
Manual Review
Comment #21
nostop8 commentedHi Klaus!
Thanks a lot for your review. I made a workaround to fix form_state input.
Comment #22
klausson commentedI checked the remedies mentioned above and agree that the remaining issues should not hold a release. Setting status to RTBC.
Comment #23
nostop8 commentedComment #24
nostop8 commentedComment #25
nostop8 commentedComment #26
nostop8 commentedComment #27
nostop8 commentedComment #28
klausimanual review:
<script>alert('XSS');</script>as attribute name and then click on manage options I get a nasty javascript popup. You need to sanitize user provided text before printing to HTML in commerce_psa_option_form(). Make sure to read https://www.drupal.org/node/28984 again. And please don't remove the security tag, we keep that for statistics and to show examples of security problems.Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.
Comment #29
PA robot commentedClosing due to lack of activity. If you are still working on this application, you should fix all known problems and then set the status to "Needs review". (See also the project application workflow).
I'm a robot and this is an automated message from Project Applications Scraper.
Comment #30
avpadernoComment #31
avpaderno