Zobrazení nadpisu ve wordpressu s omezením délky

Před chvílí jsem objevil na tipinternet.cz článek na zobrazení maximálního počtu znaků v nadpise. Je tam popsáno jakým způsobem lze zkrátit nadpisy ve wordpressu jednoduše pomoci php funkce substr. Tato funkce má však jednu nevýhodu. A to tu, že nepočítá počet znaků ale počet bajtů. Jestliže je tedy Váš web v kódování UTF-8 což nejspíš je, a používáte háčky a čárky, což asi používáte, tak může nastat problém. Například pokud budete řetězec zkracovat na 50 znaků a onen 50 znak bude např „Č“, tak se uřízne jen jeden bajt tohoto písmena a ve výsledku se vypíše nějaký paznak.

Mnohem lepší je použití multibyte funkcí. Jejich název je úplně stejný jako původní funkce jen mají prefix mb_. V tomto případě tedy mb_substr(řetězec, začátek, konec, kódování). Konkrétně například pro oříznutí všeho za 50 znakem a kódování utf-8 je to:

echo mb_substr($post->post_title, 0, 50, 'utf-8');

Takto vše funguje ale stále je zde problém, že se nadpis ořízne klidně uprostřed slova. Někomu to nemusí vadit ale já jsem detailista. Aby se tak nestalo, tak použijeme trochu složitější konstrukci:

$title = mb_substr($post->post_title, 0, 50, 'utf-8');
$mezera = mb_strrpos($title, " ", 'utf-8');
if($mezera !== false) $title = mb_substr($title, 0, $mezera, 'utf-8');

echo $title;

Tento kód postupuje takto:

  1. Zkrať řetězec na 50 znaků.
  2. Ve zkráceném řetězci najdi poslední mezeru.
  3. Jestliže zkrácený nadpis mezeru obsahuje, pak ho zkrať po poslední mezeru.
  4. Zobraz oříznutý nadpis.

Tento postup se může zdát už jako zcela dokonalý ale obsahuje ještě jeden problém. Co když bude nadpis dlouhý přesně 50 znaků? V tom případě by mohl být klidně zobrazen. Tento kód jej však i tak zkrátí po poslední mezeru. Ve výsledku bude tedy chybět celé poslední slovo.  Přidáme proto ještě jednu podmínku a 3 tečky nakonec a celý kód bude vypadat takto:

$title = mb_substr($post->post_title, 0, 50, 'utf-8');
if(mb_strlen($post->post_title, 'utf-8') > 50){
   $mezera = mb_strrpos($title, " ", 'utf-8');
   if($mezera !== false) $title = mb_substr($title, 0, $mezera, 'utf-8').' ...';
}

echo $title;

Tento kód zařídí, že vypisovaný nadpis nebude nikdy delší než 50 znaků. Slova budou vždy celá a pokud dojde ke zkrácení, tak nakonec přidá 3 tečky. A to je přesně to co jsem chtěl.

Recept na SEO v 5 krocích

Různí SEO mágové se Vás budou snažit přesvědčit jak je jejich práce komplikovaná a složitá a jak je obtížené se něčemu jako je SEO vůbec věnovat. Když Vám to bude někdo tvrdit, tak od něj rychle pryč. SEO optimalizace je v základu úplně jednoduchá.

A teď slíbený recept

Předpokládám že nabízíte nějaký produkt nebo službu a chcete aby Vás lidé našli ve vyhledávačích. Aby se tak stalo, tak stačí těchto 5 kroků:

  1. Nesnažte se optimalizovat na obecné (jednoslovné) fráze ale buďte konkrétnější.
  2. Zjistěte si jak lidé hledají to co nabízíte. (Jaké fráze používají při hledání)
  3. Použijte tyto fráze na svém webu v rozumném množství a v různých tvarech. (hlavně přirozeně)
  4. Zjistěte si jaké weby se na vybrané fráze umísťují vysoko ve vyhledávání.
  5. S těmito weby vyměňte odkazy.

Tadá. SEO hotovo.

Ale abych byl fér

Ano SEO optimalizace je v základu úplně jednoduchá. Ale její provedení bývá mnohem náročnější. Hlavním problémem jsou body 2 a 5, které je snadné napsat ale už je to horší splnit.

Problém s bodem 2

