Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
When adding a variant for the node edit form, the page returns only "Array".
If I turn of PE, and use only panels, the form renders properly, so it seems PE specific.
Comment | File | Size | Author |
---|---|---|---|
#75 | node_add_edit_form-1139918-75.patch | 1.84 KB | plopesc |
| |||
#75 | interdiff.txt | 828 bytes | plopesc |
#67 | Screenshot 2016-09-22 21.38.55.png | 94.64 KB | 4alldigital |
#64 | panels_everywhere-n1139918-64.patch | 1.54 KB | DamienMcKenna |
#62 | panels-n1139918-62.patch | 1.21 KB | DamienMcKenna |
Comments
Comment #1
Letharion CreditAttribution: Letharion commentedExport of the failing variant and the site template
Comment #2
Letharion CreditAttribution: Letharion commentedComment #3
Letharion CreditAttribution: Letharion commentedNote to self:
Compare call stacks between a node_view and node_edit callback, and each PE functions format of return value.
Something that currently does
return array;
should probably be doingreturn array['content'];
Comment #4
pontus_nilssonMore information...
I had a look at the watchdog after hitting the problem Letharion describes.
The watchdog says: "Theme key "panels_edit_display_form" not found."
Refferer: admin/structure/pages/nojs/operation/node_view/handlers/node_view_panel_context/content?render=overlay
Comment #5
Letharion CreditAttribution: Letharion commentedI see the theme key not found error as well.
Someone else has reported that specific problem with just Panels here #1116522: Warning: Theme key "panels_edit_display_form" not found.
Comment #6
bryancasler CreditAttribution: bryancasler commentedsubscribe
Comment #7
pontus_nilssonMarking this as critical, since it is a show stopper. I would like to help out on this issue, but I need help to understand what is executed and in what order to isolate the problem.
Comment #8
entrigan CreditAttribution: entrigan commentedI can confirm this issue. I tried tracking down the source, but it revealed little.
Some observations:
1) panels_everywhere_page_content_content_type_render(() is not getting called
2) preview on panels page shows nothing
3) The problem happens only when the node edit page is enabled and there is an active variant with active selection criteria
4) Unlike on pages that do work, panels_everywhere_ctools_render_alter() is being called for the node edit page
Hmmmmmmmm
Comment #9
entrigan CreditAttribution: entrigan commentedIt appears that something is wrong in or around the node_edit_form context plugin. Changing the name element from 'node_edit' to 'entity_id:node' makes the page display correctly:
However this of course removes the node_edit_form context which means all of the form elements are not available.
Prodding a little bit more, I see that in ctools_context_create_node_edit_form(), $empty is set to true, and a unfulfilled context object is being returned.
Comment #10
merlinofchaos CreditAttribution: merlinofchaos commentedNot using Panels Everywhere, I've got node_edit working -- but if you're using an older version of CTools than the -beta then node_edit might be still broken.
Comment #11
entrigan CreditAttribution: entrigan commentedThe problem is specifically with Panels Everywhere active (and with a page template variant active). I reproduced the problem with the following three setups:
1. Dev versions of Ctools, Panels, and Panels Everywhere on Vanilla Drupal 7.2
2. Latest stable versions of Ctools, Panels, and Panels Everywhere on Vanilla Drupal 7.2
3. Alpha 3 of Ctools, Alpha2 of Panels, and Alpha 1 of Panels Everywhere on Vanilla Drupal 7.2
Comment #12
entrigan CreditAttribution: entrigan commentedI attempted to do more debugging. I have somewhat limited skills with php and debugging so bear with me:
It appears the the function page_manager_node_edit_get_arguments() gets called twice, and that on the second calling of the function, the next statement that returns an array will instead output Array (or if there is a devel dpm/kpr statement, it will output that) to the page and stop running.
Comment #13
entrigan CreditAttribution: entrigan commentedThe problem is with the node context getting build by the site_template task. Commenting out panels_everywhere_site_template_add_context($contexts, $node, t('Node being viewed'), 'node', 'node'); in the function panels_everywhere_site_template_get_base_contexts() makes the node edit page work again.
This is of course has the side affect of making the node context no longer available to the site template : ( Not sure how to fix it but at least we know where the source of the problem is.
Thanks for pointing me in the right direction on IRC Merlin.
Comment #14
entrigan CreditAttribution: entrigan commentedMerlin suggested the solution might be to cache the context in the node_edit_form context plugin. Unfortunately the node_edit_form plugin seems to only get called once, and hence caching had no affect.
However I did discover in all of this that the node context was getting called twice, and I discovered a fix: Removing 'node' from the ctools_context array argument in the node_edit_form context:
In the function
This is all a bit over my head at the moment, but so far testing has not revealed any ill side effects (even with panels everywhere disabled).
Thoughts? If this is a reasonable fix I will roll a patch.
Comment #15
merlinofchaos CreditAttribution: merlinofchaos commentedUm. Sure if that fixes it I'm all for it.
It's possible that something treats it as a node context and squashes the form somewhere? I dunno why that would be.
Comment #16
entrigan CreditAttribution: entrigan commentedIn that case, changing projects to ctools, and attaching patch.
Comment #17
merlinofchaos CreditAttribution: merlinofchaos commentedCommitted!
Comment #18
Itangalo CreditAttribution: Itangalo commented(I can confirm that it is now possible to have node add forms in Panels Everywhere. Wohoo!)
Comment #19
jthomasbailey CreditAttribution: jthomasbailey commentedWas this committed to 6? Because it's not working.
Comment #20
jthomasbailey CreditAttribution: jthomasbailey commentedHey Merlin I don't think this was committed to 6. The patch works, though.
Comment #21
merlinofchaos CreditAttribution: merlinofchaos commentedIf the patch works for 6.x as is then let's mark it needs review so I find it. :)
Comment #22
Letharion CreditAttribution: Letharion commented@merlinofchaos
I have verified that the patch as it is applies to 6 as well, but I don't have a PE site currently on D6, so I haven't verified it's effectives. It's my understanding however that this has been confirmed by #19 in #965148: node add/edit and taxonomy pages are not rendered when using site template
You may or may not want to wait a bit to see if someone re-opens that bug.
Comment #23
Itangalo CreditAttribution: Itangalo commentedI just realized/experienced that an unfortunate side effect of this patch is that Page manager loses all knowledge about the content type, and thus which fields are available in the form.
I first thought that I should try creating a CTools relationship plugin, node form --> node, but then I realized that it won't help very much. The edit fields are of course found through the node form context data, not the node display data.
Don't really know how to approach this problem.
Comment #24
entrigan CreditAttribution: entrigan commentedOk. Maybe caching was the appropriate way to solve this. When I tried caching the node object in the node context function it did not solve the issue, so this will likely have to be done higher up in the pipeline.
Comment #25
Astma1 CreditAttribution: Astma1 commentedI had the same Problem.
The patch seemed to fix this issue, but...
Patching the "node_edit_form.inc" ends up with not being able to create a selection rule depending on the node-type for the concerned node add/edit form variant.
Comment #26
Itangalo CreditAttribution: Itangalo commentedI have investigated this issue a bit more, and found something really strange.
When un-applying the patch from #16, I get "array" on the node add form when using Bartik. However, it seems to be working fine with I use Seven for adding/editing nodes. This makes me think that the issue is theme related, and that the ideas in #4 is a good start for solving them.
Attached is a patch to get back the node context for the forms.
Comment #27
entrigan CreditAttribution: entrigan commented@Itangalo so there is no problem when using seven even with Panels Everywhere enabled and a variant active?
Also of note, the same issue came up when trying to do the analogous setup for the user edit page.
Comment #28
Itangalo CreditAttribution: Itangalo commented@entrigan: I might be mistaking, when I give it second (and third) thoughts. Won't be able to check this out for some more days, though. Sorry. :-/
Comment #29
entrigan CreditAttribution: entrigan commentedI recently ran into a similar issue with
Array
bring output. I think it was because I was runningrender()
on a render array twice. Perhaps the issue here is similar where render is getting processed twice?(I have not followed up on this at all, this is really a note to self for future investigation)
Comment #30
emattias CreditAttribution: emattias commentedI was able to get it working by checking if $variables['page']['#children'] is an array in preprocess_html and if so render that array:
Comment #31
emattias CreditAttribution: emattias commentedThe problem now is that this results in one form tag around the whole body(panels everywhere panel) and another around the content pane(normal content panel) which is invalid HTML and breaks completely in IE8.
I've investigated this and traced it down to this code in panels.module:
The if (!empty($display->context)) { statement checks if this is panel has a form context and if so it renders it as a form.
I'm unsure how to proceed with this problem. I have come up with these solutions:
1. Add an option to stop panels from completely wrapping any panel in a form tag and instead let you control which region(and possibly a single pane) is wrapped in the form tag. I have attached an example of this that I got working when I commented out the if (!empty($display->context)) { statement(so that it doesnt wrap the whole panel in form tag). This solution allow you to have several forms in one form panel(in different regions/panes).
2. Somehow detect that the current panel is a panels everywhere panel and never render it as a form.(Results on only one form tag around the content panel).
Comment #32
emattias CreditAttribution: emattias commentedHere's a patch that stops site template from being rendered as a form which seams to fix this whole issue. To be clear, with this patch my workaround in #30 is unnecessary.
Comment #33
emattias CreditAttribution: emattias commentedChange status of the issue
Comment #35
emattias CreditAttribution: emattias commented#32: dont-render-site-template-as-form-1139918.patch queued for re-testing.
Comment #37
merlinofchaos CreditAttribution: merlinofchaos commentedYes yes, testbot.
Comment #38
pixelmord CreditAttribution: pixelmord commentedHi,
I'm experiencing the same problem, also when using seven theme that goes away.
I'm using the
panels 7.x-3.x-dev (2011-Nov-03)
Automatic apply of the dont-render-site-template-as-form-1139918.patch failed.
I applied the patch manually and my first tests show, that it works so far also in my custom theme.
I attached the patch I created.
Comment #39
shadcn CreditAttribution: shadcn commentedPatch in #38 worked for me. (panels, + panels everywhere). Thanks @pixelmord
Comment #40
arnested CreditAttribution: arnested at Reload commentedThe patch from #38 works for me as well although displays some notices:
Improved patch attached.
Comment #41
HnLn CreditAttribution: HnLn commentedpatch in #40 didn't work for me in d7, #38 did and seems to have fixed the problem
Comment #42
merlinofchaos CreditAttribution: merlinofchaos commentedOkay, this is a bug in Panels Everywhere with a patch for Panels and it's in the CTools module queue. That's exciting.
Having to hardcode the site_template check in Panels is wrong. Panels Everywhere should be able to do something about the form context so that Panels doesn't screw it up. I think maybe it should just refuse to inherit form contexts or un-formify them.
This patch will at least get people going, but I'm going to move it to PE.
Comment #43
merlinofchaos CreditAttribution: merlinofchaos commentedComment #44
merlinofchaos CreditAttribution: merlinofchaos commentedAlso the patch is against D7 but the issue is against D6. :(
Comment #45
MiSc CreditAttribution: MiSc commentedRewrote patch to make it work.
Comment #46
drupov CreditAttribution: drupov commentedThe patch from #45 solves the issue with page content being wrapped in a form tag, when using a node add/edit variant together with Panels Everywhere (see issue https://drupal.org/node/1736368)
Comment #47
markus_petrux CreditAttribution: markus_petrux commentedThis is PE queue with a patch for Panels?
PS: Marked another issue as a dup. See #2123869: Double wrap content in <form> tag on user edit page
Comment #48
drupov CreditAttribution: drupov commentedHi,
#46 this issue appears only when you use node add/edit on a site that uses Panels Everywhere as site template. So it's kinda philosophical question where it belongs :)
More important: the patch from #45 doesn't apply anymore with the recently released panels 3.4:
I guess the failed parts have changed a lot during the dev phase of panels between 3.3 and 3.4, but I can't really figure out what the problem here is. Maybe someone has a clearer idea?
Comment #49
drupov CreditAttribution: drupov commentedChanging status.
Comment #50
pontus_nilssonI think this is fixed in the dev branch of PE. Could you try using 7.x-1.x-dev instead of 7.x-1.0-rc1?
One of our site uses the node add/edit variant without problems and I checked the makefile and we point to a commit in the dev-branch instead of using 7.x-1.0-rc1.
Comment #51
drupov CreditAttribution: drupov commentedJust tried it. This is not solved by using the latest dev of panels_everywhere with panels 3.4.
Comment #52
roberttstephens CreditAttribution: roberttstephens commentedThis issue was not fixed when using the latest panels everywhere and panels code.
I rerolled the patch from comment 45 on the latest panels 7.x-3.x branch, however the first portion of that patch was unnecessary.
I understand that the "right way" may be to fix this in panels everywhere, but some of us need working sites in the meantime.
Comment #53
drupov CreditAttribution: drupov commentedConfirming the patch from #52 works fine with panels 7.x-3.4+2-dev, ctools 7.x-1.4 and panels_everywhere 7.x-1.0-rc1.
Leaving this at "needs work" as it's not clear where the actual fix should appear (PE or panels). So far I am really happy to have this solution.
Thanks @roberttstephens!
Comment #54
rackberg CreditAttribution: rackberg commented32: dont-render-site-template-as-form-1139918.patch queued for re-testing.
Comment #55
DamienMcKennaI'm unable to reproduce any problems with the current -dev releases of CTools, Panels and Panels_Everywhere.
If you are still experiencing the problem with these module versions, please re-open this issue and provide specific steps to reproduce the bug. Thanks.
Comment #56
func0der CreditAttribution: func0der commentedThis is still a BIG problem.
I do not know how can not re-produce this. I got this first thing after setting up a new Drupal 7.
Anyway. Steps to re-produce this:
drush en panels_everywhere
The structure should be like this:
There you go. I hope this helps to fix this problem in Panels Everywhere and not in other modules that should not even care for Panels Everywhere.
I hope that helps you :)
func0der
Comment #57
func0der CreditAttribution: func0der commentedComment #58
MiSc CreditAttribution: MiSc commentedCan not see how this can be a major issue, and I really don't understand what we should check in the source code for - could you please add what the result is, and what it should be?
Comment #59
func0der CreditAttribution: func0der commentedIt breaks the functionality of EVERY form on the website if we are on public node add/edit pages.
So I think this is pretty major.
I do not know what more to say to the result that IS there than I already did.
The result is simply that the whole page (except for the skip link) is surrended by the form of the node add-/editing.
The SHOULD be is simple: Only surround the real form. If you want to see that in code, apply patch from #52 and compare the results.
It is easy to see.
Comment #60
MiSc CreditAttribution: MiSc commentedPlease attach what errors you get, to tell somebody too look an the error without posting it is not very collaborative. If we help each other out, problems could easier be solved.
Comment #61
DamienMcKennaOk, yes, I've reproduced the error, the problem occurs as described by func0der in #56 and the patch from #52 appears to fix the problem.
Comment #62
DamienMcKennaThis is a reroll of #56.
Comment #63
DamienMcKennaMoving this back to the Panels Everywhere queue because I think I have a possible solution.
Comment #64
DamienMcKennaTaking a cue from merlinofchaos in comment #42, this blanks out the node context if it's actually a form. I'm not completely happy with this, but merlinofchaos didn't like the alternative - hardcoding Panels to be aware of Panels Everywhere's site_template task.
Comment #65
drupov CreditAttribution: drupov commentedI just tried the patch from #64 and it works.
Thanks @DamienMcKenna
Comment #66
DamienMcKenna@drupov: Excellent, thanks for the feedback. I still need to discuss it with japerry first, but I'm happy there's a patch that could resolve the problem from this module's side, albeit kludgily so.
Comment #67
4alldigital CreditAttribution: 4alldigital commentedI've tried patch #64 but not sure its applicable to my scenario of the issue.
I have /user/%user/edit enabled from the https://www.drupal.org/project/user_pages module. After applying path #64 it didn't fix the fact 95% of the page markup was wrapped in the general form [user edit form].
After debugging line 97 of site_template.inc I confirmed $account->data->logged_in_user is not set (see attached screenshot dpm()) so
$account = ctools_context_create_empty('user');
does not get called.When putting that statement outside of the isset() function it does fix the issues, but I don't know enough about panels everywhere to help much more than this.
EDIT:
could you not make this line [97 of site_template.inc ] :
if (isset($account->data->logged_in_user) || in_array('authenticated user', $account->data->roles)) {
if you're just checking for logged in user status??
Comment #68
4alldigital CreditAttribution: 4alldigital commentedsorry to spam the issue, but just confirmed neither solution about have 100% fixed this as the form is still wrapping around panel div's (see attached)
markup is :
markup should be :
happy to help if anyone wants me to test anything...
Comment #69
DamienMcKennaGoing to need to add tests for this.
Comment #70
DamienMcKennaI'm adding tests in #2804901: Add tests for all basic functionality.
Comment #71
DamienMcKennaNow that we have some tests I can expand upon them to work out what's going on here.
Comment #72
IRuslan CreditAttribution: IRuslan as a volunteer and at DrupalJedi commented#64 works for me. I would like to set RTBC, but not sure if tests are required.
Comment #73
drupov CreditAttribution: drupov commented#64 works on a new site for me again.
Comment #74
plopescHello all,
I'm having the same situation described by @4alldigital, and tested his suggestion, which worked for me.
So here I'm posting a new patch adding this extra feature to patch in #64.
Thanks
Comment #75
plopescUpdating patch to avoid PHP notice
Comment #76
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedconflicts with https://www.drupal.org/node/2571437#comment-10472208