CTools Page manager pages do not revert properly

Still happening in Beta8. If I go to admin/build/pages, it shows the page is "Normal" rather than overridden or default as it should.

I found a workaround which might be has to be reflected in code.

Revert your variant, save the page, revert the panel itself.

subscribe.

This is quite possibly related to another issue, #853120: Use ctools functions instead of querys for revert features, so hopefully once that is resolved this issue will also disappear.

subscribing, seeing this problem when reverting a feature as well.

Subscribing, this one is driving me mad. Digging into the code, all I see it doing is deleting the page from page_manager_pages, but it doesn't seem to do anything else? Not sure if I'm missing it. Where is it supposed to actually restore the page saved in modulename.page_defaults.inc?

Updating version, seeing this in rc3.

@ #2 - your workaround worked for me. Thanks a lot! I wrestled with this for hours.

#2 workaround works for me too.

This still occurs. greg.harveys fix works.

Subscribing...

I am seeing this as well and it is very annoying. The workaround does work but when you've got lots of panel pages, it takes a lot of work to get things reverted.

This is a duplicate of #744450: Why would a feature not revert?

Greg, that makes perfect sense - I will try to drive the redundant traffic back this way then. Appologies for jumping the gun.

subscribe

I think I figured out what the problem is.

A page manager page contains 0 to n handlers (as far as I can see, these are the variants in the UI). The panels module has the panels_context handler which contains a display, which in turn contains panes. Now when you export the page with the features module, all of that gets exported into hook_default_page_manager_pages(). For ctools the elements are all separate objects (page, handler, display, pane). When building the page from code the hook is being called, which in turn builds all required objects and all is fine.

Now whenever you change anything in the page with the UI, all settings are written into the database, each object into its own table. If that is the case, the hook is not being called, everything is build from the database and again everything is fine.

Now when you try to revert the feature all that is required is that the database entries are deleted. But this only happens for the page. The other objects (handler, display, pane) remain in the database and are thus still considered overridden.

So what needs to be done is to delete the handlers, displays and panes that belong to a page. Seeing that features.ctools.inc already contains a special function for page_manager_pages I guess it's the easiest to simply add a another one that implements hook_features_revert for page_manager_pages. This fixes the issue on my side, but adds to the "wild hack" that all of features.ctools.inc is. In my point of view, the whole file should be moved to the ctools project, since it is ctools job to implement the features API and I think the ctools maintainers can do a better job of it, because they know the inner workings of their tools. Maybe thats something for the 7.x releases.

+1

Working fine on my machine!.

+1 for delegating responsability to the cTools / Panels maintainers (to be save in case of API changes in the future) - is there already an issue?

#16 works fine (thanks @Volx) and saves much time compared with #2 (which was my solution up to now)

If anybody recognizes any bad side-effects of #16 patch, please post it here. Since page_manager_page_form_delete_submit() does the same thing, it should be a safe solution.

Only re-formatted the #16 patch so that it hopefully works with drush make. Now it is relative to the "features" project directory instead of being relative to sites/all/modules[...]

subscribe

Just wrote a blog post on this... THEN I find this issue :-)

http://www.thingy-ma-jig.co.uk/blog/16-02-2011/batch-revert-views

That post has two snippets you can run from devel/php to forcefully revert/delete your views and panels.

Oh yeah, one thing I did differently was to use array_walk rather than a foreach. Practically no different. Not sure if there is an relevant performance difference...

#23 worked for me. Thanks!

Subscribing

I tried the patch in #23. I have a panels page with 3 rows and each row has div classes such as:

1. panels-flexible-row-1-main-row
2. panels-flexible-row-1-1
3. panels-flexible-row-1-2

After reverting, the row div classes change to:

1. panels-flexible-row-new-main-row
2. panels-flexible-row-new-1
3. panels-flexible-row-new-2

...which breaks my panels page theming, and is not a proper revert, right?

Version:
Pressflow 6.20
Chaos tool suite 6.x-1.8
Features 6.x-1.0
Panels 6.x-3.9

Hey Eric,

Are you sure this is related to the patch? All the patch does is delete all the pages from the database on revert. Could you add an attachment of that exact panel/page manager configuration as an attachment to this queue as well so I can take a look?

