I updated to the latest dev versions of ctools, panels and views on a test site and now when trying to edit and save a views pane I get the error:

Display "Content pane" uses a path but the path is undefined.

I did a quick look round and found that changing to "return false" in the 'has_path' function in views_content_plugin_display_panel_pane.inc seems to fix it for me. From the comments for the function I can see my hack will probably break exposed forms in blocks though....

Issue fork ctools-1221676

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

rickmanelius’s picture

rickmanelius commented

Same issue. These content panes were working before. Also to note: in the admin/structure/views page, these content panes now show a path of / even though there is no way to define that in the actual view itself for a content pane.

I'll try the interim solution posted above for now.

rickmanelius’s picture

rickmanelius commented

Totally unrelated question. Why was I assigned as the Revision 2 of the Issue summary?

jon nunan’s picture

jon nunan commented

#2, not sure how that happened, I made one revision straight after I posted it, but haven't made a 2nd. Maybe some tinkering is happening on drupal.org?

Also confirming your point in #1 I also get path '/' listed on the overview page.

Edit now revision 2 is back to me? Maybe its grabbing the user ID from the last commenter?

merlinofchaos’s picture

merlinofchaos commented

Unrelated to this issue, but answering:

Posting a comment on an issue creates a revision of the issue node; we only recently exposed the revision information, and that was a bit of a surprise to people. It ended up shining a very bright spotlight on a piece of Drupal that is quite difficult: You can't easily control who the author of a revision is programmatically. :/

As for this issue: I was afraid that has_path() thing might have side effects. I guess Views is going to need a better way of determining if a display can have an exposed form in a block.

rickmanelius’s picture

rickmanelius commented

Thanks for the answer in #4. It's still confusing as to why this happens, but I'll not let it throw me off and distract this thread anymore...

To me, it appears the main issue may stem from something confusing whether or not the view is a content pane versus a page display. Why would I think this? The main views admin area under admin/structure/views shows the path /. When you create a new view with a 'page' display, it defaults to that path. Also, if you dont' set a path in the view area, you get the same -Display "Page" uses a path but the path is undefined- error. When you go to the edit form for the view's content pane display, it properly shows the forms for a content pane.

In short: it's being displayed and managed like a 'content pane' but it seems to be using 'page' display error checking on the path variable.

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Fixed

The offending patch has been taken out behind the woodshed and shot reverted. http://drupal.org/node/1206230#comment-4751148

Status: Fixed » Closed (fixed)

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

Anonymous’s picture

(not verified) commented
Issue summary: View changes

messed up, didn't comment out, changed to return false.

mortezafox made their first commit to this issue’s fork.

mortezafox opened merge request !1