Beiträge von Demokrit

Du musst Dir lediglich einmal Bootstrap von der offiziellen Quelle downloaden. Dann hast Du alle Less Files. Alternativ nutze den BS-Customizer (mit verändertem Breakpoint für den navbar).

Schief gehen kann's nur, wenn der Theme-Ersteller eigene Less Files einkompiliert hat. Das kann man aber durch einen Vergleich zweier Versionen herausfinden.

Nein, nein - so geht das nicht. Bootstrap basiert auf Less, und Less bringt Variable in css. Der Breakpoint ist solch eine Less-Variable. Compiliert man Bootstrap, entweder mit einem dafür vorgesehenen Paket (js oder php) ODER mittels des direkt auf der Bootstrap Site verfügbaren Customizer (http://getbootstrap.com/customize/), so wird aus Variablen und dem css Basiscode das endgültige Bootstrap.

Für einen Test solltest Du den Breakpoint im Customizer ändern - aber natürlich nur den, der für den Collapse des Menüs zuständig ist. Änderst Du den Breakpoint generell, so verlierst Du fast alle sinnvollen Eigenschaften von BS.

Für ein schnelles Verständnis von Less sind die Sourcefiles (*.less) hilfreich. Die sind Teil jedes Bootstrap Downloads. Für Dich relevant dürfte navbar.less sein.

Oh, das Theme kenne ich leider nicht. Da scheint jemand sehr ähnliches zu machen, wie ich derzeit. Hier scheint die Basis "Twentythirteen" zu sein :-)

Sollte aber egal sein. Auch wenn ein "statisches" Bootstrap vorgegeben sein sollte (also eines, bei dem die less-Files nach Bedarf nicht neu kompiliert werden), so basiert der Redux Navbar sicher auf einem ähnlichen Template. Der navwalker erzeugt lediglich die geschachtelten Listen. Wo genau dies geschieht, ist Theme-spezifisch.

Der Breakpoint steht trotzdem im css. Per default steht er auf @grid-float-breakpoint : @screen-sm-min; (@screen-sm-min = 768px). Sollte in dem Theme ein bereits kompiliertes BS genutzt werden, so wirst Du den Breakpoint wohl nicht einfach verändert bekommen. Hier kann nur der Theme Entwickler helfen.

Ein Ansatz könnte sein, ein vorher mit anderem Breakpoint neu kompliertes Bootstrap in das Theme einzumogeln. Dazu müsste man wohl aber tiefer eindringen.

Moin in die Runde,

bin hier noch relativ neu, aber mir fehlt schon etwas. Ein Entwicklerforum. Möchte man beispielsweise ein komplexeres Theme erstellen, so kratzt man automatisch auch am Thema Plugin. Diesen Post möchte man nun einordnen, und hat "Design" oder "Plugin" zur Wahl.

In beiden Bereichen geht es zu 85% um Fragen wie "ich nutze Plugin/Theme xyz und möchte meine H1 gerne in rot". Soll heißen, Fragen zur Entwicklung von Themes oder Plugins werden ungesund vermischt mit Fragen zur Verwendung Selbiger. Beide Fragenbereiche sind legitim, und sollten m.E. getrennt werden.

Deshalb Vorschlag: Neuer Hauptbereich: Entwicklung

Grüße,

Thomas

Falls Du den "wp_bootstrap_navwalker" von Edward McIntyre meinst. Der hat nichts damit zu tun. Der Breakpoint ist eine Eigenschaft von Bootstrap. Du findest ihn in der "variables.less" von Bootstrap.

Ich poste mal mein Template für die Menügenerierung:

