Adminer 1.11.0

Školení, která pořádám

Nová verze Admineru (dříve phpMinAdmin) přináší velkou spoustu novinek hlavně v uživatelském rozhraní. Snažil jsem se nástroj vymazlit, aby se dal používat co nejpohodlněji.

Funkční novinky

Uživatelské rozhraní

Interní změny

Kontrola nových verzí

Po vydání nové verze, která opravuje nějaké chyby nebo přidává užitečnou funkčnost, mi je líto uživatelů, kteří na tuto verzi nepřejdou. Vedle RSS a upozornění e-mailem jsem proto přímo do aplikace přidal kontrolu nové verze. Ta je co nejméně agresivní – jednou za sezení se pokusí stáhnout informaci o nové verzi a zobrazit ji. Když se to nepovede (třeba proto, že není k dispozici připojení k Internetu), tak nic nezobrazí a dále už to nezkouší.

function verify_version(version) {
	document.cookie = 'adminer_version=0';
	var script = document.createElement('script');
	script.src = 'https://www.adminer.org/version.php?version=' + version;
	document.body.appendChild(script);
}

Historie

Jakýkoliv provedený dotaz umí Adminer zobrazit a upravit. V minulosti se celý dotaz předával v URL, což je jednak nehospodárné a jednak u dlouhých dotazů nefunguje v Internet Exploreru, který délku adresního řádku omezuje. Nová verze ukládá provedené dotazy do session proměnné, kterou využívají odkazy pro jejich upravení. Historie je oddělená pro každý server a vybranou databázi. Kromě toho se provedené dotazy zobrazují na stránce SQL příkazu, kde je vidět kompletní historie úprav v Admineru.

Závěr

Celkem jsem provedl více než 150 změn, jejich kompletní seznam je v SVN.

Vydal jsem verzi 1.11.1, která opravuje chybu při zapnuté extenzi Filter. Alespoň můžeme vyzkoušet, jestli funguje upozorňování na nové verze.

Jakub Vrána, Adminer, 3.7.2009, diskuse: 78 (nové: 0)

Diskuse

Honza:

Dobrý den,
Jakube, možná něco přehlížím v konfiguraci, ale Adminer se pokouší přistupovat na adresu http://servername/Adminer/server=servername&db=dbname
Postrádám v adrese oddělovač pro předání parametrů "?". Nevím, zda to není chybějícím nastavením URL REWRITE, používám IIS bez tohoto modulu.
Děkuju za nasměrování k řešení.

ikona Jakub Vrána OpenID:

Dělala to i předchozí verze? V jakém okamžiku (po provedení jaké akce) se otazník nepřidá?

Honza:

Zda předchozí, to nevím, zkusil jsem Adminer poprvé. Otazník chybí kompletně u všech textových linků, tzn. přihlášení se provede korektně, ovšem pak (kromě volby jazyka a databáze - jsou to select boxy) není možné kliknout na žádný odkaz, protože u všech chybí otazník. Vyřešil jsem to vlastní PHP chybovou stránkou pro kód 404, která přesměruje pomocí 307 Temporary Redirect na upravené URL s otazníkem, nicméně asi to není ideální řešení :-)

ikona Jakub Vrána OpenID:

Můžete prosím ověřit, zda je na serveru nastavené $_SERVER["REQUEST_URI"] a pokud ano, tak jakou má hodnotu? Pokud ne, tak zda je nastaveno $_SERVER["ORIG_PATH_INFO"]. Prozradí to třeba phpinfo().

Honza:

Do obou atributů se korektně předávají správné údaje, v případě volání stránky s URL http://servername/Adminer/PhpInfo.php je v obou proměnných hodnota "/Adminer/PhpInfo.php".

Patrick:

Dobrý den,
také se mi to objevilo, ale také až u této verze. 1.10 byla v pořádku... Server je apache...

ikona Jakub Vrána OpenID:

Nedaří se mi to reprodukovat na žádném serveru. Můžete si prosím stáhnout zdroják http://www.adminer.org/data/adminer-1.11.0.zip a vyzkoušet, jestli to dělá i ten?

Honza:

Ano, projevuje se to i ve zdrojové verzi aplikace, naprosto shodně.

ikona Jakub Vrána OpenID:

Můžete tedy prosím v index.php zavolat var_dump($SELF) po nastavení této proměnné?

Patrick:

Můžu vám dát přístup k testovací databázi jestli by to mohlo pomoct...

