Beiträge von b3317133

• Ist die Subdomain "intern" auf den Ordner /wordpress gesetzt? Screenshot Einrichtung Subdomain?
  
• Aufruf Admin wäre dann subdomain.example.com/wp-admin/ - also ohne /wordpress im Pfad!
• Gibt es eine und falls ja was steht in der .htaccess im Hauptverzeichnis der bestehenen Seite?
• Was genau ist im Ordner /wordpress? Screenshot FTP?
• Wie genau wurde "manuell aufgesetzt"? Falls vorhanden, entferne eine ggf. manuell eingerichtete wp-config.php Datei, die wird dann von WordPress selbst angelegt.

Zitat von tobi386

Einrichtung einer Subdomain funktionieren nicht.

Was genau funktioniert mit der Subdomain nicht? Subdomain anlegen, "Umleitung (Intern)" auf Installationsordner setzen, Subdomain im Browser aufrufen. Ggf. Browsercache leeren, um vorherige Versuche daraus zu entfernen...

Zitat von Peter G

Um Menüs zu erstellen gehe ich über Design -> Menüs. Unter dem Punkt "Menüeinträge hinzufügen" werden die Custom Post Types nicht mit angezeigt.

Oben rechts "Ansicht anpassen" und/oder Einstellung show_in_nav_menus prüfen.

Benenne die .htaccess wieder zurück oder klicke einmal ohne Änderungen im Menü Einstellungen > Permalinks > Aktualisieren Button unten, damit die .htaccess neu generiert wird und die "schönen" Permalinks wieder funktionieren.

Was am Rande auffällt, die Seite steht auf "noindex" für die Suchmaschinen, ist das Absicht?

<meta name='robots' content='noindex, nofollow' />

Gesamt ein seltsamer Effekt, evtl. kommt Dein Safari/Mac nicht mit dem SSL-Zertifikat zurecht, es wäre interessant, ob ein Aufruf einer statischen Seite per http:// klappt, z.B.

http://werbeloewen.de/readme.html

..aber das geht derzeit durch eine generelle autom. Weiterleitung auf SSL nicht.

Deaktiviere alle Cache-, Minify-, CDN- und sonstige Optimierungsplugins, derzeit mind. aktiv: NitroPack

Leere danach den Browser-Cache. Was genau wird dann in Safari angezeigt? Screenshot?

Ein Umbenennen der .htaccess muss mindestens dazu führen, dass die bestehenden "schönen" Permalinks nicht mehr funktionieren. Wenn es das nicht tut, wurde die falsche .htaccess umbenannt oder es laufen weitere Cache-Mechanismen.

Wurde kürzlich die PHP Version umgestellt?

Evtl. sind Theme oder Plugins nicht mit dem aktuell verwendeten PHP 8.0.13 kompatibel.

Beide Seiten laden hier derzeit ohne Fehlermeldung, bis auf als solche angezeigte Shortcodes durch offenbar derzeit ggf. durch Fehlersuche inaktive Plugins.

Normalerweise sind bei WordPress bei Seiten keine Pingbacks, sondern nur bei Beiträgen.

Bei Dir ist die Pingback Funktion wie gesagt warum auch immer für die Kontakt Seite trotzdem aktiv, ebenso für die Seiten Disclaimer, Impressum, Termine, Gästebuch, Über uns.

Evtl. ist auch das Jetpack Plugin dafür verantwortlich oder etwas anderes hat das beim Anlegen der Seiten dort eingestellt.

Alternativ mal in der Datenbank nachsehen, statt "open" sollte dort "closed" stehen, z.B. die Kontakt Seite bei Dir hat die ID 9.

Es handelt sich nicht um einen Hack.

Das ist einfach nur die in WordPress eingebaute Pingback Funktion, die bei Dir warum auch immer für diese Seite aktiv ist.

WordPress > Seiten > bei Deiner Seite Kontakt > QuickEdit > Pings erlauben > Haken rausnehmen > Aktualisieren

Sehen kann man das z.B. über die REST-API:

Lt. Download Manager Support Forum ist das Problem bekannt und man will es mit dem nächsten Update beheben.

WordPress lädt standardmässig jedes Plugin auf jeder Seite.

Es dürfte sich um den hier im Popup-Maker Support Forum beschriebenen Effekt handeln.

