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

Comments

PA robot’s picture

Status: Needs review » Needs work

There 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.

nostop8’s picture

Priority: Normal » Major
Status: Needs work » Needs review

Hi 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.

gisle’s picture

Priority: Major » Normal

Reversing an unwarranted priority upgrade.

Your issue summary is missing a git clone command.

PAreview is not happy: http://pareview.sh/pareview/httpgitdrupalorgsandboxnostop82232329git

nostop8’s picture

Issue summary: View changes

Updating description. Added use case, git clone --branch 7.x-1.x, titles h3

nostop8’s picture

Issue summary: View changes
gwprod’s picture

Status: Needs review » Needs work

2. 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');

nostop8’s picture

Hi 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!

nostop8’s picture

Status: Needs work » Needs review
gwprod’s picture

Regarding 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:


$options[$value['option_id']] = t('@name', array('@name'  => $value['name']));

Though I recognize that it's largely pointless to do so.

nostop8’s picture

1. 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 :)

gwprod’s picture

  1. I've looked at the code in question for your table form, and the most obvious issue is that you aren't using '#tree' => TRUE at each level of the hierarchy:
    When 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

       $table[$i] = array(
           '#tree' => TRUE,
        );
    

    At or around line 114 and this

    $form['table']['#tree'] = TRUE;
    

    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.

  2. I understand what you are trying to do with t(), the problem is that passing dynamic data to t() can be a security risk, because it isn't escaped. A better option might be to call locale directly, then escape the output.
nostop8’s picture

1. 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!

nostop8’s picture

Updates:
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).

gwprod’s picture

So I just noticed something; why are your class methods magical?

nostop8’s picture

Are 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.

gwprod’s picture

yes, 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)

nostop8’s picture

Well, 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!

klausson’s picture

There 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.

nostop8’s picture

klausson, 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.

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"
--------------------------------------------------------------------------------

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.

FILE: ...var/www/drupal-7-pareview/pareview_temp/includes/commerce_psa.admin.inc
--------------------------------------------------------------------------------
FOUND 0 ERRORS AND 4 WARNINGS AFFECTING 4 LINES
--------------------------------------------------------------------------------
91 | WARNING | Do not use the raw $form_state['input'], use
| | $form_state['values'] instead where possible
92 | WARNING | Do not use the raw $form_state['input'], use
| | $form_state['values'] instead where possible
94 | WARNING | Do not use the raw $form_state['input'], use
| | $form_state['values'] instead where possible
276 | WARNING | Do not use the raw $form_state['input'], use
| | $form_state['values'] instead where possible
-----------------------------------------------------
klausson’s picture

Status: Needs review » Needs work

Automated 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

Individual user account
Yes: Follows the guidelines for individual user accounts.
No duplication
Yes: Does not cause module duplication and fragmentation.
Master Branch
Yes: Follows the guidelines for master branch.
Licensing
Yes: Follows the licensing requirements
3rd party code
Yes: Follows the guidelines for 3rd party code.
README.txt/README.md
Yes: Follows the guidelines for in-project documentation and the README Template.
Code long/complex enough for review
Yes: Follows the guidelines for project length and complexity.
Secure code
Yes. If "no", list security issues identified.
Coding style & Drupal API usage
Nothing found that needs to be addressed before release, except for the issues identified by PAreview.sh (see above). Switching back to "needs work" for a fix.
nostop8’s picture

Hi Klaus!

Thanks a lot for your review. I made a workaround to fix form_state input.

klausson’s picture

Status: Needs work » Reviewed & tested by the community

I checked the remedies mentioned above and agree that the remaining issues should not hold a release. Setting status to RTBC.

nostop8’s picture

Issue summary: View changes
nostop8’s picture

Issue summary: View changes
nostop8’s picture

Issue summary: View changes
nostop8’s picture

Issue summary: View changes
nostop8’s picture

Issue summary: View changes
Issue tags: +PAreview: review bonus
klausi’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: -PAreview: review bonus +PAreview: security

manual review:

  1. commerce_psa.js: you should use 2 spaces per indentation level. See https://www.drupal.org/node/172169#indenting
  2. commerce_psa_module_implements_alter(): the comment should say why you need to alter the form earlier, e.g. before which other hook yours needs to run.
  3. commerce_psa_theme_registry_alter(): why do you need to swap out inline_entity_form? Please add a comment.
  4. When I enter attributes at node/1/psa and try to save I get an Exception: "EntityMalformedException: Missing bundle property on entity of type commerce_product. in entity_extract_ids()".
  5. The "Manage Options" screen is vulnerable to XSS exploits. If I enter <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.

PA robot’s picture

Status: Needs work » Closed (won't fix)

Closing 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.

avpaderno’s picture

Issue tags: -, -Commerce product attributes
avpaderno’s picture