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!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Jim Kirkpatrick’s picture

Apparently 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.

no_idea_yet’s picture

Just hit the same issue ... running Apache 2.2.25. Hints in plain English to what that workaround actually is would be much appreciated :)

Jim Kirkpatrick’s picture

Well the code I used is as follows -- replace the panels_ajax_tab_element_info_alter() function starting on line 96 with this:

function panels_ajax_tab_element_info_alter(&$element_info) {
  if (arg(0) == 'panels_ajax_tab') {
    if (!empty($_SERVER['HTTP_X_REQUEST_PATH'])) {
      $element_info['form']['#action'] = $_SERVER['HTTP_X_REQUEST_PATH'];
    }
  }
}

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.

Jim Kirkpatrick’s picture

Title: Fatal error: Call to undefined function getallheaders() in modules/panels_ajax_tab/panels_aj » Fatal error: Call to undefined function getallheaders() in panels_ajax_tab.module line 96
Issue summary: View changes
Status: Active » Needs review
FileSize
599 bytes

Patch for the fix in comment 3.

Jim Kirkpatrick’s picture

Actually 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:

function panels_ajax_tab_element_info_alter(&$element_info) {
  if (arg(0) == 'panels_ajax_tab') {
    if (!empty($_SERVER['HTTP_X_REQUEST_PATH'])) {
      $element_info['form']['#action'] = $_SERVER['HTTP_X_REQUEST_PATH'];
    }
    else {
      $element_info['form']['#action'] = $_GET['q'];
    }
  }
}

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...

Jim Kirkpatrick’s picture

Update: 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.

Jim Kirkpatrick’s picture

Hmm... 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.

itarato’s picture

Status: Needs review » Closed (fixed)

Fixed the original issue in commit #98cd543 . For the other issues (if still exist) please create new issues.

jordanrussellsmith’s picture

I downloaded the latest dev release 7.x-1.x-dev (2014-Aug-11), but it does not include this change.

sja1’s picture

Yes, 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.

sja1’s picture

Status: Closed (fixed) » Needs review
sja1’s picture

For the record, here is the fix that was applied then rolled back:

/**
 * Workaround for non-Apache webserver where getallheaders() is not enabled.
 *
 * @see https://www.drupal.org/node/2110907
 * @see http://php.net/manual/en/function.getallheaders.php
 *
 * @credit majksner at gmail dot com
 */
if (!function_exists('getallheaders')) {
  function getallheaders() {
    foreach ($_SERVER as $key=>$value) {
      if (substr($key, 0, 5) === "HTTP_") {
        $key = str_replace(" ", "-", ucwords(drupal_strtolower(str_replace("_", " ", substr($key, 5)))));
        $out[$key] = $value;
      }
      else {
        $out[$key] = $value;
      }
    }
    return $out;
  }
}

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.

alec-AW’s picture

For information only :

roderik’s picture

So we have

  • Jim Kirkpatrick's solution in #4 (patch)
  • which was then fixed by himself in #5 (comment)
  • and separately, the code committed earlier to this module and then rolled back (comment #12)

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.)

rahul.shinde’s picture

Assigned: Unassigned » rahul.shinde

  • rahul.shinde committed 40bfeb1 on 7.x-1.x
    Issue #2110907 by Jim Kirkpatrick, roderik, rahul.shinde: Fatal error:...
rahul.shinde’s picture

Assigned: rahul.shinde » Unassigned
rahul.shinde’s picture

Status: Needs review » Fixed

Added fallback for getallheaders.

Status: Fixed » Closed (fixed)

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

jordanrussellsmith’s picture

Status: Closed (fixed) » Needs work

This fix got wiped out in commit 002dccd

  • rahul.shinde committed 0bd60de on 7.x-1.x
    Issue #2110907 by Jim Kirkpatrick, roderik, rahul.shinde: Fatal error:...
rahul.shinde’s picture

Status: Needs work » Fixed

Re-added the missing code.

Status: Fixed » Closed (fixed)

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

vidhatanand’s picture

Seems still facing it. Not sure if same cause.

roderik’s picture

FileSize
2.32 KB

@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.