Czy Magento jest gotowy na PHP 7?

PHP 7 osiąga status wersji beta i obecnie trwa wiele testów. Biorąc pod uwagę, że Magento nadrobiło zaległości w ciągu ostatniego roku od „działa tylko na PHP 5.3” do „w pełni kompatybilnego z PHP 5.6”, chciałbym wiedzieć, ile rozważają kompatybilność PHP 7 dla Magento 1.x, a także Magento 2.

Znalazłem ten post przez Annę Filinę, gdzie znalazła jeden problem w Magento 1.9.1 (nadal niezmieniony w 1.9.2), ale biorąc pod uwagę, że Magento 1 nie ma testów jednostkowych, nie ufam, że to był jedyny problem.

Pytanie brzmi: czy zapewniona będzie zgodność PHP 7 z Magento 1? A ponieważ Magento 2 prawdopodobnie został już przetestowany na PHP 7 (dzięki zautomatyzowane testy!), Czy są jakieś znane problemy?

Magento oficjalnie ogłosiło 20 stycznia 2016 r., Że CE i EE 2.0.1 oficjalnie obsługują PHP 7.0.2.

Magento Enterprise Edition i Community Edition 2.0.1 są już dostępne i zawierają ważne aktualizacje bezpieczeństwa i funkcjonalności, w tym oficjalne wsparcie dla PHP7.0.2.

Link: https://magento.com/blog/technical/new-magento-20-resources-and-support-php7

Jeśli używasz najnowszej wersji, M CE 1.9.2.2, istnieje rozszerzenie, które zapewni pełną zgodność z PHP 7: https://github.com/Inchoo/Inchoo_PHP7 . (Zastrzeżenie: Jestem autorem, choć społeczność bardzo pomaga).

Można go również zainstalować za pomocą Composer ze strony http://packages.firegento.com/ .

Wszystkie wymienione tutaj niezgodności zostały naprawione. Uważamy, że może być jeszcze kilka przypadków, ale nic nie powstrzymuje. Testy, zgłaszanie problemów i żądania ściągania są mile widziane.

Nie mam pojęcia o PHP7, ale domyślam się, że większość rzeczy jest nadal ważna w PHP7, więcej informacji można znaleźć na blogu Matthiasa Geniara

• ext / mysql: mimo że jest to bardzo stare rozszerzenie MySQL, sądzę, że nadal jest bardzo szeroko stosowane, ale nadszedł czas, aby wszyscy przenieśli się do pdo_mysql.
• set_magic_quotes_runtimei magic_quotes_runtime: wygląda na to, że widziałem te powiadomienia o wycofaniu od… na zawsze?
• iconv.input_encoding, iconv.output_encoding: do tej pory nigdy nie miałem do nich zastosowania ...
• #komentarze stylowe w plikach ini: brawo dla spójności, zawsze wolałem; (średnik) komentarze w plikach .ini!
• preg_replace()modyfikator eval: brawo dla nastawionych na bezpieczeństwo sysadminów!

Myślę, że jedyne, co możemy mieć w Magento, to preg_replace()modyfikator ewaluacji, ale mam nadzieję, że nie.

Oprócz tego Magento dostarczyło 1.9.2 ze zaktualizowanym TAF, który można znaleźć w dev. Dzięki temu powinieneś być w stanie uruchomić kilka testów frontonu na PHP7 i później sprawdzić dziennik

Brak komentarza do Magento 1, ale Magento 2 miał pewne problemy z nazwami klas, takimi jak „String”. Naprawienie nie zajęło dużo czasu, ale nie wyszło po wyjęciu z pudełka. Oczekuję, że Magento 2 zostanie naprawiony, ale może nie zostać jeszcze naprawiony z powodu innych priorytetów.

Jest prawie gotowy. Próbowałem uruchomić czysty Magento 1.9.2.1 z PHP 7 RC1, co spowodowało natychmiastową awarię (błąd krytyczny) Magento. Po naprawieniu tego problemu wszystko wydawało się działać, z wyjątkiem backendu, do którego nie mogłem się zalogować. Później okazało się, że jest to problem związany z sesją, który można załatać.

Krótko:

1. Błąd krytyczny można naprawić, zastępując, Mage_Core_Model_Layouta następnie zmieniając wiersz 555 z:
   $out .= $this->getBlock($callback[0])->$callback[1]();
   na
   $out .= $this->getBlock($callback[0])->{$callback[1]}();

2. Problem sesji chwilowo może być ustalona na podstawie nadrzędnych Mage_Core_Model_Session_Abstract_Varieni przepisywania getData, setData, unsetData, addFullNamesmetody, więc wszędzie tam, gdzie $this->_databył używany, to zostaną zastąpione $_SESSION.

