Beiträge von Am Ende des Lateins

Verstanden.

PS.:

Das Widget ermöglicht auch eine zweispaltige Darstellung; dann tritt das gleiche Problem auf.

Wenn ich versuche, dieses Problem analog mit

.dcw_c2 {
    float:none !important;
}

zu lösen, wird das Problem aber nicht (richtig) behoben.

Zitat

Lad sie doch einfach übers Forum hoch.

Weil ich die Möglichkeit dazu nicht gefunden hatte, sondern nur angeboten bekam, die Bild-URL einzugeben.

Zitat von SirEctor

Warum stellst du Screenshot beim Eröffnen der Frage ein und löschst diese kurze Zeit später wieder?

Weil ich die Bilder der Bequemlichkeit in meine WP-Mediathek hochgeladen hatte und sie mir diese aber unübersichtlich machten, sodaß ich da aufgeräumt habe. Sorry.

Danke. Mit

.dcw_c1 {
    float:none !important;
}

in meinem child-Style Sheet klappt es; ohne "!important" nicht.

Ich habe gerade das Plugin "Display Categories Widget" installiert, um mir in einem Widget die Unterkategorien zu einer bestimmten Kategorie anzeigen zu lassen.

Das funktioniert so weit auch - allerdings ist die untere Trenn-/Grenzlinie zum nächsten Widget falsch plaziert (statt unter "Antifaschismus" müßte sie unter "Umwelt" sein).

