Das Problem könnte an Zeile 276 des Plugins liegen, weil dort der Content nur eingelesen wird anstatt ihn durch die do_shortcode Funktion zu jagen. Das müsste man im Detail debugen.
Beiträge von mensmaximus
-
-
nutze enfold theme
Bis hier hin habe ich gelesen und hätte gerne geholfen, da es sich um mein Haus und Hof Theme handelt. Leider Fehlen Deinem Text sämtliche Merkmale vernünftiger Grammatik wodurch das Lesen zur Qual wird. Schreibe bitte ganze, zusammenhängende Sätze mit Groß- und Kleinschreibung, damit man die Zusammenhänge versteht.
-
Grundsätzlich: Wenn unterschiedliche Plugins die selben Filter-Hooks verwenden 'gewinnt' das mit der niedrigsten Priorität, also das Plugin was als letztes seine Modifikation am Content durchführt. Ja nachdem wie es arbeitet kann es zu solchen Phänomenen kommen.
In Deinem Fall: Wo stellst Du "Display Shortcodes" ein bzw. aus und von welchem Plugin kommt das?
-
Das machst Du bei der Anlage des Custom Post Type und der Custom Taxonomie über den Parameter Rewrite und Slug (bzw. Slug als Element des Array Rewrite). Anschließend brauchst Du noch zwei Filter für post_link und post_type_link um den Permalink dynamisch zu befüllen. %categpory% als solches gibt es für CPTs nicht, da diese Taxonomie schon für Posts verwendet wird.
-
Es gibt drei Möglichkeiten wo sich die 301 Weiterleitung befinden könnte
1. in der Datei .htaccess
2. in einem Plugin für Weiterleitungen
3. in einer Funktion in der functions.php Deines Theme/Childtheme -
Du brauchst nur die Plugins prüfen, die netzwerkweit aktiviert wurden und das sind im Regelfall nur sehr wenige.
-
Bitte Link zur Shop-Seite und Link zur Seite auf der die Weiterleitung statt findet, damit man einmal sehen kann von wo, nach wo umgeleitet wird.
-
Doch, sonst würde ich den Menüpunkt doch auch gar nicht sehen.
Bedeutet das jetzt "Ja, ich habe meine Cookies gelöscht" oder nicht?
-
Habe ich gemacht, es ändert sich aber nichts. Laut [COLOR=#000000][FONT=arial]WP Memory Usage ist der Speicher ja aber auch schon auf 256 MB oder?[/FONT][/COLOR]
Diese Programme lesen, wenn sie es überhaupt richtig machen, das Memory Limit aus, welches im Forntend zum Tragen kommt
Codedefine( 'WP_MEMORY_LIMIT', '256M' )Da Dein Fehler im Backend erscheint und Du sehr viele statische Seite hast, dürfte sichergestellt sein, das beim Versuch der Auflistung der Speicher überläuft. WordPress ist nicht auf statische Seiten ausgelegt sondern auf Beiträge. Zu erklären wo das Problem genau liegt, ist mir jetzt zu aufwändig aber so viel sei gesagt: Statischen Seiten sind hierarchisch, weshalb WordPress ein anderes Ladeverhalten an den Tag legt.
Falls Du einen eigenen Server hast (kein Hostingaccount) könntest Du das Speicherlimit einfach weiter erhöhen:
Codedefine( 'WP_MEMORY_LIMIT', '384M' ) define( 'WP_MAX_MEMORY_LIMIT', '384M' );Grundsätzlich stell sich aber die Frage ob 400 statische Seiten tatsächlich Sinn machen oder ob hier nicht einfach ein grundlegender Irrtum über die Verwendung von WordPress vorliegt. Nicht selten habe ich bei der Analyse solcher Phänomene feststellen müssen, dass der Einsatz eine Custom Post Types die Verwendung von statischen Seiten überflüssig machte.
-
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
Codedefine( 'WP_MAX_MEMORY_LIMIT', '256M' ); -
-
-
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.
-
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
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 lassenDie 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.
-
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.
