This is a module that provides a base structure for tagging of Vehicle Y/M/M on Drupal content. This module borrows heavily from the storage structure and style behind the Taxonomy module. The reason for not extending the Taxonomy module is to provide a better separation between the types of tagging so as to allow distinct and separate tagging for normal Taxonomy and for Vehicles. Also there is a relationship component required that can make using Taxonomy vocabularies messy at best and buggy at worse.

Some of the issues I've tried to address in this module are discussed here: http://drupal.org/node/438490

Because of the direct relationship between a Vehicle Make and Vehicle Model and to further simplify the creation of Vehicles without redundant multiple tags for each year and model of vehicle I've chosen a two-tiered approach which has one vocabulary each for Make and Model with a direct relationship between them that allows for the automatic creation of a standard Y/M/M selector.

This module has been designed to allow easy importing of an existing Y/M/M database via a flat CSV file. An importing script has not been created yet, but is planned for a future update. Currently importing can be done manually, using a contributed module, or one at a time via the built in form in the module UI.

Vehicle is currently a Drupal 7 module. No plans are set to backport to Drupal 6 unless the community requests. Drupal 8 compatibility is planned for the future.

Project page: http://drupal.org/sandbox/Ignigena/1650668

GIT link: http://git.drupal.org/sandbox/Ignigena/1650668.git
GIT clone: git clone http://git.drupal.org/sandbox/Ignigena/1650668.git vehicle

I plan on reviewing other projects as I have the time and work allows.

Thanks for your consideration!

Reviews of Other Projects:
http://drupal.org/node/1807430#comment-6579802
http://drupal.org/node/1806400#comment-6579862
http://drupal.org/node/1813730#comment-6613346

Comments

gflamino’s picture

StatusFileSize
new1.31 KB

Came up with some minor warnings and errors using coder (http://drupal.org/project/coder). See report.

Ignigena’s picture

Thank you for your review.

I have addressed the minor warnings and errors along with a few additional coding standards errors I found in the module. All changes have been pushed to the GIT repository.

Ignigena’s picture

Issue summary: View changes

Added review of another project.

andrewkamm’s picture

Hi Ignigena,

Since vehicle.module doesn't do anything besides implement hook_menu() (for the admin/vehicle) path, You may want to consider merging the vehicle and vehicle_ymm modules.

The primary reason is to smooth the installation process. The installation instructions in the README refer to vehicle as a single module ("Enable the module and configure settings") and when I installed via Drush, I didn't realize there are actually four modules to be enabled (there are no dependencies to listed in vehicle.module).

Plus, the content presented at /admin/vehicle just said that I "have no administrative items" (not that I need to enable other modules).

I ran Coder reviews on all four modules included, and the reports came back clean.

However, I hit problems while trying to add vehicle information though: I'm unable to create a Make. I receive an error that "The machine-readable name is already in use. It must be unique." (I've attached a screenshot)