[Blockierte Grafik: http://peter-nowak-journalist.de/wp-content/upl…Trennlinien.png]

http://peter-nowak-journalist.de/

Weiß jemand Abhilfe oder ein anderes Plugin mit gleicher Funktionalität, das ich statt dessen ausprobieren könnte?

Ich verwende das Theme Twenty Sixteen unter WP 5.1. Dort sind die unteren Widget-Bereiche standard-mäßig zwar unterhalb der Beiträge und Seiten, aber links von der rechten sidbar plaziert.

Der code, der das reguliert steht am Ende der single.php:

</main><!-- .site-main -->


   <?php get_sidebar( 'content-bottom' ); ?>


</div><!-- .content-area -->


<?php get_sidebar(); ?>
<?php get_footer(); ?>

Wenn ich den code wie folgt verändere, verschiebt sich der (gesamte) untere Widget-Bereich auch noch unter die sidebar.

</main><!-- .site-main -->


</div><!-- .content-area -->


<?php get_sidebar(); ?>
<?php get_sidebar( 'content-bottom' ); ?>
<?php get_footer(); ?>

Ich würde jetzt gerne nur den zweiten unteren Widget-Bereich in dieser Weise verschieben und den ersten an seiner Standard-Twenty Sixteen-Position belassen. - Läßt sich das auch bewirken?

Klar scheint mir zu sein, daß dafür die Zeile

<?php get_sidebar( 'content-bottom' ); ?>

auch an der alten Stelle des codes stehen bleiben muß - und ich vermute, daß ich in den beiden fraglichen Zeilen "content-bottom" durch spezifischere Angaben ersetzen muß. - Aber wie heißen die beiden unterschiedlichen Widget-Bereich?

Danke; funktioniert. - Der erste Link ist jetzt korrigiert.

Ich verwende das Theme Twenty Sixteen unter WP 5.1. Wenn in Überschriften Abkürzungen vorkommen, die aus Großbuchstaben bestehen (z.B.: EU, USA) (oder aus sonstigen Gründen Wörter in Überschriften mit Großbuchstaben geschrieben wurden), so entstehenden bei den Verweisen (zurück / älterer Artikel --- weiter / neuerer Artikel) hin zu dem Artikel mit den Großbuchstaben in der Überschrift vor und nach den Großbuchstaben unerwünschte Zeilenumbrüche; siehe screen shots:

Beispiel "EU":
[Blockierte Grafik: http://peter-nowak-journalist.de/wp-content/upl…aben_Bsp_EU.png]

http://peter-nowak-journalist.de/2019/02/18/wel…ng-in-scherben/

Beispiel "USA":

[Blockierte Grafik: http://peter-nowak-journalist.de/wp-content/upl…ben_Bsp_USA.png]http://peter-nowak-journalist.de/2019/02/04/ube…as-taxigewerbe/
http://peter-nowak-journalist.de/2019/02/04/ube…as-taxigewerbe/

Lassen sich diese Zeilenumbrüche irgendwie vermeiden?

Falls das zur Lösung führt: Im Quellcode sind die Abkürzungen als span class="caps" gekennzeichnet:

<nav class="navigation post-navigation" role="navigation">
        <h2 class="screen-reader-text">Beitrags-Navigation</h2>
        <div class="nav-links"><div class="nav-previous"><a href="http://peter-nowak-journalist.de/2019/02/17/der-dritte-weg-zog-mit-fackeln-und-trommeln-durch-fulda/" rel="prev"><span class="meta-nav" aria-hidden="true">Zurück</span> <span class="screen-reader-text">Vorheriger Beitrag:</span> <span class="post-title">»Der Dritte Weg« zog mit Fackeln und Trommeln durch Fulda</span></a></div><div class="nav-next"><a href="http://peter-nowak-journalist.de/2019/02/21/muss-die-linke-die-eu-verteidigen/" rel="next"><span class="meta-nav" aria-hidden="true">Weiter</span> <span class="screen-reader-text">Nächster Beitrag:</span> <span class="post-title">Muss die Linke die <span class="caps">EU</span> verteidigen?</span></a></div></div>
    </nav>

und

<nav class="navigation post-navigation" role="navigation">
        <h2 class="screen-reader-text">Beitrags-Navigation</h2>
        <div class="nav-links"><div class="nav-previous"><a href="http://peter-nowak-journalist.de/2019/02/04/cg-gruppe-verkauft-postscheckamt-an-art-invest/" rel="prev"><span class="meta-nav" aria-hidden="true">Zurück</span> <span class="screen-reader-text">Vorheriger Beitrag:</span> <span class="post-title">CG-Gruppe verkauft Postscheckamt an Art-Invest</span></a></div><div class="nav-next"><a href="http://peter-nowak-journalist.de/2019/02/04/usa-hoffnung-fuer-mumia-abu-jamal/" rel="next"><span class="meta-nav" aria-hidden="true">Weiter</span> <span class="screen-reader-text">Nächster Beitrag:</span> <span class="post-title"><span class="caps">USA</span>: Hoffnung für Mumia Abu Jamal</span></a></div></div>
    </nav>

(Ich habe schon probiert, was passiert, wenn ich die Abkürzungen lösche und neue über die Tastatur eingebe: Das Problem bleibt bestehen.)

Danke.

1. Da heißt es am Anfang:

Zitat

so far I haven’t been able to coax any field to be required while using the Gutenberg editor (WordPress 5 Beta 4), if the fieldset position is not defined as “normal, below content”.

Meine Felder sind allerdings ohnehin "Nach dem Inhalt" positioniert - und das Ausfüllen der erforderlichen Felder wird trotzdem nicht erzwungen. (Versuche ich, sie "Nach dem Titel, vor dem Inhalt" zu plazieren, was ich teilweise gerne gemacht hätte, werden sie gar nicht erst angezeigt.)

2. Am Ende findet sich dort folgender Lösungsvorschlag:

Zitat

The solution I came up with as a fix was to use jquery to disable the publish / update button if the forms on the page don’t validate. It’s only briefly tested so I wouldn’t recommend on a production site without testing.

Make sure that this script is enqueued via file or is in <script> tags in the admin footer on the gutenberg edit page.

Code

jQuery(document).ready(function($) {
   $(window).bind("load", function () {
       switch_publish_button_on_valid()
   });
   $("form :input").change(function() {
           switch_publish_button_on_valid();
       });
   function switch_publish_button_on_valid(){
       if($('form.metabox-location-normal')[0].checkValidity()){
           $('button.is-primary').removeAttr('disabled');
       } else {
           $('button.is-primary').attr('disabled', 'disabled');
       }
   }
});

Alles anzeigen

Das verstehe ich aber anscheinend wieder nicht richtig - und scheint ja auch ein bißchen riskant zu sein ("It’s only briefly tested so I wouldn’t recommend on a production site without testing.") Ich habe mich trotzdem ein bißchen umgesehen:

a) Es gibt in wordpress/wp-admin eine Datei edit.php. Diese endet mit den Zeilen:

<?php>
include( ABSPATH . 'wp-admin/admin-footer.php' );

b) Aber ob der dahin soll und wo genau - keine Ahnung; zumal das ja - anders als mein child-Theme mit dem nächsten WP-Update eh überschrieben würde, also nur eine Notlösung von kurzer Dauer wäre.

Bringt leider nur das gleiche Ergebnis wie mit der index.php:

Wenn ich allein

acf_form_head();

in die Zeile vor

get_header(); ?>

setze, richtet es zwar keinen auf den ersten Blick sichtbaren Schaden an; hat aber allein auch nicht den gewünschten Effekt.

"wp_head()" und "wp_footer()" sind auch in der single.php (von Twenty Sixteen) nicht von Hause aus enthalten - müßte ich also wissen, wie und wo ich das einfügen muß. ---

Mir kam jetzt allerdings die Idee: Müßte es sich nicht auch eher um eine Datei handeln, die für das back end zuständig ist? Denn es soll ja nicht nur die Anzeige im front end, sondern schon das Speichern verhindert werden, solange die Pflicht-Felder nicht ausgefüllt sind.

Zitat

da fehlt mindestens ein Semikolon hinter acf_form_head(). Wie gesagt, PHP Grundlagen halt. Wer viel "extra" will, muss eben auch viel extra lernen. Hat ja auch größtenteils nix mit WP zu tun.

Mit Semikolon dahinter funktioniert die Webseite jedenfalls weiterhin; aber allein dies reicht leider nicht aus, um eine Eingabe in die fraglichen Felder zu erzwingen.

Zitat

Wie gesagt, PHP Grundlagen halt. ... Hat ja auch größtenteils nix mit WP zu tun.

Da WP ja anscheinend u.a. auf PHP aufbaut, ja wohl irgendwie schon...

Zitat

Wer viel "extra" will, muss eben auch viel extra lernen.

Ich schraube halt alle paar Jahre mal an einem Theme herum und lerne dabei manches und behalte auch manches - das muß dann allerdings auch so erklärt sein, daß es meinen begrenzten Vorkenntnissen entspricht. Anderes kann ich einfach nur dankend konsumieren und anwenden.

Und wenn sich hier anscheinend Leute mit PHP auskennen und vielleicht schon zehn php-Bücher gelesen haben, und den Eindruck haben, daß für meine Fragen php-Kenntnisse hilfreich sind, dann nehme ich - wie gesagt - auch Buchempfehlung gerne entgegen. -

Und wenn die Antwort auf meine Frage am Anfang des Threads gewesen wäre, daß es keine einfache Lösung gebe, mit der sich das Ausfüllen der Felder wirklich verpflichtend machen läßt, dann wäre auch das eine informative Antwort gewesen. Dann hätte ich mich halt damit abgefunden, daß es nicht 100-prozentig so ist, wie ich es haben möchte.

Gibt es umgekehrt hier Leute gibt, die eine Antwort parat haben, die ich einfach umsetzen kann, nehme ich sie gerne entgegen. -

Aber ein Hilfe-Forum benutze ich halt, weil ich eine Frage habe und nicht weiß, wie ich die Antwort anders finden kann - und auch nicht die Absicht habe, ein Informatikstudium zu beginnen.

Lies vielleicht einfach noch mal, was ich tatsächlich geschrieben habe und überleg Dir dann, was darauf eine thematisch passende Antwort wäre. Oder übergeh einfach meine Frage mit Schweigen, wenn Dir die Frage nicht gefällt (ist ja hier in der Tat niemand zum Antworten verpflichtet...).

Danke schön. :)

