uio--WebPageMain-Module
Irgendeiner sollte sich mal drum kümmern. Es könnte auch jemand anderes machen. Nur wer?

Tasks "TODO-LISTE"

Liste mit Bugs, Wünschen und To-Do

Überblick

Hinweise

Entwicklung - KEIN Design.

Bitte habt dafür Verständnis, dass wir uns im DEV Bereich nur mit technischen Aspekten und Daten zu UIO Design System nicht befassen, NICHT mit Webdesign und damit auch nicht mit der Frage, wie die Ansichten angehübscht werden könnten. Wenn Ihr das Design verbessern wollte so wechselt in den CREATE Bereich.

Wir informieren über Workarounds [1] um Ihnen eine Lösung für den Zeitraum zu ermöglichen, indem wir eine Lösung für das eigentlich Problem angehen oder eben auch zuweilen mal nicht. Schlussendlich muss irgendwer die Arbeiten auch machen.


Zur Zeit für 1.5.2.x in Planung

Die Wunschliste für Features hat eine gewisse Länge.

BreadCrumbList

Erweiterung von BreadCrumbList(s) um eine semantische Auszeichnung mit deren Hilfe aus den mit UIO realisierten Webseiten.

BreadCrumbList (50%)

Erweiterung von BreadcrumbList(s) um eine semantische Auszeichnung mit deren Hilfe aus den mit UIO realisierten Webseiten. Eine BreadcrumbList für den menschlichen Nutzer gibt es bereits. Was aktuell noch fehlt ist die maschinenlesbare Version für die API mit welcher wir auch Domain-übergreifend in Echtzeit Informationen zu Seitenstrukturen und Aktualisierungsdaten von Webseiten unserer Partner austauschen können.

Scroll-to-Top-Link

Wie manche bereits bemerkt haben: Die Scroll-To-Top-Links unten rechts auf der Webseite funktionieren seit 1.5.2.x nicht mehr. Dieses Element wird demnächst durch eine Variante ersetzt und im Ist-Zustand erst einmal ignoriert.

Meta-Daten (SOLVED)

Die Meta-Daten für Keywords, Description, Abstract werden seit 1.5.2.x nicht mehr im HTML5 Code ausgegeben. Ursache ist die Durchsetzung von Namespaces in der Dokumentstruktur. Das Problem wird in 1.5.2.x behoben werden.

Scroll-to-Top-Link (0%)

Der Scroll-to-Top-Link untenrechts im Layout funktioniert zur Zeit nicht. Das Element ist noch eine Altlast aus einer alten Template und wird demnächst durch eine UIO Variante ersetzt werden.

T146 Schließen-Icon für Modal

Ungünstiger Schließen-Icon

Der Icon oben rechts in modalen Fenstern sollte von x auf das Unicode-Zeichen × geändert werden.

T147 Punkte im URI-Segment

Problemstellung

Problemstellung: Ein URI-Segment wie beispielsweise example-0.0.0.0 kann in uio-1.5.2.24 nicht verwendet werden weil im Rendering offenbar die Punkt-Zeichen . ignoriert werden.

Ursache

Die Ursache scheint im Routing-Modul beim Matching von URIs zuliegen. Die Punkte werden als Teil der URI in den Dokumenten korrekt erfasst.

Workaround

Der bisherige Lösungsansatz besteht darin, statt . Punkt-Zeichen ein - Minus-Zeichen zu verwenden: example-0-0-0-0

Unterstriche _ sind zwar auch denkbar, eine manuelle Eingabe mit dem Smartphone ist dann allerdings etwas schwieriger. Darüber hinaus ist die Schreibeweise example_0_0_0_0 mit Unterstrichen unüblich.

Status

T148 Bookmark Icons

Problemstellung

Wir können in 1.5.2.x zwar PageAnchor definieren und diese entweder über entsprechende Links im Menü oder auch über die automatisiert erzeugen PageAnchorLinks anspringen. Ist man aber an der entsprechende Stelle auf der Seite sieht man diese Sprungmarken dort nicht und ist damit auch nicht in der Lage, beim Scrollen in einem Inhalt auf einer Seite die Position zu speichern.

Der Icon soll über die Konfiguration des Themes geändert werden und über das Basis-Theme definiert als Standard gelten.

Die bisherigen PageAnchor haben bislang im Layout keine visuelle Darstellung und dienen einzig und allein als Lösungsansatz, um die Position zu definieren, zu welcher gesprungen wird. Sie dienen auch zugleich dazu, den Title bzw. die Label für das Menü anzugeben.

Hinweis: Es handelt sich genau genommen semantisch betrachtet um eine Verknüpfung mit der linken oberen Ecke eines WebPageElement Content-Elements. Es ist also denkbar, dass wir diese PageAnchor Elemente schlichtweg im Content jedes Content Elements ermöglichen.

Workaround

Der bisherige Workaround besteht darin, schlicht den Begriff, um den es geht, im Text nach der Überschrift nochmals zu erwähnen und diesen als InlineLink auf auf diesen Block zu verlinken.

Der Vorteil dieses Verfahrens besteht darin, dass ein Mensch und auch eine Suchmaschine direkt den Zusammenhang zwischen Sprungziel des Links und der Label/Aufschrift versteht. Bei einem Icon ist das nicht sofort ersichtlich.

Üblicher Ansatz

Der nachfolgende Beispielcode zeigt das Prinzip: Der Link kapselt einen i-Element dessen Gestaltung über eine CSS realisiert wird in welcher der eigentliche Icon dann entweder als Grafik verlinkt oder als base46 Kodierung im Code zu finden ist.



<a href="#jobs-stellenangebote-praktika">
 <i class="fa fa-link" aria-hidden="true"></i>
 <span class="IconForBookmark_URI" style="display: none;">
 #jobs-stellenangebote-praktika</span>
</a>

<a href="#cases">
 <i class="fa fa-link" aria-hidden="true"></i>
 <span class="IconForBookmark_URI" style="display: none;">
  #cases
 </span>
</a>

Status

T149 TextShortener

Problemstellung

Das ce:TextShortener Element ab 1.5.2.29 ermöglicht zwar die Verkürzung der Ansicht sehr langer Begriffe und ist auch in der Lage, durch Klick auf den gekürzten Begriff eine lange Version anzuzeigen. Die Darstellung in voller Länge sprengt allerdings das oftmals das Layout. Darüber hinaus ist es für den Nutzer nur anhand von "..." am Ende des Betriffs ersichtlich, dass der Text für die Ansicht gekürzt wurde.

Workaround

Die Notlösung besteht darin, solche langen Texte in Absatzelementen dort einzufügen, wo eine lange Darstellung, auch wenn diese über das Layout einer Spalte hinaus geht, immerhin überhaupt noch gelesen werden kann.

Vorschlag

Es wird angeregt, dem Element in der Darstellung einen Mouse-Over-Effekt zu geben mit dessen Hilfe angezeigt wird, dass man durch Klick die volle Länge sehen kann. Diese Darstellung ließe sich dann als modaler Dialog anzeigen, dh. aufklappen in einer Layer in der Mitte des Browserfensters bzw. über oder neben dem Element; dieses mit der Option, das Element auch leicht wieder schließen zu können.

Status

Diese Erweiterung hat bislang eine geringe Priorität weil bereits jetzt ein Klick auf das Element den langen Begriff überhaupt darstellen kann.

T150 SoftwareSourceCode

Problemstellung

Damit die manuelle Redaktion in XML von ce:SoftwareSourceCode Elementen und deren Überprüfung erleichtert wird, werden vor Beginn des Quellcode-Samples und zum Ende eigentlich überflüssige Zeilenumbrüche, Leerzeichen und Tabulatoren eingeführt.

Da die Inhalte mit HTML5 PRE Elementen gerendert wird, damit jedes Zeichen im Quellcode auch exakt an der selben Position wie im Originalcode ausgegeben wird, führt das zu der Problemstellung

Workaround

Die Notlösung kann darin bestehen, die erste Zeile des Codes direkt nach dem CDATA-Block zu beginnen und zwischen dem text-Knoten und dem CDATA-Block keine Leerzeichen einzufügen.

Wir empfehlen Ihnen, dass nicht zu tun, da wir eine automatisierte Lösung realisieren werden.

Lösungsweg

Alle Inhalte innerhalb der text-Eigenschaft werden vor Beginn des CDATA-Elements entfernt.

Alle White-Space-Character zwischen öffnendem CDATA Element und dem Zeilenumbruch, welcher vor der ersten Zeile mit einen Nicht-White-Space-Character und damit Quellcode des eigentlichen Samples beginnt, wird gelöscht.

Alle Whitespace-Character nach Ende des letzten Nicht-White-Space-Character werden bis zum folgenden schließenden Block des CDATA Bereichs gelöscht.

Alle Zeichen zwischen dem schließenden CDATA-Element und dem schließenden text-Element der text-Eigenschaft des SoftwareSourceCode-Elements werden gelöscht.

Status

Umsetzung ist vorgesehen noch für 1.5.2.x.

T151 LinkedData WebPage

Problemstellung

Wir benötigen für eine semantische Verknüpfung von WebPage-Instanzen über verschiedene UIO Systeme eine LinkedData Auszeichnung der zuhörigen WebPage(s).

Planung

Die WebPage Instanzen werden redaktionell als ce:WebPage-Elemente gepflegt. Die ergänzenden semantischen Zusatzinformationen sind allerdings sehr, sehr umfangreich.

Wir erwägen dahingehend, einen möglichst großen Anteil dieser Informationen automatisiert durch Skripts zu ermitteln.

Damit alle WebPages bestimmte Werte konsequent erben können, ist es vorgesehen, Eigenschaften vorab "initialisieren" zu können über eine übergeordnete Seite. Wir gehen derzeit davon aus, dass diese Standard-Informationen über die WebSite-Instanz definiert und/oder von dort wiederum referenziert werden.

Status

Work-in-Progress

T152 WeekCalender

Problemstellung

Für eine leichtere Ermittlung von Zeitblöcken für Abstimmung von Terminen ist es erforderlich, dass dass das WeekCalender-Element in der Redaktion verwendet werden kann.

Planung

Zeitblöcke: Die Synchronisierung zwischen Wochen im Kalender und den Feiertagen fehlt noch, um nur die Blöcke als korrekte Blöcke zu ermitteln, die nicht durch Feiertage unterbrochen werden.

Synchronisierung der Verfügbarkeit von Ressourcen wie Personen, Maschinen, Räumen mit den jeweiligen Blöcken steht noch aus.

Realisiert

Der Wochenkalender in einer Rohfassung ist fertig und ermittelt für den Zeitraum von "n" Wochen alle Wochen mit zugehörigen Anfangs- und Enddaten.

Wir haben ein Skript geschrieben welches uns alle Wochenenden und Feiertage inklusiver aller Feiertage, welche sich nach Ostern ausrichten, programmiert.

Status

Work-in-Progress

T153 LinkedData BreadcrumbList (Bug, small)

Problemstellung

Der Breadcrumb-Pfad erzeugt basierend auf den jeweiligen URI Segmenten die Zielseiten mit einer 'id' und einer 'url'. Das ist soweit korrekt.

Der Fehler besteht hierbei darin, dass auch für die Sprachversion wie '/de' eine solche Seite in der BreadcrumbList. Diese Seite gibt es gar nicht.

Work-Around

Das Problem wird dadurch gelöst, dass ein '/de' URI Pfad kurzerhand entweder auf den Root des Realm wie '/de/@???' oder zurück auf '/' geroutet wird.

Planung

Der erste Schritt zu einer Lösung sollte darin bestehen, dass ein URI-Segment, welches nur aus einem einzigen Element wie 'de' besteht, eigentlich gar nicht gerendert werden sollte. Das Problem hierbei: Die Startseiten einer WebSite innerhalb von URI ermöglichen eine Adressierung des RealmNode ohne eine Sprache als einziges und damit erstes Element.

Es ist vorgesehen, die Adressen für die Sprachschalter konsequent auf die Standardseite des Servers zu verlinken weil ohne eine weitere Angabe des Root-Knoten unbekannt ist, zu welcher WebSite die Anfrage gehört.

Die derzeit beste Variante bestände darin, dass der Server beim ersten URI-Segment klar zwischen Sprachschalter und URI-Key für einen RealmNode differenzieren kann. Das ist aber bislang nur bei einem Prefix mit '@' möglich.

Status

Concept

Wir diskutieren das noch.

T154 Box+ImageObject Highlight

Problemstellung

Um die im kleinen Format dargestellten Bilder auch in größerem Format darstellen zu können, suchen wir eine Funktionalität, mit der man auf das Bild klicken und das dann in einer zweiten Layer größer sehen kann, ohne dass man dazu die Bilddatei direkt aufruft.

Work-Around

Bislang wird über einen Icon auf die Bilddatei verlinkt, allerdings mit target="_blank". Damit ist sichergestellt, dass sich die Originalseite nicht schließt.

Planung

Es ist vorgesehen, die Lösung mit CSS zu realisieren. Eine JS Version wäre eine Alternativ

Status

In-Progress

Wird mit hoher Wahrscheinlichkeit noch in Version 1.5.2.* kommen.

Priority

Important

T155 Verfügbarkeit

Problemstellung

Es ist eine Synchronisierung der Verfügbarkeit von Mitarbeitern mit den Buchungsoptionen für Serviceleistungen zu prüfen.

Status: Prototyp in Planung

T156 Globaler Graph

Problemstellung

Es wurde testweise ein LinkedData Graph für eine WebSite über den SuperHeader plaziert. Das Verfahren ist ein Provisorium.

Auch für dieses Provisorium aber benötigen wir einen Ansatz, um den Graph auch in die übrigen WebSites integrieren zu können.

Planung

Wir empfehlen, diesen Teil als ContentInstance und ContentReference mit CERaw Elementen zu realisieren, bis eine andere Lösung gefunden wird.

T157 Globaler Graph

Problemstellung

Es wurde testweise ein LinkedData Graph für eine WebSite über den SuperHeader plaziert. Das Verfahren ist ein Provisorium.

Auch für dieses Provisorium aber benötigen wir einen Ansatz, um den Graph auch in die übrigen WebSites integrieren zu können.

