UIO 1.5.2 Blog

Zur Unterscheidung normaler doppelter und einfacher Anführungstriche von sogenannten ScareQuotes suchten wir eine Lösung, mit welcher diese redaktionell eingeben, nachträglich aber stilistisch verändert werden können.

Das Problem hierbei: Es gibt im Deutschen keine Regel für sogenannte ScareQuotes, siehe auch https://en.wikipedia.org/wiki/Scare_quotes.

Zitat: In speech: In spoken conversation, a stand-in for scare quotes is a hand gesture known as air quotes or finger quotes, which mimics quotation marks. A speaker may alternatively say "quote" before and "unquote" after quoted words, or say "quote unquote" before or after the quoted words, or pause before and emphasize the parts in quotes. These spoken methods are also used for literal and conventional quotes.

Das Update 1.5.2.68 bringt eine Reihe kleinere Ergänzungen insbesondere in Bezug auf die Doku.

Das Modul für die Erzeugung von Kalender ermittelt inzwischen Day-Elemente, erkennt Wochenenden und ist in der Lage deutsche Feiertage zu berechnen. Das Berechnungsprogramm für Zeitblöcke ist im Aufbau.

Die bisherige rote Farbgebung wurde für @cty Seiten auf dunkelgrün verändert, um das Lesen von Inhalten auf diesen Seiten zu verbessern sowie zudem auch den Fotos und Bildern auf diesen Seiten mehr Geltung zu verschaffen.

Farb-ID: snmcty

client/theme/css geändert

Keine Breaking Changes.

Mit Hilfe von ce:ContentReference ist es bekanntlich möglich, über den uri-Parameter andere XML Files zu verlinken, um deren Inhalten nachladen und rendern lassen zu können.

So gut das Verfahren auch schon lange funktioniert: Es bestand nun der Wunsch, für dieses Rendering zusätzlich Parameter übertragen zu können, damit auch Inhalte, die eigentlich basierend auf statischem Content zentral gepflegt werden, dennoch um Parameter erweitern zu können.

Wir haben uns von C# .NET Delegates und Lambdas inspirieren lassen und sind dabei, ergänzende Parameter auch für Content-Referenzen übergeben zu lassen.

Wie haben A= (A) , B= (B) , C= (C) und D= (D) eingebeben.

Dieser Text ist DEMOTEXT mit dessen Hilfe wir die Verwendung von ContentInstance Parametern testen. Dieses Feature ist noch im Test. Für Fragen nehmen Sie Kontakt auf.

Dieses Feature befindet sich derzeit in der Konzeption.

Die Problemstellung besteht mitunter darin, dass mit apply-templates gerenderte XML-Dokumente in den Fällen, in denen diese aus einer zentralen Datei geladen wurden, zwar XML Variablen für A, B, C und D verwenden könnten. Die zugehörige Werte für A bis D müssten für den Rendering-Prozess allerdings den zugehörigen Templates für die Content Elemente übergeben werden. Das ist aber bei Hunderten von Templates so nicht möglich.

Wir unterliegen der Einschränkung von XML/XSL 1.0. Viele Nutzer von Shared Webhosting Angeboten haben nicht die Option, XSL 3.x Features nachinstallieren zu können.

Basierend auf Feedback aus der Community haben wir die <ce:FootNote> um eine Konfigurationseigenschaft <ce:label> ergänzt. Damit ist es nun möglich, bei der Deklaration der Fußnote direkt den vorangestellten eigentlichen Text anzugeben zu welchem diese Fußnote eigentlich gehört.

In diesem Zusammenhang wurden die Styles so programmiert, dass zwischen dem Text der Label und der Darstellung der hochgestellten Nummer für den Fußnotenverweis in der Browseransicht kein Zeilenumbruch mehr stattfinden kann.

Bugfix: Der zwischenzeitlich Bug, bei welchem sich über den Rücksprung vom FootNote-Text die URL geänderte hatte, indem dort ein / Schrägstrich angehängt wurde, ist behoben.

Man kann also nun einen Fachbegriff ^[1] im Text verwenden, ohne dass dieser in diesem Text selbst erläutert werden muss.

Vor dem Hintergrund, dass zwischen dem Text der Label und dem Fußnotenverweis die Zeilentrennung verhindert wird, ist dringend zu empfehlen, den Text der Label möglichst kurz zu fassen.

Sollte die Fußnote sich auf mehrere vorangehende Worte oder sogar einen ganzen Absatz beziehen, so sollten Sie die <ce:label> Eigenschaft nicht angeben.

