Beiträge von b3317133

Zitat von WP-58475

.... Ich konnte das Child Theme zwar aktivieren, Änderungen im Costumizer ließen sich gar nicht speichern. ..

Wird denn das Child Theme des Theme Herstellers benutzt?

Das beeinflusst nur einen Teil der Links. WordPress speichert die Domain auch hardgecodet z.B. im Inhalt von Beiträgen, Seiten bei Grafiken oder Links, daher ist bei Domainwechseln eine entspr. Anpassung der ganzen Datenbank nötig, siehe Better Search Replace.

Weiterhin dürfte es bei dieser Lösung mit Cache-Plugins oder auch SEO-Plugins, die für Sitemaps o.ä. interne Caches nutzen, zu Verwirrungen kommen.

In WordPress gibt es für eigene Datentypen auch sog. Custom Post Types mit ggf. Custom Taxonomies (ähnlich wie Kategorien, Schlagworte u.ä.), hierfür wird statt eigenem Code gern das Plugin Custom Post Type UI verwendet. Für zusätzliche Datenfelder gibt es dann Custom Fields / Metadata, hierfür wird statt eigenem Code gern das Plugin Advanced Custom Fields verwendet, mit dem man komfortable Eingabemasken erstellen kann.

Das ist seit Jahren der "normale" Weg, eigene Strukturen in WordPress zu erstellen und zu pflegen. Die Custom Post Types können je nach Parameter auch im Frontend unsichtbar bleiben und nur im Backend sichtbar sein.

WordPress kann mit "Wildcard Subdomains" nichts anfangen, eine einfache WordPress Installation arbeitet standardmässig nur mit einer Domain.

Für die Installation auf der Subdomain ist offenbar derzeit die Hauptdomain in der Datenbank hinterlegt, das sieht man z.B. hier bei [FONT=Courier New]url[/FONT] und [FONT=Courier New]home[/FONT], daher leitet WordPress selbst alles auf diese Domain weiter.

https://test.imrsprime.com/wp-json/

Mehr zur Anpassung in der Datenbank z.B. hier, weiterhin fehlt dann noch Better Search Replace o.ä.

Am Rande bemerkt, alle Links im Eingangsposting zeigen auf Facebook-URLs, warum?

Hier erscheint ein Scrollbar unten und man kann die Seite horizontal verschieben wenn der Header sichtbar ist.

Wenn der Seitenheader sichtbar ist, zeigt sich noch ein zusätzliches ähnliches Problem, das wird vom Dropdown Untermenü unter "Kontakt" verursacht, das nach rechts aus der Seite herausragt.

Vermutlich kann man irgendwo in den Megamenü-Einstellungen für nur dieses Untermenü das Alignment auf "rechts" stellen.

Alternativ kann man es mit sowas versuchen, das spricht hardgecodet den aktuellen ID des Menüs "Kontakt" an:

#mega-menu-wrap-main #mega-menu-main > li#mega-menu-item-2560.mega-menu-flyout ul.mega-sub-menu {
    right: 0;
}

Generell, bei Fragen/Hilfe zu Darstellungsproblemen, deaktiviere alle Minify-, Cache-, Optimierplugins, derzeit mind. aktiv: Cache Enabler, Autoptimize.

Im aktuellen Fall scheint das Problem aus der Testimonial Section zu kommen, versuche es mal damit:

.elm-testimonials-main {
    overflow:hidden;
}

Der Code in [FONT=Courier New]admin-interface.php[/FONT] wird nur in den Theme Einstellungen verwendet, da dürfte derzeit auch einiges nicht funktionieren, aber das hat mit dem Slider im Frontend nichts zu tun.

Der relevante Code für das Frontend befindet sich (nach kurzer Google-Recherche) in der Datei [FONT=Courier New]functions.php[/FONT] des Themes relativ am Anfang:

