Closed (fixed)
Project:
Commerce Core
Version:
7.x-1.x-dev
Component:
Product
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
5 Apr 2013 at 08:55 UTC
Updated:
6 May 2013 at 10:50 UTC
Jump to comment: Most recent file
Comments
Comment #1
artusamakHere is a patch fixing that in the spirit of the current implementation (patch 1).
One thought though, we are displaying this help text for the SKU field: "Supply a unique identifier for this product using letters, numbers, hyphens, and underscores. Commas may not be used." it reminds me a lot the machine name field type. We could have used a dedicated element type for that i guess?
I believe that instead of a set of checks of chars to exclude we should go for an explicit list of what we are allowing (patch 2).
Comment #2
amateescu commentedWhile the second patch is clearly the better choice (even better if it was changing the check to use Drupal's #machine_name), that would be an API change and who knows what other funky characters might be right now in existing user's sites. So I'll vote for patch 1 :)
Comment #3
rszrama commentedYeah, we've gone over various restrictions for SKUs before and decided to leave them in their current state. However, the problem with patch 1 is there may already be sites using slashes in their SKUs who weren't using this widget or weren't referencing multiple products. Perhaps there is some other fix that doesn't involve restricting slashes?
Comment #4
amateescu commentedSure, we can fix the widget instead.
Comment #5
rszrama commentedThe problem here is that we copied some "dumb" code from core. It basically didn't define any arguments for the page callback, simply leaving it up to the menu router to supply bits of the URL... thus, the $string argument was only ever getting the first bit of the SKU preceding the /. I changed this to explode the path arguments, splice out the first 5, and then rejoin the final bits as the new $string, and it worked just fine with a local site using / in SKUs.
Commit: http://drupalcode.org/project/commerce.git/commitdiff/5cc24ff
Comment #6
thim commentedThis limit of split up based on the args causes issues with multi country/language setups.
Example: http://example.com/BE/en/commerce_product/autocomplete/commerce_product/...
Where BE represents the country
en represent the language
The rest is a normal autocomplete.
How do I resolve this?
I tried to use make the autocomplete path absolute but this does break the widget '#autocomplete_path' => '/commerce_product/autocomplete/commerce_product/line_item_product_selector/product',
Comment #7
thim commentedI filled a seperate issue for the problem.
http://drupal.org/node/1976426
The current issue is closed so not need to reopen.