It seems to me that resetting an entity's display to the defaults is as much an "update" to the entity as any other panelizer edits. I suggest we re-save the entity. I'm specifically interested in this as it will allow Entity Cache to play nicely with the reset button.

Comments

azinck’s picture

Status: Active » Needs review
StatusFileSize
new617 bytes
damienmckenna’s picture

I'd like to get merlinofchaos' opinion on this.

damienmckenna’s picture

Issue summary: View changes
Issue tags: +Check with merlinofchaos
damienmckenna’s picture

damienmckenna’s picture

Status: Needs review » Needs work
Issue tags: -Check with merlinofchaos
damienmckenna’s picture

Status: Needs work » Needs review

Lets get the patch reviewed.

damienmckenna’s picture

damienmckenna’s picture

StatusFileSize
new660 bytes

Strictly speaking this then means that the caches don't have to be manually purged.

The last submitted patch, 7: panelizer-n2082841-7.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 8: panelizer-n2082841-8.patch, failed testing.

damienmckenna’s picture

Status: Needs work » Needs review

8: panelizer-n2082841-8.patch queued for re-testing.

mglaman’s picture

Is there more steps to reproduce, test this? I ran through xdebug and could never get page_reset to run, which leads to executing $this->reset_entity_panelizer($entity, $view_mode);.

However, I did xdebug on Entity Cache and entitycache_entity_update() seems to get called whenever Panelizer settings (custom settings, content, etc) are updated.

Status: Needs review » Needs work

The last submitted patch, 8: panelizer-n2082841-8.patch, failed testing.

damienmckenna’s picture

Issue tags: +Needs reroll
damienmckenna’s picture

StatusFileSize
new671 bytes

Rerolled.

FYI I also created #2409373: "Reset to defaults" should work with revisions as I realized that revisions were not being handled correctly.

damienmckenna’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll +SprintWeekend2015
mglaman’s picture

Again, I think this is working as expected. This patch is within delete_entity_panelizer() method.

  public function hook_entity_delete($entity) {
    $this->delete_entity_panelizer($entity);
  }

I tried to find usages of this method, and this is the only time it is used - the hook_entity_delete() method. It doesn't seem to hurt anything by trying to save the entity, however resetting caches seems less harmful then attempting to save the entity.

Resetting a view mode invokes reset_entity_panelizer().

    // Only proceed if the view mode was customized for this entity.
    if (empty($entity->panelizer[$view_mode])) {
      drupal_set_message(t('Unable to reset this view mode'));
    }
    else {
      // Identify this entity's bundle.
      list($entity_id, , $bundle) = entity_extract_ids($this->entity_type, $entity);

      // Update the panelizer_entity record.
      $entity->panelizer[$view_mode]->did = NULL;
      $entity->panelizer[$view_mode]->name = $this->get_default_display_name($bundle, $view_mode);

      // Update the entity.
      $this->entity_save($entity);

And this does invoke an entity save. Both methods delete items from the panelizer_entity table and remove entries. Except the reset is working as designed, and as requested in the issue.

damienmckenna’s picture

damienmckenna’s picture

Should it also remove the $entity->panelizer records?

socialnicheguru’s picture

Status: Needs review » Needs work
Related issues: +#2798325: Segfault when trying to save the smart_ip admin page

This caused smart_ip module not to work. With this patch enabled going to admin/config/people/smart_ip caused WSOD and a segmentation fault. https://www.drupal.org/node/2798325

this was on a clean install