PHP & Microsoft Excel & CSV import & encoding

Csak egy link, ami többet mond száz szónál:

https://stackoverflow.com/a/4440143

Én a linkelt megoldást preferálom.

PHP_INI_SCAN_DIR környezeti változó a PHP-ban

Mire is jó ez a PHP_INI_SCAN_DIR?

Ha ez a környezeti változó be van állítva a PHP futási környezetében, akkor az ebben tárolt útvonalon megpróbál minden *.ini fájlt betölteni, amellyel felüldefiniálhatóak a korábban már beolvasott "php.ini" beállítások.

Bővebben angolul a PHP dokumentációjában: http://php.net/manual/en/configuration.file.php#configuration.file.scan

FONTOS:
Ne tévesszük össze a futtatható php parancssori kapcsolói közül a "-c <path>|<file>" lehetőséggel. Ez utóbbi arra való, hogy ha érvényes fájlra vagy könyvtárra mutat, akkor a php beállításokat tartalmazó fájlokat onnan próbálja beolvasni. Ha a -c kapcsoló nem mutat érvényes fájlra vagy könyvtárra, akkor a PHP az alapértelmezett helyek valamelyikén keres majd megfelelő ini állományt.

Ui.: A fenti változó nagyon hasznosnak fog bizonyulni a saját kis webszerveren további pofozgatásában, mert már meguntam, hogy az egyik PHP verzióban egy kicsit másképpen vannak beállítva olyan általános értékek, mint például a feltölthető maximális fájlméret (max_upload_filesize) vagy a POST kérések maximális mérete (post_max_size) és hasonlók.

Phalcon v2.0.0 UPGRADE

Kb. 1 hete jött ki a Phalcon v2.0.0, amelynek a legfőbb célja, hogy a v1.3.x-es verzióvonal forráskódjait átültessék a PHP szintakszisához elég közel álló Zephir nyelvre, ami szintén a Phalcon készítők gyermeke.

Zephir röviden:

Mindenki vessen egy pillantást a Zephir köztes nyelvre, amely hidat képez a C és a PHP között, és leegyszerűsítheti a saját PHP modulok írását. Mi sem bizonyítja ezt jobban, mint a most kiadott Phalcon v2.0.0 *.zep kiterjesztésű forrás állományai.

Ennyit a Zephir-ről!

A Phalcon v1.3.x --> v2.0.0 upgrade folyamatról írt néhány sort a Phalcon csapata is a blogjukban.

Ebből a cikkből is látszik, hogy elsődleges céljuk egy Zephir alapú v2.0.0 verzió megalkotása volt felhasználva a v1.3.4-es verzió kódjait és funkcionalitását, ami azt eredményezi, hogy a lehető legnagyobb mértékben kompatibilis a v2.0.0 a v1.3.4-el, kivéve néhány pontot természetesen. :)

Egy Phalcon-ra épített projektben az upgrade során szerzett tapasztalataim a következők voltak:

(a lista még bővülhet) 

------------------------------------------------------------

\Phalcon\DI\InjectionAwareInterface->setDi() metódus fejléce megváltozott:

    public function setDI($dependencyInjector)

        -->

    public function setDI(\Phalcon\DiInterface $dependencyInjector)

------------------------------------------------------------

\Phalcon\Mvc\Application->registerModules metódus fejléce megváltozott:

    public function registerModules($modules, $merge=null){ }

        -->

    public function registerModules(array $modules, $merge = null) {}

------------------------------------------------------------

A \Phalcon\Config értékek nem lehetnek callback és/vagy Closure típusúak, mert

akkor a ->merge() metódus ki fog akadni!!!

Egyetlen egyszer be tudja a ->merge() állítani a Closure típusú értéket, de ha egy már Closure típusú érték helyére egy újabbat kellene összefésülni, akkor fog kiakadni "Call to undefined method Closure::count()" kivétel üzenettel.
A jelenséget ez az if elágazás okozza a Phalcon forrásában:

