Beiträge von mastermind

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?

Zitat von DoctorJay

Warum macht es Sinn die Rechte runter zu regeln um was beschreiben zu können?

*tieflufthol* Also:

- Es gibt bei Zugriffsrechten drei Positionen: Besitzer (u) - Gruppe (g) - Andere (o)
- Es gibt drei Arten von Zugriffsrechten: Lesen (r) - Schreiben (w) - Ausführen (x)

Für jede Datei gibt es also ein Set von Besitzer, Gruppe (und Anderen), sowie die jeweils gesetzen Zugriffsrechte. Das kann wiefolgt aussehen (ein '-' bedeutet, dass das Recht nicht gesetzt ist):

Besitzer darf lesen, schreiben, ausführen:

rwx

Gruppe darf nur lesen und ausführen:

r-x

Andere dürfen nur lesen:

r--

Insgesamt für die jeweilige Datei also:

rwx r-x r--

Man kann diese dreistelligen "Päckchen" auch in Zahlen ausdrücken, wobei die Päckchen binär dargestellt werden: Eine '1' heißt: Recht gesetzt, '0' heißt Recht nicht gesetzt, z.B.:

rwx
111

dabei ist '111' eine binäre '7' (hoffe, ich muss das nicht auch noch erklären), oder z.B.

rw-
110

(binär '6')

eine Datei mit den Zugriffsrechten

rwx r-x r-x

hat also die binären Zugriffsrechte 755. Damit wäre sie also von Dir veränderbar. Allerdings, wenn Du sie mit dem WordPress-Editor bearbeitest, ist es der Webserver, der die Datei verändert. Auf einem vernünfitg konfigurierten Server sollten alle Dateien automatisch der Webserver-Gruppe gehören, weshalb eine 664 zum beschreiben ausreichen sollte. Ist dies aber nicht der Fall, muss die Datei von allen beschreibbar sein; die Zugriffsrechte müssen also mindestens 666 sein.

HTH

Eher letzteres. ;)

Im Allgemeinen wird es nicht so ganz einfach sein, es zu verbreitern, da Du ggf. Grafiken, XHTML und CSS anpassen musst.

Im Verzeichnis /wp-content/themes/DEIN_THEME/ findest Du die Dateien, aus denen sich das Theme zusammensetzt. Alles andere ist Fleißarbeit.

Wenn Du mit SQL-Dumps arbeitest, ja. Aber das wirst Du vermutlich eh machen, wenn Du den Server wechselst.

Es sind übrigens ganze zwei Einträge, die in der Tabelle "wp_options" zu ändern sind.

Ich vermute mal, mit "Hilfslink meinst Du sowas wie "http://user1234.someserver.com/". Dann vermute ich mal, hast Du das auch in den WordPress-Optionen so eingetragen.

Sollte es so sein, dann ist das überhaupt kein Problem. Du kannst nach dem Domainumzug, wenn Du die Datenbank und die Dateien transferiert hast, einfach die neue Domain via phpMyAdmin o.ä. setzen.

Du solltest nur darauf achten, dass Du bei manuell angelegten internen Links eine relative und keine absolute URL angibst (also nicht "http://user1234.someserver.com/blabla/blubb" sondern "/blabla/blubb"). So sparst Du Dir ne Menge Arbeit.

edit: Eine schöne Seite hast Du übrigens. Bist Du sicher, dass Du es noch besser machen kannst? ;)

Hast Du schon eine .htaccess angelegt?

Wenn die Apache-Konfiguration keine .htaccess oder nur bestimmte Optionen zulässt, dann gibt eine unerlaubte Option einen "500".

Tipp: mal die .htaccess kurz umbenennen und nochmal testen.

Dann gib doch bitte mal nen Link zur Seite.

Ich befürchte eher, der Server ist nicht richtig konfiguriert:

$ nc [...].com 80
GET / HTTP/1.0


HTTP/1.1 200 OK
Date: Wed, 05 Apr 2006 09:41:41 GMT
Server: Apache/2.0.55 (Unix) mod_perl/1.99_17-dev Perl/v5.8.0 mod_ssl/2.0.55 OpenSSL/0.9.8a PHP/4.4.2 FrontPage/5.0.2.2634
Last-Modified: Wed, 29 Mar 2006 10:47:07 GMT
ETag: "174029-2c-edd480c0"
Accept-Ranges: bytes
Content-Length: 44
Connection: close
Content-Type: text/html; charset=ISO-8859-1


<html>Apache is functioning normally</html>

Diese Meldung erscheint z.B., wenn der Domain ein fehlerhalftes DocumentRoot zugeordnet wurde.
Vielleicht magst Du mal Deinen Server-Admin ansprechen.

P.S. Sach mal, was ist denn das für ein fameboys.com für ein abgefahrenes Portal?! Das letzte Mal habe ich soviele Schwänze auf einen Haufen beim Bund in der Mannschaftsdusche gesehen... ;)

Ohne Dir zu nahe treten zu wollen, Nadine: Strato ist meiner Ansicht nach ein S**haufen. Das fängt an bei den Datenschutzbestimmungen und AGB, geht über den unfreundlichen und unfähigen Support und endet lange nicht bei dem miesen Preis-Leistungsverhältnis. Wir hatten mal einen Root-Server bei Strato und waren einfach nur froh, als wir da weg waren.