Honza:

Mám obdobný výsledek jako Patrick. A proaktivně :-) jsem si dovolil před nastavením $SELF ověřit obsah proměnné $_SERVER["REQUEST_URI"] - a vida, je prázdná. Tady bude asi příčina.

Patrick:

obsah $_SERVER["REQUEST_URI"]  se ztrácí zřejmě někde na řádku

$_SERVER = ($_SERVER ? filter_input_array(INPUT_SERVER, FILTER_UNSAFE_RAW) : array());

Honza:

Obsah té proměnné $_SERVER["REQUEST_URI"] se ztrácí tady:

$_SERVER = ($_SERVER ? filter_input_array(INPUT_SERVER, FILTER_UNSAFE_RAW) : array());

ikona Jakub Vrána OpenID:

Děkuji za odhalení, zatracený Filter. Můžete prosím vyzkoušet verzi http://www.adminer.org/data/adminer-1.12.0-dev.php? Pokud bude fungovat, tak bych ji ještě dnes vydal.

Pro zajímavost, jakou verzi PHP používáte? A jak máte nastavené konfigurační direktivy filter.default a filter.default_flags?

Patrick:

U mně je to dobrý :)

PHP 5.2.10, webhosting C4:
http://www.webhosting-c4.cz/php5info

Patrick:

filter.default je unsafe_raw a filter.default_flags je prázdná

ikona Jakub Vrána OpenID:

Děkuji, chyba je tedy zřejmě vyřešena. Zkombinovaly se dva problémy – SERVER se Filtrem zřejmě nepřepisuje za všech okolností a místo unsafe_raw jsem omylem napsal unsafe_row :-). Díky tomu se ale na chybu alespoň rychleji přišlo.

Zhruba do hodiny vydám novou verzi.

ikona Jakub Vrána OpenID:

Novou verzi jsem skutečně vydal a zmínku o ní jsem přidal do článku. Ale kdyby si tam toho někdo nevšiml, tak to raději píšu i sem.

Honza:

Děkuji za pomoc, momentálně situace shodná s Patrickem, Adminer funkční. Nastavení direktiv rovněž shodné.

ikona Jakub Vrána OpenID:

To já děkuji za pomoc s odhalením a lokalizováním chyby.

Patrick:

výsledek var_dump

string(17) "server=localhost&"

Dundee:

Stajná chyba i u mě (Apache2, fcgid). Vytváří to odkazy ve tvaru:

http://localhost/server=localhost

ale Adminer běží na adrese:

http://localhost/pma.php

Honza Marek:

Nejde mi stáhnout adminer z hlavního stahovacího odkazu na adminer.org. Musel jsem kliknout na mirror.

ikona Jakub Vrána OpenID:

Ano, nějakou dobu trvá, než se nová verze na SF.net objeví.

Visitor:

Jakube, stále přidáváte nové funkcionality... Kdy se z "min" stane "my"?

Možná jinak...
Proč jste schopen do jednoho malého souboru dostat to co "My" má v několika megabytech?

ikona Jakub Vrána OpenID:

Situace se změnila. Adminer už není nějakou chudší variantou phpMyAdminu, ale plnohodnotným nástrojem, který si lidé (samozřejmě včetně mě) vybírají proto, že se jim s ním prostě lépe pracuje. To, že je v jednom malém souboru, je jen příjemný bonus.

A v jednom malém souboru je proto, že se jednak snažím věci dělat elegantně a jednak to pořád beru jako důležité kritérium, takže jsem třeba zdrojový kód minifikoval, což má v PHP málokdo zapotřebí.

ikona bukaJ:

Jakube,
poslal jsem Adminer na hosting a zlobí mi tam posílání SQL dotazu přes textové pole. Adminer hlásí "Nepodařilo se nahrát soubor".

Dělá to jen u zaslání kompletního DUMPu databáze, konkrétně asi 100kB textu.  Když jej pošlu jako soubor, je vše OK, ale když ho pošlu jako text okopírovaný do políčka, tak to padne.

Pokud bys, Jakube, potřeboval ještě nějaké informace (např. o hostingu), napiš mi e-mail.

Juraj:

Ahoj. Presne sa to stávalo i mne, nepodarilo sa mi však túto chybu reprodukovať.

ikona Jakub Vrána OpenID:

A nezmáčkl jsi náhodou tlačítko Provést u souboru místo tlačítka Provést pod textareou? Jejich funkce se totiž liší - horní zpracuje textareu, spodní přiložený soubor.

