Beiträge von helix

    Es könnte daran liegen, dass noch irgendein float aus deinem Headerbereich wirksam ist. Probiere einmal, deinem #main noch ein clear zu verpassen:

    Code
    #main {
        width: 720px;
        padding: 20px;
        float: left;
        margin-left: 50px;
        clear: both;
    }

    Wenn das nicht klappt, können wir weitersuchen.

    Gruß
    helix

    Nein, nicht direkt beim Bearbeiten des Formulars.
    Du hast in deiner Admin-Menüleiste (normalerweise die schwarze Leiste links) unter „Kontakt“ oder „Formulare“ oder-wie-auch-immer auch den genannten Unterpunkt „Integration“. Dort findest du die Stelle(n), an denen du deine beiden Schlüssel eingibst. Und danach im Formular dieses ReCaptcha-Tag einfügen.

    Gruß
    helix

    Also vielleicht solltet ihr folgendes noch wissen.
    Ich habe die Seite am Anfang auf dem Unterordner /v2 installiert, dort hat alles wunderbar geklappt. Nach dem Umzug in das Rootverzeichnis ist der Fehler aufgetreten und alle Lösungsvorschläge die hier genannt wurden, bzw. die ich bei Google finden konnte führten zu keinem Erfolg.

    Selbst eine Neuinstallation von Wordpress hat nicht geklappt.


    […] und hol dir dieses Plugin suche und ersetze nochmals alle URLs

    https://wordpress.org/plugins/better-search-replace/

    Ich hab alles neu installert = ohne Erfolg
    neuer User = ohne Erfolg

    Naja, wenn ich neues Wordpress raufmache funktioniert es in der Subdomain, aber nicht im Hauptverzeichnis.

    Für mich „riecht“ das sehr danach, dass eben doch der Umzug von Unterverzeichnis auf Root nicht richtig / vollständig gemacht wurde.
    => Auch die htaccess angepasst?
    => Alle Domain-Routing-Einstellungen beim Hoster oder alternativ htaccess im Rootverzeichnis etc. ???

    Gruß
    helix

    Indem du erstmal rausfindest, wie sich das Theme responsive verhält: Welche Elemente verändern (wann und wie) ihre Größe oder ihre Position. Das kannst du einerseits beobachten, Browserfenster mal einfach zusammenschieben. Andererseits in der Stylesheetdatei gucken, was da definiert ist. Für das responsive Verhalten sind sogeannte Media Queries verantwortlich, die beginnen im Stylesheet immer mit Media, kannst du also über die Suchen-Funktion im Editor-Programm leicht finden.

    Die Logik von diesen Media Queries ist: Wenn die Größe vom Ausgabegerät / Browserfenster größer oder kleiner wird als ein bestimmtes Maß (da gibt es unterschiedliche Ansätze, ob man das von groß nach klein oder von klein nach groß organisiert), werden die relevanten ids oder Klassen anders definiert.

    Du musst also nicht nur generell die Maße anpassen, sondern auch gucken, dass bei den veränderten Definitionen bei den Media Queries auch noch alles zusammenpasst.

    Für die Bildbreite gibt das Theme eigentlich alles schon richtig vor. Da ist (wenn ich nix übersehen habe) definiert

    Code
    img {
        height: auto;
        max-width: 100%;

    Das heißt „übersetzt“: Das Bild wird in seiner Originalgröße ausgegeben, es darf aber nicht breiter sein als die Breite vom umschließenden Element (der Inhaltsbereich). Wenn der Inhaltsbereich schmaler ist, als die Bildbreite, wird das Bild verkleinert. Die Höhe (auto) wird so angepasst, dass die Proportionen erhalten bleiben.

    Du musst das Bild nur groß genug hochladen und auch ausgeben. Was ich vorhin gesehen hatte, mit der image-size large, das muss von dir kommen (beim Einfügen des Bilds, da kannst du die Größe auswählen), auf der Demo vom Theme ist es nämlich in Fullsize ausgegeben (nein, large ist nicht größer als full ;-))

    Gruß
    helix

    Das ist schon möglich, es gibt ziemlich sicher sogar mehrere bis viele Wege zum Erfolg,

    ABER,

    bevor wir jetzt mit gemeinsamen Kräften mal hier und mal da und mal dort was verschlimmbessern, vielleicht doch erstmal kurz stehen bleiben, Seite ansehen und sich die Frage stellen: was mach ich da eigentlich?

    Durch deine Anpassung der Seitenbreite ist das Design nicht mehr responsive, d.h. bei kleinerem Browserfenster wandert die gepunktete Linie seitlich in den Text.
    Gewollt? Ich glaube kaum …

    Für dein Video ist das Tool zum Einbetten des Video verantwortlich.

    Die Bilder werden vom Theme in der image-size large ausgegeben. Und die ist mit 640 Pixeln definiert. Kannst du entweder unter Einstellungen -> Medien verändern (greift dann aber erst für Bilder, die von da an neu hochgeladen werden) oder, wenn es im Admin-Bereich ausgegraut ist, in der functions.php

    Oder du veränderst dein Seitentemplate dahingehend, dass die Bilder in der image-size full ausgegeben werden und passt es per css an die Breite vom Textbereich an.

    Gruß
    helix

    Das ist kein Grund, rot zu werden.

    Wenn man ein eigenes Theme aus eigenem Design erstellt – und so hatte ich deine Frage verstanden – braucht man diese body-class in den meisten Fällen gar nicht. Da stelle auch ich mir die Frage: Warum soll ich den Server Code ausgeben lassen, der gar nicht gebraucht wird?
    Aber für solche Anwendungsfälle wie Admin-Bar, die sich mit absolut positionierten Kopfzeilen ins Gehege kommt, ist es dann super-nützlich, dass WordPress die passenden Klassen out-of-the-box kann.

    Gruß
    helix

    Sieht so aus, dass du dein Logo nicht richtig referenziert hast.

    Also Code im Prinzip so:

    PHP
    <div id="header">
        <center>
            <a href="<?php echo site_url(); ?>">
                <img src="" />
            </a>
        </center>
    </div><!-- header -->

    und dann fürs Bild, je nachdem, in welchem Verzeichnis du es liegen hast

    PHP
    <img src="<?php bloginfo('stylesheet_directory'); ?>/img/logo.png" />


    oder, wenn es im upload-Verzeichnis liegt

    PHP
    <img src="<?php echo site_url(); ?>/wp-content/uploads/logo.png" />

    Gruß
    helix

    Sieht so aus, als ob du bisher lediglich das Standard-WordPress-Menü drin hättest, das einfach alle Seiten anzeigt, die du angelegt hast. Schau mal (kenne das Theme nicht, daher nur ein allgemeiner Tipp), dass du ein eigenes Menü generieren kannst, in das du nur die Seiten ziehst, die du im Menü haben willst und das du dann der Layoutposition Headernav (wie auch immer die Position im Theme benannt ist) zuordnest.

    Gruß
    helix

    mein Editor funktioniert nicht mehr. Also der HTML Editor zwar schon, aber der VISUALL nicht mehr. Egal ob das bei Beiträgen, Seiten, oder sonst wo.

    Bin IT-Informatiker vom Beruf, also das ist das erste was ich mache :D

    Hm, dürfen wir da von dir auch eine etwas fundiertere Fehlermeldung erwarten?
    Interessant wäre doch z.B. die Frage: erscheint der Tab für „visuell“ und lässt sich nur nicht klicken? Oder ist der Tab schon gar nicht mehr da?

    (Wenn ich einen Fehler finden will, frage ich, ob er reproduzierbar ist. Und wenn ja: wie ist der Fehler reproduzierbar? Das ist meistens schon die halbe Lösung. Das funktioniert übrigens auch in der analogen Welt …)

    Gruß
    helix

    Kannst du mal bitte einen Link zur Seite posten? Danke.

    Gruß
    helix

    … tschuldigung, Unsinn, Link ist ja da …

    … und soweit ich das sehen kann, würde das bei mir auch so funktionieren, wie von maxe vorgeschlagen.

    Fehlerträchtig ist, dass du jeden Button mit inline-Style im Element einzeln formatierst. Schreibe lieber den Code von maxe in die style.css, dann gilt er für alle diese Buttons.
    => Also komplett, alle Styles für die Buttons, wie von dir in Post #3 gelistet. Aber eben für .social-share-button a (heißt übersetzt: alle Links innerhalb eines Elements mit der Klasse social-share-button werden so dargestellt)

    Ja, das ist irgendwie doof, wenn man Änderungen an Originalen vornimmt und nicht penibel dokumentiert.

    Aber es ist kein Weltuntergang. Funktionieren tut es ja. Und „sollte“ ist das richtige Wort. Du hast Zeit bis zum nächsten Update von deinem Theme.

    Gruß
    helix

    Äh nein. Das Child-Theme ist genau dafür da, dass du deine ganzen Anpassungen und Änderungen ins Child-Theme schreibst. Wenn dann das parent-Theme aktualisiert wird, werden deine Änderungen nicht überschrieben, weil die ja im Child-Theme stehen.

    Das Child-Theme besteht zunächst nur aus einer style.css und einer functions.php.
    In der functions.php legst du fest, dass die styles vom parent-Theme mit eingebunden werden. Änderungen am Styling trägst du in deiner css vom Child-Theme ein. Soweit, so gut.

    Wenn du nun an irgendeiner Stelle andere Inhalte ausgeben willst, schnappst du dir die Datei aus dem Parent-Theme, das für diesen Bereich zuständig ist, speicherst sie unter gleichem Namen im Child-Theme ab und nimmst dort, im Child-Theme deine gewünschten Änderungen vor.

    Gruß
    helix

    Nein, mit margin und padding kommst du bei absolut positionierten Elementen nicht weiter. Da musst du top: Abstandx; eingeben. Und Abstand x ist die Höhe der Admin-Bar.
    Ich hoffe, du hast deinem body-tag die wp Body-Class verpasst. Du solltest es im Stylesheet so definieren, dass dieser Abstand nur gegeben wird, wenn body die Klasse .admin-bar oder .logged-in hat.

    Alternative ist, du schaltest dir die Admin-Bar aus. Für dich persönlich in deinem Profil im Admin-Bereich von WordPress.
    Generell (wenn du es z.B. zum Zeigen brauchst) kannst du es auch in der wp-config.php ausschalten.

    Gruß
    helix

    Im Prinzip müsstest du das wie Baukasten machen können:

    Pack die Zeile mit der sidebar-left vor deinen Content-Bereich, also direkt hinter die Zeile get_header. Dann das ganze Content-Gedöns. Und da, wo jetzt drei Zeilen zum Einbinden von Sidebars stehen, bleibt die sidebar-right.

    Die zugehörigen php-Dateien, was dir als Sidebar ausgegeben wird, solltest du nochmal bürsten, im Moment tragen beide Sidebars die id #primary-sidebar.
    IDs sind eindeutige Bezeichner für Elemente, die auf jeder Seite nur einmal vorkommen.
    Also z.B. dann für die rechte Sidebar einfach die id #secondary-sidebar vergeben. Dann kannst du die Dinger auch im CSS sauber getrennt ansprechen, einmal mit float: left; einmal float: right; … (Du hast die eindeutigen Bezeichnungen als Klassen vergeben; vielleicht hast du hier die Logik einfach vertauscht. Mit den Klassen, das funktioniert so, aber mit den ids, da kannst du dir so, wie es jetzt ist, Probleme mit einhandeln …)

    Gruß
    helix

    Das Problem ist nur, dass ich die im Autorenbereich geschriebenen Inhalte noch mit speziellen Klassen versehe um sie per css anzusteuern bzw. die HTML Struktur klarer zu gestalten. Das heißt jede Unterseite wird wieder anders behandelt.

    Eigentlich nicht wirklich ein Problem.
    Mach mal erst einen Plan (hast du wahrscheinlich schon ;-)), was du wo brauchst, was gleich ist und was unterschiedlich …

    Schau mal hier: http://www.texto.de/wie-du-eine-si…en-kannst-2122/
    das ist eine Anleitung von Monika hier aus dem Forum, einen OnePager mit dieser ChildPage-Option umzusetzen. Sie nutzt ein benutzerdefiniertes Feld für die Sprungmarken. Du bist selbstverständlich frei, benutzerdefinierte Felder für ids oder Klassen zu nutzen … Also z.B. für die Klasse .publication (oder anderes) für das umschließende div. Die Klassen für Titel und Autor kannst du gleich im Loop definieren, .media (hier ist doch gemeint, wo publiziert?) wäre dann wieder ein Fall für ein benutzerdefiniertes Feld …

    … und

    PHP
    wp_reset_postdata();

    bringt dich auf die Spur, wie das generell mit multiplen Loops geht …

    Und nein, ich glaube nicht, dass es irgendwie einfacher sein kann, das Markup im Editor einzufügen / von anderen, potentiell Unbedarfteren einfügen zu lassen. Das ist schon für Leute, die keine Angst vor spitzen Klammern haben, ein fehleranfälliges Unterfangen.

    Aber es ist natürlich die Frage, wieviel Zeit und Energie du in das Projekt stecken kannst und willst.
    Wenn es für dich ein Projekt ist, dich tiefer in WordPress einzuarbeiten – du die Arbeit, die du reinsteckst, also irgendwie für dich als „Weiterbildung“ verbuchen kannst, dann gönn dir den Spaß …

    Gruß
    helix

    Diese Lösung ist auch sehr gut.

    Welche Lösung für welches Projekt gut ist, hängt immer von vielen Faktoren ab. Die wichtigsten sind:
    * die Frage, wieviel Entwicklung / Veränderungen / Wachsen auf der Seite zu erwarten ist
    * die Frage, was für diejenigen „logisch“ ist, die die Seite nachher pflegen (sollen)

    So wie du es jetzt gelöst hast, musst du es für jedes Vorkommen von ich-möchte-mehrere-Childseiten-auf-ihren-Parentseiten-ausgeben extra definieren.
    Wenn Childseiten nur für eine solche Anordnung zur Verwendung kommen sollen, kannst du die Ausgabe auch generalisieren => if-Abfrage, ob die Seite Childseiten hat, wenn ja, alle ausgeben lassen, Sortierreihenfolge sinnvollerweise menu-order.

    Möglich ist auch, statt Childseiten Beiträge jeweils einer bestimmten Kategorie anzulegen und dann jeweils festzulegen: gib auf Seite 1 Kategorie x aus, auf Seite 2 Kategorie y etc.

    Gruß
    helix