<!-- Fixed navbar -->
<div class="navbar navbar-inverse navbar-fixed-top tsbs-top-menu" role="navigation">
    <div class="container">
        <div class="navbar-header">
            <button type="button" class="navbar-toggle collapsed" data-toggle="collapse" data-target=".navbar-top-collapse">
                <span class="sr-only">Toggle navigation</span>
                <span class="icon-bar"></span>
                <span class="icon-bar"></span>
                <span class="icon-bar"></span>
            </button>
            <a class="navbar-brand" href="<?php echo esc_url(home_url('/')); ?>" rel="home"><?php bloginfo('name'); ?></a>
        </div>
        <div class="navbar-collapse collapse navbar-top-collapse">
            <?php
            wp_nav_menu(array(
                'theme_location' => 'top_menu',
                'depth' => 2,
                'container' => false,
                // 'container_class'   => 'collapse navbar-collapse navbar-top-collapse',
                'menu_class' => 'nav navbar-nav',
                'fallback_cb' => 'wp_bootstrap_navwalker::fallback',
                'walker' => new wp_bootstrap_navwalker())
            );
            ?>
            <ul class="nav navbar-nav navbar-right">
                <li class="dropdown">
                    <?php if (is_user_logged_in()) : ?>
                        <a href="#" class="dropdown-toggle" data-toggle="dropdown"><span class="glyphicon glyphicon-user"></span> <span class="current-user"><?php $current_user = wp_get_current_user(); echo $current_user->display_name; ?></span> <span class="caret"></span></a>
                        <ul class="dropdown-menu" role="menu">                        
                            <li><a href="<?php echo wp_logout_url(home_url()); ?>" title="Logout"><span class="glyphicon glyphicon-log-out"></span> <?php _e('Logout', 'bootstrapped'); ?></a></li>
                        </ul>                            
                    <?php else : ?>
                        <a href="#" class="dropdown-toggle" data-toggle="dropdown"><span class="glyphicon glyphicon-user"></span> <span class="caret"></span></a>
                        <ul class="dropdown-menu" role="menu">                            
                            <li><a href="<?php echo wp_login_url(get_permalink()); ?>" title="Login"><span class="glyphicon glyphicon-log-in"></span> <?php _e('Login', 'bootstrapped'); ?></a></li>
                            <li class="divider"></li>
                            <li class="dropdown-header"><?php _e('get involved', 'bootstrapped'); ?></li>
                            <li><a href="#"><a href="<?php echo wp_registration_url(); ?>" title="Register"><span class="glyphicon glyphicon-leaf"></span> <?php _e('Register', 'bootstrapped'); ?></a></li>
                        </ul>                            
                    <?php endif; ?>


                </li>
            </ul>


            <form id="searchform" class="navbar-form navbar-right" role="search" action="<?php echo esc_url(site_url()); ?>" method="get">
                <div class="form-group">
                    <input id="s" name="s" type="text" class="form-control" placeholder="<?php esc_attr_e('Search &hellip;', 'bootstrapped'); ?>" value="<?php echo esc_attr(get_search_query()); ?>">
                </div>
                <button id="searchsubmit" type="submit" name="submit" class="btn btn-default"><span class="glyphicon glyphicon-search"></span></button>
            </form>                    
        </div><!--/.nav-collapse -->
    </div>
</div><!-- /Fixed navbar -->

Du siehst, der navwalker wird einfach in statischen Markup eingeklinkt. Zugewiesene Icons werden hierbei in allen Ansichten vorangestellt, mobil wie Desktop.

Ja, der Artikel ist ausgezeichnet. Danke für den Link.

Er beschreibt aber eher, was ich unter "Baustelle B" gelistet habe. Ich beobachte die Diskussion um neue Tags für responsive Images bereits seit einer ganze Weile. Im November 2013 war der neue "picture" Tag klinisch tot, jetzt scheint er wieder im Rennen. Auch wenn ihn heute bereits einige Browser unterstützen, so fehlt mir noch das klare Commitment: "Ja, das ist der Weg der Zukunft". Ein wesentlicher Grund für die Nutzung von Bootstrap ist für mich, dass es für einen PHP Entwickler schier unmöglich ist, hinsichtlich Browser-Nickeligkeiten und CSS-Entwicklung auf dem Laufenden zu bleiben. Man arbeitet bereits an Bootstrap 4, und ich denke, da wird auch ein Ansatz für responsive Assets enthalten sein. Soll wohl auch früher kommen, als erwartet.

Zur Implementation muss man natürlich noch mehr Einfluss nehmen auf die Markup Generierung seitens WP. Gerade deshalb such ich derzeit die "kleine Lösung" für zwischendurch.

Das alles sprengt auch längst den Rahmen eines Themes. 30% meines derzeitigen Codes gehörte eher in ein Plugin, denn eigentlich müsste man das gesamte Image-Rendering austauschen. Das ist ne harte Nuss.

Hallo in die Runde,

===
Spoiler: Der nachfolgende, sehr lange Beitrag richtet sich vorwiegend an Entwickler mit "responsiven" Kenntnissen und der Absicht, etablierte CSS Frameworks zu nutzen, wie Bootstrap oder Foundation.
===