Planung

Wir empfehlen, diesen Teil als ContentInstance und ContentReference mit CERaw Elementen zu realisieren, bis eine andere Lösung gefunden wird.

T158 Datum und Zeit

Problemstellung

Es gibt weltweit diverse verschiedene Varianten wie man ein Datum, eine Zeiteingabe, eine Kombination aus Datum und Zeit sowie aber auch Zeitangaben wie eine Zeitdauer zwischen zwei Zeitpunkten formatieren kann.

Es ist für die weitere redaktionelle Erfassung von Datum (Date), Zeit (Time), Datum (DateTime) mit Zeit sowie Zeitdauer (Duration) zwingend erforderlich, dass entsprechende Werte redaktionell in einem korrekten Format erfasst werden.

Das Ziel besteht darin, alle Dokumente mit deren Zeitangaben validieren und diese Formate auch von einem Format in ein anderes Format umwandeln zu können. Die Voraussetzung hierfür besteht darin, dass ein Format in Dateien zweifelsfrei erkannt werden kann und auch korrekt ist.

Beispiel: ISO 8601 für ein Datum 2024-09-02. Dieses Format wird für Werte in LinkedData für Properties mit "@type":"Date" verwendet. Google aber akzeptiert das so zuweilen nicht.

Beispiel: 2024-09-02T09:00:00+02:00 gibt ein Datum mit Zeit und Zeitverschiebung von 2 Stunden gegenüber UTC. Dieses entspricht 9 Uhr in der Sommerzeit für die Zeitzone "Berlin".

02.09.2024 ist ein deutsches Datumsformat. Die Uhrzeit wird gewohnt ohne Sekunden 09:00 Uhr erfasst. Das Problem hierbei: Ohne einer Angabe der Zeitzone ist es nicht möglich, in einem internationalen Kontext den korrekten Zeitpunkt zu bestimmen.

Ansatz

(1) Das date-Element

Konsequente Auszeichnung von Datum, Datum und Zeit und Dauer in redaktionellen Inhalten über das entsprechende Markup. <date>31.12.1999</date> würde vom Prinzip her ermöglichen, einen Datum- oder Zeitwert als Text-Knoten zu erfassen.



<ce:Paragraph-01>
 Am <date>31.12.1999</date> haben wir die letzte
 Silvesterparty des 20. Jahrhunderts gefeiert.
</ce:Paragraph-01>

Dieser Ansatz mag in Zeiten der KI oder auch für redaktionelle Inhalte, deren Zielgruppe sich nur in einer Zeitzone befinden, übertrieben wirken. Für eine semantisch korrekte Erfassung ermöglicht dieses zumindest einem Skript, überhaupt in Texten Datumsangaben zu finden, um fehlende Angaben erkennen und/oder ergänzen zu können.

(2) date-Element mit Eigenschaften

Das Problem: Wer nun die Feier als LAN-Party mit Freunden aus USA, Europa und Japan hätte ausrichten wollen, hat ein Problem: Der Tag steht zwar fest, aber für den Beginn der Party und auch für das Ende der Party benötigen wir auch eine Zeitangabe für die Stunde und zudem die Zeitzone.

In den USA ist es üblich, bei Zeitangaben eine Zeitzone zu benennen und/oder diese basierend auf einer Stadt zu erkennen; so gilt für die Zeitangabe zumeist der Ort der Veranstaltung. Bei Online-Veranstaltung gibt es aber keinen Ort. Selbst die Angabe eines Landes reicht wie im Falle der USA nicht mehr aus.

Eine sehr transparente Variante bestände darin, einen Zeitwert zusätzlich als Attribut zu erfassen.



<ce:Paragraph-01>
 Am <date iso-8601="1999-12-31">31.12.1999</date> haben wir die letzte
 Silvesterparty des 20. Jahrhunderts gefeiert.
</ce:Paragraph-01>

Dieser Ansatz führt aber dazu, dass zwischen einer Text-Angabe und einem Wert einer ergänzenden Eigenschaften Abweichungen entstehen können. Diesen Fall gilt es grundsätzlich zu vermeiden. Jeder Wert sollte grundsätzlich nur 1x erfasst und auf dieser Grundlage automatisiert interpretiert und ggf. automatisiert in alternative Formate gewandelt werden können.

Es fehlt auch hier wiederum die Zeitzone, so dass dieser Tag auf der Welt zu 24 verschiedenen Uhrzeiten beginnt und endet.

(3) date-input-format

Die sauberste Lösung besteht wie bereits schon bei <text lang="de">Handy</text> darin, einerseits den Datentyp eines Wertes, der als Text-Literal (hier: Handy) angegeben wird, durch ergänzende Parameter genauer zu spezifizieren. Die Angabe von des lang Parameters dient bislang dazu, textliche Inhalte in Fällen, wo man möglicherweise auch fremdsprachliche Varianten nutzen möchte, klar auszuzeichnen.

Dieses Prinzip funktioniert bei einem <date/> Wert vom Prinzip her auch: Die nachfolgende Variante zeigt, wie man bei der Erfassung von Datum, Datum mit Zeit und einer Zeitdauer klar das zugehörige Eingabeformat und auch den Wert angeben kann, ohne dass man redaktionell die Ausgabe des Datums im Text schreiben.



<ce:Paragraph-01>
 <ce:Date format="iso-8601" value="1999-12-31"/>
 <ce:DateTime format="iso-8601" value="1999-12-21T22:00:00+02:00"/>
 <ce:Duration format="iso-8601" value="P4H"/>
</ce:Paragraph-01>

Dieses Verfahren ist redaktionell für Ungeübte etwas schwierig, ist allerdings technisch und semantisch betrachtet ein sehr guter Ansatz:

Werden die redaktionellen Inhalte nun automatisiert verarbeitet und/oder hierbei auch eine Ansicht der Informationen z. B. als Webseite angezeigt, müssen die Templates nichts anderse machen, als basierend auf dem Date-, DateTime- oder Duration-Wert, für die Ausgabe in deutscher Sprache dann die korrekte Darstellung wählen.

(4) Norm vor Konfiguration

Im Falle von LinkedData ist es so, dass man sich die Diskussion über das Format dadurch erspart, dass das Schema eindeutig ISO-8601 als Standard ebenso vorgibt wie man auch für die Textkodierung zwingend UTF-8 voraussetzt.

Nationale Eigenheiten seien also jedem Land und jedem Redakteur für eine Umrechnung in einer Ansicht später gegönnt, aber wenn es um redaktionelle Erfassung von Informationen und damit auch Datum, Datum und Zeit und Zeitdauer geht, funktioniert eine automatisierte Erfassung und Verarbeitung nur dann, wenn die Eingangsdaten in einem strikten Format erfasst wurden, wo es keinen Millimeter an Spielraum für eine Fehlinterpretation gibt.

Es gibt nun zwei Varianten, wie man den Code-Umfang verkürzen kann: Eine Normung oder Standartisierung bedeutet, dass man für die Attribute und Parameter, die man nicht mit angibt, in der Dokumentstruktur über die Konfiguration Default-Werte vorgibt.

Norm und Standard würde bedeuten, dass man diese Konfiguration sich ebenso ersparen kann, wenn man ISO-8601 als Standard definiert. Man muss also nur dann diese Default-Werte in der Konfiguration verändern, wenn es einer Gruppe von Redakteuren nicht zuzumuten wäre, Angaben zu Datum, Zeit, Datum und Zeit oder einer Dauer im ISO-8601 Format anzugeben.



<ce:WebPage>
 <ce:config>
  <ce:Default-Date-format="iso-8601"/>
  <ce:Default-DateTime-format="iso-8601"/>
  <ce:Default-Duration-format="iso-8601"/>
 </ce:config>
 <ce:contents>
  <ce:Paragraph-01>
   <ce:Date value="1999-12-31"/>
   <ce:DateTime value="1999-12-21T22:00:00+02:00"/>
   <ce:Duration value="P4H"/>
  </ce:Paragraph-01>
 </ce:contents>
</ce:WebPage>

Status

Die aktuelle Vorabentscheidung gibt für Zeitangaben das ISO-8601-Format vor. Eine erste Version der Elemente wurde ab Version UIO 1.5.2.38 eingeführt.

T159 ImprintCopyrightMadeByBlock

Problemstellung

Das Element für die Pflege der Fußzeile hat mit *ImprintCopyrightMadeByBlock noch einen etwas fragwürdigen Tag-Name. Darüber hinaus ist es zweckmäßig, dieses Element konsequent über ContentInstance und ContentReference Elemente zu realisieren, damit Ergänzungen wie z. B. Social Media Links für alle Branches und WebSites des Clusters dargestellt werden.

Workaround

Bis zu einer Neufassung des Elements wird empfohlen, dass die Dokumentation für die Redaktion des Elements und der Ansatz über die Content-Referenzierungen erläutert und den Redakteuren nachgelegt wird, damit Fußzeilen, die identisch sein sollen, über Referenzen und nicht mehr über Kopien abgebildet werden.

T160 dateChanged für WebPages

Problemstellung

Für die korrekte semantische Auszeichnung von ce:WebPage Instanzen ist es erforderlich, dass dataChanged wie auch dateCreated und dergleichen erfasst werden.

Diese Infos werden benötigt, LinkedData Informationen für die Synchronisation von Informationen zwischen verschiedenen Seiten optimieren zu können.

Diese Infos werden darüber hinaus für die SiteMap benötigt.

Workaround

Ein WorkAround kann darin bestehen, diese Daten in im GlobalLinkedData Element zu erfassen.

Wenn das allerdings getan wird, so ist es zwingend erforderlich, dass diese Daten auch dort dann konsequent bei Änderungen aktualisiert werden.

T161 Google SiteMap

Problemstellung

Für Google ist es sinnvoll, eine Google Sitemap bereitzustellen. Eine solche SiteMap besteht bislang noch nicht.

Workaround

Ein Workaround kann darin bestehen, dass diese SiteMap von Hand gepflegt wird.

Die Voraussetzung hierfür ist allerdings, dass dieses SiteMap.xml Files zumeist über das Wurzelverzeichnis der Domain erfasst werden, also example.com/sitemap.xml. Das ist technisch aber nur bedingt oder gar nicht möglich, weil die mit UIO betriebenen Server mehrere Domains abdecken

Es hat sich gezeigt, dass bei einer Erfassung einer Webseite über den URI wie 'https://example.com/alpha' und 'https://example.com/beta' die Google Search Console auf einmal anbietet, dass die zugehörige Sitemap auch in 'https://example.com/alpha/sitemap.xml' und 'https://example.com/beta/sitemap.xml' liegen kann bzw. liegen muss.

Status: Concept

Die Google Sitemaps werden kommen, und es steht auch zu erwarten, dass diese Sitemaps über UIO automatisch erzeugt werden.

Es geht also später nur noch darum, welche Seiten in der SiteMap erfasst und welche nicht erfasst werden.

Da UIO allerdings auch 100 Domains je Installation verwalten und auf den selben Webroot auf dem Server routen kann, besteht technisch betrachtet die Problemstellung, dass jede Webseite bezogen auf den URI Pfad einen eigenen RootNode bekommt und ggf. auch eine eigene RealmNode Adresse hat.

Die technische und organisationen Konzeption ist noch in Planung.

T162 robots.txt (Bug, teilweise gelöst)

Problemstellung

Der UIO Server liefert offenbar die robots.txt Datei NICHT aus und spendiert stattdessen den HTML Content einer 404 Seite.

Status: Bug

Gängiges Problem: Die robots.txt Datei liegt direkt im Webroot URI, also example.com/robots.txt. Die Konfiguration von Routen sollte für diese Files eigentlich nicht über die Realms sondern über die Serversettings erfolgen.

Das Problem ist teilweise gelöst.

Offen bleibt die Problemstellung, dass bei verschiedenen Domains mit einem Routing auf Realms jeder Realm seine eigene robots.txt Datei benötigt.

Eine robots.txt Datei wird von Crawlern / Suchmaschinen immer über Domainname gefolgt von/robots.txt adressiert. Eine Adressierung über example.com/was/auch/immer/robots.txt gibt es also nicht.

Eine robot.txt Datei muss also in Abhängigkeit wie auch die zugehörige sitemap.xml Datei immer aus dem jeweiligen Realm geladen und anschließend über den HTTP Server als /robots.txt ausgeliefert.

T163 Home-Link

Problemstellung

Es hat sich gezeigt, dass man an sehr vielen Stellen einen Link auf die Startseite im Sinne von "Home" benötigt, darunter nicht nur auf Seiten, die Redakteure selbst pflegen sondern auch Seiten die zur Infrastruktur wie 'search' oder 'membership' gehören.

Es ist dringend zu empfehlen, dass für jeden WebSite-Cluster so eine Home-URL wie z.B. de/{realmID}/home oder ähnliches definiert wird, dass der UIO Server im Zweifelsfall diese Adressen definieren/verwenden kann, auch wenn Redakteure vergessen, Standardwerte von Templates oder Beispiele zu ändern.

Es sollte in diesem Zusammenhang ein ce:InlineHomeLink oder ce:InlineLinkHome oder ähnliches Element geschaffen werden, weil wir damit auch die Gestaltung ggf. anpassen können.

T164 HeaderNavigationCluster

Problemstellung

ce:HeaderNavigationCluster: Wenn der referenzierte File NICHT besteht und/oder nicht gelesen werden kann führt dieses zu einer Warnung in der Ausgabe auf der Webseite.

Diese ist zu unterdrücken!

/ce:WebSite/ce:hasPart/ce:HeaderNavigationCluster



  <ce:HeaderNavigationCluster>
   <ce:config>
    <ce:filePath>
     <text>HeaderNavigationCluster_RealmNode_V3.xml</text>
    </ce:filePath>
   </ce:config>
  </ce:HeaderNavigationCluster>

Workaround 1/2

HeaderNavigationCluster und HeaderNavigationSwitcher werden im Regelfall nur einmal zu Beginn je WebSite Elemente im Cluster erzeugt. Man kann schlichtweg einen Standard-File für -Cluster und -Switcher definieren und muss nur darauf achten, in den eigentlichen Menüs die Referenzen auf die Menüs auszukommentieren.

