Beiträge von mastermind

Zitat von Tascha

dann ist ja gut wenn die Seite nicht zu lang hat zum laden.
Ich nutze eure Hilfsbereitschaft nun gleich nochmals aus (solange ich niemandem auf die Nerven gehe :D)

Passt scho

Zitat von Tascha

wie kann ich diesen Fehler denn korrigieren und was genau läuft da schief?

Har, har, har. Das Problem ist einfach zu beschreiben -- nur die Lösung könnte kompliziert werden.

Das Problem ist folgendes: Im Quelltext müssen alle &-Zeichen als & maskiert werden, auch in URLs. Das Problem bei Dir ist, dass Deine URLs offenbar automatisch generiert sind, und man sinnvollerweise auch automatisch die &-Zeichen konvertieren würde.

Die Lösung könnte beispielsweise darin bestehen, dass man sich ein kleines Plugin zimmert, welches letztendlich alle nicht maskierten HTML-eigenen Zeichen konvertiert. (Darf ich evtl. fragen, welches Plugin (und wozu) Du verwendest, um einen Session-Handler in der URL zu haben?)

Zitat von Reeno

ich suche eine Möglichkeit, die 404-Fehlerseite direkt aufzurufen, da ich alle Fehler des Webspaces auf diese umleiten möchte. Bisher leite ich auf domain.de/wp/404 um (WordPress liegt im Ordner wp/), was den Benutzer zwar auf die Fehlerseite umleitet, aber einen zweiten 404 Error generiert.

WordPress tut genau das -- allerdings nur, wenn Du .htaccess benutzt und nur ab dem Verzeichnis, in dem es selbst liegt.

Also bei mir wird nicht zwischen groß und klein unterschieden.

Jokerzeichen gibt es standardmäßig nicht; z.B. der Stern wird auch als solcher gelesen. Allerdings kannst Du auch einfach so nach Wortbestandteilen suchen lassen.

Könntest Du evtl. noch ein paar Infos geben? Was genau machst Du, um den Artikel zu löschen, wo kommt eine leere Seite? Hast Du evtl. irgendwelche Plugins, die das verursachen könnten? Wenn ja: was passiert, wenn man alle Plugins ausschaltet?

Hast Du die DB über "/wp-admin/install.php" angelegt?

Ich weiß nicht, ob das PHP-gzip auf Deiner Seite überhaupt richtig aktiviert war... vielleicht war es auch nur deshalb in Firefox schneller, weil zwar die Datenmenge größer war, diese jedoch nicht mehr dekomprimiert werden musste? Wenn Du z.B. eine schnelle Leitung, aber einen älteren Rechner hast, ist das sehr wahrscheinlich.

Bei mir kommen Deine Inhalte jedenfalls nach wie vor flink an.

(Aus diesem Grund finde ich übrigens, dass das Komprimieren von Webinhalten nicht immer von Vorteil ist.)

Zitat von Tascha

Mastermind:
das mod_gzip ist nun installiert. Das sollte nun von alleine laufen oder? Oder muss ich da nun was machen?

Jep, das läuft schon:

Date: Mon, 10 Apr 2006 15:39:24 GMT
Server: Apache/1.3.34 (Unix) mod_gzip/1.3.26.1a mod_auth_passthrough/1.8 FrontPage/5.0.2.2510 mod_log_bytes/1.2 mod_bwlimited/1.4 mod_ssl/2.8.25 OpenSSL/0.9.8a
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Encoding: gzip
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Vary: Accept-Encoding
X-Pingback: http://www.tascha.ch/xmlrpc.php
X-Powered-By: PHP/4.3.10
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

"Content-Encoding: gzip" ist das Zauberwort. Das heißt Du kannst jetzt das PHP-gzip abschalten, wenn Du magst.

Was das Validieren angeht: da wird sich einiges lichten, wenn erstmal die dämliche PHP-Fehlermeldung verschwunden ist.

Zitat von Tascha

Ich werde mich mal erkundigen betreffend dem offensichtlich fehlenden Modul. Konnte keine solche Datei finden im etc

Das Modul wird normalerweise separat installiert. Wenn Du magst, kannst Du in Deinem Paketmanager nachschauen, ob das Modul installiert ist. Wenn Du es installierst, wird es mit Sicherheit auch direkt aktiviert.

Zitat von Tascha

Nun trotzdem noch zu meiner php code frage.
Der Code, den ich versuchen wollte, war das was falsch? Zum Unterdrücken der Fehlermeldung im Browser.

