Version 3.93.2
-
Soeben ist Version 3.93.2 live gegangen.
Sie enthält eine Fehlerbehebungen für die letzte Version: https://hilfe.church.tools/wiki/0/Weiterentwicklung von ChurchTools ("Changelog") -
Wir benutzen die Version 3.93.2. Seit 2 Wochen (Version davor) sind an CT-Wiki gravierende Änderungen gemacht worden, die eine vollständige Überarbeitung aller Beschreibungen nötigt machen und die
<details>Funktion zur strukturieren Beschreibung geht seit dem garnicht mehr. Die Rückmeldung vom Support (#89396) das: "nicht als Fehlverhalten zu werten" kann ich nicht nachvollziehen. Ein Beispiel Im Text ist der Header:## YT Studio, auf den bisher mit... auf der [Studio](#ytstudio) Seite findest du ...verlinkt wurde. das ist seit 2 Wochen mit(#YTStudio)- also case-sensitive anzugeben.Ich hatte das bereits im Chat hier geschrieben @Andy * hat mich ermutigt das im Forum (also hier) zu diskutieren.
*Editiert von Admin (Andy), da die Chat-ID hier nicht zugeordnet werden kann.
-
@ralf-werner verwendest du schon Markdown? ich vermute, ja.
ich würde dringend davon abraten, in Markdown HTML einzubetten. Das ist unglücklich, dass das überhaupt geht. Ich bin nicht sicher, ob das beabsichtigt ist. Dokumentiert ist es jedenfalls nicht.
Das mit den AutoID (link auf Überschriften) ist natürlich unglücklich. Ich selber hab das bewusst nie verwendet. Ich kann mir aber auch nicht vorstellen, dass dieses Verhalten absichtlich verändert wurde. Wenn, dann hätte es eine Migration geben müssen. Wenn nicht dann ist es eigentlich ein Bug. Wenn das aber nicht dokumentiert war, dann kann man sich auch nicht darauf verlassen.
Im Grunde ist es ein Feature-Request, Markdown Attrribute zu unterstützen. Habe es in die von mir angelegte Wunschliste eingetragen.
-
@bwl21 Ich benutze ausschließlich MD! Die
<details>Funktion benutze ich auch in anderen MD-Wiki-Umgebungen ohne Probleme (und in CT bist vor zwei Wochen) , wie auch diverse andere Funktionen, die in CT-Wiki alle nicht gehen. Um eine gute Umsetzung zu betrachten sollte man sich Wiki ansehen. Da ist CT sehr weit von entfernt.Mein Beispiel oben ist typisch, wenn mehr als eine Bildschirm-Seite auf der Wiki-Seite ist. Kathegorie übergreifend wäre das dann bei uns der Link:
(https://anskar.church.tools/wiki/7/test/#YTStudio)Die beste Lösung wäre natürlich case-unsensitive (lower wie zuvor aber konsequent wie bei Personen-Suche) und eine Positionierungs-Genauigkeit wie über das Inhaltsverzeichnis.Ich denke auch nicht dass dieses Verhalten absichtlich verändert wurde, aber auf die Bitte, es sofort zurückzusetzen hat mein CT-Supporter nicht reagiert. Das hätte ja in dieser Version bereits erfolgen können, weshalb ich noch wartete. Ein Feature Request ist der Wunsch nach etwas Neuem nicht das Beheben eines gerade eingefügten Fehlers. Wünsche hätte ich ziemlich viele und dringliche. Wenn ich deinen Beitrag aber richtig interpretieren bist du auch nur am sammeln und nicht am umsetzen.
-
@ralf-werner Es gibt nicht das eine Markdown. Wie viele andere Standards auch ist "Markdown" zu einem Oberbegriff für einen ganzen Wust von Markdowns geworden. Ein Verweis auf das Wiki Markdown genügt also nicht also Beweis für einen Fehler, allenfalls als Zielmarke.
Ich werde vom CT Support immer wieder auf dieses Dokument verwiesen:
https://www.markdownguide.org/cheat-sheet/
woaus ich schließe, dass man sich bei der Implementierung daran orientiert hat. Und ja, darin fehlen viele Dinge, an die wir uns in anderen Markdowns (einschließlich HTML) gewöhnt haben. Es bleibt zu hoffen, dass die Implementierung nach und nach erweitertert wird. Zu bedenken ist dabei allerdings, dass jegliche Erweiterung für die App und das Web implementiert werden muss. Und wenn für eine (oder gar beide) dieser Platformen eine Bibliothek verwendet wurde, dann sind den Erweiterungen möglicherweise auch Grenzen gesetzt.
Nun zu dem konkreten Problem:
Grundsätzlich sind URLs ab dem Server/Domain Namen case-senstiv. Es steht dem Server frei, davon abzuweichen und diesen Teil der URL ebenfalls case-insensitiv zu behandeln. Das oben von mir referenzierte Dokument macht zu diesem Punkt keine Aussagen, weshalb ich dazu raten würde, von einer case-sensitiven Behandlung auszugehen und der Einfachheit halber nur lower-case zu verwenden. Das ist eigentlich immer eine gute Idee: Auf Nummer sicherzugehen und das strengere Verhalten anzunehmen, und sich darüber zu freuen, wenn der Server manchen Fehler meinerseits verzeiht.Kurzum: Mag sein, dass sich das Verhalten kürzlich geändert hat, aber du hast dich da möglicherweise auf etwas verlassen, was bislang überhaupt nicht garantiert war und nur zufällig funktioniert hat.
-
@thommyb sagte in Version 3.93.2:
Kurzum: Mag sein, dass sich das Verhalten kürzlich geändert hat, aber du hast dich da möglicherweise auf etwas verlassen, was bislang überhaupt nicht garantiert war und nur zufällig funktioniert hat.
Danke für deiner allgemeinen Abhandlung zu MarkDown. Das war mir bekannt. Es beschreibt aber nicht die Lösung für mein Problem, Das die Änderung der CT-MD Funktionalität die Überarbeitung aller meiner Dokumente nach sich zieht. Wenn ich deine Aussagen ernst nehme, kann das demnächst erneut geschehen.
Neben Feature-Request und Bug-fixing gibt es auch den Begriff Rollback, was in diesem Fall die Lösung wäre. Das ist i.W. eine CT-Interne-Funktion, so dass ich den Verweis auf die App und verschiedene lib* nicht nachvollziehen kann.
Ich bin unsicher ob du das Problem richtig verstanden hast. Es geht nicht um URLs (da gibt es keine Probleme) sonder um Header-Rererenzen. Dazu sagst du "Einfachheit halber nur lower-case zu verwenden". So war das vorher! Wenn du keine solche Dokumente hast, kannst du es auch nicht wiederholen, es sei denn ein du bekommst ein Rollback. Das hätte ich dann auch gerne
Ich habe aufgegeben mit der App zu arbeiten, da sie in einem sehr desolaten Zustand ist, gegenüber der web-Version keine Vorteile bietet und oft in den web-Modus wechselt. Dort sind dann auch wieder die Fähigkeiten von mobilen Geräten nutzbar (weil das fast jeder Browser kann).
-
Ich kann dir versichern, dass ich mich mit URLs sehr gut auskenne. Ich verdiene mein täglich Brot mit diesem Wissen. Und da muss ich dir leider mitteilen, dass die anchor/header id sehr wohl mit der URL zu tun hat. Sie muss nämlich korrespondieren mit der fragment id (das ist der Teil nach dem "#") in der URL. Wie sonst sollte der Browser wissen, welchen Teil des Fensterinhalts er in den Blick rücken sollte? Und meines Wissens sagt der Standard, dass dieser Teil case-senstiv ist.
Allerdings war ich bis eben davon ausgegangen, dass CT custom-ids unterstützt. Darauf bezog sich meine Emfehlung, nur Kleinbuchstaben zu verwenden. Nun stelle ich aber gerade fest, dass custom ids nicht unterstützt werden, sondern nur automatisch generierte IDs. Ich denke, das ist der Teil, auf den du dich beziehst. Wenn hier nun tatsächlich bei der automatischen Generierung etwas geändert wurde, dann könnte das zu dem von dir beschriebenen Verhalten geführt haben. Ich weiß, dass zuletzt etwas an der Generierung von HTML Attibuten geändert wurde. Die anchor id fällt in das Muster und könnte davon betroffen gewesen sein. (Spekulation!) In diesem Fall wäre es vielleicht so oder so zu einer notwendigen Korrektur gekommen.
Nebenbei bemerkt finde ich die automatisch generierten anchor/header ids ziemlich wackelig und anfällig. Wer würde denn von "Lärm im Außen- und Innenbereich" auf die anchor/header id "LrmbelstigungimAuenundInnenbereich" kommen, ohne im HTML source nachzuschauen? Ich käme gar nicht auf die Idee, so meine URLs zusammenbauen zu wollen. Deshalb denke ich, das eigentliche Manko sind die fehlenden custom ids. Mit denen ließen sich die entsprechenden IDs abhängigkeits- und regelfrei benutzen. Zu spät für dich, weil das URL-Kind bereits in den Brunnen gefallen ist, aber sicher trotzdem einen Feature Request wert.
-
@thommyb sagte in Version 3.93.2:
Wer würde denn von "Lärm im Außen- und Innenbereich" auf die anchor/header id "LrmimAuenundInnenbereich" (lrmimauenundinnenbereich vor 3 Wochen) kommen
Danke @thommyb für deine Abhandlung zu anchor/header Ich wünsche mir, das in meiner Gemeinde sich viele mit der Beschreibung ihrer Prozesse beschäftigen und habe versucht eine einfache Beschreibung (#links) dafür zu erstellen, die jeder mit Erfahrung im "Mails-Schreiben", versteht. Zwar mit links zu offiziellen Seite aber sonst nur den Umgang mit Leer- und Sonderzeichen an einfachen Beispielen, wie deins.
Ich bin noch immer der Meinung, die Wiederherstellung einer Funktion, von vor drei Wochen ist kein Feature-Request sondern Rollback oder bestenfalls Bug-Fixing-der-einfachen-Art (man weiß ja wie es vorher richtig war).
Warum gerade (evtl nur) bei CT lower-case nicht funktionieren soll, habe ich nicht verstanden. Ich habe oft mit github-MD gearbeitet, wo lower-case funktioniert (ähnlich zu CT-Wiki vor 3 Wochen). Eine meiner Seiten habe ich in beiden Umgebungen eingebaut und davon ein kleines Video gemacht. Wie kann ich das hier hochladen? Wichtiger als case-sensivität, ist mir aber das die abgeschaltete<details>Funktion wieder aktiviert wird. -
Was @thommyb schreibt, beschreibt es schon sehr gut.
Die IDs für die Überschriften wurden eingeführt, damit das Inhaltsverzeichnis funktioniert. Irgendwie mussten diese IDs generiert werden und dabei kam
LrmimAuenundInnenbereichbei raus. In der letzten Version wurde eine Fehlerbehebung für führende Zahlen gemacht, da das in IDs nicht erlaubt ist. Dabei ist der Fehler reingekommen, dass die IDs nicht mehr lowercase generiert werden. Den meisten Usern wird es nicht auffallen, da sie diese IDs nicht nutzen. Für die nächste Version werden wir das Verhalten natürlich wieder zurückdrehen.Das
<details>zurzeit nicht funktioniert, liegt daran, dass wir hier eine härtere Überprüfung des generierten HTMLs aus Markdown einbauen mussten und dabei nur gewisse Tags erlaubt sind.<details>hatten wir dabei bisher einfach nicht auf dem Schirm, können wir aber denke ich auch wieder erlauben. Dies wird aber vermutlich in der App auch nicht vernünftig gerendert?!Bedenkt dabei: Da wir unser Markdown nicht nur in HTML fürs Web umwandeln, sondern es auch in der App mit React-Native auf iOS und Android funktionieren soll, werden wir hier in Zukunft restriktiver sein (keine Angst, mit entsprechendem Vorlauf und Migration). Wem die Möglichkeiten unseres Markdowns-Umfangs nicht ausreichen, sollte einfach die HTML-Version des Wikis nutzen!
-
-
Danke Andy ich bin leider nicht berechtigt oder die 3.4Mb sind zu groß.
Für die Fehlermeldung reict es aber
-
@ralf-werner na ja ... aber die Antwort von @jziegeler sollte ja etwas versöhnlich für dich klingen.
-
@jziegeler sagte in Version 3.93.2:
Dies wird aber vermutlich in der App auch nicht vernünftig gerendert?!
Vieleicht nicht vernünftig aber es funktionierte überhaupt. Wenn ich die Berechtigung hätte *.mp4 (29 Sekunden) hochzuladen, könnte ich das hier zeigen.
Ich habe deinen Beitrag als Rollback Ankündigung der nächsten Version verstanden
und deine Rolle als berechtigt es zu tun - fein! Wann kann ich damit rechnen? -
Ich habe mal einen Feature-Wunsch aufgemacht, um das Ganze abzurunden. Bitte gerne hier abstimmen: https://forum.church.tools/topic/9019/custom-ids-für-wiki
-
@ralf-werner sagte in Version 3.93.2:
Um eine gute Umsetzung zu betrachten sollte man sich Wiki ansehen. Da ist CT sehr weit von entfernt.
Hm ... dein Link zeigt auf den Wikipedia-Atikel. Der ist eine allgemeine Abhandlung zu Wikis.
Es gibt keine allgemein anerkannte Definition für Wikis und keine Einigkeit darüber, welche Merkmale ein Wiki ausmachen.
Nicht dass ich mit dem CT-Wiki schon zufrieden wäre (siehe meine Wunschliste) ... aber das 'sehr weit entfernt', müsstest du dann doch etwas präzisieren, damit wir verstehe, was genau du meinst.
Insbesondere sollte man unterscheiden zwischen Funktionen des Wiki und der Unterstützung von Markdown.
-
@bwl21 sagte in Version 3.93.2:
müsstest du dann doch etwas präzisieren, damit wir verstehe, was genau du meinst.
Betrachte Wiki mal nicht inhaltlich (WikiWiki-Bus) sondern als Beispiel, mit welcher Erwartung ein wikipedia Nutzer die Aufarbeitung von Informationen zu einem Thema liest. Selbst wenn MD=MarkDown-Wiki Einschränkungen gegenüber HTML hat, könnten viele Funktionen auch mit MD umgesetzt werden
Ich habe mit github-MD Erfahrung, wo vieles fuktioniert, was in CT fehlt. Vor allem ist es ein stabiles Wiki, dass von Nicht-Experten gut gepflegt werden kann, auch wenn dort nicht alles Gold ist was glänzt. Wenn man sich an den anchor/header Algorithmus von @thommyb oben gewöhnt hat kann ich damit gut leben. In github ist das genauso und wenn CT es schafft nicht-case-sensitiv zu arbeiten, um so besser, dann brauche ich auch alle Änderungen der letzten zwei Wochen nicht rückgängig machen.
-
@ralf-werner Solange nicht klar und verlässlich definiert ist, wie die IDs generiert werden, würde ich diesen keinen Meter über den Weg trauen bzw. immer davon ausgehen, dass ich mein Wiki anfassen muss, wenn sich am Alogrithmus etwas ändert.
Beispiel Umlaute: Es gibt ja durchaus mehrere Möglichkeiten, einen Umlaut in ein umlaut-loses Format zu überführen:
(1) Der Umlaut entfällt (ä -> _) [Zustand heute]
(2) Der Umlaut wird als blanker Vokal dargestellt (ä -> a)
(3) Der Umlaut wird aufgelöst (ä -> ae)
(4) Der Umlaut wird ähnlich einer HTML Entität dargestellt (ä -> auml)Mit jeder Änderung des Algorithmus wird es potenziell Leute geben, deren IDs gebrochen werden. Diejenigen, die in den letzten zwei Wochen solche IDs im Wiki eingesetzt haben, werden stöhnen, wenn wieder irgendetwas zurückgedreht wird. Diejenigen, die Zahlen zu Beginn ihrer Überschriften haben (was ja durchaus wahrscheinlich ist), werden stöhnen, weil diese seit zwei Wochen nicht mehr möglich sind. Ich würde sagen: Die Büchse der Pandora ist geöffnet. Und ohne Dokument, das die Regeln verlässlich beschreibt, kann sich niemand auf irgendetwas berufen, außer: "letzte Woche ging's noch".
-
@thommyb sagte in Version 3.93.2:
Mit jeder Änderung des Algorithmus wird es potenziell Leute geben, deren IDs gebrochen werden.
Da gebe ich dir recht. Dennoch würde ich mich über den baldigen Rollback den @jziegeler angekündigt hat freuen (warte noch auf Antwort auf meine Frage - Wann). Wenn er in den Allgorithmus eine gewisse Fehlertolleranz programmiert und dies nicht den Rollback verzögert (mein Vorschlag oben) hätte ich nichts dagegen.
Auf unserer Technik-Kathegorie-Seite habe ich die (damals) aktuellen Regeln beschrieben und wie mit den Schwachheiten von CT-Wiki am besten umgegangen wird, um sich nicht zu sehr zu ärgern und die trotzdem die Potentiale zu nutzen. Deiner Liste oben füge ich noch einen Punkt hinzu:
(5) Das Sonderzeichen wird durch %<hexcode> ersetzt (benutzt CT-Wiki manchmal auch z.B. "%20" für space).Wie @jziegeler oben sagte ("Den meisten Usern wird es nicht auffallen, da sie diese IDs nicht nutzen.") das kann sein! Ich benutze es viel, mit dem Effekt das reine Leser der Texte mir die Verantwortlichkeit zuordnen, wenn die links nicht "funktionieren".
-
@ralf-werner Hi Ralf-Werner, jeder nutzt das "Wiki" anders, als wirkliches Wiki mit "viele schreiben = Crowd Intelligence" habe ich es noch nicht gesehen, aber meine Welt ist klein
Als ich mich vor 20 Jahren mit "topic-based technical documentation" (im Rahmen des XML-Standards DITA) beschäftigte, wurde empfohlen, jede Seite genau eine Bildschirm-Seite lang zu machen, also kein Scrolling und zumindest keine Inhaltsverzeichnisse. Die Überschrift sollte beschreiben, auf welche (eine) Frage der Leser eine Antwort bekommt.
Wikipedia hat viele Artikel = Seiten, die ein kleines Büchlein für sich sind (ich denke immer noch papierbasiert, bitte verzeiht).
Das ist nicht mein Vorbild. Denn Lesen 2.0 ist nicht sequentielles Lesen sondern selektives Lesen. Dazu einfach auf jeder (kurzen) Seite Begriffe als Links markieren und unten einen Abschnitt mit Verlinkungen "Verwandte Themen" einfügen.
Wenn jeder deiner Zwischenüberschriften, die es wert sind, verlinkt zu werden, der Name eines Wiki Artikels wäre, dann gäbe es dein Problem nicht.
Anderer Punkt: Wenn jede Änderung freigegeben werden müsste (Qualitätssichernder Ansatz), dann sind kurze Seiten einfacher freizugeben, da nur wenige Experten gegenlesen müssen, je mehr auf der Seite steht, umso mehr muss geprüft werden, da ja alles schnell veraltet. Es ist für Leser toll, wenn eine gestern geänderte Seite komplett aktuell ist und nicht nur die 5% in einem Unterabschnitt ...Zusammenfassung: Jeder macht es anders, es gibt kein falsch oder richtig, nur ein aufmerksam oder lieblos - und da sehe ich, dass du dich echt bemühst, damit die Perlen an Information gefunden werden können!
-
@gunnar sagte in Version 3.93.2:
Als ich mich vor 20 Jahren mit "topic-based technical documentation" (im Rahmen des XML-Standards DITA) beschäftigte
Yup 20 Jahre sind eine lange Zeit Bildschirme sehen heute anders aus, Erwartungen und Verhalten ändert sich
. Ich wollte darüber eigentlich nicht philosophieren, sondern nur die verlorenen CT-Wiki Fähigkeiten zurück, was mir @jziegeler oben auch zusagte, nur noch nicht Wann.