Mit diesem Ansatz haben zwar die Menüs für HeaderNavigationCluster und HeaderNavigationSwitcher falsche Inhalte; da die Menüs aber gar nicht gerendert werden spielt das keine Rolle.

Diese Menüs müssen erst dann reale Links enthalten wenn diese angezeigt werden sollen. Das gilt oftmals nur für größere Webseiten im Cluster mit anderen Webseiten oder vielen Branches.

Workaround 2/2

Die Ausgabe von Fehlern in Produktivsystemen ist unterdrückt.

Status

T165 GSearchCon LDJSON id

Problemstellung

Die Google Search Console scheint @id Werte in LD+JSON fehlerhaft als optionale URL für WebPage(s) zu interpretieren.

https://snewmedia.com/de/@snm/support/ wurde als url-Eigenschaft definier und von Google auch korrekt für die Indizierung verwendet.

https://snewmedia.com/WebPage/WebPage/de/@snm/support/ wurde von Google fehlerhaft als alterantive URL erfasst und abgelehnt, weil es ja schon obige Adresse als kanonische Adresse gibt.

'WebPage/de/@snm/support' wurde als @id definiert,

Vorschlag: Veränderung von @id zu Strings die nicht mehr mit WebPage-url-Werten verwechselt werden können und weiterhin aber eine ähnliche Struktur haben. Zusätzlich ist eine Domain und/oder die Bezeichnung des Realm zu ergänzen.



{
 "@context": "https://schema.org",
 "@type": "WebPage",
 "@id": "snewmedia.com:de:@snm:support",
 "url": "https://snewmedia.com/de/@snm/support/",
 "isPartOf": {
  "@type": "WebPage",
  "url": "https://snewmedia.com/",
  "@id": "snewmedia.com:home"
 }
}

Diskussion

Eine Zuweisung einer @id wie "snewmedia.com:home" mag zwar sinnvoll sein, lässt sich aber nicht ohne weiteres mit 'home' automatisieren weil es auch eine Seite mit einem URI-Pfad-Segment 'home' geben könnte welches dann die selbe @id hätte.

Der Sinn und Zweck von 'WebPage' als @id Bestandteil hat damit zu tun, dass hiermit der Stereotyp für die Daten angegeben wird.



{
 "@context": "https://schema.org",
 "@type": "WebPage",
 "@id": "WebPage:snewmedia.com:de:@snm:support",
 "url": "https://snewmedia.com/de/@snm/support/",
 "isPartOf": {
  "@type": "WebPage",
  "url": "https://snewmedia.com/",
  "@id": "WebPage:snewmedia.com"
 }
}

Diese Variante ergänzt den Datentyp und entfernt eine 'home' Bezeichnung.

Wichtig: Die IDs müssen automatisiert ermittelt werden können auf Grundlage des tatsächlichen URI.

T166 GSearchCon 5xx Fehler

Problemstellung

Die Google Search Console erfasst URIs welche anschließend über HTTP 301 oder 302 auf die eigentliche neue URL weitergeleitet werden mit einem 5xx Fehler.

Die Bezeichnung durch Google ist FALSCH. Es handelt sich tatsächlich um korrekte URLs welche mitunter auch über CURL unter Windows, Linux etc. geprüft werden können.

Workaround

Der Workaround in UIO 1.5.2.43 sah so aus, dass man schlichtweg einen weiteren REALM einrichtet und für diesen eine weitere RoutingDefinition erstellt.

Anzugeben sind in "uri" das Muster für die Erkennung von Requests sowie "forward-uri" und "forward-httpheader" mit den passenden Type.

Die Angabe einer canonical-Adresse spielt KEINE Rolle weil diese Adresse erst über den HTML Code der WebPage der neuen URL geliefert wird. Die kanonische URL dient nur noch einer leichteren Auffindbarkeit dieser Definition in der Konfiguration.



<!--
<forward-http>HTTP/1.1 302 Found</forward-http>
<forward-http>HTTP/1.1 307 Temporary Redirect</forward-http>
<forward-http>HTTP/1.1 301 Moved Permanently</forward-http>
-->

<route>
 <canonical>de/@snm/learn/course/c-plus-plus</canonical>
 <uri>^app\/data\/schulungen\/cpp(?:$|\/$)</uri>
 <forward-uri>de/@snm/learn/course/c-plus-plus</forward-uri>
 <forward-httpheader type="301"></forward-httpheader>
</route>

Wenn eine Seite mit "302" definiert wird, erkennt die Google Search Console diese URLs/URIs als "Seite mit Weiterleitung".

Status: Beobachten

Wichtig ist hierbei nur, dass Google diese alten URLs, welche hier weitergeleitet werden, überhaupt erkannt hat und später korrekt weiterleitet.

Sollten sich vormalige URI und URL ändern und es eine neue Adresse geben, ist es möglich, diese auf die neue Adresse weiterzuleiten.

T167 GSearchCon Duplikat/nicht indiziert

Problemstellung

Die Google Search Console liefert einen "vorrübergehenden Verarbeitungsfehler" in Fällen, in welchen von einer Drittseite ein Link mit einem URI eingerichtet wurde den es aber so nicht gibt.

Da jedes Requests spätestens durch eine 404-Seite beantwortet wird, führt das dazu, dass Google die fehlerhafte Adressierung als Warnung auflistet und darüber informiert, dass diese Seite nicht erfasst und nicht indiziert werden wird.

Beispiele

Beispiel: Eine vormalige Webseite adressiert 'https://snewmedia.com/de/folgen/facebook' als URL mit einem URI den es aber auf der Zielseite gar nicht gibt.

So ermöglicht beispielsweise eine Webseite über HTTP GET Parameter dass ein Zugriff auf die Webseite example.com plötzlich zu einem Aufruf auf einer anderen Seite führt. Dieses war vom Seitenbetreiber eigentlich für eigene interne Links ermöglicht worden, führte aber dazu, dass man die Webseite auch so aufrufen kann, um auf Drittseiten zu springen.



http://www.example.com/index.php?id=9&type=0&jumpurl=http://www.snewmedia.com&juHash=e075caade0195336bef3ebb3899c1b6759ade455

Google ermöglicht es, veraltete Inhalte zu aktualisieren. Hierzu kann man Google auffordern, bestimmte URLs aus dem Index entfernen zu lassen. Genau genommen bietet Google an, eine URL für 6 Monate zu sperren.

https://support.google.com/webmasters/answer/7041154?hl=de

https://snewmedia.com/de/kontakt

https://snewmedia.com/de/datenschutz/overview

https://snewmedia.com/de/impressum

https://snewmedia.com/?request=

https://snewmedia.com/de/datenschutz/overview

Empfehlung

Eintragung dieser URLs für eine HTTP 301 Forwarding. Damit wird Google mitgeteilt, dass es diese URL zukünftig an einer neuen Adresse gibt.

Alternativ: Anlegen einer zusätzliche Seite mit dieser URL, um dort die Information anzubieten, die gesucht wird. Dieses kann aber zu Double Content Problematiken führen.

T168 GSearchCon Gecrawled - Nicht indiziert

Problemstellung

Manche Adressen werden von Google beim Crawling der Webseite erfasst, dann aber doch nicht im Index aufgenommen.



https://example.com//de/willkommen
https://example.com//
https://example.com//home
https://example.com/de
https://example.com/de/kontakt/ansprechpartner

Diskussion

https://example.com//de/willkommen entsteht als fehlerhafte URL in Fällen, in welchen der Redakteur bei der Eingabe eines Links den URI mit einem / Slash beginnend erstellt. Ab UIO 1.5.2.43 werden relative Links grundsätzlich NICHT mehr mit einem / begonnen. Seit UIO 1.5.2.43 endet die absolute Adresse mit einem / Slash.

https://example.com// entsteht als URL ebenso wie im vorangestellten Beispiel.

https://example.com/de/kontakt/ansprechpartner entsteht als Folge einer fehlerhaften URI-Angabe.

T169 GSearchCon /de Seiten

Problemstellung

Die URI-Struktur beginnend mit dem de Language-URI-Pfad-Segment führt bei der automatischen Erzeugung von BreadcrumbList Elementen dazu, dass auch dieser erste Knoten, UIO ist er als 'ContextNode' benannt, ebenso zu einem URI und einer URL für eine Seite führt die es aber so nicht gibt.

'https://example.com/' ist die Adresse einer Webseite ohne Sprachauswahl.

'https://example.com/@example' ist die Adresse einer Webseite ohne Sprachauswahl welche den RealmNode angibt.

'https://example.com/de/@example' ist die Adresse einer Webseite mit Sprachauswahl und Angabe eines zweiten URI-Pfad-Segments wie hier '@example' welches hier einen UIO RootNode adressiert welcher benannt ist nach dem zugehörigen Realm.

Erläuterung

Erst der zweite Parameter gibt an, welches UIO WebSite Element hier eigentlich mit einem RootNode gerendert werden soll, denn es ist möglich, den gleichen URI über zwei oder auch mehr verschiedene Domains zu adressieren. Der erste Parameter ist also entweder die Sprachoption, wenn es mindestens zwei URI-Segmente gibt, und es ist die Bezeichnung des RealmNode wenn es nur ein URI-Segment gibt.

Eine 'https://example.com/@example.com' Adresse gibt also korrekt einen URI und die URL für einen RealmNode für 'example.com' an und ermöglich es, dass man den selben URI auch über 'https://snewmedia.com/@example.com' hätte adressieren können. Erst das UIO System prüft also basierend auf dem ContextNode, welche WebPage zu rendern ist.

Eine 'https://example.com/de' wird also sinngemäß als RealmNode adressiert und müsste eigentlich nun einen RealmNode als WebPage auflisten.

Lösungsansatz

Alle Sprachschalter wie 'de' und 'en' mit nur einem einzigen URI-Segment sollten konsequent auf diejenige URL weitergeleitet werden, welche der zugehörigen Sprachversion zu die Defaultseite entspricht.

Wenn 'https://example.com/' dem URI '' entspricht so wird diese Adresse über die Serverkonfiguration auf einen Realm umgelenkt; das kann ein example.com Realm sein. Wenn daraus die Hauptseite 'https://example.com/@example' als URL ohne Sprachauswahl wird ist es sinnvoll, eine 'de' Adresse auf 'https://example.com/de/@example' zu routen.

T170 GSearchCon Duplikat und Ignorieren der kanonischen Seite

Problemstellung

"Duplikat – Google hat eine andere Seite als der Nutzer als kanonische Seite bestimmt"

Dieser Fall kann mitunter dann entstehen wenn die redaktionellen Inhalte von zwei verschiedenen WebPage-Dokumenten für Google identisch wirken.

Beispiele

https://snewmedia.com/@snm: Dieses Adresse entspricht der Adressierung des 'snewmedia.com' Realm über einen Kurznotation mit '@snm'. Diese Seite entspricht in einem UIO System der Startseite für ein Realm und damit ein Dokument welches unabhängig von den eigentlichen WebSite-Deklarationen ist. Ein RealmNode ist ein Container für WebSite- und WebPage-Elemente, man kann das Realm auch als Datenmodell oder Datenbank verstehen welche unter der Kontrolle eines Inhabers des Realms ist.

https://snewmedia.com/de/@snm/studio: Diese URL entspricht der Adressierung eines UIO BranchNode, dh. in diesem Fall ist es die primäre WebSite innerhalb des '@snm' Realms. Ein Unternehmen kann mehrere WebSites mit ein und der selben UIO3 Installation betreiben, dh. so kann es auch 'de/@snm/dev' oder eben 'de/@snm/create' geben.

Google entscheidet hier eigenständig für 'https://snewmedia.com/' als kanonische URL. Das mag an dem Punkt sinnvoll sein, wo eigentlich 'https://snewmedia.com/de/@snm/studio' bislang die Startseite von SNEWMEDIA ist. Genau genommen ist aber diese Entscheidung von Google falsch: Der 'de/@snm/studio' Link ist vom Prinzip her die Startseite eines Portals oder einer Abteilung, in UIO3 als 'BranchNode' bezeichnet.

Dadurch, dass die '@snm' Adressierung des RealmNode noch keine Sprache angibt ist es normal, dass die Seite als eigentlichen Inhalt nur die Links auf die eigentliche Startseite wie 'https://snewmedia.com/de/@snm' für eine deutsche und ggf. 'https://snewmedia.com/en/@snm' für eine englische Version bereitstellt. Damit würde also eine eigentliche Startseite angegeben welche ein RootNode aber noch kein BranchNode ist.

Vielfach wird aber aus '@snm' direkt auf den primären Branch wie 'portal' oder bei SNM auf 'studio' verlinkt.

https://snewmedia.com/de/@snm: Das ist die offizielle Startseite von SNEWMEDIA in der deutschen Version. Google wählt eigenständig 'https://snewmedia.com/' als URL. Das ist in diesem Fall auch in Ordnung. Im Falle von '@cty' 'https://snewmedia.com/@cty' wäre dieser Ansatz aber falsch.

Lösungsansatz

Vorab: Das ist kein technisches Problem sondern eine Problem welches aus einer Kombination aus Redaktion und Konfiguration von URLs sowie Weiterleitungen sowie Angabe von Links entstanden ist.

Es wird dringend empfohlen, die verschiedenen Startseiten klar differenziert nach dem selben URI-Schema auszuzeichnen und dann bei der Angabe von Links diese auch konsequent korrekt zu verwenden.

Darüber hinaus ist es aber auch bedeutsam, dass diese Seiten konsequent eigenständige unabhängige redaktionelle Inhalte nicht nur für Menschen sondern auch für Suchmaschinen bieten, darunter verschiedene Meta-Description-Angaben.

Status: Beobachten

Das Problem kann mitunter damit zu tun haben, dass die isPartOf und hasPart Deklarationen für 'de/@snm/studio' wiederum auf 'de/@snm/studio' verweisen. Die Ursache besteht darin, dass isPartOf eigentlich auf WebSite und nicht WebPage Elemente verweisen soll.

T171 isPartof verweist auf selbe Seite

Problemstellung