Asi by to chtělo jedno z nich přejmenovat, že?

Mohla by tam také být detekce toho, co je vyplněné, ale problém je, že může být vyplněné oboje.

Martin:

Bezva, nová verze už samovolně neodhlašuje :-)

Jinak někde tu zaznělo, že jednosouborovost je příjemný bonus. Myslím, že pro spoustu lidí včetně mě je to naprosto zásadní kritérium a možná i největší důvod, proč tenhle nástroj používat...

paranoiq:

myslím, že i bez té jednosouborovitosti už to Adminer vyhrává na celé čáře :]

Martin:

Hmm, tak jsem se radoval předčasně. Večer ve 22:00 jsem se přihlásil a ráno byl odhlášen (bez uzavření prohlížeče, změnila se jen IP adresa).

Jarek:

Díky moc za Adminer, od té doby, co o něm vím, jsem přestal používat phpMyAdmin.

Měl bych prosbu: bylo by možné ve struktuře tabulky vedle názvu a deklarace sloupce zobrazovat také komentáře? Přehled celé databáze je zobrazuje, tak by to bylo konzistentní. Komentáře k jednotlivým sloupcům si píšu a časem jako když je najdu.

paranoiq:

ano. komentáře, které jsou schované nejsou příliš užitečné. také bych byl rád, kdyby byly zobrazené

ikona Jakub Vrána OpenID:

Zobrazuje se v editaci struktury tabulky, asi to tak nechám.

ikona PeTaX:

Jakube, mám pocit, že CSV import má nějakou chybku. Pokud je csv oddělený čárkami a texty v "", tak to všechny textové řetězce zahodí.

ikona Jakub Vrána OpenID:

Jde skutečně o fatální chybu importu, vnitřek "" se prostě zahodí. Opravil jsem to v SVN, děkuji za upozornění.

Ondřej Brejla:

Ahoj. Při úpravě tabuly má hlavní přidávací "+" tlačítko (to nahoře, vedle zaškrtávátka auto increment) anglický titulek Add next. Ostatní "+"ka u jednotlivých řádků mají český ekvivalent.

ikona Jakub Vrána OpenID:

Díky za upozornění. Už jsem si toho také všiml a opravil to v SVN.

Martin:

Taky jeden bug report. Při editaci tabulky, pokud se klikne na přidání sloupečku (čudl +), obnoví se stránka a přidají se dva sloupečky. Není problém jeden umazat, a v předchozí verzi to bylo ok.

ikona PeTaX:

add Martin: Dělá to jen MSIE - Firef, Chrome a Opera ne.

ikona Jakub Vrána OpenID:

Díky za upozornění, opravil jsem to v SVN.

Jakub Sochor:

Zdravím,
Adminer se mi velmi líbí, ale bohužel mi u něj vadí jedna věc, která je dostupná v PhpMyAdminu a to tato:
Když mám tabulku a kliknu na Nová položka, tak by vedle názvů sloupců mohl být zobrazen také jejich datový typ. Bylo by to přehlednější, při přidávání do nějáké tabulky, kterou moc neznám a chci tam přidat jednu položku.

ikona Jakub Vrána OpenID:

Ve viditelné oblasti by to podle mě moc překáželo, tak jsem to přidal alespoň do title názvu sloupce. Na stejném místě se to zobrazuje i ve výpisu dat.

ikona Jiří Pospíšil:

Dobrý den, při nastavování výchozích hodnot sloupců Adminer správně výchozí hodnoty nastaví, ale později s nima nepracuje, resp. při manuálním vkládání nové položky je pole s nastavenou výchozí hodnotou prázdné a stejně tak při opětovné editaci výchozích hodnot sloupců.

ikona Jakub Vrána OpenID:

Díky za upozornění, je to zavlečená chyba. Opravil jsem to v SVN.

pojízdná kočka:

Ono je stejně divné, proč nemůžou být výchozí hodnoty rovnou na stránce pro pozměnění tabulky - navíc, když tam můžou být komentáře... (které jsou z hlediska databáze nedůležité).

