Der Zugriff auf die Datenbank ist dann und wann nötig. Aus dem Backend von WordPress heraus kann das sehr einfach sein und man muss die Zugriffsdaten nicht zur Hand haben. Sehr schnell ist ein Kundenzugriff möglich und alle Möglichkeiten, die einem mySQL in die Hand gibt, sind mit dem Plugin Adminer möglich. Vom Exportieren, Importieren und alle Arten von SQL-Zugriffen via GUI bis hin zur SQL-Anweisung kann Adminer eingesetzt werden.
Das Tool Adminer ist die Grundlage meines Plugins und holt das Tool direkt in das WordPress Backend. Adminer hat auch ohne mein Plugin und ohne WordPress sehr viele Vorteile und wer einfach, schnell und unkompliziert auf die Datenbank zugreifen will, der sollte sich das Tool anschauen - Adminer. Alternativ lohnt ein Blick in den Artikel bei Dr.Web, wo Adminer ausführlich erklärt wird.
Nun aber zum Plugin, welches den Adminer in WordPress integriert.
Was macht das Plugin
Das Plugin erleichtert den Zugriff auf die Datenbank aus WordPress heraus. Es ist entstanden, weil ich nicht selten helfen soll und die Leute keinen Zugang haben, ihn nicht wissen oder auch kein Tool auf dem Webspace für den Datenbankzugang haben. Damit bleibt mir oft nur das Einrichten eines Tools und das wollte ich vereinfachen. Mit diesem Plugin geht das einfach; es ist aber ebenso mächtig wie jedes andere Tool, welches alle Zugriffe auf die Datenbank zulässt - daher Vorsicht im Umgang mit dem Plugin. Das Anlegen einer Sicherung im Vorfeld sollte selbstverständlich sein.
Der Zugang auf Adminer wird über das Plugin gelöst, so dass man keine Zugangsdaten benötigt. Ebenfalls kann das Plugin direkt aus dem Admin-Bereich von WordPress installiert werden, so dass, je nach Webspace, nicht mal ein FTP-Zugang erforderlich ist.
Adminer lässt den Export und Import von großen Datenmengen zu, damit kann es sehr einfach sein, die Datenbank einzuspielen. Ebenfalls kann jede Art von SQL-Anweisung ausgeführt werden. Hinzu kommt, dass Adminer die SQL-Anweisung zu einer Anweisung via Mouse-Klick zurück gibt, so dass man die Anweisung dann als Syntax hat und anderweitig nutzen kann.
Adminer wurde von mir in zwei Punkten verändert, da beide Themen den Zugriff auf einen Server benötigen. Die Themen Versions-Kontrolle von Adminer und Syntax-Highlightning der SQL-Anweisung benötigen einen Zugriff auf SourceForge. Beide Punkte sind nicht relevant für das Plugin und der Zugriff ist nicht bei jedem Nutzer gern gesehen. Hinzu kommt das das Highlightning eine 100 kByte Datei benötigt, die aus meiner Sicht nicht unbedingt notwendig ist. Wer beide Funktionen unbedingt haben möchte, der muss nur die Adminer-Datei im Ordner inc des Plugins mit dem Original austauschen.
Ebenfalls habe ich ein neues Stylesheet erstellt, welches die Optik von Adminer dem Design von WordPress 2.8 anpasst. Somit ist die Arbeit in gleicher Optik gewährleistet. Das Design kann auch ohne Plugin genutzt werden und steht auf der Site von Adminer zum Download.
Voraussetzungen
Um das Plugin zu nutzen, ist WordPress Version 2.7 das Minimum, darunter habe ich keine Tests unternommen. Grundvoraussetzung ist eine saubere Installation, wo die Datenbankzugänge zu den Standard-Konstanten gepflegt sind. Das wird sicher auf die meisten Nutzer zutreffen, ist aber leider nicht immer so.
Installation
Es werden keinerlei Daten in der Datenbank abgelegt und es müssen auch keine Einstellungen vorgenommen werden. Daher ist die Installation auch denkbar einfach: in das Pluginverzeichnis kopieren oder mit Hilfe der automatischen Installation aus dem Backend des Blog installieren lassen und im Anschluss aktivieren.
Im Anschluss steht im Bereich Werkzeuge (Tools) ein neuer Unterpunkt Adminer bereit, der euch den Zugriff ermöglicht. Auf der Site zu Adminer muss dann lediglich der Button Start Adminer genutzt werden und Adminer wird in voller Bildschirmgröße in eine Thickbox geladen, so dass man ausreichend Raum zu arbeiten hat.
Download:
Der Download ist im offiziellen Plugin-Verzeichnis zu finden oder aus dem Backend deiner Installation heraus.
Historie
Seit geraumer Zeit bietet das WordPress Plugin Repository die Möglichkeit der Ausgabe des Changelog an und so werde ich direkt am Plugin, in der Readme, die Historie pflegen - daher bitte ich, dass ihr euch dort die Änderungen anschaut, so dass ich ein wenig hier pflegen muss: Changelog.
ungefeahr die gleiche Funktionalitaet wie: http://wordpress.org/extend/plugins/wp-phpmyadmin/ , oder?
Ja, aber viel viel schlanker und schneller. Die Funktionalität soll gleich phpMyAdmin sein. Adminer ist in Richtung Import von SQL besser, weil phpMyAdmin hier diverse Einschränkungen hat, die man als "Normaluser" nicht so einfach ändern kann.
Ich habe das Plugin mal ausprobiert und bin nicht sehr glücklich damit.
Das liegt nicht nur daran dass direkt beim Start von adminer erstmal das Passwort der Datenbank klartextlich angezeigt wird, sondern vor allem an der Langsamkeit der Oberfläche. Zumindest im Firefox auf dem Mac ist die Bedienung sehr zäh. Da nehme ich im Zweifelsfall doch lieber den phpmyadmin.
@webe: Ich kann in keinem Test etwas an der Geschwindigkeit merken. Der Vorteil ist ja, dass eh man phpMyAdmin installiert hat, ist man mit Adminer als Plugin schon an der Datenbank dran. Damit soll phpMyAdmin nicht schlecht gemacht werden, ganz im Gegenteil. Es ist ein mächtiges und unverzichtbares Tool, aber oft einfach zu groß. Wer einen Zugang zu phpMyAdmin hat, der braucht Adminer nicht unbedingt; für die schnelle Hilfe und schnellen Zugriff finde ich Adminer besser.
Das Passwort steht doch eh in der config, warum soll man das verschlüsseln? Wer Admin-Rechte im Blog hat, der kann eh alles. Daher wüsste ich nicht, warum ich das nicht auslesen soll; es dient ja eh nur zur Hilfe für den Admin, wenn was beim Login in Adminer nicht klappt.
Gutes Plugin, vor allem ist für mich die Prozessübersicht interessant, das die Zugangsdaten für den MySQL Zugriff im Klartext sichtbar sind stört mich auch etwas, denn wenn jemand sich durch Hintertürchen Admin Zugriff aufs Blog beschafft sieht er nicht zwingend auch die configdaten, so aber schon, allerdings ist schon allein durch die WordPress interne Plugin-Installationsroutine ein Hintertürchen für Plugins die alle Daten im Klartext sichtbar machen vorhanden, von daher bleibt es sich eigentlich auch wieder egal
dein Plugin ist jedenfalls sehr praktisch!
Gruß Sven
Ich sehe bei WP-phpmyadmin und diesem Plugin erhebliche Sicherheitsrisiken. Die Idee ist sehr gut, das Plugin auch, jedoch habe ich es wieder entfernt, da es mir zu unsicher ist.
Danke Frank für das Plugin! Ich wollte es gleich mal testen, bekomme aber leider folgenden Fehlerhinweis:
Da ich nicht weiss, inwiefern "Deine" pagination einfach durch eine vorhandene ersetzt werden kann, wollte ich nicht einfach im Code "rumfummeln"
Nein, eigentlich kann ich das nicht ändern, dazu müsste ich Adminer eingreifen, was ich bei den beiden Eingriffen, die ich aktuell getan habe, belassen möchte. Insofern wäre es schön, wenn das andere Plugin Pagination den Namen der Funktion ändert, bzw. sollte man das Plugin so schreiben, dass es nur im Frontend zieht, denn im Backend wird es sicher nichts tun, denke ich.
Das Plugin ist wirklich äußerst hilfreich, vor allem, wenn man für Kunden sichern muss.
Bestimmt interessiert auch viele andere Leser, wie man die alten Post-Revisionen damit löschen kann, ohne etwas kaputt zu machen. Ich habe leider erst jetzt die Revisionen heruntergesetzt und schon jede Menge Müll in der Datenbank. Wäre das einen Artikel wert?
@Ramona: es gibt dazu viele Plugins oder ein Query löscht alles:
DELETE FROM wp_posts WHERE post_type = "revision";You keep forgetting to update the version number in the file so it stays at "update needed"
Hallo Frank,
es gibt ein kleines Problem mit dem neuen Release deines Plugins, so dass man das automatische Update nicht nutzen kann:
http://wordpress.org/support/topic/plugin-adminer-upgrade-loop-with-101
Würde mich über einen Fix freuen
Schöne Grüße
Tobias
@The Frosty, @Tobias: i dont find a problem, the current version is 1.0.1 and the automaticly update works fine on my tests on diefferent installs. Maybe the SVN form wp.org has a problem? Please can you test this also, on my installs works the plugin fine and i use this on my client sites for helping and administration.
Hallo Herr Bueltge,
das Update-Problem taucht bei mir auch auf. In der Hauptdatei des Plugins wird die Versionsnummer nicht geändert. Die steht immer noch bei 0.2 irgendwas. (Habe sie von Hand angepasst, deshalb kann ich gerade nicht nachschauen). WordPress zeigt also immer die Update-Meldung, auch wenn gerade aktualisiert wurde.
Nach dem zweiten Update von 1.0.0 auf 1.0.1 passierte das wieder. Die Versionsnummer wird bei jedem Update zurückgesetzt.
Weiterer Vorschlag für dieses wirklich sehr geniale Plugin:
Die CSS-Datei nur laden, wenn wirklich Adminer aufgerufen wird. Zur Zeit wird sie bei jedem Admin-Aufruf geladen.
Ich kann die Versionsnummer nirgends nachvollziehen, wo bleibt die 0.2* stehen? Das CSS lade ich nur, wenn die Thickbox mit dem Adminer geladen wird. Lediglich das kleine CSS für das Menu-Icon wird immer geladen. Auch die Settings-CSS kommt nur, wenn die Seite des Adminer aus dem Menu gewählt wird. Hast du eventuell mehr Infos. Danke.
Sorry, aber das muss ich fragen, auch wenn's manche stört: Ich habe auf XAMPP eine DB eines "richtigen" Blogs importiert. Wie kriege ich diese für Testzwecke zum Laufen, zumal auf dem localhost schon eine Test-DB vorh. ist. Beim Ändern der wp-config kommt ein Redirect zum Originalblog. Das war mein erster Importversuch, um zu sehen, was dabei passiert.
@Ramona: in der DB ist die URL vermerkt, daher musst du die URLs für Blog und Install von WP anpassen; geht am einfachsten via Konstanten, siehe Beitrag
define('WP_SITEURL', 'http://www.example.com');
define('WP_HOME', 'http://www.example.com/blog');
Hallo Frank,
das Problem ist, dass du in der "readme.txt" ein "Stable Tag" setzt. Das ist die Version, die WordPress im automatischen Update verteilt, bzw. die von WordPress als "aktuellste" angesehen wird (obwohl es im SVN schon neuere geben kann!).
Für das von dir gesetzte (1.0.0) existiert jedoch kein SVN-Tag (im Repository-Ordner "tags"). Dort hast du nur mal für Version einen 0.2.6 angelegt.
Dadurch liefert WordPress dann doch den Trunk aus. Und in diesem ist sozusagen der Widerspruch, dass der Plugin-Header in der adminer.php sich als 1.0.1 ausgibt, aber die readme.txt 1.0.0 für die richtige Version erklärt. Dadurch kommt dann vermutlich der Update-Mechanismus durcheinander und bricht das Update ab, sprich, die runtergeladene zip-Datei wird nicht installiert (ich kann mich auch irren, so dass möglichweise gar keine Datei runtergeladen wird, aber der Update-Ablauf-Dialog das trotzdem anzeigt). Damit bleibt die zuletzt installierte Version (0.2.7) im Blog installiert.
Zur Lösung des Problem musst du meines Verständnisses nach einfach wieder die Tags im SVN-Repository nachpflegen (generell bei jedem Release). Das hast du bei 1.0.0 und 1.0.1 anscheinend nicht getan.
), schreib einfach "Stable tag: trunk" und gut ist.
Die readme.txt und die adminer.php in jedem Tag sollten auf sich selbst zeigen.
Die readme.txt im Trunk sollte dann auf die wirklich von die als "stable" angesehene Version zeigen (bzw. die, die du von WordPress verteilen lassen möchtest).
Im Normalfall ist das immer die aktuellste Versionsnummer, weil ja sonst niemand automatisch an die aktuellste Version kommt.
Falls du dich mit SVN-Tags nich rumplagen willst (ich hasse diesen Schritt bei einem Release auch immer
Schöne Grüße
Tobias
@Tobias: hast du einen Lesetipp um die Tags und SVN zu verstehen?
Jetzt habe ich gerade die Adminer-Zip-Datei noch mal direkt von WordPress.org herungergeladen. In der Hauptdatei adminer.php steht tatsächlich noch "Version: 0.2.7" drin. Der Plugin-Updater von WP bekommt die Info, dass Ver. 1.0.1 aktuell ist und lädt diese herunter.
Nach dem Update prüft WP nun natürlich die aktuelle Version gegen die installierte und erkennt die Differenz.
Zum CSS: Stimmt natürlich, das ist nur das Icon als base64. Sorry, habe nicht in die Datei geschaut.
Danke euch vielmals!
@Tobias: DANKE. habe ich noch nie anders gemacht, bei keinem Plugin und wie gesagt bei mir ist das auf keiner Install wie von euch beschrieben. Eventuell hat WP was am SVN umgestellt, bzw. die Auslieferung. Ich habe nun den Stable-Tag auf trunk gesetzt, in der Hoffnung dass ihr das Plugin nutzen könnt und keine Probleme mehr mit dem Autoupdate habt. In meinem Download, pur als zip über die DL-Seite des Plugins von wp.org ist die 1.0.1 drin - verstehe ich nicht.
Hi Frank,
danke für deine schnelle Reaktion bzgl. des Problems!
(Live Update: Noch während ich den Kommentar schreibe, geht der Download wieder zur aktuellsten Version
Hat wohl nur noch ein bißchen Zeit gebraucht. Der nächste Absatz ist damit eigentlich obsolet.)
Komischerweise geht es jetzt immer noch nicht, obwohl ich keinen Grund mehr sehe, dass es nicht geht. Es scheint mir, als ob das Repository auch einen Schluckauf hat. So wurde wohl die zip-Datei des Trunks nicht aktualisiert und liefert immernoch 0.2.7 (auch wenn man manuell runterlädt)...
Zu den Tags: Doch, du hast das schon gemacht, z.B. bei RSS Import (hier) und WP Maintenance Mode. Dort hast du erst vor 10 Tagen einen Tag angelegt. Tags sind eigentlich auch nichts dramatisches, sondern nur eine für Menschen verständlichere Schreibweise für eine Revisionsnummer. Statt z.B. zu sagen: "Lade dir mal die Revision 2342 des Programms runter.", sagt man so: "Lade dir mal Version (=Tag) 1.4 runter." Bestimmte Entwicklungsstände (Revisionen) kriegen also einfach einen leichter erkennbaren Namen. (Meine "Lieblingsanleitung" zu SVN ist das hier. Erklärt das ganze mit den direkten Kommandozeilen-Befehlen, ich nutze aber lieber TortoiseSVN als Windows-Shell-Erweiterung.)
So, und weil jetzt auch das Update des Plugins geklappt hat, kann ich auch mein Lob loswerden
Vielen Dank für die neue Version und deine Arbeit an der Integration des Scripts in WordPress! Erleichtert die Arbeit ungemein und erspart das lästige externe Pflegen eines phpMyAdmin.
(Zusätzlich gleich noch ein Mini-Bug-Report: beim ändern des
)
onload="bodyLoad();"hast du ein " zuviel entferntZusätzlich möchte ich noch empfehlen, die jeweils alte Adminer-Version wieder aus dem Plugin zu löschen. Ist zwar keine wirkliche Sicherheitslücke, weil die Datei ja ohne DB-Zugangsdaten nichts nützt, aber ich fühle mich ohne die alten Versionen wohler
Schöne Grüße
Tobias
Hi nochmal,
noch als Zusatzinfo: http://core.trac.wordpress.org/ticket/15138
Es scheint wirklich noch andere Probleme mit dem Repository zu geben. Ich weiß aber nicht, ob die auch der Grund für unsere Probleme sind. Vorstellen kann ich es mir, aber das mit den Tags wäre auch möglich.
Gute Nacht,
Tobias
@Tobias: ich habe den tag in der readme geändert, passt das damit?
OK, scheint wirklich ein SVN-Problem zu sein.
Ich habe jetzt die Zip über den Link oben im Artikel heruntergeladen und dann installiert. Klappt alles und die Versionsnummer stimmt natürlich auch.
Dann bleibt also nur, dass der Plugin-Updater über das WP-Repository die falsche Zip geladen und installiert hat.
@Tobias: ich lege nur dann Tags an, wenn die nachfolgende Version große Unterschiede aufweist und man damit eventuell direkt eine ältere Version ziehen kann.
Die jeweils ältere Version von Adminer war immer drin, falls es Probleme gibt, da es schwer ist Adminer umfassend zu testen und durch die Paketierung sehr schwer zu lesen.
Ich passe das aber an und lade die neue Version hoch.
* mir seit der Suche untergekommen: http://svnbook.red-bean.com/ ( in deutscher Sprache)
Hi Frank,
ich empfehle, für jede Version (die eine eigene Versionsnummer hat) ein Tag anzulegen. Damit schaffst du dir sozusagen auch ein lückenlos nachvollziehbares Versionsarchiv und man kann sich auf einen festen Stand der Software beziehen. Du musst ja ein Tag (falls du es nicht als "stable" oder verteilungswürdig erachtest) nicht in der readme.txt als "Stable Tag" markieren. Damit schaffst du dir zusätzlich auch die Freiheit, im Trunk rumzuentwickeln und zu testen wie du möchtest und bekommst damit auch eine "Developer-Version" (die man auf der Plugin-Seite auch downloaden kann (Link ganz unten)). Und wenn dir der Trunk würdig für eine neue Versionsnummer erscheint, legst du darauf ein Tag an. Und wenn dir dieses Tag dann so stabil erscheint, dass es auch über das automatische Update verteilt werden soll, änderst du die readme.txt (im Trunk und im Tag!) auf das neue "Stable Tag", schon wird es auch verteilt.
So mache ich es bei meinem Plugin immer und fahre damit bisher gut. (Eigentlich habe ich sogar noch einen Zwischenschritt drin, weil ich nicht direkt im wp.org-SVN entwickele, sondern in einem zweiten Google-Code-SVN, um durch blöde Fehler von mir nicht plötzlich doch eine neue Version rauszuhauen (wozu ein falscher "Stable Tag" reichen könnte).)
Deine bisherige Verfahrensweise funktioniert natürlich auch, ist aber (wie wir hier wohl erlebt haben) nicht robust genug gegenüber eventuellen Repository-Problemen (für die du natürlich nichts kannst). Damit meine ich nicht, dass du nicht immer Tags anlegst (das ist vollkommen legitim, man sozusagen nur die Vorteile von oben nicht - auch natürlich auch weniger nervige Arbeit), sondern dass das "Stable Tag" auf ein nicht existierendes Tag gesetzt ist (das müsste auch der Grund sein, warum der Link zu Version 1.0.2 hier nicht gefunden wird).
Schöne Grüße
Tobias
@Tobias: ich werde das in jedem Fall bedenken; wenn die Stable Tag sauber funktioniert, dann ist das ja gut und ich nutze es gern. Ich würde gern meine Ideen schon im SVN haben und nicht den Nutzern mitteilen. Insofern würde das meiner Arbeitsweise sehr nahe kommen.
Da hat sich etwas getan. Ich habe gerade auf einer frischen Installation die Update-Funktion getestet. Alles einwandfrei. Version 1.0.2 ist installiert und die Update-Benachrichtigung ist jetzt auch verschwunden, wie es sein soll.
Danke!
Hi Frank,
jap, dann ist die "Stable Tag"-Angabe auf ein existierendes Tag genau das was du brauchst. Du kannst wie gewohnt im Trunk entwickeln, aber der "Stable Tag" ist der, der ausgeliefert wird.
Schöne Grüße und nochmals danke für deine Entwicklungen!
Tobias
Ich danke für die Infos!
Frank, wenn sich im Blog meines Kunden nach der Adminer-Installation das Plugin nicht starten lässt (weißes Fenster), woran kann das liegen?
@Ramona: schwer zu sagen, eventuell eine alte Version? in allen Browsern?
Hallo Frank,
mir ist da was komisches aufgefallen. Wenn Adminer aktiv ist können sich bestimmte Benutzergruppen nicht anmelden. Mitarbeiter und Autoren können sich nicht einloggen. Da kommt dann das berühmte "Schummeln, was?". Auch wenn man als Autor eingeloggt ist und im anderen Browser als admin das Plugin aktiviert kriegt man als Mitarbeiter oder Autor ne Fehlermeldung und kann nicht weitermachen. Wenn du Adminer ausschaltest kannst Du nach F5 weiterarbeiten. Interessantes Phänomen!
@Susann: kannst du mal die neue Version testen - http://downloads.wordpress.org/plugin/adminer.zip
Ich habe etwas geändert und in meinem Test klappt alles; danke für eine Rückmeldung.
wie die Zeit vergeht ... getestet - funktioniert prima, danke.
Mir war das nicht gleich aufgefallen, weil ich das Plugin nur bei Bedarf aktiviere;-)
Hi Frank, vielen Dank für das tolle Plugin.
Soweit läuft alles rund, außer der Bereich Ereignisse in der Datenbank scheint ein Fehler auf zu weißen.
Dort steht das Ereignisse
Benutzer 'xxxxxxxxx'@'%' hat keine Zugriffsberechtigung f�r Datenbank 'dbxxxxxx'
Sprich. Der Benutzer mit dem gleichen Namen und der gleichen Datenbank hat keinen Zugriff?
Muss ich da noch was umstellen?
@Chris: das Plugin gibt nur Passwort/Username von WP durch, eventuell ist die dort nicht zulässig; da kann ich wenig zu sagen.
Im Rahmen einer größeren Aufräumaktion im Blog bin ich auf dein Plugin zu Adminer gestoßen - funktioniert 1A und erspart mir das phpmyadmin, klasse Tool, danke fafür.
Danke für das Plugin! Ich sehe Fehlermeldungen im Serverlog, eben mit der nagelneue Version 1.0.3 (hätte das Problem auch mit 1.0.2) und es scheint mir zu daß ein Zugriff auf css Datei fehlschlägt durch ein doppelten Schrägstrich Zeichen. Eine Zeile zum Beispiel vom Logdatei:
[02-Feb-2011 12:10:20] PHP Warning: filemtime() [function.filemtime]: stat failed for /path/to/public_html//adminer.css in /home7/nitaonli/public_html/wp-content/plugins/wp-minify/wp-minify.php on line 708Do you have also this problem, when you deactivate your plugin wp-minify? This css-file is only for Adminer inside the thickbox overlay and Adminer-Core use this file inside the iframe and the is the path correctly.
Zumindest hat sich da jemand schon mal Gedanken gemacht. Einer weiteres Plugin, welches ich ausprobieren muss ^^
Danke
When executing a raw SQL search, the backslashes added by WordPress GPC POST input processing are not being un-escaped by the plugin before execution. Should they be?
Example, SELECT * FROM `wp_options` WHERE `option_value` LIKE '%foo%'
it's being converted to
SELECT * FROM `wp_options` WHERE `option_value` LIKE \'%foo%\'
and throwing an error
Error in query: Syntax error near '\'%foo%\' at line 1
Thanks for your help
@Mark: thanks; i will see for an solution; i think WordPress add an filter to mask the ' . I hope, i can fix on the next version.
Help! the plugin is gone from wordpress.org!
I have a zip of it, so I can get around it and install from zip, but I think you should look into it. I heard that wordpress.org was going to start pulling plugins that hadn't been updated in more than two years, so maybe the problems with the version number described above had something to do with it.
@Sidney: yes, i have geting a warnig form wp.org, why i habe minified code in the plugin and now i have updated, the new release, all source is readable and also an small bugfix for use sql-queries in Adminer.