Hugo-Shortcode-Gallery

Dafür verwendete ich hugo-shortcode-gallery. Hierbei werden die von Hugo generierten Vorschaubilder per JavaScript geladen und bei einem Klick darauf werden in einer Lightbox die Originale angezeigt. Letzteres war zuletzt in Firefox ziemlich lahm.

Eine Galerie fügt man mit diesem Shortcode ein:

{{< gallery match="images/*" >}}

Damit werden alle Bilder im Unterverzeichnis images/ des Page Bundle zur Galerie hinzugefügt. So kann man auch mehrere Galerien in einem Blogbeitrag mittels verschiedenen Unterverzeichnissen erstellen lassen.

Einzelbilder statt Galerie

Über die Zeit hat sich jedoch für mich herauskristallisiert, dass ich Galerien gar nicht benötige. Stattdessen finde ich es jetzt besser, Bilder einzeln einzubinden, sodass man auch zu jedem Bild eine Beschreibung und einen Alt-Text hinterlegen kann. Und auch eine Lightbox will ich nicht mehr haben, Bilder werden per Klick direkt geöffnet.

Schon seit längerem nutze ich daher gar keine Galerien mehr.

Da aber in circa 90 Blogbeiträgen bereits die anfangs genutzten Galerien enthalten sind, wollte ich mir die Arbeit ersparen, diese manuell umschreiben zu müssen.

Eigene Pseudogalerie statt Hugo-Shortcode-Gallery

Deshalb habe ich die Hugo-Shortcode-Gallery aus dem Projekt entfernt und einen gleichnamigen eigenen Shortcode erstellt, der die Bilder per Markdown einfügt und mit dem Original verlinkt, so wie hier beschrieben.

Man kann somit die alte Form weiterverwenden und für

{{< gallery match="images/*" >}}

wird durch alle passenden Bilder iteriert und dann wird das hier eingefügt:

[![](images/bild1.jpg)](images/bild1.jpg)
[![](images/bild2.jpg)](images/bild2.jpg)
…

Das nächste Rendern des Blogs dauerte nach der Änderung sehr lange, schließlich mussten für hunderte Bilder in insgesamt 90 Galerien verschiedene Bildgrößen generiert werden. Für meinen Blog waren das so zusätzlich 1,6 GB an neuen Bildateien.

Diese Änderung ist jetzt im Blog und auch im Wiki implementiert. Ich musste in der config.toml des Wikis den timeout etwas erhöhen, da es dort Galerien mit extrem vielen Bildern gibt.

Alt und neu im Vergleich

Links die alte Galerie und rechts die neue.

Hier der Link zum Blogbeitrag mit den schönen Minecraft-Bauten.

Passt

Das passt so für mich. Es gibt eine Abhängigkeit weniger, um die man sich ganz selten mal kümmern muss und die eigene Lösung benötigt auch kein JavaScript mehr.

Und falls ich mal in einen Blogbeitrag ganz viele Bilder als reinen Bilddump werfen möchte, dann kann ich das weiterhin mit dem entsprechenden Shortcode machen. Bevorzugt sind aber weiterhin Bilder mit Bildbeschreibung im Alt-Text.

Ich hatte damals überlegt, für welche der beiden Methoden ich mich entscheiden sollte. Die Wahl ist auf Beschreibungen in den Exif-Metadaten gefallen. Der Grund ist, dass auch die anderen Angaben wie z. B. ISO-Wert usw. bereits in den Metadaten enthalten sind und das aus meiner Sicht sinnvoll ist, dass auch die Bildbeschreibung dort landet, damit man nicht mit dem Medium brechen muss.

Zudem habe ich jetzt jetzt eine einfache Möglichkeit gefunden, Bildbeschreibungen mit Hilfe von Digikam in die Exif-Metadaten meiner Fotos im Blog einzufügen.

Setup

1. Zunächst fügt man das content-Verzeichnis des Blogs als Sammlung bzw. Collection in Settings -> Configure digikam… -> Collections in Digikam hinzu, sodass man Zugriff darauf hat.
2. Dann setzt man in Settings -> Configure digikam… -> Metadata bei Behaviour im Bereich Write This Information to the Metadata einen Haken bei Captions and title.¹

   

Dateibeschreibung einfügen

Nun kann man ein Bild auswählen und rechts den Bereich Captions öffnen und bei Caption die Bildbeschreibung eintragen. Dann klickt man unten auf Apply. Vergisst man das, fragt Digikam bei Auswahl eines anderen Bilds nach, ob die Änderung gespeichert werden soll.

Änderungen prüfen

Öffnet man z. B. in Dolphin die Dateieigenschaften eines Bildes mit Bildbeschreibung, dann kann man diese im Bereich Details -> Description sehen.

Natürlich geht das auch mit exiftool:

$ exiftool 2022-04-01-kagube-selfie.jpg

File Name                       : 2022-04-01-kagube-selfie.jpg
File Size                       : 859 KiB
[…]
Description                     : Kagube wollte ein Selfie machen.
[…]

Veränderungen an den Dateien