Für alle Startseiten einer WebSite besteht in Version 1.5.2.49 das Problem darin, dass die automatisierte Erzeugung von JSON+LD Code dazu führt, dass diese WebPage (oftmals ist es ein BranchNode) für isPartOf auf sich selbst verweist.

Die Ursache besteht darin, dass aus der WebPage immer die zugehörige WebSite referenziert wird und das UIO3 System hierbei dann hierfür den passenden URI ermittelt. Dieser ist für eine WebSite genau diese WebPage.

Der untenstehende Code zeigt, dass sowohl '' mit 'https://snewmedia.com/' und '@snm' als auch 'de/@snm/studio' über 'isPartOf' auf die selbe WebPage mit der ID 'WebPage/de/@snm/studio' verweisen.

Google gewinnt also den Eindruck, dass beide URLs zu einer WebPage gehören welche Teil der gleichen WebPage sind. Da es zwei verschiedene URLs sind welche beide als kanonische URL ausgewiesen wurden, trifft Google eine Entscheidung und wählt die kürzere Variante.



{
 "@context": "https://schema.org",
 "@type": "WebPage",
 "@id":"WebPage/de/@snm/studio",
 "url":"https://snewmedia.com/de/@snm/studio",
 "isPartOf":{
   "@type":"WebPage",
   "url":"https://snewmedia.com/de/@snm/studio",
   "@id":"WebPage/de/@snm/studio"
  }
 }

{
 "@context": "https://schema.org",
 "@type": "WebPage",
 "@id":"WebPage/@snm",
 "url":"https://snewmedia.com/@snm",
 "isPartOf":{
  "@type":"WebPage",
  "url":"https://snewmedia.com/de/@snm/studio",
  "@id":"WebPage/de/@snm/studio"}
}

{
 "@context": "https://schema.org",
 "@type": "WebPage",
 "@id":"WebPage/",
 "url":"https://snewmedia.com/",
 "isPartOf":{
  "@type":"WebPage",
  "url":"https://snewmedia.com/de/@snm/studio",
  "@id":"WebPage/de/@snm/studio"
 }
}

Lösungsansatz

Für jedes WebSite-Dokument sollte konsequent eine eigene '@id' Eigenschaft mit dem Prefix 'WebSite' definiert werden, so dass daraus in diesem Falle 'WebSite/de/@snm/studio' werden würde.

Damit wird also dann klargestellt, dass alle 3 URLs und URIs zu WebPages gehören welche als 3 WebPages ein Teil der gleichen WebSite sind, aber eine WebSite ist immer nur ein Gruppierungselement.

Diese WebSite wiederum, die in UIO3 ja auch tatsächlich als WebSite-Dokument besteht, kann dann auf eine WebPage als Startseite verweisen. Und genau an der Stelle muss sich der Redakteur dann entscheiden, welches die für diese WebSite dann maßgebende Startseite mit welcher URL ist.

Hinweis: Die Definition von '@id' Eigenschaftswerten mit einer URL-artigen Schreibweise ist bereits als Problemstellung (T166) erfasst worden.

Status: In Planung

Geplant wird die Erfassung von WebSite-Dokumenten zusätzlich zu WebPage-Elementen.

Die Voraussetzung besteht allerdings darin, dass die '@id' Werte für alle Daten auf einen neuen Standard geändert werden, damit Google diese ID-Strings nicht mehr als URL fehlinterpretiert.

Workaround

Ein Workaround kann darin bestehen, für die Startseite, wo der Nutzer sich noch nicht für einen Branch wie 'de/@snm/studio' entschieden hat, eine eigenständige 'WebSite' mit auch einem eigenen Menü zu definieren.

Ansatz: Anlegen einer WebSite für die Startseite als Container für '', '@snm', 'de', 'de/@snm' und den zugehörigen alternativen Sprachversionen.

HeaderNavigationModule_RealmNode_@_V24A

WebSite__@snm__@_V24A

T172 LinkedData Realms URI

Problemstellung

Bei der Erzeugung von URLs für RealmNodes, welche direkt über einen Context-Key adressiert werden, fehlt bei lokaler Adressierung ein Slash zwischen Domain und Context-Segment.

Fehlerhafter URL



<meta
 name="data-uio-fn-geturl-actualpage"
 content="http://localhost@snm">

T173 SETTINGS_CANONICAL_DOMAIN umbenennen

Problemstellung

Die 'SETTINGS_CANONICAL_DOMAIN' Umgebungsvariable hat eine falsche Bezeichnung. Es handelt sich bei diesem Wert in der serverseitigen Programmiersprache (PHP, JAVA, XSL etc.) um den 'context_root_URI' Wert welcher die URI-Segment-Pfad-Bestandteile angibt mit denen angegeben wird, wo die Wurzel für die Adressierung der Startseite der dortigen UIO Installation besteht.

Lösungsansatz

Umbenennen in allen .htaccess Files.

Umbenennen in allen Files der Serverseite wo die Variable beispielsweise in PHP über ENV geladen wird.

Status: Geplant

Die Umbenennung wird mit Version UIO 1.5.3.x kommen.

T174 WebRessources und URL Templates

Problemstellung

In UIO 1.5.2.53 übliche Erfassung von WebPage Elementen als File in Verbindung mit einer ergänzenden Erfassung mit einem URL-Template-artigem Muster in der RoutingDefinition sowie der späteren Verlinkung aus verschiedenen Menüs funktioniert.

Die Erfassung von URI-Segmenten als Realm-, Root-, Branch-, Section-, Article- und Topic-Node ist klar und eindeutig. Das Verfahren hat Ähnlichkeitkeit mit Java EE bzw. Jakarta EE Techniken in Hinblick auf URI-Segmente für den jeweiligen Knoten welcher über die Reihenfolge der Definition von Routen die übrigen Bestandteile der gesamten URI-Sequenz ermittelt.

Organisatorisch betrachtet besteht bei all der Flexibilität allerdings ein Problem: Eine WebPage kennt bislang stets nur die übergeordnete WebSite. Die WebSite selbst aber kennt nicht die zugehörigen WebPages. Ursache: WebPage Elementen referenzieren das WebSite Element primär für das Erben von Styles und des Menüs.

Ein zweites Problem besteht darin, dass die WebPage selbst Ihre eigene Adresse, unter der Sie aufgerufen wird, nicht kennt, weil die WebPage selbst nur ein Informationsknoten und Dokument ist welches basierend auf der Verarbeitung eines HTTP Requests über ein Matching mit einer Route zwar dann geladen wird, letztendlich aber über viele solche Routen und URI-Muster gefunden und geladen werden kann.

Lösungsansatz

Einführung von Web-Ressourcen in Anlehnung an Jakarta EE: Eine WebRessource ist im Kern ein digitaler Service welchen man über eine URL bzw. eine URI-Sequenz relative zu einem aktuellen WebRoot adressieren kann. Dieser WebService möge anschließend eine Antwort generieren.

Die Besonderheit dieser WebRessource-Knoten besteht darin, dass hierbei nicht nur die URI-Sequenz wie beispielsweise de/a/b/c eine Bedeutung hat sondern auch die HTTP Methode wie GET, POST, OPTIONS, PUT, HEAD. Hinzukommt aber noch, dass ein URI nicht nur über Strings wie de/a/b/c definiert wird sondern zumeist relative zu einem übergeordneten Service, so dass 'c' als URI-Segment ausreichend ist wenn die Verarbeitung sicherstellt, dass 'c' erkennt, dass es in /a/b/ eingehängt wird und es sich bei der Sprache um 'de' handelt.

Darüber hinaus werden URI-Segmente in Anlehnung an URL-Templates für Variablen vorbereitet. Lautet eine Adresse de/stadt/frankfurt so ist es möglich, dass der selbe Service sowohl de/stadt/frankfurt als auch de/stadt/wiesbaden verarbeiten kann, wenn denn die URI-Definition beispielsweise über de/stadt/{$location} klarstellt, dass das letzte Segment der URI als String-Wert einer Variablen '$location' zugeordnet wird.

Es ist dahingehend technisch möglich, dass nicht nur WebPage-Knoten definiert werden sondern genau genommen WebRessourcen welche WebPage-Dokumente rendern. Die bisher manuell geführten RouteDefinition-Einträge entsprechen also genau genommen der Erfassung eine zwingend geordneten Reihenfolge URI-Mustern welche zu vollständigen REST-artigen WebRessource-Service-Adressen erweitert werden können.

Vorschlag

Der Vorschlag besteht nun darin, dass diese Routen nicht mehr ähnlich manuell gepflegt werden sondern dass eine jede WebRessource für sich betrachtet deklariert und dann automatisch erfasst wird, damit diese Routen automatisch berechnet werden und es möglich wird, für jede WebRessource die zugehörige URI-Segment berechnen zu können.

Technisch betrachtet ist es denkbar, dass jede WebPage eine Eigenschaft bekommt über welche dieser entweder eine vollständige URL, eine relative URL bezogen auf den Webroot und/oder auch auch nur ein relatives URI-Segment bezogen auf eine übergeordnete Parent-URI-Sequenz bestimmt wird.

Ähnliche URI-Templates

Problemstellung: Da nun eine de/stadt/{$location} für location beliebige Strings ermöglicht, kollidiert diese Adresse mit einer URI-Template für einen Service welche über einen URI wie de/stadt/liste nur eine Liste liefern sollte. Bei der Registrierung von Webservices und deren URI-Templates muss es also auffallen, dass 'liste' und '{$location}' beide das dritte Segment sind und beide einen String-Wert darstellen. Bei der Registrierung muss also eine Fehlermeldung ausgegeben werden bzw. der zuletzt erfasste Eintrag oder auch beide müssen verhindert werden.

Ein de/stadt/{$location} Muster gilt sinngemäß als 'de/stadt/*' Muster und würde für 'de/stadt/liste' bei einer Überprüfung eines URI mit allen anderen schon erfasstenen URIs einen Treffer erzeugen.

Diskussion

Eine Lösung ist mittelfristig zwingend erforderlich. Es muss möglich sein, aus dem Code heraus die Inhalte eines anderen WebPage-Dokuments lesen oder auch nach Informationen in anderen Dokumenten suchen oder recherchieren zu können.

Ein Crawling kann hierbei über alle erfassten URI-Templates erfolgen, so dass ein interner Crawler für alle Routen welche definiert wurden testweise die zugehörigen Dokumente aufruft und rendern lässt, um auf diese Art und Weise zu erfahren, welche Informationen eigentlich veröffentlicht werden. Dieses Verfahren entspricht dem typischen Google-Crawler-Verfahren: Man veröffentlicht eine Sitemap mit allen URL; und der Crawler einer Suchmaschine ruft alle Seiten auf und erfasst, was dort steht.

Führt nun jemand eine Suche nach Informationen aus werden diese Informationen nicht im CMS in allen Dokumenten durchgeführt sondern in einem Index welcher auf den Daten basiert, welche der Crawler gefunden hat.

Dieses Verfahren ist vergleichsweise leicht zu implementieren weil man im Grunde genommen nur alle erfassten URI-Templates testweise aufrufen muss.

Da einige URLs Formularwerte erwarten, die man nicht testen kann, und einige WebRessourcen auch Cookies oder Formularwerte zwingend erfordern, handelt es sich bei den URLs/URIs letztendlich um WebServices, WebRessourcen und/oder auch potentielle Aktionen (Actions) im Sinne des Schema.

Status: Konzept

Maßgebend zum Verständnis: Es gibt WebPage-Dokukumente welche statische Inhalte haben. Es gibt aber auch WebService-URIs welche ebenso eine Antwort erzeugen welche man im Browser anschauen kann, deren Informationen aber basierend auf Formularwerten, der Uhrzeit oder den bisherigen Interaktionen des Nutzers oder anderer Nutzer mit dem System basierend.

Es gibt dahingehend einen einzigen WebService, welcher im Grunde genommen URIs wie de/a/b/c auswerten und hierfür+ das passende WebPage-Dokument laden und rendern kann.

Es gibt aber darüber hinaus auch verschiedene andere WebService(s) welche basieren auf /api/a/b/c oder /api/a/b/c?d=1 oder /api/a/b/c?d=1&e=2 ein serverseitiges Skript ausführen welches das eigentliche WebPage-Dokument dann zur Laufzeit auf dem Server erst noch erzeugen.

Empfehlung

Es wird empfohlen, dass bisherige Verfahren einer manuellen Erfassung von URI-Mustern zu erhalten, dieses aber zu einer Registrierung von WebServices oder WebRessourcen zu erweitern.

Immer dann, wenn der Server ein HTTP Request bekommt und eine Ressource hierbei erkennt, wird eine Instanz dieser Ressource erzeugt welche die Anfrage bearbeitet.

Immer dann, wenn wir erfolgreich ein HTTP-Request mit einem URI über ein Match mit einer Route verarbeitet haben,

Die Erfassung einer URL bei einem WebPage-Dokument ist zwar naheliegend; genau genommen aber werden mit den URI-Mustern nicht das WebPage-Dokument erfasst sondern die WebRessource deren Service ein solches passendes WebPage-Dokument dann laden und rendern kann.

Die Problemstellung sollte in viele kleine Teile zerlegt werden bevor die Konzeption fortgesetzt wird.

T175 Zugriffsrechte an WebPages binden

Problemstellung

Um eine Suchfunktionalität mit Volltextsuche planen zu können ist es von großer Bedeutung, dass das System bei einer Suche erkennen kann, ob für bestimmte WebPage-Dokumente eine Zugriffsgeschränkung besteht. Nur unter dieser Voraussetzung könnte sichergestellt werden, dass im Suchergebnis nur die Suchergebnisse erscheinen, auf welche der Nutzer auch tatsächlich einen Zugriff hat.

Lösungsansatz

Als Workaround ist es denkbar, dass auch Inhalte von geschützten Seiten durchsucht werden und abschließend von der Suchfunktionalität eine Liste von URLs/URIs für Zielseiten ermittelt wird.

Es müsste aber vor einer Auflistung dieser Links im Suchergebnis für jeden Link geprüft werden, ob der aktueller Nutzer mit seinem aktuellen Anmeldestatus einen Zugriff hat.

Stand

