Adminer 5.1.0 - autoloading pluginů

Jsem velký zastánce convention over configuration, takže Adminer ani žádnou konfiguraci nemá. Jsem za to strašně rád. S konfigurací se člověk časem dostane do bodu, kdy by do ní potřeboval začít přidávat minimálně nějaké ify a pomalu se z toho stává programovací jazyk. Dále je konfigurace noční můra řešení problémů – uživatel si stěžuje na nějaké chování a teprve po hodině zjistíte, že si něco zapnul v konfiguraci. V horším případě spolu konfigurační direktivy můžou všelijak kolidovat a jejich udržování stojí hodně energie. Jenže uživatelé si chování prostě měnit chtějí, tak jsem jim dal do ruky mocnější nástroj – pluginy. Ty nejsou omezeny tupostí konfiguračního jazyka a můžou dělat vše, co jejich autor zvládne vymyslet. Adminer jen musí poskytnout dostatečné API.

Zapnutí pluginů v Admineru nebylo úplně nejjednodušší: bylo potřeba vytvořit soubor s definicí funkce adminer_object, ručně vložit soubory s pluginy (nebo je autoloadnout) a vytvořit jejich objekty. Dále vytvořit další objekt, který to všechno pospojoval, a ten z funkce vrátit. Člověk také nesměl zapomenout vložit původní adminer.php a také soubor plugin.php, který pluginy vůbec dovoloval používat. Říkal jsem si, že to každý programátor zvládne – v praxi to je copy/paste příkladu a jeho upravení. Ale někdy člověk musí řešit i další věci – třeba pokud plugin dělá dodatečnou autentizaci (např. podle IP adresy nebo podle jiného hesla než do DB), tak také musíme znemožnit přístup k původnímu adminer.php, kde tyto kontroly neproběhnou.

adresářová struktura Tohle všechno je teď pryč. V Admineru 5.1.0 stačí pluginy prostě zkopírovat do adresáře adminer-plugins/ a Adminer si je tam odtud sám nahraje. Pokud pluginy potřebují nějakou konfiguraci, tak je možné ji udělat v souboru adminer-plugins.php pouhým vrácením pole s vytvořenými pluginy:

<?php
// zde nemusí být žádné include_once "login-password-less.php"

return array(
    new AdminerLoginPasswordLess('$2y$07$Czp9G/aLi3AnaUqpvkF05OHO1LMizrAgMLvnaOdvQovHaRv28XDhG'),
);
?>

Dobrá zpráva je, že předchozí způsob vytváření pluginů i všechny stávající pluginy nadále fungují – není potřeba dělat žádnou úpravu. Další možnost je všechny pluginy vytvořit z libovolného zdroje v adminer-plugins.php a adresář adminer-plugins/ ani nemusí existovat. Tohle celé funguje i pro pluginy databázových ovladačů.

Já už tento způsob nahrávání pluginů nějakou dobu používám a je to neskutečně pohodlné. Když chci nějaký plugin, tak si na něj v adresáři adminer-plugins/ prostě jen vytvořím symlink. To jde příkazem mklink i na Windows a ve správci souborů na to mám klávesovou zkratku. A když plugin nechci, tak symlink zase jen smažu.

Další změny

Kromě této zásadní změny jsem udělal i několik dalších oprav a úprav:

Ovladač pro IMAP

Jen tak pro legraci jsem vytvořil Adminer pro IMAP. Koukám do poštovního klienta a po intenzivní práci na Admineru najednou všude vidím tabulky s daty. Tak jsem si řekl, jak by asi bylo složité to udělat, a ukázalo se, že zase až tolik ne. Schránky se zprávami se zobrazují jako tabulky, hlavičky zpráv se zobrazují jako jejich obsah. Pokus o editaci zprávy o ní zobrazí nějaké další údaje. Vložení záznamu nic nedělá, ale s trochou úsilí by to asi šlo předělat na odeslání nové zprávy. Mazání označí zprávy jako smazané, ale ze schránky je fyzicky neodstraní, to se dá udělat příkazem TRUNCATE. A to je asi tak všechno, co to umí. Funkce support(), kterou Adminer zjišťuje, co všechno daná databáze podporuje, vrací pro všech 25 featur prostě false.

Testy pro PDO

Přidal jsem parametr URL ext=pdo, který vynutí použití extenze PDO místo nativních, které Adminer preferuje. Je to hlavně kvůli snadnějšímu ladění chyb, protože PDO ovladač se chová trochu jinak (např. pro boolean sloupce v některých databázích vrací skutečný PHP bool). Pro PDO se také nově generuje kompletní sada end-to-end testů. Díky tomu se mi podařilo ošetřit pár chyb a nekonzistencí, které Adminer při použití PDO měl.

Interní změny

Změna, která se navenek doufám nijak neprojeví (end-to-end testy nic neodhalily), je modernizace JavaScriptu:

V PHP jsem zapnul chyby E_NOTICE a E_STRICT kromě přístupu k neexistujícímu prvku pole. To se hádám navenek v některých okrajových případech projevit může, ale co odhalily testy a na co jsem sám narazil, to jsem opravil.

Na závěr zmíním, že jsem sepsal poznámky pro vývojáře, v podstatě takový můj braindump.

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

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-2025 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.