Sobald man eine Bildbeschreibung eingefügt hat, ändert sich auch die Datei für Git. Man kann diese Änderungen dann committen und beim nächsten Bau des Blogs werden in der Galerie die Bildbeschreibungen angezeigt.

Passt

Für mich ist die Lösung als Collection innerhalb von Digikam sehr praktisch. So kann ich auch im Nachhinein die Fotos des Blogs verwalten, zwischendurch einfach mal Bildbeschreibungen verändern, Fotos nachbearbeiten und vor allem z. B. auch die Möglichkeit nutzen, Bilder anhand von bestimmten Merkmalen dank Digikam wiederzufinden, statt nur über Blogbeiträge oder Dateinamen.

Denn Digikam bietet z. B. die Möglichkeit, ähnliche Dateien anhand eines ausgewählten Bildes oder anhand eines selbst gemalten Bildes zu finden.

Gallery-Shortcode

Das Theme liefert jetzt einen eigenen Shortcode gallery mit, siehe Dokumentation.

Da ich bereits einen Shortcode für Galerien habe, nutze ich diesen neuen noch nicht. Aber ich werde ihn mal in Zukunft ausprobieren.

Jedoch vertragen sich mein bisheriger Shortcode von hugo-shortcode-gallery und der neue Shortcode nicht, da sie den selben Namen nutzen.

Deshalb musste ich die Datei themes/hugo-shortcode-gallery/layouts/shortcodes/gallery.html nach layouts/shortcodes/nat_gallery.html kopieren und anschließend alle Vorkommen von

{{​< gallery match="images/*" […] >​}}

nach

{{​< nat_gallery match="images/*" […] >​}}

Umschreiben. Das ging mit der Befehlszeile:

find ./posts/ -type f -iname "*.md" -execdir \
sed -E -i -e 's/ gallery match=/ nat_gallery match=/g' '{}' \;

In Zukunft werde ich für neue Shortcodes immer einem eigenen Prefix verwenden.

Beitragsbilder auch auf Beitragsseite

Beitragsbilder werden jetzt nicht mehr nur in der Liste der Beiträge als Thumbnail angezeigt, sondern auch ganz oben, sobald man den Beitrag öffnet. Es ist jetzt so, wie es zuletzt im hier verwendeten WordPress-Theme war. Das gefällt mir.

Die neue Funktion aktiviert man in der config.toml im Bereich [params] mit:

post.featuredImage = true

Das verwendet Bild ist das selbe wie das Thumbnail eines Beitrags.

Per Voreinstellung wird das Beitragsbild unterhalb des Titels und der Metadaten (Datum, Lesezeit, Tags, Kategorien) angezeigt. Ich bevorzuge es jedoch, wegen meines alten WordPress-Themes, ganz oben über dem Beitrag.

Deshalb habe ich die Datei themes/layouts/partials/post.html nach layouts/partials/post.html kopiert und die Zeile 8 zwischen die Zeilen 3 und 4 verschoben.

Hier der Direktvergleich, oben die alte Ansicht ohne Beitragsbild und unten mit:

Repo einbinden

Per Voreinstellung ist es nur innerhalb des /docs-Layouts möglich, Links zum Repo der Website anzeigen zu lassen, sodass man z. B. die aktuelle Seite auf Github bearbeiten kann.

Das hier kommt in die config.toml:

[repo]
  url = "https://github.com/razonyang/hugo-theme-bootstrap"
  # branch = "main"
  subPath = "exampleSite"
  # dateFormat = "02/01/2006, 15:04:05 PM"

Um die Infos zu einem Repo auch in der normalen Blogansicht anzuzeigen, kann man in die Datei themes/hugo-theme-bootstrap/layouts/partials/hooks/sidebar-begin.html das Partial einfügen: ¹

{{ partial "docs/repo" . }}

Karussell

Fügt man in das Front Matter von Beiträgen den Parameter carousel: true ein, dann werden solche Beiträge auf der Startseite ganz oben in einem eigenen Bereich angezeigt und man kann mit Pfeiltasten zwischen diesen wechseln. Leider hat das bei mir noch nicht funktioniert, es sieht nämlich ganz anders aus als der Projektseite (siehe hier). Hier das Partial dazu.

Schock: Es waren nur 52 Punkte (mobile Ansicht) und 71 Punkte (Desktop). Das ist weit weniger, als bei meinem alten Wiki mit 74 Punkten (mobil) und 98 Punkten (Desktop).

Da das verwendete Theme mit dem Namen “Docsy” von Google stammt (das habe ich erst nach der Entscheidung dafür bemerkt), nahm ich an, dass auch die Punktezahl bei dem Test entsprechend hoch sein sollte.

Auch die Website des Themes erreicht dort nur 48 Punkte (mobil) und immerhin 96 Punkte (Desktop).

Unschön gemachte Offlinesuche

Dann haben wir (Vri und ich) viel ausprobiert und haben herausgefunden, dass es hauptsächlich an der verwendeten Offlinesuche des Themes liegt. Schaltet man diese ab, dann steigt das Ergebnis auf 89 Punkte (mobile Ansicht) und 100 Punkte (Desktop).

