Fryboyter

Bolt CMS - Die Suchfunktion oder warum mich das Routing ans Limit bringt

Die Umstellung von fryboter.de von Wordpress auf Bolt CMS verkommt langsam einer unendlichen Geschichte. Kaum bin ich "fertig", kommt mir eine neue Idee, was ich noch ändern kann. Wichtig war mir aber schon immer die Suchfunktion.

Schon seit ich mir der Umstellung begonnen habe, hat es mich gestört, dass die Suchfunktion bei Bolt nicht funktioniert hat. Das Suchfeld einzubauen war eigentlich kein Problem. Aber bei jeder Suche bekam ich einen Fehler 404 angezeigt. Die Lösung des Problems zeigt mal wieder, dass auch Bolt CMS Ecken und Kanten hat. Wobei man hier nicht von einem Fehler an sich reden kann, sondern davon, dass Bolt CMS einige Stellschrauben hat.

So würde die Grundinstallation beispielsweise auf einen Artikel in Form von https://planetlinux.de/entrie/deutschsprachiger-usenet-server-mit-schwerpunkt-arch-linux verlinken. Da aber Google die Artikel in Form von https://planetlinux.de/deutschsprachiger-usenet-server-mit-schwerpunkt-arch-linux indexiert hat, ist das blöd, weil ich nicht von null anfangen oder mit htaccess tricksen will.

Hier kommt nun der Teil von Bolt CMS ins Spiel der mir immer noch Kopfschmerzen bereitet. Das Routing. Hiermit lassen sich kurz gesagt die Aufrufe umbiegen. Um das “entrie/” aus den Artikellinks zu entfernen habe ich folgendes als Erstes in die Datei routing.yml eintragen.

pagebinding:
path: /{slug}
defaults:
   _controller: controller.frontend:record
   contenttypeslug: entrie
   contenttype: entriest;

Als Erstes, weil die Einträge ganz oben die höchste Priorität haben. Um so weiter unten Sie in der Datei stehen um so weniger Priorität haben sie (und werden somit zum Beispiel nicht beachtet). Das Beispiel zeigt beispielsweise, dass alle Inhalte mit dem Inhaltstyp entries über den Pfad /slug ereichbar sind. Also zum Beispiel https://planetlinux.de/deutschsprachiger-usenet-server-mit-schwerpunkt-arch-linux.

Ein Stückchen weiter unten in der Datei ist bereits die Route für die Suche vorhanden.

search: path: /search defaults: _controller: controller.frontend:search

Aber egal was ich versucht habe, die Suche hat immer nur den Fehler 404 ausgespuckt. Eine Zeit lang war ich so weit, dass es zukünftig einfach keine Suchfunktion geben wird. Punkt. Ende. Aus. Die Lösung war dann doch recht “einfach”. So richtig kapiere ich sie aber trotzdem nicht. Ich habe einfach den Teil mit der sich auf die Suche bezieht über den Teil mit dem Pagebinding eingetragen. Und schon funktioniert die Suchfunktion. Klar es hat etwas mit der Priorität zu tun. Aber /search und /{slug} sind doch zwei unterschiedliche Sachen, oder nicht? Na ja das ist erst mal egal. Es funktioniert ja.

Was jetzt noch fehlt, ist der RSS-Feed für eine bestimmte Kategorie. Irgendwie muss ich ja meine Artikel auf osbn.de veröffentlichen. Es gibt zwar eine Erweiterung aber diese kann “nur” einen seitenweiten Feed bzw. einen pro Inhaltstyp erstellen. Und der Inhaltstyp umfasst alle Artikel die ich auf fryboyter.de veröffentliche. Da hier auch mal der eine oder andere Artikel veröffentlicht wird, der nichts mit osbn.de zu tun hat, ist das blöd… Noch blöder ist es, dass ich absolut keine Ahnung habe wie ich diese Erweiterung ändern könnte.

Ich habe daher einfach mal den Entwickler der Erweiterung auf Github gefragt, ob eventuell in absehbarer Zeit auch Feeds für einzelnen Kategorien möglich sein werden. Bisher habe ich aber noch keine Antwort erhalten. Zur Not habe ich mir auch einfach mal eine PHP-Datei gezaubert die mir einen Feed erstellt. Besonders froh bin ich aber nicht mit der Lösung. Wer will, kann sie sich ja mal ansehen…

echo '<'.'?xml version="1.0" encoding="UTF-8"?'.'>'; ?> 
<rss version="2.0"
    xmlns:content="http://purl.org/rss/1.0/modules/content/"
    xmlns:wfw="http://wellformedweb.org/CommentAPI/"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:atom="http://www.w3.org/2005/Atom"
    xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
    xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
    >

<channel>
    <title>Fryboyter.de</title>
    <atom:link href="https://fryboyter.de/files/feed.xml" rel="self" type="application/rss+xml" />
    <description></description>
    <language>de-DE</language>
    <link>https://fryboyter.de</link>    
    <sy:updatePeriod>hourly</sy:updatePeriod>
    <sy:updateFrequency>1</sy:updateFrequency>

<?php 