When I try customizing the machine name, the field description says to use underscores, but doing so results in a validation error that says to use hyphens. When I used hyphens, I received the uniqueness error above (I receive that same error if I remove all hyphens and underscores.

Also, in vehicle_ymm.css, consider using a CSS selector that limits your the custom styling to module-specific items rather than form.select, which could potentially interfere with non-Vehicle styles.

Let me know if there's a setting or other dependency I may be missing. I'll retest then and let you know how it goes.

Screenshot of validation error

Ignigena’s picture

Thanks for the review, fatleaf.

As for the Vehicle module simply being a hook for the menu: I plan on adding other features to this section that will be global features not specific to one module. Also makes the menu structure a bit easier. To address your concern I have modified the README.txt file to contain clearer instructions telling the user to enable one or both of Vehicle Make and Vehicle Model to actually build the structure.

If this is against best practices or you'd suggest an alternate strategy here, please advise. I noticed that Views includes a module for the base View and also a Views UI module that must be enabled for Administration functionality. This is sort of the strategy here, although I plan on introducing future features directly in the root Vehicle module as well.

I addressed the bug you found in Vehicle Make as well as fixing the inconsistency between the help text and error text. Everything should be working now.

Good suggestion in the CSS file, I have also updated this accordingly so we don't accidentally restyle an existing select form element.

Pushed everything live to the GIT repository and verified no coding standards errors.

Ignigena’s picture

Issue summary: View changes

Added review of another project.

Ignigena’s picture

Issue tags: +PAreview: review bonus

Reviewed three other projects; adding bonus tag.

klausi’s picture

Status: Needs review » Needs work
Issue tags: -PAreview: review bonus +PAreview: security

Thanks for your reviews, just make sure that you pick the oldest applications first.

Review of the 7.x-1.x branch:

  • Remove "version" from the ./vehicle_model/vehicle_model.info file, it will be added by drupal.org packaging automatically.
  • Remove "version" from the ./vehicle_make/vehicle_make.info file, it will be added by drupal.org packaging automatically.
  • Remove "version" from the ./vehicle_ymm/vehicle_ymm.info file, it will be added by drupal.org packaging automatically.

This automated report was generated with PAReview.sh, your friendly project application review script. You can also use the online version to check your project. You have to get a review bonus to get a review from me.

manual review:

  1. vehicle_make_list_entities(): this is vulnerable to XSS exploits, as you are printing the country unsanitized which is user provided input. If I enter <script>alert('XSS');</script> as country I get a nasty Javascript popup. Please read http://drupal.org/node/28984 again. Same in vehicle_make_vehicle_page(). Please check all your code where you print user provided text.
  2. vehicle_make_pathauto_bulkupdate(): why do you need the extra select query? Just use entity_load() with FALSE as $ids?
  3. "$result->rowCount() . ' vehicle makes were updated.'": all user facing text must run through t() for translation, and you should use placeholders with t() for the dynamic number.

Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.

Ignigena’s picture

Status: Needs work » Needs review
Issue tags: -PAreview: security +PAreview: review bonus

Thanks for the review klausi!

I have fixed all issues you came across during your manual review. I will review another 3 projects as soon as I am able, but work is keeping me really busy.

Ignigena’s picture

Issue tags: -PAreview: review bonus

Crap, I don't know how it added the review bonus back in :\

klausi’s picture

Issue tags: +PAreview: security

Please don't remove the security tag, we keep that for statistics and to show examples of security problems.

Ignigena’s picture

Sorry, I just posted a reply and it both removed that tag and added back in the review bonus tag. I'll double check the Tags from now on to make sure it isn't changing anything.

2pha’s picture

Hi,
This looks like a promising module, and I am currently after a module like this for a car parts site I am building.

I have just installed this module on a clean drupal install and will give you my impressions as I went through the process of creating a vehicle part on the site :)

  • After installing all the vehicle modules I liked that the vehicle menu was at the top level and easy to find.
  • I created 2 vehicles, both a make and model Holden Commodore, 1 sedan and 1 wagon (bodytype field).
  • When creating the model, I was surprised when I saw there were many fields (engine position, seats etc.). This is a fieldable entity, why are these fields already on the entity? I understand why a model reference is needed, and maybe the year but I don't understand why the other fields are there.
  • I created a part content type and added a vehicle reference field.
  • I went to create a part thinking that I would be able to assign the part to a holden commodore sedan and then another part to the wagon but the vehicle reference field had year, make model and trim comboboxes. I hadn't entered a value for the trim on the vehicles and couldn't select the bodytype at all, the trim combobox had 2 values both on 'none'. This is a little confusing and maybe a normal entity reference field would have been better for me on the part content type.

I'm not sure if any of this will be helpful to you, but I thought you might like the feedback from someone who was looking at actually using this module on a production site. The functionality seems to be a little too specific for my needs so I don't think I will use it, but it does give me a head start in creating my own module.
Thanks

Ignigena’s picture

When creating the model, I was surprised when I saw there were many fields (engine position, seats etc.). This is a fieldable entity, why are these fields already on the entity? I understand why a model reference is needed, and maybe the year but I don't understand why the other fields are there.

This was done for easy, one-step importing from the Car Query API database. This may be moved to a separate submodule that will extend the fields with this default data. But that was the reasoning behind having so many default fields in addition to it being fieldable.

I went to create a part thinking that I would be able to assign the part to a holden commodore sedan and then another part to the wagon but the vehicle reference field had year, make model and trim comboboxes. I hadn't entered a value for the trim on the vehicles and couldn't select the bodytype at all, the trim combobox had 2 values both on 'none'. This is a little confusing and maybe a normal entity reference field would have been better for me on the part content type.

