Beiträge von mensmaximus

Schau Dir mal diesen Thread an: http://forum.wpde.org/installation/1…erreichbar.html

Füge einmal folgende Zeile in Deine wp-config.php ein

define( 'WP_MAX_MEMORY_LIMIT', '256M' );

Hast Du das http://forum.wpde.org/allgemeines/13…html#post594333 gemacht?

http://forum.wpde.org/onlineshop-mit…html#post613780

Das Du in der Datenbank die Pfade änderst ist Voraussetzung, Link hatte ich gepostet. Dann wolltest Du aber eine 'schöne' URL. Daazu habe ich Dir etwas geschrieben. Vielleicht formulierst Du ja nochmal was Du jetzt genau willst, ansonsten ziehst Du deine Blogs um, kopierst die Bilder in das Standard Upload Verzeichnis der jeweiligen Site und änderst alle Pfade mit suchen und ersetzen ab. Anschliessend änderst Du die URL wie beschrieben und machst eine Umleitung.

Zitat von wp0815

Der "Upload URL Path" sollte dann also der Pfad sein, der im Browser zum Hochladen genutzt werden sollte (und damit auch in der Datenbank als URL abgelegt wird). Aber leider funktioniert das bei mir nicht - Die URL bleibt immer /wp-content/uploads/sites/NUMMER/... ;(

Wenn Upload URL Path einen 'Alias' enthalten soll, der das eigentliche Upload Path Verzeichnis 'versteck', brauchst Du auch eine Rewrite Regel (in WP oder in einer .htaccess Datei)

OFFTOPPIC

Zitat von IICCEE

Grundsätzlich, das sagt auch All-inkl selbst, ist die Ausführung von PHP als Modul und nicht als FASTCGI performanter, deswegen sollte man das nicht dauerhaft als FASTCGI laufen lassen

Die meisten Provider wollen FastCGI nicht, weil es mehr RAM verbraucht. Ein moderner, richtig konfigurierter Server ist mit PHP-FPM schneller als mod_php und verbraucht weniger Speicher. Hierzu hat Bitnami auch einen Beitrag geschrieben: http://blog.bitnami.com/2014/06/perfor…apache-and.html

Und das Argument der Sicherheit, welches bei mod_php so hoch gelobt wird ist nicht war. Bei FastCGI bzw. PHP-FPM hat man keine übergreifenden Rechte im Filesystem zwischen den Hostingaccounts, bei mod_php sehr oft schon.

Daher lautet meine Empfehlung seit langem: FastCGI, besser PHP-FPM mit Apache 2.4 bzw. NGINX (für V-Server).

Wen Du es selbst schreiben willst, kannst Du den Filter posts_search verwenden.

Es gibt sicherlich andere Lösungen, diese im Rahmen der Hilf zur Selbsthilfe alle aufzuzählen sprengt den Rahmen des Forums. Mein Vorschlag basiert auf Deinem Beispiel Link.

Du kannst doch Upload Path und Upload ZRL Path pro Seite im Netzwerk in den jeweiligen Seiteneinstellungen im Netzwerk Admin ändern.

Zitat von wp0815

herauslesen, dass ich alle Posts abändern muss?! Ok, ich könnte das mit nem SQL-Statement ändern. Aber das ist ja nicht der Punkt: Mir ist ehrlich gesagt noch nirgendwo diese Form der URL untergekommen. Ist das denn normal?

Das ist das Basisverhalten einer Netzwerk Installation.

Schau mal ob Dir die kostenfreie Version reicht: https://wordpress.org/plugins/woocom…duct-tabs-lite/
Falls nicht kannst Du auch eine Pro Version kaufen.

Mehrere Single Installationen in ein Netzwerk zu integrieren bedeutet Handarbeit: https://codex.wordpress.org/Migrating_Mult…s_3.0_Multisite

Schau Dir mal http://codecanyon.net/item/woocommer…gration/8790106 an

Zitat von Monika

ist ein work-around dessen bin ich mir bewusst

Für "dieses" Problem ist es ein Workaround aber grundsätzlich ist die Verwendung von PHP 5.6 mehr als zu empfehlen und der FastCGI Modus sorgt auch gleich dafür, dass andere Probleme 'verschwinden'.

Du darfst auf keinen Fall eine ältere Version manuell einspielen! Wenn Du ein Downgrade machen willst musst Du eine Backup wiederherstellen.

Prüfe zunächst Deine PHP Version. Alle Versionen kleiner als 5.5 sind veraltet und müssen upgedated werden. Am besten Du stellst auf 5.6 um.

Kannst Du noch das Backend aufrufen und Dich anmelden?
Falls ja, prüfe ob alle Plugins und Themes aktualisiert sind und führe gegebenenfalls die Updates durch.

Falls nicht, verbinde Dich per FTP mit Deinem Webserver und benenne das /plugins Verzeichnis unterhalb /wp-content in /plugins_old um und erstelle einen leeren Ordner /plugins. Danach prüfst Du ob die Seiten laden (ignoriere Layoutfehler, da jetzt keine Plugins mehr geladen werden) und Du Dich anmelden kannst. Falls das funktioniert kopierst Du ein Plugin nach dem anderen von /plugins_old nach /plugins um. Nach jedem kopierten Verzeichnis lädst Du die Seite neu. Tritt der Fehler erneut auf ist das zuletzt kopierte Plugin nicht kompatibel und Du kannst dieses zuletzt kopierte Verzeichnis löschen.

Laden die Seiten auch mit deaktivierten Plugins nicht, liegt ein Problem mit dem Theme vor.

PS.: Dein Screenshot kam während ich meine Antwort geschrieben habe. Prüfe ob im WordPress Verzeichnis eine Datei mit dem Namen .maintenance liegt und lösche diese.

Zitat von drno

und das sollte was bringen? die automatischen Updates sowie auch manuelle Updates aus dem Dashboard klappen z.B. auch mit PHP 5.5.x problemlos.

Ich behaupte nicht, das es mit 5.5 nicht geht. Viele User haben aber Probleme im Zusammenhang mit PHP 5.5 und Updates gemeldet. In vielen Fälle hat die Umstellung auf PHP 5.6 geholfen.

Zitat von juna

Ist diese Vorgehensweise richtig?

Nein. Du erstellst eine Multisite Installation und lässt den Domainnamen auf das Installationsverzeichnis zeigen, nicht auf ein Unterverzeichnis. Die Installation wird also im Browser über http://deinedomain.xyz/ aufgerufen und nicht über http://deinedomain.xyz/unterverzeichnis/. In WordPress erstellst Du dann eine neue Site. Unterverzeichnisse legst Du nicht an.

https://codex.wordpress.org/Configuring_Au…ion_via_Filters

Achte auf den Satz mit must-use plugin

Kanst Du einmal auf PHP 5.6 umstellen?