Eine Verschachtelung von Fußnoten ist nicht möglich. Es ist also nicht möglich, ein <ce:FootNote> Element innerhalb des <ce:content> Bereichs eines <ce:FootNote> Elements zu verwenden.

Fußnoten auf einer Seite werden automatisch in der Reihenfolge, in welcher diese im Text erscheinen, durchnummiert. Das Einfügen einer neuen Fußnote oberhalb im Text führt also dazu, dass alle bisherigen Fußnoten eine neue Nummer und damit auch eine neue Adresse bekommen.

Wenn Sie zwingend eine Sprungmarke auf einer WebPage angeben möchten

Die Fußnoten können redaktionell verwendet werden. Es sind aber für die Zukunft Erweiterungen sowie auch Änderungen denkbar.

Fehlender Parameter für einen optionalen Rücksprung zu PageAnchorLinks Menüs im Kopf der Inhalte, T181.

Fehlender Parameter für die Ausgabe eines Icons wie dieser z. B. für das Anlegen von Bookmarks auf manchen Seiten üblich ist. T182.

Der zwischenzeitlich Bug, bei welchem sich über den Rücksprung vom FootNote-Text die URL geänderte hatte, indem dort ein / Schrägstrich angehängt wurde, ist behoben.

Dieser Bug hatte dazu geführt, dass man immer nur einmal je WebPage zurück zur Stelle im Originaltext springen konnte, weil bei einem weiteren Sprung von einer Fußnote zu deren Texte bei einem Rücksprung dann bereits mit / zwei Slashes angehängt wurde und vom Server die URL nicht mehr erkannt wurde.

Die Einführung der Option, mehrere Domains mit der selben UIO System-Installation rendern zu lassen, hat einige Folgen gehabt. So kann es passieren, dass für bestimmte Domains oder Subdomains keine SSL Zertifikate vorliegen.

Damit der SETTINGS_FORCE_HTTPS Parameter aus .htaccess Files auch in den Templates für die Erzeugung der vollständigen URLs von Links bekannt ist, wird auch diese Umgebungsvariable ab 1.5.2.64 an PHP und die Template Engine weitergereicht.

Hinweis: Im Zuge der Verwendung mehrerer Domains je Installation ist es erforderlich, dass für die Gültigkeit einer Regel immer die zugehörige Bedingung ("cond") davor nochmals definiert wird. Die htaccess Files kennen in 2024 keine Blöcke für Definition!

Dieses betrifft alle UIO Installationen bei welcher eine Installation mehrere Domains abdecken soll.

Ab 1.5.2.62 ist es zwar möglich, auch Anfragen an eine Domain komplett weiterzuleiten. Wir empfehlen aber, dass für bestimmte URIs einer Seite doch mit 301 und 302 gem. HTTP kontrolliert zu tun.

Schritt 0: Fahren Sie zuerst eine SICHERUNG Ihrer lokalen Daten und auch ggf. der Daten auf dem Produktivsystem.

Schritt 1: Anlegen eines neuen Realm für die bisherige Domain als Forward-Realm. Hierbei hängen Sie "-forward" an den Namen des Realm-Folders an.

Schritt 2: Anlegen einer RoutingDefinition.xml Datei im Forward-Realm.

Schritt 3: Konfigurieren Sie die zugehörigen Weiterleitungen mit 301 (permanent) und 302 (found) für URIs. Denken Sie daran, die Zieladresse als forward-uri mit https://example.com/ oder der gewünschten Domain beginnen zu lassen. Erst dann folgt der eigentliche URI innerhalb der neuen Zielseite.

Schritt 4: Aktualisieren Sie die routing_config_REALMS.xml und ergänzen Sie den neuen Forward-Realm für die alte Domain, und zwar in der Reihenfolge vor den neuen Realms.

Schritt 5: Legen Sie für die alte Domain nun noch einen Konfigurationsfile in /conf an. Diese Daten werden zwar eigentlich gar nicht verwendet, weil die Weiterleitungen vorher erfolgen sollten. Die Angabe des Files ist aber erforderlich, damit die Engine den Zugriff und die Verarbeitung für HTTP Requests überhaupt akzeptiert.

Schritt 6: Aktualisierung Sie die .htaccess Files für die sowohl lokale als auch die online-Version. Denken Sie hierbei daran, dass Sie die RewriteRule für die HTTPS ggf. auf false setzen müssen falls Sie für die alte Domain kein SSL Zertifikat haben sollten: RewriteRule ^ - [E=SETTINGS_FORCE_HTTPS:false]