Der Grund: Die Index-Datei für die Offlinesuche wird bei jedem Seitenaufruf automatisch abgerufen und ausgewertet. Bei einer ungepackten Größe von ca. 800 KiB der json-Datei ist das nicht unerheblich.

Unschönes CSS

Aber auch ein “Preload” eines CSS ist nicht gerade schön gemacht. Dieses bewirkt, dass es relativ lange dauert, bevor überhaupt Inhalte im Browser angezeigt werden.

Was nun?

Mir ist grundsätzlich egal, wie viele Menschen auf meinen Webseiten gucken und ich habe deshalb dazu auch keine Auswertungen. Mir ist jedoch wichtig, dass man die Inhalte findet, wenn man danach sucht. Und meines Wissens verweisen Suchmaschinen weniger gerne auf Webseiten, die relativ langsam sind. (Stimmt dieses alte Halbwissen überhaupt noch?)

Abgesehen davon soll das neue Wiki auch auf älterer Hardware (Desktop und Smartphone) und langsamen Verbindungen gut funktionieren.

Optimierungen

CSS ohne Preload

Um das Preload aus dem CSS herauszubekommen, kopiert man die Datei themes/docsy/layouts/partials/head-css.html nach layouts/partials/head-css.html und ändert die unteren Zeilen von:

<link rel="preload" href="{{ $css.RelPermalink }}" as="style">
<link href="{{ $css.RelPermalink }}" rel="stylesheet" integrity="{{ $css.Data.integrity }}">

Nach:

<link href="{{ $css.RelPermalink }}" rel="stylesheet">
<link href="{{ $css.RelPermalink }}" rel="stylesheet" integrity="{{ $css.Data.integrity }}">

Suche nur auf bestimmten Seiten

Eine Möglichkeit ist es, die eingebaute Offlinesuche des Themes nicht mehr auf allen Seiten im Wiki anzuzeigen, sondern nur auf einer eigenen Suchseite.

Ich bin kein Profi bei sowas, habe mir den Quelltext des Themes angeschaut und keine Stelle gefunden, das zu tun und diese Möglichkeit daher verworfen. Aber schlaue Menschen können hier bestimmt mehr und könnten das für sich so umsetzen. Daher sei diese Möglichkeit genannt.

Andere Implementierung für die Suche

