Vorlage Diskussion:UploadCampaignLink
Protokoll-relativer Link
[Quelltext bearbeiten]@Elya: Ich hatte gestern bei dieser Vorlage den Protokoll-relativen Link mit einem https: versehen. Der Grund dafür ist, dass protokoll-relative Links zwei Links erzeugen (http: und https:), aber immer nur der Link mit https: verwendet wird (hier kann man die Problematik nachlesen). Nun bekam ich aber heute auf meiner Diskussionsseite einen Hinweis, dass diese Änderung einen Fehler ausgelöst hat. Ich habe den Link inzwischen sicherheitshalber wieder zurückgesetzt. Hast du als Erstellerin der Vorlage eine Idee wie man dieses Problem lösen kann?--Doktor Wu (Diskussion) 18:21, 10. Jun. 2020 (CEST)
- Hi Doktor Wu, hmmm … ist acht Jahre her und mit Sicherheit nicht völlig auf meinem Mist gewachsen, wir haben damals in WLM so einiges gebastelt und von anderen Kampagnen abgeschaut. Aber ich verstehe auch nicht so ganz das Ausgangsproblem – ein protokollrelativer Link erzeugt nicht zwei Links, sondern spielt gerade den aus, der im Kontext benötigt wird. In der Erläuterung steht ja auch nicht, dass sie entfernt werden müssen, sondern können. Wenn die Vorlage vorher keine Fehler geschmissen hat (die ich auch nicht mehr nachvollziehen kann), würde ich es vorziehen, auf die Änderung zu verzichten. Abgesehen davon meldet diese Fehlerliste ja anscheinend auch noch false positives – zuviele Unklarheiten für mich, um ein echtes Debugging zu betreiben. Liebe Lómelinde, in Aktion kannst du die Vorlage z.B. hier: Liste der Baudenkmäler im Kölner Stadtteil Dünnwald sehen, es wird eine ganze Menge an Infos über Parameter mit an den UploadWizard übergeben, aus der Liste heraus. Sie funktioniert nur eingebunden. Beste Grüße --elya (Diskussion) 20:15, 10. Jun. 2020 (CEST)
- Also um das mit den Protokoll-relativen Links nochmal klarzustellen: Es ist richtig, dass dadurch genau der Link ausgewählt wird, den man gerade braucht. Genauer gesagt, du übernimmst das Protokoll der Webseite auf der du den Link anklickst, bei Wikipedia also https. Es wird aber trotzdem der http-Link als externer Link der Seite gespeichert weil er ja theoretisch gebraucht werden könnte (also zumindest bis vor einigen Jahren). Es werden also beide Links angelegt, aber der http-Link wird nie benutzt. Es wird also ein überflüssiger Link bei jeder Verwendung der Vorlage angelegt und das betrachte ich als Fehler und möchte diesen Fehler gerne beheben. Es geht also darum herauszufinden ob es tatsächlich irgendein Problem gibt wenn der Link mit https: beginnt, oder ob das wirklich nur ein falscher Alarm war. Also wenn ich das richtig sehe, weißt du nicht (mehr) ob der Protokoll-ralative Link hier absichtlich genutzt wurde um einen Fehler, bzw. unerwünschten Effekt zu beheben?! Vielleicht schaffen wir es zusammen ja trotzdem die Vorlage so zu gestalten, dass sie ihren Zweck erfüllt und keine unnötigen Links erzeugt.--Doktor Wu (Diskussion) 20:53, 10. Jun. 2020 (CEST)
- Hilf mir bitte mal, ich versteh's immer noch nicht: wo siehst du einen zusätzlichen „gespeicherten Link“? Es wird HTML-Code mit genau einer URL gerendert. Deshalb heißt es ja „relativ“, weil der Link kontextbezogen reagiert. --elya (Diskussion) 21:16, 10. Jun. 2020 (CEST)
- Also hier habe ich dir mal alle externen Links der Seite .NET Framework herausgesucht: [1] . Wenn du jetzt die ersten beiden Einträge anschaust, dann siehst du an der zweiten Spalte, dass sich diese Einträge nur darin unterscheiden, dass in einem http: und im anderen https: steht. Im Quelltext des Artikels kannst du leicht sehen, dass dies durch einen Protokoll-relativen Link verursacht wird. Der dritte und vierte Eintrag ist auch so ein Paar und nicht das Letzte in diesem Artikel. Jede Einbindung dieser Vorlage erzeugt solch ein Paar und damit einen unnötigen Link.--Doktor Wu (Diskussion) 21:48, 10. Jun. 2020 (CEST)
- Hilf mir bitte mal, ich versteh's immer noch nicht: wo siehst du einen zusätzlichen „gespeicherten Link“? Es wird HTML-Code mit genau einer URL gerendert. Deshalb heißt es ja „relativ“, weil der Link kontextbezogen reagiert. --elya (Diskussion) 21:16, 10. Jun. 2020 (CEST)
- Also um das mit den Protokoll-relativen Links nochmal klarzustellen: Es ist richtig, dass dadurch genau der Link ausgewählt wird, den man gerade braucht. Genauer gesagt, du übernimmst das Protokoll der Webseite auf der du den Link anklickst, bei Wikipedia also https. Es wird aber trotzdem der http-Link als externer Link der Seite gespeichert weil er ja theoretisch gebraucht werden könnte (also zumindest bis vor einigen Jahren). Es werden also beide Links angelegt, aber der http-Link wird nie benutzt. Es wird also ein überflüssiger Link bei jeder Verwendung der Vorlage angelegt und das betrachte ich als Fehler und möchte diesen Fehler gerne beheben. Es geht also darum herauszufinden ob es tatsächlich irgendein Problem gibt wenn der Link mit https: beginnt, oder ob das wirklich nur ein falscher Alarm war. Also wenn ich das richtig sehe, weißt du nicht (mehr) ob der Protokoll-ralative Link hier absichtlich genutzt wurde um einen Fehler, bzw. unerwünschten Effekt zu beheben?! Vielleicht schaffen wir es zusammen ja trotzdem die Vorlage so zu gestalten, dass sie ihren Zweck erfüllt und keine unnötigen Links erzeugt.--Doktor Wu (Diskussion) 20:53, 10. Jun. 2020 (CEST)
Danke für den Link aber diese Denkmalliste würde mich (im Quelltext) schon vor Herausforderungen stellen, da zu sehen wie die Vorlage für das Bild bestückt wurde (oder dass sie überhaupt eingebunden wäre) ist auch nicht möglich. Ebensowenig ist es für Benutzer des visuellen Editors erkennbar, wie sie benutzt werden soll, und, dass sie scheinbar „nur für eine Einbindung in Vorlagen“ gedacht ist. „UploadCampaignLink“ klingt für mich nach Wahlkampf in den USA, das nur nebenbei.
{{UploadCampaignLink|size=45|campaign=wlm-de-nrw-k|id={{{Nummer_Denkmalliste|}}}|id2={{{Ortsteil|}}}|description={{{Bezeichnung|}}}, {{{Adresse|}}}|lat={{{NS|}}}|lon={{{EW|}}}}}
Ich versuche nur Fehler abzuarbeiten. Wo es mir nicht gelingt, muss ich halt beim Verursacher nachfragen. Es gibt tatsächlich in den Listen einige Seiten, die dort angezeigt werden (oder auch nicht angezeigt aber in der Zählung stehen), wo sich die Fehler nicht beheben lassen, weil die fehlerhafte Stelle nicht gefunden wird. (Liegt meist an der schieren Größe der Seiten, wie diese Wikipedia:Café/Archiv 2017 Q2 Wikipedia:Café/Archiv 2017 Q3, oder einem irgendwie eingefrohrenen Serverstand) Da habe ich es auf alle möglichen Arten versucht, sie bleiben dort.
Hier aber ist es anders, hier wird es durch die Parameter, genauer durch die Pipes in den Parametern ausgelöst, jede Einbindung, die von der Software so gelesen wird
[[Datei:Bildname.jpg|mini||hochkant|Bildlegende]] – Doppelte Pipes [[Datei:Bildname.jpg|mini||Bildlegende]] <gallery> Bildname.jpg||Bildlegende Bildname.jpg|links|Bildlegende – Bildattribute links/rechts in der Galerie </gallery>
erzeugt eine Fehlermeldung (und manchmal auch sichtbare Fehler, weil beispielsweise die Bildlegende fehlt). Es gelingt mir aber nicht das durch Maskierung oder wie normalerweise durch entfernen der überzähligen Pipes, zu beheben. Da es aber vorher problemlos funktionierte, sehe ich auch nicht, weshalb man da etwas ändern muss. Letztlich bin ich nicht die Einzige, die sich aktiv um die Behebung dieser Linterfehler kümmert und der Nächste stünde erneut vor diesem Problem und das möchte ich gern vermeiden. --Liebe Grüße, Lómelinde Diskussion 06:51, 11. Jun. 2020 (CEST)
- Erstmal vielen Dank für deine Mühe! Also ist nicht absehbar wie sich das reparieren lässt udn wir belassen es sozusagen beim kleineren Übel? Eine Frage drängt sich mir aber noch auf: Dass der Fehler entsteht ist das dieser Vorlage geschuldet, oder irgendein Fehler der Datei-Einbindung? Weil im letzteren Fall könnte das ja auch noch andere Stellen betreffen und müsste vielleicht irgendwo gemeldet werden?!--Doktor Wu (Diskussion) 08:27, 11. Jun. 2020 (CEST)
- Das kann ich nicht so genau sagen, weil ich nicht weiß wie diese Routine der Fehleranalyse aufgebaut ist. Ich weiß nur, dass überzählige Pipes zu einer doppelten Bildlegende Führen. Die Datei ist ja quasi auch eine kleine Vorlage die quasi bestimmte Attribute erkennt und umsetzt.
[[Datei:spezifischer Name einer existierenden Datei mit Suffix |(Attribute wie mini, links, rechts, hochkant, rand, rahmenlos …)| Maßangaben px |class=noviewer |alt= alternative Beschreibung |Bildlegende]]
Wenn man nun hingeht und dort durch Vorlagenparameter scheinbar zusätzliche Pipes ohne erkennbare Attributwerte erzeugt, dann wird es von der Software nicht verstanden, was sie nun machen oder anzeigen soll. So würde ich das laienhaft umschreiben, warum das nun aber ohne dieses https funktioniert und mit nicht, da bin ich überfragt. Scheinbar wird es aber ohne dann als Teil der URL erkannt während das https dies irgendwie aushebelt. Dabei wäre es für mich anders herum logischer. Erklären kann ich es nicht. --Liebe Grüße, Lómelinde Diskussion 08:43, 11. Jun. 2020 (CEST)- Ok, vielleicht habe ich irgendwann mal Muße dieses Problem nochmal anzugehen, aber fürs Erste lasse ich einfach die Finger von Links in Dateieinbindungen. Nochmal vielen Dank für deine Hilfe!--Doktor Wu (Diskussion) 10:03, 11. Jun. 2020 (CEST)
- Das kann ich nicht so genau sagen, weil ich nicht weiß wie diese Routine der Fehleranalyse aufgebaut ist. Ich weiß nur, dass überzählige Pipes zu einer doppelten Bildlegende Führen. Die Datei ist ja quasi auch eine kleine Vorlage die quasi bestimmte Attribute erkennt und umsetzt.
@Doktor Wu, Lómelinde: Ich habe bisher keinen Fehler in der Vorlage gefunden. Wenn ihr keine Einwände habt, setze ich morgen nochmal die Vorlage auf https und schaue mir den Lint-Fehler an. Vielleicht sehe ich dann etwas. Wenn mich das auch nicht weiterbringt, revertiere ich mich selber wieder. — Raymond Disk. 19:08, 13. Jun. 2020 (CEST)
- Du kannst doch einfach die Vorherversion aufrufen. Ich kann dir aufschreiben wie die Fehlermeldung aussieht.
- Fehlerhafte Dateioptionen
}}}&id={{{id
}}}&id2={{urlencode:{{{id2
}}}}}&descriptionlang={{{descriptionlang
de}}}&description={{urlencode:{{{description
}}}}}&lat={{{lat
}}}&lon={{{lon
}}}&categories={{urlencode:{{{categories
}}}}}
- Du kannst auch LintHint verwenden, dann zeigt es dir das an und an den rot markierten Stellen sind Lücken daher habe ich die gefärbt. Man sieht, dass die Pipes das Problem auslösen. Man kann aber nicht erkennen, wo oder weshalb da ein Unterschied ist. außer, dass da ein
https:
hinzukommt, der Link funktioniert auch soweit. Irgendetwas scheint aber dem Parser, oder wie das Dingen heißt, zu sagen ‚halt hier stimmt etwas nicht‘. Möglicherweise ein Fall für Phab, oder so. Ich bin mit meiner Weisheit am Ende. Fehler, die ich nicht beheben kann, machen mich unzufrieden. Ich habe noch ein paar davon. Die Meisten habe ich aber immer lösen können. Falls du also eine Lösung findest sag Bescheid, vielleicht kann ich daraus etwas lernen. Gute Nacht derweil. --Liebe Grüße, Lómelinde Diskussion 19:45, 13. Jun. 2020 (CEST)- Ich habe ebenfalls nichts dagegen - im Gegenteil ich würde es sehr begrüßen wenn du herausfinden würdest was genau hier passiert.--Doktor Wu (Diskussion) 20:36, 13. Jun. 2020 (CEST)
- @Doktor Wu, Lómelinde: Ich gebe für den Moment erstmal auf. Ich bin recht sicher, dass es sich um einen false positive-Fehler von Lint handelt, der durch Vorlagensyntax erzeugt wird. Es gibt dazu auch Task 245478 mit einem noch nicht geprüften Patch, mit dem solche Fehler künftig einfach ausgeblendet werden können. Ich lasse das https erstmal drin stehen, weil ich glaube, dass das die sauberere Lösung ist, auch wenn das den false positive-Eintrag erzeugt. Ihr könnt mich aber auch revertieren, da werde ich keinem böse sein. — Raymond Disk. 12:20, 14. Jun. 2020 (CEST)
- Ich habe ebenfalls nichts dagegen - im Gegenteil ich würde es sehr begrüßen wenn du herausfinden würdest was genau hier passiert.--Doktor Wu (Diskussion) 20:36, 13. Jun. 2020 (CEST)
Nun ja glücklich bin ich damit nicht, denn wie gesagt es kümmert eh kaum jemanden und die Behebung dieser Fehler wird einer handvoll Benutzer überlassen, teilweise wird man beschimpft und mit Kommentaren in der Art von ‚wo soll da etwas falsch sein‘ revertiert. Es erschwert die Wartung, weil man sich wieder eine Seite mehr merken muss, die in den Listen angezeigt aber nicht korrigiert werden kann. Zuletzt ist leider auch noch das schöne Tool von Firefly durch den Umzug zum Cloudserver kaputtgegangen und somit wird es immer schwieriger den Überblick zu behalten und zu sehen wo muss etwas getan werden. Aber du Raymond kennst dich doch auch mit der Software ein wenig aus, kannst du das defekte Tool nicht irgendwie wieder anschubsen, damit es sich wieder täglich aktualisiert. Das wäre wirklich eine große Hilfe. --Liebe Grüße, Lómelinde Diskussion 12:42, 14. Jun. 2020 (CEST)
- @Lómelinde: Glücklich bin ich auch nicht mit dem Fehler. Mit dem Tool kenne ich mich leider nicht aus, da müssten dann andere helfen. — Raymond Disk. 20:18, 14. Jun. 2020 (CEST)
Ich habe jetzt mal eine Trimmung eingebaut, ich hoffe so geht es auch ohne Linterfehler auszulösen. --Liebe Grüße, Lómelinde Diskussion 11:34, 27. Jun. 2020 (CEST)
Weitere ID-Parameter
[Quelltext bearbeiten]Hallo zusammen @Elya,@Raymond,@Doktor Wu, @Lómelinde tut mir leid, dass ich euch alle anpinge, aber spricht aus eurer Sicht was dagegen, die Vorlage um weitere Parameter zu erweitern. Also einen dritten oder vierten Parameter, den man der Campaign übergeben kann? Naiv wie ich bin, denke ich, dass das geht.
Hintergrund meiner Frage ist, dass ich die Denkmal-ID und Koordinaten übergeben möchte. Für die ID brauche ich den ersten Parameter, für die Koordinaten die Parameter 2 und 3. Wenn ich die normalen Koordinaten-Parameter nutze, wird das in die standardmäßigen Koordinaten im Upload Wizard gebracht und dort in den Fotostandort umgewandelt. das wäre falsch, denn aus der Denkmalliste wird der Objektstandort übergeben. Das heißt, ich muss ne zusätzliche Objektlocation Vorlage mit den Koordinaten bestücken. Und das sind ja schon zwei Parameter.
Vielen Dank für eure Antworten. -- Thomas 21:25, 12. Apr. 2024 (CEST)
- Sorry, ich habe hier lediglich mal versucht einen Fehler zu beheben. Daher kann ich das nicht beurteilen. Ich arbeite nie mit dieser Vorlage. --Liebe Grüße, Lómelinde Diskussion 06:17, 13. Apr. 2024 (CEST)
- @Lómelinde Kein Problem.
- ich hab jetzt einfach mal versucht, die vorlage anzupassen. erste tests machen keinen ärger... -- Thomas 10:33, 13. Apr. 2024 (CEST)
- Jo, prima. --Liebe Grüße, Lómelinde Diskussion 10:38, 13. Apr. 2024 (CEST)
Paraemter nur mitgeben, wenn sie gefüllt sind
[Quelltext bearbeiten]Hallo zusammen, aktuell gibt die Vorlage der Campaign folgende Werte mit
- Decription
- sprachangabe
- lat
- lon
- ID 1 bis ID4
Wenn die Parameter nicht belegt werden, gehen sie trotzdem in den Upload-Link ein und machen den Link lang - für nichts. und in großen Listen, kostet das speicher und bringt damit die Listen an Darstellungsprobleme kann jemand, der das kann (also nciht ich), die vorlage mit einer funktion versehen, die dafür sorgt, dass diese parameter nur in den link gehen, wenn sie inhalt transportieren @Hgzh, Raymond: Ich werde wohl auch einen, der von mir zugefügten parameter ID 3 und ID 4 rückbauen.
Das gitl auch für Vorlage:UploadCampaignLinkNoImage. Viele Grüße -- Thomas 17:17, 20. Apr. 2024 (CEST)
- Ich habe das mal Testweise gemacht und es funktioniert. Allerdings gibt es bei den fields Angaben das Problem, dass es dort dann, wenn es nur noch einen Wert gibt wird, dass dieser dann in der Kampagne immer in das erste Feld geschrieben wird. Sollte an einer Stelle also kein Wert für id gegeben sein, aber einer für id2, wird der Wert der für das zweite Feld vorgesehen ist in das erste Feld geschrieben. Wenn man das beim erstellen der Vorlagen und Kampagnen beachtet sollte das nicht zu Problemen führen. Im die alten Nutzungen zu schützen könnten wir die ersten beiden fields immer setzen und nur die id3 und id4 wenn leer entfernen. --GPSLeo (Diskussion) 19:29, 20. Apr. 2024 (CEST)
- Danke @GPSLeo: für die Umsetzung und deinen Vorschlag zum Umgang mit den Bestandsparametern find ich gut. viele Grüße -- Thomas 20:29, 20. Apr. 2024 (CEST)
Verlinkungen entfernen
[Quelltext bearbeiten]Die Vorlagen sammeln sich die Infos aus einzelnen den Feldern zusammen. Dort sind manchmal auch Wikilinks eingetragen, die in commons nichts bringen, weil sie kein ziel haben. z. B.
[[Wohnhaus]]
[[Schloss]]es
[[Gebäude|Wohnhaus]]
gibt es nen code, der das aus der Vorlage entfernt um
- die sonderzeichen loszuwerden (unter anderem das Pipezeichen
- die links zu verkürzen und damit speicherplatz zu sparen
- keine falschen links in commons zu erzeugen
-- Thomas 15:36, 22. Apr. 2024 (CEST)
- Ich (oder eigentlich ChatGPT) habe da mal ein Lua Modul gebaut und eingebunden, das das Problem lösen sollte. --GPSLeo (Diskussion) 20:02, 22. Apr. 2024 (CEST)
- So eine Funktion gab es bereits, siehe Wikipedia:Lua/Modul/Text bei getPlain. Kann also dadurch ersetzt werden. -- hgzh 21:17, 22. Apr. 2024 (CEST)
- Funktioniert leider nicht für Wikilinks. (Test: Link und Link2) --GPSLeo (Diskussion) 21:29, 22. Apr. 2024 (CEST)
- @GPSLeo und @Hgzh also manchmal könnte ich euch beide küssen. Danke, dass das so gut funktioniert mit euch und ihr mir immer wieder helft. Viele Grüße -- Thomas 21:59, 22. Apr. 2024 (CEST)
- Sorry, meinte ein anderes getPlain: Wikipedia:Lua/Modul/WLink.
{{#invoke:WLink|getPlain|[[Link|Link2]]}}
= Link2 -- hgzh 22:14, 22. Apr. 2024 (CEST)
- Funktioniert leider nicht für Wikilinks. (Test: Link und Link2) --GPSLeo (Diskussion) 21:29, 22. Apr. 2024 (CEST)
- So eine Funktion gab es bereits, siehe Wikipedia:Lua/Modul/Text bei getPlain. Kann also dadurch ersetzt werden. -- hgzh 21:17, 22. Apr. 2024 (CEST)