Problem mit plugin_staticpage

[MarcusJ.]

Ich habe grade von 1.0.2 auf 1.1-beta5 upgedated, in der Hoffnung, daß dann auch Quicksearch der statischen Seiten funktioniert.
Der Ärger fing schon an beim Update von event_staticpage von (IIRC) V3.36 auf V3.38.

Code: Select all

Warning: pg_query() [function.pg-query]: Query failed: ERROR: column "shownavi" of relation "serendipity_staticpages" already exists in /home/bofh/www.bogomips.de/s9y/include/db/postgres.inc.php on line 210
Error in ALTER TABLE serendipity_staticpages ADD COLUMN shownavi int4 default '1';
ERROR: column "shownavi" of relation "serendipity_staticpages" already exists

und noch ein Kilometer weiteres Gemeckere. Soweit noch harmlos und nur Warnings.
Statische Seiten funktionieren damit auch soweit

Aber was zum Verrecken nicht geht, ist die Installation des zugehörigen plugin_staticpages (V1.12). Wenn ich versuche, das Sidebarplugin zu installieren, fällt die Installation konsequent auf die Nase:

Code: Select all

Fehler: serendipity_plugin_staticpage:fd76f4d72158b4a1a1633f474fa6dbdc ()
DEBUG: Plugin serendipity_plugin_staticpage:fd76f4d72158b4a1a1633f474fa6dbdc not an object: .
Input: Array ( [adminModule] => plugins [pluginPath] => [install_plugin] => serendipity_plugin_staticpage [action] => [adminAction] => ) .

This error can happen if a plugin was not properly downloaded (check your plugins directory if the requested plugin was downloaded) or the inclusion of a file failed (permissions?)
Backtrace:
Installing plugin: Array ( [0] => serendipity_plugin_staticpage [1] => [2] => right [3] => 0 [4] => )
INSERT INTO serendipity_plugins (name, sort_order, placement, authorid, path) values ('serendipity_plugin_staticpage:fd76f4d72158b4a1a1633f474fa6dbdc', 6, 'right', '0', '')
No valid path/filename found. Aborting.
Classname serendipity_plugin_staticpage still does not exist. Aborting.
Loading plugin failed painfully. File not found?
No valid path/filename found. Aborting.
Classname serendipity_plugin_staticpage still does not exist. Aborting.

Logisch, beim insert fehlt ja auch offensichtlich der Inhalt für path. Das Plugin liegt allerdings ganz normal auf dem Server im serendipity_event_staticpage Ordner und ist verfügbar mit geeigneten Permissions.

Auf meinem öffentlichen System mit S9y 1.0.2 laufe ich nebenbei mit event_staticpage v3.37 und plugin_staticpage v1.12 in exakt das selbe Problem wie ich nun feststellen mußte. Mit einer älteren Version des event_staticpage Plugins ging das noch (ich meine 3.36, aber bin nicht ganz sicher, womit es zuletzt noch funktioniert hat, weil ich das sidebar plugin schon länger nicht mehr aktiviert hatte).

Also sowohl S9y 1.0.2 als auch 1.1-beta5 bekommen das sidebar plugin bei identischem Fehlerbild nicht mehr gebacken. 1.0.2 allerdings erst seit einer der neueren event_staticpage Versionen. php ist nebenei 5.1.6.

Hat jemand hier schon mal ähnlich abstruses beobachtet?

***Update***

Ich fand das so seltsam, daß ich vorhin noch weitergetestet habe und scheint ein Problem der aktuellen event_staticpage Version zu sein, da ansonsten mein Indianer und php noch die selben Versionen sind, mit denen das vor ein paar Wochen noch problemlos funktioniert hat.

Ich habe vorhin noch einmal eine jeweils frisch runtergeladene Version von s9y 1.0.1 und 1.0.2 sauber neu installiert - jeweils mit komplett neuer und leerer Datenbank - diese Versionen weil das mit beiden mal funktioniert hat.

Ich habe dann jeweils erst spartacus installiert, event_staticpage (v.3.38) und plugin_staticpage (v1.12) und sonst exakt nichts anderes gemacht. Nur ausschließlich diese Schritte. Hat soweit funktioniert.