Der Rand ist offenbar aus Barrierefreiheit-Gründen vorhanden.

Zitat von Peter G

Welche Möglichkeiten gibt es um das zu lösen.

Der von WordPress dafür vorgesehene Weg ist hier beschrieben:

Zitat von b3317133

Für verschiedene Template-Dateien für die Einzelausgabe in einem Custom Post Type muss dieser [FONT=Courier New]page-attributes[/FONT] Support beim Registrieren haben, dann werden auch ggf. vorhandene weitere Templates für den Custom Post Type ermittelt und beim Bearbeiten des Einzelbeitrags zur Auswahl angezeigt.

Damit ist kein weiterer Unterscheidungscode nötig, Beispiel:

<?php
/*
Template Name: MTX Dashboard
Template Post Type: mtx-site
*/

Dateiname beliebig z.B. [FONT=Courier New]mtx-dashboard.php[/FONT], diese Datei wird dann bei entspr. Auswahl von MTX Dashboard im Editor anstelle der [FONT=Courier New]single-mtx-site.php[/FONT] genutzt.

Vermutlich hast Du einen "Custom Post Type" erstellt, siehe auch Dokumentation Post Typen.

Die im Code genutzte is_page() Abfrage ist für einzelne Seiten (die den Post Type 'page' haben), siehe auch Dokumentation is_page().

Die Template-Datei für den eigenen Post Type hinterlegt man im Child Theme. Welche Datei von WordPress in welcher Reihenfolge gesucht bzw. genutzt wird siehe auch Template Hierarchy Dokumentation bzw. Custom Post Type Template Files Dokumentation.

Für verschiedene Template-Dateien für die Einzelausgabe in einem Custom Post Type muss dieser [FONT=Courier New]page-attributes[/FONT] Support beim Registrieren haben, dann werden auch ggf. vorhandene weitere Templates für den Custom Post Type ermittelt und beim Bearbeiten des Einzelbeitrags zur Auswahl angezeigt.

Leider fehlte diese Angabe im ersten Posting, so dass im Grunde niemand sinnvoll helfen konnte.

Für viele Plugins werden bei der genannten WordPress Version vermutlich auch gar keine Updates gezeigt, da viele Plugins inzwischen höhere WordPress Versionen voraussetzen.

Bei so alten Installationen empfiehlt WordPress eine manuelle, schrittweise Aktualisierung von WordPress auf zuerst 4.9.18 und dann 5.0.x, dabei jeweils die Plugins auf Updates prüfen und dann in kleinen Schritten weiter mit z.B. WordPress 5.1.x, dann 5.2.x, dann 5.3.x usw. mit jeweils folgenden Plugin Updates, da ab 5.0 in jeder WordPress Version viele viele Änderungen drinstecken. Ebenso geht man bei der PHP-Version vor, parallel passend zum Releasezeitpunkt des jeweiligen WordPress schrittweise auf 7.2.x, 7.3.x, 7.4.x. Ebenso mit dem Theme, die Version jeweils zeitlich zum Rest passend. Dazu beobachtet man bei jedem Schritt das Error Log des Servers, zudem lässt man WP_DEBUG in eine debug.log laufen und behebt ggf. manuell kleinere Problemchen direkt im Code, falls dadurch Updates verhindert werden, was bei diesen Rahmenbedingungen durchaus trotz schrittweisem Vorgehen vorkommen kann.

Zitat von alhai

... erst seit das Theme aktualisiert wurde, zuvor eher nicht. Das Theme ist Hestia update von 2.1.1 zu 3.0.20, ansonsten funktioniert aber alles.

Das Theme Update ist ein Riesensprung - Hestia 2.1.1 ist drei Jahre alt - seitdem ist viel passiert in WordPress. Es kann daher viele Einflüsse geben. Welche WordPress Version, welche Plugins, was wurde noch aktualisiert, von welche auf welche Versionen usw., siehe auch Forenregeln Punkt II.

Generell: Solche Updatesprünge sollte man in jedem Fall mit einem aktuellen Klon des Websites vorher auf einem Testserver durchspielen.

"Autor*innen" sieht aus wie eine sog. Taxonomie, in der man bei Dir offenbar verschiedene Autoren o.ä. einstellt. Dieser Menüpunkt bzw. diese Bezeichnung stammt vermutlich aus Deinem Theme oder einem Plugin. Was erscheint, wenn Du den Punkt auswählst?

