Implement unique URLs for particular products on product displays

I thought we'd talked about this a bit before in a related issue, but I can't find it. : )

I think the solution is going to be to use some sort of GET variable in the URL to indicate the particular product selected. It would be nice if we could update this as the add to cart form is being manipulated ... maybe that's possible through some sort of anchor tag instead? Then when the add to cart form is submitted, it can just redirect back to this canonical URL instead of the general node URL.

Here is a proposal for this:

Repo: git.drupal.org:sandbox/pcambra/1081200.git
Branch: 1082596
Diff: http://drupalcode.org/sandbox/pcambra/1081200.git/commitdiff/ccf1575dc0d...

Ok, I gave it a second thought and I come with a much simpler and cleaner solution:

Repo: git.drupal.org:sandbox/pcambra/1081200.git
Branch: 1082596
Diff: http://drupalcode.org/sandbox/pcambra/1081200.git/commitdiff/2e2a5a19999...

I don't suppose there's some way for this to work through an anchor identifier vs. a GET variable?

i.e. http://www.example.com/node/4#product-14 vs. http://www.example.com/node/4?product=14

I'm not sure that really makes a difference, though. I would like to see the actual URL of the page updating as the option is changed so it's easy to bookmark particular product selections... but perhaps that should just be a separate issue. I'm guessing that'd take some JS work and testing for degradability.

Here is the change with a js perspective

Repo: git.drupal.org:sandbox/pcambra/1081200.git
Branch: 1082596

Attaching a patch because I don't know if I can make a diff in the repo viewer when there is > 1 commit in the history.

Anyway, when you change the hashtag, by default it doesn't refresh unless we do something similar to http://plugins.jquery.com/project/hashchange

Note that the multiple attributes is not covered for this method, I'm not sure what's the best solution for that as we have the actual "machine name" of the attributes instead of a product id in the page.

Why won't this support multiple attributes? Even when there are multiple select lists, it all still boils down to referencing a single particular product ID.

Using the hashtag makes that all the process happen in the client, and when we expose the multiple attributes (like dependent size-color), the product id is not exposed in the html, only the attribute values, we would need to expose the product id or do a much heavier js code, that probably would need to hit database to get the combination of attributes for a given product id, or maybe changing the hashtag to be #product-attr1-attr2-...

Perhaps we need to revive a hidden field for the product ID then to accommodate multiple attributes. This patch is incomplete without that support. Also, I noticed in testing that after you change the selector once and it sets a fragment, it won't do it again on any subsequent selections. Also, even though using the fragment results in the proper product being selected on the page, the fields that are rendered are still the fields for the default product (i.e. in my form, I have Product One = $10, Two = $20, and Three = $30, and adjusting the URL to select Three by default still shows a price of $10).

I'm also wondering if we should use #product-[product ID]. I'm not sure what I'd use instead, but is it bad to use an English word in the URL here? I suppose it may not be enough to just use the ID itself (i.e. #3), but perhaps it would be better with a more abstract identifier (like #pid-3)?

Just ran into that issue !

Having a specific URL for each product "variation" of a product display would be the best, especially for SEO...

Being able to produce a URL based on the product attributes may also fix the problem of "inconsistent" display path in the line items of the cart (the product in the line items seems to always redirect to the default product variation of the product display, not the actually added to cart one !)

I fully agree with #13.

I've came across this issue by accident since I did not find it right away. That means I've tried all solutions described above myself. I can only add that
- when using #5 only the cart options are correct, not the rest of the product fields I displayed (E.g. imageslideshow per product)
- when using #8 it will work and even with modifications so that it sees url-changes-hash-tag-included, it's not that user friendly (let alone SEO friendly) to do it ajax way on page load.

Summary of what I see in this issue

