Beiträge von Ammaletu

Hm, tut mir Leid, ich sehe keinen Fehler in der Datei. Keine Ahnung, was für ein Problem Dein Browser damit hat. Hast Du es mal mit einem anderen Browser bzw. einem Löschen des Caches probiert?

Zitat

Ich habe bei meinem Confixx mal nachgeschaut bei den Servermeldungen. Dort steht "Webalizer Statistiken aktiviert." Und zwar heute nachmittag. Kann das etwas damit zu tun haben?

Würde ich nicht vermuten, aber mit Sicherheit kann man es natürlich nicht sagen. Hast Du die PHP-Version da irgendwo gefunden? Gibt es eine phpinfo-Seite oder so?

Zitat

Auch war ich auf der Seite, die Du mir als Link gegeben hast. Ich wollte das dann auch so ändern wie Du gemeint hast, aber in meiner widget.php gibt es so etwas nicht.

Doch, es sei denn Du verwendest eine andere WP-Version. In 2.8.6 sieht Zeile 897 der Datei so aus:

if ( ( $callback && isset($wp_registered_widgets[$widget]['callback']) && $wp_registered_widgets[$widget]['callback'] == $callback ) || ( $id_base && _get_widget_id_base($widget) == $id_base ) ) {

Wenn ich den Fehler jetzt richtig verstehe, könnte es helfen, das so zu ändern:

if ( ( $callback && isset($wp_registered_widgets[$widget]['callback']) && $wp_registered_widgets[$widget]['callback'] === $callback ) || ( $id_base && _get_widget_id_base($widget) === $id_base ) ) {

Habe ich aber nicht getestet, ist nur eine Vermutung basierend auf oben ergoogelten Informationen. Da ich dazu aktuell nichts im Trac finde, bin ich auch nicht sicher, ob das wirklich ein WP-Problem ist. Vielleicht tritt das auch nur auf mit Widgets, die speziell kompliziert sind?!

Zitat

Auch komischerweise diese Fehlermeldung, die gezeigt wird ist darin nicht enthalten.

Warum sollte sie auch, es ist ja ein PHP-Fehler. Der wird von PHP generiert und ausgegeben, weil es einen Fehler im Programm gefunden hat.

Zitat

Oder kann es etwas damit zu tun haben, daß ich gestern ein Plugin (wp-downloadcounter.1.1) installiert habe?

Könntest Du ja sehr leicht selber überprüfen. ;-) Da der Fehler aber in einer Core-Datei auftritt, würde ich eher nicht drauf tippen. Kann natürlich sein, dass das Widget, welches den Fehler auslöst, aus dem Plugin stammt.

Zitat

Ach ja: ich würde gerne diese Line 897 ändern, aber wie komme ich zu dieser? Muß ich jetzt alle Zeilen zählen?

Jeder gute Editor bietet Dir eine Anzeige der Zeilennummern. Eigentlich alle schlechten, die ich kenne, auch. Du musst ggf. die Anzeige der Statusleiste aktivieren. ;-)

Nur mal als Update für alle, die den Thread vielleicht noch verfolgen oder wiederfinden: Wie es aussieht, lagen die Probleme zum einen an falschen Pfaden in der DB (keine Ahnung, wie die da reinkamen) und zum anderen an einem defekten/inkompatiblen Theme. Also wer ähnliche Probleme hat: Im Backend mal auf die Pluginseite klicken (dann werden eventuell defekte Plugins deaktiviert) und genauso auf die Themeseite (dann wird ein defektes Theme möglicherweise deaktiviert). Um ins Backend zu kommen, wenn die Pfade falsch eingetragen sind, kann man WP_SITEURL und WP_HOME in der wp-config.php definieren.

Wenn Du nur ein anderes Stylesheet pro Kategorie haben möchtest, siehe z.B. hier:
http://forum.wordpress-deutschland.org/design/43297-v…es-pro-kat.html

Wen Du tatsächlich komplett andere Templates brauchst 8also andere HTML-Struktur, andere Inhalte), erstelle Dir doch einfach Themedteien dafür. "category-123.php" wird von WP automatisch für Kategorie mit der ID 123 aufgerufen. Die IDs findest Du im Backend, in der Kategorieübersicht, wenn Du die Maus auf die Links hältst, stehen sie in der Statuszeile des Browser am Ende der URL. Als Vorlage kannst Du die archive.php nehmen, wenn Dein Theme eine hat.

