Beiträge von mensmaximus

    Danke für die Antwort. Der springende Punkt dürfte wohl sein, festzustellen, ob das Problem IMMER NUR bei dem einen User auftritt. Dann den User halt einfach nicht mehr verwenden und durch einen anderen ersetzen und die Sache ist vorbei.

    Ja das ist die Vorgehensweise ganz vieler Leute. Man nennt das auch symptomatische Fehlerbehebung. Der Grund ist dann aber nicht gefunden und kann jederzeit wieder auftreten. Man stelle sich vor es ist ein Hack. Aus diesem Grund rate ich immer zu einer kausalen Fehlerbehebung. Und Zeitersparnis ist bei möglichen Sicherheitsproblemen kein Argument.

    Dann müssen die Subdomains auf einen eigenen Webspace zeigen. Bei den meisten Anbieter gibt es die Möglichkeit Subdomains auf Verzeichnisse zu mappen. Dort installiert man dann jeweils ein WordPress. Zwei Installationen auf einem Webspace in Unterverzeichnissen mit Rewriteregeln ist im Regelfall aufwändiger und fehleranfällig.

    Adhoc würde ich sagen, dass bei dem User in der wp_usermeta Tabelle etwas nicht stimmt. Was genau kann ich nicht sagen. Ich würde mir alle Einträge in der Tabelle für diese User ID filtern und einzeln durchgehen ob mir etwas "seltsames" auffällt. Was "seltsam" ist eröffnet sich für das geschulte Auge relativ schnell.

    Also Deine zufällige Anzeige geht z.B. so:

    Code
    function mensmaximus_display_random_user() {
        global $wpdb;
        $users = $wpdb->get_results("SELECT user_nicename FROM $wpdb->users ORDER BY RAND() LIMIT 1");
        foreach ($users as $user) {
            echo $user->user_nicename . '<br />';
        }
    }
    add_shortcode('winner','mensmaximus_display_random_user');

    Dort wo Du den Shortcode [winner] einsetzt, erscheint ein zufällig ausgewählter Benutzername.

    Für ein komplettes Gewinnspiel mit Auswertung gibt es das Jobforum ;-)

    Also entweder ich bin heute zu doof oder Deine Erklärung ist unvollständig.

    1. Deine Single Installation besteht aus einer einzigen Seite. Erfolgt ein Zugriff ohne Proxy, über die IP oder den domainnamen (mit und ohne www) mit http oder https Protokoll, sorgt WordPress dafür, dass Du intern richtig umgeleitet wirst. Rufst Du über den Proxy auf, holt sich der Proxy die Inhalte vom hinterlegten Domainnamen oder der IP Adresse. Für WordPress ist das ein normaler Zugriff und da es nur eine Seite gibt, kann auch nur diese eine Seite ausgegeben werden.

    2. Die Multisite Installation liefert aber mehrere Seiten zurück und verwendet dazu einen Redirect, der Dich aus dem Proxy wirft. Der Redirect macht also den Unterschied.

    Versuche mal folgenden Code in Deiner wp-config.php:

    sslsite.de und meine-domain.de ersetzt Du mit den realen Namen (ich habe die Platzhalter von Dir übernommen).

    Ich befürchte aber das es wenig bringt.

    Das dürfte in den meisten Fällen in den normalen Shared-Webhostingpaketen nicht möglich sein.

    :shock: Vor 10 Jahren war das sicherlich ein Thema (weil nur IP basierend möglich) aber heute ist das doch Vergangenheit. Selbst der RIPE lässt als Grund für die Zuteilung mehrerer IP Adressen die Nutzung von SSL nicht mehr zu, weil fast alle aktuellen Webserver (nein der IIS kann es nicht) SNI unterstützen.

    Ansonsten einfach ein Paket buchen, dass es kann bzw. einen Provider auswählen der verstanden hat, dass Sicherheit eine wesentliche Rolle im Internet spielt.

    Den Hauptblog (http://www.meine-domain.de) leite ich mit dem "Quick Page/Post Redirect Plugin" auf http://www.meine-domain.de/de/ weiter, so dass ich im Prinzip zwei Blogs (/de/ und /en/) besitze.

    Bei meiner Multisite-Installation jedoch spielt es keine Rolle auf welche der beiden Wege ich meine test.html aufrufe - ich werde immer zu http://www.meine-domain.de/test.html weitergeleitet.

    Der Redirect macht den Unterschied. Angesichts der heutigen SSL Preise halte ich von den Proxy Lösungen nichts. Meine Empfehlung ist der Kauf eines Comodo PositiveSSL Zertifikates.

    Ich betreibe und verwalte viele Multisite Installationen im puren SSL Betrieb, SSL und Non-SSL gemischt als Subdomain und Multidomain Installation. Die beste Lösung ist immer ein SSL Zertifikat pro Domain oder ein Wildcard Zertifikat bei Subdomains.

    Hast Du schon mal das /plugins Verzeichnis umbenannt (z.B. /plugins.off). Es kommt/kam vor, dass manche Plugins (z.B. bbpress) die Benutzerrechte verändern. Wenn es dann immer noch nicht geht, musst Du Dir die Tabellen wp_users und wp_usermeta anschaun. Der User mit ID 1 muss z.B. den Level 10 haben. Ein Prüfung der wp-options Tabelle kann auch helfen. Stimmen z.B. die Einträge für siteurl und home? Auch das Filesystem kann den Fehler hervorrufen. Ändere alle Ordner auf 755 und alle Dateien auf 644.

    In den meisten Fällen ist es aber ein Plugin Problem.

    Es fehlt also noch das die Elternobjekte dich in der Größe nicht verändern wenn die Untermenüpunkte erscheinen.

    #navigation li ul {
    position: absolute !important;
    top: 110px !important;
    width: 100vw !important;
    }

    Das hilft Dir aber nicht wirklich. Ich hatte ja schon anfangs gesagt, dass das schwieriger wird. Über reines CSS lässt sich das meiner Meinung nach nicht sauber lösen. Was passiert denn wenn der letzte Menüpunkt rechts fünf Untermenüpunkte hat?

    Bei der Zeit, die Du da investierst, hätte sich der Kauf von UberMenu längst rentiert.

    Machen wir es anders. Wir bauen Dir ein Termin Feld in die Eingabemaske für Artikel (Posts) ein:

    Den Code kannst Du in Deine functions.php kopieren und abspeichern.

    Wenn Du jetzt post-new.php mit dem Parameter termin_id=xyz aufrufst, steht Deine Termin ID schon im Post.
    http://deine_domain/wp-admin/post-…&termin_id=Test füllt den Title, den Excerpt und die Termin ID mit dem Wort "Test" aus.

    Auf diese Weise spar ich mir jetzt die Erklärung von Custom Post Types ;-)