Fatal error: Call to undefined function: array_intersect_key() in url/modules/update/update.compare.inc on line 695

Better title for visibility

This is coming from #669554: Reduce RAM bloat: only save attributes from .info we care about.

I've suggested a health warning be added to the 6.16 release page. #732546: Drupal 6.16 release page needs health warnings

Quick patch to duplicate the functionality safely with PHP4.

uhm? Why that complex?

Oh yeah, that works too I guess. :)

Bless you! (patch worked perfectly on my php4 system -- and, no, I don't want to have php4, but I'm stuck with it for the next couple of months).

reproduced with PHP 5.2.9 (according to cPanel).

I appreciate the quick patch, but I'm concerned about where else some PHP5 stuff may have gotten in. I'm ready to upgrade my production site from 5 to 6 (was about to roll it tonight). I upgraded my test site today with 6.16 and hit this.

Any thoughts?

@10: some options:
1. test, test, test
2. Wait a day or 2 for someone else to pick up any further problems
3. Review the list of bugs fixed in 6.16 (http://drupal.org/node/732000 and their patches and/or http://drupal.org/project/cvs/3060/?branch=DRUPAL-6) for PHP5-isms
4. Throw caution to the wind
5. Maybe there is some tool out there to check the entire Drupal source for PHP4 incompatible constructs?
6. All of the above

While I know that D6 is supposed to work on PHP4, as a module maintainer, I am happy that people may be forced to finally move to PHP5. Many, if not most modules are requiring PHP5 any way. So I don't consider this bad news.

@gpk, you left out just disabling update. Life may be more difficult without it, but it will not come to an end.

@gfury: your only option is to upgrade to PHP5. PHP4 is end-of-life.

@12: Darn, missed that one!!

Committed this fix, thanks.

For anybody running on PHP 4, the easiest fix right now might be to replace this line:

        'info' => update_filter_project_info($file->info),

with this line in modules/update/update.compare.inc:

        'info' => $file->info,

until a new core release is out. Which will not get you the memory improvements, but make your Drupal work on PHP 4. Next time the new release comes out, just overwrite this file with the new version, so the changes will be in.

Thank you, Gábor! That worked for me.

While I mostly run Drupal on PHP5, there's one site still running 4. I was surprised to see the error upgrading from 6.15 to 6.16!

@all: Sorry about this. A few thoughts on what led to 6.16 being released like this:

A) The absence of automated testing for D6 core is obviously a problem. If we had even the most basic automated testing running in the various environments we claim to support, this wouldn't have happened.

B) Waiting until a day or two before a planned security release to clean out the D6 RTBC queue seems like a recipe for problems like this. #669554: Reduce RAM bloat: only save attributes from .info we care about was RTBC for 2 solid months before it was committed 2 days before 6.16 was going out. If this was committed back when it was "ready", this could have lived in 6.x-dev for weeks or months and probably been noticed before an official release. This is even more of a concern given point (A). Without real automated testing, our -dev releases are even more important. @Gabor, please consider looking at the D6 RTBC queue more often than every few months, days before you're planning a release -- especially given how dependent D6 is on manual testing, and how hard it is to get people to manually test/review patches sitting in the queue.

C) D7 requires PHP5. Our core development model requires fixing everything in HEAD first, then backporting. This makes it hard for those of us doing core work to be able to test things ourselves in every supported configuration. Not that it's impossible to setup a D6 + PHP4 test site along side my PHP5 D6 and D7 (and D5) test sites, but it's just more work and I already have very little time to spare.

Not trying to pass "blame" on this, just trying to draw out some lessons and thoughts on what could be done in the future to avoid these sorts of problems from biting us again.

Thanks/sorry,
-Derek

Same problem on 5.2.12.

@dww: Thanks for working so hard on Update module! I don't think there's any reason to excuse and I'm sure that no one thought of assigning blame in the first place. After all, PHP4 is end of life and officially unsupported. Contrary to that, I really love how you take on such a solid responsibility for maintaining that core component!

Instead of complaining, all of us should be deeply grateful to have dww - someone who actually cares and really tries hard to improve Drupal core.

Can you believe that a webhosting package, newly registered in January 2010, still has PHP 4.4.9?
Customer bought it as business package at German 1and1, don't like to work with 1and1 anyway, it's slow and still haven't the mod rewrite enabled.

Thanks for the patch, seems to work so far, so I could install Drupal 6.16.

@e-fee: You should be able to force PHP5 on 1und1.

Add on line 5 of your .htaccess

# Force php5
AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php

Additional I also need to force MySQL5. You can do this in your settings.php, e.g. at line 92 add

ini_set('mysql.default_socket', '/tmp/mysql5.sock');

I am not a server expert, but this is what solved the issue for me ages ago.

@dww: we could draw conclusions on this issue, if you'd like to. Let's see.

You are calling for early commits. I've committed #251792: Implement a locking framework for long operations *a month* before the Drupal 6.16 release *after* ensuring the issue had *numerous* positive tester feedback comments. It is result of multiple critical issues in the Drupal 6 queue, see eg. #732064: "Call to undefined function lock_acquire", locale module and #732024: Updating from 6.1 user warning: Table 'semaphore' doesn't exist.

Based on experience with such issues in the past two years, people using Drupal 6.x-dev as a testing ground is as far as I've seen largely a myth. I clearly intended to commit stuff and put in some huge changes like the lock patch early to get feedback from people running with it even after ensuring I got plenty of feedback on the issue itself.