Abyste uspěli, tak je nutné najít pokud možno co nejvíc různých frází, které lidé používají. Čím širší máte základnu klíčových slov, tím více lidí na svůj web přivedete. Bohužel žádný vyhledávač Vám neposkytne informace o tom jak lidé hledají to a ono. Abyste to zjistili, tak potřebujete tvrdou řemeslnou práci, a zkrátka vyzkoušet jednu frázi za druhou. Můžete se zeptat známých a přátel jak by právě oni vaši službu hledali. Různé agentury mají výhodu v tom, že už možná podobně zaměřený web optimalizovali a je navštěvován. Díky tomu znají statistická data jak se lidé na web dostali.

Problém s bodem 5

Ono se řekne vyměnit odkazy s weby, které jsou vysoko ve vyhledávání. Jenže co z toho budou mít oni. Vy jste jejich konkurence, tak proč by vám měli pomáhat? Pravdou je, že Vám pomáhat jen tak nebudou. Jak to ale vyřešit? Řešení je dvojí:

  1. Zaplatíte jim.Výhoda: Je to snadné a rychlé. Nevýhoda: Stojí Vás to peníze. Můžete být penalizován a někteří na to stejně nepřistoupí i kdybyste nabízeli cokoli.
  2. Odkazy neměnit s konkurenty ale s weby se kterými se nějak doplňujete.Výhoda: Je to zdarma, máte z toho vzájemný prospěch a je to čisté řešení. Nevýhoda: Obtížně se hledají a na fráze, na které optimalizujete zřejmě nikdy nebudou tak vysoko ve vyhledávání jako přímí konkurenti, takže výsledný efekt bude menší.

Stejně jako v předchozím případě to vyžaduje tvrdou práci, která nějakou dobu trvá a stojí peníze.

Co ještě vědět o SEO optimalizaci?

Kvalitní SEO optimalizátor by měl samozřejmě znát ještě několik dalších informací o vyhledávačích. Jako že titulek by neměl být delší než 70 znaků nebo popisek delší než 200 znaků apod. To jsou však věci spíše praktické než nějakým způsobem ovlivňující pozici. Zkrátka vyhledávače zobrazují titulky o maximální délce okolo 70 znaků a popisky taky nejsou příliš dlouhé. Takže je lepší je delší nedělat aby se zobrazilo jen to co jsme chtěli a ne to co si vybral vyhledávač.

Kvalitní SEO optimalizace vyžaduje určité znalosti a stojí nějaký ten čas a tím i peníz ale není to žádná magie. Je to jen práce s daty a statistikou. Kdo Vám bude tvrdit, že je to něco šíleně komplikovaného, tak od toho ruce pryč.

Firefox má problém s průhledností při velkém obrázku na pozadí

Nedávno jsem vytvořil svou novou podobu mé homepage Bronzi.cz. Jedná se jen o rozcestník, který je tvořen velkou fotkou na pozadí a 4mi obdélníky s obsahem. Obrázek na pozadí má poměrně velkou datovou velikost a načítá se tak delší dobu, což se dá očekávat. Ve všech prohlížečích kromě Firefoxu je obrázek zobrazován postupně podle toho jak je načítán. Ve Firefoxu se tak však nestane. Obrázek na pozadí není vidět dokud se celý nestáhne a teprve potom se zobrazí.

Později jsem zjistil, že je to zapříčiněno průhlednými obdélníky v popředí, které jsou průhledné díky css vlastnosti opacity. Když jsem průhlednost zrušil, tak byl obrázek zobrazován průběžně jak má. Firefox zřejmě nedokáže vypočítat průhlednost průběžně během načítání obrázku na pozadí ale musí počkat, než se obrázek celý stáhne. Po té spočítá průhlednost a až nakonec jej zobrazí.

Řešení tohoto problému se přímo nabízí. Obdélníky jsem nechal během načítání stránky neprůhledné a teprve až po načtení celého webu je jim nastavena vlastnost opacity. Obrázek na pozadí je tak načítán průběžně a neblikne až po nějaké sekundě, což působí rušivě. Obdélníky mají tak malou průhlednost, že je téměř nepostřehnutelné, že se zprůhlední a návštěvníkům webů to nezpůsobí takový šok jako když se po nějaké době najednou zobrazí pozadí.

