I am trying to set per field caching on drupal commerce. So I get to "price" field on product, but I can't do anything as

"Price is locked and cannot be edited." is shown there, which is done by drupal commerce, but then we cant't apply this module to that field. Is there a way around it for locked fields?

Comments

Marko B created an issue. See original summary.

Marko B’s picture

Title: Price is locked and cannot be edited. » Price is locked and cannot be edited
znerol’s picture

This might get tricky. Not only because of the locked field, but also because Drupal Commerce is somewhat complicated when it comes to the add-to-cart form and the way it collects fields from the product (via product reference) and places it on the node (i.e., product display). Before diving too much into those technical difficulties, please provide some background on your motivation of loading the price field via Ajax/ESI. Maybe there is a solution to your problem which is simpler?

Marko B’s picture

So I have product display that has price. I am trying to use auth cache to put whole page in cache_page. But for price I need ajax, because, price is different per IP. I have international store, and we are displaying currency per country. So language is not in works here, although we also have 12 languages. Price is determined with rules and changes accordingly. I am rendering this product display in template as

        <div class="price-block">
          <?php print render($content['product:commerce_price']); ?>
        </div>

which is the field that comes from product entity itself. I am trying to see If I can lift the block on price somehow, just to see if it will work.
Other Idea I just have is to maybe make this price field a VIEW block or VIEW EVA field and then try to use auth cache on that. Would like to make use of it as auth cache field though, hoping to make it more standard. Thoughts?

Marko B’s picture

I am wondering how could I enable auth cache with form/code. So I could bypass "The field Price is locked and cannot be edited." I am guessing this should be possible?

Marko B’s picture

Ok so what I did in the end is
1. Unlocked the commerce_price. with (http://drupaldump.com/price-locked-and-cannot-be-edited-how-unlock-or-an...)
2. Then set authcache to that field. Then another stumbling block. I hit authcache_cancel(t('FIXME: authcache_field - what should we do with custom view_modes?'));
3. I did what i wrote here, as this should be another topic https://www.drupal.org/node/2580237 and then it worked for me.

Wondering still. How could we set authcache to fields, blocks, views with code? and also your thoughts on this other topic?

znerol’s picture

Glad that you found a solution which works for you.

For most fragments the settings are stored as part of the elements configuration. For example you can export a view and the authcache settings will be present there. Same for fields and panel panes.

The big exception is blocks. This is because there is no built-in way to manage block configuration. Settings which are not saved as part of an elements configuration is stored inside variables. Use something like drush vget | grep authcache to list those.

znerol’s picture

I have international store, and we are displaying currency per country. So language is not in works here, although we also have 12 languages. Price is determined with rules and changes accordingly.

You also might consider customizing the authcache key such that it takes into account the requests origin (IP address zone).

Something like this:

function MYMODULE_authcache_key_properties() {
  return array(
    'ip_zone' => MYMODULE_determine_ip_zone()
  );
}

function MYMODULE_determine_ip_zone() {
  $zone = 'default';
  $ip = ip_address();
  // implement your magic here
  return $zone;
}

Like this you end up storing multiple versions of a page in the cache varying according to your custom requirements.

znerol’s picture

Status: Active » Fixed

Guess this is answered. Please open a new issue if there is still something unclear.

znerol’s picture

Category: Feature request » Support request

Status: Fixed » Closed (fixed)

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