Siehe auch /BehobeneProbleme, DseAnregungen, SupportWiki:WikiAnregungen, SupportWiki:WikiProbleme.

Inhaltsverzeichnis dieser Seite Suche über Titel-Link einer Unterseite klappt nicht    Nicht vollständig in Google indiziert    Klammern in Quelltexten    Änderungen/Korrekturen    Cache    Style    Zählen der Änderungen    Suche    InterWiki Bitte    CharacterCode0166 Inkonsistenz    Vorschau    Code    Schrägstrich    Links    Unbeabsichtigte Unterseite    Sehr kaputtes Textparsing    Symbol bei PDF-Links

Suche über Titel-Link einer Unterseite klappt nicht

Wählt man auf der Seite GregorRayman/Exceptions oben den Titel-Link, wird mit "Keine Seite gefunden." geantwortet. Die Seite ist aber mehrfach verlinkt.

Ja, danke für den Fehlerbeschreibung. Die ausgeschriebenen Verlinkungen sind vorläufig zur Not über Volltextsuche zu finden DiesesWiki:search=GregorRayman/Exceptions . Das Problem muss ich mir anschauen, hängt sicher mit Umstellung auf die hierarchische Struktur und Linkstrategien zusammen. Danke nochmal. -- HelmutLeitner

Nicht vollständig in Google indiziert

Wir sind mit diesem Wiki in Google anscheinend nicht vollständig indiziert, z. B. liefert die Suche /"bjarne stroustrup" "schrieb das buch"/ (derzeit, 27. November 2003) keinen Hinweis auf die entsprechende Seite dieses Wikis. (Hier jetzt absichtlich kein Link. ;-)

Vielleicht hat jemand Ahnung, wie man das ereichen kann ...

(Vor längerer Zeit meinte mal jemand, wir wären recht vollständig indiziert, siehe DseWikiImGoogle.)

Mmmh, die Wege des Google sind unergründlich. Ich habe hauptsächlich aus den vorhandenen Seitenzahlen geschlossen, dass die Indizierung einigermaßen vollständig sein dürfte. Hatte aber auch schon immer Probleme mit der Seite EKEIDP, die ziemlich populär ist, auch jeder Menge Links hat, die darauf zeigen, aber im Google nicht zu finden ist. Keine Ahnung warum. Google kommt an sich alle 4-5 Wochen und klappert "alles" ab. -- HelmutLeitner

Interessantes um Registrierte Seiten einer Domaine im Google rauszufinden: site:www.wikiservice.at und eventuelle suchbegriffe sucht nur seiten diese domaine -- FranzWieser

Stand 22. Januar 2004: Die entsprechende Seite wird gefunden.

Klammern in Quelltexten

Manchmal kommt Wiki mit den eckigen Klammern in nicht klar. Im folgenden Beispiel musste ich die Klammern verdoppeln, damit ein Teil des Quelltextes nicht ausgeblendet wird:

def quicksort(a): if not a: return [] return quicksort([x for x in a if x < a[0]]) + [a[0]] + quicksort([ [x for x in a[1:] if x >= a[0]] ]) #im 2. quicksort-Aufruf ist ein Klammerpaar zu viel, aber Wiki zeigt es sonts nicht an

Änderungen/Korrekturen

Siehe ÄnderungOderKorrekturDiskussion

Cache

Wenn man die Editierseite anfordert (action=edit), schickt AFAICS der HTTPd keinen No-Cache-Header mit ("Cache-Control: no-cache" oder "Cache-Control: max-age=0", AFAIK). Gibt Probleme mit HTTP-Proxies, die dann diese Seite evtl. nicht neu vom Server anfordern. Ist das beabsichtigt?

Du meinst, dass nach dem Editieren dem Benutzer u.U. auf diese Weise die alte Seite - ohne seine Änderungen - angezeigt wird?

(Voraussetzung ist, dass ich den Browser so konfiguriert habe, dass ein Proxy-Server benutzt wird)

Ich rufe "Ändern" auf einer Seite auf und bekomme das Textfeld angezeigt

Beim Aufruf der Seite hat sich der Proxy-Server deren Inhalt gemerkt ("gecached"), d.h. er hat die Seite in einem internen Zwischenspeicher abgelegt (dafür sind Proxies da)

Wenn ich nun später erneut in derselben Seite "Ändern" aufrufe, liefert der Proxy-Server die gecachete Seite aus, d.h. mit dem alten Inhalt

Dieses Problem ist mir nicht bewusst und wenn dieses Problem auftaucht, natürlich auch nicht beabsichtigt. Zur allfälligen Lösung benötige ich aber noch mehr Informationen und am besten jemanden der das Problem sehen und die Behebung kontrollieren kann. -- HelmutLeitner