Pro zájemce ještě přikládám javascriptový kód, který je však poměrně jednoduchý.

<script>
window.onload = function(){ // funkci navěsíme na událost načtení stránky

	var els = document.getElementsByTagName('div'); // najedeme divy

	for(var i = 0; i < els.length; i++){

	   if(els[i].className.indexOf('box') != -1){ // boxy mají třídu 'box'

	      els[i].style.opacity = '0.97'; // nastavíme průhlednost
	   }
	}
}
</script>

Jak najít a odstranit duplicity v databázi

Když pracujete s databází, do které ukládáte hodně dat, pak se dřív nebo později dostanete do situace, kdy se v ní nachází nějaké duplicity. Otázka je jak je najít a následně pak smazat. Já na to používám velice jednoduchý SQL dotaz, který ale skvěle funguje.

Všechny duplicity v databázi najdete tímto SQL příkazem:
SELECT * FROM `vase_tabulka` as tab where (select count(id) from ` vase_tabulka` where duplicitni_sloupec = tab.duplicitni_sloupec) > 1

Aby vše fungovalo i u vás, musíte změnit 2 věci:

  1. vase_tabulka změňte na název tabulky, kde chcete hledat duplicity.
  2. duplicitni_sloupec změnte na název sloupce, kde chcete najít duplicity.

Pokud máte v databázi hodně dat, tak to může chvíli trvat. Je velice vhodné, aby na sloupci, kde hledáte duplicity, byl index. Dotaz následně vrátí všechny duplicitní řádky tak, že budou vypsané oba dva. Pokud chcete vidět oba dotazy pod sebou, pak použijte toto:

SELECT * FROM `vase_tabulka` as tab where (select count(id) from ` vase_tabulka` where duplicitni_sloupec = tab.duplicitni_sloupec) > 1 order by duplicitni_sloupec;

Pokud chcete vypsat vždy jen jeden záznam, použijte klauzuli group by na konci dotazu takto:

SELECT * FROM `vase_tabulka` as tab where (select count(id) from `vase_tabulka` where duplicitni_sloupec = tab.duplicitni_sloupec) > 1 group by duplicitni_sloupec;

Bohužel tento dotaz by měl teoreticky fungovat, avšak prakticky někdy nefunguje. Proto je nutné udělat ještě jednu kličku a použít celý dotaz jako vnořený do vnějšího, kde se teprve vytvoří skupinky.

SELECT * FROM (SELECT * FROM `vase_tabulka` as tab where (select count(id) from `vase_tabulka` where duplicitni_sloupec = tab.duplicitni_sloupec) > 1) as tab2 group by duplicitni_sloupec;

Odstranění duplicit

Při odstranění budeme postupovat tak, že chceme smazat všechny řádky, které odpovídají prvnímu dotazu, kromě těch, které odpovídají druhému dotazu. Bohužel většině databází není možné mazat ze stejné tabulky, ze které aktuálně čtete, proto není možné použít tyto dotazy jako podmína při mazání:

Musíme to tedy obejít. K tomu abychom mohli duplicity smazat, využijeme dočasné tabulky, do kterých všechna data uložíme a následně přečteme z nich. Celý dotaz pro odstranění duplicit bude vypadat následovně:

1) vytvoříme dočasnou tabulku, do které uložíme id řádků pro smazání.

CREATE TEMPORARY TABLE `smazat_temp` (
`id` INT(255) NOT NULL,
);

2) Do tabulky vložíme data

Insert into `smazat_temp` (id) values (SELECT id FROM `vase_tabulka` as tab where (select count(id) from `vase_tabulka` where duplicitni_sloupec = tab.duplicitni_sloupec) > 1);

3) Momentálně jsou uložena v tabulce veškeré duplicitní id, my ale chceme vždy jednu verzi z nich zachovat. Řádky, které chceme ponechat, proto z této tabulky vyjmeme dotazem:

Delete from `smazat_temp` where id in (SELECT * FROM (SELECT * FROM `vase_tabulka` as tab where (select count(id) from `vase_tabulka` where duplicitni_sloupec = tab.duplicitni_sloupec) > 1) as tab2 group by duplicitni_sloupec);

4) Na závěr odstraníme data z hlavní tabulky a dočasnou odstraníme.

