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
| Comment | File | Size | Author |
|---|---|---|---|
| #28 | query.jpg | 69.88 KB | sah62 |
| #26 | field-values.jpg | 12.15 KB | sah62 |
| #21 | before-save.jpg | 29.62 KB | sah62 |
| #21 | after-save.jpg | 30.43 KB | sah62 |
| #14 | vehicle1.png | 21.07 KB | Bob Humphrey |
Comments
Comment #1
gflamino commentedCame up with some minor warnings and errors using coder (http://drupal.org/project/coder). See report.
Comment #2
Ignigena commentedThank 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.
Comment #2.0
Ignigena commentedAdded review of another project.
Comment #3
andrewkamm commentedHi Ignigena,
Since
vehicle.moduledoesn't do anything besides implementhook_menu()(for theadmin/vehicle) path, You may want to consider merging thevehicleandvehicle_ymmmodules.The primary reason is to smooth the installation process. The installation instructions in the README refer to
vehicleas 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 invehicle.module).Plus, the content presented at
/admin/vehiclejust 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 thanform.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.
Comment #4
Ignigena commentedThanks 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.
Comment #4.0
Ignigena commentedAdded review of another project.
Comment #5
Ignigena commentedReviewed three other projects; adding bonus tag.
Comment #6
klausiThanks for your reviews, just make sure that you pick the oldest applications first.
Review of the 7.x-1.x branch:
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:
<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.Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.
Comment #7
Ignigena commentedThanks 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.
Comment #8
Ignigena commentedCrap, I don't know how it added the review bonus back in :\
Comment #9
klausiPlease don't remove the security tag, we keep that for statistics and to show examples of security problems.
Comment #10
Ignigena commentedSorry, 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.
Comment #11
2phaHi,
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 :)
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
Comment #12
Ignigena commentedThis 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.
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 :)
Comment #13
Ignigena commentedI have just made some major updates to how the Makes and Models are stored to address some of the thoughts in #11:
Comment #14
Bob Humphrey commentedHello 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.
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.
Finally, I see that there are a lot of warning messages being logged when I run your module.
Best of luck with your continuing work on this module.
Bob
Comment #15
Ignigena commentedThanks Bob for taking the time to review my project. Appreciate the detail and testing you did.
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?
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.
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.
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!
Comment #16
summit commentedHi, 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
Comment #17
Ignigena commentedHi 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!
Comment #18
Bob Humphrey commentedHi 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:
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
Comment #19
rotty_dean commentedHiya, 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."
Comment #20
summit commentedHi, 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
Comment #21
sah62 commentedThanks 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.
Comment #22
srutheesh commentedHi ,
There is still some coding standered issue.
Link : http://ventral.org/pareview/httpgitdrupalorgsandboxignigena1650668git
Comment #23
Ignigena commentedThanks 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!
Comment #24
Ignigena commentedJust 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!
Comment #25
sah62 commentedThanks 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.
Comment #26
sah62 commentedAnother 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.
Comment #27
srutheesh commentedHi 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 .
Please fix the vehicle make issue so that i can check the vehicle functionality.
Thank you,
Srutheesh
Comment #28
sah62 commentedI 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.
Comment #29
Ignigena commentedThanks 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.
Comment #30
Ignigena commentedSrutheesh: 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.
Comment #31
Ignigena commentedsah62: 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!
Comment #32
sah62 commentedDone. Thanks for the other changes.
Comment #33
klausiSorry for the delay. Make sure to review more project applications and get a new review bonus and this will get finished faster.
manual review:
Otherwise looks RTBC to me!
Comment #34
Ignigena commentedThanks 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.
Comment #35
klausino 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.
Comment #36
sah62 commentedCongratulations, 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.
Comment #37
Ignigena commentedThanks 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 :)
Comment #39
tonkatuph commentedI 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.
Comment #40
Ignigena commentedtonkatuph: can you post this to the issue queue on the project page? This will help to track and fix!
Comment #41
tonkatuph commentedSure, but I'm not sure where to post it. Newbie here ;D
*Update: I figured it out. Thanks.
Comment #41.0
tonkatuph commentedAdded project review link.