Jeśli ktoś jest zainteresowany rozwiązaniem, można je znaleźć tutaj .

Magento2 jest gotowy na PHP 7. Dostosowanie kodu do PHP7 zostało wykonane i wszystkie zmiany są dostępne w gałęzi developerskiej. Zobacz problem na GitHub

Ponadto obsługa php 7 w Magento1 wymaga wstecznie niezgodnych zmian i myślę, że nie będzie oficjalnie obsługiwana.

Występuje problem z tym, jak Magento oblicza całkowitą sumę zamówienia i stosuje rabaty. To także powstrzymuje ekspresową kasę Paypal, ponieważ elementy zamówienia nie sumują się do ogólnej sumy z rabatem.

Problem wydaje się polegać na tym, że Mage_Sales_Model_Config_Ordered::_compareTotals()nie działa on tak samo w PHP7 jak PHP5 i uasort()teraz opiera się na relacjach przechodnich przy porządkowaniu, ale nie musi to dotyczyć sum zamówień.

Spróbuj użyć: -

protected function _getSortedCollectorCodes()
{
    if (Mage::app()->useCache('config')) {
        $cachedData = Mage::app()->loadCache($this->_collectorsCacheKey);
        if ($cachedData) {
            return unserialize($cachedData);
        }
    }
    $configArray = $this->_modelsConfig;
    // invoke simple sorting if the first element contains the "sort_order" key
    reset($configArray);
    $element = current($configArray);
    if (isset($element['sort_order'])) {
        uasort($configArray, array($this, '_compareSortOrder'));
    } else {
        foreach ($configArray as $code => $data) {
            foreach ($data['before'] as $beforeCode) {
                if (!isset($configArray[$beforeCode])) {
                    continue;
                }
                $configArray[$code]['before'] = array_unique(array_merge(
                    $configArray[$code]['before'], $configArray[$beforeCode]['before']
                ));
                $configArray[$beforeCode]['after'] = array_merge(
                    $configArray[$beforeCode]['after'], array($code), $data['after']
                );
                $configArray[$beforeCode]['after'] = array_unique($configArray[$beforeCode]['after']);
            }
            foreach ($data['after'] as $afterCode) {
                if (!isset($configArray[$afterCode])) {
                    continue;
                }
                $configArray[$code]['after'] = array_unique(array_merge(
                    $configArray[$code]['after'], $configArray[$afterCode]['after']
                ));
                $configArray[$afterCode]['before'] = array_merge(
                    $configArray[$afterCode]['before'], array($code), $data['before']
                );
                $configArray[$afterCode]['before'] = array_unique($configArray[$afterCode]['before']);
            }
        }
        foreach ($configArray as $code => $data) {
           $largest_small = $smallest_large = 0;
           foreach ($data['after'] as $afterCode) {
              if(isset($configArray[$afterCode]['sort_order']) && $largest_small < $configArray[$afterCode]['sort_order'])
                 $largest_small = $configArray[$afterCode]['sort_order'];
           }
           foreach ($data['before'] as $beforeCode) {
              if(isset($configArray[$beforeCode]['sort_order']) && ($smallest_large == 0 || $configArray[$beforeCode]['sort_order'] < $smallest_large)) 
                 $smallest_large = $configArray[$beforeCode]['sort_order'];
           }
           if($smallest_large <= $largest_small+1){
              if($smallest_large == 0) $smallest_large = $largest_small+1;
              $add = $largest_small+2-$smallest_large;
              foreach ($configArray as $code1 => $data1) {
                 if(!isset($data1['sort_order'])) break;
                 if($smallest_large <= $data1['sort_order'])
                    $configArray[$code1]['sort_order'] += $add;
               }
           }
           $configArray[$code]['sort_order'] = $largest_small+1;
        }
        uasort($configArray, array($this, '_compareSortOrder'));
    }
    $sortedCollectors = array_keys($configArray);
    if (Mage::app()->useCache('config')) {
        Mage::app()->saveCache(serialize($sortedCollectors), $this->_collectorsCacheKey, array(
                Mage_Core_Model_Config::CACHE_TAG
            )
        );
    }
    return $sortedCollectors;
}

To są moje badania, którymi chcę się podzielić z wami na temat niezgodności php7 magento. Obecnie znalazłem kilka miejsc, w których kod powinien zawieść z powodu jednolitej składni zmiennych.

Plik: app / code / core / Mage / ImportExport / Model / Export / Entity / Product / Type / Abstract.php

Metoda: overrideAttribute

$data['filter_options'] = $this->$data['options_method']();

Plik: app / code / core / Mage / ImportExport / Model / Export / Entity / Customer.php

Metoda: filterAttributeCollection

$data['filter_options'] = $this->$data['options_method']();