Delete from `vase_tabulka` where id in (select id from `smazat_temp`);
Drop table `smazat_temp`;

Celý dotaz je nutné spustit během jednoho sezení. Pokud, tedy používáte phpMyAdmin, tak do pole s SQL příkazem musíte napsat vše najednou:

CREATE TEMPORARY TABLE `smazat_temp` (
`id` INT(255) NOT NULL,
);

Insert into `smazat_temp` (id)  (SELECT id FROM `vase_tabulka` as tab where (select count(id) from `vase_tabulka` where duplicitni_sloupec = tab.duplicitni_sloupec) > 1);

Delete from `smazat_temp` where id in (SELECT id FROM (SELECT * FROM `vase_tabulka` as tab where (select count(id) from `vase_tabulka` where duplicitni_sloupec = tab.duplicitni_sloupec) > 1) as tab2 group by duplicitni_sloupec);

Delete from `vase_tabulka` where id in (select id from `smazat_temp`);
Drop table `smazat_temp`;

Teď nechte databázi chvíli šrotit a duplicity budou pryč.

Jak psát PR články aby měly smysl?

Už bylo napsáno mnoho článků o tom, že PR články jsou jen nafouknutá bublina nebo že jde v principu jen o katalogový zápis s větším množstvím textu. A bublina PR článků pomalu splaskává stejně jako kdysi bublina katalogových zápisů. Jak už to tak bývá tak pravda je vždy někde uprostřed. Stejně jako vkládání odkazů do katalogů má význam jen v rozumné míře, tak i psaní PR článků má svá pravidla, kdy mají smysl.

1) Cílení na long tail

Aby byl Váš článek navštěvovaný, tak je třeba spolehnout se na vyhledávače. Na internetu dnes bohužel neexistuje žádný PR web, který by měl takovou přirozenou návštěvnost, aby Váš článek četli lidé, kteří PR web běžně navštěvují. PR weby navštěvují převážně jen lidé, co píší PR články. A za předpokladu, že určitě nechcete věnovat příliš úsilí, abyste Váš PR článek na cizím webu nějak optimalizovali na nějaké hlavní klíčové slovo je jedinou cestou pro úspěch u vyhledávačů cílit na long tail. Lidí, kteří takové dotazy píší do vyhledávacího políčka je podstatně méně než v případě hlavních frází ale jen u nich máte šanci dostat se na první příčky ve vyhledávání.

2) Vkládejte články do tematických webů

Tento bod souvisí částečně s bodem prvním a se SEO optimalizací. Dnes již každý webový vyhledávač pozná, do jakého tématu spadá napsaný článek. Pokud je článek o tabletkách na hubnutí napsán na webu o automobilismu, pak pozná, že zde něco nesedí. Dobře jsou ohodnocené stránky s určitým tématem, které se nachází na tematických webech se stejným zaměřením. Stránky, které svým tématem vybočují z tématu webu, nemají pro vyhledávače takový význam. Navíc na netematických PR webech je taková změť různých článků, že vyhledávač si nebude jistý, k jakému tématu Váš článek patří a ztratíte tak důležité body.

3) Dbejte na originalitu

Články propagující Váš web by měly být na různých PR webech různé. Když webový vyhledávač najde duplicitu, pak si stejně vybere jen jeden článek a ostatní zahodí. Vaše práce s přidáváním do mnoha PR webů přijde v niveč. PR článek nemusí být kdoví jaký copywriterský skvost. Dokonce nemusí ani obsahovat příliš klíčových slov a nemusí být ani gramaticky správně. Stejně cílíte na long tail a i lidé co píší dotazy do vyhledávačů, dělají i gramatické chyby. Váš článek by měl být hlavně na každém webu originální, jedině tak jej budou brát vyhledávače v úvahu.

Já nejčastěji píšu na každý PR web z patra, co mě napadne, a neřeším, co si o tom kdo pomyslí. Svůj účel ten článek splní.

4) Nepřistupujte k PR článkům jen jako k potravě pro vyhledávače

… ale jako k místu odkud k Vám mohou přijít potencionální návštěvníci, kteří Vám přinesou zisk.