Navíc se s tím pojí další potíže - vezměte např. tento příklad: Mám tabulku, ve které mám pole typu varchar s nějakou řetězcovou výchozí hodnotou. Pak se rozmyslím, že místo varchar chci třeba typ int nebo datetime. Při pokusu o uložení změněné tabulky MySQL zařve "nesprávná výchozí hodnota pro pole (to a to)" a uživatel nemá z daného formuláře šanci tu výchozí hodnotu změnit. (Ano, může sice upravit nabízené SQL, ale to už jsme kvalitativně klesli z příjemného point-and-click nástroje na databázový shell, takže doufám, že tohle nebude nikdo namítat.)

ikona Jakub Vrána OpenID:

Já s tím souhlasím, proto je taky integrace výchozích hodnot do úpravy tabulky v oficiálním TODO.

Tento konkrétní problém se dá vyřešit kromě úpravy SQL také tak, že se v jiném tabu otevře úprava výchozích hodnot, tam se původní hodnota vymaže a potom se struktura tabulky uloží znova (stačí refresh stránky). Krkolomné to je samozřejmě taky.

Michal Prynych:

Dobry den, vsiml jsem si, ze pro kazde zobrazeni stranky se vyuziva prikaz SHOW TABLE STATUS pro zobrazeni leveho menu, pokud, ale mam dost velkych tabulek, tento prikaz trva velmi dlouho, nedalo by se to vyresit nejak jinak? Pripadne nejak kesovat? Jinak je to skvely nastroj, diky za nej.

ikona Jakub Vrána OpenID:

Kešuje se seznam databází, jehož získání taky může trvat dlouho. Tuto keš je navíc celkem snadné promazávat. Seznam tabulek se mi kešovat nechce, protože tam může dojít ke změně na více místech, vyloučit se nedá ani změna mimo Adminer, která se nedá detekovat.

Můžete prosím uvést nějaká čísla? Kolik tabulek, jakého typu a jak dlouho trvá získání jejich seznamu. Čas prozradí třeba SQL příkaz v Admineru.

Michal Prynych:

Je mi jasne, ze je to ponekud ozehava vec, protoze tabulky se mohou menit casteji nez databaze. Na druhou stranu si rikam, jak moc tu zmenu potrebuju opravdu aktualne videt?

Jinak tabulek je asi 160, vetsinou innodb, celkova velikost databaze je neco pres 10 gigabajtu. A to ziskavani seznamu trva mezi 3 - 5 sekundami. Bohuzel nemam zadne zkusenosti s optimalizaci SHOW TABLE STATUS ani optimalizaci information_schema (mimochodem dotazy na information_schema primo trvaji uplne stejne)

ikona Jakub Vrána OpenID:

Mě získání seznamu 150 prázdných InnoDB tabulek v databázi trvá kolem 13 ms. Zkuste prosím vyexportovat jen strukturu tabulek a zjistit, jak dlouho trvá jejich výpis (nejlépe na stejném serveru, ale v jiné databázi).

Můžete prosím také zjistit, jak dlouho trvá příkaz SHOW TABLE STATUS LIKE na jednotlivé tabulce?

Michal Prynych:

skutecne, na prazdnych tabulkach na stejnem stroji v jine db je to 0.013 s (coz je moc pekne a cely adminer je pak krasne svizny :)

na jednotlivych tabulkach je to dost ruzne, nejvetsi tabulka, ktera ma nejvice indexu trva necele 2 sekundy. druha nejvetsi tabulka, ktera ma jen primarni klic trva 0.3 sekundy a zbytek tabulek, ktere jsem nahodne zkusil maji 0.001

doted jsem vubec netusil, ze SHOW TABLE STATUS je zavisly na datech v tabulce. je mozne ze nektere enginy tyto informace neudrzuji, ale dopocitavaji je?

ikona Jakub Vrána OpenID:

Také to je pro mě novinka. O tom, že by se informace dopočítávaly, nevím. Naopak InnoDB přesný počet nezná a v SHOW TABLE STATUS uvádí jen přibližnou hodnotu. Přesto je ale u velkých tabulek pomalý, viz např. http://lists.mysql.com/mysql/179735.

Zatím jsem alespoň do navigace přidal zavolání flush(), aby se zobrazila hlavní část stránky. Zavedení tabulkové cache zvážím.

Michal Prynych:

Skutecne je to tak, zkusil jsem tu jednu tabulku naplnit a SHOW TABLE STATUS se velmi zpomalil. Zda se ze MyISAM timto netrpi. Kazdopadne diky za diskusi :)

Igor Aufricht:

