Fixe Anker

[hausl]

Ich muss immer wieder feststellen, das Seitenanker nicht mehr stimmen, das finde ich mittlerweile echt schon doof. Wenn sich in einem Tutorial der ### Header ändert, dann ändert sich ja automatisch der Anker mit und alle Verweise auf den alten Anker - auch von den anderen Beiträgen - sind nicht mehr gültig und somit nicht mehr direkt verlinkbar.

Ich hab leider keine Idee... gibts ev. auch sowas das man den Headlines einen fixen Anker mitgeben kann den man dann als quasi Perma-Anker verwenden kann?

[mermshaus]

Du kannst möglicherweise hinter/unter die Zeile mit der Überschrift so was setzen:

### Die Überschrift
{: #eine-feste-id}

• http://kramdown.gettalong.org/syntax.html#inline-attribute-lists

PS: Ich könnte das alles selbst ausprobieren, aber ich will keine unnötigen Merge-Konflikte herbeiführen, falls du auch was dran machst.

[hausl]

Ja das funktioniert.

http://php-de.github.io/jumpto/standard-mail-validation/#quellen (#quellen hab ich fix vergeben)

Bleibt nur noch die Frage ob wir uns hier auch was überlegen sollen

• wie bei den jumpto.. also irgend eine Prefix/Namespace bezugnehmend auf den Artikel oder sonstwelche Logik
• und ob wir durchgängig fixe Anker vergeben sollen. Das sollte (muss) dann nämlich auch in die Contribute-Richtline.

[mermshaus]

also irgend eine Prefix/Namespace bezugnehmend auf den Artikel oder sonstwelche Logik

Ich glaube, das ist nicht notwendig, denn die Identifier hängen ja am URL, sind also durch den genamespacet, wenn man so will.

ob wir durchgängig fixe Anker vergeben sollen

Das ist vermutlich ganz sinnvoll, um das von dir beschriebene Probleme etwas mehr zu verhindern, ja. Für bestehende Artikel kann man ja sagen, dass zumindest dann einer (der bestehende?) explizit vergeben werden sollte, wenn die Überschrift noch mal verändert wird. Dann müssen wir nicht jetzt zwingend erst mal alles anpassen.

Letztlich wird das wohl immer ein kleines Problem bleiben, da ja Überschriften theoretisch auch ganz gelöscht werden könnten. Es ist aber sicher denkbar, ein Check-Tool zu programmieren, dass die fertigen HTML-Seiten durchgeht und guckt, welche Links ins Leere zeigen. Das muss man ja nicht alles von Hand machen.

In die Contribute-Richtlinie aufzunehmen, dass nach Möglichkeit eine eigene ID vergeben werden sollte, finde ich aber sinnvoll.

[Golpha]

Bedenkt aber das ihr grad bei Kontent-sensitiven Dingen wie Ankern weniger perm-linken könnt als ihr vielleicht meint. Ein Kirsche-Anker der auf eine Apfel-Überschrift zeigt macht nicht viel Sinn. (Ja ich weiß, Grundsätzlich werden sich die Beiträge nicht so stark verändern dass sie das gesamte Überschrift-Thema verändert, aber es mag durchaus sein das Beiträge Themen später mal zusammenfassen oder ausgliedern, da ist der Anker dann eh inexistent wenn er vorher verlinkt wurde oder er hat sich zu einem gemeinsamen Anker für einen allgemeineren Abschnitt verändert. Beides lösen eure Problem-Ansätze nicht, sind aber die häufigsten Gegebenheiten die eintreten können.

Ich für meinen Teil würde die Anker allerhöchstens simplifizieren (vom Wortlaut). Wenn ein Anker mal weg fällt, ob nun gelöscht oder ersetzt, ist das halb so tragisch, da der richtige Gesamtbeitrag der die gewünschte Information mit hoher Wahrscheinlichkeit noch enthält ja angesteuert wurde.

[mermshaus]

Bedenkt aber das ihr grad bei Kontent-sensitiven Dingen wie Ankern weniger perm-linken könnt als ihr vielleicht meint.

Ich bezog mich auf interne Links (ich denke, hausl auch?), hatte ich aber nicht dazugeschrieben. Das sind eben Links im Inhaltsverzeichnis eines Artikels beziehungsweise zwischen Seiten des Projekts. Die können wir kontrollieren.

Wer von extern auf einen URL mit Fragment-ID verlinkt, muss meines Erachtens ohnehin wissen, dass der Fragment-Teil nicht wahnsinnig robust ist. Das ist nicht unser Problem, sage ich mal. :)

In Sachen URLs sind wir mit dem flachen „Wiki“-Schema schon ausreichend gut dabei, denke ich. Bei weiteren Maßnahmen für erhöhte Robustheit (gepflegte DB mit neuen Entsprechungen für legacy URLs etwa) sehe ich schnell ein Missverhältnis von Aufwand und Nutzen.

Wenn ein Anker mal weg fällt, ob nun gelöscht oder ersetzt, ist das halb so tragisch, da der richtige Gesamtbeitrag der die gewünschte Information mit hoher Wahrscheinlichkeit noch enthält ja angesteuert wurde.

Genau.

[hausl]

Ich bezog mich auf interne Links (ich denke, hausl auch?), hatte ich aber nicht dazugeschrieben. Das sind eben Links im Inhaltsverzeichnis eines Artikels beziehungsweise zwischen Seiten des Projekts. Die können wir kontrollieren.

Ja und auch wieder nein.

Im Grunde war das schon der Auslöser, das die Kapitel-Anker ganz oben im Beitrag nicht mehr funktionieren, wenn man im jeweiligen Header ein Zeichen ändert und da denkt man kaum dran die jedesmal mitzuändern. Und wenn ich da weiter denke fallen auch alle externen Verlinkungen mit Kapitelanker damit flach. Dies ist bei perma-Anker-Namen nicht so schlimm, da "passiert" weder beim Kapitelanker noch bei einer externen Verlinkung nichts bei kleinen Änderungen im Header.

Natürlich gibt es immer Ausnahmen und Probleme, das Anker ganz verschwinden oder sich inhaltlich ganz ändern (Kirsche - Apfel) aber damit müssen wir leben. Alternative wäre die Anker nur 1, 2, 3 zu nennen was genauso wenig bringt weil dann externe "ältere" Verlinkungen auf Kapitel dann ev. sogar auf falsche Kaptiel laufen würden, also das gleich wieder vergessen , da ist es weit besser man landet un-ver-anktert im richtigen Artikel.

[mermshaus]

Habe gerade mal das hier laufen lassen (dauert ca. 2 Minuten):

$ linkchecker -a http://php-de.github.io/ > linkcheckerlog

Statistics:
Downloaded: 2.76MB
Robots.txt cache: 422 hits, 55 misses
Number of domains: 50
Content types: 27 image, 438 text, 0 video, 0 audio, 4 application, 0 mail and 1 other.
URL lengths: min=17, max=150, avg=53.

That's it. 470 links checked. 35 warnings found. 4 errors found.

linkchecker sollte unter Linux paketiert sein. -a heißt, dass auch Fragments/Anchors, die nicht gefunden werden, vom Programm ausgegeben werden.

Das spuckt dann haufenweise Kram aus wie etwa:

URL        `/jumpto/php-ini/#kollision-von-parameterangaben'
Name       `Kollision von Parameterangaben'
Parent URL http://php-de.github.io/jumpto/php-ini/, line 101, col 71
Real URL   http://php-de.github.io/jumpto/php-ini/#kollision-von-parameterangaben
Check time 43.430 seconds
D/L time   0.078 seconds
Size       5KB
Info       42 URLs parsed.
Modified   2013-12-18 12:03:15
Warning    [url-anchor-not-found] Anchor
           `kollision-von-parameterangaben' not found. Available
           anchors: `allowurlfopen', `allowurlinclude',
           `alternative-verwendung-von-superglobalen-arrays',
           `breadcrumbs', `content', `contents',
           `disableclasses', `disablefunctions', `exposephp',
           `fremdinitialiserung', `guide',
           `kollision-von-parametern', `links-zum-thema',
           `logoContainer', `magicquotesgpc', `page',
           `problematik', `registerglobals', `top',
           `verfgbarkeit'.
Result     Valid: 200 OK

:thumbsup: (Wobei ich nicht weiß, ob das auch über verschiedene URLs hinweg klappt. Hier ist der Fehler auf derselben Seite.)

Das scheint ein sehr gut ausgebautes Tool zu sein. Es gibt auch GUI-Anwendungen dafür.

PS: In der Einstellung markiert es auch Redirects (etwa http://github.com/ → https://…). Ob man da in allen Fällen was machen muss, ist aber diskutabel.

PPS: Ist klar, dass man das nicht alle paar Minuten ausführen sollte. :)

[hausl]

das kling ja fein! hm.. linkchecker, jekyll, mir scheint ich muss mir echt ein VM hier mit linux aufsetzen.. welche distribution is egal oder "muss" es diese oder jene sein? Ach ich schau mal ob es sowas auch für Win gibt :)

[mermshaus]

Mit Ubuntu kannst du nichts falsch machen. Wenn du das hier zu bedenklich findest, würde ich ansonsten zu Debian raten. Das (Ubuntu, Debian) ist aber persönliche Präferenz, die nicht wirklich auf gewichtigen Argumenten basiert. Grundsätzlich dürfte so ziemlich jede halbwegs verbreitete Distribution die Sachen paketiert haben. Ich gehe da nach dem Motto: Je verbreiteter die Distribution, desto einfacher findet man Hilfen.

Das ist übrigens ziemlich einfach aufzusetzen. ISOs kannst du auf den Homepages runterladen und dann etwa in VirtualBox tun. Wenn du mal mehr mit Linux machen willst, ist das definitiv eine coole Sache.

[hausl]

Je verbreiteter die Distribution, desto einfacher findet man Hilfen.

Seh ich auch so, ich vermute ja das ist auch der Grund warum ich bisher nur Windows "mache" ;)

VirtualBox ist hier sowieso vorhanden, derzeit aber nur mit Win XP und Vista virtualsiert, da fehlt eindeutig noch ein Linux. Danke.

[Golpha]

ich benutze entweder win 8.1 oder fedora um am repo zu arbeiten, je nachdem welches gerät ich wo grad in der hand habe wenn ich was machen will. Ubuntu ist desktop mainstream.. mir persönlich gefällt da fedora besser.

[hausl]

Also bisher arbeite ich entweder online im Editor oder in Windows (7) über den Win-Github Client. Aber was ich gesehen hab gbt es zB kein Jekyll für Windows um mal auf die schnelle lokal vor dem comitten eine fertige von jekyll geparste Vorschau zu bekommen - inkl. allen Spezialitäten... das fehlt mir zB. doch tlw. ziemlich.

Ja und das andere ist das Link Tool vom mermshaus.

Ubuntu ist desktop mainstream.. mir persönlich gefällt da fedora besser.

Ok, das ist dann vermutlich auch Geschmackssache.. mir wäre da wichtig Windows ähnlickeit damit ich mich schnellstmöglich zurecht finde und halt große community. Ich schau mal, ubuntu, debian, fedora. ok.

[Golpha]

@hausl

http://www.madhur.co.in/blog/2011/09/01/runningjekyllwindows.html Du installierst dann nur Ruby und Jekyll. easy_install brauchste nicht da wir keine pygments aktive nutzen. Falls dir der befehl jekyll build was erzählt von illegal charset änder deinen console charset auf chcp 1252 ( nötiger smart fix, da die files zwar utf-8 sind aber wir nicht redcarped nutzen sondern kramdown ).

Ich mag Fedora, ebend weil es nicht Windows ist. Ich empfehle dir Linux akzeptieren zu lernen statt sich zu wünsch das es wie Windows wär ( was es definitiv nie sein wird ) ~ okay klingt wahrscheinlich jetzt härter als ich es meine.

[hausl]

Danke, ich schau mir das nach Weihnachten (oder nach Silvester) mal an .. momentan komm ich zu gar nix.

ad Linux: Ein OS ist IMHO ein Mittel zum Zweck und je besser ich das Mittel behersche (mich damit zurechtfinde) desto schneller komme ich ans Ziel. Nicht mehr und nicht weniger meinte ich oben. Ich hab es mir bis dato noch nie ernsthaft angesehen weil es einfach nicht nötig war ... und nur damit ich es angesehen hab daher hatte ich bisher einfach nicht genug Langeweile-zeit ;)

[Golpha]

Alles klar, ich versuch mich morgen mal am Ankündigen, sofern ich an den PC komme. Euch 2 auf jeden fall schon mal frohe Weihnachten.

[hausl]

Sonst wirds halt was fürs nächste Jahr ;)
Danke - euch beiden ebenfalls frohe Weihnachten und schöne Feiertage!!

[mermshaus]

Wünsche ich auch. :)

„Ankündigen“?

Ein OS ist IMHO ein Mittel zum Zweck und je besser ich das Mittel behersche (mich damit zurechtfinde) desto schneller komme ich ans Ziel.

Ich betrachte es mittlerweile so, dass die EDV-Welt eine Linux/FLOSS-Welt ist, in der absichtlich inkompatible Betriebssysteme Sonderfälle darstellen, auch wenn sie im Desktopbereich einen Nutzeranteil von 90+ % haben.

FLOSS läuft prinzipiell auf 100 % aller Rechner. Dass sich einige Nutzer dazu entschlossen haben, defizitäre Betriebssysteme zu nutzen, auf denen man nicht so ganz easy mal curl -s http://getcomposer.org/installer | php und php composer.phar install ausführen kann, ist zum Beispiel kein Grund, derlei Sachen nicht zu verwenden.

Dass es der Hersteller deines Nischen-Betriebssystems verhindert, einfach sudo apt-get install jekyll (oder dergleichen) tippen zu können, um dir Jekyll zu installieren, ist der eigentliche Skandal. :D

[Golpha]

Windows hat durchaus sowas wie apt-get nur nicht nativ. Nennt sich Chocolatey. http://chocolatey.org/

Grad entdeckt, da gibts auch ein jekyll equivalent das die "selbe Engine" nutzen kann: http://chocolatey.org/packages/pretzel https://github.com/Code52/pretzel