Weby a PHP

S weby jsem začal experimentovat již na vyšší odborné škole, nějakých 20 let zpátky. Tehdy to byly sice jen takové testování, jak to funguje a díky tomu, že vývoj vysokorychlostního internetu byl ještě v plenách, tak s připojením na internet přes modem byly možnosti z části omezené.

Ze začátku jsem testoval různé technologie, PHP, .NET, JAVA a k tomu přidružené technologie, jako javascript, css, atd. Zjišťoval jsem, co jaká technologie nabízí a v čem budu dále pracovat a rozvíjet své zkušenosti a dovednosti.

Již v té době, řekněme po 2 letech zkoušení, jsem si našel první zakázku – vytvoření objednávkového systému pro nákup CD disků pro jednoho vokalistu, který si svá CD sám nahrával a sám vydával. Zakázka celkem za 3000,- (pro studenta dost peněz pro začátek) obsahovala nákup na internetových stránkách s možností platby bankovní kartou a jednoduchou administrací. Byla napsána v PHP za použití jednoduchého javascriptu a dnes již zastaralého vkládání designových značek přímo do kodu HTML (tedy bez CSS).

Předtím neexistovaly žádné platební systémy, jako GoPay, či PayU. Vše se muselo projednávat s bankou (tuším s Českou spořitelnou) a napojení bylo přes, v tu dobu, nové API 3D Secure.

Tato zakázka se vydařila a zároveň byla pro mě odrazovým můstkem v PHP. Od té doby pracuji nejen v  PHP.

Nette

S Nette jsem přišel do styku nedávno, asi tak před 6-ti lety, kdy se rozhodovalo, na čem se bude stavět nové jádro eshopu pro firmu, ve které jsem pracoval. Zajistil jsem si školení přímo u profesora Nette Davida Grudla, kde jsem teprve poznal kouzlo Nette frameworku a od té doby experimentuji s jeho nasazením všude, kde je to jen možné. Ještě nyní se mi někdy zdá, že je to až moc “magic” a některé metody úplně nechápu, ale je to přirozený vývoj a mám takový pocit, že i pan Profesor Grudl někdy tápe a zjišťuje, jak daná věc vlastně funguje.

Mým prvním výsledkem Nette eshopu je http://www.vyfuky-pema.cz . Zakázka, která byla mimo standardní pracovní proces, se vlivem mnoha změn trošičku protahovala a nakonec jsem práci odevzdal zdarma, neboť mým hlavním cílem bylo naučit se fungovat a zvládat první krůčky a nástrahy, které mě povedou k dokonalému vývoji webů v Nette frameworku. 

S Nette jsem pokračoval také v práci, kterou jsem vykonával pro firmu Religis, kde je na něm postaveno celé nové jádro e-shopů. Byl jsem u zrodu tohoto jádra, pomáhal jsem vymýšlet moduly a vůbec funkčnost celého systému. Celý systém má pak na starosti kolega, ale často jsem se k němu vracel a dodělávál k němu nové moduly.

Můj nový počin v eshopech na Nette je vytvořený soukromý projekt https://www.domaci-nakupy.cz. (projekt uzavřen, ale kody mohu ukázat).

Laravel

Nějaký ten rok si hraju s tímto skvělým frameworkem, v Moraviu jsme na něm vytvořili několik webů a informačních systémů. Jeví se mi daleko lepší, než Nette a to díky široké dokumentaci a také mnoha uživatelů tohoto frameworku – daleko lépe se hledají případné moduly a rozšíření.

Soukromý projekt https://www.nakupy-detem.cz (starší jádro projektu je nyní na https://www.nakupy-detem.sk) je v Laravelu vytvořen. V něm používám i React JS (Košík a nějaké drobnůstky).

Docker

Výborná technologie, která dala základ tomu, že se již nemusí pokaždé nastavovat localhost na spuštění projektu. Stačí si jej pullnout z Gitu, nastartovat Docker a může se testovat, programovat, prostě cokoliv. Samozřejmě je nutné jej nejprve pro daný projekt nastavit, ale již jsem jich dělal tolik, že to dnes již není žádný problém.

Dockerem jsem se začal zabývat tak před 4-mi lety, od té doby mě jej používám pro každý projekt, který vytvářím.

Databáze – Mysql

Kde by byl vývoj PHP, kdyby nebylo pořádného a rychlého databázového enginu, jako je MySQL. Jasně, je to v celku jednoduchá databáze, oproti například Oracle, či PostgreSql, ale pro weby absolutně vyhovující. Tak, jako jsem se zabýval PHP, tak jsem se i zabýval MySQL. Jsem zručný ve vytváření i složitých dotazů s výbornou indexací a tedy i rychlostí. Často důmám nad dotazama a zjišťuji, jakým způsobem by šlo dotaz předělat tak, aby byl ještě o malinko rychlejší. Obecně totiž zjišťuji, že MySQL má největší podíl na rychlosti jak stránek, tak hlavně i serveru jako takového (ono to jde krásně vidět na vytíženém serveru, kdy proces mysql zabírá na 6 procesorů a např. Apache s PHP sotva procesor jeden).

Čím lépe jsou dotazy vytvořeny, tím rychleji fungují stránky (i když jsou používány různé keše, tak databázové dotazy musí běhat rychle) a server obecně dokáže přijímat více požadavků.

Ze začátku jsem pracoval pouze s enginem MyISAM, nyní již vše řeším s INNODB a plně využívám jeho potenciálu na poli cizích klíčů a zamykání řádků namísto celé tabulky. Nyní, když od verze 5.6 je možné v INNODB vytvořit fulltext (který jsem předtím řešil krkolomně přes jinou tabulku v MyISAM), je možné již zcela zavrhnout zastaralý engine MyISAM.

Apache

Webový server Apache je samozřejmou součásti mého webového vývoje. Snad jednou jsem zkoušel i IIS (informační internetovou službu systému Windows), bleskurychle jsem přešel zpět na Apache, který je, dle mého názoru, o mnoho jednodušší a navíc jej využívá většina serverů na světě. 

Zkušenosti s rozběháním a nastavením běhu serveru mám dlouholeté, i když mě vlastně stačí znát jen pár konfiguračních direktiv, které nutně potřebuji pro nastavení funkčnosti Apache a PHP. Další moduly Apache, pokud jsou potřeba pro funkčnost webu, vetšinou řeším nakouknutím do dokumentace a testováním uvedených příkladů.

Důležitou součástí webového serveru je možnost přesměrování webové stránky na jinou, kterou Apache řeší modulem mod_rewrite, který často využívám pro přesměrování například pěkných URL adres a nebo pro vytváření obrázkové keše.

Dalším modulem, který využívám, je mod_headers, kterým dokáži automaticky posílat hlavičky pro nakešování požadavků na straně klienta dle typu souboru.

NGINX

I když pro přímý přístup na web používám Apache, tak Nginx mi slouží jako proxy a to i mezi https a http na lokálním serveru. Nginx mám také spuštěn na lokálním developerském počítači a přes něj se snadněji napojuji na spuštěné dockery. Základní nastavení nginxu umím provést i pro weby, ale zřídka kdy jej použiji.

Javascript

Tak jako jsem spjatý s PHP na straně serveru, tak stejně využívám i možnosti JavaScriptu na straně klienta. Vlastně celou svou administraci pro https://www.nakupy-detem.cz se snažím vytvářet tak, aby byla co nejkomfortnější pro administrátory a tím pádem se bez Javascriptu, a hlavně JQUERY knihovny, neobejdu. Dnes již JQuery není tak markantní, když se dají krásně používat JS funkce od verze 6 a případně i Classy.

Často využívám knihovny třetích stran, jako fancybox (pro vyskakovací okna), nebo Caroufredsel (pro pěkné posuvníky obsahu), tak i základní knihovnu pro JQUERY – UI pro lepší vzhled a funkčnost webu.

A co AJAX (nebo raději AJAJ?). Ano, i toto je mým denním chlebem. Snad vše, co lze, provádím nyní AJAXem a to jak v administraci, tak i na frontové části webů. Vlastně Nette s AJAXem pracuje velmi dobře, proto jej mám rád a často jej využívám.

Dalším mým přáním je vyzkoušet si Web Sockets – ale prozatím jsem nenašel vhodný projekt, na kterém by to mělo smysl dělat.

ReactJS

Je to již nějaký čas, co jsem s tímto skvostem přišel do styku a hned na to naprogramoval (tedy byl jsem součástí týmu) počasí pro jeden portál (pocasi.centrum.cz). Od té doby jsem udělal ještě asi 3 aplikace (například interní aplikace pro kontrolu strojů v hale) a dnes, kdy pracuji na redesignu svého eshopu nakupy-detem.cz, ho používám taktéž.

V rámci reaktu zvládám jak react samotný, tak i se spojením s Reduxem či React Routerem.

Fulltextové enginy – elastic search a Sphinx

S těmito fulltextovými enginy jsem se již setkal dávno a s oběma nadále experimentuji.

Sphinx se mi zdá trošičku horší na konfiguraci, kdy indexy je nutné zadávat do konfiguračního souboru a poté engine restartovat. Kdežto elastic search dovoluje vkládat index pěkně za chodu.

Oba enginy se ukázaly jako velmi rychlé a dobře tak nahrazují MySQL fulltext. Navíc díky použití těchto enginu klesá zátěž na databázi, která je na produkčních serverech velmi vytížená.

Co se týká experimentace ohledně fulltextových filtrů a možností – já jsem si prozatím vždy vystačil se základy. Prozatím jsem se nemusel pouštět do složitějších dotazů na fulltextové enginy tak, aby mi vyhazovaly „zvláštní“ výsledky, vždy mi stačily jednoduché dotazy, které mi ve výsledku vracely Idečka, které jsem obratem poslal do databáze.

Pro fulltext na nový nakupy-detem.cz již používám různé filtry a mapování (ngram a podobné) – testuji lepší vyhledávání.

Linux a server obecně

V Religisu jsem měl na na starost chod všech serverů, i když byly menežované, tak je nutné zajistit a hlídat jejich chod a v případě přetěžování z jakéhokoliv důvodu, najít příčinu a snažit se o co nejrychlejší odstranění příčiny pomalosti serveru. K tomu mi pomáhá znalost základních příkazů Linuxu a často pracuji v SSH přimo na serverech.

Někdy je nutné přenést weby ze serveru na server, což je pro mě již rutinní záležitost (včetně přenostu databáze, DNS záznamů a přenos případných emailů). Dále, zakládání FTP účtů, vytváření databází v MySQL, či jiné přímo serverově věci mi nejsou v žádném případě cizí.

Mimo to mám vlastní server, který je menežovaný a umístěn u firmy VSHOSTING. I když veškeré služby spojene s instalací serveru, či softwaru na něj, provádí zmíněný VSHOSTING a jeho administrátoři, i já často chodím na server přes SSH a pracuji přímo tam. 

S tímto souvisí i správa certifikátu. Spravuji server, který není menežovaný a všechno si tedy musím obstarávat sám, včetně přidávání certifikátu. Proto mám i s tímto zkušenosti. Navíc si spravuji i vlastní certifikáty pro mé soukromé eshopy, takže nákup, vytvoření a použití certifikátů pro zapnutí HTTPS na webu je maličkostí.

Nyní, co mám Ubuntu na svém vývojovém notebooku, tak je nyní používaní linuxu hračkou, i když někdy nastavení opravdu bolí, vždy pomůže Stackoverflow.

Navíc, jelikož používám pro develop Docker, tak základem každého dockeru je správné nastavení běhového prostředí a to právě v linuxu za použití i některých skriptů psaných v SH.

