CMS Made Simple Forums

MacLane wrote: Habe die .htaccess Datei im uploads Ordner schon kontrolliert: Da sind die gleichen Werte drin wie bei einer cmsms-Installation eines anderen Hosters, wo es das Problem nicht gibt.

Deaktiviere mal alle .htaccess Dateien (umbennennen auf _.htaccess z.B.)

Danach schauen ob das Problem noch immer existiert. Falls nein, kannst du mit TryAndError versuchen den Fehler zu lokalisieren. Wenn der Fehler auch mit deaktivierten .htaccess Files auftritt, ist das Problem an anderer Stelle zu suchen.

Hast Du dem Tiny gesagt, dass er benutzerspezifische Verzeichnisse nehmen soll?
Der versucht dann nämlich für jeden User ein extra Verzeichnis im Bilder-Uploads-Verzeichnis anzulegen und darauf zuzugreifen.
Welche Zugriffsrechte sind denn für das Uploads-Verzeichnis und dessen Unterverzeichnisse gesetzt?

Abgesehen davon: Wenn Du nur die .htaccess Datei im Uploads-Verzeichnis umbenennst, nimmt der Server einfach die aus dem übergeordneten Verzeichnis. Also schau mal, ob Du nicht doch irgendwo noch eine .htaccess Datei hast, die Dir evtl. den Zugriff auf diverse Dateien oder Verzeichnisse verbietet.

Hast Du den Uploads-Ordner evtl. umbenannt?
Einige Module greifen nämlich nicht auf die config Variable zu, um den Uploads-Ordner zu ermitteln, sondern suchen stur nach "uploads".
(Der TinyMCE gehört soweit ich weiß allerdigs nicht dazu.)

MacLane wrote: Der Webhoster ist alfahosting.de, bei dem mir schon auch eine Merkwürdigkeit (z.B. im Unterschied zu all-inkl.de) auffällt: Wenn ich bei  all-inkl mit der Bild- oder Dateiverwaltung etwas hoch lade ist der Owner wwwrun; bei alfahosting ist der Owner = dem FTP-Benutzer.

Das muss nicht unbedingt aussergewöhnlich sein. Mein bevorzugter Webhoster setzt suPHP ein. Damit läuft php jeweils immer unter dem jeweiligen FTP Nutzer. Zusätzlich kann man bei dieser Konfiguration ein eigenes php.ini einsetzen.

Aus diesem Grund: Gib mal dem uploads Ordner die Rechte 755. Möglicherweise kann das Problem auch damit zusammenhängen. Zumindest bei suPHP dürfen keine 777er Rechte mehr vergeben werden.

Noch eine Besonderheit bei alfahosting: Bei der Konfiguration von TinyMCE muss unter "Weitere Optionen" der Haken bei "Eine statische Konfigurationsdatei verwenden" gesetzt werden. Kann es vielleicht damit zusammenhängen?

Ich bin mir nicht ganz sicher. Wenn php im CGI Modus läuft, kann TinyMCE mit dynamischen Config-Files probleme haben. Hängt möglicherweise mit dem oben geschilderten zusammen.

Das Fenster mit der Dateiauswahl enthält ein iFrame.
Schau Dir mal die URL des iFrames an.
In der Regel sieht sie in etwa so aus:
[Deine Domain]/modules/TinyMCE/filepicker.php?sp_=[irgendeine kryptische id]&type=image.
D.h. es wird versucht direkt auf eine Datei im Modul-Verzeichnis zuzugreifen.
Welche Rechte hat das Modul-Verzeichnis?
Gibt es irgendwelche Regeln, die den direkten Zugriff auf das Modul-Verzeichnis oder auf bestimmte Dateien des Modul-Verzeichnisses verbieten?

MacLane wrote:
Das ist exakt so, wie auch bei der funktionierenden Installation bei all-inkl.

Das hat nix zu sagen, da Server nunmal nicht gleich Server ist.
So gesehen ist da nichts exakt so wie irgendwo anders.
Setz mal die Rechte für die filepicker.php auch auf 755.

Hast Du Dir diese iFrame URL mal angeschaut?
Ist die korrekt?
Existiert die Datei a der angegebenen Adresse?

Vielleicht liegts auch am Domain- oder Verzeichnisnamen.
Könnte ja sein, dass irgendwelche Zeichen enthalten sind, die der TinyMCE irgendwie konvertiert.
Allerdings würde es dann eher zu einem 404 Fehler kommen (Seite nicht gefunden), aber kein interner Server Fehler.

Welche PHP Version und welche CMS Version?
Wieviel RAM wird Dir gegönnt?

Vielleicht solltest Du auch einfach mal Deinen Provider fragen, wieso Du auf die Datei filepicker.php nicht zugreifen kannst.
Einfach mal die URL vom iFrame kopieren und dem Provider zeigen.
Vielleicht kann der Dir sagen, wieso das nicht geht.

Ja klar liefert der Server HTML.
Nämlich die Fehlermeldung anstelle des eigentlichen Resultats irgendeiner PHP Datei

Du solltest Dich wirklich mal mit dem Provider auseinandersetzen.
Oder vergleich mal die Zugriffsrechte des Admin-Verzeichnisses (inkl. PHP Dateien) mit dem Modul-Verzeichnis.