Beiträge von Iris Kammerer

Hallo, allerseits!

Ich versuche seit einer Ewigkeit, Jetpack zu installieren. Das klappt zwar bis hin zur Aktivierung des Plugins, aber die Verbindung zum Wordpress-Account wird verweigert, stattdessen wird folgende Fehlermeldung im Backend angezeigt:

Zitat

Jetpack could not contact WordPress.com: token_http_request_failed. This usually means something is incorrectly configured on your web host.connect() timed out!

(Siehe Anhang!)

Im errorlog findet sich dazu Folgendes:

[Wed May 02 11:28:26 2012] [error] [client *meineIP*] ALERT - script  tried to increase memory_limit to 268435456 bytes which is above the  allowed value (attacker '*meineIP*', file  '*meinPfad*/wordpress/wp-admin/admin.php',  line 109)

Mein Hoster braucht ein bisschen mehr Informationen, um mir zu helfen, weil diese Fehlermeldung auf dem Server von WP öfters produziert wird. Kann mir (DAU! :wink:) jemand weiterhelfen?

Vielen herzlichen Dank im Voraus!
Viele Grüße,

Iris Kammerer

Leider hat nix geholfen. Der nach Änderung der php.ini angezeigte Skriptfehler hätte eigentlich nicht auftreten dürfen. Des Rätsels Lösung ergab sich nach kompletter Rekonstruktion einer zweiten (Test-)Installation per Try&Error: Theme dkret3 und Plugin Anti-Captcha können offenbar nicht miteinander.

Durch vollständige Beseitigung des Plugins und des Themes sowie deren Spuren und nachfolgender Neuinstallation des Themes hat es dann endlich geklappt.

Nichtsdestotrotz Dankeschön an alle! :smile:

Herzliche Grüße,

Iris Kammerer

Zitat von infected

Liegt vermutlich daran, dass dort überhaupt kein WordPress läuft?! Das ist eine ganz normale HTML Seite. Hast Du vielleicht die falsche URL gepostet?

EDIT: Du solltest den Hinweis zum Wartungsmodus etwas auffälliger gestalten ;-) Naja, wie dem auch sei... Hast Du´s mal in nem anderen Browser getestet?

Ich schrieb bereits im Eingangsbeitrag:

Zitat

Getestet habe ich das auf MSIE, Firefox, Safari und Opera, Cookies und JavaScript sind aktiviert.

Das komplette WP-Verzeichnis neu zu überspielen hat auch nichts gebracht.

Lieder hilft mir das alles gar nicht weiter ... Dafür habe ich das schön konfigurierte Theme überschrieben ... Ohne Einloggen kriege ich das nicht mehr repariert.

Davon abgesehen funktioniert das Frontend weiterhin -- aber wie komme ich wieder ins Backend??? :confused:

Ratlose, dennoch hoffnungsvolle Grüße

Iris Kammerer

Hallo, allerseits!

Auf einer WP-Installation, die ich mitbetreue, ist nach dem Upgrade von 2.9.2 auf 3.0.1 ein Fehler aufgetreten, den ich im Forum so nicht finden konnte:

Der Login gleich nach dem Upgrade funktionierte problemlos, aber seit einem Neustart des Browsers trat beim Anmelden (admin) die unten angehängte Fehlermeldung auf.

Getestet habe ich das auf MSIE, Firefox, Safari und Opera, Cookies und JavaScript sind aktiviert. Die empfohlene Leerung des Cache änderte gar nichts am Problem.