Verzovací systémy – Git (svn)

Bez verzovacího systému se nedá vyvíjet, to je přece jasné. SVN jsem používal dříve v začátcích, avšak jeho nutnost být neustále napojen na Internet, když chci něco commitnout, mě přinutila začít používat GIT. A dobře jsem udělal, rychlý, bezpečný, perfektní. Díky tomu se vývoj v mém působišti mnohonásobně zpřesnil a zrychlil, jelikož nemusíme řešit věci jako “Kdo to smazal z toho kodu?”. Já jsem si na něj navykl tak, že když si zakládám nějakou složku, kde si budu jen psát třeba jen nějaké zápisky z výletu, tak ihned ji dávám do GITu.

Pro své projekty navíc používám službu www.bitbucket.com – takže vše mám ihned všechny kody z jakéhokoliv místa k dispozici.

Jen poznámka pro mne: trošku mě mrzí, že jsem si ještě nepřivykl používat funkci Stash – možná  někdy konečně na to najdu důvod …..

Styly – CSS

Pro své projekty si sám vytvářím HTML šablony (ne grafiku, tu přenechávám grafikovi), proto vím a umím používat CSS. Také se snažím nalézat rozdíly v prohlížečích ( i když např. IE verze statečně ignoruji) a přizpůsobit tak web všem. Rovněž  mám nemalé zkušenosti s vytvářením responzivních webů.