Dann das Sidebar Plugin wieder deaktiviert und wieder neu angewählt.
Prompt fallen beide ansonsten klinisch reine und völlig unberührte Probeinstallationen derbe auf die Nase - mit genau dem oben bereits beschriebenen Fehlerbild.

Plugin laden geht genau einmal nach der frischen Installation und dann nie wieder.

Genau das hat aber mal mit einer älteren Pluginversion vor 2 Monaten fehlerfrei bei ansonsten identischer Umgebung funktioniert und ich vermute nun einen Bug innerhalb der Module.

Kann das hier jemand bei seiner Installation nachvollziehen?

[garvinhicking]

Hi!

Ich fürchte das erste Problem hängt mit PGSQL zusammen; staticpages ist eher mit MySQL entwickelt worden. Die Quicksearch klappt glaube ich auch nur mit MySQL zusammen, weil PGSQL ja keine Indexsuche bietet.

Was das sidebar-plugin problem angeht, das klingt sehr komisch. Denn sobald das Plugin einmal geladen wurde müsste die serendipity_plugin_staticpage.php im Verzeichnis serendipity_event_staticpage liegen und Spartacus diese Datei garnicht neu ziehen, weil sie ja schon vorhanden ist.

Die Fehlermeldung kommt jedoch von Spartacus, obwohl das garnicht aktiv werden dürfte.

Kannst du daher mal prüfen ob die genannte PHP-Datei bei Dir existiert, und ob sie korrekte Leserechte aufweist?

Viele Grüße,
Garvin

[MarcusJ.]

Das Plugin ist auch tatsächlich vorhanden

Code: Select all

ls -l serendipity_event_staticpage 
[...]
-rw-r--r-- 1 www-data www-data 94142 2006-11-13 18:45 serendipity_event_staticpage.php
-rw-r--r-- 1 www-data www-data 10427 2006-11-13 18:45 serendipity_plugin_staticpage.php
[...]

und es waren wie gesagt jetzt auch komplett frische Installationen, bei deren Installdialog auch auch alles in schönstem grün erstrahlte.

Kann man irgendwo noch die älteren Versionen von event_staticpage wieder runterladen (3.34 oder früher)? Ich würde die gerne nochmal manuell als Gegentest einwerfen, weil es halt damit mal funktioniert hat. So drückt mir ja spartacus jetzt überall nur noch die aktuelle Version rein und das verreckt hier unter allen Testszenarien auf allen Rechnern.

Das hier ist das Verenden des frischen S9y 101 beim Wiederaktivieren des Sidebar Plugins und bei 102 sieht es genauso aus:

Code: Select all

Fehler: serendipity_plugin_staticpage:f5c1c12fc0d53f1d7b09ad4667ebce53 ()
DEBUG: Plugin serendipity_plugin_staticpage:f5c1c12fc0d53f1d7b09ad4667ebce53 not an object: .
Input: Array ( [adminModule] => plugins [pluginPath] => [install_plugin] => serendipity_plugin_staticpage [action] => [adminAction] => ) .

Please report this bug. This error can happen if a plugin was not properly downloaded (check your plugins directory if the requested plugin was downloaded) or the inclusion of a file failed (permissions?)
Backtrace:
Installing plugin: Array ( [0] => serendipity_plugin_staticpage [1] => [2] => right [3] => 0 [4] => )
INSERT INTO serendipity_plugins (name, sort_order, placement, authorid, path) values ('serendipity_plugin_staticpage:f5c1c12fc0d53f1d7b09ad4667ebce53', 9, 'right', '0', '')
No valid path/filename found. Aborting.
Classname serendipity_plugin_staticpage still does not exist. Aborting.
Loading plugin failed painfully. File not found?
No valid path/filename found. Aborting.
Classname serendipity_plugin_staticpage still does not exist. Aborting.

Das event_staticpage Plugin läßt sich nebenbei einwandfrei de- und reinstallieren.

[garvinhicking]

Hi!

Also wie erwähnt, sobald das Plugin lokal vorhanden ist, darf Spartacus das garnicht mehr versuchen downzuloaden.

Wenn das spartacus trotz vorhandenem Plugin versucht, ist etwas schief mit der Plugin-Datei, denn das s9y framework denkt dann die PHP-Datei ist garnicht vorhanden.