Tento bod je v podstatě zobecněním všech předchozích. Obsahuje základní myšlenku, kterou jsem popsal ve článku Optimalizace pro vyhledávače = optimalizace pro lidi. Jde o to, že pokud Váš článek bude přínosný pro lidi, pak jej budou vyhledávače dobře umisťovat, protože je to přínosné i pro vyhledávače.

 

Jak importovat velké databáze a jaké můžete mít problémy?

Nedávno jsem řešil přechod z jednoho hostingu na druhý pro můj projekt kečtení.cz, tak aby nevznikla žádná prodleva v dostupnosti. Během toho jsem si vytvořil zálohu databáze, která měla přes 500Mb a setkal jsem se s problémem jak tuto zálohu obnovit. PHPmyAdmin ani Adminer s takovými zálohami pracovat neumí a vlastní parser jsem si psát nechtěl. Naštěstí jej už někdo udělal za mě.

Našel jsem si php skript, který slouží přímo pro import velkých záloh, který naleznete na adrese http://www.ozerov.de/bigdump/. Ten stačilo stáhnout, rozbalit a už byl funkční. Jak vše nastavit si můžete přečíst zde. Skript bigdump je napsán tak, že nepřekročí ani memory limit ani time limit na běh jednoho skriptu. Je totiž na pozadí spouštěn vícekrát za sebou, i když to není na první pohled vidět. Na konci obnovy se pak můžete podívat, kolik sezení zabrala celá obnova.

Dalším problémem, se kterým jsem se setkal, bylo, že při nahrávání 500 megového souboru mi spadl internet a bylo nahráno zhruba 80% souboru. Při mém pomalém připojení se mi nechtělo nahrávat celý soubor znova. Zjistil jsem si kolik bytů souboru je nahráno na serveru a pak jsem si napsal jednoduchý skriptík, který mi vytvořil zbytek souboru a ten jsem nahrál na server.

$adresa_souboru = '../../2011-10-10-09-49-kecteni_857.sql';
$pocet_preskocenych_bytu = 328787456;
// velikost souboru, která se povedla nahrát
$f0 = fopen($adresa_souboru, 'r');
$f = fopen('cast2.sql', 'w');
fseek($f0, $pocet_preskocenych_bytu);
while (!feof($f0)) {
$text = fread($f0, 8192);
fwrite($f, $text, 8192);
}
fclose($f0);
fclose($f);

Po té jsem si napsal další jednoduchý skriptík, který mi soubory opět spojil.

$f0 = fopen('cast1.sql', 'r');
$f1 = fopen('cast2.sql', 'r');
$f = fopen('zaloha.sql', 'w');
while (!feof($f0)) {
$text = fread($f0, 8192);
fwrite($f, $text, 8192);
}
fclose($f0);
while (!feof($f1)) {
$text = fread($f1, 8192);
fwrite($f, $text, 8192);
}
fclose($f1);
fclose($f);

Nemusel jsem tak nahrávat celý soubor znovu ale pouze zbývající část. Před spuštěním jsem si ještě první část přejmenoval na cast1.sql aby vše fungovalo. Výsledný celý soboubor byl vytvořen jako zaloha.sql.

Po té už jen stačilo spustit skript bigdump.php a začala obnova databáze. To nějakou dobu trvalo, ale vše proběhlo úspěšně. Co se ale nezálohovalo, byly uložené procedury v databázi. Ty jsem si musel dodatečně přepsat ale hlavní práce týkající se zálohy struktury databáze a dat byla hotova.

 

Jak mám nastavené .htaccess na hostingu wedos

Na hostingu Wedos je možné používat více domén v jednom hotingovém programu a je také možné vytvářet libovolné množství subdomén jen vytvořením dalšího adresáře ve výchozí struktuře kořene webu. Směrování do jednotlivých adresářů je zde řešeno pomocí .htaccess, který po vytvoření hostingu obsahuje toto:

RewriteEngine On

# cele domeny (aliasy)
RewriteCond %{REQUEST_URI} !^domains/
RewriteCond %{REQUEST_URI} !^/domains/
RewriteCond %{HTTP_HOST} ^(www.)?(.*)$
RewriteCond %{DOCUMENT_ROOT}/domains/%2 -d
RewriteRule (.*) domains/%2/$1 [DPI]