function jquery_scripts() {
    if (!is_admin()) {
    
    wp_deregister_script( 'jquery' );
    wp_register_script( 'jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js', false);
    wp_enqueue_script( 'jquery' );
    wp_enqueue_script('nivo_slider', get_template_directory_uri() . '/includes/nivo/jquery.nivo.slider.js', array('jquery'));
    ...

Ändere das mal so ab:

function jquery_scripts() {
    if (!is_admin()) {
    
/*
    wp_deregister_script( 'jquery' );
    wp_register_script( 'jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js', false);
    wp_enqueue_script( 'jquery' );
*/
    wp_enqueue_script('nivo_slider', get_template_directory_uri() . '/includes/nivo/jquery.nivo.slider.js', array('jquery'));
    ...

Wie ist der Originalzustand dieses Codeblocks ohne Deine Änderungen?

Und was steht in der Datei [FONT=Courier New]header.php[/FONT] des Themes?

Nutze das Symbol [FONT=Courier New][+][/FONT] hier im Forum, um Code-Blöcke einzufügen.

Aus irgendwelchen Gründen wird bei Dir die [FONT=Courier New]jQuery[/FONT] Komponente von einem externen Server geladen:

http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js

Diese Einbindung erfolgt derzeit via [FONT=Courier New]http[/FONT] und wird daher in den meisten Browsern aus Sicherheitsgründen geblockt wenn die Seite an sich per [FONT=Courier New]https[/FONT] geladen wird, siehe auch Browser Console beim Aufruf der Seite.

Dadurch funktionieren die Scripts auf der Seite nicht mehr, inklusive des Sliders.

Mögliche Lösungen:

• Die Einbindung der [FONT=Courier New]jQuery[/FONT] Komponente von diesem externen Server ersatzlos streichen, WordPress bringt eigentlich selbst schon [FONT=Courier New]jQuery[/FONT] mit.
• Die Einbindung der [FONT=Courier New]jQuery[/FONT] Komponente von diesem externen Server auf [FONT=Courier New]https[/FONT] ändern (und diese externe Einbindung in der noch zu erstellenden Datenschutzerklärung aufführen).

Das Theme Nucleare bindet nach kurzem Einblick in den Code als Parent die [FONT=Courier New]style.css[/FONT] eines ggf. vorhandenen Child Themes ein.

Daher benötigt man diese Einbindung nicht erneut im Child-Theme.

Man kann/sollte daher bei diesem Theme diese Zeile in Deiner Child Theme [FONT=Courier New]functions.php[/FONT] weglassen:

wp_enqueue_style( 'child-theme-css', get_stylesheet_directory_uri() .'/style.css' , array('parent-style'));

Tipp am Rande:

Dein Child Theme [FONT=Courier New]style.css[/FONT] wird derzeit zwei mal eingebunden, direkt hintereinander, einmal mit dem handle [FONT=Courier New]child-theme-css[/FONT] und einmal mit dem handle [FONT=Courier New]nucleare-style[/FONT], sichtbar im HTML-Quelltext im [FONT=Courier New]<head>[/FONT].

Vermutlich passt die Einbindung in der [FONT=Courier New]functions.php[/FONT] des Child Themes nicht wirklich zum Parent Theme. Das passiert oft, wenn Child Theme Generatoren oder Copy&Paste Codeblöcke von irgendwoher o.ä. verwendet werden.

Das Problem könnte man ggf. im Code bei [FONT=Courier New]add_action( 'wp_enqueue_scripts', ...[/FONT] in der [FONT=Courier New]functions.php[/FONT] des Child Themes sehen.

Zitat von Romka

Es ist doch so: Lädt man ein Bild hoch bei Wordpress, dann werden normalerweiße 4 Dateien daraus gemacht. 1 x Original und 3 x Konvertiert mit entsprechender Auflösung wie in den Mediaeinstellungen hinterlegt.

Seit WordPress 4.4 wird intern eine weitere Bildgrösse medium_large erstellt, oft erstellt WordPress weiterhin auch noch Auflösungen für z.B. die Anzeige der Thumbnails in der Mediathek bzw. auch für spätere Angaben in [FONT=Courier New]srcset[/FONT] usw..

Auch WordPress Standard Themes erstellen diverse weitere Grösse für Header Bilder, Beitragsbilder, Archivübersichten usw.

• Evtl. ist derTheme Editor z.B. in [FONT=Courier New]wp-config.php[/FONT] deaktiviert, ggf. auch über das Theme selbst.
• Oder der Editor ist durch ein laufendes Sicherheits-Plugin (aus guten Gründen) deaktiviert.
• Oder die Rolle Deines Benutzers hat nicht die nötigen Rechte.
  
• Oder Du arbeitest in einer WordPress Multisite Installation, dann hat das ggf. wieder ganz andere Gründe.

Generell: Das Bearbeiten von Theme Dateien sollte man ohnehin besser nur offline und via FTP machen.

Zitat von Nina H.

Die Aufrufzahl von "WP-Statistics" steht nur in einem <p></p> Tag. Da kann ich so nichts ändern ohne eine Klasse, sonst wirken sich die Änderungen auf die ganze Seite aus.

Ansprechen kannst Du diesen Absatz z.B. so:

.ShariffSC.shariff-ohne-sidebar + p {
    background-color: #f8f;
}

Um den Abstand etwas zu verringern, wäre z.B. sowas ein Ansatz:

.ShariffSC.shariff-ohne-sidebar {
    overflow: hidden;
}
.ShariffSC.shariff-ohne-sidebar + p {
    margin-top: 0;
}

Wenn über längere Zeiträume weder Besucher noch Bots vorbekommen, sollten Backups oder Updates eher die geringere Sorge sein, dann kann man diese Websites ggf. besser einfach aufgeben.

Zitat von DuerrUndSteidle

Wenn wp_cron an ist werden ja alle Cronjobs nach einem Intervall abgerufen.

Das ist vom Besucheraufkommen abhängig, kommt länger mal kein Besucher/Bot vorbei, verzögert sich die Ausführung bis der nächste kommt.

Zitat von nepomunich

.. anscheinend haben meine Einstellungen doch was gebracht.

Für andere Leser mit ähnlichen Problemen, was hast Du eingestellt und wo?

Zitat von nepomunich

Zum https: Wie könnte man das beheben? Bzw. wer?

Wende Dich an Deinen Hostinganbieter.

Zitat von nepomunich

bei meinem bei Ihnen gehosteten WordPress-Blog

Hier im Forum wird kein WordPress gehostet. Wende Dich an Deinen Hostinganbieter.

Von hier aus funktioniert der genannte Website per http augenscheinlich einwandfrei, Bilder werden angezeigt, die beiden .pdf bzw. .docx die lt. REST-API vorhanden sind, kann man ebenfalls runterladen.

http://www.berndoswald.de/wp-json/wp/v2/media

Link zu einer Seite mit einem PDF o.ä. wo man den 403 Fehler sehen kann? Screenshot wie das bei Dir aussieht?

Nebenbei noch, der Website ist auch per https erreichbar, aber das zugehörige Zertifikat ist falsch ausgestellt.