Soweit ich weiß, kannst Du in den Optionen eingeben, wo der Upload-Ordner liegen soll (Einstellungen > Verschiedenes). Achtung: Probiere das nur mit einem kompletten Backup aus! Besser noch wäre es, das zuerst an einer lokalen Kopie der Seite zu probieren. Ich gehe davon aus, dass Du die Dateien dann per Hand (=per FTP) auf dem Server ins neue Verzeichnis verschieben musst (kann ich mich aber irren, vielleicht macht WP das ja auch selber). So oder so musst Du dann alle vorhandenen Beiträge editieren und den Pfad anpassen. Dafür gibt es glaube ich ein "Suchen und Ersetzen"-Plugin, das Dir da viel Arbeit abnimmt. Außerdem gilt der neue Upload-Pfad natürlich für alle Medien, die Du hochlädst, nicht nur für Fotos.

Um den Pfad außerhalb des WP-Ordners zu kriegen, müsstest Du eventuell "../meine-fotos" nehmen. Aber auch das ist jetzt nur geraten von mir. Wie gesagt, Backup (Dateien + DB) und am besten nicht live auf dem Server ausprobieren.

Das Plugin zieht aber einfach nur einen Feed und macht daraus Artikel, oder? Die Darstellung des Bildes in der Sidebar müsste damnach aus dem Theme stammen. Da wäre also die Frage, wo kriegt das Plugin das Bild her und was müsste man an den Beiträgen ändern, damit das Bild nicht im Artikel-Inhalt angezeigt wird. Wie ist das denn bei Deinen eigenen Beiträgen -- wie bindest Du das Bild da ein?

Was heißt "öffnet sich nicht"? Wenn Du auf den Link im Menü klickst, passiert gar nichts? Der Browser beginnt zu laden, die alte Seite bleibt aber stehen? Es wird nur eine weiße Seite angezeigt (<-- anklicken!)? Der WP-Rahmen wird angezeigt, aber kein Inhalt? Werden im Browser JavaScript-Fehler angezeigt?

Du kannst die Styles entweder direkt im Header ausgeben oder in eine eigene Datei packen. So oder so müsste das über den Hook im Header eingebaut werden.

Bedenke aber auch jeden Fall, dass die meisten aktuellen Themes schon Styles für Widgets mitbringen. Du kannst eher nicht erraten, wie die aussehen und solltest deswegen versuchen, dem Theme dahingehend nicht in die Quere zu kommen.

Erste Regel bei Fehlermeldungen: Abtippen und in Google danach suchen. Das führt zielstrebig zu diesen Infos:
http://www.bigroom.co.uk/blog/php-nesti…sive-dependency

Kann es sein, dass Dein Provider Dein Package auf PHP 5.2 aktualisiert hat? Als Workaround fürs erste solltest Du an der angegebenenStelle in der Datei mal schauen, ob da ein "==" steht, das Du durch ein "===" ersetzen könntest. Ich will ja mal hoffen, dass das in 2.9 behoben wird.

Siehe auch:
http://faq.wordpress-deutschland.org/wie-kann-ich-w…r-installieren/

Auf dem eigenen Rechner ziehe ich normalerweise vor, weil man da volle Kontrolle über das Logging hat und sich die Dateien schneller bearbeiten lassen als per FTP. Falls Du den Testblog online einrichten willst, nimm einen anderen Tabel-Prefix fürs Testblog (z.B. "wptest_", einzutrageh in der wp-config.php).

Also wirklich was erkennen kann man auf dem Screenshot nicht, aber es sieht so aus, als würde sich das Fensterchen schon öffnen, nur eben leer. Stimmt das? So oder so, schaue zuerst mal, ob im Browser JavaScript-Fehler angezeigt werden und dann ggf. ob auf dem Server PHP-Fehler geloggt werden.

jottlieb: Zu dem Thema könnte man eigentlich mal einen FAQ-Eintrag verfassen, oder? Ist ja wirklich eine "oft gestellte Frage". Beim kurzen Durchschauen eben habe ich dazu nichts gefunden.

felix13372: Das Thema hatten wir wie gesagt schon oft. Wieso das durch ein Update passieren sollte, weiß ich zwar nicht, aber es wird wohl dran liegen, dass die Adressen, die in den WP-Optionen eingetragen sind, nicht stimmen.

Zitat

1.bei der Anweisung stand delete und nach dem ich das gelöscht habe, war die meldung auch weg.

Ok, das bezieht sich dann vielleicht auf was anderes. Du hattest weiter oben zwei Screenshots der .htaccess angehängt, welche das illustrieren sollten (oder?). Die sehen für mich gleich aus. Sicher, dass Du das nicht aus versehen zweimal das gleiche Bild ist? Oder sehe ich bloß nicht, was Du da geändert hast? :-)

Zitat

wenn ich auf den uninstallscript link klicke, dann kommt ne Warnung.

Ja, weil zur Sicherheit vor dem Deinstallieren eine Änderung an einer Datei des Plugins nötig ist. Damit das nicht aus Versehen macht bzw. jemand anderes einem den Cache ausknipst. Wie es genau geht, steht in der readme-Datei, aber das brauchst Du ja dann hoffentlich nicht, wenn wir das hier noch hinkriegen.