Also wenn Du auf das statische Seitenleistenplugin klickst, sagt dir spartacus jedesmal dass es gedownloadet werden soll? Wie sieht der Button neben der Installation aus? Mit Disketter oder mit Pfeil?

Alte Versionen des Plugins kannst du nur direkt über das CVS Repository (http://php-blog.cvs.sourceforge.net/php ... taticpage/) runterladen.

Bist Du sicher dass Du von serendipity 1.1-beta das spartacus plugin udn alle anderen dateien vollständig aufgespielt hast? Nicht dass von einer älteren version einige dateien noch vorhanden sind.

Viele Grüße,
Garvin

[MarcusJ.]

Du sagst also, die Fehler kämen von Spartacus und da würde bereits was falschlaufen und nicht beim eigentlichen Modul, richtig?

Der Button zeigt das Disksymbol und nicht das Downloadsymbol!
Deshalb bin ich da eigentlich auch gar nicht erst drauf gekommen, daß da Spartacus noch am Werk ist.

Ich habe zum Testen komplett frische 1.0.1er und 1.0.2er Installationen aufgespielt mit komplett neuer und leerer Datenbank. Absolut nichts dran gemacht, außer die Pluginverwaltung angefaßt und nach Spartacus noch die staticpages Module aktiviert. Die scheitern beide.

Die 1.0.2er Version meines Produktivsystems scheitert und die von 1.0.2 auf 1.1-beta5 upgedatete Version meines Testsystems scheitert. Mittlerweile vier Installationen, zwei Rechner. Ansonsten läuft aber alles einwandfrei. Mir ist jedenfalls sonst nichts aufgefallen. Andere Seitenleistenplugins kann ich völlig nach Herzenslust deaktivieren und aktivieren, soweit ich das bisher probiert habe. Nur das der Staticpages ist überall dasselbe Problem.

Aber was ich noch festgestellt habe und was evtl. noch hilfreich ist: Da es ja bei den ganz frischen Installationen genau einmal funktioniert hat, das Sidebarplugin zu installieren, habe ich jetzt mal ganz einfach das ganze serendipity_event_staticpage-Verzeichnis, also beide Plugins nach Deaktivierung in den Eimer gehauen.
Spartacus holt das dann bei erneuter Anwahl die Module neu und man kann das Sidebarplugin wieder genau einmal aktivieren. Weitere Versuche von Ab- und Anwahl scheitern dann zwar wieder wie gehabt, aber so bekomme ich das Sidebarplugin wenigstens notfalls wieder aktiviert, ohne die ganze Installation plätten zu müssen.
Muß ich halt das Modulverzeichnis als fiesen Workaround notfalls händisch weglöschen und neu saugen lassen bis der Bug gefunden ist.

Aber irgendwie sieht das aus, als würde Spartacus bei dem einen Modul verpeilen, das es das vorher schon mal gesaugt hat. Wo wird denn der Status in der db hinterlegt, dann grabe ich mal direkt in der Datenbank?

***update***

Ich habe mir jetzt noch mal die Mühe gemacht, auf dem Testrechner noch eine weitere frische Installation von s9y 1.0.2 in Betrieb zu nehmen
*ächz*.
Ich habe dafür extra mysql installiert und das dagegen laufen lassen.
Kein Problem. Tut einwandfrei. Das sidbar plugin kann ich sooft de- und reaktivieren wie ich will.
Da der einzige Unterschied zu den anderen Installation ausschließlich die Datenbank als Backend ist, muß da IMHO irgendwo ein böser Bug in Bezug auf postgres sein. Irgendwas in der Pluginhandhabung ist wohl leider rein mysql-only gestrickt.
Nur leider ist mysql für mich absolut keine Option auf dem Produktivsystem.

Wie kann ich den Bug wohl näher einkreisen?

[garvinhicking]

Hi!

Leider habe ich hier keine einfache Möglichkeit derzeit pgsql zu installieren (müsste php komplett neu kompilieren). Wäre es dir möglich mir FTP Zugriff zu einer Test-Installation zu geben so dass ich mir das ansehen kann?

Ich bin sicher dass es ein einfacher Fehler ist der einfach nur wieder mit fehlenden ' Zeichen in pgsql zusammenhängt.

Wenn Du mir die Daten geben willst, schreib mir bitte eine PM.

Viele Grüße,
Garvin