- This is a big issue when you click the cart link and endup seeing a total different product. The status of this should be at least major since it just does not work in real life yet for product variations. So it's a bug as well.
- We need a full url, or maybe GET parameter product_id. If we use the hashtag, then the javascript would need to follow when on url change too.
- It's best to not use the ajax method on the canonical url page as this is not SEO and user friendly. I think the better solution is to have a loaded the correct product ID from parameters in the url. I don't like get params much, but it seems the best solution here. Maybe an alternative would be to be able to use it in the real node path (E.g. node/1/product/44, which would be url aliassed as shop/product1 and shop/product1/product-title-for-44). I don't know if that's doable yet.

I am currently checking how the node_view starts and where modications would need to be done, so the complete page knows about it. The first problem is the fact that it does not seem to be enough to change the form state values as some other product fields could be displayed as well.
Does this seem reasonable?

So for me, my view mode for the product display needs to be refreshed will the reference field and some separate product fields, delegated by the commerce_product_reference module. I also saw there that you must have the reference field configured for the standalone's to work.

So fixed with this patch:
- node/product-display?product_id=[product_id] (E.g. in the cart view I now use that link on added products)
- Fix in the cart module as in patch #5 to change that option field on product variants
- When product nodes are rendered, there was a hardcoded ->get(0) invoked on the entity wrapper. When changing this to a possible GET parameter, it works great.

I don't think this is the best way as it would be nice to have a clean url for this as well.

I checked at the patch of Stalski #15 and it seems like it cannot be applied to the latest RC release of DC.
Did any maintainer had a look at this patch to potentially apply it ?

Thanks !!

Patch #15 did apply correctly for me on RC1, but it triggered some errors when testing.
After watching the patch code it seems the $node variable that is used there is never declared.
Also getting the right language key could be avoided by using the entity_metadata_wrapper() created object.

So attached is an updated patch that seems to set everything right if the product_id $_GET parameter is found.

I guess the line item links should also be automatically updated with the ?product_id query if a product display has multiple products entities assigned to it...
I'll have to look into that some more later though.

subscribe

Does #17 patch have any chance to be committed to drupal commerce ?
This issue is quite blocking for integration of popular sharing widgets (facebook, twitter, ...) as each product doesn't have a specific url

An issue summary here by one of you who has participated would help this go forward, I would think. (Just edit the node, and use the template offered.)

Triaging, this is not technically a bug.

patched against 7.x-1.x-dev (2011-Nov-06), it works!

That patch works as presented, but we're not decided this is the way forward (namely, I'm interested in any side effects using a GET variable like this will have). Leaving in needs review for now.

Just throwing an idea see if can be done ..
What about using the url rewrite function to rewrite clean url with get parameters, is this doable ?

FWIW Views is handling pages argument pretty nicely with slashes...
For instance, if i create a view page with a contextual filter, arguments are passed by the url separated with slashes : views_name/arg1/arg2/arg3....

if we had a product display node/14 with and products with COLOR and SIZE attribute, the url may look like this : node/14/red/small
Then if the options are not pointing at any of the product variation available in the product display, it would fallback on the first product reference, and display it as it is doing right now.

Does it sound like a decent solution ?

Yeah, I was actually wondering if something like that would work. I just don't know how that would play with pathauto.

Hello, I am trying to use the patch against the 1.1 version but I can't figure out why it is not working. Anyone has been able to figure out something with the latest version?

Hello, I change the status back to active since the patch doesn't work on latest code.

#17: canonical_url-1082596-17.patch queued for re-testing.

#15: canonical_1082596_15.patch queued for re-testing.

It's just going to need some work to apply. I even went back and applied it to the July version and then tried a merge, and the merge conflicts were pretty intimidating.

I would like to use direct product url for Google Merchant Center feed, it is recommended to have an unique url to each product variations. And what about utilisation of the Flag module on a product display with several product variations ? I had in mind to use Flag to give possibility to create gift registry on my website. So the married could flag each product variation to make their own gift registry.

subscribing

The Views approach in #25 looks the nicest by a country mile, IMO. But i'm not sure replacing / replicating all product display nodes via Views is that viable?
Has anyone tried this approach yet?

So far, this is the only feature (or lack thereof) that I've found that's rubbed the shine off DC - otherwise it's pretty much awesome. It's seems like a fairly fundamental requirement and it's a shame there isn't yet a straightforward solution.
Fingers crossed someone finds a good solution :)