Vielleicht hilft Dir folgende Seite (bevor ich sie ganz abschreibe ;)): http://de.php.net/error_reporting

Zitat von Tascha

Hier die Ausgabe:
[...]

Also zlib-Support scheint drin zu sein. Dann hab ich zunächst auch keine Idee.

Aber mal was anderes: Warum möchtest Du überhaupt über PHP komprimierte Inhalte ausliefern? Es belastet Server und Client unnötigerweise, und gerade *die* Inhalte, für die es auf Deiner Website am interessantesten wäre (nämlich die Bilder) komprimiert PHP eh nix. Außerdem sind JPEGs ja schon komprimiert, da ist also nicht viel zu holen.

Zitat von Tascha

Betreffend Apache: Das weiss ich leider nicht, kann ich das wo nachschauen?

Das kommt auf Deine Linux-Distribution an. Standardmäßig in /etc/apache2/modules.d müsste eine Konfigurationsdatei für das Modul sein. Falls die nicht da ist, fehlt aller Wahrscheinlichkeit nach auch das Modul. Ein "locate mod_gzip" sollte ggf. das Modul selbst ausfindig machen.

Worauf ich mit dem Apache hinaus will: Wenn Du unbedingt komprimieren willst, dann wäre es sinnvoller mit Apache. Denn der komprimiert *alles*, was er ausliefert, und es gibt keine Probleme mit instabilen gzip-Implementationen wie offenbar in WordPress.

Also, Fehler zu "unterdrücken" halte ich grundsätzlich für keine so tolle Idee. Wie wär's mit einer Fehleranalyse?

Vielleicht sollten wir zunächst mal schauen, ob Dein PHP überhaupt zlib-Untestützung hat. Kannst Du bitte mal aus der phpinfo-Ausgabe den Bereich "Configure command" posten? Und: hat Dein Apache das "mod_gzip" installiert?

Du könntest den originalen TinyMCE nehmen. Der ist relativ einfach zu integrieren.

Ich nutze den hier: http://boren.nu/archives/2004/10/13/theme-switcher-plugin/

Problematisch ist nur, dass er beim Wechseln den Switcher nicht in alle Themes automatisch einbaut. (Liegt aber nicht am Plugin, sondern an den Themes.) Ein <?php wp_sidebar(); ?> in jede sidebar.php könnte aber helfen (allerdings nicht selbst getestet).

Das Problem scheint folgendes zu sein: Noch vor den HTTP-Headern wird in irgendeinem der includes Inhalt gesendet. Wie das da reinkommt, weiß ich nicht.

Könntest Du bitte einfach mal probieren, die Verzeichnisse /wp-includes und /wp-admin zu löschen und neu aufzuspielen? Das könnte das Problem lösen.

Bei mir ist mit Linux und Firefox alles ok.

Allerdings würde ich zunächst auch vorschlagen, /wp-admin und /wp-includes zu löschen und neu zu installieren. Das sind nun mal die Verzeichnisse, in denen sich die WYSIWYG-Geschichte abspielt.

Das passiert z.B., wenn schon HTML und danach nochmal HTTP-Kopfdaten gesendet werden.

Passiert das nur im Admin?
Hast Du evtl. Plugins installiert, die den HTTP-Header modifizieren könnten?
Kannst Du bitte einen Link zu Deiner Seite posten?

Mit CSS -- entweder "text-align: center;" oder "margin-left: auto; margin-right: auto;".

Vage Vermutung: Könnte sein, dass es einen Fehler beim Pingen gibt.
Du könntest versuchsweise Pings und Trackbacks abschalten und schauen, ob es dann immer noch passiert.

Da musst Du leider das Plugin, genauer: die MySQL-Suchabfrage modifizieren.

Meiner Ansicht nach liegt es nicht am Server.

Hast Du evtl. irgendwelche Plugins aktiviert, die den Header oder Cache oder globale Variablen modifizieren? Vielleicht magst Du mal versuchsweise alle Plugins deaktivieren?

Falls das nicht hiflt, hätte ich noch eine andere, allerdings recht radikale Idee:

- das gesamte WP-Verzeichnis sichern,
- alle Dateien und Verzeichnisse außer /wp-content löschen und neu installieren.

jadmanx: Is es vielleicht möglich, dass eines Deiner Plugins unter bestimmten Voraussetzungen die HTTP-Header modifiziert und die Fehler produziert?

Könntest Du evtl. mal alle oder ggf. einige Plugins deaktivieren?