$host = "localhost";
$user = "Nutzer";
$pass = "Passwort";
$dbase = "Datenbankname";

$connection = mysqli_connect("$host" , "$user" , "$pass") OR DIE ("Keine Verbindung zu der Datenbank moeglich.");
mysqli_select_db($connection , $dbase) or die ("Auswahl der Datenbank nicht moeglich.");

// Datenbankabfrage
$query = "SELECT bolt_entries.slug AS slug, bolt_entries.datepublish AS date, bolt_entries.title AS title, bolt_entries.body AS blabla FROM bolt_entries, bolt_taxonomy WHERE bolt_entries.id = bolt_taxonomy.content_id AND bolt_taxonomy.slug = 'osbn' AND bolt_entries.status = 'published' ORDER BY bolt_entries.datepublish DESC LIMIT 20";  
$result = mysqli_query($connection , $query) or die (mysql_error()); 

// Ausgabe der Daten
while ($row = mysqli_fetch_array($result)){ 
    $slug = $row['slug']; 
    $title = $row['title']; 
    $blabla = $row['blabla']; 
    $pubdate = strtotime($row['date']);
    $pubdate = date('r', $pubdate);     
?> 
    <item>
        <title><?php echo $title; ?></title>
        <link>https://planetlinux.de/<?php echo $slug; ?></link>
           <guid isPermaLink="false">https://fryboyter.de/<?php echo $slug; ?></guid>
        <pubDate><?php echo $pubdate; ?></pubDate>
        <description><![CDATA[<?php echo $blabla; ?>]]></description>
    </item>
<?php } /* close while*/ ?>

</channel>
</rss>

Die Ausgabe der Datei in eine XML-Datei weitergeleitet erzeugt zumindest schon mal einen validen Feed. Allerdings müsste ich die Datei per Cronjob laufen lassen. Auf eine Lösung wie die Datei aufgerufen wird, sobald ein neuer Artikel veröffentlicht wurde, bin ich noch nicht gekommen.

OSBN

Das Ende von Wordpress naht

Vor einigen Monaten hatte ich hier schon mal geschrieben, dass ich WordPress den Rücken kehren will. Als neue Plattform habe ich Bolt CMS gewählt. Der Wechsel ist in letzter Zeit aus beruflichen Gründen, aber auch weil ich wenig Lust hatte, ins Stocken geraten. Aber es geht in die nächste Runde.

Seit heute bin ich quasi in der Beta-Phase angekommen. Was das Template betrifft, habe ich es bewusst schlicht gehalten. Und das nicht nur, weil ich von Grafikbearbeitung keine Ahnung habe.

Fryboyter Beta

Das Template an sich ist aktuell gerade mal 18 KB groß und besteht aus 10 Dateien (inkl. Bilddateien, exklusive Webfonts). Allerdings blähen die eingebetteten Webfonts (EOT, SVG, TTF, WOFF und WOFF2) das ganz auf 1,9 MB auf. Bezüglich der CSS-Datei lässt sich vermutlich noch das eine oder andere KB einsparen, da viele Einträge nicht genutzt werden.

Was mir allerdings richtige Sorgen gemacht hat, war der Import der Wordpress-Artikel. Denn hier gibt es leider keine Erweiterung die unter Bolt CMS 3.x funktioniert. Ich habe mir daher eine abenteuerliche Lösung selbst gebaut. Leider hat diese aktuell noch dermaßen Ecken und Kanten, sodass ich vermutlich auch gleich die Artikel per Copy-and-paste übertragen hätte können. Von der Entwicklungsdauer will ich erst gar nicht anfangen. Zudem sind bei einigen Artikeln Nachbesserungen nötig (spezielle Formatierungen von Wordpress-Erweiterungen usw.). Kurz gesagt, der Import war zum Kotzen. Vermutlich wäre das aber auch so spaßig geworden, hätte ich auf ein anderes System gesetzt.

Ein weiteres Sorgenkind ist die Suchfunktion. Ich habe unter Bolt das Routing so geändert, dass die Links nicht https://planetlinux.de/entrie/deutschsprachiger-usenet-server-mit-schwerpunkt-arch-linux lautet, sondern https://planetlinux.de/deutschsprachiger-usenet-server-mit-schwerpunkt-arch-linux. Dann zickt allerdings die Suchfunktion von Bolt. Allerdings bin ich mir nicht sicher, ob es wirklich an Bolt liegt oder ob ich hier das Problem bin. Hiermit werde ich die Entwickler von Bolt bzw. die Gemeinschaft um Bolt wohl noch mal um Hilfe bitten müssen. Alternativ überlege ich mir auch, ob ich überhaupt eine SuFu brauche…

Ansonsten läuft alles genauso wie ich es mir vorgestellt habe. Schnell, stabil und ressourcenschonend. Im Debug-Modus werden gerade mal 2 MB in der Spitze verbraucht. Mein PHP Speicherlimit liegt bei 128 MB. Wenn ich den Debug-Modus deaktiviere, wird vermutlich noch weniger Speicher benötigt. Alles in allem war der Wechsel die richtige Entscheidung für mich. Vor allem, wenn es um die Templates geht.

OSBN | Allgemein