Adminer für WordPress

bueltge.de [by:ltge.de] wird von Frank Bültge geführt, administriert und gestaltet. Alle Inhalte sind persönlich von mir ausgewählt und erstellt, nach bestem Gewissen und Können, was die Möglichkeit von Fehlern nicht ausschließt.

Kommentare

  
  1. ovidiu sagt:

    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.

  2. webe sagt:

    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.

  3. Sven sagt:

    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

  4. Wolfgang sagt:

    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.

  5. Danke Frank für das Plugin! Ich wollte es gleich mal testen, bekomme aber leider folgenden Fehlerhinweis:

    Fatal error: Cannot redeclare pagination() (previously declared in /.../wp-content/plugins/pagination.php:10) in /.../wp-content/plugins/adminer/inc/adminer-2.0.0.php on line 89

    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.

  6. Ramona sagt:

    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?

  7. The Frosty sagt:

    You keep forgetting to update the version number in the file so it stays at "update needed"

  8. Tobias sagt:

    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.

  9. linguasite sagt:

    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.

  10. Ramona sagt:

    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');

  11. Tobias sagt:

    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.
    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 🙂 ), schreib einfach "Stable tag: trunk" und gut ist.

    Schöne Grüße
    Tobias

  12. linguasite sagt:

    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.

  13. linguasite sagt:

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

  14. Tobias sagt:

    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 entfernt 🙂 )
    Zusä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

  15. Tobias sagt:

    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

  16. linguasite sagt:

    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.

  17. @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)

  18. Tobias sagt:

    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.

  19. linguasite sagt:

    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!

  20. Tobias sagt:

    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

  21. Ramona sagt:

    Frank, wenn sich im Blog meines Kunden nach der Adminer-Installation das Plugin nicht starten lässt (weißes Fenster), woran kann das liegen?

  22. Susann sagt:

    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!

  23. Susann sagt:

    wie die Zeit vergeht ... getestet - funktioniert prima, danke.
    Mir war das nicht gleich aufgefallen, weil ich das Plugin nur bei Bedarf aktiviere;-)

  24. Chris sagt:

    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?

  25. Christian sagt:

    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.

  26. 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 708

    • Do 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.

  27. Tony sagt:

    Zumindest hat sich da jemand schon mal Gedanken gemacht. Einer weiteres Plugin, welches ich ausprobieren muss ^^

    Danke

  28. Mark Kelnar sagt:

    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

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

© 2016, since 2005 bueltge.de [by:ltge.de] · Theme is built by ThemeShift