Zitat

4.Wo ist der Backend Editor???

Du kannst Themedateien im WP-Backend unter Design > Editor bearbeiten. Ich hatte angenommen, dass Du die .htaccess dort gesucht und nicht gefunden hast!?

Zitat

Diese WP-Supercache Block, muß ich den auch wieder im FTPServer ändern? Wo ist der ? ich suche und suche.....

In der .htaccess-Datei, und ja, die Datei per FTP ziehen, bearbeiten und dann wieder hochladen. Aufpassen, dass Windows sie Dir nicht umbenennt. das ist manchmal etwas zickig mit Dateien, die nur eine Dateiendung haben und keinen Namen (aus Windows-Sicht).

Schau in Deinen Screenshot der .htaccess-Datei, da siehst Du die beiden mit BEGIN und END gekennzeichneten Blöcke. Die sind genau falsch herum, die SuperCache-Anweisungen müssen zuerst kommen.

Das Theme nutzt an der Stelle die Standard-WP-Funktion wp_list_categories, welches das so ausgibt. Der Text wird also wohl in der normalen Sprachdatei von WP stehen. Die kannst Du ändern, das musst Du dann aber bei jeder neuen Version wieder machen, was schnell nervt.

Du kannst die Ausgabe im Theme abschalten. Suche Dir die Datei /inove/templates/header.php raus und gehe zur Zeile 32. Die sollte so aussehen:

wp_list_categories('title_li=0&orderby=name&show_count=0');

Die wäre zu ändern in:

wp_list_categories('title_li=0&orderby=name&show_count=0&use_desc_for_title=0');

Ansonsten kannst Du im Backend auch einfach für die Kategorien einen Beschreibungstext eingeben (unter Artikel > Kategorien). Der würde dann anstelle des Standardtextes benutzt.

knutwilli: Bist Du sicher, dass es bei Dir auch an Wp SuperCache liegt? Falls nicht, kannst Du dafür nicht einen eigenen Thread aufmachen?! Das wird sonst übel verwirrend, wenn wir hier zwei Gespräche durcheinander führen. ;-)

Stephi: Meine Antwort von gestern ist irgendwie im Nirwana verschwunden. Habe ich vielleicht doch aus Versehen vor dem Antworten geschlossen. :-/

Zitat

HAbe mal einen screenshot angehangen, ist der haken bei cache rebuild richtig?

Würde ich erstmal ohne probieren. Das ist scheinbar für Seiten mit speziell hohem Traffic gedacht.

Zitat

und weiter unten im Screenshot steh genau wie Du gesagt, hast, daß ich was aus der htaccess löschen muß

Bist Du sicher? Du solltest das eigentlich einfügen, dachte ich, nicht löschen.

Zitat

Wegen dem unistall-script, ich weiß von nix*peinlich*

Ist wie gesagt auf der Optionsseite verlinkt, such nach "uninstall". Aber wir kriegen das ja hoffentlich noch zum Laufen.

Zitat

Vielen Dank nochmal so zwischendurch, bin begeistert über die Hilfe.

Kein Problem. Ist eine gute Gelegenheit, mir das Plugin mal näher anzuschauen.

Zitat

ich habe die .htaccess gefunden, unglaublich, aber wenn man nicht im FTP sucht, wird man wohl nur unglücklich beim suchen:wink:

Ja, die Datei steht wohl nicht zur Verfügung über den WP-Backend-Editor.

Zitat

Nun habe ich das rausgelöscht was mir im WP gesagt worden ist, aber da bringt es irgendwie noch nicht

Ich sehe da auf Anhieb keinen Unterschied, aber Du musst auf jeden Fall den WP-Super-cache-Block nach oben setzen. Sonst kann es nicht gehen. ;-)

Also alles zwischen und inlcusive "# BEGIN WPSuperCache" und "# END WPSuperCache" an den Anfang der Datei setzen. Probier das bitte mal. Wenn es dann immer noch nicht geht, müssten wir weiterüberlegen.

Nimm das auf jeden Fall ernst und gehe fürs erste davon aus, dass es an WP liegt, wenn Du keine andere Lücke findest. Zum Stichwort "WordPress gehackt" sollte Google oder die Forensuche Dir eine Menge Tips ausspucken. Am besten wäre es natürlich, wenn Du die genaue Lücke identifizieren könntest. Sichere also ggf. den aktuellen Stand des Webspaces auf Deinen lokalen Rechner, ehe Du aufräumst.

