Néhány mobil, tablet, és asztali eszköz képernyő méretének gyűjteménye:
http://screensiz.es/
2019. január 20., vasárnap
2018. november 15., csütörtök
Google Chrome & sw.js & localhost & SSL
Röviden:
- localhost https kapcsolat alatt self signed ssl tanusítvány van beállítva.
- service worker sw.js regisztráció hibába ütközik tanusítvány probléma
- "An SSL certificate error occurred when fetching the script." és társai console hibaüzenetek.
- a google szerint a "unsafely-treat-insecure-origin-as-secure" chrom flag majd biztos megoldja.
- nem jön össze több kombóban sem
- De hoppá, hoppá, az újabb Chrome böngészőkben van erre egy elegánsabb megoldás
- Tehát: chrome://flags/#allow-insecure-localhost
2018. szeptember 17., hétfő
PHP: "/public" eltávolítása az URL-ből
Ez a probléma általában előjön az én esetemben.
A relativitás híve vagyok. Egy oldal menjen az éles tárhelyen a gyökérből, vagy akár egy almappából a fejlesztés helyén.
Persze a mai trendek nagyon tolják a "csinálj mindennek egy-egy virtualhost-ot" jellegű tutorialokat, és minden legyen bebetonozva.
Általában fel-felbukkan egy-egy olyan oldal, ahol még a képek, és más erőforrások elérését is "/" karakterrel kezdik, hogy az biztosan az oldalhoz tartozó document root szerver beállítástól legyen értelmezve. Hogy ez miért jó? Még nem tudom. De az is megtörténhet, hogy egyszer, előbb-utóbb a szemem elé akad egy cikk, amely elmagyarázza, hogy így fontos másodperceket is meg lehet spórolni a nagy látogatottságú és/vagy nagy erőforrás igényű oldalaknál.
Hasonló volt a helyzet a CDN tárhelyekről hosztolt harmadik féltől származó javascript, css, és font csomagok esetén is. Valóban gyorsabb lenne a kiszolgálás, ha a legtöbb dolgot külföldi CDN-ről menne. (cdnjs, jsdelivr, stb..), de mint később néhány cikk rávilágított, hogy a magyarországi hálózati rendszer felépítése éppen az ellenkező hatást váltja ki, és tovább tarthat több esetben a kiszolgálás, mint ha azt közvetlenül az oldal tárhelyéről szolgálódna ki, vagy egy másik magyarországi CDN tárhelyről.
No mindegy is.
Visszatérve a címben lévő témához.
Általában belefutok a fenti problémába. Főleg, ha olyan tárhely hozzáférést kapok, ami közvetlenül a document root mappára mutat és nem lehet egy szinttel feljebb másolni.
Persze itt most jöhet a következő jó gondolat: "miért nem másolja ki az ember fia az egész public mappát az oldal gyökerébe?" Mert néhány kísérlet talán ki lehet találni néhány fontos és létező útvonalat, amit nem kellene látni. "De erre meg ott van a .htaccess, vagy egy-egy üres index.html, stb..."
A vitát lehet folytatni még egy darabig. Ez vitathatatlan.
Szóval a lenti linken egy kis kód részlet érhető el, amely az URL-ben lévő "/public" karakter sorozatot távolítja el az URL-ből átirányítással:
https://gist.github.com/racztiborzoltan/e6ab85c3b54d7e8bc0d482ec3cee17e0
Szép napot!
A relativitás híve vagyok. Egy oldal menjen az éles tárhelyen a gyökérből, vagy akár egy almappából a fejlesztés helyén.
Persze a mai trendek nagyon tolják a "csinálj mindennek egy-egy virtualhost-ot" jellegű tutorialokat, és minden legyen bebetonozva.
Általában fel-felbukkan egy-egy olyan oldal, ahol még a képek, és más erőforrások elérését is "/" karakterrel kezdik, hogy az biztosan az oldalhoz tartozó document root szerver beállítástól legyen értelmezve. Hogy ez miért jó? Még nem tudom. De az is megtörténhet, hogy egyszer, előbb-utóbb a szemem elé akad egy cikk, amely elmagyarázza, hogy így fontos másodperceket is meg lehet spórolni a nagy látogatottságú és/vagy nagy erőforrás igényű oldalaknál.
Hasonló volt a helyzet a CDN tárhelyekről hosztolt harmadik féltől származó javascript, css, és font csomagok esetén is. Valóban gyorsabb lenne a kiszolgálás, ha a legtöbb dolgot külföldi CDN-ről menne. (cdnjs, jsdelivr, stb..), de mint később néhány cikk rávilágított, hogy a magyarországi hálózati rendszer felépítése éppen az ellenkező hatást váltja ki, és tovább tarthat több esetben a kiszolgálás, mint ha azt közvetlenül az oldal tárhelyéről szolgálódna ki, vagy egy másik magyarországi CDN tárhelyről.
No mindegy is.
Visszatérve a címben lévő témához.
Általában belefutok a fenti problémába. Főleg, ha olyan tárhely hozzáférést kapok, ami közvetlenül a document root mappára mutat és nem lehet egy szinttel feljebb másolni.
Persze itt most jöhet a következő jó gondolat: "miért nem másolja ki az ember fia az egész public mappát az oldal gyökerébe?" Mert néhány kísérlet talán ki lehet találni néhány fontos és létező útvonalat, amit nem kellene látni. "De erre meg ott van a .htaccess, vagy egy-egy üres index.html, stb..."
A vitát lehet folytatni még egy darabig. Ez vitathatatlan.
Szóval a lenti linken egy kis kód részlet érhető el, amely az URL-ben lévő "/public" karakter sorozatot távolítja el az URL-ből átirányítással:
https://gist.github.com/racztiborzoltan/e6ab85c3b54d7e8bc0d482ec3cee17e0
Szép napot!
2018. szeptember 5., szerda
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.
https://stackoverflow.com/a/4440143
Én a linkelt megoldást preferálom.
2018. szeptember 4., kedd
Kategória fa lekérdezése 3 szintig egy SQL utasításban
Optimalizálni kellett egy nagyobb kategória fának a lekérdezését, hogy egy SQL utasítással lehessen lekérdezni az összes szükséges információt, így ne legyen annyiszor megszólítva az adatbáziskezelő.
Természetesen már korábban is belefutottam a problémába, de eddig nem publikáltam semmit.
Tehát álljon itt egy SQL utasítás megjegyzésekkel:
--
-- SQL utasítás, amely faszerkezetbe rendezett kategóriákat tud
-- maximum 3 szintig listázni.
-- Az eredményt lineárisan bejárva a programozási nyelvben is lehet
-- egy több dimenziós tömböt felépíteni, mert nem fog előfordulni,
-- hogy a felsőbb szint esetleg később jönne a listában!
--
SELECT
-- TODO: További oszlopokat szabadon hozzáadni!
-- Az első táblában lévő információkra van szükségünk:
c_1.id
-- Ebben az oszlopban a kategória hierarchiának megfelelően fordított
-- sorrendben kerülnek "," karakterrel összefűzésre
-- Az eredményhalmaz feldolgozása során nagy segítséget nyújthat egy többdimenziós
-- szerkezet összeállításához.
, CONCAT_WS(",", c_1.id, c_2.id, c_3.id) AS category_hierarchy
-- Ez az oszlop azt számolja ki, hogy hányadik kategória szinten
-- fog elhelyezkedni az adott sorban lévő "c_1"-es kategória
, 1 + LENGTH(CONCAT_WS(",", c_1.id, c_2.id, c_3.id))
- LENGTH( REPLACE ( CONCAT_WS(",", c_1.id, c_2.id, c_3.id), ",", "") ) AS level_number
-- A listázott kategóriához hozzácsatoljuk, ha lehetséges a szülő kategóriáját,
-- és a szülő kategóriához hozzácsatoljuk annak a szülőjét is, ha lehetséges:
FROM category_tree AS c_1
LEFT JOIN category_tree AS c_2 ON c_1.parent_id = c_2.id
LEFT JOIN category_tree AS c_3 ON c_2.parent_id = c_3.id
WHERE
-- Ez csak apróság, de általában mindenhol jelen van egy "Látható-e a kategória"
-- típusú oszlop információ, ami alapján csak a publikus kategóriák lesznek listázva
-- Természetesen láthatóság nem csak a levél kategóriára lesz ellenőrizve.
-- Ha a szülő nem látható, akkor nem lenne értelme listázni a benne lévő
-- elemeket
(
c_1.status = 1
-- A 2. és 3. csatolt táblában az IS NULL is szükséges, mert nem biztos
-- hogy minden sorhoz lehetett további szülő és szülő-szülő kategóriát
-- csatolni. Ekkor ugye a LEFT JOIN miatt ezek a mezők NULL értékúek lesznek.
AND (c_2.status IS NULL OR c_2.status = 1)
AND (c_3.status IS NULL OR c_3.status = 1)
)
-- Ez a feltétel azt köti ki, hogy az 1. vagy a 2. vagy 3. szintnek a gyökérben
-- kell végződnie, amelynek már nincs szülője
AND (
c_1.parent_id IS NULL
OR c_2.parent_id IS NULL
OR c_3.parent_id IS NULL
)
ORDER BY
-- Szükséges növekvő sorban a szint számnak megfelelő sorba rendezni az
-- eredményeket, hogy az eredményhalmaz lineáris feldolgozása során ne legyen
-- olyan kategória, amelynek a szülője még nem került volna feldolgozásra.
level_number ASC
-- Érdemes valamilyen egyértelmű sorszámozást tartalmazó oszlop alapján
-- még rendezni az eredményeket:
, c_1.sequence_number ASC
Természetesen már korábban is belefutottam a problémába, de eddig nem publikáltam semmit.
Tehát álljon itt egy SQL utasítás megjegyzésekkel:
--
-- SQL utasítás, amely faszerkezetbe rendezett kategóriákat tud
-- maximum 3 szintig listázni.
-- Az eredményt lineárisan bejárva a programozási nyelvben is lehet
-- egy több dimenziós tömböt felépíteni, mert nem fog előfordulni,
-- hogy a felsőbb szint esetleg később jönne a listában!
--
SELECT
-- TODO: További oszlopokat szabadon hozzáadni!
-- Az első táblában lévő információkra van szükségünk:
c_1.id
-- Ebben az oszlopban a kategória hierarchiának megfelelően fordított
-- sorrendben kerülnek "," karakterrel összefűzésre
-- Az eredményhalmaz feldolgozása során nagy segítséget nyújthat egy többdimenziós
-- szerkezet összeállításához.
, CONCAT_WS(",", c_1.id, c_2.id, c_3.id) AS category_hierarchy
-- Ez az oszlop azt számolja ki, hogy hányadik kategória szinten
-- fog elhelyezkedni az adott sorban lévő "c_1"-es kategória
, 1 + LENGTH(CONCAT_WS(",", c_1.id, c_2.id, c_3.id))
- LENGTH( REPLACE ( CONCAT_WS(",", c_1.id, c_2.id, c_3.id), ",", "") ) AS level_number
-- A listázott kategóriához hozzácsatoljuk, ha lehetséges a szülő kategóriáját,
-- és a szülő kategóriához hozzácsatoljuk annak a szülőjét is, ha lehetséges:
FROM category_tree AS c_1
LEFT JOIN category_tree AS c_2 ON c_1.parent_id = c_2.id
LEFT JOIN category_tree AS c_3 ON c_2.parent_id = c_3.id
WHERE
-- Ez csak apróság, de általában mindenhol jelen van egy "Látható-e a kategória"
-- típusú oszlop információ, ami alapján csak a publikus kategóriák lesznek listázva
-- Természetesen láthatóság nem csak a levél kategóriára lesz ellenőrizve.
-- Ha a szülő nem látható, akkor nem lenne értelme listázni a benne lévő
-- elemeket
(
c_1.status = 1
-- A 2. és 3. csatolt táblában az IS NULL is szükséges, mert nem biztos
-- hogy minden sorhoz lehetett további szülő és szülő-szülő kategóriát
-- csatolni. Ekkor ugye a LEFT JOIN miatt ezek a mezők NULL értékúek lesznek.
AND (c_2.status IS NULL OR c_2.status = 1)
AND (c_3.status IS NULL OR c_3.status = 1)
)
-- Ez a feltétel azt köti ki, hogy az 1. vagy a 2. vagy 3. szintnek a gyökérben
-- kell végződnie, amelynek már nincs szülője
AND (
c_1.parent_id IS NULL
OR c_2.parent_id IS NULL
OR c_3.parent_id IS NULL
)
ORDER BY
-- Szükséges növekvő sorban a szint számnak megfelelő sorba rendezni az
-- eredményeket, hogy az eredményhalmaz lineáris feldolgozása során ne legyen
-- olyan kategória, amelynek a szülője még nem került volna feldolgozásra.
level_number ASC
-- Érdemes valamilyen egyértelmű sorszámozást tartalmazó oszlop alapján
-- még rendezni az eredményeket:
, c_1.sequence_number ASC
2018. augusztus 31., péntek
Laravel: cookie beállítása, hogy elérhető is legyen azonnal a response objektum megszületése előtt
Kóstolgatom a Laravel PHP keretrendszert.
Egyik problémám a címben némileg hosszan és hanyagul lett megfogalmazva.
Mert ugye van itt ez a:
Cookie::queue('key', 'value', 5);
Amivel a response létrejötte előtt lehet olyan cookie-kat definiálva, ami majd automatikusan hozzá lesz dobva a response objektumhoz, ha az már létezni tetszik. (nagyjából)
De nekem az kellett, hogy ha én azt mondom sablonosan, hogy
cookie_beallitasa($name, $value);
akkor a függvény meghívását követő sorban már ki tudjam adni a
\Cookie::get($name);
metódus hívást és éppen az előbb beállított $value értéket kapjam.
Erre jutottam:
$request->cookies->set('name', 'value');
echo \Cookie::get('name'); // output: 'value'
Hova is kellett ez nekem:
Egy middleware osztályba, ami a request handler lefutása előtt kellett, hogy beállítson néhány dolgot a cookie értékek közé.
Ui.: Valószínű, hogy van erre egy sokkal frappánsabb és egyszerűbb megoldás, de egy kevés google keresgélés után mindig a ::queue() metódusba futottam, de az éppen nem oldja meg a problémámat.
Egyik problémám a címben némileg hosszan és hanyagul lett megfogalmazva.
Mert ugye van itt ez a:
Cookie::queue('key', 'value', 5);
Amivel a response létrejötte előtt lehet olyan cookie-kat definiálva, ami majd automatikusan hozzá lesz dobva a response objektumhoz, ha az már létezni tetszik. (nagyjából)
De nekem az kellett, hogy ha én azt mondom sablonosan, hogy
cookie_beallitasa($name, $value);
akkor a függvény meghívását követő sorban már ki tudjam adni a
\Cookie::get($name);
metódus hívást és éppen az előbb beállított $value értéket kapjam.
Erre jutottam:
$request->cookies->set('name', 'value');
echo \Cookie::get('name'); // output: 'value'
Egy middleware osztályba, ami a request handler lefutása előtt kellett, hogy beállítson néhány dolgot a cookie értékek közé.
Ui.: Valószínű, hogy van erre egy sokkal frappánsabb és egyszerűbb megoldás, de egy kevés google keresgélés után mindig a ::queue() metódusba futottam, de az éppen nem oldja meg a problémámat.
2018. augusztus 30., csütörtök
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.
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.
Feliratkozás:
Bejegyzések (Atom)