http://blog.revolucnihosting.cz/favicon.ico http://blog.revolucnihosting.cz/ cs http://blog.revolucnihosting.cz/tip-na-plugin-php-speedy-vam-zrychli-wordpress/c-25.html Už jste někdy řešili problémy s výkoností WordPressu? Plugin PHP Speedy by Vám mohl výrazně pomoci. Úkolem tohoto pluginu je minimalizovat požadavky na server a přenos dat směrem k uživateli. Nejdná se přitom o žádnou magii, ale o běžně používané metody, které ale průměrný uživatel WordPressu zřejmě nezná. Co tedy tento Plugin skutečně udělá s Vaší instalací: spojí jednotlivé CSS a JS soubory do jednoho. Tím se minimalizuje počet požadavků na hosting a nedochází tak k blokování při stahování většího počtu těchto souborů U CSS a JS souborů vytvoří gzipovanou alternativu (objem dat se může zmenšit až na třetinu) a pokud Prohlížeč návštěvníka stránek podporuje tuto kompresi, tak mu jí nabídne k stažení Možnost otestování davají přímo autoři na těchto stránkách: Stránka bez použití PHP Speed Stránka zrychlená pomocí PHP Speed Stažení: Odkaz ke stažení naleznete na stránkách pluginu: http://aciddrop.com/php-speedy/Přímí odkaz: PHP Speedy 0.5.2 download Instalace: stáhněte si plugin a rozbalte jej do libovolné složky rozbalený archiv nahrajte do Vaši instalce Wordpressu do adresáře /we-content/plugins/ přihlašte se do administrace Wordpressu a sekci Pluginy aktivujte PHP Speedy WP přejděte do Nastavení > PHP Speedy WP kde si plugin nakonfigurujete Konfigurace PHP Speedy WP JS Libraries Zde zaškrtněte knihovnu, které používají Vaše témata vzhledu, nebo jiné pluginy. Pokud ale využíváte novější verzi knihoven(než kterou uvádí Speedy), nebo si nejste zcela jisti, raději nezaškrtávejte a PHP Speedy WP knihovny bude ignorovat Ignor list Speedy dokáže také ignorovat Vámi vyjmenované soubory. Jednotlivé názvy souborů, které chcete vynechat ze zpracování oddělte čárkou a Speedy je vynechá ze zpracování. Minify Options Zmenšení obsahu html(minify page), css(minify css) nebo javascriptu(minify javascript) tím že odstraní bílé znaky a komentáře ze zdrojových souborů. Gzip Options Zapne kompresi zdrojových z kódů html, css nebo javascriptu. Ve výchozím stavu je Gzip vypnutý a autor doporuče jeho zapnutí pouze u menších stránek. Pro více škálovatelné stránky, je totiž výhodnější Gzip zapnout na straně serveru. Far Future Expires Options Zapne posílání informací o vypnutí platnosti javascriptových a css souborů. Ty se uloží na straně prohlížeče návštěvníka a soubor se tak nemusí stahovat pořád dokola. Pokud změníte tyto soubory, tak Speedy automaticky vygeneruje novou verzi souborů a prohlížeči pošle aktuální soubory. Data URIs Umožní uložit některé obrázky jako Data URIs a tak celkově snížit HTTP požadavky na server což sice načítání zrychlí, ale datová velikost se zvětší a starší IE budou mít problém se zobrazením. Pro jistotu bych doporučil nechat vypnuté. Další dvě možnosti File cleanup a Footer text už jsou tak trochu na okrasu. Cleanup průběžně promazává starší vygenerované soubory(doporučuji radši jednou za čas mazat ručně) a footer text přidá odkaz na stránku pluginu. Zdroje: O Wordpressu (@wordpresstipy) on Twitter http://aciddrop.com/php-speedy/ http://blog.revolucnihosting.cz/kdy-muze-byt-strtotime-nezbytnosti/c-24.html Na spoustě míst na internetu se dočtete, že se má používat funkce strtotime(); a datum nedopočítávat, důvod je jednoduchý. Je to přehlednější co se týče čitelnosti kódu a v některých případech Vám jeho používání odloží vrásky o pár let. Tímto menším článkem bych chtěl vysvětlit jeden praktický příklad, kdy je vhodné ba dokonce žádoucí jej využít. Řekněme že uživateli budeme chtít ukázat jaké datum bude přesně za 30 dní. Existuje více možností zápisů, ale aby bylo vidět to co chci vysvětlit vybral jsem tyto dva: {echo date("Y-m-d",strtotime('+ 30 day'))."\n";//vypíše 2011-11-01echo date("Y-m-d",strtotime("2011-10-02")+(30*86400))."\n";//2011-10-31} Na první pohled by se mohlo zdát, že obě možnosti dělají jedno a to samé. V první možnosti přičítáme k dnešnímu datu třicet dní pomocí funkce strtotime(); a v případě druhém přičítáme 30 krát počet vteřin ve dni k aktuálnímu datu. Proč ale máme ve výsledku druhého případu o jeden den méně? Jelikož strtotime(); pracuje s NOW to znamená že počítá s roky, měsíci, dny, hodiny, minutami a sekundami, tak si pro jistotu necháme vypsat celý výstup date(); {echo date("Y-m-d H:i:s",strtotime('+ 30 day'))."\n";//vypíše 2011-11-01 16:33:16echo date("Y-m-d H:i:s",strtotime("2011-10-02")+(30*86400))."\n";//2011-10-31 23:00:00} Na první pohled asi každého trkne čas u druhého příkladu 23:00:00. To je hodnota, která by se už neměla vrátit vůbec. Většina lidí si řekne: "co bych chtěl, je to PHP". Ale když půjdete postupně tak, jak se řádek vykonává, zjistíme že je výsledek vlastně správně. Základem je prvotní zadání datumu strtotime("2011-10-02"); což pro funkci strtotime(); není kompletní informace a tak si musí doplnit i čas v požadovaném dni. Ve skutečnosti je tedy zadáno strtotime("2011-10-02 00:00:00"). Toto lze ověřit následujícím zápisem: {echo strtotime('2011-10-02')."\n"; // vrátí 1320098400echo mktime(0, 0, 0, 10, 2, 2011)."\n"; // vrátí 1320098400} Poté, co má PHP přepočítanou první část výpočtu přičte k němu námi nadefinovaný počet vteřin. Vypadá to asi takto: 1320098400 + (30 * 86400) = 1320098400 + 2592000 = 1322690400. Výsledek si můžeme pomocí date(); převést na lidmi lépe čitelný tvar: echo date( "Y-m-d H:i:s", 1320098400)."\n"; //vrátí 2011-10-31 23:00:00 Vida, dobrali jsme se stejně špatného výsledku jako PHP. V čem je ale problém? Není v tom žádné kouzlo. Dnešní datum je zadán v timezone Europe/Prague což je UTC + 2hod = SELČ. Říkáte si proč +2 hodiny když jsme vůči UTC posunuty pouze o jednu hodinu? Jde o to že o jednu hodinu jsme posunuty pouze tehdy když máme zimní čas, ale datum zadání je v letním času. A jelikož se vypisuje výsledek s datumem v zimním času (na zimním čas letos budeme přecházet 30.10.2011), tak nám PHP naservíruje výsledek již v zimním čase tedy UTC + 1hod = SEČ. Jinými slovy datum a čas 2011-10-31 23:00:00 zapsán zimním časem je to samé jako 2011-11-01 00:00:00 v letním čase. Tím že se odečte jedna hodina, zákonitě se musí změnit i datum o jednotku a tím že jsme si hned na začátku odřízli celý výstup se zdálo, že jsme přišli o celý den. Ještě lépe je to vidět na následujících příkladech: {echo date( "Y-m-d H:i:s", strtotime("2011-10-02")+(28*86400))."\n";//vrátí 2011-10-30 00:00:00echo date( "Y-m-d H:i:s", strtotime("2011-10-02")+(29*86400))."\n";//vrátí 2011-10-30 23:00:00} Pokud bychom chtěli aby nám i tento zápis vracel datumy správně, tak budeme muset říct skriptu, aby pracoval s časovým pásmem, které letní čas nepodporuje. tedy např.: {date_default_timezone_set("UTC"); echo date( "Y-m-d H:i:s", strtotime("2011-10-02")+(28*86400))."\n";//vrátí 2011-10-30 00:00:00echo date( "Y-m-d H:i:s", strtotime("2011-10-02")+(29*86400))."\n";//vrátí 2011-10-31 00:00:00} Samozřejmě by se v praxi našli případy, kdy by jsme ocenili tuto druhou možnost. Vždy záleží na konkrétní situaci. Není důvod dogmaticky využívat strtotime();. http://blog.revolucnihosting.cz/update-php-na-verzi-5-3-8/c-23.html Dnes v noci byl proveden update PHP na verzi 5.3.8. Byly opraveny dvě chyby: #55439 - crypt() returns only the salt for MD5 #55283 - SSL options set by mysqli_ssl_set ignored for MySQLi persistent connections Zdroj: http://www.php.net/releases/5_3_8.php http://blog.revolucnihosting.cz/planovy-update-mysql/c-21.html Vnoci (z 14.06.2011 na 15.06.2011) bude provedený plánovaný update MySQL (verze 5.5) na serverech služby RevolučníHosting.cz. Update bude proveden mezi 24:00 - 02:00, tak aby byly minimalizovány případné problém. Přesto dojde ke krátkodobému výpadku služby. Děkujeme za pochopení http://blog.revolucnihosting.cz/spusteni-nove-sluzby-click4webstore/c-20.html Dnes jsme po delších přípravách spustili novou službu s názvem click4websotre. Cílem této služby je dostat eshopy našich zákazníků na facebook tak aby se zvýšila jejich konkurenceschopnost. Služba je dostupná ve dvou variantách. 1. Eshop je provázán se současnými e-shopy. Našim současným zákazníkům na systémech webareal.cz, webareal.sk,... přibude v administraci tlačítko na nainstalování aplikace do facebooku (podmínkou je mít zaregistrovaný účet na facebooku a mít aktivní tzv. pages - firemní stránky). 2. Eshop si budou moci zřídit i e-shopy, které nejsou provozovány pod naším systémem. V takovém případě bude nutné e-shop buď naplnit ručně, pomocí předem nadefinovaného CSV, nebo XML feedu (vzor bude shodný s heureka.[cz|sk]) Pro začátek bude nová služba spuštěna pouze pro české a slovenské mutace našeho systému, ale spuštění na ostatních mutací na sebe nenechá dlouho čekat. Domovské stránky projektu: http://www.click4webstore.com/ http://blog.revolucnihosting.cz/moje-stranky-byly-napadeny/c-17.html Co dělat když Vaše stránky blokuje antivir, prohlížeč, nebo jste po spuštění  Vašich stránek v prohlížeči přesměrování na porno stránky. Existuje několik jednoduchých postupů, které Vám mohou  pomoci se problému zbavit. 1. Zkontrolujte doménu. Někteří lidé tento krok podceňují, ale místo kam doména ukazuje se dá podvrhnout a pokud nemáte jistotu že doména směřuje tam kam má, tak hledání chyb a jejich opravování bude marným bojem. Více se dočtete např. na stránce: http://www.bezpecnedomeny.cz/. 2. Prohledejte svůj osobní počítač. Respektive prohlédněte všechny počítače na kterých se připojujete k FTP Vašeho webu. Je důležité skenovat jak antivirem, tak nějakým prográmkem na odstranění malweru. 3. Změňte hesla. Především je nutné změnit heslo k FTP a databázi, jestli jí využíváte. V ojedinělých případech bývají na FTP uložená i hesla k doprovodným aplikacím (jako je například tiketovací program) uložená v textové podobě. Pokud je to i Váš případ, změňte i tato hesla. Plus pokud používáte stejné heslo k více službám, změňte heslo na dotyčných službách. 4. Zabezpečte své připojení ke stránkám. Nezapomeňte že většina hesel se v základu posílá sítí tak jak jej napíšete při přihlašování. Pokud se jedná o autentizaci webovou, tak vyhledávejte přihlašování pomocí https a i v případě FTP existují možnosti jak přenos hesla zbezpečit. Přístup k FTP lze také vyhradit jen určeným IP adresám (na našem hostingu lze snadno natavit, tak není důvod tuto možnost nevyužívat). 5. Nahrajte poslední platnou zálohu dat i skriptů. Většinou je po napadení stránek, nějak upraven kód, tak aby se škodlivý software mohl šířit i mezi Vaše návštěvníky. Pokud nejste schopni v krátké době opravit data nebo kód sami, je kolikrát jednodušší a rychlejší nahrát zálohu databáze nebo skriptů. Nezapomeňte také překontrolovat .htaccess pokud jej využíváte. V případě napadení stránek se jedná o nejsnazší cestu jak stránky přesměrovat. 6. Najděte příčinu prolomení stránek. Sofistikované útoky se většinou vedou na větší aplikace. Pokud máte své stránky na sdíleném webhostingu, tak je velmi pravděpodobné že už podobný problém je na internetu několikrát popsán. V případě open source se to rovná téměř jistotě. 7. Aktualizujte software. To se týká především instalací open sourcových projektů. Kódy aplikace jsou veřejně dostupné a tak se na ně snáze vytváří exploit. Navíc má záškodník jistotu že bude moci stejnou technikou proniknout do více webů a to je vždy lákavé. Komunity, těchto projektů pracují celkem spolehlivě a tak je dost jisté, že se v nejbližší době objeví aktualizace, která pomůže právě Vám. V případě že se jedná o chybu nějakého doplňku tak oprava trvá z pravidla déle a je lepší zvolit jeho deaktivaci. 8. Změňte hesla. Ano,  změňte je znova. V tomhle buďte opravdu paranoidní. Pokud totiž pracujete pomalu tak je dost možné že si záškodník našel znovu změněná hesla. Takže pokud uplynula delší doba od zjištění problému do opravy problému, tak změňte heslo. Jistota je jistota. 9. Vytvořte zálohu skriptů i databáze. Nikdy nevíte, kdy jí budete znovu potřebovat. 10. Pokud jsou Vaše stránky na černé listině, požádejte o jejich vyškrtnutí. Na internetu existuje mnoho blacklistů. A pokud se na některý dostanete (především http://stopbadware.org/) tak Vaše stránky bude blokovat např. prohlížeč Google Chrome, FireFox nebo se ve výsledcích vyhledávání na Googlu zobrazí štítek, že je web nebezpečný (to zjistíte například vyhledáním následujícího výrazu: site:www.vasedomena.cz). Přitom k samotné blokaci stránek stačí pouze odkazovat na web, který malware obsahuje (v takovém případě většinou stačí odkaz odstranit a prohlížeče už web zobrazí). Svůj web z této listiny dostanete následujícím způsobe: ověřte si svůj web pomocí služby google webmaster tools na domovské stránce Nástrojů pro webmástry klikněte na požadovaný web pokračujte kliknutím na Diagnostika > Malware poté zvolte položku Požádat o kontrolu Pokud už budou Vaše stránky čisté, tak Vás google odstraní z blacklistu a odstraní štítek z výsledků vyhledávání. Uvádí se sice, že to může trvat až 1 den, ale co vím tak to nikdy netrvá tak dlouho. 11. Kontaktujte poskytovatele hostingu. To sice můžete udělat kdykoliv, třeba hned jak zjistíte že Vaše stránky byly napadeny, ale první rady  budou zcela jistě shodné s předchozími body ;-). Pokud si ale s kterýmkoliv z předchozích bodů nebudete vědět rady, tak nás kontktujte okamžitě. http://blog.revolucnihosting.cz/wordpress-vymena-bezpecnostniho-klice/c-16.html Pro zvýšení bezpečnosti Vaší instalace WordPressu je vhodné občas změnit bezpečnostní klíč. Tato situace nastane především pokud máte podezření na pokus o prolomení Vašich stránek, nebo bezprostředně po nainstalování WordPressu. Bezpečnostní klíč se ukládá do souboru wp-config.php a jeho vytvoření není nikterak složité (teda pokud jeho vygenerování nebudete chtít sepsat sami, to už by chvilku přemýšlení zabralo). Ve verzi 2.6 byly ve WordPressu k dispozici tři bezpečnostní klíče AUTH_KEY, SECURE_AUTH_KEY a LOGGED_IN_KEY. Ty pomáhají k lepšímu hashonání uživatelských dat ukládaných do cookies. Od verze 2.7 byl do této skupin přidán ještě čtvrtý klíč NONCE_KEY a aby se hashování ještě zesílilo přibyla ke každému klíči ještě definice tzv. saltu. Ukázka toho, jak takové klíče a salty mohou např. vypadat: {file:viewWPSecurityKey.php} Salt si můžete představit jako většinou náhodný řetězec, který má ztížit prolamování výsledného hashe. Výsledný hash je poté nemožné prolomit (no v podstatě není nic nemožné). Při vytváření těchto klíčů je důležité aby byly dostatečně dlouhé, náhodné a komplikované. Při jejich tvorbě je nejlepší použít online generátor (při každém obnovení stránky online generátoru se vygeneruje jiný klíč). Změnou těchto klíčů ztížíte možnost napadnutí Vašich stránek a přidáte tak i náhodné prvky pro práci s hesly. http://blog.revolucnihosting.cz/wordpress-otazky-ohledne-bezpecnosti/c-15.html Právě jsem si dočetl FAQ ohledně bezpečnosti worpressu a jelikož jsem v češtině nic podobného nenašel, tak sem umístím jednoduchý překlad. 1. Kam mám hlásit problém s bezpečností? Pošlete co nejvíce detailů (v angličtině) na adresu: security@wordpress.org 2. Byl jsem napaden. Co mám dělat? Nainstalujte si do Wordpressu plugin Exploit Scanner, který by Vám měl pomoci při hledání a čištění poškozených částí WordPressu. Dále je vhodné zajistit: změnu hesel pro všechny uživatele. Především pak administrátorského a editorské pokud jste v poslední době uploadovali soubory přes FTP, tak změňte heslo k FTP přeinstalujte si WordPress na poslední stabilní verzi ujistěte se že Vaše všechny pluginy a témata vzhledu jsou aktuální (popřípadě je aktualizujte) změňte svůj bezpečnostní klíč přečtěte si často kladené otázky a odpovědi na téma moje stránky byly napadeny. 3. Proč někteří uživatelé mohou vkládat nefiltrované HTML? Administrátorské a editorské účty mají povolené vkládat do title a obsahu stránky nefiltrované HTML.  Koneckonců je WordPress publikační nástroj a v určitých situacích je vhodné autorům tuto možnost poskytnout. Na druhou stranu to sebou může nést určité bezpečnostní riziko (např. získání cizích cookies pomocí XSS).  Pokud tedy Vaší instalaci využívá uživatel, kterému příliš nevěříte, je vhodné dát mu nižší oprávnění, u kterých je fitrování povinné. Problém může také nastat v případě že svou instalaci necháte podrobit bezpečnostnímu testu (ten je doporučeno spouštět na uživatelských účtech s nižším oprávněním). Pro zapnutí filtrování pro všechny uživatele můžete do souboru wp-config.php vložit následující kód: define( 'DISALLOW_UNFILTERED_HTML', true ); 4. Proč jsou zobrazeny některé přímé cesty při nahrávání souborů? Problém je v konfiguraci stránek. Na produkční server by se nikdy nemělo dostat nastavení display_errors nastavené na on. Na našich serverech je defaultně vypnuto. Pokud s tímto nastavením laborujete, nezapomeňte jej odstranit dřív, než nahrajete stránky na produkční server. 5. Proč jsem dostal e-mail "Reset password"? Pokud dostanete e-mail obsahující "Someone has asked to reset the password for the following site and username" (stručně přeloženo: Někdo požádal o změnu hesla pro následující uživatelské jméno), tak to znamená, že někdo navštívil reset hesla na Vašem blogu. Tuto akci může provést každý, jelikož musí být dostupná především těm, kteří heslo opravdu zapomněli. Vaše heslo může změnit pouze ten, kdo si přečte došlý e-mail. Pokud jste si jisti tím, že nebyl Váš e-mail napaden, můžete tento e-mail ignorovat. Jedná se o volný překlad, originál naleznete na stránce: http://codex.wordpress.org/FAQ_Security http://blog.revolucnihosting.cz/instalujeme-dokuwiki-na-revolucnihosting-cz/c-14.html Čas od času Váš webový projekt dosáhne určitého stupně složitosti a tak je dobré potskytnout potencionálním zákazníkům určitou dokumentaci, manuál, atd. a přitom je nezbytné zachovat jednoduchost struktury a usnadnit tak orientaci potenciálním zákazníkům. Jako u většiny webových projektů už na internetu existuje celá řada zdarma dostupných řešení, takže nutně nemusíme platit vývoj šitý Vám na míru. K tomuto účelu jsou na internetu používány především wiki systémy a já jsem si zvolil jako jednoho z mnoha jejich zástupců právě DokuWiki. Stažení aktuální verze můžete provést na následující stránce: http://www.splitbrain.org/projects/dokuwiki. Pro neznalé angličtiny jen upozorním, že je dostupný i v české lokalizaci, která je již v instalačním balíčku obsažena a nemusíte jí tak stahovat odděleně. Následující postup jsem testoval na verzi s označením 2010-11-07a, ale není vyloučeno že se postup s některou novou verzí nemůže změnit(nicméně při jednoduchosti instalace o tom dost pochybuji;) ). Začátek instalace je jako vždy stejný. Rozbalte si stáhnutý archiv na Váš lokální disk a zkopírujte jej přes FTP na hosting (archiv má ~9.2MB a obsahuje více jak 3000 souborů a složek, takže při nahrávání přes FTP je nutné se obrnit trpělivostí). Tím jsou přípravy na instalaci dokončeny, DokuWiki totiž neukládá data do databáze, ale do souborů. V instalaci budeme pokračovat tak, že si adresu na kterou jsme skripty nahrály přes FTP zobrazíme přes webový prohlížeč. DokuWiki narozdíl od ostatních podobně distribuovaných aplikací neumí zjistit, že se jedná o první spuštění a tak nenabídne možnost instalace. Proto je nutné spustit skript s názvem install.php (v prohlížeči je tedy nutné zadat adresu http://www.vase-domena.cz/install.php. Můžeme se obejít i bez instalace, ale DokuWiki by zůstala v základním nastavení a editovat obsah by tak mohl úpně každý). V základu je DokuWiki v angličtině, ale v pravém, horním rohu by jste měly mít roletku na změnu jazyka, kde pro počeštění instalace vyberte cs a instalace se Vám automaticky prohodí do českého jazyka (pokud se tak nestane, klikněte na tlačítko Update). Následně vyplníte krátký formulář kterým nastavíte administrátorský účet: Název wiki - Bude použito jak v title, tak bude zobrazeno v horní části stránky. Zapnuto ACL - Ponechte zaškrtnuté, povolí Vám administrovat wiki Správce - Uživatelské jméno admina aplikace Celé jméno E-mail - Použije se v případě resetu hesla, nebo notifikaci novinek Heslo (je nutné zopakovat aby se minimalizovala chyba překlepu) S výběrem licence lze těžko poradit, hodně záleží na charakteru výsledné nápovědy, ale u každé možnosti máte otazníček a po kliknutí na něj se dostanete na příslušnou licenci. Po výběru licence, stačí kliknout na tlačítko Uložit a instalace bude dokončena. Poté už je jen nutné přes FTP smazat z rootu webu soubor install.php. Toť vše. Pozn.:Pro ty co ještě nikdy nepracovali s žádným wiki systém. Obsah se administruje na tom samém místě na jakém se prohlíží. Pokud nejste přihlášeni, tak budete mít na každé stránce tlačítko Přihlásit se. V opačném případě bude mít v každé sekci oddělené nadpisem (vlevo dole) tlačítko Upravit. Wiki systémy navíc nevyužívají wisiwig editor, takže navyknout si psát syntaxi kterou podporují je z počátku obtížné, ale jde jen o zvyk. Výhodou na našem hostingu je i to, že se nemusíte starat o nastavení práv k adresářům. DokuWiki bude mít automaticky možnost zápisu do příslušných adresářů. http://blog.revolucnihosting.cz/jak-na-majsky-datum-v-php/c-13.html Tento článek bude jen tak na uvolnění. Náhodou jsem si totiž vzpomněl na všemocná proroctví o konci světa na sklonku příštího roku a tak jsem se rozhodl dát sem menší funkci jak si v PHP vypočítat konec světa:) Nejdříve ještě malá odbočka pro ty, kteří jsou informací o (teď už opravdovém) konci světa nedotčeni. Proroctví je založeno na konci Mayského kalendáře, který nastane přesně na zimní slunovrat 21.12. 2012 a Mayské počítadlo se má zastavit na krásné cifře: 13.0.0.0.0. (nechce se mi to nikterak rozebírat, odkáži raději na google) Ale proč vlastně toto téma zavádět na tento blog? Jako programátor nikdy nevíte co si na Vás zákazník vymyslí a tak i takováto věc se může hodit. Mě se to přihodilo nedávno, když mě o to požádal kamarád a tak řešení raději umístím na internet. Co kdyby se mi to příští rok ještě hodilo;) A abych pravdu řekl, tak jsem na internetu nenašel jednodušší způsob než výsledek vypočítat přes Julian Day Count. Způsob řešení hold spočívá na závažnosti zadání: {file:mayaDate.php} http://blog.revolucnihosting.cz/instalace-wordpress-na-revolucnihosting-cz/c-12.html WordPress je rychlé a kvalitní řešení, jak si na svém hostingu zprovoznit blog. Instalace toho CMS se může lišit hosting od hostingu(základ je však vždy stejný) a proto jsem se rozhodl pro začínající jedince popsat postup na našem hostingu. Přípravy na instalaci Dejme tomu že budeme chtít WordPress zobrazovat na subdoméně wp.example.cz. Přihlásíme se tedy do klientské sekce abychom si mohli vytvořit FTP a databázi nutnou pro chod WordPressu. Jelikož jsem se rozhodl, že WordPress chci zobrazovat na subdoméně wp, tak je nejdříve nutné tuto subdoménu vytvořit (tuto část můžete tedy přeskočit, pokud se má WordPress zobrazovat pod www). Po přihlášení do klientské sekce se tedy proklikáme do sekce Moje domény a hosting > Subdoména a klikneme na tlačítko Přidat subdoménu. V zobrazeném formuláři stačí pouze vybrat doménu u které má být vytvořena subdoména a do kolonky Jméno vyplnit hodnotu wp. Poté stačí kliknout na Uložit a subdoména je vytvořena. Následuje vytvoření FTP. To nalezneme v sekce Moje domény a hosting > FTP přístup. Klikneme na tlačítko Přidat FTP a nastavíme následující údaje: login: test_wpheslo: tajne-hesloDomovský adresář: wp/web/ U domovského adresáře je vždy důležité aby směroval na již existující. Pokud bychom tedy chtěli WordPress zobrazovat na adrese www.example.cz tak by tato hodnota obsahovala www/web/. Dále je také dobré nastavit IP adresu, ze kterého bude FTP spojení povoleno. Po kliknutí na Uložit už je na řadě vytvoření databáze. Můžete samozřejmě použít i nějakou již existující, ale vzhledem k možnostem našeho hostingu si vytvoření nové databáze můžete dovolit. Proklikejte se tedy do sekce Moje domény a hosting > Databáze klikneme na tlačítko Přidat databázi. Vyplníme např. tyto údaje: Server: mysql51.revolucnihosting.czLogin: dbtest_wpHeslo: db-heslo Opět pokud chcete mít klidnější spaní, doporučuji nechat u položky Host vybranou možnost local. Tím zajistíte, že i v případě prozrazení hesla nepůjde spravovat databázi vzdáleně. Samotná instalace Nyní už můžeme přistoupit k samotné instalaci. Stáhneme si aktuální verzi WordPressu např. ze stránek: http://www.cwordpress.cz/ a rozbalíme na svém počítači. Poté je potřeba nastavit FTP klienta. Pro ukázku jsem si zvolil Total Commander, protože je to pořád hojně využívaný FTP klient. Snad obrázky napoví více než slova. Pokud tedy budete postupovat tak jak je znázorněno na obrázcích tak by jste se měli bez problému připojit k FTP. Pokud ano tak na něj zkopírujte všechny skripty. Nyní už máme podstatnou část za sebou. Dále si pustíme v prohlížeči stránku (v tomto případě wp.example.cz)na kterou jsme si skripty zkopírovali. Mělo by se zobrazit následující okénko: Tato hláška může neznalého uživatele možná trošku zmást, ale připravené webové rozhraní funguje na výbornou a tak je nejjednodušší kliknout tlačítko Vytvořit konfigurační soubor a na následující stránce potvrdit kliknutím na Let's go!. Tím se dostanete do nastavení přístupů k databázi. Zde vyplníte údaje podle toho, jaké jste si vymysleli při zakládání databáze. Pro mnou popsaný příklad by vyplnění vypadalo následovně: Jen pro upřesnění ještě doplním, že Database Name (jméno databáze) a User Name (uživatelské jméno) se na našem hostingu vždy rovnají. Password (heslo) vyplníte dle svého uvážení, Database Host vyplňuje u nás vždy mysql51.revolucnihosting.cz a Table Prefix zvolte dle svého uvážení (osobně nikdy neměním). Po vyplnění těchto údajů klikneme na Submit a necháme chvilku WordPress přemýšlet. Pokud jste vše vyplnili správně, tak by se Vám měla zobrazit stránka s tlačítkem Run to install. Klikněte tedy na toto tlačítko. Tím máme největší práci za sebou. Následuje jen vyplnění krátkého formuláře kde budete vyzváni k vyplnění názvu webu, uživatelské jména, hesla a e-mailu: Abych pravdu řekl, tak nevím jaká vzorová data vyplnit, ale předpokládám, že pokud jste došli až k tomuto bodu, tak nebude nejmenší problém s vyplněním. Po vyplnění klikneme na Instalovat WordPress.Toť vše. Jak si můžete vyzkoušet instalace se dá se vším všudy stihnout do 5 minut přičemž nejvíce bude zdržovat nahrávání souborů na FTP. http://blog.revolucnihosting.cz/adminer-je-cim-dal-vice-chytrejsi/c-11.html Plnohodnotnou náhradou za velmi populárního správce MySQL databáze PhpMyAdmin je Adminer z dílny českého vývojáře Jakuba Vrány. Adminer dokáže překvapit několika maličkostma, které dokáží zpříjemnit práci s databází a tak kolikrát k přechodu na něj překáží většinou víceletý návyk na PhpMyAdmin. Tento příspěvek by neměl být recenzí Admineru, neboť v jeho používání nejsem příliš kovaný, ale měl by upozornit na propagaci tohoto správce databáze. A jelikož už Jakub Vrána napsal o admineru několik článků a propaguje jej kde může, tak se bude spíše jednat ho souhrn několika odkazů, které je dobré si pročíst. V Admineru je především kladen důraz na bezpečnost a rychlost celé aplikace. Což dokazuje i to, že celý adminer se dá stáhnout v jednom jediném souboru (oceníte především při nahrávání na FTP, v tomto ohledu bude adminer asi vždy jednoznačným vítězem). Pro začátečníka v tvorbě webů jistě jen stěží představitelná myšlenka(adminer totiž obsahuje i ikonky). Ale i takového výsledku lze dosáhnout správně zvolenou strukturou, minimalizací a kompilací. Výhoda jediného souboru tví také v tom, že pokud nějakou akci provádíte častěji, tak si její URL můžete uložit do bookmarku a zrychlit tak přístup k čatso prováděným věcem (jen pro upřesnění: PhpMyAdmin využívá rámy). Samotný adminer je distribuován pod licencí GPL nebo Apache a jeho zdrojové kódy jsou k prohlédnutí na následující adrese: http://sourceforge.net/scm/?type=git&group_id=264133 Za přečtení jistě stojí i autorovo srovnání Admineru vs. PhpMyAdmin, které sice až moc vychází ve prospěch Admineru, ale není tam na druhou stranu napsáno nic, co by nebyla pravda. Adminer vedle PhpMyAdminu nabízíme také na našem hostingu a to na drese:  https://adminer.revolucnihosting.cz/ Pokud by jste ale zatoužily po bližším prozkoumání určitě navštivte domovské stránky Admineru. Pozn.: Jednou z maličkostí, která příjemně překvapí je automatické upozorňování na novou verzi. http://blog.revolucnihosting.cz/generujeme-qr-kody-pomoci-google-chart/c-10.html QR kód si můžeme představit jako dvourozměrný, modernější čárový kód do něhož lze zakódovat až 4300 znaků nebo 7000 číslic. Tento způsob kódování pochází z Japonska a hodí se např. pro chytré mobily, pro které už je dostupných hodně čteček těchto kódů. Výsledný kód je v podstatě soubor bílých a černých čtverečků, které po přečtení a dekódování obsahují textovou informaci. Například QR kód pro náš hosting by vypadal následovně: Jak je tedy vidět, použití je asi nejlepší pro nalákání uživatele na mobilní verzi Vašich stránek.  Toho se poslední dobou využívá i v tiskových reklamách. Uvedený příklad tedy není moc dobrý, protože náš hosting nedisponuje mobilní verzí. Jak si tedy takovýto kód jednoduše vygenerovat? Stačí využít služby Google Chart, ta Vám vygeneruje obrázek (nejčastěji se používá pro generování grafů) pouhým složením URL adresy. Adresa vždy začíná: https://chart.googleapis.com/chart . Jako parametry této URL se pak zadávají hodnoty díky kterým google rozpozná jaký kód má vygenerovat. Jednotlivé parametry URL: cht - Specifikace obrázku, který se má vygenerovat. Pro vygenerování QR kódu je tedy nutné použít "qr" chs - Velikost obrázku. Optimální je zhruba do 200x200 (uvádí se v pixelech) chl - Textová data, která se mají zakódovat. choe - Výstupní kódování. Podporovaná jsou UTF-8, ISO-8859-1 a Shift_JIS URL adresa pro příklad uvedený nahoře je následující: https://chart.googleapis.com/chart?cht=qr&chs=150x150&chl=http://www.revolucnihosting.cz&choe=UTF-8 Výsledný obrázek je ve formátu PNG a lze si jej uložit a pak jej na internetu použít. Další možností je adresu vložit přímo do atributu src v tagu img. Kód se pak vytvoří ihned jak se pokusí prohlížeč zobrazit obrázek. Tuto variantu bych ale moc nedoporučoval. A proč? Představte si že máte web náchylný na XSS. Ano, žádný programátor není neomylný. Pokud by tedy na webu nějaká takový chyba byla, tak by nějaký XSS vtipálek mohl změnit adresu. Konkrétně parametr chl a uživatel by pak byl přesměrován na jinou adresu než na jakou doufal. Většina čteček sice chce ještě potvrzení o přesměrování, ale praxe je taková že spousta uživatelů přesměrování potvrdí bezmyšlenkovitě. http://blog.revolucnihosting.cz/drupal-patch-pro-upload-souboru/c-9.html Dnes jsme na technické podpoře řešili celkem záludný bug v Drupalu v.7. Jednalo se o problémy s uploadem souborů. Adresáře po instalaci byly vytvořeny správně, přístupová práva byla také v pořádku ale Drupal pořád odmítal poslušnost. Chyba se projevovala tak, že vypisovala následující hlášku: Warning: move_uploaded_file(): Unable to access temporary://jmeno_soubor vefunkci file_save_upload() (řádek: 1528 v souboru /../www/web/includes/file.inc). Na tuto chybu v souboru /includes/file.inc už byl naštěstí vydán potřebný patch, takže nebylo nutné skript opravovat. Patch si můžete stáhnout na následující stránce: http://drupal.org/files/issues/patch-file-uploading.patch Snad Vám tato informace zkrátila alespoň trochu hledání :) http://blog.revolucnihosting.cz/nastavujem-cname-u-subdomeny/c-8.html Pokud nastavujme doménu k hostingu tak musíme nastavit NSSET ID. Není to sice nutnou podmínkou, ale jedná se o ideální stav. Ale co dělat když potřebujeme, ať už z jakéhokoliv důvodu, část domény nasměrovat na jiné servery? Když totiž nastavíte NSSET ID na hodnotu REVOLUCNIHOSTING-CZ tak jak požaduje náš hosting, tak Váš určený registrátor nemůže spravovat jednotlivé záznamy. To se musí udělat na naší straně. Dejme tomu, že budete chtít nastavit subdoménu eshop.mojedomena.cz na naší další službu www.eshop-rychle.cz. Pozn.: využitích pro takováto nastavení můžete najít více. Např. směrování subdomény na statický server v rámci optimalizace webu nebo směrování na testovací server. Záleží jen na Vaší představivosti. Přihlaste se tedy do klientské sekce, dále pokračujte odkazem Moje DOMÉNY a HOSTING a v zobrazeném podmenu klikněte na SUBDOMÉNY. Pokračujte kliknutím na modré tlačítko Přidat subdoménu a zobrazí se Vám následující formulář: Popis nastavení, které jsem na obrázku nastínil je následující: Doména: vyberete doménu, u které chcete nastavit subdoménu Jméno: název subdomény. V našem případě eshop (to co je zobrazeno před doménou) DNS: zde jsou dvě možnosti A: vyžadují některé služby. Tohoto příkladu se políčko pro záznam typu "A" netýká (vyplňuje se do něj IP adresa služby) CNAME: nastavte hodnotu na "c1.eshop-rychle.cz". (Tuto adresu Vám vždy sdělí poskytovatel služeb) Poté už stačí kliknout jenom na tlačítko Uložit. Projevení nastavení by nemělo zabrat déle než šest hodin. http://blog.revolucnihosting.cz/automaticke-doplnovani-pevnych-mezer/c-7.html Při psaní jakýchkoliv textů je největší problém, udržet jej typograficky správně. Nastavení šířky stránky se může občas změnit a tak se může klidně stát, že Vám zůstane písmeno "a" viset na konci řádky. Což je samozřejmě chyba. Různé editory sice mají své zkratky na vložení tzv. pevné mezery, ale vzpomenout si pokaždé na její vložení, se mi občas jeví jako nadlický úkol. Při psaní webových stránek se pevná mezera zapisuje html entitou  . Tu si sice pamatuje každý kdo html kód píše, ale chtít to po lidech kteří web plní obsahem nemůžeme. Sepsat pro automatické nahrazování mezer za pevné tam kde je to třeba, není nikterak náročné. Horší je si sehnat seznam všech možností kde se mají mezery nahradit. S tím Vám může pomoci například wikipedia.org kde je umístěn seznam titulů u kterých se nahrazování musí také dodržovat. Výsledná funkce není složitá a za tu chvilku práce to určitě stojí. Proto bych doporučoval obětovat menší čas i takovéto nepatrné úpravě. Výsledná funkce může vypadat třeba takto: {file:insertNbsp.php} Škoda jen, že něco podobného nejde sepsat na všechny gramatické chyby:) http://blog.revolucnihosting.cz/ping-sitemap-pro-google/c-6.html Soubor sitemap.xml má pomoci vyhledávačům v indexaci internetových stránek a nastínit strukturu webu. Umístění má být ideálně v rootu webu, což ovšem není podmínkou. Pokud je ale umístěn v nějakém adresáři, odkazy v něm umístěné, by neměly odkazovat na nadřazený adresář. Co ale dělat když vyhledávače o Vašem souboru sitemap nevědí? Nebo vědí, ale ještě nevědí o změnách na Vašem webu? Google už nějakou dobu nabízí možnost, jak do něj můžete šťouchnout tak, aby si Vaší sitemap stáhnul, uložil si odkazy nalezené v ní a použil je následně k indexaci stránek, hned jak bude mít čas. Tomuto šťouchnutí se říká ping sitemap. Zjednodušeně řečeno jde pouze o spuštění url adresy v určitém formátu. Pro google je to konkrétně: http://www.google.com/webmasters/sitemaps/ping?sitemap=sitemap_url Spouštět tento příkaz pokaždé, když se na stránkách vygeneruje nová verze sitemap je nepraktické a jen stěží zapamatovatelné. Pokud má být práce efektivní, je třeba rutinní práci automatizovat. Přičemž né pokaždé musíme nutně smolit vlastní kód. Na internetu je spousta hotových řešení při jejichž použití pak do kódu Vaši aplikace stačí přidat následující příkaz: {file:pingSitemap/_googleSitemap.phps} Aby jste mohli využívat ping sitemap takto jednoduše, stačí když do Vaší aplikace umístíte deklaraci funkce pingGoogleSitemaps();, kterou naleznete v článku: PHP function to ping Google Sitemaps. Bohužel toto řešení není vhodné pro náš hosting jelikož není povolená funkce fsockopen();. Řešením je tedy funkci upravit tak, aby se prováděla pomocí CURL. {file:pingSitemap/rhPing.phps} Ping pro sitemap podporují i další vyhledávače, ale jejich význam je v našich končinách minimální. Proto jen pro představu uvedu url adresy jednotlivých pingů: Yahoo.com: {file:pingSitemap/yahooUrl.phps} Bing.com: {file:pingSitemap/bingUrl.phps} Ask.com: {file:pingSitemap/askUrl.phps} Díky těmto adresám lze také do budoucna funkci velmi jednoduše rozšiřovat. Jak je na tom s implementací český seznam bohužel netuším. Ale seznam má ve zvyku být pár let pozadu, takže s trochou trpělivosti se dočkáme. Pozn.: Pokud budete rozšiřovat funkci o další pingy, a funkci spouštíte při nějaké náročnější akci, tak se Vám může nepříjemně protáhnout doba zpracování. Proto je vhodné generováné pingy spouštět např. cronem, kde si nejdříve ověříte zda došlo ke změně sitemap. http://blog.revolucnihosting.cz/zobrazovani-chyb-na-webu/c-5.html Manipulování se zobrazením chyb na testovacím vs. produkčním serveru, by mělo patřit k základním schopnostem již začínajících programátorů. Přesto se i dnes najdou lidé, kteří toto buď nechtějí nebo neumějí řešit. Přitom je pro testery(nebo škůdce) zobrazená chyba na produkčním serveru něco jako červená barva pro býka. Základní chybou bývá využívání znaku zavináč "@", který je schopen potlačit chybové hlášení u funkce, které je předřazen. Programátor by si měl uvědomit, že chyby jsou dobrou nápovědou k jeho nedokonalému kódu a tak by se měl snažit tyto chyby odchytávat a odstraňovat. Nejlepší vizitkou pak je, když log chyb zůstává prázdný. Na našem hostingu je zobrazování chyb defaultně vypnuto tak, aby nedocházelo k jejich zobrazování návštěvníkům webu. Pokud ale vyvíjíte stránky, je vhodné si zobrazování zapnout. Toho lze docílit nastavením direktivy display_errors. Dodatečné nastavení zobrazení si pak můžete nastavit php funkcí error_reporting(); Na začátek Vašeho scriptu tedy umístíte následující řádky: {file:source01.php} K tomuto zápis bych snad uvedl jen dvě poznámky. Nastavením error_reporting(0); sice zobrazovaní chyb také zamezíme, ale má to podobný účinek, jako kdyby jste používaly zavináč před funkcemi u kterých chcete chyby potlačit (Takže nedoporučuji). Vzpomenout si pokaždé než zkopírujete scripty na ostrý server že máte nastavit 0 u display_errors , je přinejmenším nepraktické. Rozšíříme si tedy nastavení o následující řádky: {file:_source02.php} Zjednodušeně řečeno si zde definujeme konstantu DEBUG díky které se můžeme v celém projektu rozpoznat zda skripty nespouštíme na testovacím serveru. O tom zda jsme na testovacím serveru nám rozhoduje jedna podmínka. Proměnná $_SERVER['HTTP_HOST'] nám říká pod kterou doménou web zobrazujeme (vhodné např. při využívání webových aliasů) a $_SERVER['REMOTE_ADDR'] kontroluje zda se na skript koukáme z naší IP. Jen pro pořádek doplním, že je potřeba za hodnotu 255.255.255.255 doplnit Vaší IP adresu. Tu zjistíte např. příkazem ipconfig v příkazové řádce, popř. ještě jednodušeji na adrese: http://www.mojeip.cz/ Pokud zatím nevíte proč jsem vlastně definoval konstantu DEBUG jedno z možných použití by mohlo být následující. Předpokládejme že veškeré chyby ukládáme do pole $chyby a na produkčním serveru budeme chtít zapisovat chyby do logu a na testovacím je vypsat do divu, který pak můžeme libovolně nastylovat. Rozšíření by mohlo vypadat následovně: {file:_chybyDebug.php} Fantazii se meze nekladou. Ostatně jako v celém programavání. Samozřejmě se nejedá o vyřešení způsobů zobrazování chyb, ale jen nastínění záčátečnických chyb, kterých je dobré se vyvarovat. Závěrem ještě jedno malé upozornění. Pokud do nějakého adresáře ukládáme citlivá data, jako jsou např. výpisy chyb, je dobré adresář znepřístupnit z venčí. Toho dosáhneme vytvořením souboru .htaccess do adresáře, který chceme ošetřit a do něj vložíme následující řádku: {file:htaccessDeny.php} http://blog.revolucnihosting.cz/nastaveni-cronu/c-4.html Umět nastavit cron by dnes měl umět každý tvůrce webu. Bohužel tomu tak ale nebývá. Jestli je vina na straně tvůrců webů(který pro ně marně hledají využití) nebo tuzemských webhosterů(kteří ne vždy tuto službu umožňují nastavit) těžko spekulovat. Pravdou ovšem je, že cron je velice užitečná věc. Pro neznalé pojmu cron jen drobné vysvětlení. Cron je softwarový démon(program běžící na pozadí operačního systému) který se stará o spoštění skriptů, programů, atd. v určitém čase. Pro uživatele OS Windows by se dalo říct, že se jedná o plánovač úloh. Na webu se nejčastěji používá k automatizaci rutiní práce nebo spouštění výkonnostně náročných operací na čas, kdy server v podstatě odpočívá(většinou noční až ranní hodiny). V naší klientské sekci se do nastavení cronu dostanete přes detail domény v části služby. Vedle názvu cron klikněte na symbol "±". Zobrazený formulář odpovídá tomu, jak by jste zadávali cron v příkazové řádce linuxu. Zvolili jsme radši přenositelnost vědomostí, nad pohodlností klikatelného formuláře, ve kterém by se zkušenější uživatelé mohli zbytečně ztrácet. Formát cron Jednodtlivá políčka (kromě cmd) označují čas/datum spuštění. Každé políčko může obsahovat nejen číselný rozsah(minuty: 0-59; hodiny: 0-23; den: 1-31; měsíc: 1-12; den v týdnu: 0 = neděle, 1 = pondělí, …, 6 = sobota), ale i hvězdičku nebo zápis typu */5. Pokud je v v těchto polích hvězdička, tak to znamená vykonání příkazů v každé jednotce daného rozsahu. jestli zadáte např. */5 do pole minuty, tak se příkaz vykoná každou pátou minutu. Do políčka cmd se poté zadává buď  URL adresa stránek, nebo lokální absolutní cesta ke skriptu který se má spustit. Větší zázrak v nastavování cronu není a pokud jste zatím žádný nestavovali, tak snad následují tabulka příkladů by mohla naznačit že v cronu není žádná alchymie. Pro přehlednost budu uvádět jenom nastavení časových údajů. Popis provedení minhoddenmesdvt Každou minutu každého dne v týdnu * * * * * Každé pondělí v 6:30 30 6 * * 1 Každých pět minut */5 * * * * Prvního dne v měsíci o půlnoci 0 0 1 * * Každou 10 minutu mezi 14:00 a 15:00 */10 14 * * * 29.2 v 7:00 (přestupný rok) 0 7 29 2 * Doufám, že předchozí tabulka Vám dala alespoň základní přehled nad tím jaké časové úseky lze celkem snadno definovat. Fantazii se meze nekladou a určitě by se našli ještě zajímavější příklady, ale bylo by to podle mého názoru pouhé opakování těch, co jsem napsal výše. Jen ještě pro přehled, takhle nějak by vypadal zápis druhého příkladu cronu na příkazové řádce: 30 6 * * 1 /......./cron.php http://blog.revolucnihosting.cz/domenova-kriminalita/c-3.html Pokud je Vám tento pojem neznámy, je načase to napravit. Cena domény je sice zanedbatelná, ale prošvihnutí jednoho data splatnosti Vás může stát mnohonásobně víc. Ti, kdo byly na letošním CIFu si většině případů určitě nenechali ujít přednášku od Petra Šmída ze společnosti Active 24. Byl to výborný přednes o tom, co všechno Vás může stát nepozornost. Co je to vlastně doména? Doména je něco co nelze vlastnit. Jedná se o digitální záznam v registru domén, kde si můžete pronajmout právo jí nasměrovat na Vámi určený server(kde pomocí domény můžete provozovat různé služby). Součástí domény je totiž IP adresa služeb, které se mají pod ní zobrazovat (jen pro zjednodušení, samotné nastavení má zpravidla více záznamů, ale to nepatří do tohoto článku). Cena jedné domény je různá. Národní registrátor (u nás CZ NIC) určí nákupní cenu a registrátoři domén, pak prodávají doménu s určitou marží. Cena cz domény je vsoučasnosti cca 200Kč/1rok. Doménu pak lze využít klasickým způsobem, zaparkovat jí a různě s ní spekulovat, nebo jí zaparkovat aby s ní nemohl spekulovat někdo jiný. Rizika vlastnictví domény Nechtěná změna (krádež) domény Název mluví za své, takže netřeba rozvádět. Jen je dobré mít na paměti, že pokud máte doménu dnes pod kontrolou, zítra tomu tak být nemusí. Toho lze docílit: nabouráním e-mailu - Registrační e-mail je dostupný z whoisu(veřejného výpisu). Pokud je e-mailová adresa z nějakého freemailu, tak mohla expirovat a může si jí zaregistrovat kdokoliv. zneužitím svěřených přístupů - Ty mohou být zneužity např.: webmasterem, zaměstnancem, člověkem přes web, nebo bývalému zástupci firmy. zfalšováním podpisu úředního ověření Účelovým založením firmy - Buď se stejným nebo podobným názvem, nebo s jiným názvem ale na stejné adrese. zaregistrováním domény po expiraci, na které byl vytvořen registrační e-mail cennější domény. Cybersquatting Registrování domén s názvy cizích obchodních značek. Tuto doménu pak lidé drží ve svém vlastnictví, aby s ní mohly spekulovat. Spekulant pak řeší na tom, že společnost nechce riskovat nákladné a zdlouhavé soudní spory na získání domény na kterou má právo. Další možností je parazitování na dobrém jménu značky. Spory o převod domény Vznikají především při zpochybňování převodu domény, při rozdělení firmy nebo rozchodu obchodních partnerů. Kyberšikana Využívání doménového jména k pomluvení, psychickému týrání, skrytému boji proti konkurenci, atd. není žádná novinka. Příkladů již bylo v naší zemi víc než dost. Netřeba připomínat, dříve nebo později se objeví nový. Prevence doménové kriminality sepište smlouvy ověřujte identitu protistrany ověřuje si informace ve whoisu ověřujte si web např. na: http://web.archive.org uvádějte do kontaktů název firmy vyhýbejte se  uvádění konkrétní osoby vyplňte DIČ / IČO pokud si nemůžete doménu zamknout, tak pravidelně kontrolujte stav domén a kontaktů sjednocujte a aktualizujte své kontakty pokud je to možné tak doménu zamkněte neuvádějte smyšlená data používejte trvanlivé a bezpečné emailové adresy nevybírejte si registrátora jen podle ceny Co dělat když už je pozdě: hlavní je neplatit vyděračům kontaktujte původního i současného registrátora domény buďte připraveni doložit všechny doklady o Vašem původním vlastnictví domény spolupracujte s centrálním registrem NIC podej trestní oznámení Doufám že po přečtení, si méně znalý uživatel uvědomí, jak moc cenná pro něho jeho doména může být. Cena domény totiž není jen ta co platíte svému registrátorovi, ale jako hodnota Vaší značky kterou je nutné neustále opatrovat. Ještě bych možná doporučil prohlédnout si prezentaci, která byla na konferenci. Ta je ke stažení na stránkách CIF 2010.