Also zuerstmal: WP Super Cache ist kein Plugin, das man einfach anschalten und vergessen kann. Man sollte sich zumindest die Zeit nehmen, die Doku zu lesen und es korrekt einzurichten. Ohne ein gewisses Verständnis, wie es funktioniert, könnte es bei Problemen schwierig werden. Es lohnt sich aber; zumindest soweit ich gelesen habe, soll es die Seitenauslieferung sehr beschleunigen.

Wenn Du WP Super Cache deinstalliert hast und das auch so lassen willst, musst Du soweit ich das verstanden habe, trotzdem die .htaccess anpassen. Darin wird auf die gecachten Dateien verwiesen. Die .htaccess liegt immer im obersten Verzeichnis der WP-Installation. Wenn es sie nicht gibt, benutzt Du vermutlich die Standard-Permalinkstruktur. Momenbt, ich schaue mal... Ja, sieht so aus als hättest Du noch keine Permalinks eingestellt. Wenn es die Datei also nicht gibt, ist das vielleicht auch schon der Grund, wieso WP Super Cache nicht funktioniert hat (siehe unten). Falls es sie gibt und nur dann sollte der Inhalt so aussehen:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /testblog/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /testblog/index.php [L]
</IfModule>


# END WordPress

Wobei die Pfade dann natürlich auf Deine Installation zeigen müssen. Den Block von Wp Sucper Cache würdest Du erkennen, das ist relativ viel, was darüber stehen müsste.

Schau dann außerdem in die wp-config.php. Bei meinem Test eben hat das Plugin diese Zeile eingefügt:

define('WP_CACHE', true); //Added by WP-Cache Manager

Das dann auf "false" stellen oder löschen. Die gecachten Dateien selber müssten unter wp-content/cache gespeichert sein.

Im übrigen sehe ich auf der Optionsseite gerade einen Link auf ein Uninstall-Script. Hast Du das benutzt? Ich würde vermuten, dass WP Super Cache dann selber hinter sich aufräumt. Schau dazu am besten in die readme.php, es erfordert aus Sicherheitsgründen eine kleine Modifikation an einer Plugindatei. Dort ist auch die manuelle Deinstallation beschrieben (super, hätte ich ja nicht so viel tippen müssen *g*).

Wenn Du WP Super Cache einsetzen willst, musst Du Dich ein wenig damit beschäftigen. Aktiviere das Plugin und gehe auf die Optionsseite. Schalte es auf "On". Mir wurden danach als zweite Zwischenüberschrift ein Hinweis auf "Missing Apache Modules" ausgegeben, zusammen mit weiteren Hinweisen dazu. Falls das bei Dir auch kommt, sag Bescheid, was genau ausgegeben wird, dann kann man da weitersehen.

Darunter steht in einem gelben Kasten ("Mod Rewrite Rules"), was man manuell in seine .htaccess-Datei kopieren soll, über die WordPress-Regeln. Ohne diese Änderung wird das Cachen wohl gar nicht funktionieren, eventuell war das ja auch das Problem bei Dir.

Noch weiter unten auf der Optionsseite kannst Du dann einstellen, was gecacht werden soll. Du müsstest Dir dann außerdem Gedanken über dynamische Inhalte z.B. in Deiner Sidebar machen, die natürlich auch mit gecacht werden.

Freut mich, dass jetzt alles stimmt. Das ist manchmal etwas mühsam, aber man fährt damit echt besser. Wenn später mal Probleme auftauchen, kann man im Validator wenigstens ohne viel Suchen sehen, wo die herkommen. :-)

Die Kategorien sind Kategorien, keine Seiten. Wenn Du bei allem außer den statischen Seiten "Home" hervorheben willst, kannst Du natürlich die Abfrage etwa so gestalten:

if (is_home() || (!is_page() && !is_404()))

Dann wäre es hervorgehoben wenn es die Startseite ist und bei allem anderen außer statischen Seiten und der 404-Seite.

Also ich habe mir das Theme jetzt mal in meinem Testblog installiert und dort funktioniert das Paging über WP-PageNavi problemlos. Ich wüsste so auf Anhieb also nicht, wieso es bei Dir nicht gehen sollte. Ok, es kann immer an einem anderen Plugin liegen. Was läuft denn da noch so? Wenn das gleiche mit dem Theme und ohne andere Plugins auch passiert, kannst Du mir das Theme natürlich mal zippen und per Mail schicken. Vielleicht hast Du da ja doch noch was verändert? Oder anders herum: Passiert das auch, wenn Du mal probeweise auf das Default-Theme umschaltest oder geht das Paging dann (musst Du da natürlich vorher auch einbauen, in die archive.php zum Beispiel)?

Aufgefallen ist mir ansonsten, dass das Theme relativ alt ist. Keine Ahnung ob Du damit auf Dauer glücklich wirst. Aber funktionieren tut es im Moment noch.