ich arbeite erst seit kurzem an und um Wordpress, entwickle aber bereits viele Jahre mit php im Umfeld CMS u.Ä. Um den Einstige zu finden, erstelle ich seit ca. 3 Wochen ein Bootstrap 3.2 basierendes responsive Theme. Meine Basis dafür war "Twentyforteen", zusammen mit Einblicken in andere, bereits vorhandene Bootstrap Themes. Alles bisherige klappt bestens. Soll heißen: Featured Content, Custom Headers, Widget-Bereiche, mehrere Navigationselemente, Post Thumbnails. Alles ist responsive und spricht jetzt "Bootstrap". Den Bloat an Wordpress Klassen habe ich erst mal beibehalten, habe Bootstrap typische Klassen hinzugefügt. Wirkliches Aufräumen folgt dann am Schluss. Mein Theme erstelle ich für meine private Site, habe also auch keine Probleme, es nach Fertigstellung der Community zu geben.

Nicht gekümmert hatte ich mich bislang um den Content-Bereich, und genau hier beiße ich jetzt auf eine Nuss, die ich nicht geknackt kriege. Es geht um Bilder (oder Ähnliches) im Content. Man neigt natürlich dazu, alles, was das BE unterstützt, auch umzusetzen. Dazu zählen links oder rechts floatende Bilder, mit oder ohne Caption.

Ich suche hier nicht unbedingt die "Lösung" meines Problems, sondern würde lieber das Thema "responsive Images im Text" abstrakt diskutieren.

Im ersten Schritt habe ich mir mal Image Handling bei etablierten Redaktionssystemen angeschaut. SPON, Süddeutsche und Guardian benutzen, auf Wordpress Sprech übersetzt, ausschließlich Post-Thumnails und Gallerien (Bilderstrecke). In-Content Images kommen nicht vor. Noch nicht mal als Block-Elemente, die einfach zu realisieren wären. Keine der Sites hat den Anspruch, responsive zu sein - es wäre somit Pipifax, In-Content Bilder zu nutzen. Tun sie aber nicht.

Damit ein Bild responsive im Text floaten kann, darf es ruhig Breite und Höhe haben. Width und Height sind zwar ein Anachronismus, aber unter dem leidet nicht nur Wordpress. Viel wesentlicher ist, dass das Elternelement weiß, wie breit das Bild ist.

Mit Bordmitteln erzeugt Wordpress folgenden Markup für ein links floatendes Bild mit Caption:

<figure class="wp-caption alignleft" id="attachment_50" style="width: 150px;">
    <a href="http://www.unkommod-local.eu/wp-content/uploads/2014/09/galaxy1-cf435d8ad176142a.jpg">
        <img height="150" width="150" alt="Der ALT" src="http://www.unkommod-local.eu/wp-content/uploads/2014/09/galaxy1-cf435d8ad176142a-300x219.jpg" class="wp-image-50 size-medium">
    </a>
    <figcaption class="wp-caption-text">
        Die Beschriftung
    </figcaption>
</figure>

Man erkennt das Problem schnell. Die Klasse "size-medium" klebt nicht am Elternelement "figure", sondern am Bild, wo sie überhaupt keinen Sinn macht (zumindest nicht, bevor jemand den Parent-Selektor im css erfunden hat). Wahrscheinlich hängt die Klasse sinnlos am IMG Tag, weil bei Abwesenheit eines Caption keinerlei Wrapper ausgegeben wird, sondern nur der blanke IMG-Tag. Warum eigentlich? "figure" ist auch ohne "figcaption" zulässig.

Gestern habe ich eine Lösung auf Basis des "img_caption_shortcode" Filters erstellt, die funktioniert - zumindest für im System fest vorgegebene Bildergrößen. Der erzeugte Markup sieht so aus (diesmal einige WP Klassen weggelassen):

<figure class="wp-caption pull-left size-medium" id="attachment_50">
    <a href="http://www.unkommod-local.eu/wp-content/uploads/2014/09/galaxy1-cf435d8ad176142a.jpg">
        <img height="150" width="150" alt="Der ALT" src="http://www.unkommod-local.eu/wp-content/uploads/2014/09/galaxy1-cf435d8ad176142a-300x219.jpg" class="wp-image-50 img-responsive">
    </a>
    <figcaption class="wp-caption-text">
        Die Beschriftung
    </figcaption>
