Beiträge von Am Ende des Lateins

    Tipp am Rande, eine Umwandlung von Schlagworten in Kategorien hat direkten Einfluss auf die Suchmaschinenerfassung (SEO) des gesamten Websites, da die bisher bestehenden Pfade zu den einzelnen Übersichtsseiten der Schlagworte dann nicht mehr existieren..

    Dann bleiben wir mal bei dem Thema:

    • Wegen der Suchmaschinen-Erfassung hat er diese vielen Schlagwörter (ca. 12.000 Schlagwörter bei ca. 4.000 Beiträgen, von denen die allermeisten Schlagwörter aber nur einen einzigen Beitrag verschlagworten).
    • Suchmaschinen hin und her - zumindest aus der Perspektive der Lesenden scheinen mir Schlagwörter, die nur einen einzigen Artikel verlinken völlig nutzlos zu sein (zu dem am allermeist verwendeten Schlagwort gibt es 60 Beiträge; zu dem am zweitmeisten verwendeten 42 Beiträge und zu ca. 25 Schlagwörtern 15 bis 30 Beiträge - und der Rest von den 12.000 Schlagwörtern ist "ferner liefen") - ganz abgesehen davon, daß sie sich nicht hierarchisieren lassen und anscheinend auch erheblich Performance beanspruchen, wenn ich richtig verstanden habe:

    Warum dieser Konverter ansonsten nicht funktioniert, ergäbe sich ggf. aus dem error-log oder aus weiteren Tests z.B. mit anderen PHP-Versionen, WordPress-Versionen, Anzahl von Tags, Nachlesen bzgl.Kompatibilität im entspr. Support-Forum des Plugins, usw.

    • Um mal ein Beispiel zu geben: Es gibt 44 Schlagwörter, in denen "SPD" vorkommt - darunter "SPD" pur, wozu es sieben Beiträge gibt. Zu allen anderen 43 SPD-Schlagwörtern gibt es nur ein oder zwei Beiträge (z.B.: "Martin Schulz SPD", "TTIP SPD" - aber auch "Georg Maaßen SPD", obwohl Maaßen ja gar nicht SPD-Mitglied ist).
    • Mir erschiene nun - aus sozialwissenschaftlicher LeserInnen-Perspektive - sinnvoll, eine Ober-Kategorie "SPD" zu bilden, die die Beiträge zu allen bisherigen 44 "SPD"-Schlagwörtern abdeckt, und darunter eine handvoll von Unterkategorien

      • wie "SPD-Gremien (Parteivorstand, Konvent, Parteitag etc.)",
      • "Gliederungen (Berlin, Kreisverband Odenwald etc.)",
      • "SPD-PolitikerInnen" (dazu vielleicht noch Unter-Unterkategorien mit den Namen, z.B. "Martin Schulz")
      • und
      • "SPD und Politikfelder" (und darunter Unter-Unterkategorien zu den Politikfeldern, z.B. "TTIP", "Maaßen-Affaire")
      • zu bilden.
    • Und entsprechend mit anderen Schlagwörtern, die sich hierarchisieren lassen - sodaß dann am Ende nur noch Schlagwörter übrigbleiben, die nicht oder nur schlecht hierarchisierungsfähig sind - und auch von diesen alle Schlagwörter zu löschen, zu denen es nicht mindestens drei Beiträge gibt - sodaß es dann am Ende vielleicht noch ein paar hundert, aber nicht mehr 12.000 Schlagwörter gibt.

    Was haltet Ihr von meiner Idee? Erschiene Euch eine solche Struktuierung sinnvoll? Oder würdet Ihr - wegen der Suchmaschinen - davon abraten, in die bestehenden Schlagwörter einzugreifen?

    Und falls letzteres: Wäre, es dann zumindest unschädlich, die Schlagwörter aus dem Beiträge-Meta ausblenden? (Eine solche Ausblendung erschiene mir - als Notlösung - aus folgendem Grund sinnvoll:

    Es gibt zum Beispiel diesen Beitrag (und ähnliche Beiträge gibt es öfter):

    http://peter-nowak-journalist.de/2019/01/04/bot…aft-angekommen/

    Dazu gibt es acht Schlagwörter: Annalena Baerbock Abschiebungen, Christoph Schwennike Cicero, Matthias Drobinski Süddeutsche Zeitung, Pressemeldung Stadt Cottbus, Rassismus Bottrop, Silvesternacht Amberg, Was geschah in Amberg?, Was geschah wirklich zu Silvester in Amberg.
    Aber jedes dieser acht Schlagwörter verschlagwortet haargenau diesen einen Artikel zu Bottrop und Amberg. - Das heißt: LeserInnen, die den acht Schlagwörter-Links im Meta dieses Beitrages folgen, gelangen mit dem Link jeweils ausschließlich zu dem Artikel, den sie eh schon kennen... -

    Um den LeserInnen das Klicken auf solche Links ohne zusätzlichem Informationswert zu ersparen, würde ich gerne - als Radikalkur - die Schlagwörter auf solche reduzieren, die tatsächlich öfter verwendet werden und mehrere Artikel erschließen oder - als Notlösung - die Schlagwörter aus dem Beitrags-Meta ausblenden. - Was ist Eure Meinung dazu?)

    Das hat er eh beides noch nie selbst gemacht; das ist gerade alles mein Freundschaftsdienst. -

    Das größere Probleme als der .xml-Export, für den sich in der Tat ab und an einfach das Kalender-Plugin manuell deaktivieren ließe, ist das Nicht-Funktionieren des Konverters -

    den bräuchte ich dringend, um nicht allzu aufwendig etwas Übersicht - durch Kategorien-Hierarchisierung - in die Unmengen von Schlagwörtern, die der Content-Produzent in den vergangenen Jahren vergeben hat, zu bringen. ---

    Mal sehen, was die Anfrage beim Hoster wegen der error.log ergibt...

    Danke. - Kann ich die Umstellung auf php7 einfach so machen? Oder sollte ich vorher erst wieder die Datenbank sichern und die aktuelle .xml-Datei exportieren?

    Ich habe inzwischen beide Sicherungen gemacht und auf php7 umgestellt. - Aber auch nach Umstellung funktioniert der Export der .xml-Datei nur dann, wenn ich vorher das Kalender-Plugin von time.ly deaktiviere.

    Hier scheine ich jetzt das Richtige gefunden zu haben:

    "memory_limit 100M 100M"

    Das wird mir unter folgender Überschrift angezeigt: "SERVERMODULE
    Hier können Sie sich die Module zu den Scriptsprachen, die auf Ihrem Server installiert sind, anzeigen lassen.
    Moduldetails für: PHP 5.2.17 (Stable)
    Stand : 27.02.2019"

    Inzwischen habe ich folgendes festgestellt:

    1. Unter der Überschrift

    "SERVERMODULE
    Hier können Sie sich die Module zu den Scriptsprachen, die auf Ihrem Server installiert sind, anzeigen lassen.
    Moduldetails für : PHP 7.1.23 (Stable)
    Stand : 28.02.2019"

    wird mir ebenfalls nur

    "Core
    PHP Version 7.1.23
    Directive Local Value Master Value
    memory_limit 100M 100M"

    angezeigt. - Kann das sein?

    2. a) Im übrigen soll es sich wohl bei beiden Listen (der zu 5.2.17 und der zu 7.1.23) um Beschreibungen der php-Versionen als solches und nicht um das memory_limit, das tatsächlich zur Verfügung steht, zu handeln. Denn an anderer Stelle - https://www.df.eu/de/webhosting/ -
    heißt es :

    || -------------------- || Basic - 3,99 €/Monat || Medium - 6,99 || Professional 9,99 €/Monat || Premium19,99 ||Ultimate 39,99 ||

    || DF ScriptPower || 64 MB RAM, 30 CPU-Sek. || 128 MB RAM, 40 CPU-Sek. || 128 MB RAM, 60 CPU-Sek. || 256 MB RAM, 60 CPU-Sek. || 256 MB RAM, 120 CPU-Sek.||

    Danach scheint das memory_limit wohl nicht (nur<?>) von der jeweiligen php-Version, sondern (auch<?>) vom jeweiligen Tarif abzuhängen.

    b) Im Moment läuft der Blog noch mit einem noch schlechteren Tarif als "Basic", für den ich aber nicht die Angaben zur "Script Power" feststellen konnte, sondern nur, daß er zum gleichen Preis jedenfalls weniger GB Web- und mail-Speicherplatz (2 statt 25 GB) biete. Zu

    "[Blockierte Grafik: https://img.df.eu/auto/bestellung/groupheader/bgffffff_dynamisch.png]
    für interaktive Inhalte mit PHP, Perl und MySQL"

    heißt es dort einfach nur "ja".

    3. Ich hatte gestern den Content-Produzenten gebeten, sich bei seinem Hoster nach der error.log zu erkundigen; letzterer hat aber noch nicht geantwortet.

    Nachher hier (noch mal) folgende Fragen:

    a) Soll ich an der php-Version etwas ändern? [Mir ist allerdings nicht einmal ganz klar, ob aktuell PHP 5.6.34 (siehe oben den screen shot in Antwort #16) oder PHP 5.2.17 (Stable) installiert ist. Letzteres wird mir angegezigt, wenn ich dort:

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

    in der Zeile "PHP5" in der letzten Spalte auf "Detaillierte Informationen" klicke. Anschließend wird mir - automatisch - dies:

    [Blockierte Grafik: http://peter-nowak-journalist.de/wp-content/uploads/2019/02/php-5-2-17.png]

    angezeigt. Ich kann dort aber auch zu den anderen Versionen wechseln. Jedenfalls befindet sich dort - weiter unten - auch die - für 5.12.17 und 7.1.23 identische Angabe zum memory_limit.)

    b) Was hat es damit auf sich, daß dort für alle php-Versionen ein memory_limit von 100 M angezeigt wird? - Hätte es unter den diesen Umständen überhaupt einen Sinn, zu einem teureren Tarif (als Basic, mit dem der Blog ab Mitte März laufen wird) zu wechseln oder, wäre php eh der Falschenhals?

    Danke. "get" statt "the" ist richtig, habe ich nun durch probieren festgestellt;

    mangels hinreichender Englisch- oder Informatik-Kenntnisse erschloß sich mir die Bedeutung des Unterschiedes zwischen "returns" und "displays" an der genannten Stelle aber nicht von selbst. -

    Vielen Dank allseits. - Dann kann dieser Thread auch geschlossen werden.

    Danke. -

    Nach dem Vorbild von:

    Zitat

    "Um ein Zusatzfeld auch im Template auszugeben, braucht man nur dessen Namen. Man kann das Feld dann an beliebiger Stelle in das Template integrieren . Hierzu reicht der folgende PHP-Befehl:

    PHP
    <?php the_field('name_des_feldes'); ?>

    Das wars dann auch schon. Natürlich gibt es Feldtypen, die zusätzliche Parameter zulassen. Es lassen sich jedoch alle Feldtypen mit the_field in standardisierter Form ausgeben."

    https://entwickler.de/online/php/wor…-579847918.html

    habe ich mir folgendes gedacht:

    1. In meiner Zeile

    PHP
    <?php the_post_thumbnail( 'post-thumbnail', array( 'title' => the_title_attribute( 'echo=0' ) ) ); ?>

    sind php-Anfangs- und End-Markierung ja eh schon vorhanden.

    2. Also habe ich probiert, was passiert, wenn ich

    Code
    the_title_attribute( 'echo=0' )

    durch

    Code
    the_field( 'datum_der_erstveroffentlichung' )

    ersetze.

    3. Dies gibt zwar wie gewünscht meine Eingabe aus - aber nicht als Tooltip zu dem Bild/Logo, sondern links daneben:

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

    Was war mein Fehler? Was habe ich nicht bedacht?

    Korrektur (ich hatte in Antwort #21 falsch beschrieben, was ich gemacht hatte):

    Nicht

    "array( 'alt' => the_title_attribute( 'echo=0' )" ist dafür verantwortlich, daß bisher - bei mouse over - der Beitragstitel als Tooltip zu dem Logo/Bild erscheint,

    sondern nur dann,

    wenn ich dort "alt" durch "title" ersetze, erscheint der entsprechende Tooltip. (Und die weitere Ersetzung von "the_title_attribute" durch "datum_der_erstveroffentlichung" führte dann zu der besagten Fehlermeldung.)

    Mit dem Plugin das zusätzliche Eingabefeld zu erzeugen, habe ich hinbekommen (siehe im Bild unten rechts):

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

    Jetzt bliebe nur die Frage: Wie bekomme ich das dort Eingegebene nun ausgegeben (sei es gemäß der ursprünglichen Idee als Tooltip zu dem Beitragsbeitrag - oder meinetwegen auch anders [z.B., wenn auch entsprechend Anderes eingeben würde, als Unterüberschrift <unterhalb der eigentlichen Beitragsüberschrift]: "Dieser Beitrag erschien ursprünglich in der Jungle World vom 21. Februar 2019"])?

    Wenn ich richtig sehe, ist in meiner function.php

    PHP
    <?php the_post_thumbnail( 'post-thumbnail', array( 'alt' => the_title_attribute( 'echo=0' ) )

    "array( 'alt' => the_title_attribute( 'echo=0' )" dafür verantwortlich, daß bisher - bei mouse over - der Beitragstitel als Tooltip zu dem Logo/Bild erscheint:

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

    Richtig geraten?

    Da ich meinem zusätzlichen Eingabefeld den Namen "datum_der_erstveroffentlichung" gegeben hatte, habe ich einfach mal probiert, was passiert, wenn ich in meiner function.php "the_title_attribute" durch "datum_der_erstveroffentlichung" ersetze. - Aber so einfach ist die Welt dann doch nicht -

    das führt bei Aufruf der Webseite zur folgender Fehlermeldung: "Fatal error: Call to undefined function datum_der_erstveroffentlichung() in /kunden/272167_10247/webseiten/wordpress/wp-content/themes/dgs_child/functions.php on line 33"

    zu Variante 1 wäre der title nicht für jede Verwendung des Bildes identisch, denn es hätte ja den Post Title (Titel vom Beitrag).

    zu #15, du kannst den Post Titel als title Attribut von img nehmen (wie bereits oben beschrieben und auch von dir getestet)

    Du meinst das zweite Bild in meinem Eingangs-post? - Von der Variante war ich abkommen, weil mir scheint, daß die Beitrags-Bild-Funktion für den Content-Produzenten einfacher und mit weniger Klicks zu handhaben ist, als das Einfügen eines Blocks für das Bild und dann das korrekte Plazieren des Blocks; außerdem müsste bei dieser Variante auch noch im html-Modus "alt" durch "title" ersetzt oder ergänzt werden. Das dürfte für den Blog-Betreiber zu diffizil sein.

    Den Hinweis auf, "Da würden sich z.B. die Custom Fields (benutzerdefinierte Felder) anbieten, evtl. sogar über das ACF Plugin", hatte ich vorhin übersehen. - Das Plugin kann ich ja mal ausprobieren; vielleicht komme ich damit zurecht.

    Und bzgl. der error.log habe ich jetzt eventuell noch gefunden:

    Zitat

    CGI-Debugger
    Mit dem CGI-Debugger können Sie Fehlermeldungen, die von Skripten ausgegeben werden, aus den Error-Logfiles ausgeben lassen. Zudem finden Sie dort eine Übersicht der letzten Zugriffe aus dem Access-Log und können sich eine Logdatei langsamer Datenbankabfragen ansehen. Auf diese Weise können Fehlerursachen zeitnah und einfach ermittelt werden.
    So geht’s
    Durch den Aufruf der Adresse https://sslsites.de/domain.tld/system-cgi/cgi-debug können Sie direkt auf den bereits standardmäßig vorinstallierten CGI-Debugger zugreifen.


    Wäre das die benötige Datei/Information? -

    Wenn ich die Adresse aufrufe, erhalte ich allerdings folgende Fehlermeldung: "Proxy-Fehler
    Die angeforderte Domain kann über diesen Proxy nicht genutzt werden."

    Ich denke allerdings nicht, daß ich überhaupt einen Proxy benutze. Das wüßte ich doch, oder nicht?

    Ist das das php memory_limit:

    Zitat

    ScriptPower
    Arbeitsspeicher: 13 MB RAM
    CPU-Zeit: 8 Sekunden
    Skriptlaufzeit: 180 Sekunde
    Die oben angegebenen Werte stehen Ihnen pro Skript zur Verfügung. Sofern diese nicht ausreichend sind und zu einem Abbruch eines Skriptes führen, sollten Sie eine Optimierung des Skriptes und/oder ein Upgrade auf einen Tarif mit höheren Skriptlimits in Erwägung ziehen

    ?

    Hier scheine ich jetzt das Richtige gefunden zu haben:

    Zitat

    memory_limit 100M 100M

    Das wird mir unter folgender Überschrift angezeigt: "SERVERMODULE
    Hier können Sie sich die Module zu den Scriptsprachen, die auf Ihrem Server installiert sind, anzeigen lassen.
    Moduldetails für : PHP 5.2.17 (Stable)
    Stand : 27.02.2019"

    es ging lediglich darum, ob die css class post-thumbnail noch benötigt wird.

    Anscheinend nicht, wenn es eh so aussieht, wie es aussehen sollen - außer ich bemerke später irgendeinen Fehler.

    zu #15, du kannst den Post Titel als title Attribut von img nehmen (wie bereits oben beschrieben und auch von dir getestet) oder aber noch z.B. das Post Datum hinzufügen.

    zu Variante 1: Dann wäre ja aber, wenn ich recht verstehe, der title-Text für jede Verwendung des Bildes identisch, oder nicht?

    zu Variante 2: Das würde auch nicht wirklich weiterhelfen. Denn das Datum des posts steht eh ja im post-Meta. - Das title-tag würde ich gerne aus folgendem Grunde verwenden:

    • Der Blog-Betreiber (Content-Produzent) bringt z.B. heute bei telepolis oder irgendwo einen Artikel unter.
    • Dann kommt er z.B. erst morgen oder übermorgen dazu, den Artikel im eignen Blog zu dokumentieren/spiegeln.
    • Deshalb würde ich gerne bei dem Logo (Bild) des jeweiligen Erst-Veröffentlichungs-Mediums einen title-Text, der das Datum der jeweiligen Erstveröffentlichung nennt, unterbringt. (Nur das hätte ja einen informativen Mehrwert gegenüber dem post-Meta.)

    Hosting-Upgrade o.ä. auf einen leistungsfähigeren Account.

    Was ist denn in dem Zusammenhang der entscheidende Parameter für "leistungsfähiger"? (Da der Konverter auch dann nicht funktioniert, wenn alle anderen Plugins deaktiviert sind, scheint ja - wenn der Konverter funktionieren soll - kein Weg an einem Upgrade herumzuführen.)

    Zu Antwort #15:

    Ich habe dann (statt "title") "alt" wiederhergestellt (insoweit also die Originalversion). - Und wenn ich recht verstehe, reguliert die inc/template-tags.php bzw. meine functions.php nur das, was im front end ausgegeben/anzeigt wird, aber nicht, was im back end eingeben werden kann.

    Das heißt: Ohne Lösung, wie ich den title-Text überhaupt erst einmal beitrags-spezifisch eingeben kann, brauche ich mich mit der Ausgabe gar nicht weiterbeschäftigen. - Das wird dann wohl zu anspruchsvoll für mich.

    Zu Antwort #13:

    Spricht irgendetwas dafür "span" zu verwenden, statt einfach die fragliche Zeile zu löschen? (Es scheint ja auch ohne "span" so auszusehen, wie es soll.)

    Jetzt habe ich noch probiert, was passiert wenn ich bei

    Code
    array( 'alt' => the_title_attribute( 'echo=0' )

    "alt" durch "title" ersetze. Das hat auf den ersten Blick keinen sichtbaren Effekt - führt jedenfalls nicht dazu, daß mir nun im back end bei den jeweiligen Beiträgen ein Eingabefeld zur Verfügung stehen würde, um den title-Text einzugeben, siehe z.B.:

    [Blockierte Grafik: http://peter-nowak-journalist.de/wp-content/uploads/2019/02/kein_Feld_f_title-tag.png]


    PS.:

    Zu Antwort #11: Danke; ich habe die Zeile jetzt ganz gelöscht.