Plik: app / code / core / Mage / ImportExport / Model / Import / Uploader.php

Metoda: _validateFile

$params['object']->$params['method']($filePath);

Plik: app / code / core / Mage / Catalog / Model / Product / Link / Api / V2.php

Metoda: przypisać

if (isset($data->$attribute['code'])) {
    $links[(int)$linkedProductId][$attribute['code']] = $data->$attribute['code'];
}

Plik: app / code / core / Mage / Catalog / Model / Product / Link / Api / V2.php

Metoda: aktualizacja

$data->$attribute['code']

Plik: lib / Varien / File / Uploader.php

Metoda: _validateFile

$params['object']->$params['method']($this->_file['tmp_name']);

Plik: app / code / core / Mage / Core / Model / Layout.php

Metoda: getOutput

$out .= $this->getBlock($callback[0])->$callback[1]();

Oprócz innych odpowiedzi związanych z Magento 1:

W Zend_XmlRpc_ServerZend Framework 1.12.12 naprawiono niezgodność PHP 7 z

• Dziennik zmian
• PR

Wszystkie wersje wcześniejsze niż CE 1.9.2.2 / EE 1.14.2.2 używają starszej wersji Zend Framework, dlatego mogą wystąpić problemy, jeśli użyjesz interfejsu API XML-RPC Magento.

Sprawdź pliki z inchoo, które zostały zmienione, aby M1 był kompatybilny z php 7, to niewielkie zmiany w kilku plikach, ale inteligentna praca Inchoo. https://github.com/Inchoo/Inchoo_PHP7/tree/master/app/code/local/Inchoo/PHP7

Używam Magento 2 CE w wersji 2.1.4 i działa dobrze.

magento \ app \ bootstrap.php

if (!defined('PHP_VERSION_ID') || !(PHP_VERSION_ID >= 50005 && PHP_VERSION_ID < 50700 || PHP_VERSION_ID === 70002 || PHP_VERSION_ID === 70004 || PHP_VERSION_ID >= 70006)) {
    if (PHP_SAPI == 'cli') {
        echo 'Magento supports PHP 5.6.5, 7.0.2, 7.0.4 and 7.0.6 or later. ' .
            'Please read http://devdocs.magento.com/guides/v1.0/install-gde/system-requirements.html';
    } else {
        echo <<<HTML
<div style="font:12px/1.35em arial, helvetica, sans-serif;">
    <p>Magento supports PHP 5.6.5, 7.0.2, 7.0.4 and 7.0.6 or later. Please read
    <a target="_blank" href="http://devdocs.magento.com/guides/v1.0/install-gde/system-requirements.html">
    Magento System Requirements</a>.
</div>
HTML;
    }
    exit(1);
}

Krótka odpowiedź brzmi „nie”. Magento CE 1.9.2.4 oficjalnie obsługuje PHP 5.4 i 5.5. Podczas gdy PHP 5.6 działa dobrze, nasyca pliki dziennika mnóstwem komunikatów ostrzegawczych.

Długa odpowiedź jest taka, że ​​stosunkowo łatwo go zmodyfikować, aby obsługiwał obsługę PHP7. Jednak wiele rozszerzeń nadal nie jest kompatybilnych z PHP7, więc w dużej mierze jesteś sam.

PHP 7.0 przestaje istnieć od pierwszego tygodnia grudnia 2018 r.

W tym poście aktualna wersja Magento 2.2.3 (wydanie z 20 lutego 2018 r.) Nie obsługuje PHP 7.1 ani PHP 7.2.

Obsługiwane wersje możesz potwierdzić, sprawdzając app/bootstrap.phpfolder instalacyjny Magento i szukając kodu podobnego do następującego:

/* PHP version validation */
if (!defined('PHP_VERSION_ID') || !(PHP_VERSION_ID === 70002 || PHP_VERSION_ID === 70004 || PHP_VERSION_ID >= 70006)) {
    if (PHP_SAPI == 'cli') {
        echo 'Magento supports 7.0.2, 7.0.4, and 7.0.6 or later. ' .
            'Please read http://devdocs.magento.com/guides/v1.0/install-gde/system-requirements.html';
    } else {
        echo <<<HTML
<div style="font:12px/1.35em arial, helvetica, sans-serif;">
    <p>Magento supports PHP 7.0.2, 7.0.4, and 7.0.6 or later. Please read
    <a target="_blank" href="http://devdocs.magento.com/guides/v1.0/install-gde/system-requirements.html">
    Magento System Requirements</a>.
</div>
HTML;
    }
    exit(1);
}

Wydaje się również, że występują problemy, .htaccessktóre powodują 500 błędów w Apache 2.4.

Dodatkowo dołączony plik kompozytora zawiera tylko zależności dla php5.5