Yeah +1 for views-approach as #25. Would love to have a solution for this!
Greetings, Martijn

Hi,

I have added patch #17 and http://[siteurl]/node/56/product-display?product_id=[104] is not showing the correct variant...
what could be the case please? Am I doing something wrong here? Do I use the wrong url? I would love to have this working, Then I can better show the correct product-variants.

Greetings, Martijn

I set this to needs work, if thats ok, the url node/[nid]/product-display?product_id=[product-id] is not showing a node-view with attributes related to the product-id.
If this is wrong, sorry, but I am not able to get this to work using #17.
Greetings,
Martijn

Hi,
I thought about this more. I think the best solution would be if the url would be

[siteurl]/[node-alias]/[attribute-name1]/[attribute-name2] etc..

So for instance this will be

[site-name]/doll/red/25mm

I think this is suggested in #25 using views! This would be great for SEO, userfriendlyness and site seriousness!
This also makes it really possible to have the product-displays shown to the customer, and the products/SKU's only have as backoffice material.
Would love to have this working and I think a lot of people are waiting for this, right?

Greetings, Martijn

It's not an oversight so much as a difficult technical challenge. Still waiting for a good solution to surface; we really just need more research into this. I don't suppose you have any experience with this type of functionality on other systems?

Hi,
The solution should use pathauto to have nicely formed url like:

[siteurl]/[node-alias]/[attribute-name1]/[attribute-name2] etc..

The pathauto [attribute-name1]/[attribute-name2] variables should trigger the right show off of the attributes in the add to cart form. May be this can be handled by views?

This way the in #40 explained misleading message to the user is corrected, the url's are great for SEO, views gives may be also other options for this when necessary and last but not least finally I can really only use product entities in the backoffice. Right now to get to a product I need to customize a view and use the product-id in the url..which is not the favorable way for this!

I am not a programmer, but would love to test a solution for this!
Greetings, Martijn

The problem is that a URL like that can't be updated as the form is updated. Additionally, it isn't very clear how we can communicate items from path arguments like this to the proper Add to Cart form on the page.

Hi, May be somebody from drupal core has a solution for this, or somebody from similar modules which have url/form connection?
Greetings, Martijn

Hi,

May be it can work the other way around. By adding the add to cart form to:
http://drupal.org/sandbox/davereid/1643530 ?
I made an issue there: http://drupal.org/node/1664650

Greetings, Martijn

Hi, set this to active, because I think there has to be made a solution from scratch on.
This is really for me a big issue still because on the one hand you don't want to show the products to the customers, but on the other hand there is no choice now, because the node-system is not working correct with attributes. Like explained in http://drupal.org/node/1082596#comment-6121660
Greetings, Martijn

Hi,

Can this module maybe help? http://drupal.org/sandbox/Perignon/1587818 ?
Greetings, Martijn

We had a chat about this last night at a Drupal meetup in Cambridge. Two interesting points were raised:

1) From an SEO point of view, different *clean* URLs for product variations woul likely be viewed by Search Engines are duplicate content. To use the summary example, If you have a t-shirt print that has multiple fabric colours and sizes, then you create a new product display node for that print. Changing the fabric colour or size via a select box / radios doesn't actually change the content of the product node (other than perhaps changing the image if present) and so for any individual t-shirt print available in three colours and three sizes there will be 9 URLs with exactly the same content... You could write alternatice copy for each product variation (as if!) or perhaps the solution here is that there is a canonical META tag in the page, referencing the root/default product display node URL. If this is the case, then I think the Issue title is slightly misleading - we don't want canonical URLs for product variations, we want unique URLs along with the functionality to have preselected form elements based on the contents of the URL, and one rel="canonical" META tage in the page template pointing to the default product display node URL.

ref:
http://www.seomoz.org/learn-seo/duplicate-content
http://www.searchenginejournal.com/are-you-making-these-7-panda-punishin...

2) A potential solution to the overall problem, which would likely only be viable on a smaller-scale ecommerce store, would be to simply create a new product display node for each product variation. This would obviously be a more long winded approach, but it should work out OK.