https://github.com/phalcon/cphalcon/blob/phalcon-v2.0.0/phalcon/config.zep#L227

------------------------------------------------------------

\Phalcon\Mvc\Router->getDefaultModule() metódus nem létezik Phalcon v2.0 alatt

------------------------------------------------------------

\Phalcon\Events\EventsAwareInterface::setEventsManager() metódus fejléce eltér 

Phalcon v2.0 alatt:

\Phalcon\Events\EventsAwareInterface::setEventsManager($eventsManager) 

-->

\Phalcon\Events\EventsAwareInterface::setEventsManager(Phalcon\Events\ManagerInterface $eventsManager) 

------------------------------------------------------------

Az alábbi utasítás formát át kell írni:

\Phalcon\Mvc\Model::find(array(
'conditions' => '...',
'bind' => array( 1 => 'VALUE'),
'bindTypes' => array(\Phalcon\Db\Column::BIND_PARAM_***),
));

A következőre:

\Phalcon\Mvc\Model::find(array(
'conditions' => '...',
'bind' => array( 1 => 'VALUE'),
'bindTypes' => array( 1 => \Phalcon\Db\Column::BIND_PARAM_***),
));

Röviden:
A 'bindTypes' tömbnek az indexelése most már minden esetben követnie kell a 'bind' tomb indexelését.


------------------------------------------------------------

\Phalcon\Mvc\Model\ValidatorInterface->validate() metódus fejléc megváltozott 
Phalcon v2.0 alatt
public function validate($record);
--> 
public function validate(\Phalcon\Mvc\ModelInterface $record);

------------------------------------------------------------

Phalcon XSLT sablon motor

Már egy ideje pofozgatom az alábbi XSLT alapú sablon motort, amely kifejezetten a Phalcon PHP-s keretrendszerhez lett kialakítva:

Packagist link:
https://packagist.org/packages/racztiborzoltan/phalcon-xslt-view-engine

Github:
https://github.com/racztiborzoltan/phalcon-xslt-view-engine

Még nem igazán tartom tökéletesnek, de a céljaimnak egyenlőre meg fog felelni. Amúgy is sokat fejlődött az első kiadáshoz képest!

De egyre jobban érik egy v2.x ág elindításának a gondolata.



Próbáljuk meg egészséggel fogyasztani! :)

PHP Snippet: View szintek gyorsítótárazása Phalcon-ban

Nem nagyon találtam meg a Phalcon dokumentációjában, csak némi google zaklatás után.

A helyzet: Phalcon View objektumban beállítható, hogy legyen gyorsítótárazva a nézet, de ekkor a legfelső szinttől a teljes tartalmat gyorsítótárazza. Ha a renderelési szint lejjebb van állítva, akkor nem készít gyorsítótár bejegyzést.

DE!!! Van egy a dokumentációban nem említett beállítás, amellyel megadható, hogy a View objektum melyik szintjének kimenete legyen eltéve a gyorsítótárba.

Ezt pedig a következőképpen lehetséges:

    $view->cache(array(
        'level' => \Phalcon\Mvc\View::LEVEL_ACTION_VIEW
    ));


----
Örültem a szerencsének!

-----------------------------------------------------------

Kiegészítés a fenti bejegyzéshez (2014-04-02)

Nem minden esetben történik meg a fentebb említetthez hasonló beállítások mellett a megfelelő View szintek gyorsítótárazása.

Az alábbi érdekes jelenségeket tapasztaltam ezzel kapcsolatban:

1. Ha nincs megadva a ->cache() metódusban a gyorsítótárazandó szint, akkor csak a LEVEL_MAIN_LAYOUT renderelési View szint esetén fog automatikusan gyorsítótárazni.
   (Ez a pont inspirálta a fenti bejegyzést! :))
2. A View esetén beállított renderelési szintnek nagyobbnak kell lennie a gyorsítótárazandó View szintnél, hogy beinduljon az automatikus gyorsítótárazás
3. LEVEL_LAYOUT renderelési szint esetén bármilyen gyorsítótárazandó szint beállítása esetén két eredményt sikerült kicsiholnom:
• Nem volt gyorsítótár bejegyzés létrehozva,
• Vagy állandóan csak a LEVEL_LAYOUT szint lett csak a gyorsítótárba letárolva, annak ellenére, hogy pl. LEVEL_ACTION_VIEW lett megjelölve a gyorsítótárazandó View szintnek
4. Egy hasznos, gyakorlati kísérletezgetések utáni tanács:Ha a ->cache() metódusban a 'level' értéknek TRUE-t adunk meg, akkor éppen a View-nak beállított renderelési szint teljes tartalma fog a gyorsítótárba bekerülni.
   Valamint, ha ugyanez a 'level' érték FALSE-t kap, akkor nem lesz gyorsítótár generálva!
   

Egyenlőre ennyi!

PHP függvény hívás gyors teszt

in medias res:

<?php
$foo = function($a, $b, $c)
{
    $j = 5-10-34-1+3/5;
    //    echo 'foo function';
};


function foo($a, $b, $c)
{
    $j = 5-10-34-1+3/5;
}


class Bar
{
    public static function static_foo($a, $b, $c)
    {
        $j = 5-10-34-1+3/5;
    }
   
    public function foo($a, $b, $c)
    {
        $j = 5-10-34-1+3/5;
    }
   
   
}


$max = 10000;

echo '1 - '.$max;
echo '<br />';echo '<br />';