CSS jako takové se mi jeví nějak moc neohrabané, proto raději používám jazyk SASS (http://sass-lang.com/) což je software, napsaný v RUBY, který zavádí lepší organizaci a psaní souborů CSS a zpříjemňuje tak práci se styly.

Ruckus

Tak jako pro zdrojové soubory existuje GIT (nebo SVN), pro databáze existuje Ruckus.

Jde o verzovací nástroj pro databázi, napsaný v PHP, a používá se hlavně pro práci v kolektivu a hlavně pro Deploy projektů. I když jej pro své soukromé projekty nepoužívám (na projektech pracuji pouze já, takže prozatím nemám důvod jej použít), tak ve firemním prostředí je shledávám velmi účinným řešením databázových verzí projektu. Jelikož jsou soubory pro vytvoření, změny databáze uložené v souborech, tak spolu s využitím verzovacího nástroje (GIT či SVN) je pak zaručena určitá bezpečnost a rychlost vývoje projektu v týmu v oblasti změn v databázi.

Testy – testování softwaru

Testování jsem pro sebe zavedl celkem nedávno. Již kdysi jsem testoval za pomocí PHPUnitu, ale až s příchodem Nette testeru jsem se testování naučil mnohem líp. I když zase, své soukromé projekty ještě pod testem nemám (kde vzít na to čas, že?), ale nové projekty, které vytvářím, se již snažím vždy testovat a to za pomocí právě zmíněného Nette testeru.

Ještě mám v hledáčku testování přímo ve vebovém prohlížeči za podpory Selenium testů, také jsem zkoušel, dokonce i některé testy mám vytvořeny pro projekt www.nakupy-detem.cz, ale bojím se, že již jsou testy zastaralé a nefunkční. Mám však v plánu se k nim co možná nejdříve vrátit.

Další znalosti na poli pozice programátora webových projektů:

Souhrně zde uvedu další mé znalosti, které snad nepotřebují širší popis.

– správa DNS – mám vlastní stránky, proto si také sám spravuji k nim DNS

– hardware počítačů – každý správný ajťák si musí umět vytvořit svůj vlastní počítač (samozřejmě ze zakoupených komponent)

– nastavení routerů a síťových služeb – znám problematiku, starám se o síť ve firmě + o domácí routery

– znalostí produktů Atlasianu – Jira, bamboo, wiki, …  – např. přes Bamboo ve firmě deployujeme všechny projekty – výborný software.

– Photoshop – na stříhání grafiky a občasné vytváření bannerů apod.

Analýza

V nadpisu píšu „Programátor a webový analytik“, co to pro mě vlastně ta analýza znamená?

Před tím, než vůbec začnu cokoliv psát, si musím dobře rozmyslet, jakým způsobem kód povedu, jaké jsou případné překážky, zádrhele, jaké k tomu potřebují další nástroje. To všechno musím analyzovat a snažit se najít všechny možné problémy a nedostatky, které daná specifikace/projekt obsahuje.

Z minulosti vím, že se ne úplně na 100% dají předpovídat všechny problémy, které při vývoji mohou nastat, ale z analýzy vyplynou ty hlavní a důležité věci, na které si dát pozor a kterým se bezprostředně při realizaci vyhnout. Z těchto analýz také v závěru vzniká kalkulace a nacenění zadané práce.

Firefox od nějaké novější verze již nepodporuje u inputu autocomplete=”off”. Někdy je však zapotřebí, aby prohlížeč automaticky nedoplňoval data do políčka ze svojí cache paměti. Jednak je to zapotřebí u políček pro zadání hesla, kdy nechceme aby se hesla automaticky doplňovala (a tím pádem každý, kdo má přístup k tomuto počítači, aby se jednoduše nedostal tam, kde nemá co dělat) a také u určitých formulářů, kdy po odesílání a následném redirektu zpět na formulář nechceme, aby byly hodnoty v inputu stejné, jako byly před odesláním na server.

Existuje však jednoduchá pomoc, vytvořil jsem tento skript, který právě autocomplete=”off” plně nahrazuje ( a funguje ve všech prohlížečích stejně – za předpokladu, že existuje knihovna JQUERY):

$( document).ready(function () {

$(‘input[type=”password”][autocomplete=”off”]’). each(function () {

var $this = this ;

$ (‘<input>’ ).attr({
type : ‘password’
}) .keyup (function () {
$($this). val($(this).val());
}) .insertAfter( this);

$ (this ).hide() ;
});

});

Tento skript funguje na políčko pro heslo, ale asi již pro vyvojáře nebude problém ho předělat na jakýkoliv input, kde je potřeba vypnout autocomplete.

Moje první nasazování SSL jsem rozepsal v mém předchozím článku, nyní, již trošku poučený s chyb, jsem nasazoval SSL certifikát na náš e-shop www.nakupy-detem.cz. Vlastně jsem tento web musel přenést z jednoho serveru na druhý, když už jsem byl u takových změn, tak jsem se rozhodl o větší změnu a zabezpečit tak stránky před “šmejdama” na internetu.

Zásadní otázka: Proč implementovat SSL?

Internet je spojení počítačů ať již kabelem, nebo dnes “bezkabelově” a nikdy nevíte, který “parchant” se dokáže hecknout do Vašeho routeru, nebo na síť spojující Vás a ISP, nebo nedejbože přímo do počítače ISP (Internet Service Provider) přes kterého jste do sítě internet napojeni. Tímto dokáže útočník celkem v pohodě odposlouchávat síť a tím tak získávat data ohledně všech přenosů, které uživatelé na internetu uskuteční. Tak například, chcete snad vědět, jakou pizzu si soused objednává? Není problém, připojte se na jeho router a jelikož jeho oblíbená pizzerie zřejmě nebude mít zabezpečené připojení přes SSL, tak v klidu zjistíte, jakou pizzu si objednal. Ba co víc, díky tomuto spojení není problém mu objednávku změnit a objednat mu na jeho jméno, pod jeho účtem, nějakou pizzu, avšak s dovozem na Vaši adresu.

Jak tomu zamezit? Stačí, aby sousedovic oblíbená pizzerie instalovala na svůj web SSL certifikát a tím by zajistila přenos všech informací šifrovaně. Ano, vy by jste to sice odposlechli, ale místo “heslo: aaa” by se vám objevilo něco jako “lkjls515dafk lkds” – prostě kódováná zpráva, která nejde ničím rozkodovat.

Toto je pouze názorný příklad, banalita s objednáváním pizzy, ale co kdybychom toto udělali s jeho oblíbenou bankou? Tady už je situace jiná. (i když banky již mají šifrované připojení, ale né všechny jsou úplně bezpečné viz. výzkum odborníka na webovou bezpečnost Michala Špačka – Banks & HTTPS in the Czech Republic 2015-03-18)

Na eshopu nakupy-detem.cz zadávají zákazníci (pro někoho) citlivé informace, jako adresu a své jméno, později přibude na webu možnost se zaregistrovat a využívat více možností nákupu výrobků. Tam se samozřejmě budou přihlašovat svým jménem a heslem a pokud by tyto důležité informace nebyly dostatečně zabezpečeny, mohlo by rychle dojit k jejich zcizení a nemalým problémům jak ze strany zákazníka, tak samozřejmě ze straný nás, jako provozovatele obchodu. Zabezpečení stránek certifikátem je tedy jasná a správná volba.

Získání SSL certifikátu a jeho nasazení

Je důležité si nejprve rozmyslet, které domény (subdomény) chci zabezpečit. Pro zabezpečení našeho webu potřebuji ochránit celkem 3 subdomény (nakupy-detem.cz, www.nakupy-detem.cz, a administrační část webu).
K tomu jsem si opatřil certifikát, který je právě pro tři domény. Wildcard by byl taky vhodný, ale zbytečně dražší (navíc implementace je těžší a někdy to nefunguje, jak má, viz. můj minulý článek)
Po získání certifikátu pak stačilo jej poslat kolegům ze server hostingu, aby jej nasadili.

Přechod webu na SSL

U webu jako takového je nutné změnit všechny absolutní vnitřní odkazy, aby směřovaly na HTTPS. Pokud je web, či eshop, postaven na nějakém frameworku, tak většinou stačí jen změnit někde v konfiguraci hlavní url webu (baseUrl), některé frameworky si to i samy detekují a automaticky všechny odkazy k tomu přizpůsobí. Důležité je věnovat pozornost informačním stránkám (vlastně všem místům na stránce, kde se obsah negeneruje, ale je dodáván manuálně, např. wysiwyg editorem v administraci), tam je nutné tyto odkazy buď manuálně změnit, nebo všechny tyto texty prohnat nějakým skriptíkem/filtrem.

Poté je důležité nastavit web tak, aby veškerou komunikaci automaticky směroval na HTTPS. V htaccess souboru se to dělá těmito dvěmi řádky:

RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}  [R=301,L]