Was soll ich nach YouTutorials suchen, wenn ich schon nicht weiß, wonach ich eigentlich suchen soll?! -

Hilfreich wäre ein Hinweis auf ein empfehlenswertes deutschsprachiges Buch zu php-Grundlagen. (Vor längerer Zeit hatte ich mal WordPress-Themes entwickeln von Cremer/Lambertz gelesen; aber das habe ich heute nicht mehr im Kopf, da ich mich damit nicht regelmäßige beschäftige.)

Zitat von maxe

erstes Suchergebnis

Mit welchem Suchbegriff/en denn? -

Davon abgesehen hilft mir allein das:

Zitat

Make sure that you have placed acf_form_head() before get_header()and that your theme includes both wp_head() and wp_footer() calls.

so nicht wirklich weiter. Da steht ja nicht einmal, um welche Datei/en es geht; außerdem weiß ich nicht, was "calls" im vorliegenden Zusammenhang bedeutet. Ich vermute mal, die index.php ist gemeint.

Dort ist die erste Zeile nach dem einleitenden Kommentar:

get_header(); ?>

Von "wp_head()" und "wp_footer()" steht in der Datei nichts. - Wo müßte das hin? Und in welcher Form? Nur so oder noch mit

<?php ... ?>

drumherum? (In der letzten Zeile steht zwar nichts von "wp_footer()", aber "<?php get_footer(); ?>".)

Wenn ich zunächst einmal "wp_head()" und "wp_footer()" ignoriere und nur