The Y/M/M widget uses only the model name and trim to build the menu. Extra fields such as "bodystyle" are for display purposes or for building into a custom View (Views integration already provided for all fields.) This could probably be made more clear with documentation or the future addition of the ability to define what options are used to build the Y/M/M widget.

In any case, to do what you were wanting you'd create two model entities with the following:

Make: Holden
Model: Commodore
Year: (some year)
Trim: Sedan

Make: Holden
Model: Commodore
Year: (some year)
Trim: Wagon

This will allow you to tag with the Y/M/M widget and build the menu accordingly.

I'd definitely love to talk about ways that this module can be made a bit easier for the first time install including collaborating if possible. I'd hate for you to have to create your own module from scratch to do the basic same thing. I'm using this module on two live production sites right now but there's always more use studies that I haven't thought of myself.

Thanks for the review :)

Ignigena’s picture

I have just made some major updates to how the Makes and Models are stored to address some of the thoughts in #11:

  1. You can now specify a range of years for each Vehicle Model versus needing to create a different one for each year. Reduces the number of entries needed to have a fully operational Y/M/M database and selector.
  2. The extra fields on the Model entities have been moved to their own module that dedicated to bringing integration with CarQueryAPI. This should help to keep things simple for the fresh install and also better suited for broader use.
Bob Humphrey’s picture

Status: Needs review » Needs work
StatusFileSize
new79.44 KB
new25.14 KB
new21.17 KB
new21.07 KB

Hello Ignigena,

This looks like a promising module for anyone working with car parts.

However, when I took your module for a test drive, I found some errors.

After adding one or two make records, the application started to return 500 errors whenever I tried to add or edit another make record. This started after I tried to edit the machine name for a make record. The records were being added or updated correctly in the database, but the module would still return a 500 error.

500 error

500 error

I was able to add model records successfully, but I would suggest that you provide the user with some kind of confirmation message after a record has been added. Without any kind of feedback from your module, after adding a record I was left wondering if the add worked or not.

I added the Vehicle Make/Model Selector block to my site and it worked nicely. However, if I tried to select a vehicle for which there were no matching records, the application displayed a php error. The same thing happened when I selected Vehicle Makes from the Navigation menu and then picked a particular model that didn't have any matching records.

php error

Finally, I see that there are a lot of warning messages being logged when I run your module.

warning messages

Best of luck with your continuing work on this module.

Bob

Ignigena’s picture

Status: Needs work » Needs review

Thanks Bob for taking the time to review my project. Appreciate the detail and testing you did.

After adding one or two make records, the application started to return 500 errors whenever I tried to add or edit another make record. This started after I tried to edit the machine name for a make record. The records were being added or updated correctly in the database, but the module would still return a 500 error.

I was unable to replicate this issue on a fresh D7 install on my local machine. Can you let me know exactly what steps reproduce the 500 errors you mentioned here? Was it only the records where you tried editing the machine name? Was there any error message when you tried editing the machine name?

I was able to add model records successfully, but I would suggest that you provide the user with some kind of confirmation message after a record has been added. Without any kind of feedback from your module, after adding a record I was left wondering if the add worked or not.

Good point! I had set a confirmation message for deletion but not for adding or updating a record ... silly me! In any case, I've added the appropriate confirmation message and pushed the changes live.

I added the Vehicle Make/Model Selector block to my site and it worked nicely. However, if I tried to select a vehicle for which there were no matching records, the application displayed a php error. The same thing happened when I selected Vehicle Makes from the Navigation menu and then picked a particular model that didn't have any matching records.

Thanks for catching this. I've fixed this. This error just started popping up since I added the ability to specify a year range and changed the field name to support that. Just missed changing it on that line.

Finally, I see that there are a lot of warning messages being logged when I run your module.

I should have caught this. I started off the module using custom theme files but moved to hooks for the Make and Model pages. I never removed the references to the theme files and this is what was generating the errors.

Once again, thanks for the excellent review!

summit’s picture