Der bisherige Zugriffsschutz ist ein funktionierender Prototyp welcher verlässlich den Zugriff auf bestimmte Adressen für alle User sperrt und nur für bestimmte angemeldete User erlaubt.

Die zugehörigen Rechte sind bislang an den jeweiligen User gebunden, nicht an WebPage-Elemente und nicht an UserGroup(s). Für die Zuweisung von Benutzergruppenschlüsseln an User sowie eine Zuweisung erforderlicher Benutzergruppenschlüssel zu WebPage-Dokumenten gab es bereits einen Prototyp.

Status: Ideenfindung

Der derzeitige Zugriffsschutz wurde dahingehend geschaffen, um für einzelne Personen geschützte Seiten und deren Unterseiten definieren zu können.

T176 API/Suchfunktion

Problemstellung

Gesucht eine Suchfunktionalität welche basierend auf einer Suchanfrage aus einem Suchformular irgendwelche sinnvollen Ergebnisse liefern kann.

Lösungsansatz

Der derzeit favorisierte Ansatz besteht darin, diejenigen öffentlichen WebPages, für die ein Zugriff auch ohne vorherige Anmeldung am System möglich ist, im Zuge der Erzeugung einer Ansicht über die Templates ergänzend über weitere Templates inhaltlich auszuwerten, um hierbei neben der eigentlichen Ansicht von WebPage-Dokumenten im Browser zugleich auch eine Stichwortliste zu erstellen welche für jedes Stichwort oder Fließtext eines Absatzes ergänzend vermerkt, ob es sich um Überschriften oder andere Absatzformate und dergleichen handelt.

Empfehlung

Wir empfehlen die Programmierung einer ergänzenden Template welche die eine Suchfunktion dienenden Stichworte basierend auf redaktionellen Inhalten der aktuellen Seite bereits jetzt erfasst und provisorisch als Metadaten im HTML Code mit ausgibt, siehe T177.

Ergänzend sollte ein Cache für alle erzeugten bzw. gerenderte WebPage-Dokumente geschrieben werden, siehe T178.

Die serverseitige Suchfunktionalität wäre dahingehend auf dieser Grundlage in der Lage, den HTML Code im Cache zu laden und direkt über einen Selektor auf die zugehörigen Meta-Informationen zugreifen zu können, siehe T179.

Status: Konzeption

Die Umsetzung der Suchfunktionalität erfordert mehrere Zwischenschritte aus Voraussetzung.

T177 Konfiguration auf XML umstellen

Problemstellung

Die bisherige Konfiguration einer Installation erfolgt basierend auf PHP Konstanten. Das ist an dem Punkt auch gewollte, damit im Programmverlauf bestehende Einstellungen von administrativer Seite nicht durch Code verändert werden können.

Die Problematik hierbei besteht darin, dass sich die Konfiguration nicht alle übrigen in XML erfassten Informationen auslesen, überprüfen und um Vorschläge für Korrekturen ergänzen lassen.

Es wird dahingehend vorgeschlagen, die bisherige Konfiguration des Systems in einer zukünftigen Version konsequent auf XML umzustellen.

Lösungsansatz

Da es ich bei XML um Strings handelt, es es möglich, die Konfiguration als XML String schrittweise in Projekten einzufügen und auch hierfür eine neue PHP Konstante zu schaffen, um signalisieren zu können, dass ein Projekt nun das XML Format unterstützt.

Empfehlung

Es wird dringend empfohlen, vor einem Beginn der Einführung von XML den zugehörigen XML Namespace zu schaffen und sich über die Struktur der zu erfassenden Informationen auszutauschen, um Konfigurationen auch Modul-orientiert (darunter Email) konfigurieren zu können.

Es wird empfohlen, zuerst die Prototypen für die C# und JAVA basierten HTTP Server zu realisieren, um dortige Anforderungen vor einer Umplanung kennen zu können.

Status: Warten

T178 WebPage-Cache

Problemstellung

Damit die Suchfunktionalität auf Serverseite Daten findet, in welchen basierend auf einem Suchbegriff gesucht werden kann, ist es erforderlich, dass das System für bereits bei einem Zugriff durch Nutzer gerenderter WebPages eine Kopie in einen Cache schreibt.

Ob hierbei der vollständige HTML Code der Seite geschrieben wird oder aber nur ein Auszug und/oder eine XML-Variante, welche nur die Daten für die Suchfunktion zur Verfügung stellen soll, ist freigestellt.

Lösungsansatz

Es wird empfohlen, dass derjenige HTML5 Code, welcher an den Client/Browser bei einem Request geschickt wird, im Anschluss und/oder parallel in den WebPage-Cache geschrieben wird.

Es ist zwingend erforderlich, dass den Dokumenten im Cache zu entnehmen ist, über welche URL bzw. welchen URI diese adressiert wurden. Diese Information wird dafür benötigt, die Zugriffsrechte des aktuell später suchenden Nutzers auf diese Informationen prüfen zu können.

Empfehlung

Es wird grundsätzlich empfohlen, die im Cache abgelegten Dokumente in einem zweiten Prozess auszuwerten, um verwertbare Informationen in einen zentralen Gesamt-Cache zu schreiben, damit bei einer Suche nur 1 File geöffnet und durchsucht werden muss.

Status: Konzeption

T179 Zugriff der Such-API auf WebPage-Cache

Problemstellung

Unter der Voraussetzung, dass der WebPage-Cache (T178) realisiert wurde, ist die Such-API auf Serverseite dahingehend zu erweitern, dass diese auf die Daten im WebPage-Cache zugreifen kann.

Lösungsansatz

Da es sich bei den erzeugten WebPage-Cache-Daten um normale HTML5 Dokumente handelt, lassen sich die Daten als DOMDocument lesen und auswerten.

Empfehlung

Es wird grundsätzlich empfohlen, nur diejenigen WebPage-Daten im Cache auszuwerten, auf welche der aktuelle Nutzer auch tatsächlich einen Zugriff hätte.

Die Daten im Cache müssen also erkennen lassen, zu welchem URI und welcher URI diese Dokumente im Cache gehören.

Status: Warten

Die Planung erfordert die Fertigstellung des WebPage-Cache, siehe T178.

T180 offers fehlen

Problemstellung

Die Google Search Console beschwert sich wegen fehlender 'offers'.

Lösungsansatz

Ursache ist eine fehlende Synchronisierung von Offer-Instanzen mit der Verfügbarkeit.

Workaround

Die zugehörigen Offer-Einträge müssen in offers für die entsprechenden Objekte manuell in JSON+LD angelegt werden.

Hinweis: Die Schreibweise von IDs hat sich geändert.

T181 PageAnchor mit Link zum Menü

Problemstellung

Mit Hilfe des <ce:PageAnchor> Elements ist es möglich, in Analogie zum HTML <a> Element sogenannte Anchor-Elemente anzulegen. Der über das Attribut anchorID="sprungmarke" angegebene Text bewirkt, dass im HTML Code ein über die Adresse #anchorID-sprungmarke Element im HTML Code der Ansicht der Seite erzeugt wird.

Wenn man zusätzlich das Element mit addToPageAnchorLinks="1" konfiguriert so wird diese Sprungmarke mit einer zugehörigen Label, welche man derzeit als Textnode angibt, im zugehörigen PageAnchorList Menü angezeigt.

Beispiel

Der nachfolgende Code erzeugt einen PageAnchor und stellt sicher, dass im PageAnchorLinks Menü für den Link 1.5.2.24 InlineLink ~ erscheint.



<ce:PageAnchor
 addToPageAnchorLinks="1"
 anchorID="uio-1.5.2.24"
 label="Design DES"
>
1.5.2.24 InlineLink
</ce:PageAnchor>

Der Wunsch besteht nun darin, dass nicht nur ein Link aus dem Menü an diese Position erzeugt wird sondern dass es auch durch einen Zusatzparameter möglich wird, einen Rücksprung vom Marker zurück zur Position im Menü bekommen zu können.

Lösungsansatz

Dieses Verfahren wurde bereits sinngemäß für die Fußnoten programmiert: Die Fußnoten einer Seite werden allerdings automatisch zur Laufzeit durchnummiert. Das ist bei den Sprungmarken nicht gewünscht, denn deren Adressen/Keys möchte man individuell angeben können, um auch von Drittseiten dorthin verlinken zu können. Diese Adressen sollen also nachträglich nicht geändert werden.

Workaround

Der bisherige Workaround besteht darin, dass man einen Link zumindest zum PageAnchorLinks Menü erzeugt.

T182 PageAnchor mit Bookmark-Icon

Problemstellung

Es wird ein Zusatzparameter für die Konfiguration von <ce:PageAnchor> Elementen benötigt, um auf dessen Grundlage einen zusätzlichen Icon mit Link auf diese Position für die Erstellung von Bookmarks bzw. Speichern der Position anlegen zu können.

enableBookmarkIcon="1" wäre eine Variante, wie man diese Eigenschaft nennen könnte.

T183 Correct-URI-Wrong-Domain-Bug

Problemstellung

Das bislang in Version 1.5.2.x bestehende Verfahren beim der Verarbeitung von HTTP Request, suchen, finden, laden von redaktionellen Inhalten und dem zugehörigen Rendering-Prozess für die Erzeugung einer HTML Ansicht welche der Nutzer im Browser betrachten kann hat in Version 1.5.2.67 einen Bug:

Suchmaschinen adressieren mitunter zwar den Korrekten URI wie de/thema/was/auch/immer aber verwenden bei der Indizierung und Verlinkung plötzlich die falsche Domain.

Ursache

Die Ursache der Problematik besteht darin, dass eine UDS Installation als Framework die Webseiten für mehrere Domains darstellen kann und auch genau das tun soll. UDS differenziert also in der internen Verwaltung keine Domains sondern schlichtweg Realms, Ordner und Files verschiedener Typen, darunter RealmNode, RootNode, BranchNode, SectionNode, TopicNode, AspectNode und dergleichen.

Der verwendete HTTP Server, im Regelfall Apache, leitet also Anfragen für bestimmte Domains schlichtweg an den selben Kern der Software weiter. Hierbei wird zwar der Domainname korrekt übermittelt. Es ist aber möglich, dass ein URI de/thema/was/auch/immer über diese Domain damit korrekt adressiert werden kann obwohl dieser inhaltlich auch hin Hinblick auf Design und Logo eigentlich für eine andere Domain gedacht war.

Diese Flexibilität ist vom System ausdrücklich eigentlich gewünscht. Normalerweise dürfte also eine Suchmaschine wie Google eine falsche Kombination aus Domain und URI überhaupt nicht erfassen, denn so lange man niemals einen Link auf einen URI bei einer Domain A adressiert, der eigentlich zur Domain B gehört, dürfte auch die Suchmaschine damit für A diesen URI nicht erfassen. Die Realität aber zeigt: Genau das ist passiert.

Workaround Variante 1

Die erste Variante besteht darin, bei Erkennen einer Erfassung eines URI für die falsche Domain ein Forwarding zu programieren, um die falsche URL auf eine korrekte URL weiterzuleiten.

Workaround Variante 2

Bei einer Verlinkung von einer Seite der Domain A auf Inhalte der Domain B sollte zusätzlich über den reinen URI hinaus auch die Domain mit https://example.com/ vorangestellt werden. Damit ist sichergestellt, dass ein auf einen anderen Realm und dessen Domain verweisender Link auch von einer Suchmaschine korrekt erfasst wird.

Nachteil: Bei einem Verschieben von Inhalten von Domain B zu Domain C stimmt damit der Link nicht mehr.

Lösungsansatz

Der Lösungsansatz für die Lösung der Problemstellung besteht darin, für einen jeden URI nicht nur die zugehörigen Files und Inforationsstruktur wie Realm, Root, Branch etcetera zu ermitteln sondern darüber hinaus auch die passende Domain.

Wird also ein URI im System adressiert und wird hierbei festgestellt, dass die Adresse zwar den korrekten URI aber eine falsche Domain hat, ist in diesem Falle eine automatische HTTP Forwarding Weiterleitung mit wahlweise 301 oder 302 auf die korrekte Adresse möglich.

T184 Comment Element (Bug)

Problemstellung

Das <comment> Element dient im XML Code dazu, dass ein Redakteur hier Anmerkungen für die Bearbeitung schreiben oder auch durch das das Kapselns eines Bereichs mit <comment> und </comment> Elemente der Seite ausblenden kann, dh. solche Kommentarbereiche werden in der Webseiten ansicht normalerweise nicht dargestellt.

Innerhalb von <ce:WebPageMain><ce:contents>.. werden die Inhalte aber offenbar gerendert.

Workaround

Ein Workaround besteht schlichtweg darin, keine <comment> Elemente direkt unterhalb von <ce:WebPageMain><ce:contents>.. zu verwenden.

<comment> Elemente innerhalb von <HTMLBODY_MAIN_CONTENT_010_Section_Overview> Elementen sind übrigens möglich. Das gilt auch in Bezug auf <comment> außerhalb des WebPageMain.

T185 Emails und ContactForm

Problemstellung

Die Konfiguration des Email-Versands erfolgt in Version 1.5.2.67 noch über eine PHP Konfiguration im Client-Bereich. Dieses ist bislang erforderlich und auch gewollt gewesen, denn die Ergänzung des Systems um den Versand von Emails war einst bis jetzt nur für administrative Zwecke auf dem Hauptserver gewollt. Im Zuge der Nutzung des Systems auch auf Servern ist es erforderlich, die zugehörige Konfiguration zu vereinfachen und die Konfiguration des Systems als Ganzes zu vereinfachen.

Lösungsansatz

Es wird empfohlen, die bisherige Konfiguration für den Versand von Emails in die Konfiguration der übrigen Einstellungen für die jeweiligen Domains oder auch Realms zu verschieben.

Workaround

Ein Workaround ist zur Zeit nicht sinnvoll da das System im Ist-Zustand über die direkte Konfiguration des Email-Moduls genau so funktioniert wir es eigentlich auch mit dem Hinzufügen des Moduls gedacht ist.

