Beiträge von Ammaletu

siehe die FAQ: »Fatal error: Allowed memory size of *** bytes exhausted?« ? « WordPress Deutschland FAQ

Ich kann mich irren, aber sind 16 MB nicht etwas wenig? Frage ggf. Deinen Provider mal. Alternativ kann es helfen, sich von Plugins zu trennen, die speziell viel Speicher fressen.

Das liegt daran, dass die jQuery-Bibliothek nicht gefunden wird. Da die im Kern von WordPress enthalten ist, sollte das eigentlich nicht passieren. Vorstellen könnte ich mir folgendes: Beim Laden auf den Server ist was schief gegangen (kommt öfter vor als man meinen sollte). Ggf. noch mal mit einem anderen FTP-Programm probieren. Oder ein anderes Plugin pfuscht da rein, z.B. durch Umdefinieren der Variablen, die jQuery benutzt. Möglich, aber sieht von der Fehlermeldung her eigentlich nicht so aus, glaube ich. Du könntest aber ja trotzde mal alle Plugins ausschalten testweise. Ansonsten könntest Du das Theme mal noch testweise zum Standardtheme wechseln und schauen, ob es damit geht. Ebenfalls könnte es helfen, mal zu schauen, ob beim Laden der Seite irgendwelche 404-Fehler kommen (z.B. mit dem "Live HTTP Headers" AddOn für Firefox). Das würde dann für Theorie 1 sprechen (Fehler beim Upload auf den Server).

Also Punkt zwei wäre IMHO einfach ein Text-Widget. Schau Dir das mal unter Design > Widgets an. Mit minimalen HTML-Kenntnissen kriegst Du da auch einen mailto-Link problemlos rein (wobei ggf. die Frage des Spamschutzes wäre?!).

Punkt 1 könnte man auch mit einem Text-Widget machen, da kannst Du ja auch das HTML für Bilder einfügen. Oder schwebt Dir da noch eine weiterführende Automatik vor?

Zu Punkt 3 kann ich gerade nichts sagen. Bietet Coppermine keine Unterstützung für sowas?! Ich weiß, dass es Plugins gibt, die beide System integrieren, habe mir das aber leider noch nicht selber anschauen können...

Ok, da das Bild komplett per Stylesheet eingebunden ist, musst Du es wohl doch mit der ganz oben zitierten Variante per JavaScript verlinken. Ersetz mal die Anführungszeichen, dann sollte das passen.

Aber andere Sache: Schau mal in den Quelltext Deiner Seite. Gleich nach dem Body-Tag steht eine lange Liste an merkwürdigen Links (in der Seite selbst nicht angezeigt). Falls Dein Blog nicht irgendwie für Hotels, Online-Casinos und anderen Krempel werben soll, würde ich sagen, da hat jemand was eingeschmuggelt!?

weiße Seite = PHP-Fehler in 9 von 10 Fällen. Hast Du ins Errorlog geschaut?

Hat sich bei dem Umzug der Pfad auf dem Server geändert? Falls ja, hast Du alle Vorkommen des alten Pfades in dem DB-Dump ersetzt bevor Du ihn auf dem neuen Server importiert hast?

Hm, viel fällt mir nicht dazu ein, aber so als Idee: Turbo-Funktion ausschalten falls sie aktiviert ist, Browser-Cache leeren, ggf. mal testweise aus- und wieder einloggen. Im Browser auf JavaScript-Fehler achten, ggf. auf dem Server mal ins Errorlog schauen.

Zum einen: Soweit ich weiß ist die Verwendung von externer Blog-Software per default abgeschaltet. Das wurde in einem der letzten Updates geändert, früher war das immer angeschaltet, kann sein dass das mit dem Sprung zu 2.7 war. Vergewissere Dich, dass das in den Optionen angeschaltet ist.

Und zum Fehler 500: Das ist ein Sammelbegriff für beliebige interne Fehler. Der genaue Wortlaut der Fehlermeldung sollte in einem Errorlog zu finden sein, ohne den kann man dazu nicht viel sagen. Wo Fehler bei Dir auf dem Server geloggt werden, kann Dir ggf. der technische Support Deines Hosters sagen.

In dem Link fehlt nur das HTTP. Ok, habe gerade mal den aktuellsten Artikel zu kommentieren versucht und kriege dort auch die "Der Beitrag wurde entfernt"-Meldung. Das ist ja wirklich merkwürdig.

Spontan fällt mir auf, dass ich z.B. an Post 850 kommentiere (http://www.opensuse-lernen.de/?p=850), dann aber bei Post 16 lande (http://www.opensuse-lernen.de/?p=16&cpage=1#comment-71)?! Die Meldung kommt dann vermutlich, weil die ID 16 nicht zu einem Beitrag gehört, der anschaubar ist, könnte ich mir zumindest vorstellen.

Ich habe jetzt nicht die zeit, das komplett zu ende zu denken, aber da ist irgendwo der Wurm drin, und ich würde vermuten, dass entweder ein Plugin reinpfuscht oder es an der Integration der neuen PagedComments liegt. Kann dabei vielleicht was schief gelaufen sein im Theme?

Ich würde an Deiner Stelle erstmal eine Kopie des Blogs lokal mit XAMPP installieren (siehe FAQ) und schauen, ob es dort auch auftritt. Falls ja, kannst Du testweise mal auf ein Theme umschalten, das nicht die Paged Comments enthält (Default Theme?) und alle Plugins mal deaktivieren. Vielleicht lässt sich so die Ursache auch schon eingrenzen.

Ja, sieht super aus so. Danke! :-)

Hm, nein, mir ist das nicht wirklich klar. Oben in Deinem Beispiel hast Du eine simple Liste ohne weitere Einrückungen gepostet. Wenn das nicht ginge, hätte ich auf ein Stylesheet-Problem getippt, was sich mit einem Link zur betroffenen Seite viel besser lösen lässt. Wenn normale Listen gehen, verstehe ich noch nicht, was Du möchtest. Einen Listenpunkt noch weiter einzurücken sollte ebenfalls gehen (das wäre dann halt eine Liste in einer Liste), es sei denn, es liegt wieder an Deinem Stylesheet.

Hm, dann ist es entweder ein wählerischer Wurm oder Du hast das Problem zwischenzeitlich gelöst. ;-) Ich sehe meinen Testkommentar jedenfalls:
OpenSuSE-lernen.de Post Topic Filesharing mit Frostwire

Habe ich eben mit FF3 unter Win XP abgegeben. Den kannst Du im übrigen löschen.

Zitat

Also nachdem sich Wordpress einfach verabschiedet hatte und nur noch Fehler 500 ausgab,

Wenn das Problem auftrat, ohne dass Du etwas am Theme oder Plugins geändert hast, kann es auch sein, dass Dein Provider etwas geändert hat. In dem Fall hilft das Einspielen eines Backups gar nichts.

So oder so heißt Fehler 500 dass ein interner Fehler aufgetreten ist. Wenn Dein Webspace sinnvoll eingerichtet ist, sollte sich der Fehler in einer Logdatei wiederfinden. Wo die zu finden ist, kann Dir ggf. Dein Provider sagen. Mit dem genauen Wortlaut der Fehlermeldung kann man dann die Ursache dafür sicher finden.

Das Einfügen einer Liste geht natürlich. Falls Dein Theme die Liste nicht wunschgemäß formatiert ausgibt, wäre das ein leicht zu lösendes Stylesheet-Problem. Gib uns doch ggf. mal einen Link auf einen Beispiel-Beitrag.

Ich habe mal einen Vorschlag zu machen bzw. eine Bitte. Das mag wie Kleinkram wirken, aber es nervt mich schon sehr lange. ;-)

Und zwar: Könnte man auf der FAQ-Übersichtsseite mal die Listenpunkte so formatieren, dass sie wie Listenpunkte aussehen, also mit einem Kästchen oder was auch immer davor? Ok, wenn ich mir den Quelltext so anschaue müsste man erstmal Listenpunkte einfügen, die li-Tags fehlen offenbar, was die Seite obendrein nicht valide macht.

Na, jedenfalls finde ich den Textbock momentan sehr störend. Man sieht einfach auf den ersten Blick nicht, wo eine Frage anfängt. Das Auge hat quasi nichts zum Festhalten. Ideal wären also Listenpunkte und ein minimaler Abstand zwischen den Einträgen.

In der Regel komme ich nämlich auf die Seite, um den Link zu einem bestimmten Eintrag rauszufischen, und wenn ich nicht mittlerweile wüsste, dass ich nach dem Stichwort "heimisch" suchen kann, würde das immer ewig dauern, den zu finden. ;-)

Für alle Suchenden, die hier vielleicht landen: Nach dieser Anleitung in den FAQ sollte das problemlos klappen:
Wie kann ich WordPress auf meinem heimischen Rechner installieren? « WordPress Deutschland FAQ

Weil wir es gerade in einem anderen Thread hatten: Wenn Du das Revisions-Feature von WP nicht ausschaltest, bekommst Du auch auf dem Server keine fortlaufenden IDs hin, weil einige der IDs immer für die älteren Versionen eines Beitrags verwendet werden.