Problémy s obrázky:

Standardně s obrázky při přechodu webu na SSL nejsou problémy, ovšem na webu nakupy-detem.cz jsem pro optimalizaci kdysi udělal to, že se obrázky stahovaly z různých subdomén (např. img1.nakupy-detem.cz, img12.nakupy-detem.cz0). Tím se standardně obchází maximální počet souběžných připojení prohlížeče na jednu doménu (různé prohlížeče mají různě nastavené omezení, např. Firefox má max 6 souběžných připojení, Internet Explorer verze 10 jich má 8). Problém však nastal, kdy díky certifikátu, který je vystaven pouze na 3 subdomény, toto jaksi přestalo fungovat a prohlížeč odmítal zobrazit obrázky, které přišly z neznámého zdroje. Na subdoméně img2.nakupy-detem.cz vystavený certifikát není, a když se prohlížeč snaží tuto sobdoménu kontaktovat, tak dostane sice certifikát, ale který není ověřený u centrální autority (tzv. self signed) a tím pádem se standardně odmítne ke zdroji připojit. Nyní jsem celkem litoval, že jsem si nezakoupil Wildcard certifikát. Jediný způsob, jak se toho zbavit, bylo odstranění této “subdoménovsko obrázkové” funkčnosti.

Co na to vyhledávače?