James

Also Eric, in general do you know what causes that "new" to replace the numbers? Is that something auto-generated by the flexible layout or is that something you manually configured in you reverted feature?

Whatever the cause of the issue in #29, it wasn't introduced by the patch in #23.

This is a reroll with git prefixes.

Patch on #32 worked great for me.

Thanks for the feedback. I think my comments in #29 describe an issue that is separate from this one here and unrelated to patch #23.

The issue in comment #29 actually starts when I first create/export the feature, and the myfeature.pages_default.inc file has code like:

    $pane->pid = 'new-1';
...
    $display->content['new-1'] = $pane;
    $display->panels['center'][0] = 'new-1';

Then if I revert to code later I notice that the div classes changed to say "new" in them.

patch in #32 misses:

require_once drupal_get_path('module','ctools').'/page_manager/plugins/tasks/page.inc';

but all in one, it works out pretty good for me. Adding a revert hook is only the first side of the medal though, what about the rebuild hook?

As far as I understand there is no need for a rebuild hook since Panels stuff works from database OR code - in contrast to CCK fields, permissions etc. that ONLY live in database.
So by deleting the (overridden) database entries for Panels pages, the (default) code definitions for your Panels pages will be used.
Am I wrong with that?

subscribe - this is a major problem!

Here's the patch from #23 re-rolled with the extra line from #35.

Forgot to make the previous patch relative to the features module directory - fixed.

Hi galooph, I think you got the patch backwards by accident, the pluses and minuses should probably be reversed.

:( +1

This should likely have been set back to needs review; it looks like none of the patches are ready unless go through and change the minuses to plus on last.

I don't use page manager, so leaving this for tim.plunkett, just wanted to fix the status.

Doh! No idea how I managed to get the previous patch back to front!

Here's the patch from #39 the right way round.

Applying this patch definitely allowed some of my features to revert correctly. Marking as RTBC...

also votinv RTBC, using this patch over a long time now ( more then 6 months or so )

Sub

#44 works fine; Features beta3, ctools RC1

Been using it for a couple of months now without any issues.

Tagging

#44 worked for me, thanks!

#44 works for me. Thank you! There is one side effect: reverting takes much more time.

Just subscribing. The patch worked for me too.

Taking all the reviews to mean it's a-okay. Commited to 6.x; hopefully I got everyone's names in the commit message >.O

http://drupalcode.org/project/features.git/commit/31cbcf0

Patch applies cleaning for 7.x, but no idea if it works.

Can confirm this applied cleanly in D7, haven't yet had a good opportunity to test an actual revert.

Rerolled for D7 style.

This is ready.

I've just tried it and it works for my case. Confirming the RTBC.

Committed to 7.x. Thanks everyone.

http://drupalcode.org/project/features.git/commit/0d9d2aa

What about d6?

Eugenmayer, this was committed to D6 in #53.

Tank you!

I hate to reopen this ticket, but I've recreated and reverted over and over again and simply cannot get this feature to see it's still default!

I just updated to the latest ctools (7.x-1.x-dev) and I'm running the latest stable versions of panels and features (7.x-3.0 and 7.x-1.0-beta6). Like the previous authors, these panels existed before and I'm trying to use features to now track them in code. But even when I get successful messages:

Reverted all page_manager_pages components for custom_features_content.
Reverted all panels_mini components for custom_features_content.

They refuse to revert without manually going into the panels.

Am I doing something wrong? Do I need to move to the dev versions of panels/features?

Ctools 7.x-1.0
Features 7.x-1.0-rc1+7-dev
Panels 7.x-3.2

Same thing here, when I ask a feature to revert a page manager component of the feature, it gives the message "Reverted all page_manager_pages components" but when viewing the feature, the Page manager section still shows the feature as overridden.

This new phenomenon is now related to #1369246: Features incorrectly reporting panels as overridden. Pid counting changed..

If that issue is in fact what you observe, please close this issue as "closed (fixed)".

Marking as needs more info until we can show that this is a recurrence of the reported issue and not a duplicate of #1369246

It's been well over a year and no one has come forth with more information. Closing this. Feel free to reopen if you can provide more information.