Schritt 7: Eigentlichen Realm für alte Domain anlegen. Hierzu gehört die RoutingDefinition.xml welche auf den Kurznamen für den Realm- bzw. RootNode erforderlich ist sowie eine RealmNode.xml Datei für die Startseite und eine RealmNode_HTTP404 Seite.

Schritt 8: Der vollständigkeithalber sollte noch die sitemap.xml Datei angelegt werden, auch wenn darin faktisch nichts oder fast nichts stehen wird.

Schritt 9: LOKALES TESTEN! Erst dann Daten auf den Hauptserver übertragen.

Im Zuge der Verschiebung von Routing-Konfigurationen vom jeweiligen Webserver (NGINX, APACHE etc.) zu Applikation wurde die Verarbeitung von <forward-uri> Werten von <route> Einträgen in der 'RoutingDefinition' geändert.

Ab 1.5.2.61 sind jetzt gegenüber bisherigen URIs auch wieder vollständige URLs möglich, um nicht nur intern routen und "forwarden" zu können sondern auch an externe Domains inklusive Angabe des Protokolls.

Damit in Google bekannte URLs und insbesondere URIs für eine Domain für eine Webseite, die diese Anfrage bekommt, auch in Zukunkt erreicht werden kann, um Anfragen an die URI kontrolliert mit 301 oder 302 auf die neue URI weiterleiten zu können, war bislang der folgende Code in der "RoutingDefinition" in UIO bis 1.5.2.60 üblich.

Ab 1.5.2.61 ist es möglich, die Domain mit Protokoll der URI voranzustellen. Der Router vermag Adressen mit http:// bzw. https:// von reinen URIs zu unterscheiden.

Hinweis: Die canonical-Angabe hat für Weiterleitungen keine Bedeutung.

Vorher:

Nachher:

Dieses Verfahren ermöglicht es nun, im Fall einer fehlenden Suchfunktion auf einer mit UIO realisierten WebPage diese Suche auf Google auszulagern. Dieses setzt allerdings voraus, dass Google die WebPages dieser WebSite im Index erfasst hat.

In dieser Variante lenken wir die Suche nach dem Begriff "JAVA" auf "Java Kurstermine Wiesbaden" in Google um und reduzieren das Suchergebnis nur auf Seite von SNEWMEDIA.COM.

HINWEIS: Google schaltet allerdings dennoch auch für diesen Fall Google Ads Werbung von Mitbewerbern.

Redaktion:

Die Blogs und Blogposts werden schrittweise überarbeitet und gelten zukünftig nicht mehr direkt als WebPage sondern als SocialMediaPosting Instanz.

SocialMediaPosting Daten sollten ab UIO 1.5.2.60 als <ce:SocialMediaPosting> Element in eigenen XML Files erfasst oder als entsprechende XML-Files erzeugt werden.

Die redaktionellen Inhalte für ein <ce:SocialMediaPosting> befinden sich hierbei im der <ce:articleBody> Property. Der zugehörige redaktionelle Inhalt wird hierbei als vollständiger <CEContainer> geschrieben und kann damit sowohl Layout-Zeilen als auch die üblichen 1/2/4 Layout-Spalten haben.

Eine Liste von SocialMediaPosting Einträgen lässt sich über das <ce:SocialMediaPostingList> Element plazieren.

In Version UIO 1.5.2.60 verfahren wir dahingehend, dass der Konfigurationsparameter <ce:items> die Referenzierung von <ce:SocialMediaPosting> Instanzen ermöglicht, indem dort das ref=".." Attribut die zugehörige des Files über eine relative Adressierung im Realm angibt.

Diese Art der Adressierung ist provisorisch!

Das Verfahren ist ein Prototyp und dient primär der Ideenfindung. Wir empfehlen bei Bedarf an Blog und Posts in der Zwischenzeit den bisherigen Ansatz: Legen Sie Blogposts entweder als WebPage oder aber als Section in einer WebPage an.

Das refdefault Attribut der Liste ermöglicht es, einen Default-Blog-Post anzugeben. Dieser wird dahingehend verwendet, um fehlende Felder wie mitunter für ce:author und andere Properties zu füllen.

Die Adressierung einzelner SocialMediaPosting Instanzen als Teil der Items der Liste ist provisorisch. Die Adressierung wird zukünftig über eine ID erfolgen und/oder über ein Verfahren, über welches der XML-Code direkt im Web adressiert werden kann.

Das ref=".." Attribut wird zukünftig die ID referenzieren und nicht mehr einen XML Files. Da eine ID allerdings eine alphanummerische Zeichenfolge darstellen kann die derzeitige File-Adressierung zwischenzeitig als ID-Referenzierung verwendet werden.