Mám rovnaký problém, pri prítomnosti veľkých InnoDB tabuliek (konkrétne 1,5 mil. záznamov, 1GB dát) trvá načítanie ľubovoľnej stránky v rámci Adminera rádovo sekundy. Spomalenie vzniká aj po zvolení databázy (z ponuky vľavo), keď sa načíta zoznam tabuliek.

Veľmi citeľné je to na produkčnom (vyťaženom) serveri, kedy sa čas načítavania stránok zväčšuje niekedy až na minúty.

Cache tabuliek by teda zrejme pomohla ľudom pracujúcim s InnoDB tabuľkami s veľkým množstvom dát. Mne osobne by napríklad vyhovovalo riešenie s cache a tlačidlom "refresh" pre obnovenie zoznamu tabuliek.

Vďaka.

ikona Jakub Vrána OpenID:

Cache tabulek tedy zavedu, je to skutečně nepříjemný problém. Obnovovat se bude při všech změnách tabulek a pak taky na stránce s výpisem informací o tabulkách v databázi (kde se zobrazuje i přibližný počet záznamů).

ikona Jakub Vrána OpenID:

Místo cache tabulek jsem navigaci předělal na SHOW TABLES.

Michal Prynych:

Dobrý den, parádní úprava, rychlost je teď skvělá. Díky.

kesspess:

Zdravím.
Ve verzi 1.11.1 (nevím, zda i dříve) se u výpisu dat tabulky zobrazuje český překlad "Setřídit" u třetí zobrazovací oblasti. Jsem spíše pro "Seřadit" co do významu slova, co ty na to?

ikona Jakub Vrána OpenID:

Můžeš to prosím víc rozebrat? Mě přijdou obě slova stejně vhodná.

kesspess:

Nejsem češtinář, ani jsem nehledal ve slovníku, ale slovo "Setřídit" mi evokuje to, že se data uspořádají do nějakých tříd (skupin) podle zadaných kritérií, kdežto "Seřadit" mi jasně říká, že se data budou řadit.

ikona Jakub Vrána OpenID:

To by bylo roztřídit, ne?

kesspess:

"Setřídit" a "roztřídit" se podle mě liší pouze ve směru provádění akce, akce samotná by měla být stejná...

ikona Jakub Vrána OpenID:

OK, změnil jsem to.

kesspess:

Díky.

pojízdná kočka:

Jakub: (technická) Nic proti tomu, že píšeš další a další články o phpMinAdminu/Admineru. Ale s tím, jak přibývají, začíná být (myslím si) čím dál těžší orientovat se v tom, co ti jednotliví lidé říkají v diskuzi, resp. reagovat na to.
* Co třeba nějaký prťavý navigační panel, který by shrnoval všechny články o Adminerovi (buď jako plovoucí nahoře, nebo dole, ve stylu seriálů jako třeba na Intervalu)?
* Centrální diskuze, klidně v phpBB, byla by? (koukala jsem na sourceForge, ale asi jsem pidlovoká, nenašla jsem ji)

ikona Jakub Vrána OpenID:

Články o Admineru jsou na http://php.vrana.cz/-adminer.php, což je odkázáno u každého článku.

Fóra jsou odkázaná z https://sourceforge.net/projects/adminer/support. Je to na záložce Support na stránce projektu.

Prdlořeznictví Krkovička, n. p.:

Ve výpisu tabulek Adminer nabízí parametrické vyhledávání. Jeden z operátorů je IN(), který se od ostatních odlišuje tím, že to, co je v něm, není jedna hodnota (která by se dala uzavřít do uvozovek), ale výčet hodnot.

Zjevně, Adminer má jakousi kontrolu tohoto parametru, ale vykazuje "legrační" chování pro některé parametry, např.:
IN (1, "Y") ---> IN (1,) a skončí chybou (i pro textová pole)
IN (1, CHAR(50)) ---> IN (1, 50), což není to, co uživatel měl na mysli
IN (1,"2a") ---> IN (1, 2) dtto
...

ikona Jakub Vrána OpenID:

Vyžaduje to buď všechny prvky uzavřené do apostrofů nebo do uvozovek. Pokud tomu tak není, tak se vyhází všechno kromě čísel a čárek. Nic s tím dělat asi nebudu.

Michal:

Zdravím. Měl bych pár dotazů ohledně Admineru.
V souboru index.php je nastaven error_reporting na E_ALL & ~E_NOTICE. Při zobrazení výpisu všech chyb (E_ALL) se vypíšou oznámení o nedefinovaných indexech.