Die Abhilfe besteht darin, dass der Webserver dem Proxy-Server mitteilt, dass eine bestimmte Seite nicht zwischenspeichern soll. Das geschieht dadurch, dass der Webserver mit der Seite eine spezielle Headerzeile mitschickt, die wie erwähnt entweder "Cache-Control: no-cache" oder "Cache-Control: max-age=0" lautet. Seiten, die sich praktisch ständig ändern (so wie diese hier), sollten eigentlich immer eine solche Zeile enthalten. Muss im Webserver so konfiguriert werden.

Da muss ich mich jetzt schlau machen (Apache). Lieber würde ich via Perl jeder Wiki-Seite explizit so eine Zeile mitschicken. Das Einzige, was ich im CGI-Modul sehe, ist aber ein push(@header,"Pragma: no-cache") if $self->cache();. Möglicherweise bewirkt das etwas ähnliches. -- HelmutLeitner

Wie sieht es jetzt bei dir aus? Derzeit ist $cgi->header(-Cache_control => 'no-cache', -pragma => 'no-cache') aktiviert. --hl

Es hat zuletzt Probleme mit den no-cache Optionen in Zusammenhang mit Formularen gegeben, sodass ich kurzfristig gezwungen war, diese zu deaktivieren. Möglicherweise muss ich dieses Problem noch einmal von vorne aufrollen und entweder eine Wiki-spezifische oder Benutzer-spezifische Lösung finden. Wer mit der aktuellen Situation Probleme hat, bitte noch einmal hier deponieren. -- HelmutLeitner

Style

In diesem Wiki führt der vorgegebene Style für besuchte Links auf meinem Monitor dazu, dass diese sich kaum von normalem Text unterscheiden. Warum muss denn ein Style vorgegeben sein? Was spricht dagegen, die Default-Styles, die der Benutzer in seinem Browser eingestellt hat, zu respektieren? -- HelmutEnckRadana

Da könnte man sicher einen Kompromiss finden. Oft führt das Design eines Wiki dazu, dass der Eigentümer auch eine bestimmte Farbauswahl (HTML BODY-Tags TEXT, LINK, VLINK, ALINK) vorgibt. Wenn man darauf verzichtet und bei einer Demo auf einem Fremdgerät oder bei einem Neubenutzer führt dessen Einstellungen zu einer ganz anderen Optik, dann löst das keine Begeisterung aus. Was ich mir aber gut vorstellen kann, ist das optionale Abschalten dieser Tags in den Benutzer-Einstellungen. Wäre das für dich akzeptabel? -- hl

Optimal! -- her

Zählen der Änderungen

In den Diskussionen der letzten Tage ist mir aufgefallen, daß die Autoren die Anzahl der Änderungen mitnehmen also

• (diff) LinuxDiskussion/SoftwareInstallation 20:09 (7 Änderungen) . . . . . DavidSchmitt
• (diff) LinuxDiskussion/SoftwareInstallation 19:43 (23 Änderungen) [Argument ad hominem? - Nö!] . . . . . JamesBond?

• (diff) LinuxDiskussion/SoftwareInstallation XX:XX (24 Änderungen) . . . . . JamesBond?
• (diff) LinuxDiskussion/SoftwareInstallation 20:09 (7 Änderungen) . . . . . DavidSchmitt

Na ja, ob beabsichtigt, da will ich mich nicht festlegen. :-) Jedenfalls ist es die Anzahl der Änderungen des jeweiligen Autors an dem betreffenden Tag. Irgendjemand anderer hat auch schon mal gemeint, es wäre eine ziemlich überflüssige Information. Soll ich sie wegnehmen? -- hl

Nein. Wenn man das angreift sollte man sich zuerst einmal ein paar AnforderungsGeschichten zurechtlegen, was dort wirklich interessant wäre.

Suche

[Langsam krieg ich ja schon ein schlechtes Gewissen, weil ich dauernd hier schreibe.]

Wenn man CharacterCode0166 einsetzt, interferiert das mit der Suchfunktion:

• TestMit0166 (Test¦Mit0166)

Mir ist bewußt, daß das kein triviales Problem ist, wollte es aber hier einfach dokumentieren.

InterWiki Bitte

Siehe InterWebLinks/Erweiterungsvorschläge

CharacterCode0166 Inkonsistenz

Weil es mit oben gerade aufgefallen ist: Rein gefühlsmäßig sollte bei http://linuxwiki.de/%s wohl vor dem '¦' die URL beendet werden.

Wäre natürlich. Da müsste man aber den Chracter 166 zu einem verbotenen Zeichen in Urls machen. -- hl

Ist der '¦' überhaupt in URLs erlaubt?

Ich habe keine Ahnung, deswegen bin ich vorsichtig. -- hl

Gesehen habe ich ihn noch nicht, notfalls kann er als %A6 kodiert werden. Ich seh' mich mal in den relevanten RFCs um.

Octets must be encoded if they have no corresponding graphic character within the US-ASCII coded character set, if the use of the corresponding character is unsafe, or if the corresponding character is reserved for some other interpretation within the particular URL scheme.

