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

Danke

[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

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?

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!

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

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