Why commerce products become "Access denied"?

I was trying to apply patch to latest commerce dev version, but unfortunately got error fo:

• ../commerce_product.module:85, and
• ../commerce_product_ui.module:263

May I ask what would be the reason for this error? Used git apply method.

What I've done, is download latest dev of commerce and entity_translation, saved patch file in commerce folder, and applied "git apply ....patch". Manually checking differences in patch actually led to fact, that there are no such line items to be removed or replaced, and it seems, that it's already included in latest dev.

Regarding editing, I've deleted all former products and recreated them from zero. Was not too much, and at least I have an option to edit them. But what I do not get yet, is what is the practice of creating translations for commerce products. I do not see any Translate tab in commerce product type form. I create product display, and within it create referenced product node. It apparently creates it. Then how translations should be added - via Commerce product type form, or via display form?

Sorry for posting another question within this one thread.

Yes, that is what I've done. I was experimenting with product display type and entity translation, but decided not to introduce entity translation on product display content type. Now, when I create new product under admin/commerce/products/add/product, I've got this error:

Notice: Undefined property: stdClass::$language in EntityTranslationCommerceProductHandler->getLanguage() (line 33 of /var/www/public_html/sites/all/modules/contrib/commerce/modules/product/includes/commerce_product.translation_handler.inc).

In addition I've enabled checkbox to let users translate Title field in Product type (replaced with Title module). But still can not manage to go through. I am still in need to filter product display nodes per regular Internationalization option, as I have to get different display nodes on different languages, but still let it work with entity translated product types.

I've reinstalled latest devs for ET and Commerce and this time your advised patch applied correctly (http://drupal.org/node/1495570#comment-6542408) Language error indicated in my note #7 dissapeared.

Please give me another 30 minutes to test issues out, I'll report back...

Would like to confirm, that things seem to be working as expected. Here is a short brief of what's been done so far:

Basis

I was inspired by Drupal Commerce Kickstart (dev 2.x), initially installing this distribution. But as soon as I got acknowledged with it and started to play with rules and multi-language settings, things messed up, and I decided to rebuild Commerce from zero, trying to introduce as much as it's achieved in Commerce distribution.

As I had to build this for multi language support, initial part of this project is connected to proper multi language configuration and seeking for right tools.

So I went with Search API, Facet API, Views, Entity, Commerce, Entity Translation, i18n and a bunch of other modules, yet no Entity Cache introduced.

Choosing multi-language workflow

Despite other issues, main difference by going pure Internationalization (i18n) way or go with Entity Translation is in fact, how nodes are considered by Drupal. In short - if we go pure i18n way, each language node is a separate node. If we go with ET - there is only one node for all languages. There are pros and cons, regarding choice of language handling. Additionally I use Fivestar widget to rate products, but as I've decided to go i18n way for Commerce product display nodes, my rating is separate for each language, yet the same product in terms of Commerce product type.

Mainly my choice was connected to fact, that I have chosen Search API and Facet API to provide product sorting screens, which actually do not work well with ET solution, as all nodes are considered to be original language, so not letting me filter out display nodes by current user language. Mainly in facets and display nodes handling. But still ET does the job here, presenting translated fields, but not facets - taxonomy terms in proper language.

So, what's working?

Latest devs up till today of:

• Entity (7.x-1.x-dev 2012-Sep-07),
• Entity Translation (7.x-1.x-dev 2012-Oct-15) and
• Commerce (7.x-1.x-dev 2012-Oct-13).

To overcome Language selection issues and probably Access denied issues (mentioned in this thread above) regarding Translation tab availability, I applied plach's recommended patch (http://drupal.org/node/1495570#comment-6542408). I actually can not say, why this patch didn't apply initially, but after full module deletion and installation again, patch applied without any errors, and my Language selection and Access denied errors went off.

Now I am able to create new products in admin/commerce/products section, and am presented with Translate link besides each product, where I can choose language and translate field (Title) configured for this.

After all, I create a bunch of product variations, translate these, and further move to display node creation (i18n style) - separate node per language. I fill up fields in product's display node, assign taxonomy terms (translation provided via i18n bundle module) and add existing product variations. Initially I do this in English, which is site's default language.

After I am presented with Translate tab, where I choose to add Translation to another language (creating new display node). Translating all fields but product reference fields, which are automatically populated, still in original language, but I leave it so.

After I save display node in other language, ET is replacing English Title string with particular language string, and display nodes are separated by languages in Search API type view. Including correct language taxonomy term representation in particular language view.

My settings

Regarding ET introductions:

• Enable language fallback
• Display shared labels
• Select which entities can be translated: Node; Commerce product
• Details for Commerce product: Selected Author's language and no checkboxes at all

Languages selection/detection (admin/config/regional/language/configure):