/client/theme/* Ordner beinhalten bislang alle "Client-" im Sinne von "Kunden-" gezogenen Dateien für Templates, Downloads, Schriften, Zusatzmodule und mehr.

Status: Paused

Die Planung einer Umsetzung pausiert derzeit weil zuvor das Konfigurationsverfahren von Installationen von PHP auf XML/JSON/JSON+LD umgeplant wird, damit Kundenprojekte auch über C# .NET Core und JAVA Jakarta EE betrieben werden können.

T186 ScrollToTopMarker

Problemstellung

Der bisherige ScrollTopTopMarker als Teil des MainThemes ist entfallen. Dieser befand sich normalerweise unten rechts auf einer Webseite und wurde über eine fixe Positionierung immer angezeigt, so dass ein Nutzer jederzeit zurück zum Seitenkopf zurückspringen konnte.

Lösungsansatz

Es wird empfohlen, dieses Feature sowohl den Hauptheme sowie auch sonst jedem Theme für Darstellungen wieder hinzuzufügen. Der bisherige Code wurde entfernt weil das Theme und weitere Teile der zugehörigen Libraries entfernt wurden. Darüber hinaus wurden auch die zugehörigen Font Awesome Icons entfernt.



<a class="scroll-to-top hidden-mobile visible" href="#">
 <i class="fas fa-chevron-up"></i>
</a>

Workaround

Ein WorkAround besteht derzeit darin, einen Link zum Seitenkopf als Teil der Redaktion mit wahlweise Button- oder InlineLink-Komponenten zu realisieren.

Eine weitere Variante besteht darin, ein CERaw Element zu definieren und dieses über ContentInstance- und ContentReference-Verfahren als Baustein zentral zu erstellen und zu verlinken.

Die zweite Variante wird an dieser Stelle deshalb empfohlen, weil man die zugehörigen Position, an welchen das Element dann verwendet worden ist, sehr leicht über eine Suche nach den zugehörigen ce:ContentReference Elementen basierend auf dem Filelink finden kann.

Status: Waiting

T187 "Axis" Navigation

Problemstellung(en)

Das <Navigation> Element mit den Unterelementen Continue, AncestorUp, Previous und Next wurde bereits sehr früh in der Entwicklung von UDS geschaffen so dass der zugehörige XML Code noch dem ersten Schema entspricht. Es gibt in diesem Zusammenhang eine Reihe von zuempfehlenden oder auch erforderlichen Änderungen an diesen Navigation Elementen.

Struktur und Elemente umstellen

Die nachfolgenden Änderungen erfordern eine Umplanung und sind deshalb tiefgreifender:

Dieses Navigation-Element ist ursprünglich dafür gedacht gewesen, einem Leser eine Navigation über Buttons ähnlich wie bei Blogs mit PREVIOUS und NEXT anzubieten. Einen wirklichen Sinn macht dieses Verfahren aber nur dann, wenn es sich um eine lineare Abfolge von <ce:WebPage> Elementen handelt die man in einer gerichteten Abfolge aufrufen und lesen sollte. Springt man über einen Link oder eine Suchfunktion an eine der Seiten und fehlt und stellt man hierbei fest, dass man den bisherigen Inhalt noch nicht gelesen hat, so kann man über PREV zurückgehen.

Das Navigation-Element stellt genau diese Funktionalität mit Buttons, Pfeilen und einer Aufschrift dar. Das funktioniert auch von Beginn an.

Das Problem besteht allerdings darin, dass die Dokumentstruktur eine Baumstruktur ist: Kapitel 1, 2 und 3 bilden eine solche lineare Struktur auf der obersten Ebene. Die Kapitel 1.1, 1.2, 1.3 aber bilden ebenso eine lineare Abfolge auf zweiter Ebene wie eben auch 1.1.1, 1.1.2, 1.1.3 die lineare Abfolge auf dritter Ebene anbietet.

In der Redaktion stellt sich also immer wieder die Frage: Auf welche dieser Ebenen beziehen sich denn nun eigentlich diese Navigationselemente mit "lesen", "up", "previous" und "next"?

XML auf ce-Namespace umstellen

Für die zukünftige Verwendung von <Navigation> Elementen ist der Namespace <ce:*> einzuführen, dh. das Element muss zukünftig über <ce:Navigation> adressiert werden.

Bestehende Templates-Matches können über |ce:Navigation leicht erweitert werden, um die neue Adressierung zu verstehen.

Einführung des config-Parameters

Der UDS Standard sieht vor, dass alle XML Elemente die eigene Konfiguration über ein <ce:config> Element kapseln. Dieses Element darf fehlen wenn es nicht verwendet wird weil im Rendering hierbei Standardwerte greifen. Wenn es aber im Einzelfall eine redaktionelle Anpassung geben soll, dann im <ce:config> Element.

Vorher



<Navigation>
 <Continue>
  <Link>
   <text lang="de">de/uio3-docs/uds#contentBegin</text>
  </Link>
 </Continue>
 <AncestorUp>
  <Link>
   <text lang="de">de/uio3-docs/uds</text>
  </Link>
 </AncestorUp>
 <Previous>
  <Link>
   <text lang="de">de/uio3-docs/uds</text>
  </Link>
 </Previous>
 <Next>
  <Link>
   <text lang="de">de/uio3-docs/casestudies</text> 
  </Link>
 </Next>
</Navigation>

Nachher



<ce:AxisNavigation>
 <ce:config>
  <ce:axis>
  
   <ce:Ancestor>
    <!-- 
     Startpage of Actual Chapter
     Bisher: AncestorUp
    -->
   </ce:Ancestor>
   <ce:AncestorNext>
    <!-- 
     Next Chapter 
     Bisher: ---
    -->
   </ce:AncestorNext>
   
   <ce:SiblingPrevious>
    <!-- 
     Previous Page within this Chapter before this actual Page 
     Bisher: Previous
    -->
   </ce:SiblingPrevious>
   <ce:SiblingNext>
    <!-- 
     Next Page within this Chapter after this actual Page 
     Bisher: Next
    -->
   </ce:SiblingNext>
   
   <ce:Forward>
    <!-- 
     Wenn der Leser die Axis-Navigation sieht und den 
     aktuellen Inhalt lesen möchte, wurde hierzu 
     bislang der "Continue" Button geklickt. Dieser 
     dient einem Sprung immerhalb der aktuellen WebPage
     zumeist zum Marker #contentBegin.
    -->
   </ce:Forward>
   <ce:Continue>
    <!-- 
     Continue dient normalerweise bei der Verarbeitung des Körpers von
     Schleifen in wie zum Beispiel 
     for(..) { doA();doB();if(..){continue()};doC(); }
     dient continue dazu, den aktuellen Block, der in einer Schleife
     verarbeitet wird, abzubrechen und direkt mit dem nächsten
     fortzusetzen. Bei einem Kassetenrecorder, CD-Spieler oder anderen
     Geräten dient Continue zum Sprung zum nächsten Titel. 
     
     Continue springt also eigentlich an die Stelle wohin Next auch 
     bisher gesprungen ist. Der Kontext ist aber ein anderer.
    -->
   </ce:Continue>
  </ce:axis>
 </ce:config>
 <ce:contents>
 </ce:contents>
</ce:AxisNavigation>

T188 ListItem erfordert name-Wert

Problemstellung

Die Google Search Console liefert bei einer Vielzahl von Seiten einen JSON+LD Fehler im Zusammenhang mit Breadcrumb-Pfaden. Es handelt sich immer um das erste Element dieser Liste, und zwar das Element für die eigentliche Domain.

Beispiel: https://example.com/a/b/c beinhaltet drei URI-Segmente, und zwar a, b und c. Bei der Erzeugung des Breadcrumb Pfades lautet der Pfad ?>a>b>c, wobei das erste hier mit ? gekennzeichnete Element zumeist leer bleibt.

Problemstellung

Ursache: Das erste URI-Segment, welches in UDS den ContextNode wie "de", "en" oder auch "cn" für die Sprache angibt, wirft aus welchen Gründen auch immer keine Zeichenfolge aus.

Beispiel aus der Praxis

Der nachfolgende Quellcode-Auszug stammt von der LIVE Version unser unser Webseite, in diesem Fall für die Webseite mit dem URI 'de/@snm/learn/course/javascript'.



<script type="application/ld+json">{
 "@context": "https://schema.org",
 "@type": "BreadcrumbList",
 "itemListElement": [
 {
 "@type": "ListItem", "position": 1,"item": { "@id": "WebPage:", "url": "https://snewmedia.com/",
 "name": ""
 }
 },
 {
 "@type": "ListItem", "position": 2,"item": { "@id": "WebPage:de/@snm", "url": "https://snewmedia.com/de/@snm",
 "name": "@snm"
 }
 },
 {
 "@type": "ListItem", "position": 3,"item": { "@id": "WebPage:de/@snm/learn", "url": "https://snewmedia.com/de/@snm/learn",
 "name": "learn"
 }
 },
 {
 "@type": "ListItem", "position": 4,"item": { "@id": "WebPage:de/@snm/learn/course", "url": "https://snewmedia.com/de/@snm/learn/course",
 "name": "course"
 }
 },
 {
 "@type": "ListItem", "position": 5,"item": { "@id": "WebPage:de/@snm/learn/course/javascript", "url": "https://snewmedia.com/de/@snm/learn/course/javascript",
 "name": "javascript"
 }
 }
 ]
 }</script>

Lösungsansatz

Es ist zu klären, warum die Template für die BreadcrumbList, welche hier den JSON+LD Code erzeugt für das erste URI Segment keinen Wert auswirft.

Workaround

Es gibt für das Problem derzeit keinen Workaround bis auf den, das Problem schlichtweg zu ignorieren. Da alle Seiten aller Websites korrekt gerendert, angezeigt und auch bislang trotz des Bugs in Suchmaschinen wie Google indiziert werden, ist es nicht kritisch.

Der nervige Aspekt ist allerdings der, dass die zugehörigen Seiten in der Google Search Console bis zur Klärung des Fehlers konsequent als Seiten mit Fehlern erfasst werden.

Status: Waiting

Die Priorität ist dahingehend hoch, dass dieser Fehler bei SEO Maßnahmen Zeit kostet.

T189 Barrierefreiheit

Problemstellung

Alle Webseiten öffentlicher Stellen müssen entsprechend der EU-Richtlinie 2016/2102 [2] zur Umsetzung eines barrierefreien Internets angepasst werden.

Mit UDS realisierte Webseiten lassen sich mit allen gängigen Endgeräten weitgehend verwenden, dh. alle Inhalte sind aufrufbar. Eine vollständige Barrierefreiheit aber ist bislang nicht möglich.

Der Aufwand einer kompletten Umstellung vor allem der eingebundenen Dokumente verschiedener Herkunft steht nicht im Verhältnis zum voraussichtlichen Nutzen für den Besucher. Die Unverhältnismäßigkeit der barrierefreien Gestaltung wird im Artikel 5 Absatz 2 und 4 der EU-Richtlinie (EU) 2016/2102 beschrieben.

Lösungsansatz für Bilder

Für Bilder sind Alternativtexte anzugeben. Diese werden im HTML Code als alt-Tag ausgegeben.

Für ImageObject Elemente ist in diesem Zusammenhang eine Erweiterung zu programmieren, mit deren Hilfe diese alternativen Texte redaktionell eingegeben werden können.

Im Anschluss an die Erweiterung der UDS Templates für ImageObject Elemente gilt es für die Redaktion, alle ImageObject Elemente zu finden die noch nicht bearbeitet wurden.

Trick17: Da kein einziges ImageObject die neue Eigenschaft haben wird und diese über ce:config zugewiesen wird, ist es möglich, allen <ce:BreakShy/> ce:ImageObject Elementen konsequent durch Suchen/Ersetzen <ce:config> durch von <ce:config><ce:alternativeText> mit * und schließendem </ce:alternativeText></ce:config> zu ersetzen.

Die Eingabe von * als Text ist ein Provisorium und dient zuerst einmal dazu, alle ImageObject Elemente im weiteren Bearbeitungsverlauf finden zu können, welche noch nicht editiert wurden.

Status: On-Hold

So lange mit UDS keine Webseiten öffentlicher Stellen erstellt werden, ist die Barrierefreiheit nach EU-Richtlinie (EU) 2016/2102 für Unternehmen noch nicht bindend. Es steht aber (Stand 2024) zu erwarten, dass der Gesetzgeber das auch auch Unternehmen erweitern werden wird.

Es sei aber darauf hingewiesen, dass alternative Texte für Bilder auch für SEO einen Zweck erfüllen.

Status: On-Hold

Hinweise: ce:ImageObject Elemente werden zwar zur Zeit (Stand 1.5.2.68) mit ce-Namespaces erfasst, sind allerdings noch nicht auf die kommenden Interfaces für CreativeWork Objekte angepasst worden.

Es ist dahingehend noch nicht geklärt, für welche Eigenschaft diese alternativen Texte eigentlich erstellt werden weil das UDS System eben nicht nur den HTML Code für Webseiten sondern auch LinkedData und APIs automatisch erzeugt.

Eine doppelte Eingabe von Inhalten kostet Redakteure zuviel Zeit und sollte vermieden werden.

Witz des Tages

Die Richtlinie wird, Stand 16.10.2024, übrigens nicht als HTML-Seite im Web veröffentlich sondern als PDF. Links siehe unten.

https://www.bundesnetzagentur.de/DE/Service/Barrierefreiheit/EU_2016_2102.html

https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32016L2102&rid=1

T190 Zeichenumbruch in Begriffen wie C++

Problemstellung

Browser entscheiden beim Rendering von HTML Code eigenständig, an welcher Stelle ein Umbruch im Text erfolgt. Dieses führt wieder im Zusammenhang mit Begriffen wie C++ [3] dazu, dass die aus C und zwei + Zeichen bestehende Zeichenfolge zwischen C+ und + getrennt werden kann.

Browser orientierten sich beim Umbruch an einer Reihe von Regeln, dh. Browser versuchen normale Textzeichen, wie diese in üblichen Worten, Namen und Begriffen erscheinen, als Ganzes zu erhalten. Lange Betriffe werden also von einem Browser gar nicht getrennt. Das führt wiederum dazu, dass manche Spezialisten*innen auf die Idee kommen, Zeilenumbrüche mit einem - Zeichen anzugeben. Das funktioniert zwar durchaus, aber da sich je nach Browserfensterbreite der Umbruch im Layout ändern kann, verschiebt sich auch der Zeilenumbruch immer wieder dahingehend, dass plötzlich fehlerhaft ein - Zeichen im Text auf Webseiten erscheint.

Merke:

.NET [4]

Korrekte Lösung in UDS

Für optionale Zeilenumbrüche in UDS besteht die korrekte Herangehensweise darin, ein <ce:BreakShy/> an die Position eines optionalen Zeilenumbruchs einzufügen. Das Element wird im Falle von HTML Ausgaben als &shy;> HTML Entität ausgeben. Browser kennen dieses Zeichen und dann passend dort an den Stellen um, sofern das Sinn macht.

Bug: Für übrigens alternative Ausgabeformate wie JSON, LD+JSON sollte der Zeilenumbruch im Output von UDS eigentlich nicht ausgeben werden, wird er allerdings, das die Template für das <ce:BreakShy/> bislang nicht differenzieren kann, welches Ausgabeformat geliefert werden soll.

de/@snm/dev/blog/uio-1-5-2-x#anchorID-uio-1.5.2.27

Korrekte Lösung in UDS zur Verhinderung von Umbrüchen

Ein solches Element scheint in UDS aktuell (1.5.2.68) zu fehlen und wird als T191 ergänzt.

T191 ViewActionButton erfordert target

Problemstellung

Das nachfolgende Beispiel zeigt UDS XML Code in welchem ein ViewActionButton Element als Link auf eine Zielseite definiert wird. Dieser Button soll im Inhalt klar erkennbar sein und verlinkt auch korrekte die Zielseite, aber wir wünschen, dass ein neues Fenster geöffnet wird, damit der Nutzer die bisherige Webseite noch im bisherigen Browserfenster wiederfinden kann.



<ce:ViewActionButton shape="rounded" version="1.5.2.0">
 <ce:config>
  <ce:label>
   <text lang="de">Programmstruktur von C++ Anwendungen</text>
  </ce:label>
  <ce:target>
   <text lang="de">_blank</text>
  </ce:target>                                  
  <ce:uri>
   <text lang="de">de/uio3-docs/cpp/cpp-book-1/program_structure</text>                                   
  </ce:uri>
 </ce:config>
</ce:ViewActionButton>  

Ergänzend sind die XSL Templates zu vereinheitlichen. Es wurde festgestellt, dass es zwei Versionen der XSL Files gibt.

Lösungsansatz

Wie bereits bei ce:InlineLink Elementen ist hier schlichtweg eine ce:target Eigenschaft zu ergänzen.

Status: Waiting

Das Feature wird kommen weil wir es benötigen.

T192 FootNote in ce:VTabsPanelGroup/ce:panel nicht adressierbar

Problemstellung

Wenn in einem Text innerhalb eines ce:panel Elements als Teil einer ce:VTabsPanelGroup eine Begriff mit einer Fußnote über ce:FootNote verknüpft wird, erscheint zwar die Fußnote innerhalb eines ce:FootNodeCollectionModule Elements. Der Rücksprung an das ce:FootNote Element funkioniert aber nicht.

Die primäre Ursache besteht darin, dass bei dem Versuch des Browser, zur einem solchen ce:panel zurückzuspringen, möglicherweise dieses Element geschlossen sein könnte. Es müsste also quasi dann über JavaScript bei einer Adressierung geöffnet werden.

Eine zweite Ursache besteht möglicherweise darin, dass der zugehörige Anchor als Sprungziel gar nicht gerendert wurde und damit in HTML Code fehlt.

Status: Waiting

Die Priorität für dieses Problem ist "mittel". Offenbar wird die Fußnote gar nicht angezeigt. Ein Nutzer kann also zum Text der Fußnote gar nicht springen sondern würde diese nur finden, wenn er am Seitenfuß alle Texte von Fußnoten liest und versucht, zu einem Marker zurückzuspringen.

T193 Default-404-Seiten in User-Realms

Problemstellung

Wenn in einem User-Realm die RoutingDefinition.xml Datei fehlerhafte Angaben zur Adressierung einer HTTP404 Seite hat wird bislang eine Fehlermeldung von der Engine ausgeworfen.

Die Ausgabe zwar zwar im Webhosting in der Live-Version zumeist bei korrekter Konfiguration unterdrückt, bewirkt aber auch dann eine weiße Seite ohne Fehlerausgabe.

Lösungsansatz

Der erste Lösungssansatz sollte darin bestehen, dass mit jeder Installation des Systems stets auch eine Default-404-Seite damit auch Default-Routen vorhanden sind, wo zumindest der Server selbst eine sinnvolle Information auswirft. Es sollten als XML Files sowie Routen für den Default-Zweig als Fall-Back-Lösung bestehen.

Die Idee ist hierzu, dass man diese über eine zweite Definition überschreiben kann; wenn die eigene Definition aber fehlt sollte die Originalversion gelten.

Dieses entspricht dem #ifndef Prinzip in C++.

Status: Waiting

Die Priorität für dieses Problem ist "mittel". Offenbar wird die Fußnote gar nicht angezeigt. Ein Nutzer kann also zum Text der Fußnote gar nicht springen sondern würde diese nur finden, wenn er am Seitenfuß alle Texte von Fußnoten liest und versucht, zu einem Marker zurückzuspringen.

T195 SystemCrawler

Problemstellung

Die manuelle Redaktion von Seiten, Menüs und Routen kann zu Fehlern führen. Um diese finden zu können, ist es sinnvoll, Linkfehler automatisiert finden zu können.

Lösungssansatz

Ein systeminterner Crawler sollte in einem ersten Durchlauf alle RoutingDefinition.xml Files im System lesen.

Basierend auf dieser Information ist der Crawler bereits in der Lage, zumindest relative URLs bezogen auf den Basis-URI bestimmen zu können.

Hinweis: Der Basis-URI sowie auch die zugehörige Domains ist in Version UDS 1.5.2.70 nur über Konfigurationsdateien in /conf sowie die HTTP Server Konfiguration einsehbar.

Es ist also erforderlich, in einem ersten Schritt sicherzustellen, dass alle Konfigurationen aller Daten inklusive Domain-Angaben, die sich sonst in .htaccess oder /conf befinden, konsequent in XML notiert sind, damit diese Files mit dem selben Verfahren gelesen und ausgewertet werden können wie die redaktionellen Inhalte selbst auch.

T196 Remove _DEPRECATED Folders

Problemstellung

Im Versionssprung von 1.5.1.x zu 1.5.2.x wurden einige Ordner mit dem Prefix _PRECATED* verstehen, um testen zu können, ob diese noch von irgendwo adressiert werden. Diese Ordner können ersatzlos jetzt gelöscht werden. Alle bisherigen Bestandteile wurden in 1.5.2.x neu programmiert.

Die Ordner müssen von Hand gelöscht werden.

T197 Favicon in User-Realms

Problemstellung

Es wird eine Option benötigt, dass Favicon für eine WebPage für User-Realms ändern zu können.

Favicons werden üblicherweise direkt über den Root-URI über beispielsweise https://example.com/favicon.ico adressiert. Einige Browser, darunter der Mozilla Firefox, adressiert diese Adresse faktisch ungefragt und generiert damit für jede Webseite, selbst wenn nur ein simpler HTML Code mit HalloWelt! geladen wird, dennoch zwei Zugriffe.

Lösungsansatz

Lösungsansatz: Es ist möglich, die Adressen für Favicons von *.ico auf *.png mit alterantiven Bildformaten sowie auch auf andere URIs umzustellen, damit auch statt des URI / ein /was/auch/immer/favicon.png oder aber auch ein /mein-unternehmen-favicon.png möglich wird.

Workaround

Ein Workaround besteht derzeit darin, bei UDS Installation mit mehreren Domains eine leere Grafik bzw. ein einfarbige Fläche wie weiß oder schwarz oder rot zu erzeugen. Damit haben alle Pages und Domains dann immer eine Grafik bekommen, aber alle die falsche.

Man kann die Grafik auch komplett weglassen. Dazu muss aber die favicon-Adressierung im HTML Code entfernt werden.

T198 Codehints für XML

Problemstellung

Es gibt inzwischen für UID über 100 Contentent Elements, kurz CEs. Auch wenn man im Regelfall mit Copy-Paste von Vorlagen arbeitet, so gibt es inzwischen zwei Problemstellungen:

Lösungsansatz

Workaround

T199 Dropdown-Menüs am rechten Rand

Problemstellung

Menüs im Kopfmenü, die sich bei einem der letzten zwei Einträge als Dropdown öffnen, haben das Problem, dass die 2. und auch 3. und 4. Ebene des Menüs möglicherweise beim öffnen über den rechten Rand des Browserfensters hinausgeht.

Workaround

Für das SwitcherMenü und das ClusterMenü programmieren wir das Rendering so um, dass diese Menüs eine zusätzliche CSS Klasse 'isSwitcherOrCluster' bekommen.

Damit ist es möglich, dass der Designer das Problem über CSS lösen kann.

Lösungsansatz

Das Kernproblem besteht darin, dass eine Lösung nur mit CSS faktisch NICHT möglich ist. CSS kann nicht erkennen, ob ein linksbündig angeordnetes Menü über den rechten Browser-Rand hinaus geht.

Eine solche Berechnung ist nur dann möglich, wenn Menüeintrage/Labels alle eine gleiche Größe haben und man über die Nummer des Menüeintrags auf die X-Position im Layout schließen kann und bei Kenntnis der exakten Breite von Dropdowns die Gesamtanzahl der der Pixel in der Breite weiß. Auch damit allein lässt sich das Problem nicht lösen, dh. man muss dann ein Media Query programmieren, um basierend auf dieser Vorabberechnung von Layouts schon wissen zu können, ab welcher Browserfensterbreite für welchen Menüeintrag an Position ?? das Problem besteht, um es dann mit CSS zu lösen.

Die einzige wirklich funktionierende Lösung besteht darin, beim Aufklappen von Menüelementen mit JavaScript immer auch mit JavaScript eine Positionsabfrage für die betreffenden Elemente durchzuführen.

T200 Autoerkennung von Switcher- und ClusterMenu

Problemstellung

Im Rendering-Prozess des Kopfmenüs werden in Version 1.5.2.75 nur anhand des XML load- bzw. ref-Attributs bei Menü erkannt.



<ce:Nav-L2-NavMenu style="1" #
  load="/Realm/***/***/HeaderNavigationCluster_RealmNode_V3.xml">
