drupal 7.43

Maintenance and security release of the Drupal 7 series.

This release fixes security vulnerabilities. Sites are urged to upgrade immediately after reading the notes below and the security announcement:

• Drupal Core - Critical - Multiple Vulnerabilities - SA-CORE-2016-001

No other fixes are included.

No changes have been made to the .htaccess, web.config, robots.txt or default settings.php files in this release, so upgrading custom versions of those files is not necessary.

Known issues:

• This release caused a few regressions with anonymous file uploads:
  • A regression in Drupal core that can occur under rare circumstances. See #2678822: Drupal 7.43 / 8.0.4 regression: When an anonymous user submits a form with an un-uploaded file that leads to a validation error, the file is lost on the next correct submission for more details and a possible patch.
  • A regression in the Webform module that can cause files uploaded to a webform by an anonymous user to fail to be submitted. See #2675170: Drupal 7.43 makes file upload component fail for anonymous user for more details and a possible patch. The Drupal core patch mentioned above may also fix this issue.
  • A regression in the File Resumable Upload module that prevents file uploads by anonymous users from working on fields which use that module's upload widget (see the issue). Solution: Update to the 7.x-1.4 release, which contains a fix for this problem.

  See the "Major changes" section below for more general details on changes to anonymous file uploads.

• This release causes errors on server environments where the PHP PCRE extension was compiled without unicode support. This is unusual but may be more common with older versions of PCRE. See #2676504: Upgrade to version 7.43 causes warning message about "support for \P, \p, and \X has not been compiled" for more details and a possible patch.
• If code calls drupal_goto() very early in the Drupal bootstrap this may lead to a fatal error after updating to Drupal 7.43. (This situation should be rare in practice.) The fix is to change your code to ensure that the includes/path.inc file is loaded, or see #2676598: Drupal 7.43 dies with a fatal error if drupal_goto() is called very early in the bootstrap for a possible core patch.

Major changes since 7.42:

• The File module has changed to prevent users from reusing other users' temporary uploaded files in other content, and anonymous users can no longer reuse temporary uploaded files at all. (This was not a supported use case since temporary files are those that the original user uploaded to the server but has not yet chosen to save.) This could have a minor effect on media management modules if the module provides listings of temporary files with the intention that they can be reused.

  In addition (see the "Known issues" section above) this change has caused some problems with modules that allow anonymous users to upload files. A common theme is that modules which create or alter managed file form widgets may need to adjust their code to ensure that the #default_value property on the widget is set correctly (to reflect the current file that has been uploaded and that is being displayed in the form). This is generally good practice but was not previously strictly enforced; now, in the case of anonymous users, the File module in Drupal core sometimes relies on #default_value to know which file actually belongs there after an Ajax request.

• The "system.multicall" method in Drupal's XML-RPC server has changed such that, by default, it only supports one call for each distinct RPC method (in other words, within a single XML-RPC request you may call four different methods but you can no longer call the same method four times). No changes have been made to Drupal's XML-RPC client code that is used for making XML-RPC requests from your site to other XML-RPC servers; this only affects calls from other servers to your Drupal site. This was not a commonly used feature, but if you have a use case that requires multiple calls to the same XML-RPC method in a single request, a new "xmlrpc_multicall_duplicate_method_limit" variable has been provided that allows you to do so. For example, in settings.php:

    // Allow the same method to be called up to 10 times in a single
    // "system.multicall" request.
    $conf['xmlrpc_multicall_duplicate_method_limit'] = 10;
  

  Or:

    // Setting the variable to 0 or lower will remove the limit and restore the
    // prior behavior, although this also weakens protection against brute-force
    // attacks.
    $conf['xmlrpc_multicall_duplicate_method_limit'] = 0;