• Selected/added all necessary languages, still leaving English as default, manually added en prefix for English default, to make clear separation, as I am using prefix for language separation.
• User interface text language detection: URL; Default
• Content language detection: Interface (moved to top manually); URL; Default

Commerce product type settings (admin/commerce/products/types/product/edit):

• Enabled via Entity Translation

admin/commerce/products/types/product/fields

• Replaced regular Drupal Title field with Title module, and in this field settings checked, that this is the only field in Product type I'm going to allow translation.

Product display node content type settings from admin/structure/types/manage/{your-display-type}

• Published options > Multilingual support - selected: Enabled, with translation (NOT Enabled, with field translation, as I'm going to use i18n for language and node separation).
• My title field in this display node, which is overridden by Title module is left for field translation, as these are per field settings, not per content type.
• There are no any other fields let for ET translation in product display node, even product reference field (used with inline entity form).

Basically that's all. Taxonomy term translation is handled by i18n modules and Taxonomy vocabulary has Translate... (NOT Localize...) settings - different name for each language tied into translation sets.

Search API is using search_api_db sub-module for search handling.

Hope somebody might find this valuable in development. Unfortunately I can not comment on this more in depth of modules and PHP, as I do not have deep knowledge in programming. But still managed to achieve this via WUI.

And plach, thank you for assistance!

reysharks: As I think now, not the easy one. It all depends. Both configurations (Commerce Kickstart vs Commerce) might be quite different.

I'd go with Kickstart version analysis (what functionality is needed/used) and then go with building new one step by step. After add/re-create products. If there is large quantity of products, variations, etc., then probably it would be the best to use some kind of import (thinking of Drupal import modules, like Feeds or MySQL scripts, if any could be developed).

How many products/variations do you have?

Here is video, which helped me to get grasp of overall Commerce idea. Seems to be easy, but not quite so :) http://www.youtube.com/watch?v=ViS2xFvnZwc At least it explained to me parts of module and their operations, where Kickstart configurations and use became clear.

If that's achievable (not too many products), I'd go with clean product creation. This would help to get rid of some artifacts of incorrectly configured or functioning modules/rules/relations. And add some understanding on particular use/functionality of module or rule.

Unfortunately I have abandoned that project since, as customer decided to go with OpenCart. But step by step something could be recovered from my mind. Actually in a week I'm going to start one Commerce project, so it would not be too hard to test some things. But I'll definitely go from scratch.

Any other means of helping?

How many products?

So, pure i18n would not be an option? Main difference here would be that language sites could be counted as completely different ones. E.g., if you fill shopping cart in one language, switching to that cart would display site in one language, but products - in other.

This is not the ideal way, but still it's a solution. To migrate everything to clean install, would not be optimal for sure.

I would not consider one or the other way more or less correct, as it depends on actual needs. Personally I look at product node as a row in Excel table, where accountable values are entered - SKU, Title, pricing, options, etc., but would leave description to display node. (There is a distinction between product/display nodes, which might to become mixed very easily). So, if everything, that's connected with product display to end user, is configured under Product Display node, not product node.

Such a way, it would be possible to provide different content for different countries/regions, accompanying it with native or close to native language. And it would still leave option to manage product stock, pricing, discounts, etc, native way.

I'd bother on Entity translation in Product nodes only for title and text fields (assuming description could be Rich text field, which probably would not be supported, but it might take time, or it's already solved).

Would it be an option for you to move description field to display node? Then i18n would be easy-peasy.

Regarding other translation options or modules, I'd suggest to look at site from birds perspective, as from one side, they might give you instant solution for current problem, but afterwards introduce others, say WYSIWYG integration, Voting API, etc. Things have to be checked.

I remember for sure, that I had an issue with Search API and multilingual category faceted search.

From my perspective it seems, that Necklace is a category of product (taxonomy), and all mentioned products are Display nodes, if you need to provide different description on material used in products, where Product node would be color/stone combinations.

Or you can go more granular way, if color/material differs price, or even go with variation bundles. Any way, it reduces to Product nodes with just title field, SKU and pricing.

It would give user less clicking, where one Display node would describe used materials, and visitor can choose from product variations. Or even if this is not as intended, each your mentioned Product 1-N are display nodes.

This way, it still makes sense, and prevents you from burden of changing thins on module level. And any way, you have to rework or rebuild something.

Sorry for some misleading definition, although not completely wrong. "Necklace" could be either Taxonomy term category, or Product type. Just found blog with quite simple explanations of Commerce issues:

http://thedrupalnewbie.blogspot.com/2011/11/planning-your-products-and-p...

Actually this discussion is becoming off topic, as main Ticket task was to solve Access denied errors on existing products.

If you are still interested in further discussion on options, please be so kind and PM me, to continue via e-mail.