Na ja. Das gleiche gilt für Umlaute. Und auch das wird nicht einheitlich gehandhabt. -- hl

Abgesehen von den zugrunde liegenden philosophischen Aspekten von VereinheitlichungUndStandards, kommt im gesamten DseWiki "http:\S*¦" genau einmal (nämlich hier) vor.

Vorschau

Bei der Vorschau nach dem Editieren werden Links nur teilweise als solche formatiert.

Hallo, Mister Unbekannt! Danke für den Hinweis. Das DseWiki läuft derzeit auf der Entwicklungsversion (siehe FractalWiki:action=HomePage) und da hatte sich eine Unsauberkeit eingeschlichen. Sie sollte jetzt behoben sein. -- HelmutLeitner

Code

Die Darstellung von Code-Elementen unterscheidet sich von Browser zu Browser deutlich. Um beispielsweise mit dem Konqueror eine nicht verunstaltete Darstellung zu bekommen muss der Quelltext mit höchstens 50 Zeichen Breite formatiert sein. Das passt auch recht gut zu dem eingestellten width=50. Für Benutzer von beispielsweise Mozilla belibt aber unverständlich, warum der Autor Code so "schmal" formatiert.

Dafür fügt Mozilla mit \\ abgeschlossene Zeilen einfach wieder zusammen, was, wenn der \\ auch noch verschwinden würde, wohl ein gute Lösung wäre. Der \\ bleibt aber stehen, womit der angedeutete technische Zeilenumbruch als Syntaxfehler erscheint.

Schrägstrich

Lt. Duden wird ein / nicht mit Leerzeichen umschlossen. Es heißt also C/C++ und nicht C / C++. Die Wiki-Software interpretiert den / ohne Leerzeichen ziemlich oft als Ordnerzeichen. Beispiel: Bla/Bla.

Ja, leider. Macht auch bei manchen Textautoren ziemlich viele Probleme (nicht im DseWiki). Client/Server wäre ein Beispiel. Zwei Alternativen gäbe es:

(1) Entweder die Links nur bei vorhandener Hauptseite als Fragezeichen-Edit-Link zu realisieren, oder

(2) für diese Links eine CamelCase-Seite vor dem Schrägstrich zu verlangen. Beides kann auch verwirren, deswegen konnte ich mich noch zu Nichts entschließen.

Was erscheint plausibler? -- HelmutLeitner

Ich habe mal Variante (1) implementiert. -- HelmutLeitner

Variante 1 finde ich in Ordnung. Allerdings erscheinen die betreffenden Wörter noch bei den verlangten Seiten. Ist das beabsichtigt? -- EnricoHüttig

Nein, das ist nicht beabsichtigt. Es kommt daher, dass ich nur den Link fürs Neuanlegen unterdrücke, zu einer gleichnamig vorhandenen Seite aber den Link herstelle. Nicht konsistent, wird behoben. Danke fürs Fehler-Reklamieren. -- HelmutLeitner 5. Oktober 2004 12:41 CET

Sollte jetzt behoben sein. -- HelmutLeitner 5. Oktober 2004 12:57 CET

Links

Warum werden Links hier nicht genauso gehandhabt, wie in den anderen Wikis (mit eckigen Klammern). Mir ist z.B. aufgefallen, das VisualBasic und VisualBasic für Applikationen auf den gleichen Link (VisualBasic) verweisen, obwohl es ja nicht das gleiche ist. Aber soll man nun zur Unterscheidung VisualBasicFürApplikationen? schreiben? -- RitaBock?

Hi Rita, ich weiß nicht genau, was to meinst. Geht es um CamelCase vs. explizite Links? Oder darum Links mit anderem Titel zu versehen? Geänderte Titel können so geschrieben werden, meist sinkt aber dabei die Transparenz. -- HelmutLeitner

Unbeabsichtigte Unterseite

Wie bekomme ich aus SpracheSmalltalk/Portabilität einen Link auf SoftwarePortabilität? Irgendwie lande ich immer bei SpracheSmalltalk/SoftwarePortabilität.

Ich hab die leere Seite SpracheSmalltalk/SoftwarePortabilität zuerst gelöscht, dann linkt die Seite automatisch auf das Top-Level. Andernfalls Top:SoftwarePortabilität.

Die Reihenfolge, in der nach möglichen Seiten für das Linken gesucht wird, ist in der Konfigurationsvariable

Variable AutoLinkStrategies: B;T

definiert. Siehe SupportWiki:AutoLinkStrategies (B=Brother=gleiche Ebene, T=Top). -- HelmutLeitner

Sehr kaputtes Textparsing

Diese Zeichen stören den Aufbau der Seite bei der Vorschau gewaltig. Man beachte vorallem den untersten Teil der Seite (Nach Zusatzfunktionen):

''foo ''

Symbol bei PDF-Links

Links auf Dokumente mit der Endung .PDF werden anders dargestellt als solche auf *.pdf. Beispiel siehe ModelViewPresenterPattern.