Beiträge von Trunk

    Die Link-Struktur kann eingestellt werden unter Einstellungen -> Permalinks (/wp-admin/options-permalink.php)
    In deinem Fall beim Letzten Feld (Benutzerdefinierte Struktur) /blog/%postname% eingeben.

    Und vielleicht das nächste mal ein bisschen selbst suchen, die Option ist nicht gerade schwer zu finden ;)

    Ich werde bei der HTTP-Version immer zur HTTPS-Version weitergeleitet (was gut ist! HSTS nehme ich an?), daher werden die Bilder bei mir alle normal geladen.

    Grundsätzlich sollte man aber keine HTTP-Elemente (wie die Bilder) auf einer HTTPS-Seite einbinden, da so die Sicherheit der verschlüsselten Seite untergraben wird, wenn man einfach unverschlüsselt (genauer: unauthentifiziert) Inhalte nachlädt und ausführt/anzeigt etc.

    Deshalb kann es vorkommen, dass Browser die HTTP-Bilder nicht nachladen, wenn sie auf der HTTPS-Seite sind.

    Aber da ja eh ein Zertifikat vorhanden ist, kann auch die ganze domain mit HSTS und/oder .htaccess auf HTTPS umgeleitet werden.

    Wenn das DIV (was den iframe für das Video enthält) clear:both; als CSS-Eigenschaft bekommt, sorgt das dafür, dass links und rechts daneben keine Elemente platziert werden, das Video rutscht also in eine eigene Zeile. Die regel muss also in den CSS Teil, der sich um die niedrige Seitenbreite kümmert, clear:none; in den CSS-Teil für größere Seitenbreiten.

    Wenn das im Responsive CSS festgelegt wird, sollte das Video nicht mehr halb aus der Webseite herausragen.

    Die Version, die global im System verfügbar ist, sieht man durch ausführen von

    Code
    openssl -v


    in einem Terminal. Aber der Webserver könnte auch einfach seine eigene (Open)SSL-Bibliothek mitbringen, daher einfach

    PHP
    <?php phpinfo(); ?>


    In eine Datei schreiben und über den Webserver aufrufen. Darin sollte die genutzte (eventuell mehrere) SSL-Version aufgeführt sein.

    Fremde Zertifikate würde ich auf keinen Fall in WordPress Installieren.

    Wenn, dann die Zertifikate mit aktuelleren Versionen überschreiben, die aus offizieller Quelle kommen. Ebenfalls sollte die Zertifikats-Validierung nicht ausgeschaltet werden.
    In beiden Fällen könnten dritte den Server übernehmen.

    Jedenfalls sagt "certificate verify failed" ja, dass das Zertifikat, was der Updateserver sendet, nicht verifiziert werden kann.
    Also einmal die lokalen Zertifikate aktualisieren und gucken ob dann was geht.

    "ASN1" und "message digest" deuten auf einen Fehler bei der Verschlüsselung hin.

    Also höchst wahrscheinlich OpenSSL was HTTPS für den Server macht. Welche OpenSSL-Version kommt denn zum Einsatz? (Hängt evtl. auch vom Webserver und dessen config ab)

    Bei Requests für nicht vorhandene PlugIn-Dateien fällt mich auch zuerst ein crawler ein, der eventuell nach angreifbaren Blogs sucht.

    Mehr Informationen bietet der access-log vom Webserver, da wird jeder Zugriff, also auch erfolgreiche, festgehalten. Hosting-Provider schreiben das Log meistens in /log/access.log (relativ zum Hauptverzeichnis des Webservers), sonst ist er auf einem Linux-Server mit Apache unter /var/log/apache/access.log zu finden.

    Die Logs sind auch relativ einfach zu durchsuchen, in der Linux-Konsole kann man mit den Programmen cat und grep einfach alle Einträge zu einer Bestimmten Datei oder von einer bestimmten IP rausfiltern. Zum Beispiel:

    Code
    cat /var/log/apache/access.log | grep pluginname/ordner/datei.php

    In der Regel würde ich alles, was direkt auf PHP-Dateien von WP/Plugins zugreift, als nicht normalen Traffic einstufen. Die meisten Dateien werden ja nur von anderen Dateien eingebunden, normale Besucher haben wenig Grund z.b. die functions.php aufzurufen.

    Der Titel ist auf jeden Fall noch im HTML Quelltext. Nur werden manche durch CSS versteckt...
    In der style.css vom Theme ab Zeile 1133 steht die Regel (display: none). Warum die Regel nicht auf alle Posts angewandt wird erkenne ich grade nicht.
    Jedenfalls kann der Block ab Zeile 1133 auch gelöscht werden, wenn immer überall die Titel angezeigt werden sollen.

    Warum das Problem auf einmal auftritt... Vielleicht gab es ein Theme-Update?

    Kennst du dich etwas mit HTML, JavaScript und CSS aus?

    Es muss eigentlich nur ein Button/Link eingefügt werden mit onClick-Event (JS), das die Klasse/ID (irgendwas eindeutiges für die CSS-Regel) des Headers ändert.
    Wenn sich dann beim Klick darauf die Klasse/ID des Elements ändert, muss nur noch eine CSS-Regel für beide Möglichkeiten vorhanden sein, wobei die "Fullscreen-Regel" wohl einfach display:none; sein wird.

    Plugins wären mir nicht bekannt, da der Seitenaufbau durch das Theme bestimmt wird.

    Das Zertifikat ist für Wordpress.com ausgestellt. Da sollte eigentlich deine Domain drin stehen.

    Wo wurde es gekauft? Normalerweise muss beim Kauf die Domain mit angegeben werden.

    HTTPS bedeutet, dass SSL (genauer: TLS) zum Einsatz kommt. Ohne das 's' wird die Verbindung nicht verschlüsselt, das Zertifikat nicht übertragen.

    Edit: Habe dann auch mal den Thread-Titel gelesen...
    Durch get_template_directory_uri() wird als Bild ein Pfad zu einem Ordner angegeben.
    Da gar kein Bild angezeigt werden soll, kann auch die komplette Zuweisung für default-image weggelassen werden.

    Code
    [COLOR=#000000][COLOR=#0000BB]add_theme_support[/COLOR][COLOR=#007700]([/COLOR][COLOR=#DD0000]'custom-background'[/COLOR][COLOR=#007700], array(
            [/COLOR][COLOR=#DD0000]'default-color' [/COLOR][COLOR=#007700]=> [/COLOR][COLOR=#DD0000]'e5e5e5'[/COLOR][COLOR=#007700]));[/COLOR][/COLOR]

    Zum eigentlichen Problem:

    Was ist der Inhalt der .htaccess Datei im Hauptverzeichnis?
    Das Blog ist im root-verzeichnis des Webspaces installiert, normalerweise legt man dafür einen Unterordner an.

    Ist schon etwas länger her, dass ich eine frische WP Installation durchgeführt habe, aber ich meine man kann sogar beim Setup angeben dass WP in einem Unterordner liegt und WP gibt den passenden Code aus, der dann in die .htaccess im root-verzeichnis eingefügt werden muss. Dann greift man auch auf den Blog zu, ohne den Unterordner nach dem Domainnamen einzugeben. Manche Provider bieten auch die Möglichkeit, einzelne Domains auf Unterordner zu mappen, damit nichts weiter getan werden muss.

    edit: zu spät

    Beten wir, dass das DB-Passwort nicht auch das für FTP/Webinterface ist.

    Jah, die Logindaten für deine Datenbank + Secrets der WP-Installation öffentlich zu posten war... nicht das schlauste :roll:

    Jetzt bitte:
    Alle Logindaten in der MySQL-Datenbank ändern (alle Tabellen, auf die der User zugriff hat!)
    Neue WP-Secrets generieren und in die wp-config.php eintragen
    Neue Passwörter (unterschiedliche) für alle deine Accounts anlegen, die das selbe Passwort hatten (Hoster-Account, Mail, FTP?)

    Den error.log würde ich persönlich jetzt nicht öffentlich posten, da stehen die IP-Adressen deiner Besucher drin...

    Aber man sieht, dass mod_fcgid andauernd gekillt wird, weil...

    Code
    [Sun Nov 22 14:08:15 2015] [warn] mod_fcgid: process 24467 graceful kill fail, sending SIGKILL 
    [Sun Nov 22 14:08:17 2015] [warn] [client ] mod_fcgid: read data timeout in 40 seconds 
    [Sun Nov 22 14:08:17 2015] [error] [client ] Premature end of script headers: index.php

    Und hier endet mein Fachwissen. Google empfiehlt aber, den IO-Timeout zu erhöhen:
    http://serverfault.com/questions/4140…sending-sigkill

    Weißt du, ob der Server eine HDD, SSD oder RAID hat? Könnte sein, dass MySQL Queries zu lange brauchen, etwa weil die Festplatte zu langsam ist, und php dadurch einen Timeout kriegt und 500 Error ausgibt? Ist es ein Root Server oder VServer? Ein i7-4770 sollte die MySQL-DB sehr locker handlen können.

    Wie groß ist die MySQL-Datenbank, und auf welcher Hardware läuft der server?

    cat /proc/cpuinfo
    sudo fdisk -l

    Zeigen CPU-Modell und Festplatten-Modell (neben einigen anderen Informationen) an.

    Ich würde mal die Datenbanken bereinigen und optimieren, hat bei mir mal Server Error 500 im Admin-Panel gelöst. Auf dem kleinen Webspace war es sogar spürbar schneller, als ich die WP-Datenbanken manuell bereinigt habe, alte Post-Revisionen usw gelöscht habe. Was sagt die error.log vom HTTP-Server (apache)?

    Korrekt, mit dem width/height Parametern kann die Größe des Elements, also hier des Bildes, eingestellt werden.

    Auf der Seite ist aber die Originalgröße eingetragen. Wird irgend ein Cache-Plugin verwendet? Sind die Einstellungen definitiv gespeichert, oder werden die Änderungen im Admin-Panel einfach verworfen? Wenn eine andere Bild-URL eingegeben wird, wird dann das neue Bild angezeigt?

    Als Alternative könnte man das Bild noch in der kleineren Größe hochladen, damit der Browser das bild nicht skalieren muss, allerdings erhöht das natürlich die Seitenladezeit.

    Bei mir im Browser (Firefox 42) wird das Bild jedenfalls richtig angezeigt, wenn ich die Parameter im Inspektor (F12) ändere.