</ce:Nav-L2-NavMenu>

<ce:Nav-L2-NavMenu style="1" 
  ref="Lade hier den Switcher ...."">
</ce:Nav-L2-NavMenu>  

Dieser Ansatz war zum Zeitpunkt der Entwicklung ein "Workaround" um möglichst schnell Cluster- und Switcher-Menüs integrieren zu können.

Für die Zukunft muss das Rendering aber in der Lage sein, referenzierte wie auch nachgeladene Komponenten und deren Daten in Bezug auf deren Typ automatisiert erkennen können.

ref

Die Idee dieser load- und ref-Attribute für ce:Nav-L2-NavMenu Elemente hat NICHTS mit den Switcher- oder Cluster-Menüs selbst zu tun sondern zuerst einmal nur damit, dass mit "ref" eine bestehende Menükomponente über deren ID referenziert werden können soll.

Dieses Prinzip soll also für jede Komponente schlussendlich dienen, die überhaupt irgendwo im System erfasst wurde.

load

Mit dem load-Attribut wiederum geht es darum, dass ein Dokument geladen wird ähnlich wie bei ce:ContentReference und ce:ContentInstance Elementen.

Workaround

Für das SwitcherMenü und das ClusterMenü programmieren wir das Rendering so um, dass diese Menüs eine zusätzliche CSS Klasse 'isSwitcherOrCluster' bekommen.

Damit ist es möglich, dass der Designer das Problem über CSS lösen kann.

Lösungsansatz

Das Kernproblem besteht darin, dass eine Lösung nur mit CSS faktisch NICHT möglich ist. CSS kann nicht erkennen, ob ein linksbündig angeordnetes Menü über den rechten Browser-Rand hinaus geht.

Eine solche Berechnung ist nur dann möglich, wenn Menüeintrage/Labels alle eine gleiche Größe haben und man über die Nummer des Menüeintrags auf die X-Position im Layout schließen kann und bei Kenntnis der exakten Breite von Dropdowns die Gesamtanzahl der der Pixel in der Breite weiß. Auch damit allein lässt sich das Problem nicht lösen, dh. man muss dann ein Media Query programmieren, um basierend auf dieser Vorabberechnung von Layouts schon wissen zu können, ab welcher Browserfensterbreite für welchen Menüeintrag an Position ?? das Problem besteht, um es dann mit CSS zu lösen.

Die einzige wirklich funktionierende Lösung besteht darin, beim Aufklappen von Menüelementen mit JavaScript immer auch mit JavaScript eine Positionsabfrage für die betreffenden Elemente durchzuführen.

T201 CSS Compression::Comments

Problemstellung

Der CSS Code insbesondere von custom.css Klassen sowie CSS Code für neue Komponenten beinhaltet diverse Kommentarzeilen.

Es ist gewünscht, dass diese Kommentarzeilen, sofern diese nicht mit /** als Dokumentationskommentar beginnen, entfernt werden.

Das nachfolgende CSS Code Beispiel zeigt die typischen Varianten von Kommentarblöcken in CSS Code.



/*
=======================================
=== SwitcherMenu
=======================================
*/
/*
Normaler Blockkommentar ... 
*/ 
.uio-isSwitcher { /* Block am Ende von Zeilen */
 color: /* Block innerhalb einer Zeile */ red; 
}

Workaround

Der einzige Workaround besteht derzeit darin, im CSS Code entweder gar keine Kommentare zu schreiben oder aber diese Kommentare in einen zweiten File an eine Position auszulagern, wo dieser Kommentarcode nicht geladen wird.

Eine Variante besteht mitunter darin, die Kommentare über einen Link auf die Webseite/Doku zu verlinken. Damit findet sich im Quellcode zwar noch eine Doku, aber die Redakteure haben die Option, diese Inhalte vor Zugriff zu schützen, indem ein Login und/oder aber bestimmter Cookie gefordert wird.