acf_form_head()

in die Zeile vor

get_header(); ?>

setze, bleibt mein Browserfenster weiß, wenn ich versuche, die Webseite aufzurufen. Genauso, wenn ich versuchsweise noch eine php-Anfangs- und Endmarkierung drumherumsetze.

Zu Letzterem: Mit "etwas" scheint es bei weitem nicht getan zu sein...; ohne "etwas" zu wissen, hätte ich nicht einmal eine Vorstellung, was möglich sein könnte und was für Fragen ich stellen muß. -

Zum eigentlichen:

1. Ich scheine es jetzt zu haben

• sowohl dieser neue Artikel:

http://peter-nowak-journalist.de/2019/03/01/ste…n-verdraengung/

• als auch dieser alte Artikel:

http://peter-nowak-journalist.de/2019/02/05/sin…les-populisten/

sind jetzt im ersten Absatz so formatiert, wie sie formatiert sein sollen.

2. Es hat aber reichlich gedauert, bis ich bemerkt hatte, daß in Deinem neuen code das Datum zunächst nicht mehr der 1.3., sondern der 5.2. war (die zwischenzeitliche Editierung habe ich erst unmittelbar vor dem Klick auf "Antwort erstellen" bemerkt) - weshalb ich mich gewundert hatte, warum z.B. der "Populisten"-Artikel vom 19. Februar zunächst nicht richtig formatiert war. Jetzt habe ich das Datum wieder auf den 1.3. geändert.

Zitat von maxe

du hast jetzt einen 2. body Tag einfach in der content-single.php angelegt, das ist falsch.

Nee, was ich gemacht hatte, war: Deinen code in meine header.php einzufügen und in der css.style "body.old" davorzusetzen, sodaß dort jetzt heißt:

body.old .entry-content  p:first-of-type {
   font-size: 125%;
   font-style: italic;
   font-weight: 700;
   background-color: #D3D3D3;
   padding-left: 10px;
   padding-right: 10px;
}

Aber daß ich irgendetwas falsch gemacht habe, habe ich auch gerade bemerkt, denn z.B. dieser alte Beitrag (letzte Änderung: 19. Februar) wird im ersten Absatz nicht so angezeigt wie er soll:

http://peter-nowak-journalist.de/2019/02/05/sin…les-populisten/

Zitat

Du solltest den vorhandenen body tag anpassen.

In welcher Datei denn und was ist ein body tag?

Zitat

Wenn du unbedingt nur an die content-single.php willst, ...

Ich denke nicht, daß ich das unbedingt will.

Ich habe mit Advanced Custom Fields (ACF) mehrere neue Felder für die Beitrags-Erstellung geschaffen und davon einige als "erfoderlich" definiert.

Dies führt aber praktisch nur dazu, daß diese Felder mit einem roten Stern gekennzeichnet sind, aber nicht dazu, daß sich Beiträge erst speichern/veröffentlichen lassen, wenn diese Felder ausgefüllt sind. Nicht einmal eine Fehler-/Warn-Meldung erscheint.

Besteht eine Möglichkeit das Ausfüllen der als "erforderlich" definierten Felder tatsächlich zu erzwingen?

Cool. Funktioniert:

http://peter-nowak-journalist.de/2019/03/01/ste…n-verdraengung/

Danke. Jetzt mußte ich nur noch einen unteren margin für mein lead definieren, damit auch der Abstand zum nächsten Absatz stimmt. -

Der Thread ist dann schon mit der ersten Antwort gelöst. :-)

Ich bin - unter WP 5.1 und Theme Twenty Sixteen - mit diesem Blog:

http://peter-nowak-journalist.de/

beschäftigt.

1. Ich hatte - nach entsprechender hiesiger Hilfe - folgenden code zu meinem child style sheet hinzugefügt, um eine bestimmte Formatierung aller ersten Absätze zu erreichen:

.entry-content  p:first-of-type {
   font-size: 125%;
   font-style: italic;
   font-weight: 700;
   background-color: #D3D3D3;
   padding-left: 10px;
   padding-right: 10px;
}

und diesen code, um die Seiten von dieser Formatierung auszunehmen:

.page p:first-of-type {
   font-size: 100%;
   font-style: normal;
   font-weight: normal;
   background-color: transparent;
   padding-left: 0;
   padding-right: 0;
}

2. Es blieben aber mehrere Probleme:

a) Ich habe bisher nicht herausgefunden, wie ich auch Kalendereinträge von der fraglichen Formatierung ausnehmen kann.