Implementováním SSL na web se změnila adresa webu a to na https://www.nakupy-detem.cz. Tohle vyhledávače jako google, či seznam, berou jako úplně novou adresu, avšak díky přesměrování pomocí hlavičky 301 vezmou vyhledávače adresy rychle zpět do svých indexů. Teoreticky by se přechod na tyto nové adresy neměl dotknout pozic ve vyhledávačích, ba co více, google prý hodnotí zabezpečené weby lépe.
Po 12 dnech, co web jede na SSL, jsem v google analytics zaznamenal mírné zvýšení návštěvnosti. Samozřejmě je ještě brzo na nějaké závěry, navíc to může být i jinými okolnostmi. Důležité však je, že žádné snížení návštěvnosti se nekoná.
Jediný problém je pouze v google web masters tools, který okamžitě zaznamenal pokles indexovaných stránek. Je to celkem logické, google bere web s HTTPS jako novou doménu a tudíž už starou neindexuje. Je tedy nutno v toolsech založit nový web s doménou HTTPS. Tam lze již vidět, že to, co verze HTTP ztratila v indexu, to HTTPS nabrala.

Hodně se dnes mluví o bezpečnosti a o zabezpečení zadávaných informací na web, ať již před útočníky v podobě různých hackrů, znuzených studentíků ajťáků, tak i před výzvědnými službami, jako např. ochrana před CIA či NSA. Nedávno, při auditu zabezpečení ve firmě bylo rozhodnuto, že se musí zabezpečit pomocí SSL přístupy na důležité weby v rámci firmy a k tomu i subdomény, na kterých provozujeme demo internetového obchodu. Toto demo se vždy vytváří jako subdoména k demo.firma.cz, tedy například zidle.demo.firma.cz.

Úkol tedy zněl jasně. Zabezpečit firma.cz, ale zároveň i demo.firma.cz ale i např. prodejzidli.demo.firma.cz Jelikož počet subdomén je v tomto případě nekonečný, bylo nutno vytvořit tzv. wildcard certifikát. Pro pořádek jen připomenu druhy certifkátů, které pro zabezpečení webů existují:

Použití :hover pseudo classy je na dotykovém zařízení celkem pasé, jelikož nedokáži emulovat to, že přes element jen přejíždíme, ale nechceme na něj kliknout.

No jo, ale většina stránek s tímto CSS prvkem počítá a někdy se bez tohoto elementu nedá web ovládat, hlavně u takových,  které mají určité prvky schovány pod najetím kurzoru na určité místo na stránce (např. hover menu).

Apple si to na svých zařízeních vytvořil tak, že hover se snaží emulovat  a to tím, že pro aktivace se provádí kliknutím na element, tím se aktivuje hover efekt a po druhém kliknutí se hover efekt vytratí.

Problém nastává, pokud je hover efekt použit na A HREF elementy. Jelikož zde kliknutím aktivujeme pouze hover efekt, ale stránka zůstává pořád na stejné adrese a nepřesune nás na místo, na které odkazuje HREF. To se provede tzv. dvojklikem, tedy rychlejším dvojkliknutím na daný element.

U jistého projektu mi toto dělalo problém ve vyjíždějícím menu (hover menu). Stávalo se, že na vyjeté menu se na jednotlivé elementy nedá kliknout, a to ani dvojklikem. Nevím přesně, čím to je, snad nějaký hover v CSS, který toto zabraňuje. Nicméně jsem to vyřešil jednoduchým javascriptem:

$('.submenuContent-in a').live('touchend', function (e) {
  e.preventDefault();
  location.href = $(this).attr('href');
});

Nyní mi tlačítka funguji tak, jak mají a na desktop to nemá vliv, jelikož eventa TOUCHEND funguje pouze na dotykových zařízeních.

Více se o tomto problému dočtete třeba zde

Někdy je třeba serializovat prvky formulářů, které nejsou uvnitř tágu form. Například při vyskakovacím okně, kde všechno probíhá ajaxově a není třeba poutívat form, pouze jeho elementy input, select, atd.

Pokud použijeme příjaz $(element).serialize() na jiném elementu, než na form, dostaneme prázdný string, jak toto obejít?