Lösungsansatz

Programmierung eines Stream-basierten CSS-Code-Parsers, kurz "SBCCP". Im Kern geht es hierbei darum, dass jedes Zeichen im CSS Code, welches sich nicht in einem mit /* beginnenden und mit */ endenden Bereich befindet zuerst einmal als Kommentar betrachtet wird und diese Inhalte zu White-Space transpiliert werden können.

Hinweis: Das Prinzip ist das gleiche Verfahren wie bei der bisherigen auf JAVA basierneden Programmierung der JSON- und JSON+LD Parser des Projekts welche inzwischen ebenso in JSON Kommentarcode erlauben, den es gem. JSON Standards eigentlich nicht gibt.

Status: Konzept

Das Prinzip wurde mitunter für das Rendering und die Auswertung von JSON/LD+JSON in JAVA bereits mehrfach programmiert.

Priorität: mittel

Wir können derzeit auch ohne eine Lösung leben.

T202 PostProcessing::StyleBlocks

Problemstellung

Eine Vielzahl von Templates rendern nicht nur HTML Code sondern auch gleich zugehörige STYLE-Elemente mit CSS Code und CSS Klassen für die betreffende Komponente.

Auch wenn der zugehörige Style-Block und CSS Code durchaus von Browsern korrekt verstanden wird führt dieser Ansatz zu drei Problemstellungen:

Formal betrachtet ist der HTML Code mit diesen Ansatz NICHT valide. Style-Blöcke dürfen nur innerhalb des HEAD Elements erscheinen.

Sonderfall: SVG+Style

Das nachfolgende Beispiel zeigt den erzeugten HTML Code mit einem Style- sowie auch einem SVG-Element für einen Icon. In diesem Fall ist die Plazierung von STYLE innerhalb von DEFS in SVG zulässig.



<li data-ce="Nav-L3-MenuItem" data-ce-v="1.1.0.5">
 <a class="dropdown-item" href="de/@snm/studio">SNM | STUDIO | Hauptseite
  <span class="icon-23.2262434" style="font-size: 12px; padding-left: 5px; ">
  <svg  
    xmlns="http://www.w3.org/2000/svg" 
    id="icon-arrow-up-right" 
    style="height: 16px; width: auto;" 
    viewBox="0 0 32 32">
   <defs>
    <style>
     path, polygon {
      color: #bbbbbb;
      fill: #bbbbbb;
     }
    </style>
   </defs>
   <polygon points="10 6 10 8 22.59 8 6 24.59 7.41 26 24 9.41 24 22 26 22 26 6 10 6"></polygon>
   <polygon points="10 6 10 8 22.59 8 6 24.59 7.41 26 24 9.41 24 22 26 22 26 6 10 6"></polygon>
  </svg>
 </span>
 </a>
</li>  

Lösungsansatz

Programmierung einer zusätzlichen PostProcessing-Methode der PostProcessor Klasse.

Hinweis: Die Ausgabe der Templates ist genau genommen nicht HTML5 Code sondern XML Code mit HTML5 Elementen. Erst über ein PostProcessing wird bislang der eigentliche erzeugte XML/HTML Code in HTML5 umformatiert, indem eine XML Syntax für einige Elemente wie IMG, BR, HR und andere in HTML5 gewandelt wird.

Da vor diesem PostProcessing der XML/HTML Code allerdings XML-konform ist, ist es möglich, über DOM Selektion alle die STYLE Elemente unterhalb des BODY Elements im Code zu selektieren, welche sich NICHT innerhalb eines SVG Elements befinden.

Jedes hier selektierierte STYLE Element kann anschließend als letztes Childelement in das HEAD Elements verschoben werden.

Zusatzfeature

Oftmals erscheinen diese STYLE Blöcke mehrfach in identischer Fassung wenn die zugehörige Komponente mehrfach im HTML Code erscheint.

Indem wir einen Hashcode für den STYLE-Block erfassen können wir Doubletten erkennen und nachfolgende identische STYLE-Blöcke kurzerhand weglassen.

Alternativer Lösungsansatz

Unter der Voraussetzung, dass jede Component einen eindeutigen CSS-Klassen-Prefix erhält, ist es ebenso möglich, den Code von STYLE-Blöcken nicht in den HEAD des HTML5 Dokuments zu verschieben sondern in einen page-styles-generated.css File welcher anschließend als letzte Zeile im HEAD Block noch nachgeladen wird.

Status: Konzept

Das Verfahren funktioniert und wurde bei damaligen Versionen schon einmal in JAVA realisiert.

Priorität: mittel

Webseiten lassen sich auch mit fehlerhafter Position von STYLE-Blöcken im HTML Code vom Browsern korrekt darstellen.


Workaround

Der einzige Workaround für das Problem besteht darin, in XSL Templates keine Style-Blöcke zu erstellen und/oder aber diese von Beginn an so im XML/HTML Output so zu kennzeichnen, dass diese in einem PostProcessing noch weiteraus leichter zu finden und zu verschieben sind.

Beispiel: Mit xsl:comment ist es möglich, die zugehörigen STYLE-Blöcke mit HTML-Kommentar-Elementen zu umschließen nach welchen vergleichsweise leicht gesucht werden kann.

T203 Events für Menü-Interaktionen

Problemstellung

Alle Interaktionen mit Navigationselementen sollten zukünftig konsequent Events auslösen, um auf diese mit Hilfe von JavaScript reagieren zu können.

Wofür das erforderlich ist

Das Öffnen von Menüs und Untermenüs insbesondere für Elemente der Hauptnavigation und hierunter insbesondere zuletzt das ClusterMenu und SwitcherMenu kann dazu führen, dass neu geöffnete Menüelemente sich außerhalb des sichtbaren Bereichs des Browserfenster öffnen (vgl. Task T199).

Auf diese Problemstellung ließe sich mit JavaScript reagieren (siehe Task T204). Die zugehörige Erkennung und Korrektur der Position von Menüelementen erfordert aber ein Ereignis/Event, um wissen zu können, wann eine solche Prüfung eigentlich durchgeführt werden muss.

Lösungsansatz

Wir empfehlen, die nachfolgenden Ereignisse zu erfassen und hierfür über das System weiter eigene Events auszulösen, damit auf einige Aspekte mit Korrekturen reagiert werden kann.

Event für Veränderungen der Browserfenstergröße: Die meisten UI Komponenten werden mit CSS responsiv programmiert. Es gibt allerdings Fälle, in denen über CSS mehrere Ebenen beispielsweise für modale Dialoge und Tooltipps erzeugt werden deren Position ggf. angepasst werden muss.

Event für Interaktionen mit Navigationselementen sowie auch Links erfassten (Klick/Touch).

Handler für Korrekturen

Im Zuge dieser Events ist eine Überprüfung der Position von Layout-Komponenten durchzuführen, ob sich diese noch innerhalb des Browserfensters befinden.

Wenn dem nicht so ist, sind entsprechende Positionen von Components zu verändern.

Event nach Korrekturen und zusätzlicher Handler

Hinweis: Die Veränderung der Position einer Komponente kann wiederum dazu führen, dass ein absolut zu dieser positionierte weitere Komponente nun aus dem Browserfenster herausragt.

Es sollte sichergestellt werden, dass es maximal 5 solche Schleifen geben kann entsprechend der maximalen Verschachtelungstiefe von Menüs mit 5 Gliederungsebenen.

T204 Handler und Prüfung von Objektpositionen

In Ergänzung zu Task T203 mit dem Auslösen von Events ist es erforderlich, dass Objektpositionen insbesondere von Navigationselementen, darunter die Panels von Untermenüs, überprüft werden und deren Position ggf. korrigiert wird.

Weitere Informationen siehe Task T203.

T205 Konstante für Fehlerausgabe zur Laufzeit

Die derzeitige Fehlerausgabe zur Laufzeit wird bislang noch über eine Konstante im Code konfiguriert. Die Einstellung ist in eine Konfigurations- oder Settingsdatei, wenn möglich in XML auszulagern, um die Files der eigentlichen Anwendung konsequent von der Konfiguration trennen zu können.

Status: Wartet

Priorität: Mittel

T206 PageHeader Default

Für einen schnellen Aufbau von neuen Rubriken ist es sinnvoll, auch PageHeader verlinken zu können.

Es möge mal jemand bitte testen, ob auch die PageHeader bereist über ContentReference und Content Instance Elemente referenziert werden können.

Workaround: In der Zwischenzeit kann auch mit Copy-Paste gearbeitet werden. Tipp: Man sollte im XML Code eine laufende Nummer des Typs des Headers vergeben, weil das die Suche nach bestehenden Instanzen stark erleichtert.

Status: Wartet

Priorität: Niedrig

T207 Text-Elements und apply-templates

Als Vorbereitung für T208 ContentReference für Properties ist es erforderlich, das sowohl normale XML TextNode(s) als auch <text lang="de"> mit sowie auch wiederum ohne das lang-Attribut korrekt gerendert werden.

Dieses setzt voraus, dass text-Element eine eigenständige Template programmmiert wird und diese sinnvollerweise anschließend auch über ce:Text definiert werden kann, um damit konsequent den Type in Großbuchstaben zu schreiben und diesen als Content-Element mit ce-Prefix kennzeichnen zu können.

T208 ContentReference für Properties

Die ce:ContentReference Elemente funktionieren bislang nur direkt unterhalb ce:WebPageMain/ce:contents und bei allen Elementen, welche mit xls:apply-templates Ihre ce:contents rendern.

Die Inhalte der meisten Properties und Config Einstellungen von Elementen, darunter ce:WebPage/ce:config/ce:description, greifen bislang aufschließlich auf den TextNode innerhalb des ce:description Elements zu und rendern diesen als Text.

Um auch für diese Fälle das Prinzip von ContentReference und ContentInstance nutzen zu können, muss jede Property explizit individuell für die Unterstützung umgerüstet werden.



<?xml version="1.0" encoding="UTF-8"?>
<doc
 ...
>
 <ce:WebPage>
  <ce:config>
   ..
   <ce:description>
    <ce:ContentReference uri="/Realm/example.com/_ContentInstances/cblock-WebPage-description-default-@example.xml"/>      
    Contact page of the official webpage of Example.
   </ce:description>
   ..
  </ce:config>
<ce:WebPage>  

Diskussion

Einige Property- und Config-Werte dürfen nur Zahlen, true/false oder auch wirlich nur Text haben. Um das sicherstellen zu können, werden die Inhalte im Prinzip mit xsl:value-of gerendert, dh. deren TextNode wird unabhängig von irgendwelchen weiteren XML ce-Elementen kurzerhand nur als Text interpretiert.

Damit auch XML-Elemente innerhalb dieser Werte verstanden wird, ist es erforderlich, dass nicht mit xsl:value-of sondern mit xsl:apply-templates mit einer Selektion für den aktuellen Knoten über select="." gearbeitet wird.

Die Voraussetzung hierfür ist allerdings, dass der Renderer in der Lage ist, text-Elemente zu erkennen, dh. <text lang="de"> sowie auch weitere ohne das lang-Attribut.

Status: Wartet

Priorität: Mittel bis hoch

T209 XSL Catching Missing XML File Errors

Problemstellung

Wenn aus XSL heraus adressierte XML Files, deren Adressen in XML Files zur Adressierung von ContentReferences noch nicht oder nicht mehr mit dieser Adresse bestehen, erzeugt der XSL Prozessor eine Exception welcher wiederum auch von PHP ausgeworfen wird.

Primärziel: Kontrolliertes Abfangen dieser Fehlermeldungen und Warnungen und Umleitung in Logfiles oder an Stellen, wo Redakteure erkennen können, wo es fehlende Files gibt.

Sekundärziel: Kontrolliertes Abfragen bereits auch in XSL, um dort eine für den Nutzer verständliche Informationen wie beispielsweise "Dieses Dokument wurde noch nicht erstellt." auszugeben oder aber über einen Returncode sicherzustellen, dass die dieses Dokument nachfragende Template das Element gar nicht zu rendern versucht.

Ursache

Immer dann, wenn eine Redakteur in der Redaktion von Inhalten Inhalte über bereits bestehende ContentInstance Deklarationen referenzieren möchten, ist es in 1.5.2.x üblich, den zugehörigen XML zu referenzieren, in welchem das zugehörige Dokument mit der Information zu finden ist.

Das Problem in einer Vorwärtsdeklaration von Referenzen besteht darin, dass die Wahrscheinlichkeit sehr hoch ist, dass diese weitere Dokumente zum Zeitpunkt der Erstellung der Verlinkung noch gar nicht existieren.

Das Problem besteht auch in den Fällen, in welchen eine File mit einer ContentInstance, welcher über ContentReference Techniken verlinkt wurde, zwischenzeitig umbenannt, verschoben oder auch gelöscht wurde. So etwas sollte man zwar eigentlich nie machen bzw. basierend auf IDs verhindert werden. Bei einem auf Files und URIs basiertenden Verfahren lässt sich das aber nicht verhindern.

Lösungsansatz

Ein einfache Try-Catch-Konstrukt funktioniert in diesem Fall nicht, denn XSL Prozessoren arbeiten eigenständig, dh. die Dokumente XML Dokumente werden durchaus vollständig verarbeitet, selbst dann, wenn Fehler auftreten. Der Grund besteht darin, dass es XSL eigene XSL Fehler und XSL Warnungen als Returnwert zurück gibt, welche zwar mit PHP ausgweertet s

T210 XSL Missing XML Navigation

Problemstellung

Ähnlich wie im Falle von T209: Wenn aus einer WebPage eine WebSite referenziert wird deren File es gar nicht gibt, führt auch das zuerst in XSL und dann in PHP zu einem Fehler.

Die Ausgabe des Fehlers in PHP lässt sich nach Klärung von T209 unterdrücken. Wichtig ist aber, dass zusätzlich der nicht vorhandene File auch in XSL selbst kontrolliert abgefangen wird.

Warning: XSLTProcessor::transformToXml(C:/~/cms/data/server): Failed to open stream: Permission denied in C:\~\cms\core\res\classes\Routing.php on line 3882