Das Frontend der Homepage (http://www.insel-hotel-lindau.de) funktioniert problemlos. Ich komme aber nicht mehr ins Backend.:confused:

Was soll ich tun?

(Ich bitte um Entschuldigung, wenn dieses Problem bereits beschrieben wurde, aber ich habe es weder im Handbuch noch unter den FAQ noch mittels der Forensuche gefunden.)

Herzliche Grüße und vielen Dank für eure Bemühungen!

Iris Kammerer

PS: Sorry, was vergessen: Das Löschen der Cookies hatte keinen Einfluss auf den Fehler.

Hallo, allerseits!

Ich habe vorgestern meine WordPress-version von 2.6.5 (glaub ich) zunächst einmal auf 2.7.1 aktualisiert. Das erste Anmelden nach dem Upgrade klappte, ich habe die zuvor deaktivierten Plugins wieder aktiviert, einen Artikel fertiggemacht und publiziert.

Das Frontend läuft reibungslos, soweit ich das beurteilen kann; da sind keine Meldungen im error.log (außer den üblichen 404s, wenn einer veraltete Links aufruft).

Aber: Seit gestern kann ich mich zwar korrekt anmelden, kriege aber im Backend nach der Anmeldung nur eine leere Seite als index.php zurück, und das bei jedem mir verfügbaren Browser (MSIE 8, Firefox 3.5, Safari 4.0, Opera 9.68 ).
MSIE wirft folgenden Quellcode aus:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=utf-8" http-equiv=Content-Type></HEAD>
<BODY></BODY></HTML>

Im error.log meines Web-Accounts finde ich folgende Meldungen zu den geschätzten Zeitpunkten der Anmeldungen über verschiedene Browser:

Zitat

Log Files Viewer:
[Thu Aug 06 17:24:33 2009] [error] [client 217.227.243.118] ModSecurity: Access denied with code 500 (phase 4). Pattern match "<b>Warning<\\/b>.{0,100}?:.{0,1000}?\\bon line\\b" at RESPONSE_BODY. [file "/etc/modsecurity/rules/modsecurity_crs_50_outbound.conf"] [line "42"] [id "970009"] [msg "PHP Information Leakage"] [severity "WARNING"] [tag "LEAKAGE/ERRORS"] [hostname "http://www.iris-kammerer.de"] [uri "/wordpress/wp-admin/index.php"] [unique_id "t1sjBn8AAAEAACc3EUoAAAAP"]
[Thu Aug 06 17:24:41 2009] [error] [client 217.227.243.118] ModSecurity: Access denied with code 500 (phase 4). Pattern match "<b>Warning<\\/b>.{0,100}?:.{0,1000}?\\bon line\\b" at RESPONSE_BODY. [file "/etc/modsecurity/rules/modsecurity_crs_50_outbound.conf"] [line "42"] [id "970009"] [msg "PHP Information Leakage"] [severity "WARNING"] [tag "LEAKAGE/ERRORS"] [hostname "http://www.iris-kammerer.de"] [uri "/wordpress/wp-admin/index.php"] [unique_id "t@s3wH8AAAEAABzwt-0AAAAN"]
[Thu Aug 06 17:24:44 2009] [error] [client 217.227.243.118] ModSecurity: Access denied with code 500 (phase 4). Pattern match "<b>Warning<\\/b>.{0,100}?:.{0,1000}?\\bon line\\b" at RESPONSE_BODY. [file "/etc/modsecurity/rules/modsecurity_crs_50_outbound.conf"] [line "42"] [id "970009"] [msg "PHP Information Leakage"] [severity "WARNING"] [tag "LEAKAGE/ERRORS"] [hostname "http://www.iris-kammerer.de"] [uri "/wordpress/wp-admin/index.php"] [unique_id "uBL03n8AAAEAACc3EUsAAAAP"]

Was ist da kaputt? Wie kann man das in Ordnung bringen?

Hinweis: Ich bin vor allem Anwender und kann kein PHP :oops:-- deshalb bitte möglichst idiotensicher antworten, damit ich etwas davon habe. ;-)

Vielen Dank und herzliche Grüße

Iris Kammerer

Hallo, allerseits!

Ich wollte gerade die Gunst der Stunde nutzen, um WordPress zu aktualisieren. Selbstverständlich bin ich nach Vorschrift vorgegangen (Daten sichern, Plugins deaktivieren, WP-Dateien - außer den geänderten! - löschen, neue Version entpacken, neue Version auf den Server spielen, liesmich.html aufrufen).
Bis zum Hinweis, dass jetzt die Datenbank aktualisiert werden müssen, klappte auch alles prima. Leider war die nächste Seite eine Fehlermeldung: Internal Server Error (Error 500).

Der Blick ins error.log brachte mehr Klarheit:

[Sun Dec 14 11:23:51 2008] [error] [client 84.174.201.204] ModSecurity: Access denied with code 500 (phase 2). Pattern match "\\\\.php(3|4|5)?(\\\\?|&).*=(ht|f)tps?:/" at REQUEST_URI. [id "300040"] [rev "1"] [msg "Generic PHP code injection protection in URI"] [severity "CRITICAL"] [hostname "www.iris-kammerer.de"] [uri "/wordpress/wp-admin/upgrade.php?step=1&backto=http%3A%2F%2Fwww.iris-kammerer.de%2Fwordpress%2Fliesmich.html"] [unique_id "H18E9n8AAAEAAA2cJ58AAAAf"]

Ich habe meinen Provider schon vor einiger Zeit informiert, dass ModSecurity an anderer Stelle (Bearbeitung vorhandener Seiten - siehe Threadtitel Providerwechsel: Error 500 bei Bearbeitung bestehender Seiten/Artikel, Rubrik Installation) ebenfalls Ärger macht, und werde auch dieses Problem weitergeben.