Ansonsten könntest Du probieren, den lokalen Blog über die Export-Funktion von WP zu exportieren und auf dem Server wieder zu importieren. Ich bin mir aber nicht sicher, ob darüber alles 1:1 übernommen wird. Schlimmstenfalls fügst Du auf dem Server eine DB-Kopie ein, löschst dort alle Beiträge, Kommentare und Kategorien und fügst das dann per Import ein. Das könnte gehen, musst Du aber ausprobieren (ggf. mit entsprechenden Backups).

Im ersten Codeschnipsel wären die typographischen Anführungszeichen ggf. durch gerade Anführungszeichen zu ersetzen, sonst kann das nicht klappen. Darüber hinaus finde ich es nicht sinnvoll, einen Link über Javascript zu bauen wenn es auch ein einfacher Link tut. ;-)

Am einfachsten wäre es, wenn Du uns einen Link auf die Seite geben kannst. Dann kann man einfach mal schauen, warum da etwas verschoben ist, und es müsste sich schnell eine Lösung finden lassen.

Hm, da war ich wohl etwas voreilig. Den entsprechenden Code habe ich für Java vorliegen, nach PHP habe ich das wohl noch nicht übersetzt oder ich finde das Projekt dazu gerade nicht wieder. Willst Du das eigentlich nur beim Aufruf der Startseite haben? Dann würde ich vielleicht mal suchen ob ich eine .htaccess-basierte Lösung dafür finde. ... Ah ok, habe den PHP-Code gerade doch noch gefunden. Das ist so aber noch nicht ohne weiteres in WordPress einsetzbar. Sag mir doch bitte erstmal, ob Du das nur beim Aufruf der Startseite möchtest oder für alle Seiten (fände ich ggf. etwas restriktiv, den Nutzer beim Aufruf einer bestimmten Unterseite auf eine andere Seite umzulenken).

Auf die Schnelle habe ich ansonsten nur ein Plugin gefunden, dass Dir das parallele Anbieten von Posts in mehreren Sprachen ermöglicht:
Language Switcher WordPress Plugin, from Poplar ProductivityWare

Zu der Codierungs-Sache: Wenn Du die Seite als UTF-8 auslieferst, müssen auch alle php-Dateien des Themes mit der UTF-8-Codierung gespeichert sein! Dazu brauchst Du einen guten Editor, in dem Du das Speichern als "UTF-8 ohne BOM" einstellen kannst. Ich verwende UltraEdit, das ist genial aber auch kostenpflichtig. Alternativ müssten das jEdit und Proton auf jeden Fall auch können.

Zu den Umleitungen: Da gibt es zwei Möglichkeiten, zwischen denen Du Dich entscheiden müsstest. Du kannst anhand der Sprache des Benutzers umleiten oder über seine IP. Nach Sprache ist einfach. Falls es kein Plugin dafür gibt, kann man das mit wenigen Zeilen Code in der functions.php machen. Kann ich Dir bei Bedarf raussuchen. Nach IP umleiten geht, denke ich, nur über externe Services, da kenne ich mich aber nicht so aus.

Einen Unterschied macht das nur für Leute, die z.B. in Deutschland mit einem englisch eingestellten Browser surfen. Was sollen die zu sehen kriegen, die englische oder die deutsche Seite? Für die meisten Besucher sollte dagegen filtern nach Sprache ausreichen. Wenn Du aber z.B. chinesische Nutzer komplett ausschließen willst, bräuchtest Du vermutlich die Filterung nach IP-Adressen.

Zu den Codierungen: Wenn Du mit verschiedenen Sprachen arbeitest, solltest Du die Seite unbedingt mit der UTF-8-Codierung betreiben. Da dürfte das kein Problem sein. Dafür musst Du sicherstellen, dass alle eingebundenen Komponenten UTF-8 als Codierung verwenden. Es muss also die Datenbank in UTF-8 sein (müsste mit phpMyAdmin überprüfbar sein), die Datenbank-Verbindung (wp-config.php), die Auslieferung der Datei vom Server (Einstellung in den WP-Optionen) und schließlich die Themedateien selber (damit Texte wie "ältere Einträge, die fest im Theme stehen, auch stimmen). Das ist gar nicht so schwierig, wenn man es einmal eingerichtet hat. Es hilft, einen gute Texteditor zu haben, der Dir die Codierung von bearbeiteten Themedateien z.B. anzeigt. UTF-8 übrigens immer ohne BOM speichern, auch das sollte man im Editor einstellen können.

Falls die jetzige Datenbank im ISO-8859-1-Format ist, musst Du die Daten übrigens konvertieren, einfach umstellen dürfte da nicht reichen. Finde ggf. erstmal raus, was Du aktuell verwendest.

Steht so im Quelltext der Seite, im Footer. Die Ursache sollte sich anhand der entsprechenden Themedatei herauskriegen lassen. ;-)