I could be called one of the most prolific contrib simpletest writers, given the outstanding test coverage I've achieved for many of my contributed modules, and I highly value being able to run simpletests on the Drupal 6 codebase. I did run simpletests multiple times through the release night with and without the security patches applied to ensure it is as healthy as possible. This contributed to our day being much longer, and Niel wondering about the possibility of simpletests for Drupal 5.

Unfortunately, simpletest itself is only compatible with PHP 5, so there is not much of a chance to run those tests on PHP 4 as well. I did switch my hosting environment to PHP 4 and did basic testing **on previous releases**, but unfortunately not this time. I do regret this omission. I accept/agree it is the responsibility of the core maintainer to ensure compatibility with environments supported. In its full scope, that would require me to have testing environments with all combinations of different PHP versions, different databases, operating systems and webservers. (We have introduced incompatibility before in security patches as well, which definitely cannot be crowd-sourced in testing).

The reason many patches stand in the RTBC queue for extended times, is that I look for feedback on how they ran in actual environments. I was pinged multiple times about the lock issue, and always pushed back asking for more testing results. As experience showed us, even after waiting for more feedback, then committing it early, then running all available simpletests on it, including some of the ones for my own modules on top of ones included with the simpletest module, then running on the cutting edge D6 right before release did not help.

As far as I'm seeing, the most often introduced regressions in D6 were lack of support for PHP 4, this being the third Drupal 6 version I can recall lacking support for PHP 4 in some way. Therefore I'm proposing better automated means to check for PHP 4 support. This can either be porting of simpletest to work with PHP 4 and/or an automated compatibility checking tool (which then could be used beyond code covered by tests). I'm submitting this as an idea for the core developer summit in San Francisco.

And pray-tell what does one do with this patch? I don't see any instructions for how to implement it.

@TribalDancer: you can just follow the hopefully very simple instructions in #15 to get this resolved for you until Drupal 6.17 comes out.

@TribalDancer: Or, you can apply http://drupal.org/files/issues/drupal6.update-whitelist.6.patch using the instructions at http://drupal.org/patch/apply ...

@Gabor: I was not at all casting doubt on how careful you are as a branch maintainer, how prolific as a simpletest writer, etc. It's certainly possible that manual 6.x-dev testing is mostly a myth. From a release management standpoint, I just don't see how earlier commits of RTBC D6 patches hurts, that's all. ;) Yes, pushing back before the commit to get more testing makes sense, but otherwise, it seems like the sooner things are actually in the branch, the more chances (even if rare) that someone will notice a problem before we ship an official release. And yes, point well taken that our existing testing framework can't work with PHP4, which makes this specific case tricky. If this has already burned us 3 times in the D6 life-cycle, then it seems like a more explicit "does this work on PHP4?" question in the review process of all D6 backport issues needs to be instituted. That can start from the branch maintainer, but it's up to all reviewers to help ensure this question is asked and satisfactorily answered. If we agree this is necessary and useful, we could call attention to this via devel list post, planet post, etc.

Again, I'm not trying to (re)assign blame -- as the original author of the backport patch, it was ultimately my responsibility to remember that D6 needs to support PHP4 and that PHP5-only functions are off limits -- I'm just trying to see if there are ways we can learn from this experience to improve our process.

Cheers,
-Derek

im using Parallels Plesk Control Panel...just change your PHP version to 5.+ version...and it works...try in your CPANEL...

This solution works just fine. Fastest Fix so far, thank you!

The same problem happens with PHP 5.0 (array_intersect_key() was introduced in PHP 5.1), but the solution posted in #15 works in this case too.

Please copy the code below into "update.compare.inc". You should be fine.

if (!function_exists('array_intersect_key'))
{
  function array_intersect_key($isec, $keys)
  {
    $argc = func_num_args();
    if ($argc > 2)
    {
      for ($i = 1; !empty($isec) && $i < $argc; $i++)
      {
        $arr = func_get_arg($i);
        foreach (array_keys($isec) as $key)
        {
          if (!isset($arr[$key]))
          {
            unset($isec[$key]);
          }
        }
      }
      return $isec;
    }
    else
    {
      $res = array();
      foreach (array_keys($isec) as $key)
      {
        if (isset($keys[$key]))
        {
          $res[$key] = $isec[$key];
        }
      }
      return $res;
    }
  }
}

I would try to find a solution to this problem, by using a different way
Mi website now are in a php4 server.
So, Updating modules in my Drupal 6.16 to a Drupal 6.19 version. I find this problem:
Fatal error: Call to undefined function: array_intersect_key() in /url/modules/update/update.compare.inc on line 695

Now I'll moving my updated Drupal site with this "fatal error", to a server with php 5 version.
So I'll use this way, and I will share wath I found here...

OK, I finished moving my site to a server using php5
Now, I don't see the "fatal error: call to undefined function ..."
Now the problem I have is as follows:
1) I don't see the Admin panel, although I can access the administrative pages one by one by typing the full url in the browser.
2) The Status report:
CTools CSS Cache Unable to create
The CTools CSS cache directory, sites/default/files/ctools/css could not be created due to a misconfigured files directory. Please ensure that the files directory is correctly configured and that the webserver has permission to create directories
3) And in: admin/build/modules:
• warning: unlink(sites/default/files/ctools/css/01ecf25a3839d1df013325111549b123.css) [function.unlink]: Permission denied in /home/public_html/includes/file.inc on line 444.

....Comments are welcome!

Your latest problem is unrelated to the original issue. Please open new issues for new problems so that this bug report can be kept closed.

For what it's worth, though, you probably just forgot to make your sites/default/files directory writable after moving to your new server.