Comments

dsnopek created an issue. See original summary.

dsnopek’s picture

Status: Active » Needs review
StatusFileSize
new1.25 KB

Patch is attached! I'll start a build on Travis in a moment.

EDIT: Here's the Travis build: https://travis-ci.org/panopoly/panopoly/builds/153087240

dsnopek’s picture

Blergh. Unfortunately, all the tests are failing now. It could be a gremlin but I haven't had a chance to look into it yet.

pieterdc’s picture

Some changes look like they need more attention than just applying the patch when upgrading Panels in an environment with some custom Panels extensions.

Panels its UPGRADE.txt now states:

Upgrading task handlers from Panels 7.x-3.5 or older to Panels 7.x-3.6 and newer:

- You must specify a storage type for any panels display using your custom task handler.
For examples, see panels_update_7306.

- When creating whatever stores the panel, a storage id and storage type must be defined.
See panels_mini.module for examples inside panels_mini_save and panels_mini_panels_cache_get.

- A display access plugin must be defined.
See panels_mini/plugins/panels_storage/panels_mini.inc for an example plugin.

panels_renderer_ipe now does access checks.
...

dsnopek’s picture

StatusFileSize
new9.42 KB

Ok, I figured out what is going wrong. All the Panels displays that we exported to code don't have the storage_type and storage_id set on them. Here's a patch to panopoly_test just to demonstrate what's going on - got the storage type/id set in the database and then reexported to the Feature. I'll even try with the tests to double check that this is the issue.

Here's a snippet to show:

+  $display->storage_type = 'panelizer_default';
+  $display->storage_id = 'node:panopoly_test_page:default';

EDIT: Here's the test build: https://travis-ci.org/panopoly/panopoly/builds/153104500

dsnopek’s picture

StatusFileSize
new11.72 KB

Here's a 2nd attempt at just the panopoly_test changes. This should get more of the tests passing on Travis.

bkosborne’s picture

^ the problem you described is a major problem for anyone who has panels defined on code, beyond what Panopoly provides =/. Someone else ran into it here: https://www.drupal.org/node/2785915

dsnopek’s picture

StatusFileSize
new2.77 KB

Here's a new panopoly_core patch that also fixes the storage type/id on the panels in that Feature, and includes a Panelizer patch that improves the update hook: #2785883: Infinite loop in panelizer_update_7303

EDIT: Here's a new Travis build: https://travis-ci.org/panopoly/panopoly/builds/153151355

dsnopek’s picture

Here's patches for panopoly_users and panopoly_pages. There's more to come for the modules that only do Page Manager, and not Panelizer!

dsnopek’s picture

And here's the last round of patches.

EDIT: Here's a test build with all the patches: https://travis-ci.org/panopoly/panopoly/builds/153155022

dsnopek’s picture

StatusFileSize
new3.01 KB

  • dsnopek committed d291dfc on 7.x-1.x
    Update Panopoly Core, Admin, Pages, Search, Test, Users for Issue #...
dsnopek’s picture

Status: Needs review » Fixed

Tests are passing on the patches, so I committed! I may still need to update again depending on what happens on the Panels and Panelizer issues, but this definitely appears to work for us, so I'd like to move closer to an actual release

EDIT: Here's the Travis build for the committed changes https://travis-ci.org/panopoly/panopoly/builds/153267069

Status: Fixed » Closed (fixed)

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