Eine andere Möglichkeit ist, die eingebaute Suchfunktion zu deaktivieren und selbst eine zu implementieren. Ich habe mich für die Methode entschieden, die in diesem Gist beschrieben wird. (In der Hugo-Dokumentation wird u. a. darauf verwiesen.

Der Code im Gist steht unter der MIT-Lizenz zur Verfügung, siehe hier.

Zu erstellende Dateien und Verzeichnisse

1. In die Datei config.toml:

   [outputs]
   home = [ "HTML", "JSON" ]

2. In die Datei content/de/search/_index.md

   ---
   title: "Suche"
   sitemap:
     priority : 0.1
   layout: "search"
   weight: 20
   menu:
     main:
       weight: 50
   ---

3. In die Datei layouts/_default/index.json:

   {{- $.Scratch.Add "index" slice -}}
   {{- range .Site.RegularPages -}}
       {{- $.Scratch.Add "index" (dict "title" .Title "tags" .Params.tags "categories" .Params.categories "contents" .Plain "permalink" .Permalink) -}}
   {{- end -}}
   {{- $.Scratch.Get "index" | jsonify -}}

Beim nächsten Bau der Website wird die Datei /index.json automatisch erstellt.

4. In die Datei layouts/_default/search.html (abgeändert vom Original, da es nicht funktioniert hat):

   {{ define "main" }}
   <script src="/js/offsearch/jquery.min.js"></script>
   <script src="/js/offsearch/fuse.min.js"></script>
   <script src="/js/offsearch/jquery.mark.min.js"></script>
   <script src="/js/offsearch/offsearch.js"></script>
   
   <section class="offsearch">
   <noscript><p id="offsearch-noscript">Diese Suchfunktion benötigt JavaScript.</p></noscript>
     <div class="offsearch" >
       <form action="{{ "search" | absURL }}">
         <input id="search-query" name="s" placeholder="Wiki durchsuchen…" aria-label="Search" />
       </form>
       <div id="search-results"></div>
     </div>
   </section>
   <!-- this template is sucked in by search.js and appended to the search-results div above. So editing here will adjust style -->
   <script id="search-result-template" type="text/x-js-template">
       <div id="summary-${key}">
         <h4><a href="${link}">${title}</a></h4>
         <p>${snippet}</p>
         ${ isset tags }<p>Tags: ${tags}</p>${ end }
         ${ isset categories }<p>Categories: ${categories}</p>${ end }
       </div>
   </script>
   {{ end }}

5. Ich habe das Verzeichnis static/js/offsearch/ erstellt, wo später die notwendigen JavaScript-Dateien bereitgestellt werden.

6. JavaScript selbst hosten: Ich habe die in der Originaldatei search.html eingebundenen Dateien ins Verzeichnis static/js/offsearch/ heruntergeladen, diese entsprechend lokal eingebunden und hoste sie nun selbst.

7. JavaScript für die Suchfunktion Diese Datei kommt nach static/js/offsearch/offsearch.js:

   summaryInclude=60;
   var fuseOptions = {
   shouldSort: true,
   includeMatches: true,
   threshold: 0.0,
   tokenize:true,
   location: 0,
   distance: 100,
   maxPatternLength: 32,
   minMatchCharLength: 1,
   keys: [
       {name:"title",weight:0.8},
       {name:"contents",weight:0.5},
       {name:"tags",weight:0.3},
       {name:"categories",weight:0.3}
   ]
   };
   
   
   var searchQuery = param("s");
   if(searchQuery){
   $("#search-query").val(searchQuery);
   executeSearch(searchQuery);
   }else {
   $('#search-results').append("<p>Please enter a word or phrase above</p>");
   }
   
   
   
   function executeSearch(searchQuery){
   $.getJSON( "/index.json", function( data ) {
       var pages = data;
       var fuse = new Fuse(pages, fuseOptions);
       var result = fuse.search(searchQuery);
       console.log({"matches":result});
       if(result.length > 0){
       populateResults(result);
       }else{
       $('#search-results').append("<p>No matches found</p>");
       }
   });
   }
   
   function populateResults(result){
   $.each(result,function(key,value){
       var contents= value.item.contents;
       var snippet = "";
       var snippetHighlights=[];
       var tags =[];
       if( fuseOptions.tokenize ){
       snippetHighlights.push(searchQuery);
       }else{
       $.each(value.matches,function(matchKey,mvalue){
           if(mvalue.key == "tags" || mvalue.key == "categories" ){
           snippetHighlights.push(mvalue.value);
           }else if(mvalue.key == "contents"){
           start = mvalue.indices[0][0]-summaryInclude>0?mvalue.indices[0][0]-summaryInclude:0;
           end = mvalue.indices[0][1]+summaryInclude<contents.length?mvalue.indices[0][1]+summaryInclude:contents.length;
           snippet += contents.substring(start,end);
           snippetHighlights.push(mvalue.value.substring(mvalue.indices[0][0],mvalue.indices[0][1]-mvalue.indices[0][0]+1));
           }
       });
       }
   
       if(snippet.length<1){
       snippet += contents.substring(0,summaryInclude*2);
       }
       //pull template from hugo templarte definition
       var templateDefinition = $('#search-result-template').html();
       //replace values
       var output = render(templateDefinition,{key:key,title:value.item.title,link:value.item.permalink,tags:value.item.tags,categories:value.item.categories,snippet:snippet});
       $('#search-results').append(output);
   
       $.each(snippetHighlights,function(snipkey,snipvalue){
       $("#summary-"+key).mark(snipvalue);
       });
   
   });
   }
   
   function param(name) {
       return decodeURIComponent((location.search.split(name + '=')[1] || '').split('&')[0]).replace(/\+/g, ' ');
   }
   
   function render(templateString, data) {
   var conditionalMatches,conditionalPattern,copy;
   conditionalPattern = /\$\{\s*isset ([a-zA-Z]*) \s*\}(.*)\$\{\s*end\s*}/g;
   //since loop below depends on re.lastInxdex, we use a copy to capture any manipulations whilst inside the loop
   copy = templateString;
   while ((conditionalMatches = conditionalPattern.exec(templateString)) !== null) {
       if(data[conditionalMatches[1]]){
       //valid key, remove conditionals, leave contents.
       copy = copy.replace(conditionalMatches[0],conditionalMatches[2]);
       }else{
       //not valid, remove entire section
       copy = copy.replace(conditionalMatches[0],'');
       }
   }
   templateString = copy;
   //now any conditionals removed we can do simple substitution
   var key, find, re;
   for (key in data) {
       find = '\\$\\{\\s*' + key + '\\s*\\}';
       re = new RegExp(find, 'g');
       templateString = templateString.replace(re, data[key]);
   }
   return templateString;
   }
   
   /* MIT License
   
   Copyright 2022 Edward A. Webbinaro
   
   Permission is hereby granted, free of charge, to any person
   obtaining a copy of this software and associated documentation
   files (the "Software"), to deal in the Software without
   restriction, including without limitation the rights to
   use, copy, modify, merge, publish, distribute, sublicense,
   and/or sell copies of the Software, and to permit persons
   to whom the Software is furnished to do so, subject to
   the following conditions:
   
   The above copyright notice and this permission notice shall
   be included in all copies or substantial portions of the Software.
   
   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF
   ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
   TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
   PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
   SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
   CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
   OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR
   IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
   DEALINGS IN THE SOFTWARE. */

Noch etwas CSS für die neue Suchfunktion

Dieses CSS kommt in die Datei assets/css/_styles_project.scss:

.offsearch form {margin-bottom: 40px;}
.offsearch #search-query {width: 100%; padding: 10px;}
.offsearch #search-results p {hyphens: auto;}

Ergebnis – Suchfunktion auf einer einzelnen Seite

Die Suche findet man jetzt unter wiki.natenom.com/search/ und diese Seite ist immer rechts oben verlinkt.

Für die Zukunft ist geplant, diese als Suchfeld in der Navigation einzufügen.

Ich bin sehr zufrieden mit der neuen Suche. Im Vergleich zu der Suche im Blog ist sie extrem schnell und zeigt die Ergebnisse auch schön an.

Deshalb werde ich diese Suche in den nächsten Tagen vermutlich auch in meinem Blog einbauen. Dort dauert die Suche aktuell sehr lange und verursacht sehr viel CPU-Last, obwohl dort als auch im neuen Wiki fuse.js genutzt wird.

Bei der Punktezahl erreicht das Wiki jetzt in 89 Punkte (mobil) (statt zuvor 52) und 100 Punkte (Desktop) (statt zuvor 71).

Sidebar

Ursprünglich hatte ich die Sidebar links (Seitenverzeichnis) so eingestellt, dass man jeden Bereich einzeln aufklappen/zuklappen konnte. Dadurch wurden aber im fertigen HTML ungefähr 2000 Zeilen nur für die Sidebar eingefügt. Übersichtlicher wurde es dadurch aber nicht.

Deshalb habe ich die Sidebar jetzt so eingestellt, dass aufklappen/einklappen nicht mehr möglich ist. Es ist immer nur der aktuelle Bereich geöffnet.

Hier gibt es vom Theme mehrere Einstellungsmöglichkeiten im Bereich params in der Datei config.toml:

• ui.ul_show – Gibt an, bis zu welcher Anzahl die Unterebenen des aktuellen Bereichs geöffnet dargestellt werden.
  • Hier mit ui.ul_show = 1

    

  • Hier mit ui.ul_show = 2

    

• sidebar_menu_compact – Man kann auch alles immer offen einstellen. Aber das eignet sich wirklich nur für sehr kleine Websites:

  

Auch auf die generierten HTML-Dateien wirkt sich das aus. Circa 2000 Zeilen werden benötigt, wenn die Sidebar aufklappbar ist und “nur” noch ca. 1400, wenn die Sidebar nur im aktuellen Bereich geöffnet ist. (Ich hätte erwartet, dass es im letzteren Fall bei sehr kleinen Bereichen wie “Fotografie” nur ein paar Dutzend Zeilen wären.)

Dokumentation zur Sidebar

Zeit zum Rendern des Wiki

Beim Durchstöbern der Einstellungsmöglichkeiten zur Sidebar (siehe oben) habe ich auch die sidebar_cache_limit gefunden.

Aus der Dokumentation:

On large sites (default: > 2000 pages) the section menu is not generated for each page, but cached for the whole section. The HTML classes for marking the active menu item (and menu path) are then set using JS. You can adjust the limit for activating the cached section menu with the optional parameter .ui.sidebar_cache_limit.

In meinem Wiki gibt es aktuell 1333 Seiten und ich habe das Limit testweise auf 500 eingestellt:

sidebar_cache_limit = 500

Die Zeit, um mein gesamtes Wiki zu rendern verringert sich damit von circa 12 Sekunden auf circa 2 Sekunden.

Der Nachteil ist jedoch, dass die übergeordneten Seiten nicht mehr angezeigt werden, sobald man zu tief in den Unterebenen eines Bereichs ist.

Damit ich nicht in Zukunft von diesem Mechanismus überrascht werde, sobald das Wiki über 2000 Seiten hat, habe ich den Wert auf 5000 eingestellt.

Swap Fonts

Ich wurde darauf hingewiesen, dass in bei der Einbindung der selbst gehosteten Schriften im CSS noch einstellen kann, dass lokal vorhandene Systemschriften im Browser verwendet werden, solange die vom Server bereitgestellten Schriften noch nicht heruntergeladen wurden. Dadurch werden Inhalte früher dargestellt.

Pro @font-face {-Eintrag in der Datei assets/scss/_variables_project.scss kommt diese Zeile hinzu: ¹

font-display: swap;

Gar keine systemfremden Schriften

Es ist auch möglich, die Verwendung der eingebundenen Schriften komplett zu unterbinden. Dazu trägt man in der Datei assets/scss/_variables_project.scss ein:

$td-enable-google-fonts: false;

Mir gefällt die verwendete Schriftart des Themes, daher nutze ich nicht die Möglichkeit zur Abschaltung.

Galerie hinzugefügt

Ich habe zum Wiki-Theme noch die hugo-shortcode-gallery hinzugefügt, die ich auch bereits hier im Blog verwende.

cd themes
git submodule add https://github.com/mfg92/hugo-shortcode-gallery.git

Änderungen in der Datei config.toml:

• Aus theme = "docsy" wird theme = [ "docsy", "hugo-shortcode-gallery" ]

Dazu kommen diese Einträge in den Bereich params (die ich so auch im Blog verwende):

galleryShowExif = true
gallerylastRow = "nojustify"
gallerythumbnailResizeOptions = "450x450 q85 Lanczos"
gallerythumbnailHoverEffect = "enlarge"
galleryloadJQuery = true
galleryrowHeight = "150"
gallerysortOrder = "desc"
gallerypreviewType = "none"

Eine Beispielgalerie kann man hier ansehen: wiki.natenom.com/docs/sauerbraten/maps/kleinestadt/.

Das liegt an der Voreinstellung des Shortcodes für Galerien, den ich hier im Blog verwende, der nur extrem kleine Varianten der Bilder ins HTML eingefügt. Erst wenn die Galerie in den sichtbaren Bereich im Browser kommt, wird per lazy-loading ein größeres Vorschaubild geladen und angezeigt.

So würde z. B. eine Galerie aussehen, wenn man das Laden der Thumbnails unterbindet (wie auch im Feed):

Datensparsamkeit

Eigentlich ist das eine gute Sache, denn es werden nur die Bilder geladen, die man auf einer Seite auch anschauen will und nicht solche, die erst ganz weit unten auf der Seite zu sehen wären, man aber gar nicht bis dorthin scrollt.

Mehr Daten für alle, dafür im Feedreader sichtbar

Ich habe das jetzt trotzdem umgestellt und diese extrem schlecht aufgelösten Minimalvorschaubilder deaktiviert. Das bedeutet, dass jetzt auf der Seite immer sofort die kleinen Vorschaubilder geladen werden. Diese sind maximal 450*450 Pixel groß.

Geänderte Einstellungen für Shortcode-Gallery

Dazu muss man die Option previewType der Shortcode-Gallery auf none setzen.

Es ist leider nicht möglich, das nur für den Feed so umzusetzen.

Beispielgalerie

Hier eine Testgalerie mit Fotos einer früheren Fahrradtour für die Leser im Feedreader. Sollte passen :)

Das erste Bild ist matchig, das zweite (nach der Änderung im Blog), ist höher aufgelöst.

Höhere Auflösung für Thumbnails

Das habe ich nun auf maximal 450 mal 450 Pixel angepasst und nun sieht das richtig gut aus. Der Größenunterschied zu 300 mal 150 Pixel ist nur minimal.

Realisiert habe ich das mit einem Eintrag in den Abschnitt Params in der Hugo-Konfiguration:

gallerythumbnailResizeOptions = "450x450 q85 Lanczos"

Zudem kann man pro Galerie den Vorgabewert überschreiben mit:

{{​< nat_gallery match="images/*" … thumbnailResizeOptions="850x850 q85 Lanczos" … >​}}

Bei diesem Blogbeitrag z. B., wo es sehr breite Panoramascreenshots gibt, habe ich den Wert auf 850 x 850 erhöht, damit es gut aussieht.

Noch besser wäre es natürlich, wenn der Shortcode ein srcset für die Anzeigegrößen nutzen würde und Hugo dann alle möglichen Größen rendern würde.

Hovereffekt

Zusätzlich habe ich auch noch thumbnailHoverEffect aktiviert, sodass beim Hovern mit dem Mauszeiger die Bilder um den Faktor 1,1 vergrößert dargestellt werden. Das ist wenig, sieht aber schön aus, wie ich finde.

Auch das kommt in die Hugo-Konfiguration und ist danach Vorgabe für alle Galerien:

gallerythumbnailHoverEffect = "enlarge"

Update: Eine erste Galerie, wo ich das mal mit den .meta-Dateien umgesetzt habe, gibt es hier.

Bisher werden hier im Blog bei Verwendung des Galerie-Shortcodes hugo-shortcode-gallery nur die Bilder angezeigt. Ich hätte aber gerne für manche Bilder eine Beschreibung. So, wie ich es noch von WordPress kenne.

Zwei Methoden verfügbar

Für die verwendete Galerie gibt es zwei Methoden:

1. Verwendung sogenannter Sidecar-Dateien.
2. Hinzufügen der Variable ImageDescription zu den Exif-Metadaten eines Fotos.

Im Prinzip kann man für beide Möglichkeiten einfache Script schreiben, um die Metadaten zu Bildern hinzuzufügen.

Methode Sidecar

Das sind json-Dateien, die es für jedes einzelne Bild gibt.

Heißt das Foto etwa 2021-01-07-mammutbaum-pforzheim.jpg, dann kommen die folgenden Daten in die Datei 2021-01-07-mammutbaum-pforzheim.jpg.meta:

{
"Title": "Ein Mammutbaum in Pforzheim"
}

In der Dokumentatino von hugo-shortcode-gallery sind noch weitere Metadaten in der Datei .meta enthalten, nach meinem Test wird aber nur “Title” im HTML-Code der Galerien hinterlegt.

Methode Exif Metadaten

Exif-Metadaten werden mit meinen Einstellungen in den Bildern der Galerie angezeigt, wenn sie in der Lightbox geöffnet werden. Dazu habe ich in der Konfiguration von Hugo die Option galleryShowExif = true gesetzt.

Unter Linux kann man z. B. mit dem Tool exiftool Exif-Daten in Dateien schreiben:

exiftool -imagedescription="Ein Mammutbaum in Pforzheim" 2021-01-07-mammutbaum-pforzheim.jpg
    1 image files updated

Ergebnis in beiden Fällen

Der Titel wird dann sowohl beim Hover über das Thumbnail angezeigt als auch in der Lightbox oben am Rand. Im HTML-Code fehlt leider das Alt Attribut, dazu werde ich beim Entwickler einen Bugreport erstellen, damit er das noch einfügen kann.

Titel beim Hovern mit der Maus über ein Bild:

Titel in der Lightbox:

Noch nicht entschieden

Ich habe mich noch nicht entschieden, welche Methode ich nutzen werde. In jedem Fall werde ich das Script später hier im Blog veröffentlichen, mit der ich in Zukunft die Bildbeschreibungen hinterlegen werde.

Die Methode mit den Exif-Metadaten hätte den Vorteil, dass die Daten auch in anderen Programmen angezeigt werden können. Zudem könnte ich anfangen, in meiner Fotoverwaltungssoftware immer diese Daten bereits einzutragen.

Ich bin damit auch sehr zufrieden. Bis auf einen Punkt: Ist in der letzen Zeile der Galerie nur noch ein Bild enthalten, dann wird dessen Thumbnail viel größer dargestellt, als es tatsächlich ist, und sieht dadurch matschig aus.

Das liegt daran, dass die Option lastRow per Voreinstellung auf justify gesetzt ist, was dazu führt, dass die letzte Reihe immer auf die selbe Breite gezogen wird, wie die Reihen darüber. Bei zwei oder mehr Bildern sieht man das nicht, bei nur einem Bild aber sehr deutlich.

So sieht es aus, wenn in der letzten Reihe nur ein Bild enthalten ist:

Und so sieht es aus, nachdem man entweder für die einzelne Galerie die Option lastRow="nojustify" oder in der Hugo Konfiguration gallerylastRow = "nojustify" einstellt hat:

Alle Einstellungsmöglichkeiten der Galerie und auch eine Live-Vorschau gibt es auf der Webseite der verwendeten Gallery, siehe hier.

Mit dem heutigen Update auf WordPress 5.3 wurde das Problem teilweise behoben. Zwar kann man immer noch nicht die Vorschaugröße selbst einstellen. Diese wird indirekt automatisch über die Anzahl der Spalten der Galerie festgelegt. Aber immerhin wird beim Anklicken der Bilder nicht mehr die Miniversion der Bilder geöffent sondern das Bild in voller Auflösung. Für mich reicht das aus. Einen schon ziemlich alten Bugreport dazu gibt es auf Github, siehe hier.

Wenn man trotzdem noch den Classic Editor für Galerien verwenden möchte, so muss man jetzt nur noch zum Erstellen einer Galerie in diesen Wechseln. Eine bereits vorhandene Galerie in einem Beitrag kann man jetzt auch im Gutenberg Editor komplett mit allen Einstellungen bearbeiten, so als wäre man im alten Editor.

Ich brauche das aber nicht mehr, deshalb konnte ich heute das Plugin für den Classic Editor endlich löschen und arbeite jetzt nur noch mit dem Gutenberg Editor. Gleichzeitig kann ich auch das Plugin Publish Confirm löschen, das bei einem, meist versehentlichen, Klick auf „Veröffentlichen“ eine zusätzliche Abfrage stellte, damit nicht aus Versehen ein unfertiger Blogbeitrag veröffentlicht wird. Diese Funktion ist bereits im Gutenberg Editor enthalten.

Sehr schön; einen schönen Editor bekommen, zwei Plugins entfernt. Passt. In den nächsten Tagen werde ich dann noch testen, ob das neue Thema Twenty Twenty für meine Bedürfnisse passen könnte.

Fügt man einen Galerie-Block ein, dann werden nicht die voll aufgelösten Bilder verlinkt sondern nur kleine Versionen der Bilder.

Die einzige Möglichkeit ist aktuell, dass man für das Erstellen einer Galerie in den Classiceditor wechselt und dann wieder zurück.

Einen Bugreport gibt es bereits, siehe hier.

Bessere Übersicht

Fast alle Artikel auf den Übersichtsseiten haben jetzt einen „Weiterlesen“-Link. Das macht das Durchstöbern angenehmer, weil man nicht den ganzen Artikel herunterscrollen muss.

Übersichtliche Galerien

Bei Galerien bzw. Artikel mit vielen Bildern wurden bisher sehr große Vorschaubilder verwendet, sodass man direkt beim Aufruf einer Übersichtsseite mit solchen Artikeln sehr viele Daten herunterladen mussten. Auch musste man ewig nach unten scrollen, um zum nächsten Artikel zu kommen.

Hätte ich in solchen Artikeln nur einen Weiterlesen-Link eingefügt, dann wäre die Vielfältigkeit der Bilder verloren gegangen. Denn man hat mir berichtet, dass teilweise intelligente Menschen davon ausgingen, solche Artikel würden nur aus einem einzigen Bild bestehen (dem bis zum Weiterlesen-Link).

Mit der neuen Lösung der Minivorschaubilder sieht man direkt alle Bilder und kann sich durch diese durchklicken, indem man eines davon anklickt.

Mehr Artikelbilder (oberhalb der Überschrift)

Ist ein Bild in einem Artikel vorhanden, so wird dieses auch immer für die Überschrift verwendet. Das sieht insgesamt schöner aus.

Mehr Informationen zu Bildern

Teilweise sind die Bilder in den Gallerien jetzt auch mit Kommentaren versehen, zumindest wenn ich mich an den Ort erinnern kann oder es etwas dazu zu sagen gibt.

Diese werden entweder angezeigt, wenn man mit der Maus über das Bild fährt oder links oben wenn es in groß geöffnet ist.

So sah es vorher aus:

Und so jetzt:

Technische Umsetzung

Zur Erzeugung der Galerien wurde fgallery verwendet. Die Galerien benötigen danach nur statisches HTML und JavaScript. Man benötigt dafür nur einen einfachen Webserver ohne PHP oder Datenbank.

Ein sehr einfaches Script für diese Aufgabe ist z. B.:

#!/bin/bash
FGALLERY="/usr/local/fgallery-1.7/fgallery"
IMAGEDIR="${1}"
mv "${IMAGEDIR}" ".${IMAGEDIR}_src"
"${FGALLERY}" -d -s -j2 ".${IMAGEDIR}_src" "${IMAGEDIR}"

Aufgerufen wird es mit:

scriptname bilder_von_bla

Das Script benennt das Verzeichnis „bilder_von_bla“ im aktuellen Verzeichnis um in „.bilder_von_bla_src“ und erzeugt in einem „neuen“ Verzeichnis mit dem vorherigen Namen „bilder_von_bla“ eine Galerie mittels fgallery.

Wichtig ist dabei, dass am Ende des Verzeichnisses kein Schrägstrich steht.

Wenn man die Originaldateien nicht mehr benötigt, dann kann man die versteckten Verzeichnisse mit _src am Ende danach löschen. In meinem Fall hat sich der Speicherplatz von ~400 auf ~80 MiB verringert :)