Hi, Just curious..why having the focus on vehicle, and not on an entity which could be a vehicle?
This way the module can be more generic applicable?
Greetings, Martijn

Ignigena’s picture

Hi Martijn,

Can you explain in further detail what you mean?

I have tried to keep this as generic as possible. Entities are referred to as "Vehicles" versus "Cars" so that this module can be used not solely for Car parts but also for Motorcycle, Boat, ATV, etc. I have a site currently using the module that has both Cars and Motorcycles and they are able to use this one module with a field for what "type" of Vehicle the entity is.

I'm not sure how more generic this can get without losing the functional purpose of the module in the first place. But if I'm wrong I'd love to hear any suggestions on how you would propose structuring things!

Thanks!

Bob Humphrey’s picture

Hi Ignigena,

Here's a more detailed explanation of the errors I receive when adding Make records.

When I first login, I can add new Make records without any problems.

However, when I try to edit the machine name while adding a record, I get the error message below:

500 error

The module did add the Make record I was trying to add, but it returned this error.

Once this problem has occurred, I continue to receive an error message whenever I try to add or edit any Make record.

The error condition goes away when I logoff and then log back on.

All my testing was done on a clean install of D7.

Hope this helps.

Bob

rotty_dean’s picture

Category: task » bug

Hiya, Installed your module. It seems to be just what i need if i redevlope my website in drupal.

I seem to have found a bug, i cannot get Vehicle field to save correctly. Only the 'Make' saves the rest are not. Drupal throws an error of "An illegal choice has been detected. Please contact the site administrator."

Drupal Logs show "Illegal choice 2001-2002 in field_veh element."

summit’s picture

Hi, I was under the impression it was for cars, but with your explanation it is generic enough I think. You are right that being to generic can loose functionality.
Sorry for my remark. Greetings, Martijn

sah62’s picture

StatusFileSize
new30.43 KB
new29.62 KB

Thanks for taking the time to develop this module! I sell car parts from my site, and it seems designed to provide exactly the kind of functionality that I need to make it easier for customers to find what they need. I've installed it (no problems), configured it with two vehicle makes and models (no problems), and started doing a little testing. I've found a few small behaviors that aren't quite what I expect. I'm using Ubercart for my shopping cart.

I created a Ford make and Mustang model with start model year 1967 and end model year 1998. I edited my Ubercart product content type and added a make/model field (Year/Make/Model dropdown widget) with no restriction on the number of make/model fields.

I have a part that fits 1967 - 1969 Ford Mustangs. I edit the product that corresponds to the part and add a field for a 1967 Ford Mustang, and 1968 Ford Mustang, and a 1969 Ford Mustang. Save the changes. When I edit the product again I see all three fields, but they all say "1967 Ford Mustang". I would expect to see one for each model year. Before and after images attached

Note the extra unused widget in the images. It would be nice to be able to remove it if I later want to remove a particular year/make/model.

I also tried the Year range model dropdown, but that only allows me to specify the complete range of years (1967 - 1998 in this case). It would be nice if I could just select 1967 - 1969.

srutheesh’s picture

Hi ,

There is still some coding standered issue.

Link : http://ventral.org/pareview/httpgitdrupalorgsandboxignigena1650668git

FILE: ...ar/www/drupal-7-pareview/pareview_temp/vehicle_make/vehicle_make.module
--------------------------------------------------------------------------------
FOUND 7 ERROR(S) AFFECTING 7 LINE(S)
--------------------------------------------------------------------------------
52 | ERROR | Invalid @param data type, expected int but found integer
54 | ERROR | Invalid @param data type, expected bool but found boolean
487 | ERROR | else must start on a new line
Ignigena’s picture

Category: bug » task

Thanks for the review sah62

I plan to make the trim widget either a setting in the module or moved to it's own submodule. It is primarily meant for Cars where you may have a Ford Mustang Convertible and Hardtop with separate part compatibilities. If using this for Bikes, Boats, etc. this field may not be necessary at all so I would agree that the option to do without it would be valuable.

As for your issue with the make and model compatibility. When setting up your make and model database make sure you create a separate entity for your vehicles versus lumping them all into one. Most Y/M/M databases create a separate entry for each year meaning:

1967 Ford Mustang
1968 Ford Mustang
1969 Ford Mustang
etc...