</figure>

Die Klasse "size-medium" erhält hier eine Breite in % (Bild zu Text-Verhältnis). Das Bild (max-width: 100%;) füllt sie immer komplett aus, und wird somit responsive. Über Media-Queries nimmt man es ab einem definierten Breakpoint aus dem Textfluss, und gut ist. Tut man dieses nicht, so floated das Bild auch bei kleinsten Displays neben dem Text - im korrekten Verhältnis. Da es mir nicht möglich war, im Filter an die IMG-Klasse zu gelangen (ausser den $content zu filettieren), musste ich die "$atts['width']" abfragen, um zu ermitteln, um welche Bildklasse es sich wohl handeln mag. Das ist übler Bastelkram, und auch nicht geeignet, beliebige Bildabmessungen (arbitrary) zuzulassen. Ich scheitere letztendlich daran, dass ich zwei Filter kombinieren, und aus dem ersten (image_send_to_editor), die Bildklasse in den zweiten (img_caption_shortcode) übergeben müsste. Das geht nicht.

Jetzt, da meine Bastelkramlösung fertig ist, stelle ich mir die Frage, ob floatende Bilder im Text überhaupt noch zeitgemäß sind. Sinn machen diese, in Bootstrap Sprech, nur bei col-md-x und col-lg-x Spalten, oder bei winzigen Icons, die wiederum nicht responsive sein müssten.

Wäre es ein tolerabler Ansatz zu sagen, in einem wirklich responsivem Wordpress Theme von "heute" gibt es keine im Text floatenden Bilder? Mit diesem Paradigma wäre es sehr einfach, Bilder beliebiger Größe responsive und sauber auszugeben. Dies ginge voraussichtlich unter ausschließlicher Nutzung von "img_caption_shortcode". Nach folgendem Ansatz:

1. Jedes IMG / FIGURE-IMG bildet eine Bootstrap row.
2. Anhand der hardcodierten Bildbreite ($atts['width']) werden geeignete Bootstrap column Klassen gewählt (idealerweise berücksichtigt man diese bereits bei der Wahl der Standard Bildformate).
3. Ist diese Bootstrap Klasse eine col-x-12 Klasse, so ist jede Align-Einstellung sinnlos (ignore align). Ist die Klasse < 12, so nutzt man Bootrap col-x-offset- Klassen für die Ausrichtung innerhalb der Zeile. So behalten die Steuerelemente im BE ihre Bedeutung.

Vorteile:

1. Bilder sind trotz old-school Größenangaben automatisch responsive.
2. Auf kleinen Devices "stacken" sie automatisch richtig
3. Ohne custom css oder js und ohne tiefen Eingriff in WP Image Klassen (es wird lediglich die img-responsive Klasse zu allen Bildern hinzugefügt)
4. Identisches Vorgehen nutzt man bei Bootstrap basierenden Galerien sowieso - Images werden in grids gepackt, der Code kann also wiederverwendet werden.

Nachteile:

1. Kein Bild-im-Text
2. Kleines Devices erhalten Desktop Bildgrößen ausgeliefert. Aber das empfinde ich derzeit als Baustelle B - oder als PAL - ein Problem anderer Leute.

Wie wäre Eure Denke dazu? Opfert man "Bild-im-Text", so gewinnt man eine banal einfache Lösung.

Mein Königsweg wäre:

1. Kein zusätzliches JS
2. Kein Custom CSS (pure Bootstrap), außer es geht um wirkliches Styling. Keine Styles, die nur Markup Defizite in WP beheben (das geht auf Dauer immer schief).

Bin gespannt zu erfahren, wie Ihr das handhabt, bzw. handhaben würdet.

Grüße,

Thomas

Zitat von mensmaximus

Willkommen im Club! Ein indischer Freund von mir und ich hatten die dumme Idee ein Theme zu entwickeln, dass keinen PHP Code mehr in den Templates enthält ;-) Strickte Trennung von Code, HTML und Styling. Den Geist hätten wir mal besser nicht gerufen - jetzt hält er uns wach.

Ja, ich kenne die "reine Lehre". Auch beim Zend Framework gab es ellenlange Diskussionen, ob php in die View darf. Bei TYPO3 ist alles strikt getrennt, aber anstatt auf etablierte Standards zu setzen, hat man lieber eigene Paradigmen entwickelt, deren Überambitioniertheit heute sogar mich vom Projekt TYPO3 abgeschreckt hat. Und meine Leidensfähigkeit ist ziemlich groß :-)