Passt.

Der Entwickler der Anwendung hat gestern die neue Version 1.6 herausgegeben, in der die Metadaten von den Vorschaubildern und den verkleinerten Bildern automatisch entfernt werden. In den Bildern mit voller Auflösung bleiben diese jedoch weiterhin enthalten; das Hinzufügen dieser kann jedoch unterdrückt werden.

Die wenigen weiteren Änderungen gibt es im Changelog, siehe hier.

Interessant ist auch die geänderte ToDo-Liste:

• Videos ermöglichen
• Übersichtsmodus mit Vorschaubildchen
• Möglichkeit, die Thumbnails zu deaktivieren
• EXIF-Daten anzeigen, siehe hier

Bin gespannt :)

Im Januar gab es bereits zwei Updates der GPLv2 lizenzierten Software; die interessanten Änderungen sind:

• Es ist nicht mehr notwendig, manuell das Verzeichnis mit der Vorlage in das Zielverzeichnis zu kopieren, daher reicht z. B. der folgende Befehl aus, eine Galerie in /tmp/g zu erstellen:

  fgallery /pfad/zu/bildern /tmp/g "Name der Galerie"
  

• Es kann mit -j angegeben werden, wieviele Threads parallel genutzt werden sollen, um Bilder zu verarbeiten