Ein Menüpunkt "Kategorien" wäre auch eine sog. Taxonomie, in der man dann Kategorien einstellt. Evtl. wird der Punkt bei Dir durch Dein Theme oder Plugins ausgeblendet oder es ist im Screenshot nicht sichtbar. Dieser Menüpunkt wäre Standard WordPress.

Für nötige Angaben für sinnvolle Hilfe siehe auch Forenregeln, Punkt II.

Welches Theme und Version? Welche WordPress Version? Welche sonstigen Plugins? Lt. Symbol links oben sind offenbar 20 Updates verfügbar, was erscheint beim Klick auf die 20?

Was bei den Screenshots auffällt, beim ersten steht oben "Visuellen Builder verlassen" und beim zweiten "Visuellen Builder aktivieren" Was passiert beim Klick auf "...aktivieren"? Oder meinst Du das mit "auf den Visuellen Builder klicke"?

Ergänzung: Weiterhin fällt auf, dass möglicherweise verschiedenen Cache-Plugins parallel verwendet werden, sowas kann je nach Einstellung auch Nebenwirkungen haben, Screenshot Balken oben links: Clearfy, Seitenquelltext: LiteSpeed Cache und Cache Enabler und Artefakte von NitroPack und dazu noch Essential Addons for Elementor und die interne Divi Minify Funktion. Wende Dich ggf. an die Person, die den Website technisch eingerichtet hat und lasse das noch bereinigen. Vor allem auch die Frage klären, warum Addons für Elementor zusammen mit Divi verwendet werden, das sind zwei verschiedene Paar Schuhe...

Bei der Suche nach Darstellungsproblemen sollte generell alle Cache-, Minify-, CDN- und sonstige Optimierungsfunktionen komplett deaktiviert sein.

Wenn Dein Backend deutsch ist, könnte es an einer anderslautenden Einstellung in Deinem Benutzerprofil liegen, das Einstellung > Allgemein überstimmt.

Stelle auch sicher, dass Dashboard > Aktualisierungen > Sprachen falls angeboten aktualisiert sind.

Die Beschreibung, dass Einstellungen > Allgemein die Sprache nicht speichert, ist ungewöhnlich, welche WordPress Version? Welche Divi Version? Was passiert mit allen Plugins inaktiv und einem Twenty XXX Standard Theme?

Ok, dann war das Problem lt. Deinem anderen Thema also ein Backup der Datenbank, das in die falsche Datenbank eingespielt wurde?

Die Angabe der Ursache und der vorgenommene Lösungsweg wäre hilfreich, damit spätere Mitleser im Forum das Problem nachvollziehen und selbst daraus lernen können.

Vermutlich ist die Verknüpfung der fmt Domain beim Hosting falsch und zeigt derzeit auf den Ordner des Chors. Prüfe die Domainverknüpfungen dort.

Und was genau bedeutet das hier? Welches Update wurde wo eingespielt?

Zitat von ansgarmw

Da ich dachte, dass etwas an der Konfiguration falsch ist, habe ich versucht das letzte Update einzuspielen.

Weitere Möglichkeiten wären, dass ein Backup der Datenbank des Chors in die Datenbank der fmt Seite eingespielt wurde, oder dass die Datei [FONT=Courier New]wp-config.php[/FONT] der fmt Seite mit der Datei [FONT=Courier New]wp-config.php[/FONT] des Chors überschrieben wurde.

In der Infinite Theme Demo sieht man einen ähnlichen Effekt, wenn beim Runterscrollen die Höhe des Menüs verringert wird.

Bei Dir ist das Menü von Anfang an schon so hoch/niedrig wie nach dem Runterscrollen, evtl. fällt der Effekt bei Dir daher mehr auf.

Wäre wohl am besten ein Fall für den Theme Support. Es handelt sich offenbar um ein Kauf-Theme, da hat man entspr. Support oft mitgekauft.

Ergänzung: Als Workaround könnte man den Header bei Dir von Beginn an bereits auf [FONT=Courier New]fixed[/FONT] setzen, z.B. so, ob das weitere Auswirkungen hat, musst Du aber selbst testen.

.infinite-header-wrap.infinite-header-style-plain.infinite-style-fixed {
    position: fixed;
    top: 0;
    left: 0;
    right: 0;
    z-index: 99;
}