# subdomeny (s nebo bez www na zacatku)
RewriteCond %{REQUEST_URI} !^subdom/
RewriteCond %{REQUEST_URI} !^/subdom/
RewriteCond %{HTTP_HOST} ^(www.)?(.*).([^.]*).([^.]*)$
RewriteCond %{DOCUMENT_ROOT}/subdom/%2 -d
RewriteRule (.*) subdom/%2/$1 [DPI]

# aliasy - spravne presmerovani pri chybejicim /
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^domains/[^/]+/(.+[^/])$ /$1/ [R]

# subdomeny - spravne presmerovani pri chybejicim /
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^subdom/[^/]+/(.+[^/])$ /$1/ [R]

Adresářová struktura na hostingu, pak může vypadat třeba takto:

domains -> web1.cz
        -> web2.cz
        -> web3.cz
subdom -> subdomena1
subdom -> subdomena2

Vytvoření nového adresáře ve složce domains vytvoří prostor pro doménu, která bude do tohoto adresáře směrována. Vytvoření nového adresáře v subdom vytvoří nový prostor pro subdoménu.

Veškeré subdomény ze všech domén jsou směrovány do adresáře subdom. Problém nastává, pokud chci mít na adrese subdomena1.web1.cz jeden web a na doméně subdomena1.web2.cz druhý, pak nelze toto nastavení použít, protože obojí si šáhne do adresáře subdom/subdomena1, kde najde jeden a ten samý obsah.

Proto je vhodné použít tuto strukturu, která mi také mnohem víc vyhovuje:

domains -> web1.cz -> www
                   -> subdomena1
        -> web2.cz -> www
                   -> subdomena1
                   -> subdomena2
        -> web3.cz -> www

Pro tuto strukturu používám tento soubor .htaccess:

RewriteEngine On
RewriteBase /

# presmerovani na variantu s www
RewriteCond %{HTTP_HOST} ^([^.]*).([^.]*)$
RewriteRule (.*) http://www.%1.%2 [L,R=301]

# cele domeny (aliasy)
RewriteCond %{REQUEST_URI} !^/domains/
RewriteCond %{HTTP_HOST} ^([^.]*).([^.]*.[^.]*)$
RewriteCond %{DOCUMENT_ROOT}/domains/%2 -d
RewriteCond %{DOCUMENT_ROOT}/domains/%2/%1 -d
RewriteRule (.*) /domains/%2/%1/$1 [L]

# neexistuje subdomena, pak jdi na www
RewriteCond %{REQUEST_URI} !^/domains/
RewriteCond %{HTTP_HOST} ^([^.]*).([^.]*.[^.]*)$
RewriteCond %{DOCUMENT_ROOT}/domains/%2 -d
RewriteRule (.*) /domains/%2/www/$1 [L]

V první části je vyřešena situace kdy někdo zadá adresu jako http://domena1.cz, pak bude přesměrován na http://www.domena1.cz.

V druhé části je pak řešeno směrování na jednotlivé adresáře. Adresa http://subdomena1.domena1.cz bude směrováno do /domains/domena1.cz/subdomena1/. Z tohoto chování je zřejmé, že adresa http://www.domena1.cz bude nasměrována na /domains/domena1.cz/www/. Adresář www tedy musí vždy existovat.

Ve třetí části je řešen případ, kdy je zadaná adresa http://subdomena1.domena1.cz a adresář /domains/domena1.cz/subdomena1/ neexistuje. V tom případě je vše směrováno do adresáře /domains/domena1.cz/www/, což je taky další důvod proč musí vždy existovat jinak dojde k chybě.

Toto chování také využívám například na webu aclanky.cz, kdy je vše směrováno do /domains/aclanky.cz/www/ a když chci vytvořit nový web na subdoméně, tak aby jej nezachtával hlavní web, pak stačí jen vytvořit patřičný adresář a vše bude směrováno do něj.

 

Favicon generátor

Nedávno jsem potřeboval vytvořit jednoduchou favicon ikonku a neměl jsem po ruce žádný nástroj pro vytváření ICO souborů. Samozřejmě jsem předpokládal, že existuje nějaký online nástroj a hned jsem ho začal hledat. Po chvíli jsem narazil na online službu http://www.favicon.cc/. Na ní je možné ikonku přímo nakreslit po jednotlivých pixelech nebo je možné nahrát libovolný obrázek a ten převést do ico formátu. Výsledek mého pokusu můžete vidět na webu http://www.aclanky.cz/.

