AJAX Showing Access Denied After Upgrade

Definitely need to get some tests on this.

Here is a reroll of #3 that applies to the latest dev.

Damien,

I am interested in working on the tests for this - however, I am hoping you can give some insight on where they should go and what they should test. I'm thinking that they could work with permutations on default and customized panelized nodes testing panelizer_panels_cache_get() and panelizer_default_panels_storage_access()?

Should I create a new general test file for testing the cache settings or storage access (panelizer.cache.test) or should I include some tests within the panelizer.with_panels_ipe.test since this issue seems to be focused on IPE issues?

Lets make sure the latest patch applies.

Oh darnit, the tests are failing because of #2468907: Refactor tests to remove dependencies.

The patch in #10 applied cleanly for me and resolved my issue. Thanks!

The Drafty patch was committed, so lets rerun the tests.

Had to do an actual release of Drafty, so we'll see how the tests work out this time.

Yay! Ok, the tests are running correctly now, so we can work to fix the bug and add more tests.

Rerunning the tests..

You write
$entity = current(entity_load($entity_type, array($entity_id)));

But this is more customary:

  $entities = entity_load($entity_type, array($entity_id));
  $entity = reset($entities);

Whether it makes a difference may depend on the PHP version.

The patch seems to work for me by the way.

I have looked at this patch a bit further and I think it is not right. It adds code loading a specific entity in panelizer_default_panels_storage_access(). However, that function should only load for the default panel display. panelizer_entity_panels_storage_access() should be used to load entity-specific panels.

The reason that I encountered an error is that my database was incorrect. I don't know yet how this came to be, but in the table panels_display I had some rows where storage_id was a default, such as node:panopoly_landing_page:default, but the storage_type was panelizer_entity. This should have been panelizer_default. Maybe for you this was the reverse?

Just to make sure, for those rows where the storage_type is panelizer_default on your installation, is the storage_id something like 'node:xxx:' where xxx is a node ID?

I don't have time to dig into this right now, but I have access to both Views and Panelizer should a consensus be worked out on how to fix the problem. Thanks everyone!

Thanks for participating in this thread Damien. I think the problem is that there is a way for the database to get into a state from which it can't recover. I have no idea how. I think the first step would be to add some guards in the code modifying the data that prevents writes that would corrupt the data.

I think issue #2864607 is an example of a data integrity breaking situation.

We ran into this issue with different sites. #2864607 does not resolve the issue. I was digging into the code for quite some time and came to the conclusion, that the storage_id gets set differently. Somehow it was always "::default" e.g. node:my_content_type: default. But all the previous stored displays have "::page_manager" e.g "node:1234:page_manager". As described here, whenever I saved the page via "/node/1234/panelizer/page_manager/settings", it got reset to the expected value because PanelizerEntityDefault::hook_entity_update() sets the expected value.

Somehow the unpatched module does not provide the right mechanism to set the storage_id to something that is expected or handleable via code. I assume that get_default_display_name() that got added to the codebase returns said name due to some new variables?? I'm not sure how these values are set but that seems to be the issue here.

The patch solves the issue for now.

When storage_id is like 'node:123:...', storage_type should be panelizer_entity. When storage_id is like ':default' it should be panelizer_default. I think this is broken in your database.

The column panels_display.storage_type is "panelizer_entity", only the storage_id is different as described above. I don't know if these two values match. I checked a few of our databases and they all show this pattern with storage_type of "panelizer_entity" and storage_id of "node:1234:page_manager"

After updating from 7.3.4 to 7.3.x-dev and applying the patch from #10, this still doesn't fix the issue for me. What's weird for me is i don't get the access denied bit until I have finished saving the panelizer display. When I'm making it for the first time, no big deal. My display is for a taxonomy term page, not a node (not that it should make any difference, I think).

Hello !

I've updated the patch in #10 and it works well now for the release 7.3.4

Regards.

Thanks! I'll test the patch.

I just posted another version of this same issue before seeing this: https://www.drupal.org/project/panelizer/issues/3046658 . I'm fine if its closed as a dupe, but there may be some useful reproducing details.

I included steps to reproduce from fresh install. I tracked it back to roughly the same place, "panelizer_panels_cache_save" and/or "panelizer_panels_cache_get" .

Panels 3.6 adopted storage plugin.
Storage plugin is used to check access for operations.

https://git.drupalcode.org/project/panels/commits/7.x-3.x/plugins/panels...

Panelizer 7.x is not updated for a long. Also It's not follow up this changes.
Panelizer should to implement this storage plugin. Then i think this problem will solved.

Sorry for mistaken.
Panelizer 3.3 added panels storage support and work properly (tested with 3.4)

Hello,
I'm having this same problem with panelizer 7.x-3.4, patch in #39 works for me, I'm uploading here the patch updated using panelizer as the base (instead of sites/all/modules/panelizer).

I confirmed this is still an issue. Re-rolled for latest.