The module is set up to take these types of databases. However, there are some cases where separate entities for each year isn't the most efficient way of doing things. Smaller sites with more limited databases may only have certain makes and models, or have different tagging needs and this is where the year end comes into play. An example of this might be a company that sells Corvette body parts compatible by generation. Rather than needing to load individual years, they can simply populate their database with:

1953-1962 Corvette C1
1963-1967 Corvette C2
1968-1982 Corvette C3
etc...

This is the best way to do things because these are fieldable entities which means you can load images or data specific to the model year(s) that may not be the same across the entire production of the model.

In your case, because you have one vehicle model that is 1967-1998, if you tag this vehicle model it is tagging the entire year range because it is in essence associating your product with the entire Parent Entity.

To do what you are hoping, you should first determine if you need to populate your database with model generations or if they need to be separated by each year. This will depend on the kind of parts you are selling. Do you have some parts that fit a 1967-1969 Mustang and some that *only* fit a 1968 but not a 67 or 69? In this case, you'll need to fully break them out by year for best results. Otherwise, break them into generations like the Corvette example and you'll be fine.

One thing that would probably be helpful is on the Y/M/M Dropdown widget to have something that shows visually the user is tagging a year range even though they selected one of the years. Whether this be a tooltip or a different approach altogether I am up for suggestions.

Let me know if this helps clarify! If you have any suggestions, let me know!

Ignigena’s picture

Just addressed these new coding standards. I run PAReview before every commit and it came back with no errors so these new ones must have come from an update to the review module since my last commit. Thanks for the heads up srutheesh!

sah62’s picture

Thanks for the feedback. I was thinking that I could get the behavior I want by creating a separate make/model for each year. I'll do that.

A few more questions: it would be nice if I could could change the text on the block button from "Go" to something like "Search for Parts". Short of changing code do you have any plans to make the text configurable?

It looks like you're using a view to display the "Go" search results. How would you recommend changing the display of the results? Instead of full text I'd like to create a table of titles and product images.

sah62’s picture

StatusFileSize
new12.15 KB

Another minor tweak suggestion:

As suggested above I tagged some content with a start model year, but no end model year. I modified my part content type to display the year/make/model field info on the tagged part. I hoped to see something like "1967 Ford Mustang", but each row in the list includes an end year ("1967-1967 Ford Mustang") and links to the make and model (see attached image). If no end year is listed I'd prefer to not see an end year. I'd also prefer to not have links on the make/model values, or perhaps the use of links could be optional.

srutheesh’s picture

Hi Ignigena,

I hope you have great idea.
The vehicle module is working fine but i cant enable the vehicle make module it is showing some installation error.

In the Readme.txt i can see the instruction of module usage .

2. Enable the Vehicle, Vehicle Make and Vehicle Model modules and configure 
settings.  Note that the Vehicle module currently serves to display the 
administrative interface for the Make and Model modules as well as placeholder 
for future features.  You must enable one or both of these modules in order to 
use the module properly.

Please fix the vehicle make issue so that i can check the vehicle functionality.

Thank you,
Srutheesh

sah62’s picture

StatusFileSize
new69.88 KB

I just ran into some "undefined variable" errors when I enabled the "Hierarchical display of year make and models" block:

Notice: Undefined variable: model_entities in /mypath/sites/all/modules/vehicle/vehicle_ymmblock/block--vehicleymm.tpl.php on line 40

Warning: Invalid argument supplied for foreach() in /mypath/sites/all/modules/vehicle/vehicle_ymmblock/block--vehicleymm.tpl.php on line 40

Notice: Undefined variable: model_entities in /mypath/sites/all/modules/vehicle/vehicle_ymmblock/block--vehicleymm.tpl.php on line 40

Warning: Invalid argument supplied for foreach() in /mypath/sites/all/modules/vehicle/vehicle_ymmblock/block--vehicleymm.tpl.php on line 40

It looks like this can happen if isset($model_query['vehicle_model']) on line 35 returns false. I have makes and models defined so I'm not sure why that would happen, but perhaps an else clause is needed. Krumo displays the value of $model_entities as "... (Array, 0 elements)". I've attached an image showing the query parameters. I believe the problem is that I don't yet have models associated with all of the defined makes.