Die "Reaktivierung" von WP v.2.6.5 funktionierte reibungslos, das System läuft wieder.

Trotzdem - oder besser gesagt: deshalb nochmals die Frage: Was geht da eigentlich vor? Ein Bekannter betreibt mehrere WP-Blogs beim selben (!) Provider und hatte nie eines dieser Probleme.

Ich wünsche allen einen schönen Sonntag!

Ratlose Grüße,

Iris Kammerer

Okay, vielen herzlichen Dank! Damit kann ich etwas Verständliches zusammenbauen.

Herzliche Grüße,

Iris Kammerer

Hallo, marX!

Da werde ich bei der Anfrage an den Tech-Support schon etwas präziser sein müssen, und da ich in diesen Dingen keine Expertin bin, würde ich gerne wissen, was ich den Leuten dort genau sagen soll.

Dank für die Präzisierung! :-)

Herzliche Grüße,

Iris Kammerer

Hallo, allerseits!

Ich habe mit meinem Blog erfolgreich einen Domainumzug vorgenommen.

Allerdings ergab sich nach dem Umzug ein originelles Problem: Bestehende Seiten, die vor dem Providerwechsel generiert worden waren, ließen sich zwar überarbeiten, die neue Version wurde nach "Speichern" tatsächlich abgelegt und angezeigt. Aber danach meldete der Server einen Error 500.

Der Blick ins error_log zeigte Fehlermeldungen folgenden Typs:

[Mon Dec 01 14:48:18 2008] [error] [client 84.174.198.18] ModSecurity: Access denied with code 500 (phase 2). Pattern match "\\\\.php(3|4|5)?(\\\\?|&).*=(ht|f)tps?:/" at REQUEST_URI. [id "300040"] [rev "1"] [msg "Generic PHP code injection protection in URI"] [severity "CRITICAL"] [hostname "www.iris-kammerer.de"] [uri "/wordpress/wp-admin/page.php?action=edit&post=12&message=1&_wp_original_http_referer=http%3A%2F%2Fwww.iris-kammerer.de%2Fwordpress%2Fwp-admin%2Fedit-pages.php"] [unique_id "dqN4Mn8AAAEAAEfLAhYAAAAh"]

Neue Seiten lassen sich problemlos erstellen, abändern, löschen etc. Der Fehler tritt nur auf, wenn ich Seiten/Artikel bearbeite, die vor dem Domainumzug bereits bestanden.

Was läuft verkehrt? Und wie kann ich das abstellen?

Vielen Dank vorab!
Herzliche Grüße,

Iris Kammerer

Hallo, allerseits!

Ich habe soeben den Upgrade von WP 2.6.2 auf 2.6.3 vorschriftsgemäß vollzogen und finde seither ein ziemlich fatales Phänomen vor.

Vorab: Den Test, alle Plugins zu deaktivieren, habe ich schon durchgeführt. Das ändert absolut nichts am Problem.

Wenn ich Artikel oder Seiten schreiben oder bearbeiten möchte, erscheinen zwei (!) Editorfenster.

Das "obere" Fenster erscheint quasi zwischen den Zeilen des TinyMCE-Editorsadmin; darüber wird nur die Zeile mit der Überschrift "Seite" bzw. "Artikel", der Funktion "Dateien hinzufügen: ..." und dem Link zum Wechsel auf HTML angezeigt, die übrigen Zeilen des WYSIWYG-Editors trennen oberes und unteres Editorfenster.

Das untere Editorfenster sieht "normal" aus, das obere verarbeitet offenbar die CSS-Datei nicht.

Manchmal wird der Inhalt des Artikels / der Seite nur im oberen Editorfenster angezeigt, manchmal in beiden.

Nur was im oberen Editorfenster eingetragen wird, wird vom System verarbeitet. Die Buttons des Editors, die ja jetzt unter dem oberen Fenster liegen, werden von diesem Fenster ignoriert.

Ein Umschalten auf HTML ist nicht möglich. Der Link reagiert nicht.

Ein Abschalten des WYSIWYG-Editors unter [Backend] -> [Benutzer] führt dazu, dass das untere Editorfenster verschwindet. Das obere Editorfenster bleibt ein WYSIWYG-Editorfenster.

Jedesmal, wenn ich die Seite mit dem Editor verlassen will, erscheint ein graues Popup mit folgender Meldung:

Ratlose Grüße,

Iris Kammerer

Au weia! :oops:
Für so viel Peinlichkeit gibt 's keinen Smilie mehr ...

