Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
On some servers the getallheaders()
is not available. It's redundant anyway as used in this module as the appropriate $_SERVER
variable can be got directly.
Original: Two mini panels pulling data from Views. Those views have filters on them. Any suggestions very welcome! Thanks!
Comment | File | Size | Author |
---|---|---|---|
#25 | 2110907-25.patch | 2.32 KB | roderik |
#14 | no_getallheaders-2110907-14.patch | 920 bytes | roderik |
#4 | no_getallheaders-2110907-4.patch | 599 bytes | Jim Kirkpatrick |
Comments
Comment #1
Jim Kirkpatrick CreditAttribution: Jim Kirkpatrick commentedApparently it's because Nginx does not support
getallheaders()
. See #1561624: getallheaders isn't available when running nginx for an example workaround.Workaround aside, this module is essentially server software-specific (to Apache) and would benefit from being more general. Actually, the current code that is getting all the headers into a big array only one specific one is a big overhead that's probably unnecessary.
Perhaps we can just find out the actual name for the appropriate $_SERVER (
HTTP_X_REQUEST_PATH
perhaps?) and use that instead -- or use Drupal's APIs instead.Comment #2
no_idea_yet CreditAttribution: no_idea_yet commentedJust hit the same issue ... running Apache 2.2.25. Hints in plain English to what that workaround actually is would be much appreciated :)
Comment #3
Jim Kirkpatrick CreditAttribution: Jim Kirkpatrick commentedWell the code I used is as follows -- replace the
panels_ajax_tab_element_info_alter()
function starting on line 96 with this:It's the same as before, but doesn't bother getting all the headers just to pull out the one needed -- it just gets the right one directly.
It's working on NginX for me and makes the module usable for us... I'll roll a patch but would like no_idea_yet to test if poss too.
Comment #4
Jim Kirkpatrick CreditAttribution: Jim Kirkpatrick commentedPatch for the fix in comment 3.
Comment #5
Jim Kirkpatrick CreditAttribution: Jim Kirkpatrick commentedActually the bug goes a bit deeper...
It appears that the first tab loaded has no
$_SERVER['HTTP_X_REQUEST_PATH']
set, so the code here that is supposed to set the form to be submitted back to itself is never called.Perhaps a better approach is:
This ensures we always alter the forms on URLs that start
/panels_ajax_tab
with whichever destination is more appropriate.I'm testing this now but am hitting #1944510: Views not receiving arguments from ajax tab now...
Comment #6
Jim Kirkpatrick CreditAttribution: Jim Kirkpatrick commentedUpdate: The patch over on #1944510: Views not receiving arguments from ajax tab works well and means that together with the fix above (in comment #5) this module now works well for me.
But I'm now hitting the issue whereby the submitted tab is not reloading -- though thanks to the patch the tab IS showing the correct values for the exposed filter -- it's just not the first displayed tab.
Comment #7
Jim Kirkpatrick CreditAttribution: Jim Kirkpatrick commentedHmm... actually there's still an issue -- the exposed form sometimes submits without ajax to a new page. I'll try to establish where that happens soon.
Comment #8
itarato CreditAttribution: itarato commentedFixed the original issue in commit #98cd543 . For the other issues (if still exist) please create new issues.
Comment #9
jordanrussellsmith CreditAttribution: jordanrussellsmith commentedI downloaded the latest dev release 7.x-1.x-dev (2014-Aug-11), but it does not include this change.
Comment #10
sja1 CreditAttribution: sja1 commentedYes, it looks like the fix was applied but then it was rolled back together with a number of other fixes: http://cgit.drupalcode.org/panels_ajax_tab/commit/panels_ajax_tab.module...
If you scroll to the end of the page, you can see the fix for getallheaders that had been applied.
Comment #11
sja1 CreditAttribution: sja1 commentedComment #12
sja1 CreditAttribution: sja1 commentedFor the record, here is the fix that was applied then rolled back:
I have tried both this solution, and the one in #5. Neither works for me. The error message no longer occurs, but the view still doesn't load.
I have two tabs, both with views. Regardless of the order in which I place the views into the two tabs, the view on the first tab loads correctly on initial page load, but when I click on the second tab, the second view does not load.
Comment #13
alec-AW CreditAttribution: alec-AW commentedFor information only :
Comment #14
roderikSo we have
I like the first one better. About #5, I'm wondering though - do we need to explicitly set the form action to $_GET['q']? Can't we just skip setting it, because the form action path is already OK?
(The only difference in my test seems to be, that setting $_GET['q'] strips the URL parameter from the form action.)
Comment #15
rahul.shindeComment #17
rahul.shindeComment #18
rahul.shindeAdded fallback for getallheaders.
Comment #20
jordanrussellsmith CreditAttribution: jordanrussellsmith commentedThis fix got wiped out in commit 002dccd
Comment #22
rahul.shindeRe-added the missing code.
Comment #24
vidhatanand CreditAttribution: vidhatanand at OpenSense Labs commentedSeems still facing it. Not sure if same cause.
Comment #25
roderik@vidhatanand if you are still facing this: can you try this patch?
It basically swaps above approach #12 (which was applied to the -dev version) for approach #4 (which IMHO is more straightforward).
If indeed this solves things, the issue can be reopened.