Na webu jsem chvíli brouzdal a našel jsem toto:
function makeSerializable(elem) {
return $(elem).prop(‘elements’, $(‘*’, elem).addBack().get());
}

var element = $(this).closest(‘tr’);
serialized = makeSerializable(element).serialize();

Funguje bezvadně. Díky ti google vyhledávači….

Každý, kdo pracuje s dlouhotrvájícími skripty ví, že pro lepší kontrolu, co se vlastně v pozadí děje, potřebuje kontinuální výstup. Já si kupříkladu co například 100 cyklů pošlu na výstup počet již zpracovaných položek. Tím si také kontroluji, že se skript nikde neseknul a krásně funguje.

Jelikož PHP používá pro svůj výstup buffer, je nutno pro kontinuální výstup použít funkci:

ob_implicit_flush(true);

Tím je zajištěno, že veškerý výstup skriptu je ihned předán na STDOUT.

U prohlížeče google chrome toto funguje bezvadně, ale pro svůj vývoj mám radši Firefox (má podle mě lepší debugovací nástroj – firebug) – jenže v tomto prohlížeči to nefunguje podle očekávání. Trošku jsem musel googlit a nakonec jsem nalezl způsob, jak přesvědčit firefox, aby ihned zobrazoval to, co mu pošlu. Stačí v kodu specifikovat kodování stránky:

header('Content-Type: text/html; charset=utf-8');

QTip je celkem dobrý plugin, který nahrazuje zobrazení TITLE u prohlížečů.  Použití je jednoduché:

$(‘.qtip’).qtip();  — tim nastavim p2kn0 TITLE zobrazení po najetí myší na všechny elementy, které mají CLASS=qtip

Nicméně jsem si dlouho nevěděl rady, jak udělat, aby se qtip aplikoval i na AJAXem nahraný obsah. Protože, když po nahrání obsahu znovu zavolám předešlý příkaz, tak qtip se aplikuje také na již qtipnuté prvky a následně zobrazuje u těchto prvků jakoby dva qtipy přilepené přes sebe.

V api u qtipu existuje příkaz “destroy”, který qtip z prvků zruší a logicky poté lze znovu volat příkaz na jejich znovu nabindování. Jenže qtip má takovou vlastnost, že při jeho spuštění si vytáhne z atributu tagu TITLE to, co má pak zobrazit ve svém okně a pak title smaže. Tedy, když znovu nabinduji qtip tak vlastně již nemají co zobrazit, protože je TITLE prázdné.

Řešení je celkem jednoduché:

$(document).ready(function () {
qtipAll();
});

function qtipAll()
{
$(‘.qtip’).each(function () {
var title = $(this).attr(‘title’);
if ($(this).hasClass(‘qtipAlready’)) return true;

$(this).qtip({text:title, style:”cream”, position: {
corner: {
target: ‘bottomRight’

}
}});
$(this).addClass(‘qtipAlready’);
});

}

Jaký je rozdíl mezi těmito obrázky?

Odpověď je:  jiný server

(samozřejmě taky jiný prohlížeč, ale ten tady nehraje roli)

A teď trošku vysvětlení. Na nový server jsem nakopíroval web z jiného serveru, tedy kopie 1:1. Stejné skripty, stejná databáze – všechno zdá se být stejné. Když jsem pak začal testovat chod webu na novém serveru, tak se mi nechtěly zobrazovat obrázky. Udělal jsem si proto tyto výstupy. Skript vypadá nějak takto:

Když ho volám z původního serveru, tak mi správně vypíše pole dle preg_match, když ho však volám z nového serveru, tak mě STRING neprojde eregem a tudíž nic nevypíše.

Celkem zajímavé.  Servery se akorát liší ve verzi PHP:

Server 1: PHP 5.2….

Server 2: PHP 5.4….

Nevíte někdo, co to může způsobovat? Už se tady s tím 2 hodiny trápím.