Ignigena’s picture

As suggested above I tagged some content with a start model year, but no end model year. I modified my part content type to display the year/make/model field info on the tagged part. I hoped to see something like "1967 Ford Mustang", but each row in the list includes an end year ("1967-1967 Ford Mustang") and links to the make and model (see attached image). If no end year is listed I'd prefer to not see an end year. I'd also prefer to not have links on the make/model values, or perhaps the use of links could be optional.

Thanks for pointing this out as it is rather redundant. I have modified the display to only show one year if the start and end years are the same.

Also, to avoid links on the make/model values you can use hook_field_formatter_view() to modify. I can also see adding a setting to enable or disable the inclusion of links if you feel like this would be better for broad use cases.

Just so I can keep track of this better, can you submit the feature request to the Issue queue on the project? Don't want to sidetrack the project application with these very useful feature requests that I'd love to work on implementing.

Ignigena’s picture

The vehicle module is working fine but i cant enable the vehicle make module it is showing some installation error.

Srutheesh: can you please provide the installation error you are encountering? Are you running off a fresh Drupal installation? Any additional information you can give me will help me to determine the cause of the problem.

Ignigena’s picture

sah62: thanks for the detailed report of the errors you encountered on the YMM Block module.

You are correct that the problems were happening when no models were defined. I had declared endif too soon in the block. I moved this line to the end of the block as it should have been and you shouldn't encounter these errors any more!

sah62’s picture

Just so I can keep track of this better, can you submit the feature request to the Issue queue on the project? Don't want to sidetrack the project application with these very useful feature requests that I'd love to work on implementing.

Done. Thanks for the other changes.

klausi’s picture

Status: Needs review » Reviewed & tested by the community

Sorry for the delay. Make sure to review more project applications and get a new review bonus and this will get finished faster.

manual review:

  • vehicle_ymm_block.tpl.php: this is a template file and should not contain any logic or DB queries. Assemble the content in vehicle_ymmblock_block_view() or a helper function.

Otherwise looks RTBC to me!

Ignigena’s picture

Thanks for the review klausi. I totally understand giving priority to the review bonus listings. It's been a bit hectic so I just haven't had as much time to review projects as I would like.

I moved the database queries out of the tpl.php file per your suggestion. It now resides in it's own preprocess hook which I plan on extending to pass other variables that would be useful when customizing the tpl.php file to different installation needs.

Verified everything on my local dev installation and pushed everything to GIT.

klausi’s picture

Status: Reviewed & tested by the community » Fixed

no objections for more than a week, so ...

Thanks for your contribution, Ignigena!

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.

sah62’s picture

Congratulations, Ignigena. I've needed a module like this one for several years and haven't had the time to even think about writing it myself. I'm glad you took on the commitment. I'm looking forward to using it "live" and will help in any way I can to make it better.

Ignigena’s picture

Thanks klausi for the promotion and for the reading links, I hope to contribute to the community and be as helpful as I can so these will help for sure.

And sah62, thanks for your continued help with bug reports and patching on the module. I hope to make this super useful to you and add some of the features that you're hoping for :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

tonkatuph’s picture

I the same warning "An illegal choice has been detected. Please contact the site administrator." My solution was to validate the form

under vehicle_ymm.module look for

$element['year'] = array(
'#type' => 'select',
'#options' => _vehicle_ymm_build_year_range_menu(0, $current_make_id, $current_model),
'#attributes' => array('class' => array('vehicle-ymm-year')),
'#theme_wrappers' => array(),
'#default_value' => $current_year,

Change to

$element['year'] = array(
'#type' => 'select',
'#options' => _vehicle_ymm_build_year_range_menu(0, $current_make_id, $current_model),
'#attributes' => array('class' => array('vehicle-ymm-year')),
'#theme_wrappers' => array(),
'#validated' => TRUE,
'#default_value' => $current_year,

Let me know if it works out.

Ignigena’s picture

tonkatuph: can you post this to the issue queue on the project page? This will help to track and fix!

tonkatuph’s picture

Sure, but I'm not sure where to post it. Newbie here ;D

*Update: I figured it out. Thanks.

tonkatuph’s picture

Issue summary: View changes

Added project review link.