• Schnellere Erzeugung des Bildarchivs, wenn p7zip installiert ist

Die gesamte Liste findet sich hier.

Leerzeichen…

Verzeichnisse mit Leerzeichen bereitem dem Programm Probleme; dies wurde in der aktuellen Version in Git behoben; den Download dazu gibt es hier.

Gentoo…

Auf meinem Gentoo musste perl mit dem USE-Flag “ithreads” neu kompiliert werden, welches per Voreinstellung nicht aktiviert ist, da es damit Kompatibilitätsprobleme geben soll.

\o/

Die Projektseite von fgallery findet sich hier. Eine Demo-Galerie gibt es auch.

Es fehlt nur noch die Anzeige der Exif-Daten, dann kann ich das für alle Bildergalerien verwenden :)

Heute wurde die Version 1.2 freigegeben. Das Projekt verwendet die Lizenz GPLv2.

Eigenschaften von fgallery

• Bilder werden automatisch ausgerichtet

• Aussehen wurde für mobile Geräte angepasst

• Die Wischfunktion ist auf mobilen Geräten verfügbar

• Wechselt automatisch zwischen vertikalem und horizontalem Modus, sowohl auf mobilen Geräten als auch auf dem Desktop. Hier am Beispiel von Firefox auf Android:

  

  

• Gesichtserkennung für die Generierung von Thumbnails, sodass ein Gesicht in der Mitte der Vorschau zu sehen ist

• Enthält per Voreinstellung alle Originalbilder in einer Zip-Datei zum Herunterladen

• Sortiert wird nach Aufnahmedatum

Angucken

Eine Demo-Galerie des Entwicklers gibt es hier.

Verwendung

Die Erzeugung einer eigenen Galerie wird hier beschrieben. Das Ergebnis kann man irgendwo hochladen, fertig.

Herunterladen und Code

Herunterladen kann man fgallery hier; der Quelltext liegt auch auf GitHub.

Fazit

Sehr schön, weil man so eine Galerie einmal hochladen kann und dann keine Arbeit mehr damit hat.

Was mir zum Einsatz für eigene Bilder noch fehlt ist die Anzeige der Exif-Daten wie z. B. Belichtungszeit und anderer relevanter Daten für Fotografie. Aber das steht auf der Todo-Liste des Entwicklers.