Rád bych věděl, jestli skrytí těchto varování je dostatečné za to, že se nemusí proměnné testovat na isset(..) a kód je zjednodušen. Případně jestli by se nějakým způsobem dal změnit  typ vypisovaných chyb a mohlo dojít k problémům s bezpečností.

ikona Jakub Vrána OpenID:

Adminer důsledně inicializuje všechny proměnné (zkontrolováno nástrojem http://code.google.com/p/php-initialized/), bezpečnostní riziko tedy nehrozí. E_NOTICE je vypnuto proto, že PHP upozorňuje i na práci s neinicializovaným prvkem inicializovaného pole, což je z pohledu bezpečnosti v pořádku.

Michal:

Děkuji za rychlou reakci.
Pokud do formuláře při neodeslání vypíši zpět vyplněné hodnoty přes např. <input type="text" .. value="$_POST[input]"> tak při (error_reporting=E_ALL & ~E_NOTICE) nebude vypsáno hlášení o neinicializaci prvku. Jaký je tedy obsah tohoto inputu ? Je v něm ono hlášení a je pouze skryto a input tedy není ve skutečnosti prázdný ?

ikona Jakub Vrána OpenID:

Nedefinovaná proměnná v PHP obsahuje hodnotu NULL, která se při použití v kontextu řetězce převede na prázdný řetězec. Příklad ale obsahuje jiné chyby:

1. $_POST[input] by hledalo konstantu input. Mimo řetězec je potřeba psát $_POST["input"].

2. Vstup od uživatele je nedůvěryhodný, je tedy potřeba ho při vypsání do HTML ošetřit např. funkcí htmlspecialchars().

S Adminerem nicméně tato debata nijak nesouvisí, proto další dotazy směruj třeba na http://diskuse.jakpsatweb.cz/index.php?act…&forum=9.

Michal:

Moc jste mi pomohl. Napsal jsem to do této diskuse pouze proto, že jsem na to narazil v situaci s Adminerem a věděl, že mi odborník jako vy podá jasné vysvětlení. Ještě jednou moc děkuji.

kozotoč:

Pěkný den,
Poslušně hlásím chybu:
Jedná se o poněkud méně frekventovaný případ, kdy chce uživatel odstranit celou databázi.
* možná jsem se špatně díval, ale nevidím, že by Adminer tuto možnost měl
* to, jestli by ji mít měl (a dovolit na jeden klik (a potvrzení)) zničit vše, toť filosofická otázka a rád bych to oddělil toho praktického.
* Pokud v SQL oknu v dané databázi napíšu "DROP DATABASE moje_databaze;", tak Adminer příkaz splní, ale hned nato v levém sloupci, tam, kde bývá výpis tabulek vypíše PHP chybovou hlášku:

Fatal error: Call to a member function g() on a non-object in C:\moje\php\www\adminer\index.php on line 251

PhpMyAdmin v případě zničení celé databáze přesměruje "o úroveň výš" -na databázový server se seznamem databází. Toto bych si pro tuto akci dovolil navrhnout i pro Adminera.

ikona Jakub Vrána OpenID:

Databáze se dá odstranit pomocí odkazu Pozměnit databázi.

Chybu jsem zkultivoval.

Přesměrovat o patro výš mi z SQL příkazu nepřijde příliš rozumné, protože hned další příkaz může databázi zase vytvořit. V exportech je poměrně běžně za sebou DROP DATABASE; CREATE DATABASE. Při klikacím odstranění se o patro výš přesměrovává.

kozotoč:

Ok. Díky

Vložit komentář

Používejte diakritiku. Vstup se chápe jako čistý text, ale URL budou převedeny na odkazy a PHP kód uzavřený do <?php ?> bude zvýrazněn. Pokud máte dotaz, který nesouvisí s článkem, zkuste raději diskusi o PHP, zde se odpovědi pravděpodobně nedočkáte.

Jméno: URL:

avatar © 2005-2018 Jakub Vrána. Publikované texty můžete přetiskovat pouze se svolením autora. Ukázky kódu smíte používat s uvedením autora a URL tohoto webu bez dalších omezení Creative Commons. Můžeme si tykat. Skripty předpokládají nastavení: magic_quotes_gpc=Off, magic_quotes_runtime=Off, error_reporting=E_ALL & ~E_NOTICE a očekávají předchozí zavolání mysql_set_charset. Skripty by měly být funkční v PHP >= 4.3 a PHP >= 5.0.