3

Our current Drupal 7 site runs on PHP 5.3 environment. But the server provider insisting to upgrade the PHP version to PHP 5.6 as they are about to end the support for PHP 5.3 and PHP 5.5 .

Is there any known issues for an existing Drupal 7 site migration into php 5.6?

Any tools/modules to check the version compatibility of current Drupal 7 in PHP 5.6 ?

Other than this any suggestion or advices prior to the migration ?

  • better have a test server setup with php 5.6 on local environment and test the site locally. You might get some issues in contributed modules but Drupal 7 core works fine on php 5.6 drupal.org/requirements – shrish Aug 17 '15 at 6:10
  • @shrish , Yes.. I have a test server. I have enabled the 5.6 version and testing parallel. But before that, is there any tools/module we can run over through module files and check the version incompatibility. – Jyothish Aug 17 '15 at 9:42
  • See this question – Mołot Aug 17 '15 at 13:03
  • @Mołot , That's for Drupal 6. Here the case is different – Jyothish Aug 18 '15 at 9:09
  • I wasn't flagging duplicate or anything. I only wanted to point out that official documentation often contains useful warnings. – Mołot Aug 18 '15 at 9:10
7

Is there any known issues for an existing Drupal 7 site migration into php 5.6?

For Drupal core specifically, that information will be in the issue queue. A quick search for "5.6" brings up no results. It it helps, I've been running D7 on 5.6 for ages now with no problems.

Contrib modules might be a different story, you'll need to check each of those individually, unless they offer that info specifically on the project page, or through a minimum PHP version specified in the module's .info file.

Any tools/modules to check the version compatibility of current Drupal 7 in PHP 5.6 ?

Not Drupal-specific tools (it wouldn't make sense for there to be since this just a plain PHP question). You can probably make good use of something like PHPLint. Personally I would start with IDE tools (switch the language version to 5.6, run a validator, then check the current issue list for errors)

Other than this any suggestion or advices prior to the migration ?

The only sane advice is for you to treat this as any other upgrade, whether that be code or server - make sure the site is fully tested in a development environment before pushing anything live. Have a plan in place to downgrade quickly on the live servers in case something goes wrong. If that's not an option (i.e. you don't control the server software), then re-double your testing efforts, and make sure server config is as identical as you can get it before pushing anything live.

| improve this answer | |
  • +1. I'm using 5.6 and core and the mostly used modules work fine. Drupal doesn't use preg_* functions much, so the chances of deprecated modifiers, etc are slim too. – AyeshK Aug 18 '15 at 9:22
  • 1
    We do use preg_* heavily but /e has been on the naughty list since forever. When we ported KSES to Drupal then core commiter Steven Wittens insisted on replacing it with preg_replace_callback -- ten years ago. I know this first hand because I was doing the coding under Steven's mentorship. A few years after that almost all projects were hit by a security hole due to the /e in KSES except Drupal because of this... – user49 Dec 19 '15 at 20:54
1

Today, I tried Drupal 7 on PHP 5.6 on a shared hosting plan. I can see it works slower when taxonomy_menu and views are enabled. But if you do not have these, it works just a bit slower. So I use PHP 5.5 in this case.

However, Drupal 8 works slower with PHP 5.5 and does not even install. But it will work when installing it under PHP 5.6 and then switching the server back to PHP 5.5.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.