Jak aktivovat sítě na WordPressu?

Pro svůj nový projekt infosit.cz a staronový projekt o dárcích darem.info jsem se rozhodl vytvořit systém pro vytváření webů na jednotlivých subdoménách. Po nějaké době jsem zjistil, že je možné aktivovat takový systém přímo ve wordpressu od verze 3.0. V tomto článku popíšu jak na to a s jakými problémy jsem se setkal.

Ze všeho nejdřív je nutné otevřít soubor wp-config.php a napsat do něj nový parametr:

define('WP_ALLOW_MULTISITE', true);

Po té se v administraci wordpressu v části nástroje zobrazí nová položka „Síť webů“. Po kliknutí se nám zobrazí možnosti, jestli chceme vytvořit síť jako subdomény nebo jako podadresáře. Dále název sítě a administrátorský email. V našem případě si zvolíme sítě na subdoméně. A název zvolíme infosíť.

Stránka s nastavením sítě webů

Stránka s nastavením sítě webů

Po kliknutí na „instalovat“ se síť nainstaluje a vypíšou se další požadavky, které se musí splnit, jinak síť nebude funkční.

  1. Vytvořit soubor blogs.dir v adresáři wp-content
  2. Upravit soubor wp-config.php
  3. Upravit soubor .htaccess

Jak soubory upravit je popsáno na stránce, která se zobrazí po instalaci.

Stránka po instalaci sítě

Stránka po instalaci sítě

Zásadní problém nastává, když web není umístěn v kořeni webu, tak jak wordpress předpokládá, ale používáte mod_rewrite k podstrčení adresáře s wordpressem. V takovém případě budou tyto úpravy špatné a wordpressová síť nebude fungovat.

Jak to změnit?

V dalším textu budu předpokládat správné nastavení .htaccess v nadřazených adresářích, tak že wordpress bude zobrazen na adrese infosit.cz a taky na všech subdoménách *.infosit.cz.

Soubor .htaccess je vygenerován špatně protože wordpress jej generoval jakoby se nacházel v podadresáři, ale my jej zobrazujeme jako hlavní doménu a síť chceme na subdoménách. Proto jej upravíme následovně:

RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]

# uploaded files
RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule . index.php [L]

Jediné co se změní, bude položka RewriteBase.

V dalším kroku musíme změnit soubor wp-config. Stejně jako v předchozím případě změna spočívá pouze v odstranění nadbytečné cesty k instalaci wordpressu.

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true);
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'www.infosit.cz' );
define( 'PATH_CURRENT_SITE', '/');
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Položka administrace webů

Položka administrace webů

Tento kód pak přidáme do souboru wp-config.php.

Po té co všechno uložíte, můžete obnovit stránku a budete vyzváni k novému přihlášení. Když ale kliknete na možnost administrace webů (vpravo nahoře u uživatelského účtu), budete nemile překvapení, protože web se vám nejspíš zacyklí.

K tomu aby vše fungovalo na 100% je nutná poslední úprava v databázi. Přihlásime se do phpMyAdmina a vybereme databázi s WordPressem. Najdeme tabulku wp_blogs, kterou si zobrazíme.

Položka blogu v wp_blogs

Položka blogu v wp_blogs

Ve sloupci patch je opět přebytečná cesta, kterou je třeba odstranit. Klikneme na „upravit“ a v kolonce patch ponecháme pouze lomítko „/“, zbytek odstraníme.

Editace položky patch

Editace položky patch

Kliknutím na tlačítko proveď, uložíme změny. Nyní by už síť měla běžet naprosto bez problémů, proto Vám přeji hodně štěstí při vytváření nových a zajímavých webů.

V případě, že máte wordpress v kořeni webu, pak tento návod nebudete potřebovat. Já jsem se s tímto problémem setkal na hostingu wedos, kdy web není v kořeni webu, ale je vždy podstrčen pomocí htaccess. Samozřejmě že je možné web nahrát přímo do kořene a používat jej tam v tom je hosting wedos upravdu univerzální ale mi vyhovuje právě to podstrkávání, protože tak mám mnohem volnější ruku při vytváření subdomén nebo aliasů.

Jak aktivovat síť webů přímo na stránkách wordpressu můžete najít zde.