Az FtpUse egy aprócska program, amit feltelepítve parancssorosan lehet meghajtó betűjelhez rendelni egy-egy ftp kapcsolatot.
Szerintem nagyon egyszerű a használata.
A programról bővebben a https://www.ferrobackup.com/map-ftp-as-disk.html URL címen.
Ui.: az első próbálkozások után nem igazán tudtam hordozható állapotra varázsolni, de ez valószínűleg a Dokan meghajtók miatt lehet.
A Dokan könyvtárról bővebben itt: https://dokan-dev.github.io/
2018. augusztus 24., péntek
2018. augusztus 14., kedd
Reguláris kifejezés: Az URL abszolút hivatkozás?
Reguláris kifejezéssel általában így szoktam tesztelni, hogy egy URL abszolút hivatkozás-e:
^((https?):)?//
A fenti kifejezés illeszkedik az alábbiakra:
http://www.example.com
https://www.example.com
//www.example.com
http://example.com
https://example.com
//example.com
De nem illeszkedik például az alábbiakra:
assets/page.js
/relative-from-document-root/assets/page.js
^((https?):)?//
A fenti kifejezés illeszkedik az alábbiakra:
http://www.example.com
https://www.example.com
//www.example.com
http://example.com
https://example.com
//example.com
De nem illeszkedik például az alábbiakra:
assets/page.js
/relative-from-document-root/assets/page.js
Magyarázat:
- A szöveg elejére nézi az illeszkedést a "^" karakter
- A szöveg elején 0 vagy egyszer szerepelhet a "https" karaktersorozat, amelyben az "s" karakter 0 vagy egyszer fordulható elő a "http" szöveg után
- Az illeszkedő "http" vagy "https" szöveget követni kell egy ":" karakternek
- Ha van illeszkedő "http:" vagy "https:" karaktersorozat a szöveg elején, akkor ezek 0 vagy egyszer fordulhatnak elő ("((https?):)?")
- Ha volt protokoll illeszkedés, akkor utána legyen egy "//" karaktersorozat, vagy protokoll nélküli feltüntetés esetén a szöveg azonnal a "//" karaktersorozattal kezdődjön
www kiegészítés
Ha szükséges a "www." előtagra való illeszkedés is, akkor a fenti kifejezés kibővül az alábbira:
^((https?):)?//(www.)?
Használjátok egészséggel!
XSLT - minden másolása
Jó dolog ez az XSLT!
Például ha azt szeretnénk, hogy egy XML forrásból minden elem át legyen másolva a generált tartalomba, akkor a következő egyszerű és rekurzív XSLT sablont is lehet definiálnunk:
<xsl:template match="node()|@*">
<xsl:copy>
<xsl:apply-templates select="node()|@*" />
</xsl:copy>
</xsl:template>
Például ha azt szeretnénk, hogy egy XML forrásból minden elem át legyen másolva a generált tartalomba, akkor a következő egyszerű és rekurzív XSLT sablont is lehet definiálnunk:
<xsl:template match="node()|@*">
<xsl:copy>
<xsl:apply-templates select="node()|@*" />
</xsl:copy>
</xsl:template>
Röviden:
A fenti szabály illeszkedik minden xml csomópontra és xml attributumra. Ha illeszkedik, akkor ugye
lefut.
Működése: az illeszkedő elemet (legyen az éppen aktuálisan egy csomópont, vagy attributum) másold át a cél dokumentumba. A másolás után alkalmazd újra az összes definiált XSLT sablon szabályt az aktuális csomóponton belül közvetlenül minden gyerek csomópontra, vagy attributumra.
Zseniális?
Update: egy angol nyelvű bővebb cikk a fentiekről: http://www.usingxml.com/Transforms/XslIdentity
Update: egy angol nyelvű bővebb cikk a fentiekről: http://www.usingxml.com/Transforms/XslIdentity
2018. augusztus 12., vasárnap
PHP "arg_separator.output" beállítási lehetőség legyen inkább "&"
Előtörténet:
2018-at írunk, és van egy honlap, amely egy mondjuk valamennyire régebbecske tárhelyen foglal helyet. Kapott egy kis felújítást és a későbbiekben is fog kapni ezt-azt. Mondjuk, hogy ez egy olyan kis hobby oldalam. Elvállaltam.
A tárhely PHP 5.3.10. Nem mai darab, ezt azt hiszem ki lehet jelenteni.
Saját localhost-on szintén egy PHP 5.3.29 lett beállítva az oldal fejlesztéséhez. Lent minden tökéletes volt. Felmásoltam.
A probléma ott kezdődött, hogy egy oldalon volt egy átirányítás, ha nem voltak bizonyos url paraméterek a kérésben. A szükséges default url paraméterekkel készítettem egy url, és azt header() függvénnyel ki is lett küldve, ami lent tökéletesen működött.
A szükséges plusz paraméterek a http_build_query() függvénnyel lettek hozzáfűzve az új URL-hez, és egy Location: header kíséretében ki lett küldve az éterbe.
De az átirányított url-ben a "&" paraméterek helyett "&" szerepelt. Ez így nem kóser, és elkezdtem kutatni.
A hibakeresés addig mindent rendben talált, hogy a http_build_query() függvény még helyes kimenetet ad.
Talán a header() függvényben van valami turpisság, illetve annak valamilyen beállítása?
...
Végül odáig fajult a dolog, hogy összehasonlítottam a lenti és a fenti phpinfo() kimenetét, azon belül a konfiuráiciós értékek listáját. Először tovább siklott a tekintetem, de utána ráakadtam a címben említett "arg_separator.output" beállítási lehetőségre, ami vajon mi volt az éles helyen? Hát persze, hogy "&" és lent nálam pedig az "&" érték.
Mivel az éles tárhelyen nem férek hozzá a php.ini beállításokhoz közvetlenül, de szerencsére az ini_set() függvény nem lett letiltva, ezért ezen keresztül lett orvosolva a hiba.
Milyen kis apróság, és közel 1 órás nagyon izgalmas hibakereséssel gazdagította (?) az életemet.
2018-at írunk, és van egy honlap, amely egy mondjuk valamennyire régebbecske tárhelyen foglal helyet. Kapott egy kis felújítást és a későbbiekben is fog kapni ezt-azt. Mondjuk, hogy ez egy olyan kis hobby oldalam. Elvállaltam.
A tárhely PHP 5.3.10. Nem mai darab, ezt azt hiszem ki lehet jelenteni.
Saját localhost-on szintén egy PHP 5.3.29 lett beállítva az oldal fejlesztéséhez. Lent minden tökéletes volt. Felmásoltam.
A probléma ott kezdődött, hogy egy oldalon volt egy átirányítás, ha nem voltak bizonyos url paraméterek a kérésben. A szükséges default url paraméterekkel készítettem egy url, és azt header() függvénnyel ki is lett küldve, ami lent tökéletesen működött.
A szükséges plusz paraméterek a http_build_query() függvénnyel lettek hozzáfűzve az új URL-hez, és egy Location: header kíséretében ki lett küldve az éterbe.
De az átirányított url-ben a "&" paraméterek helyett "&" szerepelt. Ez így nem kóser, és elkezdtem kutatni.
A hibakeresés addig mindent rendben talált, hogy a http_build_query() függvény még helyes kimenetet ad.
Talán a header() függvényben van valami turpisság, illetve annak valamilyen beállítása?
...
Végül odáig fajult a dolog, hogy összehasonlítottam a lenti és a fenti phpinfo() kimenetét, azon belül a konfiuráiciós értékek listáját. Először tovább siklott a tekintetem, de utána ráakadtam a címben említett "arg_separator.output" beállítási lehetőségre, ami vajon mi volt az éles helyen? Hát persze, hogy "&" és lent nálam pedig az "&" érték.
Mivel az éles tárhelyen nem férek hozzá a php.ini beállításokhoz közvetlenül, de szerencsére az ini_set() függvény nem lett letiltva, ezért ezen keresztül lett orvosolva a hiba.
Milyen kis apróság, és közel 1 órás nagyon izgalmas hibakereséssel gazdagította (?) az életemet.
2018. augusztus 2., csütörtök
Apache beállítás - FcgidInitialEnv
Előtörténet:
Röviden: elkezdtem magamnak egy saját kis fejlesztői webszervert összerakni már évek óta folyamatosan, amiről valószínűleg több bejegyzés is fog születni, mert érdemesnek tartom megosztani néhány kódrészletet.
Az apache-ban (amiből egyenlőre csak egy példányt tudok futtatni, de ez nem lesz mindig így) egy újabb lehetőséget szerettem volna megvalósítani, ami sikerült is, mások segítségével. Köszönet Nagy Gergőnek és közvetve Dankó Dávidnak, aki Nagy Gergőnek segített ezt magvalósítani.
pl.: "localhost/php55" és a "localhost/php56" alatt ugyanaz a root mappa kerüljön kiszolgálásra, de eltérő PHP verziók segítségével. Ezt sikerült is megoldani, amihez soft linkekre volt szükségem, valamint néhány fcgi php folyamat definiálására.
(Majd néhány kódmorzsát megosztok később.)
A dolog eddig úgy látszott, hogy tökéletesen működik.
DE! Egy új projektet kellett beindítani localhost alatt, de panaszkodott, hogy nem tudja írni a session mentéséhez mappát. Kis kutakodás után rájöttem, hogy a php.ini-ben a session.save_path beállításnál használt környezeti változómat nem látja a fcgi-ban indított PHP-m. Normál apache PHP modulként működött a dolog.
Rövid kerekített 5 perces keresgélés után meg is lett a megoldás. Az apache httpd.conf fájlban az fcgi definiálásakor szükséges volt megadni FcgidInitialEnv beállítást is.
Dokumentáció:
https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidinitialenv
Ui.: Mire képes az "apache és php fejlesztői csomagom"?
- egyetlen apache verzió
- több php verzió (5.3.x, 5.4.x, 5.5.x, 5.6.x, 7.0.x, 7.1.x, 7.2.x, 7.3.x), amelyből mindig a legújabb patch verziók vannak használva. A frissítés manuálisan történik, ami általában 3-4 percet vesz igénybe.
- "localhost" url kiszolgálása a apache_php_module segítségével, amely az alapértelmezetten beállított php verziót veszi alapul és annak megfelelőn állítja be az apache-ot is. Ennek a megváltoztatásához egy fájlban egy érték átállítására és az apache újraindítására van szükség.
- "localhost:80xx" különböző portokon különböző PHP verziók szolgálják ki a php fájlokat
- "localhost/phpxx" url-eken történő kiszolgálás különböző php verziókkal úgy, hogy mindegyik ilyen url ugyanazt a mappát mutatja, mint a "localhost" url.
Ui. 2.: Erről a kis saját fejlesztő csomagomról még írkálok ezt-azt. Egyetlen paranccsal indítható apache, több mysql, több php, composer, nginx, nodejs, stb..., és időnként van benne fejlődés, fejlesztés is, mint például, ahogy most is.
Röviden: elkezdtem magamnak egy saját kis fejlesztői webszervert összerakni már évek óta folyamatosan, amiről valószínűleg több bejegyzés is fog születni, mert érdemesnek tartom megosztani néhány kódrészletet.
Az apache-ban (amiből egyenlőre csak egy példányt tudok futtatni, de ez nem lesz mindig így) egy újabb lehetőséget szerettem volna megvalósítani, ami sikerült is, mások segítségével. Köszönet Nagy Gergőnek és közvetve Dankó Dávidnak, aki Nagy Gergőnek segített ezt magvalósítani.
pl.: "localhost/php55" és a "localhost/php56" alatt ugyanaz a root mappa kerüljön kiszolgálásra, de eltérő PHP verziók segítségével. Ezt sikerült is megoldani, amihez soft linkekre volt szükségem, valamint néhány fcgi php folyamat definiálására.
(Majd néhány kódmorzsát megosztok később.)
A dolog eddig úgy látszott, hogy tökéletesen működik.
DE! Egy új projektet kellett beindítani localhost alatt, de panaszkodott, hogy nem tudja írni a session mentéséhez mappát. Kis kutakodás után rájöttem, hogy a php.ini-ben a session.save_path beállításnál használt környezeti változómat nem látja a fcgi-ban indított PHP-m. Normál apache PHP modulként működött a dolog.
Rövid kerekített 5 perces keresgélés után meg is lett a megoldás. Az apache httpd.conf fájlban az fcgi definiálásakor szükséges volt megadni FcgidInitialEnv beállítást is.
Dokumentáció:
https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidinitialenv
Ui.: Mire képes az "apache és php fejlesztői csomagom"?
- egyetlen apache verzió
- több php verzió (5.3.x, 5.4.x, 5.5.x, 5.6.x, 7.0.x, 7.1.x, 7.2.x, 7.3.x), amelyből mindig a legújabb patch verziók vannak használva. A frissítés manuálisan történik, ami általában 3-4 percet vesz igénybe.
- "localhost" url kiszolgálása a apache_php_module segítségével, amely az alapértelmezetten beállított php verziót veszi alapul és annak megfelelőn állítja be az apache-ot is. Ennek a megváltoztatásához egy fájlban egy érték átállítására és az apache újraindítására van szükség.
- "localhost:80xx" különböző portokon különböző PHP verziók szolgálják ki a php fájlokat
- "localhost/phpxx" url-eken történő kiszolgálás különböző php verziókkal úgy, hogy mindegyik ilyen url ugyanazt a mappát mutatja, mint a "localhost" url.
Ui. 2.: Erről a kis saját fejlesztő csomagomról még írkálok ezt-azt. Egyetlen paranccsal indítható apache, több mysql, több php, composer, nginx, nodejs, stb..., és időnként van benne fejlődés, fejlesztés is, mint például, ahogy most is.
2018. július 26., csütörtök
restart (ismét)
Azt hiszem, hogy megpróbálom újrakezdeni ezt a blog dolgot.
A korábbi bejegyzések is megmaradnak.
Majd meglátjuk.
De az is megtörténhet, hogy keresek és találok blogger.com alternatívát.
A korábbi bejegyzések is megmaradnak.
Majd meglátjuk.
De az is megtörténhet, hogy keresek és találok blogger.com alternatívát.
2015. április 30., csütörtö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.
\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);
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
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.
------------------------------------------------------------
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);
------------------------------------------------------------
Feliratkozás:
Bejegyzések (Atom)