Permalinks - Falsches template wird gewählt

  • Hallo,

    zu dem Thema Permalinks gibt es ja schon einige Beiträge, aber mein Problem konnte ich damit nicht identifizieren.

    Die Permalinks hatten vor ein paar Tagen noch einwandfrei (Option Beitragsname) funktioniert. Heute hatte ich diverse Änderungen vorgenommen.
    Nun habe ich gerade festgestellt, dass die Beitragsseiten, das Jahr und die Monate nicht richtig erstellt werden. Die Kategorieseite funktioniert. Bei den Beitragsseiten wird das Template der Homepage geladen und für Jahr und Monat findet WP kein Template mehr.
    Wenn ich die Permalink-Option "Monat und Name" wähle, funktionieren zumindest die Beitragsseiten wieder. Jahr und Monat leider nicht.
    Wenn ich wieder auf Standard zurück gehe, funktioniert wieder alles.
    Die .htaccess passt sich entsprechend an, kann also von WP verändert werden.

    Wie kann ich wieder zu der Option Beitragsname zurück kehren?

    • Anzeige

    Hallo!

    Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

    • ✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
    • ✔️ Deutsche Server & DSGVO-konform
    • ✔️ Persönlicher Support (kein 0815-Ticket-System)

    Mehr erfahren

  • Hallo,

    soll ich die Rahmenbedingungen noch näher beschreiben oder herrscht allgemeine Ratlosigkeit, was gemacht werden müsste, um die Permalinks wieder nutzen zu können?

    Viele Grüße.

  • Hallo,

    ein Versuch noch. Ich bin den Anweisungen in den FAQ gefolgt: http://faq.wpde.org/permalinkstruk…uf-die-website/
    Allerdings gab es in dem long text keinen Eintrag (macht ja auch Sinn, da der Standard ja wieder funktioniert). Die .htaccess ist auch "leer" und enthält keine Rewrite Regeln.
    Heute habe ich festgestellt, dass die Startseite sich nicht anpasst. Ich habe eine kleine Änderung in der index.php vorgenommen und hoch geladen. Allerdings blieb diese dann in dem bisherigen Zustand. Derzeit ist die Seite bei den Permalinks auf Standard eingestellt. Daraufhin bin ich wieder auf Beitragsname gegangen, um zu sehen, ob die Startseite dann den neuen Zustand aufweist. Leider gab es da keine Veränderung, aber auf einer anderen statischen Seite (Kontakt) wurde als content die neue index.php geladen. Echt schräg.

    Wie bekomme ich da wieder Ordnung rein?
    Den derzeitigen Stand sichern (Inhalte), neu installieren in einer anderen Datenbank mit dem Ursprungstheme und dann über den Wordpress Import die Inhalte wieder hoch laden, wäre jetzt meine Überlegung. Bevor ich das mache, wäre es super, ob jemand einen einfacheren Weg vorschlagen könnte (Anpassungen in der derzeitigen DB).

    Viele Grüße.

  • Wechsel doch einmal das Theme - dieses legt die Templates fest, nicht der Permalink (der legt nur das Aussehen der URL fest).

    Schau Dir doch mal die Template Hierarchie von WordPress an, da kannst Du genau sehen, welche Datei für das Erscheinungsbild der einzelnen Bereiche zuständig ist, bzw. als Fallback dient, wenn ein spezielles Template nicht definiert wurde.

    http://codex.wordpress.org/images/1/18/Template_Hierarchy.png

    Da siehst Du z.B. dass die archive.php zuständig ist wenn es keine date.php gibt und diese (archive.php) wiederum durch die index.php ersetzt wird, falls nicht vorhanden.

    Die entsprechenden Dateien findest Du im root des themes.

  • Hallo MegaWork,
    vielen Dank für das Feedback. Das Theme habe ich kurz gewechselt. Hat aber leider nichts gebracht.

    Das Stichwort Hierarchie hat mich auf die index_bak.php gebracht, die noch im Verzeichnis liegt. Die wird aufgerufen.
    Nun habe ich die zwischenzeitlich kurz gelöscht, in der Hoffnung, dass dann die index.php ausgeliefert wird und das Permalink Problem sich gleich mit auflöst. Passiert aber leider nicht. Es wird dann nur der Header und Footer geladen. Von welchem vorgelagerten Befehl/Datei wird die index.php, bzw. bei mir derzeit index_bak.php denn aufgerufen?

    Viele Grüße.

  • Die index.php steht in der Hierarchie an oberster Stelle. Im Prinzip braucht ein theme nur aus der style.css und der index.php bestehen um zu funktionieren.
    In dieser Datei werden header.php & footer.php (wie auch die anderen Seitenbereiche, z.B. sidebars, content, usw.) inkludiert - Schau Dir doch erst einmal den Quellcode Deiner index.php an und versuche zu verstehen, wie sie funktioniert.

  • Hallo,
    ich habe die index_bak.php jetzt einfach umbenannt in index.php und dann hat sich das Problem mit der alten Version jetzt erledigt.

    Erneut zu den Permalinks, die nach wie vor unter Beitragsname im Content-Bereich falsche Inhalte generieren. Wieso funktioniert eine statische Kontakt-Seite mit Standard (./?page_id=157) aber nicht mit dem Beitragsnamen (./kontakt/) ? Die Hierarchie ist ja unter Standard in Ordnung. Wo muss ich da suchen?

  • Bist Du sicher, dass dein Hoster / dein Hosting Vertrag rewrite unterstützt? Hast Du mal mit phpinfo(); die Konfiguration Deines Servers gecheckt? - Wenn nicht, einfach mal eine php-Datei erstellen mit folgendem Inhalt

    Zitat

    <?php phpinfo(); ?>

    Diese in das Hauptverzeichnis hochladen und über den webbrowser aufrufen. Dann auf der Ergebnisseite nach rewrite suchen - wenn es gefunden wird, sicherstellen, dass die .htaccess richtig geschrieben wurde.

  • yep, bin mir sicher. Hat ja vor ein paar Tagen noch funktioniert. Ich musste allerdings ein update von php 5.2 auf php 5.5 vornehmen (1und1)
    Habe die php Info mal hoch geladen. Hier der einzige Eintrag mit rewrite:
    [TABLE="width: 600"]

    [tr]


    [TD="class: e, bgcolor: #CCCCFF"]url_rewriter.tags[/TD]
    [TD="class: v, bgcolor: #CCCCCC"]a=href,area=href,frame=src,form=fakeentry,fieldset=[/TD]
    [TD="class: v, bgcolor: #CCCCCC"]a=href,area=href,frame=src,form=fakeentry,fieldset=[/TD]

    [/tr]


    [/TABLE]


    Die .htaccess wird ja sogar verändert. Bei Standard sieht sie so aus:
    AddType x-mapp-php5 .php
    AddHandler x-mapp-php5 .php
    # BEGIN WordPress


    # END WordPress

    bei Beitragsname so:

    AddType x-mapp-php5 .php
    AddHandler x-mapp-php5 .php
    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>


    # END WordPress

    Ach ja, und php5.2 hatte ich, aufgrund des permalink-Problems, zwischenzeitlich wieder zurück installiert. Ging aber auch unter 5.2 nicht mehr.

    Einmal editiert, zuletzt von HHelms (1. Oktober 2014 um 16:32)

  • Weiß ich leider nicht.

    Ich habe mir gerade eine andere Domain (selbes 1und1 Paket mit php5.5) mit einem anderen WP-Theme und funktionierenden Beitragsname-Permalinks angesehen. Die php info sieht dort genauso aus, wie bei mir. Scheint irgendwie nicht der Punkt zu sein...

    Nun habe ich wordpress neu installiert (nicht manuell), hat aber auch keine Veränderung gebracht. In alle statischen Pages und Blog-Beiträge werden im Bereich Content Inhalte der Home gezogen. Die Kategorieseiten vom Blog (Permalinks-Beitragsname) werden mit dem richtigen Content aufgebaut. Zurück auf Standard und alle Seiten bauen sich wieder richtig auf... Ich bin verzweifelt.

  • [COLOR=#222222][FONT=Verdana, Arial, Tahoma, Calibri, Geneva, sans-serif]Hallo,[/FONT][/COLOR]

    [COLOR=#222222][FONT=Verdana, Arial, Tahoma, Calibri, Geneva, sans-serif]ich habe mich heute noch mal intensiv mit der Problematik auseinandergesetzt und eine Testumgebung mit neuer DB und der ersten Version des Themes aufgebaut. Auch dort trat das Problem aus dem "Nichts" auf.[/FONT][/COLOR]
    [COLOR=#222222][FONT=Verdana, Arial, Tahoma, Calibri, Geneva, sans-serif]Inzwischen konnte ich es eingrenzen. Es gibt einen Konflikt mit einem Plugin (Custom Post Type | [/FONT][/COLOR]Version 0.8.4 | Von WebDevStudios.com[COLOR=#222222][FONT=Verdana, Arial, Tahoma, Calibri, Geneva, sans-serif]), das noch nicht kompatibel mit WP 4.0 ist.[/FONT][/COLOR]
    [COLOR=#222222][FONT=Verdana, Arial, Tahoma, Calibri, Geneva, sans-serif]Wenn ich das komplett über FTP lösche, dann tritt der Fehler nicht mehr auf. Ich habe jetzt ein nicht so oft verwendetes, dafür aber mit WP 4.0 kompatibles Plugin aktiviert (WCK [/FONT][/COLOR]Version 1.1.1). Damit funktioniert jetzt alles.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!