echo 'foo(1, 2, 3)';echo '<br />';
$i = 0;
$time = microtime(true);
while ($i<$max)
{
    foo(1, 2, 3);
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo '$foo = function($a, $b, $c){ /* ... */ }';echo '<br />';
echo '$foo(1,2,3)';echo '<br />';
$i = 0;
$time = microtime(true);
while ($i<$max)
{
    $foo(1, 2, 3);
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo '$function = "foo";';echo '<br />';
echo '$function(1, 2, 3)';echo '<br />';
$i = 0;
$function = 'foo';
$time = microtime(true);
while ($i<$max)
{
    $function(1, 2, 3);
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo "call_user_func('foo', 1, 2, 3)";echo '<br />';
$i = 0;
$time = microtime(true);
while ($i<$max)
{
    call_user_func('foo', 1, 2, 3);
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo "call_user_func_array('foo', array(1, 2, 3))";echo '<br />';
$i = 0;
$time = microtime(true);
while ($i<$max)
{
    call_user_func_array('foo', array(1, 2, 3));
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo "call_user_func(array('Bar', 'foo'), 1,2,3)";echo '<br />';
$i = 0;
$time = microtime(true);
while ($i<$max)
{
    call_user_func_array(array('Bar', 'foo'), array(1,2,3));
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo 'call_user_func_array(array("Bar", "foo"), array(1,2,3))';echo '<br />';
$i = 0;
$time = microtime(true);
while ($i<$max)
{
    call_user_func_array(array('Bar', 'foo'), array(1,2,3));
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo 'call_user_func_array("Bar::foo"), array(1,2,3))';echo '<br />';
$i = 0;
$time = microtime(true);
while ($i<$max)
{
    call_user_func_array('Bar::foo', array(1,2,3));
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo '$bar->{$function}(1, 2, 3)';echo '<br />';
$i = 0;
$bar = new Bar(1, 2, 3);
$time = microtime(true);
while ($i<$max)
{
    $function = 'foo';
    $bar->{$function}(1, 2, 3);
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo '$class::$function(1, 2, 3)';echo '<br />';
$i = 0;
$class = 'Bar';
$function = 'static_foo';
$time = microtime(true);
while ($i<$max)
{
    $class::$function(1, 2, 3);
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';
?>


---------------------------------------------

Majd egy nálam produkált egyik kimenet:


1 - 10000

foo(1, 2, 3)
0.1220018863678

$foo = function($a, $b, $c){ /* ... */ }
$foo(1,2,3)
0.23000001907349

$function = "foo";
$function(1, 2, 3)
0.13000011444092

call_user_func('foo', 1, 2, 3)
0.21000099182129

call_user_func_array('foo', array(1, 2, 3))
0.22499990463257

call_user_func(array('Bar', 'foo'), 1,2,3)
0.27999997138977

call_user_func_array(array("Bar", "foo"), array(1,2,3))
0.29000091552734

call_user_func_array("Bar::foo"), array(1,2,3))
0.29000020027161

$bar->{$function}(1, 2, 3)
0.13499999046326

$class::$function(1, 2, 3)
0.13499999046326



---------------------------------------------

Kb. a dobogó:

• 1. hely
• foo(1, 2, 3)
•  2. hely
• $function = "foo"; $function(1, 2, 3)
• $bar->{$function}(1, 2, 3)
• $class::$function(1, 2, 3)
• 3. hely:
• call_user_*()

Forráskód

Időnként találkozik az ember ilyesmivel is:

for($i=0; $i<count($items); $i++)

{

    switch(i)

    {

        case 0:

            ...

            break;

        case 1:

            ...

            break;

        case 2:

            ...

            break;

        .

        .

        .

    }

}

(Multiline) comment regex PHP preg-re

http://ostermiller.org/findcomment.html
A fenti oldalon egy jól össszerakott regex van.

(/\*([^*]|[\r\n]|(\*+([^*/]|[\r\n])))*\*+/)|(//.*)

Hogy PHP preg függvényei is bevegyék, cserélni kell a '/' jeleket '\/' kvótázott változatra.
Tehát comment törlés esetén pl.:

$str = preg_replace('/(\/\*([^*]|[\r\n]|(\*+([^*\/]|[\r\n])))*\*+\/)|(\/\/.*)/', '', $str);

A karaktercserékre akkor van szükség, ha ragaszkodunk a PCRE '/' határoló karaktereihez.
Mert ha a határolók között megadott kifejezés tartalmazza a határoló karaktert, akkor azt kvótázni kell.

Ha más elválasztót választunk, akkor:

$str = preg_replace('#(/\*([^*]|[\r\n]|(\*+([^*/]|[\r\n])))*\*+/)|(//.*)#', '', $str);

session cookie + (chrome || explorer )

Probléma:

• Egy localhost x/y/z mappájába átrángatott projekt bejelentkező felület session cookie-val, ahogy kell
• Firefox és Opera OK, de Chrome és IE (most nálam Internet Explorer 9) nem ment
• A hibát visszavezettem a session cookie-ra, vagyis ez a két böngésző valahogy nem kapta meg a session cokie-t vagy mi  a fene
• További keresgélésem a Chrome-ra irányult főképpen.

Hibaforrás:

• Mint kiderült a Chrome-nak van egy érdekes hibája, vagy inkább hiányzó tulajdonsága
• Olyasmiről van szó, hogy a "localhost" címekről nem fogad el bizonyos cookie-kat. (link a sok közül a guglizás után)

Megoldás:

• "localhost" helyett más nevet állítsunk be a 127.0.0.1 IP címre
• A megfelelő host fájlban adjuk meg egy ehhez hasonló bejegyzést:
• 127.0.0.1 localhost.hu
• Megjegyzés: Már létezik localhost.hu domain alatt weboldal, de az nem fog bekavarni!
• Most már írhatjuk a "localhost" helyett a címekben a "localhost.hu"-t a problémás böngészőkben
• Egy megoldást az előbbi linken is leírtak, amit kipróbáltam egy hordozható Chrome 14-en, de azon nem jött be. Lehet nem a GoogleChromePortable.exe-t kellett volna paraméterezni. Mindegy!