b) WordPress nimmt manchmal auch - im visuellen Modus per copy & paste eingefügten - Text mitten im Beitrag als scheinbaren ersten Absatz (siehe z.B. dort die Absätze, die eigentlich als Blockzitate in kleinerer Schrift und ohne Hintergrund formatiert sein sollen; vgl. auch die copy & paste-Quelle zu diesem Beitrag] wahr und formatiert diesen in der dort aber von mir nicht erwünschten Weise.

3. Jetzt habe ich mir Folgendes überlegt, um diese Fehlformatierungen zumindest für neuen content zu vermeiden:

a) Ich habe mit dem Plugin Advanced Custom Fields (ACF) u.a. ein neues Feld "Lead" für die Beitrags-Erstellung geschaffen.

b) In meine content-single.php habe ich vor

<?php
           the_content();

das Folgende eingefügt:

<div class="lead"><?php the_field( 'lead' ) ?></div>

(Das gleiche würde ich auch noch in die content.php einfügen, falls der Rest so funktioniert, wie ich hoffe.)

Außerdem habe ich in meine css.style eingefügt:

.lead {
   font-size: 125%;
   font-style: italic;
   font-weight: 700;
   background-color: #D3D3D3;
   padding-left: 10px;
   padding-right: 10px;
}

c) Das Ergebnis sieht wie folgt aus:

[Blockierte Grafik: http://peter-nowak-journalist.de/wp-content/uploads/2019/03/Lead.png]

und

[Blockierte Grafik: http://peter-nowak-journalist.de/wp-content/uploads/2019/03/beispiel.png]

4. a) Ich würde jetzt gerne noch irgendwie und irgendwo definieren, daß meine Formatierung für

.entry-content p:first-of-type

nur Anwendung finden soll auf content von vor dem 01.03.2019 (also auf content, der kein ausgefülltes lead-Feld hat), sodaß also

• in dem obigem Beispiel der zweite (= erste 'normale') Absatz in normaler Schrift dargestellt würde;

• bei älterem content der erste ('normale') Absatz aber die fragliche Formatierung erhalten würde.

Das heißt: Ich würde mir ersparen für die ca. 4.000 alten Beiträge das lead-Feld nachträglich auszufüllen; bei den alten Beiträgen die Fehlformatierung der Blockzitate hinnehmen; aber für die neuen Beiträge sicherstellen, daß das lead so formatiert ist, wie es sein soll, ohne daß dies aber (für den neuen content) die Formatierung der Blockzitate beeinträchtigt.

Alternativ zu einer Datums-Bedingung käme auch in Betracht die

.entry-content p:first-of-type

Formatierung davon abhängig zu machen, daß das lead-Feld nicht ausgefüllt ist.

5. Läßt sich eine solche Bedingung irgendwie formulieren? Und falls ja: Wie?

Oder gibt es eine andere Lösung zur Vermeidung der Fehlformatierung der Blockzitate?

Ich entnehme dem zumindest die Warnung, allzu viel Arbeit in die Systematisierung der Schlagwörter zu stecken. ;-) :-)

Bliebe vor allem die - praktische - Frage: Spricht etwas dagegen, die Schlagwörter aus dem Beitrags-Meta rauszunehmen?

(Die Schlagwort-Wolke mit den zumindest etwas häufiger verwendeten [und daher für die LeserInnen relativ nützlichen] Schlagwörtern - im Moment unter den Beiträge platziert - bliebe ja trotzdem erhalten.)

Und zumindest zum Lernen würde mich noch interessieren:

1. a) Warum mag google nur ca. die Hälfte der existierenden Schlagwort-Übersichtsseiten kennen?

b) Könnte jedenfalls die von google bisher eh noch nicht erfaßte Hälfte der Schlagwörter unschädlich gelöscht werden?

2. Ist für Suchmaschinen nur relevant, daß überhaupt eine Schlagwort-Übersichtsseite existiert oder auch wieviel Beiträge auf der jeweiligen Übersichtsseite verzeichnet sind? Anders gefragt: Belohnen Suchmaschinen tatsächlich eine Inflationierung von WordPress-Schlagwörtern?

3.a ) @ "die bisher bestehenden Pfade zu den einzelnen Übersichtsseiten der Schlagworte dann nicht mehr existieren":

Wäre das ein dauerhaftes Problem oder nur solange bis, die Suchmaschinen die neue Struktur erfaßt haben?

b) Interessieren sich Suchmaschinen ausschließlich für WordPress-Schlagwörter oder auch für WordPress-Kategorien?