Thoughts?

Thanks for the insights, Carl, and I'm glad to hear it was the topic of conversation at a meetup! I think I initially used the term thinking of supporting GoodRelations, and RDF ontology for describing eCommerce data. In such a case, I was under the impression they expected an individual product to have a unique URL without really accommodating groups of like products (the proverbial t-shirt in various sizes).

However, I think you've summarized the more pressing need - a URL that when loaded will pre-select a particular product on an Add to Cart form, or in terms of the Add to Cart form builder function, will override the form's normal method of determining the $default_product on the initial pageload.

I hadn't thought about content duplication at all and am happy to take any recommendations, such as your meta tag. I'm a total newbie when it comes to meta tags, so I won't pretend to have any comments on that just yet. ; )

For solving duplicate content problem we can use meta canonical tag, it tell main url for search engines, so other urls they adds as mirrors. More about this tag you can read here http://support.google.com/webmasters/bin/answer.py?hl=en&answer=139394

But on my site I need to index each product page, because products have many differences. For each product url (I do this via hook_form_alter, so each product have separate url: node/1?sku=123, etc) I change page title (h1), image, price, product description (I add to each product textarea field), and pages becomes unique for each product and I don't need canonical url.

Example of this you can see on http://caramba-shop.ru/product/zazhigalki page.

rerolled patch #17 for 7.x-1.3+27-dev (2012-07-11)

added a line in the cart module as well, as without that, the #17 worked only partially.

This patch just uses a GET variable, so before we go in that direction, we'd need to ensure this is compatible with search engines / RDF ontologies like GoodRelations and whatever else. I don't want to leave us open to unintended side effects here.

I was just rerolling the previous patch, as i needed this functionality at the site i was building.

And i thought i might as well post it.

But i hope there ll be a solution for this later on so i dont have to use more and more custom patches :)

Hi,

I want to add something to this sentence of @rszrama:
a URL that when loaded will pre-select a particular product on an Add to Cart form, or in terms of the Add to Cart form builder function, will override the form's normal method of determining the $default_product on the initial pageload.

I think a URL should be build with pre-selecting a particular product and on this form the other selections should be able to be selected also. When selecting for example another color, the url should change accordingly.

Of course the double/multiple content issue should be tackled also by meta canonical tag. May be this can be made a setting what the meta canonical tag will be for a certain productrange.

Greetings,
Martijn

Hi,

Firstly, the patch in #51 appears not to correctly set the entity as the item description and image is loading, but a colour select is not getting set - perhaps a defaultvalue conflict?

