Adminer 2.3.0
Školení, která pořádám
Prošvihl jsem pravidelný měsíční interval pro vydávání nových verzí Adminera, takže se změn nakupilo trochu více.
Trvalé přihlášení
Výchozí limit platnosti session proměnných v PHP je 24 minut. Vzhledem k tomu, že Adminer informace o přihlášení ukládá právě sem, tak po této době dochází k automatickému odhlášení. Adminer s tím nemůže dohromady nic dělat, protože by bylo potřeba změnit buď globální hodnotu direktivy session.gc_maxlifetime
nebo lokální hodnotu session.save_path
, Adminer ale nemusí mít nikam právo zápisu. Nová verze proto přihlašovací jméno a heslo ukládá volitelně do cookie.
Kvůli bezpečnosti je ovšem neukládá v otevřeném textu, ale šifrovaně. K tomu se nakonec používá šifra XXTEA a ne mnou popsaný způsob. Aby šifrování k něčemu bylo, tak nesmí být heslo společné, ale musí být jedinečné pro každou verzi Adminera. Toho je dosaženo jednoduchým přizpůsobením – stačí definovat metodu permanentLogin
vracející libovolný řetězec. Ukázkový kód vrací každému uživateli jiný řetězec, takže ho lze přímo použít, heslo si nicméně samozřejmě můžete zvolit i vlastní.
Chápu, že definice rozšíření může být nepohodlná a povede k tomu, že většina uživatelů bude o trvalé přihlášení ochuzena, jiný bezpečný způsob uložení přihlašovacích údajů ale neznám.
Vyhledávání ve všech tabulkách
Při správě cizích databází se může hodit nová funkce, která dovoluje vyhledat text v libovolné tabulce. Ta je dostupná v Admineru i v Adminer Editoru.
Tabulky se prohledávají dotazem SELECT 1 FROM tab WHERE field1 LIKE '%$query%' OR field2 LIKE '%$query%' LIMIT 1
, který by měl být pro tuto úlohu nejrychlejší. V Admineru lze zvolit tabulky, které se mají prohledávat (takže se dají přeskočit obrovské tabulky, o kterých víme, že tam hledaný řetězec nebude, a jen by zdržovaly).
Zobrazení stavových informací
Vedle proměnných MySQL, které Adminer už nějakou dobu zobrazuje, se nově zobrazují i stavové proměnné (SHOW STATUS
). Proti ručnímu zavolání příkazu to má výhodu, že jsou z názvů proměnných vytvořeny odkazy do dokumentace.
Součty v přehledu tabulek
Při optimalizaci databáze je velmi užitečné vědět, kolik je v databázi celkem dat a jak jsou velké indexy. Adminer proto nově zobrazuje součty velikostí v přehledu tabulek. Za zmínku stojí součet sloupce Volné místo, který zobrazuje pouze místo, které lze uvolnit příkazem OPTIMIZE TABLE
. Tabulky typu InnoDB totiž volné místo mohou sdílet, každopádně ho neuvolňují.
Smazání záznamu v jeho detailu
Ve verzi 2.0.0 došlo k odstranění tlačítka Smazat z detailu záznamu, protože záznam lze smazat z výpisu dat. Protože si ale odkaz na detail záznamu posílám e-mailem, tak mi vadilo, že z této stránky nejde přímo smazat, tak jsem tlačítko zase vrátil. Stejně tak možná vrátím tlačítka pro odstranění tabulky a databáze k jejich detailu (když je zakázaný výpis seznamu databází, tak se k jejímu smazání teď nedá doklikat).
Zobrazení chyb v SQL příkazu
Několik uživatelů volalo po tom, aby v SQL příkazu bylo možné zobrazit jen příkazy, které skončily chybou. Místo toho se nyní nově pod více než jedním SQL příkazem zobrazuje odkaz na ty chybové. Jedním pohledem tak lze zkontrolovat, zda všechny příkazy uspěly a není nutné stránku prohledávat. Výhoda oproti skrytí bezchybných dotazů je v tom, že někdy je u chybného potřeba znát kontext, v jakém byl příkaz proveden.
Nevím jak vás, ale mě hrozně štve hláška You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use. Chvíli jsem váhal, pak jsem ji ale nahradil za prosté Syntax error.
U příkazů modifikujících záznamy vrací MySQL počet záznamů, které byly změněny. Někdy se ale hodí vědět i to, kolik záznamů strefila podmínka. To Adminer nově zobrazuje v bublině výsledkové řádky.
Přemýšlel jsem také o možnosti zobrazovat varování, která příkaz vyvolal, nenašel jsem pro to ale vhodné umístění, tak jsem to dal k ledu.
Zkratky uživatelského rozhraní
Když se v editaci struktury tabulky mění typ, tak obvykle nedává smysl zachovat délku. Adminer ji proto nově zachovává jen při zachování typu *char/*binary
a enum/set
.
V exportu se někdy může hodit označit víc tabulek, ale přitom ne všechny. Platí to hlavně v situaci, kdy máme v jedné databázi spatlané tabulky více projektů. David Grudl navrhoval změnit zaškrtávátka u tabulek na <select multiple>
, ten ale uživatelé neumí moc ovládat, navíc se komplikuje tím, že Adminer dovoluje zvlášť označit export struktury a dat. Nakonec jsem proto doplnil detekci prefixů tabulek (oddělených podtržítkem) a z těch, které se ve výpisu opakují, jsem pod seznam tabulek umístil odkazy.
Chyby
Kromě funkčních změn bylo opraveno také několik chyb, hlavně nefunkčnost na některých verzích IIS.
Diskuse
Honza Marek:
Bylo by možné vrátit tlačítko na smazání tabulky do stránky "Pozměnit tabulku"? Kdysi bylo myslím zrušeno s tím, že ho tam nikdo nepoužívá. Já ale dosud lezu primárně sem (než si uvědomím, že tabulku lze smazat jen v přehledu databáze).
Marek:
Podľa mňa by veľmi pomohlo použiteľnosti, ak by sa pri vyhľadávaní enum položiek použil jQuery MultiSelect (
http://abeautifulsite.net/2008/04/jquery-multiselect/) alebo niečo podobné...
a ešte jedna otázočka, keď mám vybraný filter a upravím jeden riadok, a uložím ho, tak sa stratí filter. Plánujete to nejako v budúcnosti vyriešiť?
Jakub Vrána :
Našeptávač pro enum ve vyhledávání je v oficiálním TODO.
Co se té úpravy jednoho záznamu týče, tak jsem ještě nepřišel na způsob realizace, který by mi vyhovoval.
Protože buď se všechny filtry, třídění, stránkování a tak dále může předávat v URL, což ho zhnusí, ale hlavně znejednoznační - teď když je jednoduché, tak se dá třeba snadno poznat, jestli už jsem záznam editoval, nebo si kanonický odkaz na editaci můžu uložit do záložek.
No a nebo se to může držet v session, což je problém v situaci, kdy pracuji ve více oknech najednou.
Takže sám to zatím řeším buď otevřením odkazu do nového tabu nebo označením záznamu a použitím spodního tlačítka Upravit, které se vrátí na stejnou stránku. Do budoucna asi z odkazu "upravit" u jednotlivých záznamů udělám vyskakovací formulář s AJAXovým odesíláním.
Prdlořeznictví Krkovička, n. p.:
A co třeba:
1) předávat v URL jenom index do pole v $_SESSION proměnné? (ten index by byl třeba UNIX_TIMESTAMP - tím by byla vyřešena funkčnost pro více oken i neplatnost "starých" odkazů z bookmarku)
2) vkládat do formuláře skryté políčko s URL, na kterou se (případně) vrátit.
Jakub Vrána :
Asi to je malichernost, ale pro mě jsou důležité ty kanonické odkazy. Ty návrh 1 bohužel nevytváří.
Skryté políčko tam klidně být může, ale musí se odněkud naplnit. Ha - že by hlavička Referer? Sice její posílání není povinné, ale funkčnost není nezbytná.
v6ak:
Teď mě napadá, co takhle úprava pomocí Javascriptu přímo v tabulce? Tedy, neotevřu novou stránku, jen jeden řádek tabulky začne najednou mít textarea, input a podobně místo pouhého textu, budu to mít možnost upravovat a uložit.
Jakub Vrána :
Ano, AJAXovou editaci mám v plánu už delší dobu. Chci pomocí ní kromě jiného řešit vícenásobnou úpravu záznamů.
v6ak:
Teď přemýšlím, proč mi Adminer nenabídl aktualizaci. Je to frekvencí kontrol?
Vašek Purchart:
Zrovna jsem se na to včera taky ptal Jakuba a je to tím, že se nová verze kontroluje jen jednou za session - takže do zavření prohlížeče ve většině případů.
v6ak:
Aha. Já jsem teda Adminer už pár dní nepoužíval, ale přihlášen jsem zůstal.
Jakub Vrána :
Upřesním, že se nastavuje tzv. session cookie, která platí do zavření prohlížeče. Vzhledem k tomu, že prohlížeč taky skoro nezavírám, tak jí možná nastavím týdenní platnost.
v6ak:
Ale já prohlížeč (FF 3.6.*) zavíral.
Jakub Vrána :
To se mi nezdá. Session cookie se nastavuje také do zavření prohlížeče, takže jestli jsi zůstal přihlášen, tak prohlížeč asi musel zůstat otevřen. Ověř, jestli se zavřela všechna okna a skončil proces a jestli se cookies opravdu smazaly.
v6ak:
Pokud došlo k vypnutí (ne hibernaci) počítače, tak proces asi nemohl zůstat běžet, že?
Ještě mě napadá, jestli něco nemůže prodloužit platnost sessions. Měl jsem na lokálním serveru také nějaký projekt, který sessions používal, ale já se staral o jiné věci.
Jakub Vrána :
Jak jsem psal - nejde o session PHP, takže to s tím pravděpodobně nesouvisí. Spíš ti asi prohlížeč nemaže cookies nastavené s platností do zavření prohlížeče. Schválně na stránce Admineru po spuštění prohlížeče zadej do adresního řádku javascript:alert(document.cookie)
v6ak:
V document.cookie to nemám, asi to je httponly, ale ve správci sušenek jo. Sušenku adminer_sid mám do konce relace, PHPSESSID mám do 30.3., ale to je asi jedno. Takže mám asi pátrat v rozšířeních Firefoxu.
Prdlořeznictví Krkovička, n. p.:
Mě taky ne, btw.
Jakube - děkuji mockrát za ty úpravy u zobrazování chyb. Hned si to vyzkouším.
Ales:
Syntax error: tak za tohle dík, taky mi ta hláška leze na nervy.
---:
Zdravim,
v starších verzích i v nové ( 2.3.0 ) můžu dát Zkontrolovat, Opravit a provede se, ale pokud to provedu nad tabulkou information_schema, tak dostanu následující hlášku:
Fatal error: Call to a member function fetch_assoc() on a non-object in /home/*****/php/mysql/index.php on line 684
Hever:
Proč se mi někdy nejde s novou verzí přihlásit? (chybové hlášky to nedává žádné) Mám někde nejnovšího adminera, kde to nejde a nějakou verzi phpminadmina, kde to jde.
Jakub Vrána :
Nic takového se mi nestává. Opakované přihlášení projde, nebo to je chyba trvalá? Zkus zjistit, jestli se nastaví session cookie a jestli je na disku soubor se session daty.
Jakub Vrána :
Bylo to kvůli zapnutému session.auto_start. SVN verze to řeší.
Diskuse je zrušena z důvodu spamu.