wow - so schnell - danke Euch beiden.

SirEctor:
Ja, natürlich kann ich das ul über css addressieren und ihm eigene Styles aufzwingen. Mein Problem ist per css lösbar. Mir geht es aber im Endausbau meines Themes um Automatismen, die auch automatische Style-Generierung einschließt (php Less Autocompiler). Ich möchte also Bootstrap Styles nicht durch WP-spezifische zusätzlich aufblähen. In der style.css soll bei mir eine (ab Werk) leere Definition für z.B. widget_categories stehen. Hier soll dann das endgültige Nutzer Styling statt finden. Möglicherweise denke ich aber zu perfektionistisch.

mensmaximus:
Hab's gerade getestet. Klappt wunderbar bei den Kategorien, beim Archiv scheint's nicht so einfach. Ich denke, ich werde einen Mischbetrieb aus css (wo's nicht besser geht) und custom-menue (wo's geht) wählen.

Und wenn mal Langeweile aufkommen sollte, kann man immer noch einen Widget Generator schreiben, der sich alles reinpfeift, was ab Werk oder per Plugin angelandet wird, dieses dann semantisch und accessible aufbereitet und wieder zurück in's System spuckt. Wäre wahrscheinlich der Königsweg. Aber dazu brauche ich mehr Einblick ins System.

Hallo in die Runde,

mein erster Post, nach erstmaligem Kontakt zu WP vor 10 Tagen. PHP ist mir nicht fremd. Ich habe Jahre an und um TYPO3 gearbeitet, kenne ZF, OOP und Derivate sowie auch die verschiedensten Templating Engines. WP erscheint mir bestens dokumentiert und ich hatte keinerlei Probleme, meine WP Entwicklungssite aufzusetzen.

Mein erstes Projekt ist ein Theme auf Basis Bootstrap 3.x.x. Gibt's schon 100fach, aber ich will Verständnis, und es deshalb selber machen. Alles klappt wie es soll. Responsive Navbar, 2-3 andere Navigationselemente, die Inhaltsbereiche, die Seiten, alles funktioniert wunderbar mit Bootstrap, inklusive responsive media. Mit einer gravierenden Ausnahme. Den Widgets.

Im Quellcode erkennt man, dass der Markup statisch "verdrahtet" ist. Der ul-Tag im Kategorien-Widget hat keine Klasse, und es gibt auch keine Bordmittel-Methode, ihm eine zu spendieren. Erkennt man auch an allen aufgefundenen anderen Bootstrap Themes, die an gleicher Stelle "gescheitert" sind.

Jetzt sehe ich mehrere Ansätze, das Problem zu lösen:

1. Per css, indem man die WP Widget Klassen in seine Bootstrap Less Files aufnimmt (und somit dupliziert, und aufbläht). Gefällt mir nicht wirklich, denn unnötige Redundanz führt mittelfristig immer zu Ärger. Mein Theme soll Bootstrap nach Bedarf auch neu kompilieren, und in style.css möchte ich ab Werk nur leere Klassen, zum individuellen Styling durch die Nutzer.
2. Per Javascript die Klassen tauschen: Kein Problem, ist aber übelster Bastelkram. Kommt nicht in Frage.
3. Klassentausch per PHP. Gesamten Sidebar mittels output Buffering in Variable einlesen, und Klassen austauschen. Technisch kein Problem, fühlt sich aber falsch an (und hebelt ggf. das Caching aus???).
4. Widgets mit geändertem Markup (i.e. einer zugefügten Klasse) im Theme duplizieren (class MyBootstrap_Widget_Recent_Posts extends WP_Widget_Recent_Posts). Gigantischer Overkill, nur um eine popelige Klasse hinzuzufügen.
5. Navigationsartige Widgets (Categories, Archive, Latest Posts...) durch Custom-Menues ersetzen und im BE als Widget ausblenden.

Vielleicht habe ich ja eine Möglichkeit übersehen? Gangbar sind alle Wege. Der am wenigsten falsch wirkende wäre Nr. 5, der flexibelste Nr. 3 (vorausgesetzt, er hat keinen zu großen Performancenachteil). Wie wären Eure Gedanken zu dieser Problematik?

Bin dankbar für jeden Input.

Grüße,

Thomas