Secondly, regarding SEO and duplicate content it is worth recognising that a url parameter can actually help, as the search engines are smart enough to understand these are used as parameters to alter a page's content and if the canonical is declared without the terms and the terms are only used as an attribute modifier there will be no SEO penalty. It would mean that there would not be rankings for a blue t-shirt and a green t-shirt - but then that's the point of removing duplicate content. (A side note: the trend for pretty url's is going too far if it can stop/delay an important feature like this).

I believe DC needs a solution to this problem without the need for a patch, else how can it be widely accepted for ecommerce with any form of attributes - without it you cannot link a customer to your red t-shirt or have a user share their favourite flavour ice cream on Twitter...

Regards

First and foremost thanks to the team @ Commerce Guys and everyone who contributes to the project at large. Greatly appreciated.

Wanted to echo the need for a solution to this issue. A unique URL per product variation is a must.

Regards,

capnjav

Added missing commerce_cart_field_formatter_view() modification.

Hi Maciej Zgadzaj,
Is with this patch this functionality working? A specific url per unique product? I mean a product with one or more attributes?
Very curious for a screenshot?
Greetings, Martijn

Yes, unique ?product_id= urls for each product variation. Haven't played with it very much, although so far seems to be working fine, including Add to Cart form attributes.

http://ow.ly/i/18uf0
http://ow.ly/i/18ugc
http://ow.ly/i/18ugs
http://ow.ly/i/18ugN
http://ow.ly/i/18uh5

Thanks will try it!
It is working for a part
not SEO friendly, but working, See:
http://www.zwangerschapsbel.nl/node/58?product_id=109 (20mm version) or
http://www.zwangerschapsbel.nl/node/58?product_id=110 (25mm version)

Would be great if the alias would be able to hold the attributes!:
For example for these urls:
zwangerschapsbel.nl/verzilverde-hartvormige-zwangerschapsbel/zilver/20mm and
zwangerschapsbel.nl/verzilverde-hartvormige-zwangerschapsbel/zilver/25mm.

Greetings, Martijn

Alternatively, if someone doesn't feel like patching, this should help too.

Hi,
Thanks for building a module for it. It would be great if this module would be a start to get great SEO-based product urls!
Greetings, Martijn

I've made some bigger changes to Commerce Product URLs module - feel welcome if anyone cares to take it for a test ride...

I know Ryan doesn't want to commit to using Get variables, however, I think there is a good compromise. This feature has been critical for some of our projects, and we've had to patch Commerce to accomodate it, which obviously is not ideal.

So here is what I think would be best, at least for the 1.x branch.

Create a new hook for modules to implement that can set the default product. It should just pass in the list of products from the product reference field, and the hook should return the ID of the what the default product should be. This way, site builders and developers can determine their own way of implementing unique URLs without hacking Commerce, and it would be backward compatible for all current non-hacked Commerce installs.

The patch above can be changed easily to accomodate this.

This provides the greatest flexibility while not endorsing and limiting Commerce to just one method. A new Commerce core contrib can be developed that implements the hook later, once the best path is determined, and it can be an optional module.

@jazzdrive3: I guess this is something you are talking about. Ryan has already said he's going to commit this...

#63 worked for my purpose and didn't cause any trouble that I can tell. Excellent work!

hook_commerce_product_reference_default_delta_alter does work to set the default product on the Product Display node itself. However if you create a view with multiple products being displayed as a catalog, the selection has the correct product, if you add the product to a cart it is the right product, but the sku and price reflect another.

Any thoughts...?

Added a summary of the issue, with the different solutions that have been worked. The original post remains untouched

Big thumbs up for everyone working on Drupal Commerce! Wouldn't have been able to get so far without your collaboration :)

Is there a followup on this issue or a summary to tell me where to go from here?
Seen many suggestions above but am not sure what will happen if I use one patch and another gets included in future update. Also not clear about comparison and future of suggestions since these seem to be a little old :/

Have been working on a site for months to get it perfect with two ways of viewing:
- Collections (to choose variation later) or
- Variations directly (to just browse availability and extent of variations -> 3x size & 2x Finish)

So , no matter which variation you spend time on finding, in the end you have a very good chance of ending up with the wrong choice on the Display node.
I cannot launch until this issue has been resolved, because chances are high of misplaced orders.
So what do you think is the way to go for me?

Big thanks again.
Alec

Hi,

I'm also fighting a long time with this issue.
At this moment, the "best" solution is using the Commerce Product URL module (https://drupal.org/project/commerce_product_urls).
It is not perfect but it is already a good step in the right direction.

I'm using Panels at the moment, where it is easy to make a different setup for a single variation or a display node (collection of variations).

The good news is that in Commerce 2.0 (Drupal 8) you can create a display for a single variation, without creating a display node (if you don't need to combine several variations)

Related Feature Request #2365317: Views | Display the product variation accordingly to the attribute being applied as filter

I haven't reviewed all of the code above however just a note, you can easily set a default product in a custom module using
hook_commerce_product_reference_default_delta_alter

@Andrew211 See the link in #69
https://drupal.org/project/commerce_product_urls

It works quite well and it's doing what you are suggesting.

I gave commerce_product_urls a go and it's a great module. The issue I ran into was that the hook being used doesn't seem to work when coupled with commerce_bundles. I ended up creating a module that uses jquery to update the attributes so that it works on standard product displays and bundles.

https://www.drupal.org/project/commerce_pdas

edited file from last version with some details
one man make patch file form this :)