Vielen herzlichen Dank -- Problem erkannt, Problem gelöst!
Wie konnte ich das bloß übersehen ...??? :confused:

Allen ein schönes Wochenende!

Iris Kammerer

PS Zumindest weiß jetzt die halbe WP-Community, wer bei uns zuhause das Sagen hat ... :-D

Hallo, allerseits!

Nachdem ich jetzt schon einige Artikel im Blog habe (vorwiegend Bildmaterial), möchte ich die Kommentarfunktion für Besucher freischalten.

Aber was auch immer ich unter [Einstellungen] -> [Diskussion] einstelle, es kommt stets kein Kommentarfenster, sondern die Meldung:
"Sie müssen angemeldet sein um einen Kommentar zu schreiben."

Ich benutze WP 2.6.2, habe das alles bei aktivierten und deaktivierten Plugins versucht, ohne dass sich etwas tut, und bin jetzt mit meinem Latein am Ende.

Ich habe mal einen Screenshot von den Einstellungen zu [Diskussion] und der betreffenden Artikelseite im Backend angefügt. Das unerwünschte ;-) Resultat im Frontend sieht man z.B. hier.

Allen ein schönes Wochenende!

Iris Kammerer

Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.

Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.

Schon erledigt und alle Plugins einzeln getestet. Am Ende war's das Plugin Advanced Category Excluder, das in dieser Kombination das Problem verursacht.

Herzlichen Dank! :)

Iris Kammerer

Da mein Theme nicht über eine tag.php verfügt, ist die "ranghöchste" Template-Datei archive.php.
Und die funktioniert ansonsten bestens (ist nahezu identisch mit index.php).

Ich weiß jetzt allerdings immer noch nicht, warum die "ge-tag-ten" Artikel nicht aufgelistet werden... :confused:

Herzliche Grüße

Iris Kammerer

Hallo, allerseits!

Ich möchte die Tags auf meiner Website sinnvoller organisieren, und dabei ist mir folgendes aufgefallen, dass wohl beim letzten Update passiert ist:
Wenn ich bei Artikeln - egal ob in der "Vorschau" auf der Archiv-/Index-/Kategorieseite oder auf der Einzelseite - auf die Tags klicke, findet WP im Loop nichts, denn es gibt die jeweilige Seite ohne Ergebnisse aus: Website zum Testen
Was kann denn da passiert sein? :confused:
Reicht es, wenn ich eine einzelne Datei von WP auf den Server spiele? Wenn ja, welche und wohin?

Allen einen schönen, erholsamen Sonntag!
Herzliche Grüße,

Iris Kammerer

Bingo! Ich hab 's kapiert! :-D WP nimmt bei Seiten offenbar primär die page.php! (Hätte ich mir eigentlich denken können ... :oops:)

Okay, jetzt muss ich diese Liste mit den Unterseiten via Stylesheet nur noch in ein hübsch eingekasteltes Inhaltsverzeichnis umwandeln, dann passt es.

Herzlichen Dank und viele Grüße!

Iris Kammerer

Nun ... ich hab jetzt mal die index.php um den im Codex unter List subpages even if on a subpage zitierten Code erweitert, und zwar erst mal über dem Loop, damit ich was sehe. (In der Sidebar funktioniert das Script ja nicht, wenn man - wie ich - Widgets verwendet.)

<?php get_header(); ?>
  <div id="content">
  <?php if($post->post_parent) $children = wp_list_pages("title_li=&child_of=".$post->post_parent."&echo=0"); else $children = wp_list_pages("title_li=&child_of=".$post->ID."&echo=0"); if ($children) { ?> <ul> <?php echo $children; ?> </ul> <?php } ?>

Aber leider sehe ich nichts. Die Unterseiten werden nicht aufgelistet. Im generierten Seitenquelltext taucht der Code bzw. seine Umsetzung in HTML weder in Firebug, noch in der Quellcodeanzeige des Browsers auf. (Ich hab überprüft, ob die richtige Datei an der richtigen Stelle auf dem Server liegt! ;-))

Was mache ich verkehrt? :confused:

Herzliche Grüße,

Iris Kammerer

Hallo, Ammaletu!

Leider nicht. Früher ging das, heute setzt das blöde Ding sich darüber hinweg.
Es handelt sich allerdings wohl um einen FF3-Bug, der die Browser-Integration von N360-2 betrifft. Ich bastele an der Site halt mit MSIE und warte aufs nächste Update, was soll 's? :)

Herzliche Grüße

Iris Kammerer

Problem hat sich erledigt -- "wer suchet, der findet ..." :mrgreen: