Benutzer Diskussion:J*/Archiv

Bildvorlage

Hallo J*, ich wollte dir nur mal mitteilen, was du ebenfalls tun kannst, wenn du mal wieder viel zu viel Zeit hast und däumchendrehend auf dem Sofa sitzt (denn obenstehendes wird ja keinesfalls zur längeren Beschäftigung genügen). Es geht wieder einmal um die wunderhübsche Bildvorlage, an der es immer noch - ob man es glaubt oder nicht - Verbesserungen vorzunehmen gibt. In diesem Fall liegt das Problem bei den unbequemen Doppellizenzierungen, die bei IHNEN gang und gäbe sind. Die sind nicht nur rechtlich doof, sondern auch technisch: Momentan klappt es überhaupt nicht mit diesen hübschen Icons rechts unten. Bei mehreren Lizenzen überdecken die sich nämlich einfach. Das wird schön kompliziert. Viel Spaß! ;-) --Kamelokronf 21:52, 2. Feb. 2009 (CET)

Also rechtlich finde ich Doppellizensierungen überhaupt nicht doof, immerhin darf man sich dann eine aussuchen! Das mit den Icons ist eher problematisch. Bei einer Doppellizensierung von CC/by und CC/by-nc könnte man einfach das nc-Icon weglassen, bzw. die Icons so anzeigen wie mans maximal ausreizen darf. Aber was macht man dann z.B. bei CC/by-nc-sa + CC/by-nd-sa? Entweder keine Bearbeitung oder keine kommerzielle Verwendung. Hm. Bleibt wohl nix anderes übrig, als pro Lizenz eine Icon-Zeile? Beim Basteln der Lizenz-Icons ist eine Mehrfachlizensierung schlicht-weg nicht in Betracht gezogen worden... --J* 22:04, 2. Feb. 2009 (CET)

Kleine Frage

Ich würde gerne in der Suchleiste meines Navis in das Suchfeld ein "default" einbauen (so ähnlich wie bei der Kamelopedia:Spende). Ich selber habs nicht hingekriegt und hab meinen Paten gefragt. Dieser hat mich hierher geschickt, da er meint, du könntest mir weiterhelfen. Kannst du das?--K-3000(Hbf|Kameloh!) 15:40, 4. Feb. 2009 (CET)

.*einmisch*das macht man so:

<inputbox> default=DEIN TEXT</inputbox>
und das sieht später so aus:

 

Hoffe ich konnte dir helfen;-)Der 100%-ige Profi-Beatboxer aka.Eiskamel 17:28, 4. Feb. 2009 (CET)

Im Prinzip genau so, wie Eiskamel gesagt hat, hast du ja auch schon versucht. Dummerweise geht das irgendwie nicht mit type=search2 zusammen (vielleicht zu alte Version oder keine Ahnung was). Wenn dich der zweite Button bei type=search stört, können wir den vielleicht per CSS verstecken (wenn du möchtest versuch ich's mal). Grüße --J* 17:36, 4. Feb. 2009 (CET)

Ja gerne. Den 2. Button finde ich unnötig.--K-3000(Hbf|Kameloh!) 18:19, 5. Feb. 2009 (CET)

Teaserei

Moin, ich sehe, dass du sehr fleissig bist, ich hatte da so ne Idee, kommt ein bisschen spät (aber bin erst grade online): Könnte man nicht den SG mit dem Teaser kreuzen? MMn hat jeder geteaste auch ein sg, könnte man also einn Parameter "teaser" im sg machen, dann hätte sg einmal "...schon gewusst...?" wie üblich und untendran "...schon gewusst, dass dieser Artikel einen Teaser hat?" Kameloid 15:01, 7. Feb. 2009 (CET)

Überprüfen wir die These doch mal mit dpl:

Sicher könnte man das kombinieren - meiner Meinung nach ist es getrennt intuitiver; lass mich aber auch gern vom Gegenteil überzeugen. Grüße --J* 15:17, 7. Feb. 2009 (CET)

War nur so ne Idee, damit wir nicht die Seite zustickern (auch wenns nur die Disk ist), aber es ist erschreckend und überraschend, dass solch gewaltige Themen wie "Bibel" oder "Nichts" keine sg haben... Kameloid 15:24, 7. Feb. 2009 (CET)

Im Prinzip lässt sich das ja ändern (-; --J* 16:36, 7. Feb. 2009 (CET)

Oder noch besser: Kamel:Schachtelkamel/Baustelle/Baustelle 2 und Kamel:Schachtelkamel/Baustelle/Baustelle 3 :-)...

Also der (für Kamelo-Verhältnisse) relativ druchschlagende Erfolg der schongewußtung hat mich ermutigt, auch für die gaGA-Taser eine Vorlagenlösung in Erwägun zu ziehen. Was meinste dazu? Könnte man ähnlich lösen, die choose-GaGA-Seite auf dpl umbasteln, und die Teasertexte in vorlagen packen. Würde auch den Vorlagennamensraum entlasten. Dann würde auch mal ein nciht-Schachtelkamel vielleicht den einen oder anderen Ver-Teasern... :-) -- Schachtelkamel Mach mit! 16:28, 10. Feb. 2009 (CET)

Ja, könnte die Teaserei vielleicht durchaus vereinfachen... Dafür! --J* 17:23, 10. Feb. 2009 (CET)

Rundgang

Wie siehts aus, wollen wir mal den Rundgang hier rüber holen? Die Spendenbox ist ja erstmal weg. --Kamelokronf 11:04, 10. Feb. 2009 (CET)

Ja, warum nicht. --J* 13:21, 10. Feb. 2009 (CET)

Ka-Mel-Oh!

Hallo J* WiMu meinte ich solle mich bei fragen rund um Bots an die wenden, daher, kurze frage;

Könnte bei den Monsterkarten von Ka-mel-Oh! ein Bot dashier: [1] erledigen?

Danke im voraus...--Snoopy 22:01, 10. Feb. 2009 (CET)

Grundsätzlich denke ich ja. Size, float und typ wären dann für alle gleich? Und der div um die Vorlage muss auch bei allen weggemacht werden (bzw. ist vorher da)? Und dann ich müsste wissen, welche Seiten ich abklappern muss (oder sind das einfach alle mit Kameloh2-Vorlage? - dann könnte ich es auch aus dem DPL holen) Grüße --J* 22:40, 10. Feb. 2009 (CET)

Ja, size float und typ ist überall gleich, nur der bot darf eben nur monster und keine itemkarten ändern... die monsterkarten sind genau die mit der kameloh2-vorlage... und die divs müssen bei alle Monster-Karten weggemacht werden, da sie überflüßigerweise überall sind..--Snoop kamell 23:04, 10. Feb. 2009 (CET)

Ok, kann ich in den nächsten Tagen mal angehen. Wahrscheinlich nicht vor dem Wochenende. --J* 23:05, 10. Feb. 2009 (CET)

Vielen Dank--Snoop kamell 23:07, 10. Feb. 2009 (CET)

Nochmal Nachfrage: nur im Bereich Projekt:Ka-Mel-Oh!/Karte/.... oder überall im ganzen Kameloh? --J* 00:27, 15. Feb. 2009 (CET)

Das hat sich wohl alles erledigt, dadurch das WiMu die Datenbank erstellt hat, aber wende dich bitte lieber bei technischen Fragen an WiMu...--Snoop kamell 00:31, 15. Feb. 2009 (CET)

Ok, danke! --J* 00:38, 15. Feb. 2009 (CET)

Oje

Bist du noch da? Oder hats dich völlig abgenabelt? Melde dich wenn du uns hörst! --Kamelokronf 00:03, 11. Feb. 2009 (CET)+

Sorry, mich hat's gestern vollkommen weggehauen. Da war nix mehr zu machen. Grüße --J* 14:08, 11. Feb. 2009 (CET)

Puh, du lebst noch ;-) Ähm, mit dem "klapp" in der URL das klappt (hehe) noch nicht so richtig. Allein die Links sehen anders aus, in der Test-KP wie externe und hier wie interne. --Kamelokronf 14:16, 11. Feb. 2009 (CET)

Dass die Links anders aussehen, liegt an den einigen Änderungen im Stylesheep (siehe Forum). Ich weiß auch warum das Klappding nicht geht, wollte das eigentlich noch gestern korrigieren ... sollte jetzt klappen. Grüße --J* 14:20, 11. Feb. 2009 (CET)

Ah ja, jetzt gehts. Schöööön.... :-) oder nee wie geht das bei dir (-: hihi --Kamelokronf 14:22, 11. Feb. 2009 (CET)

Noch ein Problemchen: Auf der Startseite klappt die Bildverlinkung nicht. Zum Test hab ich das Bild ganz unten nämlich auf 404 verlinkt, aber das klappt nur in einem dünnen Streifen in der Mitte des Bildes. Ist das irgendwie unkompliziert zu lösen? Danke, Kamelokronf 15:04, 12. Feb. 2009 (CET)

Ich würde sagen, da fehlt einfach der Höhe-Parameter. Ansonsten sollte man die Vorlage gar nicht verwenden, wenn es sich vermeiden lässt - dafür gibt es die linkedimage-Extension. Finde da aber auf die Schnelle die Dokumentation nicht, keine Zeit zum Suchen. Mal unter Spezial:Version schauen... --J* 17:12, 12. Feb. 2009 (CET)

sitenotice ...

Hallöle, J*

Kannst Du mir erklären, warum bei uns in der Kamelo Sachen wie {{#ifeq:{{NAMESPACE}}|blahblub|sitenotice a|sitenotice b}} in der MediaWiki:Sitenotice nicht funktionieren? Bei mir lokal geht das ... find ich doof ... --WiMu 21:30, 12. Feb. 2009 (CET)

Eigentlich sollte das. Meine ich auch schon mal gemacht zu haben... Was tut es denn stattdessen? --J* 21:45, 12. Feb. 2009 (CET)

ignoriert einfach das {{#ifeq: und zeigt die sitenotice an, als ob nichts wäre ... vielleicht war ich auch einfach zu ungeduldig, dauert ja auch eine halbe Ewigkeit, bis Wiki sich aus den <choose>-<options> was neues aussucht ... --WiMu 21:47, 12. Feb. 2009 (CET)

Merkwürdig... ich probiers gerade mal... --J* 22:17, 12. Feb. 2009 (CET)

Im Kameloh-Namespace passieren merkwürdige Dinge - ich seh da nicht mal den Titel. Ist das Absicht? Steht da irgendwas im Monobook.css? Vielleicht spielt da irgendwas ungünstig zusammen? --J* 22:36, 12. Feb. 2009 (CET)

ja, ich hab' in einem Anfall von wasweißichwas den Seitentitel per css rausgeschissen (inkl. sitenotice) ... letzteres aber wieder rückgängig gemacht ... --WiMu 22:40, 12. Feb. 2009 (CET)

MediaWiki-Systemtexte missbrauchen ...

Mist!

Bei mir lokal geht das. Damit hätte man eine sooo einfache Möglichkeit, Parameter an eine Seite per link zu übergeben ... (bei mir zu hause habe ich es geschafft, ohne javascript eine bestimmte Karte aus der Datenbank "anzulinken") Meinst du, das liegt an der Wiki-Version? Egal ... ich will endlich ein upgrade haben! --WiMu 15:09, 16. Feb. 2009 (CET)

Also so funzt das bei mir lokal (hoffe, du erkennst was):

Natürlich fehlen mir die 74174 Bilder, drum sieht das etwas daneben aus. Aber im Prinzip wird in MediaWiki:Nosuchsectiontext die (falsche) sectionnummer ($1) in die Vorlage:Karte gestopft (natürlich nur, wenn der Seitentitel passt) ... ganz mit ohne javascript. Und schwubs hätte man ein komplettes Sammelalbum auf einer einzigen Seite, durch das man scih von vorne bis hinten durchklicken kann ...

Warum geht das hier nicht? *buhuhuhu* Irgendeine Idee? --WiMu 16:24, 16. Feb. 2009 (CET)

Antwort hier ... enttäuschend, ich weiß --J* 21:00, 16. Feb. 2009 (CET)

Ka-Mel-Oh!

Moin,

ich hab' irgendwo was Ka-Mel-Oh!iges von dir gesehen und ein paar Hinweise auf javascript-Gedöhnse ... *freufreufreu* Ich würde aber folgendes Vorschlagen: wenn wir ein echtes MMPBRG (oder so) daraus machen wollten, ginge das so oder so nur mit server-Zugriff, weil wegen Echtzeit und Krams und nicht ohne php. Das einzige, was sich derzeit mit unseren Mitteln programmieren ließe, wäre doch ausschließlich das Frontend (also eine Art graphischer Benutzeroberfläche); und evtl. eine Art rudimentärer KI, gegen die man dann antreten könnte ... oder irre ich mich da? Nunja, egal. Ich hätte ein paar Ideen, wie wir uns Schritt für Schritt an ein spielbares browser-game herantasten könnten, z.B.:

• wir bauen ein Tutorial, mit dem einige festgelegte Spielzüge gespielt werden können als Veranschaulichung der Spielregeln.
• wir bauen ein paar Minigames (z.B. ein Memory aus Ka-Mel-Oh!-Karten; ein Quiz, usw.), so dass wir eben nach und nach die nötigen functions zusammenhufen
• wir sprechen uns demnächst (evtl. heute abend im chat?) mal ab ...

Nur so Ideen, der Kommunikation wegen ...

Grüße,

--WiMu 16:17, 21. Feb. 2009 (CET)

Ich bin gerade dabei, Schritt für Schritt ein Javascript-Framework für Ka-Mel-Oh aufzubauen. Falls irgendwann alles so klappt, wie ich es gerne hätte wäre folgendes möglich:

• das von dir gerade vorgeschlagene Tutorial mit Mini-KI
• ein zwei-Spieler-Modus ohne Echtzeit: Spieler 1 macht seinen Zug, speichert. Spieler 2 macht seinen Zug, speichert. Spieler 1 ... usw. (halb javascript, halb wiki-basiert).

Ich habe nicht die geringste Ahnung, ob das realisierbar ist, mach dir erstmal nicht zu große Hoffnungen... Was bis jetzt schon da ist:

• eine Erweiterung für Arrays, mit der man aus den 120 Karten auf dem Spielfeld bestimmte herausfiltern kann (ist hoffentlich nicht zu rechenintensiv)
• einen noch sehr groben Implementierungsrahmen für Kartenklassen (also alle Karten der selben Kartennummer) und Karteninstanzen (einzelne Karten), da muss noch viel gemacht werden
• eine Struktur, mit der man asychrone Vorgänge anständig bearbeiten kann (ajax oder Benutzereingaben abwarten - das geht nämlich mit normalen Funktionen nicht)
• ein wiki-Objekt, mit dem man (bei möglichst geringer Datenübertragung) Wikiseiten abrufen kann (als Quelltext oder HTML) oder belibigen Wikitext parsen kann (was noch fehlt ist ein Cache um Wartezeiten zu verringern)

Damit das wirklich funktionieren kann und dabei nicht mega-unübersichtlich und fehleranfällig wird, muss dieses mal wirklich das komplette Javascript-Repertoire raus: Klassen, Vererbung, Prototype-Library ... Mehr später im Chat! --J* 19:24, 21. Feb. 2009 (CET)

Serverpriester

Moin, J*

magst du nicht doch vielleicht Teules Serverpriester-Stelle übernehmen? Ist wirklich frustrierend, dass hier etliches nicht so funzt, wie es funzen könnte. Nicht nur Ka-Mel-Oh!, sondern beispielsweise auch die Bildersuche könnte viel einfacher und besser gehen, wenn wir eine aktuelle MediaWiki und evtl. ein bis zwei zusätzliche Extensions hätten ... Überleg's dir doch mal ...

Grüße,

--WiMu 09:43, 25. Feb. 2009 (CET)

Ok, ich schlaf noch mal drüber --J* 11:20, 25. Feb. 2009 (CET)

P.S.: was anderes: mir ist neulich was eingefallen. Das, was am Ka-Mel-Oh!-Projekt wohl den meisten Ärger verursachen würde, wenn wir ein Mann-Gegen-Mann-Echtzeit-Browsergame-per-Wiki-Edit daraus machten wäre wohl die Verseuchung der Letzten Änderungen mit 100erten von Spielzügen. Aber evtl. könnte man das Seiten-Editieren ja auch per bot erledigen und da bots in den letzten Änderungen nicht auftauchen, würde die Herde da gar nix von mitbekommen. Mal grübeln ... --WiMu 09:50, 25. Feb. 2009 (CET)

Aalso: In jedem Falle macht immer der die Edits, der die Edits macht - also mit Botflag ist da nix (und das lässt sich auch nicht ändern). Nach aktueller Planung wäre das auch nicht Echtzeit - eher so ähnlich wie in Projekt:Schach. Ob eine Echtzeitvariante auch möglich ist: keine Ahnung. Das müsste dann vermutlich als Wiki-Extension mit PHP geschrieben werden bzw. zumindest ein Teilstück davon - und dann, wie du gesagt hast, ohne Wiki-Edits (höchstens zwischenspeichern + Spielergebnis abspeichern). --J* 11:20, 25. Feb. 2009 (CET)

Noch was: die Entscheidung, wie man's am Ende machen will, muss vorher fallen, da sie wesentliche Teile der Programmierung betrifft. Argumente für und wider:

Pro PHP (nur noch die Benutzerumgebung in Javascript):

• Spiel in Echtzeit (dafür geht aber vermutlich zeitverzögertes Spiel nicht)
• direkter Zugriff auf die SQL-Datenbanken, falls nötig
• Serverseitiges Script, es kann nicht mittels Firebug und co. geschummelt werden.
• Eigentlich geeignetere Programmiersprache als Javascript

Contra PHP (nur Javascript)

• Zeitverzögertes Spiel per Wikiedits (keine Echtzeit)
• Alle Spielfunktionen können von Programmierkamelen geändert werden:
  • Karten können einfach ergänzt werden
  • Regelwerk kann verändert werden
• Fehler in der Programmierung legen die Hamster nicht lahm und Wiki kann munter weiter machen*
• MediaWiki-Updates verursachen vermutlich keine Bugs und definitiv keine Probleme im gesamten Wiki*
• Zugriff auf SQL-Datenbanken ist nicht zwingend nötig, Zugriff auf Wikiseiten reicht

* Diese Probleme könnte man auch bei PHP vermeiden, indem man das Spiel nicht als MediaWiki-Extension sondern als extra-Seite betreibt (so wie JANNiS das vorhatte). Nachteil: Zugriff auf Karten, Bilder, Werte usw. ist umständlich + wirklich alles muss von Hand übernommen werden...

--J* 11:40, 25. Feb. 2009 (CET)

hm ... ginge nicht ein Kompromiss zwischen beidem? Also so viel wie möglich per MediaWiki und so viel wie nötig per php? Quasi Karten-Datenbank, Karten anlegen, Frontend (Javascript), Regeln usw. in der Kamelo anlegen und dann per php auslesen, um damit eine Spezialseite (o.ä.) zu befüllen, auf der man dann in Echtzeit spielen kann (apropos Echtzeit: das Spiel ist ja schon im Wesentlichen runden-basiert, es muss ja "nur" beim einen Kamel ankommen, wann das andere Kamel seinen Zug gemacht hat ...) ... alles nicht so einfach --WiMu 11:47, 25. Feb. 2009 (CET)

P.S. Es gibt auch eine SecurePHP-Extension ... aber lieber nicht ... --WiMu 11:48, 25. Feb. 2009 (CET)

P.P.S. Aber vielleicht könnte man die in der Test-Kamelo einbauen zum entwickeln, und dann die scripte per FTP (oder wie geht das?) in die echte Kamelo rüberschaufen, sobald sie laufen ... --WiMu 11:50, 25. Feb. 2009 (CET)

Wenn man PHP benutzt, dann ist das Javascript nur noch für die grafische Oberfläche zuständig, alles andere macht die Sache viel zu kompliziert. Und rein von der Programmierlogik gehört Kartendatenbank und Regelwerk eigentlich auf die Serverseite. Aber da ließe sich wohl ein Assistentenbasierter Dialog machen, mit dem man Karten und Werte verwalten kann. Einzig die Spezialfähigkeiten, Items, Fusionen usw. machen mir da Kopfzerbrechen... Ich würde da gerne nochmal mit dir in "Echtzeit" drüber nachsinnen. Treffen wir uns im Chat? --J* 15:38, 25. Feb. 2009 (CET)

Hi, ich bin gerade auf Arbeit und kann deswegen nicht chatten :-( Ich melde mich, wenn ich wieder zuhause bin. Ginge evtl. was in Richtung xml für die items und Spazialfähigkeiten? So in etwa

<Conditions>
	<ArenaCondition 
		OwnCard="1" 
				/>
	<RandomCondition 
		Würfel="1" 
				/>
</Conditions>
<Actions>
na halt die Spezialfähigkeit usw.

Arrrggghs ... Chef kommt ... --WiMu 15:54, 25. Feb. 2009 (CET)

Konfig per XML statt assistent? Verdammt gute idee. Heißt nur trotzdem, dass man im Prinzip eine Mini-Programmiersprache schreiben muss... Aber so könnte das schonmal gehen. --J* 15:57, 25. Feb. 2009 (CET)

okay

okay ich werde mein bestes geben herr jott^^ :-D

Einspruch

Rücktrittsgesuch wird abgelehnt, es gibt Kamele, die können nicht ersetzt werden. Außerdem wurde die Kündigungsfrist nicht eingehalten, überhaupt wo ist die schriftliche Kündigung, da wirst du wohl noch bei uns bleiben müssen. --Da bin ich! 23:03, 2. Mär. 2009 (CET)

Wollte auch gar niemanden zurücktreten. Nur etwas zu früh auf "Speichern". Genau das wollte ich eigentlich nicht schreiben. Trotzdem vielen Dank für die Bearbeitung des Antrags (-; So schnell habt ihr vor mir keine Ruhe! --J* 23:08, 2. Mär. 2009 (CET)

Da bin ich aber froh. *erleichtert aufatmet* --Da bin ich! 23:14, 2. Mär. 2009 (CET)

Tschüss

Tschüssi... ich kanns dir wahrlich nicht verdenken. --Kamelokronf 23:05, 2. Mär. 2009 (CET)

Aaaah... Bearbeitungkonflikt!! Das hat man davon wenn man bei sowas zu früh auf Speichern drückt! --J* 23:08, 2. Mär. 2009 (CET)

Ok, jetz hab ichs kapiert. Gratuliere... mir selbst zu meiner Auffassungsgabe. --Kamelokronf 23:11, 2. Mär. 2009 (CET)

Ich kann doch die Herde nicht einfach so alleine lassen! Apropos alleine - was machen wir eigentlich mit dem Bürokratenspiel? --J* 23:17, 2. Mär. 2009 (CET)

Da wir keine neuen Spieler anwerben konnten, scheint mir als einzige Möglichkeit eine Doppelbesetzung, d.h. einer vertritt zwei Ämter... oder aber wir beschließen noch was mit unserem Delegationskomplott. --Kamelokronf 23:19, 2. Mär. 2009 (CET)

Ha! Ich wusste, dass ich das hinkriege ...

... guckst du: http://test.kamelopedia.mormo.org/index.php/Kamelopedia:Spielw%C3%BCste ist sehr sehr quick and dirty, aber es funzt ... Karten x bis y als {{Karten|x|y}} (später dann mal als {{Karten|x - y}} und vorher testen, ob das auch Zahlen sind und so). Und wie hätte man das mit Bachstuben machen sollen? Grüße, --WiMu 01:22, 3. Mär. 2009 (CET)

Das bekommen wir doch auch noch mit Buchstaben hin! Bis jetzt haben wir immer noch alles irgendwie hinbekommen! Weiß zwar noch nicht wie, aber ... --J* 14:28, 3. Mär. 2009 (CET)

und wie sieht's mit größer oder kleiner aus? Bei Zahlen funtioniert irgendwas in der Richtung

^((\d?)|(([-+]?\d+\.?\d*)|([-+]?\d*\.?\d+))|(([-+]?\d+\.?\d*\,\ ?)*([-+]?\d+\.?\d*))|(([-+]?\d*\.?\d+\,\ ?)*([-+]?\d*\.?\d+))|(([-+]?\d+\.?\d*\,\ ?)*([-+]?\d*\.?\d+))|(([-+]?\d*\.?\d+\,\ ?)*([-+]?\d+\.?\d*)))$

(das hab' ich jetzt abgeguckt und noch nicht ausprobiert *g*) ... lass das mal mit Buchstaben, ist so gut, wie es ist und ich bin echt erstaunt, wie schnell das ganze läuft ... --WiMu 16:06, 3. Mär. 2009 (CET)

Dromebot

Master meinte, Dromi sollte eine !offline-Funktion bekommen... das wäre vielleicht wirklich nicht schlecht, zusätzlich? --Kamelokronf 19:29, 3. Mär. 2009 (CET)

Spricht nix dagegen - aber dann auch wieder nur für den eigenen Namen!

Na klar. --Kamelokronf 19:33, 3. Mär. 2009 (CET)

Dromebot wird schmerzlich vermisst! Der Chat ist so leer ohne ihn. Man hat keinen zum ärgern, wenn man alleine ist. :-( --c.w. 11:39, 19. Jan. 2010 (NNZ)

Ja, ich vermisse Dromi auch. Falls Dromi nicht von alleine aus dem Urlaub zurückkommt, werd ich mal versuchen, ihn mit Schokolade anzulocken. --J* 13:16, 19. Jan. 2010 (NNZ)

Seine letzte Äußerung war, dass er mit Wiki nicht mehr reden will. (Who the fuck is Wiki?) --c.w. 17:37, 19. Jan. 2010 (NNZ)

Frage

Kannst du mal schauen ob das so im Sinne von Kamelopedie ist? das da > > Dort und > DORT und > DORT - - Luzifers Freund 16:17, 4. Mär. 2009 (CET)

Ich habe DORT noch kleine Änderungen vorgenommen - ich hoffe das ist ok so. Das Recht am eigenen Bild habe ich in einen eigenen Absatz verpackt, da eben ein Bild das z.B. unter CC-by gestellt ist und die Vorlage:Bild/Person verwendet noch nicht automatisch erlaubt sein muss (z.B. wenn die Quelle unklar ist). Im MediaWiki-Namensraum hab ich auch noch ein klein wenig gebastelt. Bei Nichtgefallen rückgängig machen! --J* 17:42, 4. Mär. 2009 (CET)

Gefällt mir. Bin dann erstmal für eine Woche weg. - - Luzifers Freund 17:50, 4. Mär. 2009 (CET)

Ich hätte da auch eine Frage ... habe irgendwo mal gelesen, dass <div> oder <span> oder sonstwas #IDs im Gegensatz zu .clases bei validem HTML nur einmal vergeben werden dürfen sollen – ich glaube, du hättest mal sowas erwähnt. Nu is mir bei meinem Server Error gerade aufgefallen, dass die Vorlage:USERNAME mehrfach hintereinander eingebunden werden kann, obwohl die immer <span id="insertusername"> macht. Kriege weder vom firebug- noch von WebDeveloper AddOn noch nicht mal einen Hinweis, geschweige denn eine Warnung und erst Recht keinen Fehler (meckern tut's nur über den doofen IEAlphafilter, der irgendwo im monobook.css oder so rumhängt). Könntest du mich mal aufklären, weil ich brech mir bei meinen scripten immer eins ab mit for (var i = 0; i <= getElementsByTagName("blahblubb").length; i++) getElementsByTagName("blahblubb")[i]{ ... Könnte ich mir dann doch sparen und stattdessen getElementById nehmen, oder? Würde einiges erleichtern.

Grüße, --WiMu 19:56, 6. Mär. 2009 (CET)

Gut dass du das gerade ansprichst, das mit id="insertusername" ist nämlich schlichtweg Pfusch und funktioniert auch nur weil -- aber mal schön der Reihe nach:

1. Tatsächlich darf ein id-Attribut nur einmal pro Dokument mit dem selben Wert vergeben werden. id ist, im Gegensatz zum class-Attribut als Referenz auf ein ganz bestimmtes Element gedacht.
2. HTML spuckt keine Syntaxfehler aus. Ganz egal was du schreibst (und wenns noch so gegen die Spezifikationen ist), der Browser versucht das Beste draus zu machen und intern irgendwie in sauberes HTML umzuwandeln. Und irgendwas wird dann auch angezeigt.
3. Da es eigentlich nur 1x eine bestimmte id geben kann, ist auch nicht spezifiziert, wie ein Browser auf die mehrfache Vergebung reagiert (glaube ich zumindest - und selbst wenn: was bedeuten dem IE z.B. schon Spezifikationen?)
4. Die Funktion getElementById referenziert, wie der Name schon sagt, nur 1 einziges Element (sonst hieße es getElementsById). Wenn ich im Firebug document.getElementById("bla").innerHTML="asdf"; eingebe, wird nur das erste bla-Element bearbeitet.
5. Warum funktioniert dann aber die Vorlage? Weil die - so wie wir sonst bei class - alle einzeln mit for durchprüft! Sollte man mal auf class umstellen, da es einige Browser geben könnte, die das zweite id=... komplett ignorieren.
6. Lösung? Wie bereits an anderer Stelle gesagt, sollte man die Kamelopedia-Javascripts mal auf den neusten Stand bringen: Objektorientierte Programmierung usw. Und an dieser Stelle könnte man dann auch ein getElementsByClassName für alle HTML einbinden (per Vererbung), dass dann einen Array zurückgibt, der dann leichter durchge-for-t werden könnte (oder bei Verwendung der Prototype-Library auch mit array.each( function(e) { e.innerHTML = } ) ).

Bitteschön! Noch kurz zu deinem Scriptschnipsel oben: du solltest lieber < anstatt <= nehmen - Zugriffe auf nicht vorhandene Elemente eines Arrays geben nur Fehler Grüße --J* 21:02, 6. Mär. 2009 (CET)

Danke für die schnelle Antwort ... hab' das inzwüschen auch schon selbst gemerkelt http://test.kamelopedia.mormo.org/index.php/Kamel:WiMu/monobook.js *schnüf* dann halt was in Richtung getElementsByClass selber bauen (wieso gibbet das eingentlich nicht ... braucht man doch andauernd und viel öfterer als byName, byTagName, usw.) --WiMu 21:13, 6. Mär. 2009 (CET)

securePHP

'nabend, J*

Mir ist da gerade was durch den Kopf gegangen ... also das doofe an securePHP ist doch, dass ein winziger Syntax-Fehler mal eben die gesamte Kamelo lahmlegen könnte, und da die php scripte hier als wiki-Seiten editiert würden, könnte man die - da ja die Kamelo lahmgelegt ist - auch nicht so ohne weiteres wieder korrigieren (müsste dazu manuell an die WikiDB, oder?). Die Alternative wäre aber, dass du ganz alleine bei dir zuhause im stillen Kämmerlein an Sachen schraubst, und die sobald sie fertig sind als Extension in die localsettings schreibst (und das - zumindest was die Kamelo betrifft - ungetestet).
Das ist beides ziemlich suboptimal. Aber könnte man das securePHP nicht so konfigurieren, dass Kameltreiber (weil das läuft ja nur auf gesperrten Seiten), die scripte hier bei uns bearbeiten können, die dann aber in der Test-Kamelo (und nur dort) laufen? Das hätte den Vorteil, dass man mit mehreren Leuten dran arbeiten könnte, eine vernünftige Versionshistorie hätte, im schlimmsten Fall die Test-Kamelo kaputt macht (und dann per rückgängig-machen wieder zum laufen kriegt), jedes Otto Normalkamel die Seiten begutachten könnte und das ganze mehr oder weniger im Life-Betrieb testen kann ... Und wenn alles funktioniert, macht man 'ne Extension draus, die in regelmäßigen Abständen upgedated wird.

Nur so ein Gedanke. Grüße, --WiMu 22:04, 8. Mär. 2009 (CET)

Aalso... eigentlich dürfte das securePHP nicht die ganze kp lahmlegen... aber wenn wir irgendwo ne Endlosschleife drin haben und zu viele Leute das Fehlerhafte script aufrufen, dann ist der Server erstmal für ne weile dicht. Problematischer ist eigentlich, dass jeder der php ausführen darf, mit dem Server anstellen kann, was er will (und wo php Rechte drauf hat). Inklusive Löschung sämtlicher Wiki-Datenbanken (falls die Wiki-Objekte für securePHP zugänglich sind, und wenn nicht, hat das eh wenig sinn für Ka-Mel-Oh), Krams auf dem Server, Spamversand über den Server, ... Irgendwie behagt mir das nicht ganz so, auch wenn es schreibgeschützt sein muss ... --J* 22:30, 8. Mär. 2009 (CET)

OK, war ja nur so ein Gedanke ich habe bis jetzt eigentlich jedesmal mein privates Testwiki lahmgelegt, wenn ich versucht habe, irgendwas in php zu schreiben, was über die Installation von Extensions hinausgeht ... --WiMu 23:25, 8. Mär. 2009 (CET)

Wenn man wirklich die Kamelopedia um eine extension erweitern will, dann schlage ich eher folgendes vor:

• Entwicklungsebene 1: Es wird auf localhost, also im privaten Testwiki geschraubt. Sobald irgend ein Kleinteil funktioniert oder wenn man aufhört zu basteln, dann wird das in ein zentrales Git-Repo hochgeladen. Jeder der ein privates Testwiki + git laufen hat kann dann den aktuellen Stand bei sich testen, Änderungen machen + hochladen. Und eventuell wären die Sourcen auch über ein Webinterface sichtbar/abrufbar (das müsste man sehen).
• Entwicklungsebene 2: Sobald das Ding halbwegs stabil läuft (keine Syntaxfehler, macht was es soll), wird die Test-Kamelo damit infiziert und das Teil wird ausgiebig getestet.
• Entwicklungsebene 3: Und wenn da dann alles OK ist, und erst dann, kommt das ganze in die richtige Kamelo.

Damit hätte man dann eine mehrstufige Lösung, die zunächst im stillen kämmerlein beginnt, wo aber trotzdem jeder mitschrauben kann (allerdings mit dem Aufwand ein Testwiki und Git installieren zu müssen), dann öffentliche Beta und schließlich final Release.

Wie wäre das so irgendwie? --J* 08:58, 9. Mär. 2009 (CET)

klingt doch ganz gut; hab' nur mit git noch keine Erfahrung ... aber das wird schonnoch. bevor wir das Ding allerdings in die Test-Kamelo stellen können (und erst Recht dann später in die Kamelo), muss irgenwer *zwinkerzwinker* mal bei JeLuF anklopfen und sich um die vakante Stelle des Serverpriesters bewerben ... --WiMu 10:40, 9. Mär. 2009 (CET)

 Besuche bitte auch:  Kamel Diskussion:Kameloid! :-) grüße Schachtel

Zusammenfassung soll ich angeben... das ist also meine Zusammenfassung.

Öh... langsam sollte doch allgemein bekannt sein, dass ich manchmal etwas schwer von Begriff bin (-; Es geht um die Teaser-Geschichte? Wenn ich das richtig sehe, müsste man da doch nur noch das DPL ummodeln, oder? --J* 21:07, 13. Mär. 2009 (CET)

Genau! :-) Ich wollte nur zart anklingen lassen, daß ich nicht unfroh wäre, wenn ein Deppl-Auskenner das mal eben hinbiegen würde... Ich krieg das allerdings auch hin, war nur heut mittag etwas akut faul nach meiner neuverteasungsorgie... -- Schachtelkamel Mach mit! 23:30, 13. Mär. 2009 (CET)

Eier

 Vergleiche: Dein Ei mit meinem... Also ich find meins viiiel schöner... :-) aber ist ne schöne Idee wieder mal, vielleicht macht ja der ein oder andere mit. Übrigens... Äh... vielleicht könntest du mir bei dieser Gelegenheit mal sagen, was da mit meinem Zeichnsatz nicht stimmt? War mir immer etwas zu peinlich/bzw. unwichtig zum Fragen... hab nen neuen Rechner seit einiger Zeit und seitdem unfunz. -- Schachtelkamel Mach mit! 01:16, 15. Mär. 2009 (CET)

Hm... bei mir ists genau andersherum. Dein Browser zeigt nicht nur die schönen Sternchen, die ich verwendet habe, nicht vernünftig an, er macht die Kästchen, die er stattdessen benutzt, auch noch ein ganz klein wenig breiter als die restlichen Buchstaben - und verhaut damit das ganze Layout. Menno. Hab jetzt erstmal normale Sternchen rein. Ist nicht ganz so hübsch, dafür funktionierts dann hoffentlich auch überall! Grüße und Danke für den Hinweis! --J* 19:12, 15. Mär. 2009 (CET)

Please help!

Ich bastle an einer Radarwiki herum und suche nach einer Lösung, wie ein im CSS vordefinierter Link mit Bildchen abgedunkelt werden kann, wenn das Ziel ein noch roter Link ist. (so ungefähr wie das Beispiel in der statischen Version). Kannst du mir helfen? --c.w. 12:57, 15. Mär. 2009 (CET)

*einmisch* Hallo, c.w. Das blöde an css ist, dass man damit nur Hintergrundbilder einbauen, also keine Halbtransparenten Bilder drüberlegen kann. Du müsstest also für alle deine Flaggen zwei Bilder haben, einmal abgedunkelt und einmal normal, und dann für alle deine IDs de, en, etc. einmal #de { background-image:url ... } und einmal a.new #de { background-image:url ... } definieren. Eine quick and dirty Lösung ist das da:

a.new img {
    filter:progid:DXImageTransform.Microsoft.Alpha(opacity=50);
    -moz-opacity: 0.5;
    opacity: 0.5;
    }

das macht die Flaggen semi-transparent, wenn sie zu einer nicht-existeten Seite führen (müsste zumindest). Ein Schönheitsfehler ist der doofe Microsoft-IE-filter, der ist nicht standardkonform (wenn es dir darauf ankommt).

Grüße, --Meister WiMu 14:15, 15. Mär. 2009 (CET)

Ach, so war das gemeint.
Übrigens ist nicht nur der IE-Filter nicht standardkonform, sondern auch "moz-opacity". Die standardkonforme Repräsentation ist das "opacity", allerdings ist das CSS3 und wird auch noch von vielen Browsern nicht anständig umgesetzt.
Du hast zwar nach einer CSS-Lösung gefragt, aber vielleicht hilft dir ja auch folgende Lösung mit den Parserfunctions und jeweils einer hellen und dunklen hochgeladenen Bildversion weiter:

{{#ifexist: Linkziel | Code mit hellem Bild | Code mit abgedunkeltem Bild}}

Das geht dann auch garantiert in jedem Browser. --J* 14:37, 15. Mär. 2009 (CET)

Juhuu! die reine CSS-Lösung mit zwei Bildern funktioniert. Das war für mich am einfachsten. Ich danke den beiden großen Meistern. Jetzt muss ich bloß noch das blöde <math></math> hinkriegen, dann kann die Radarwiki scharf ins Netz. Ich muss mir jetzt wohl jemanden suchen, der den beigelegten Quältext von Mediawiki meinem Provider-Server gemäß compilieren kann. Meine Windoof-Blechdeppen sind dazu alle zu blöd. (Ich wohl auch… :-( --c.w. 18:28, 15. Mär. 2009 (CET) )

Glossar mal nachgefragt

Hallo J*, habe gesehen, dass Du Dich mal am Glossar vergriffen hast (löblich), da kam mir mal wieder eine alte Debatte darum in den Sinn. Hatten wir nicht irgendwann schon mal die Idee das ganze Glossar zum Projekt zu machen bzw. die gesamten Unterbegriffe systematisiert eine Ebene tieferzulegen und das Glossar automatisch zu generieren? Glossareinträge könnten dann stets mit einer Vorlage als Unterartikel (sehr strukturiert) erzeugt werden. So könnte man kurze Artikel schneller verschieben oder wenn ein Begriff aus dem Glossar wächst es einfach in den Namensraum schieben und den Glossarbaustein rausnehmen … und schon ist er weider Artikel. Jeder Begriff hätte dann seine eigene Legende (History). Wie schon gesagt ich habe den genauen Faden nicht mehr im Kopf, aber wäre das langfristig eine Überlegung wert? Ich wäre dafür, wenngleich ich wohl die Progrmmirrung dafür nicht hinbekäme … na Du ahnst ja schon wieder worauf das hinausläuft? *g* WiKa 19:21, 23. Mär. 2009 (CET)

Wenn ich mich recht entsinne, war da noch die Idee, das dann als Kamelionary zu organisieren. Oder war das was anderes? Ich denk da grade mal laut weiter:

Glossar

• Jeder Glossareintrag bekäme dann also eine eigene Artikel- und Diskussionsseite unter Projekt:Glossar (oder noch besser: im Glossar-Namespace - den man dann allerdings erst noch einrichten (lassen) müsste)
• Ansicht der Einträge zentral im Glossar - würde per DPL zusammengefrickelt werden; damit es da nicht unübersichtlich wird und man jeden Eintrag von dort aus bearbeiten kann:
  • Je Eintrag ein Bearbeitungslink?
  • Eine Neuen-Eintrag-Erstellen-Box?
• Glossareinträge als Kamelionary ist doppelt gemoppelt und hat mal irgendwie gar nix (es sei denn, es soll den Glossar gar nicht mehr geben)
• Frage: Wollen wir wirklich so viele Einzelseiten haben?

Kamelionary

• Kamelionary lieber stattdessen oder parallel (im zweiten Fall könnte man dann auch zwischen Kamelionary- und Glossar-Namespace hin- und herverschieben)
• Im Kamelionary landen Begriffsklärungen und Glossarartikel, die jeweils gut mit Abkürzungen, Synonymen, Flektionen, Gegenwörtern, Ober- und Unterbegriffen, Übersetzungen usw. aufgepeppt und verwitzt werden können (Frage: Gibt's so was? -> mal den aktuellen Glossar danach durchsuchen)

Da müsste man sich dann halt überlegen wie mans genau haben will. Dafür einen (oder zwei) eigenen Namespace einzurichten (bzw. einrichten zu lassen) würde ich aber in jedem Fall für sinnvoll halten. Grüße --J* 22:46, 23. Mär. 2009 (CET)

Wenn ich mich recht erinnere, dann war das Kamelionary als fest strukturierte Parodie auf das Wiktionary gedacht. Ich würde nicht unbedingt beides wollen, letztlich könnte man auch das Kamelionary als Glossar verkaufen, das täte nicht weh. Wie schon gesagt, beides hielte ich für zuviel. Da wir von Parodie leben, wäre das Kamelionary vielleicht doch angesagt. Ich würde es auch mit den Einzelseiten unterfüttern, dafür aber streng reglementieren, dass es keine Doppelungen um normalen Namensraum und dem Kamelionary gäbe … dass wäre kontraproduktiv. Gut wäre sicherlich ein eigener Namensraum, da müssten wir wohl mal JANNiS antickern. Vielleicht sollten wir zur endgültigen Klärung mal sehen ob wir die Diskussionsseite dafür noch wiederfinden, wo das schon mal behandelt haben. (dies war die Musterseite Kamelionary) WiKa 23:22, 23. Mär. 2009 (CET)

Die Seite ist die da. --J* 00:06, 24. Mär. 2009 (CET)

Chat

Nanu? Hier siehts ja aus... --Kamelokronf 11:04, 30. Mär. 2009 (CEST) und 08:54, 31. Mär. 2009 (CEST)

Ist mir noch gar nicht aufgefallen ... ): muss ich mir also noch was überlegen ... Übrigens: Ab jetzt gibt's wieder richtig Papierkrieg! --J* 18:00, 31. Mär. 2009 (CEST)

Pünktlich vor dem Jubiläum versagt die Technik... Dromi hat einer den Mund zugeklebt und die Protokollnavi spielt verrückt. --Kamelokronf 21:13, 4. Apr. 2009 (CEST)

werd mir ersteres grad mal ansehen (und danach zweites angehen) --J* 21:26, 4. Apr. 2009 (CEST)

So hab dromi mal neugestartet; vielleicht hatte er sich mit Wiki verquatscht? --J* 21:30, 4. Apr. 2009 (CEST)

Und die Datumsanzeige hat sich selbst wieder eingekriegt ... Hmpf! Wahrscheinlich geht's am 31. April Mai wieder los ... --J* 21:40, 4. Apr. 2009 (CEST)

Bräuchte mal dringend deine Hilfe und/oder Meinung ...

Moin J*,

ich fange gerade mit meiner Dissertation an ("Die Tonfolge B-A-C-H im 20. Jhdt." oder so ähnlich). Mich lässt die Idee nicht los, das ganze nicht bei mir lokal mit irgend einem Textverarbeitungs-Programm zu schreiben, sondern direkt per MediaWiki ins Netz zu stellen (will mir dann die Domain www.b-a-c-h.org sichern). Der Vorteil wäre einfach die Erreichbarkeit von überall mit ohne Datenträger-Rumschleppen-müssen und wäre auch ideal für's Korrekturlesen (und gleich Korrigieren inkl. Änderungshistorie) - muss dann meinen Korrektoren nicht immer was zuschicken, sondern gebe denen einfach Zugriff auf die Seite. Außerdem wäre das ganze Vorlagen- dpl- css- html- usw. Gedöhnse sehr hilfreich für mich.
In der Wikipedia gibbet seit paar Tagen eine Buchfunktion, die aus einzelnen Artikeln Kapitel eines Buches macht; wäre also eigentlich genau das richtige. Nur dummer Weise steckt die Funktion noch in den Kinderschuhen - hat noch keine Silbentrennung, Kerning, Ligaturen, etc., so dass LaTeX einfach um Längen besser aussieht. Aber ich hoffe, dass sich das in den nächsten zwei Jahren (so lange werde ich wohl mindestens brauchen) noch ändert. Ist das realistisch? Oder weißt du eine Möglichkeit, statt nach PDF oder OpenOffice zu exportieren alles als LaTeX zu rendern?
Ein anderes Problem ist genau die LaTeX-Unterstützung; ich hätte wenn dann gerne Wikitex, insbösondere Lilypond so wie da. Zum einen fürchte ich, ich kriegte dann die gleichen Schwierigkeiten mit 'nem Provider wie c.w. (bräuchte für sowas doch root-Zugriff, oder?), zum anderen übersteigt das meine Programmier-Kenntnisse um Lichtjahre (habe mal versucht, wenigstens <math> bei mir lokal zu installieren und bin kläglich gescheitert). Auch finde ich die LaTeX-Darstellung in Wikis nicht wirklich gelungen <math>\frac {weil} {96dpi}</math> ... kann man das so aufbohren, dass dadraus die für Notendruck nötigen 600dpi werden? Oder am besten gleich als PostScript oder SVG? Und last but not least: ist das totaler Dummfug und ich soll lieber wie jeder andere auch das Ding gleich in LaTeX machen? Und noch laster but leaster: wenn's nicht völlig abwegig ist ... magst du mir dann beim Installieren und Konfigurieren helfen? --WiMu 13:45, 30. Mär. 2009 (CEST)

Moin WiMu! Dröseln wir den ganzen Katalog doch mal von hinten auf: Sicher kann ich dir beim Installieren und Konfigurieren von was-auch-immer (s.u.) helfen. So, und jetzt zu den einzelnen Sachen:

• Buchfunktion: Schon möglich, dass die Extension in zwei Jahren um einiges besser ist als heute, aber ich würd mich nicht darauf verlassen, dass bis zum Tag X alles geht - es sei denn, du möchtest maßgeblich bei der Entwicklung der Extension mitwirken (zumal du vielleicht auch andere Qualitätsansprüche, auch hinsichtlich Schriftsatz usw., an deine Dissertation haben wirst als an einen WP-Artikel).
• als LaTeX rendern: Es gibt auch Extensions, die Artikel in LaTeX umwandeln - aber soweit ich weiß immer nur artikelweise. Vermutlich musst du dann das Latex noch ziemlich anpassen, bis es wirklich gut aussieht, da man bei Wikitext + HTML einfach weniger Einstellmöglichkeiten für Schriftsatz, Absätze, Gestaltung, usw. hat als bei LaTeX. Zumal werden da vermutlich sämtliche Dinge, die im Webbrowser als Bild eingebunden sind, auch als Bild angezeigt, d.h. auch <math>- und Wikitex-Viecher (was natürlich Schwachsinn ist). Für <math> gibt's inzwischen ein Patch, für Wikitex müsste man vermutlich noch eins schreiben. In jedem Falle wirst du da nach dem Umwandeln in Latex-Code noch einiges verbessern müssen.
• Wikitex: Eigentlich sollte das auch ohne root-Zugriff gehen. SSH (egal ob als root oder als anderer Benutzer) wäre aber vielleicht nicht unpraktisch.
• mit-ohne Datenträger rumschleppen: wie wäre es denn, wenn du einfach im Wiki nicht Wiki-Syntax, sondern LaTeX-Code benutzt? Die Syntax-Highlight extension ließe sich mit zwei Handgriffen so umbauen, dass sie nicht nur .js und .css-Seiten automatisch einfärbt, sondern auch z.B. .tex-Seiten (hab die Stelle schon gefunden, allerdings noch nicht getestet). Vielleicht kann man auch ein Script basteln, das (entweder vom Wiki oder per SSH aufgerufen) aus den Wikiseiten per latex da dann ein DVI oder PDF draus rendert, so dass man sich das Ergebnis ansehen kann (müsste man vorher mal sehen, ob das kompliziert ist - ansonsten muss das halt manuell gemacht werden).
• Änderungshistorie: Falls das mit Wiki gar nicht klappt, kann ich dir git empfehlen, um Versionen zwischenzuspeichern - damit alleine an einem Projekt zu arbeiten ist nicht so schwer (schwieriger wird's dann mit Bearbeitungskonflikten etc.).
• sonstiges: falls du ein Wiki einrichtest, denk dran, die Seiten (per Einstellung oder noch besser .htaccess) mit einem Passwort zu sichern - sonst ist deine Arbeit schon vor der Veröffentlichung veröffentlicht ...

So, ich hoffe ich hab nix vergessen ... Grüße --J* 21:19, 30. Mär. 2009 (CEST)

also wenn ich dich richtig verstanden habe, spricht eigentlich nix gegen das grundsätzliche Konzept Internet statt lokal *freufreufreu*. Mich hat heute einer in der Wikipedia auf den Trichter gebracht, dass man ja mit der Buchfunktion auch nach OpenOffice konvertieren kann - und das lässt sich dann noch weiterverarbeiten, z.B. mit Silbentrennung. Ich denke die Entscheidung ist gefallen (ich überlege da jetzt schon eine Woche dran rum ...) und ich mach' das jetzt einfach so. Wie genau wird sich dann zeigen. Ich frag mal meinen Prof bzw. das Rechenzentrum, ob ich Zugriff auf den Uni-server kriege, dann kostet's nix. Ansonsten dealt mein Chef nebenbei mit Domains und Krams, und dann frag ich den (nächste Woche, der ist gerade in Urlaub ... die Sau). Das mit der Veröffentlichung vor der Veröffentlichung hab' ich mir auch schon überlegt. Bin mir ziemlich sicher, dass es für sowas passende Extensions gibt. Notfalls die entsprechenden Seiten sperren und mit UserFunctions nur Sysops anzeigen lassen (doof das, aber halbwegs sicher ... Mist den Quelltext sieht man ja trotzdem ... muss ich noch recherchieren). Ich werde auch mal Kamel:Peu fragen, der wollte mit mir was in Richtung Musiktheorie-Wiki/odersonstigeinternetseite machen, wenn ich mit meinem Studium fertig bin. Denke, der hat auch reichlich Ahnung ... Grüße, --WiMu 22:37, 30. Mär. 2009 (CEST)

Über Extensions wird das nicht functionieren (Zumindest nicht wirklich sicher). Aber über LocalSettings.php:

$wgWhitelistRead = array("Special:Userlogin", "-", "MediaWiki:Monobook.css" );
$wgGroupPermissions['*']['read'] = false;

Oder eben per normalem Passwortschutz per htaccess.

Grüße --J* 22:48, 30. Mär. 2009 (CEST)

$wgWhitelistRead ← angegckt ... das genau das richtige ... :-) --WiMu 22:53, 30. Mär. 2009 (CEST)

Wird langsam mal Zeit, das in Angriff zu nehmen

Hallo, J*

ich habe mal – nach wochenlangen Recherchen – einen webhoster angeschrieben, der (angeblich) bereits viel Erfahrung mit MediaWiki und LaTeX und so hat, wegen des Projekts da oben. Die Frage ist ja immer noch, ob ich mir einen vServer mit Root-Zugriff (kostet ca. 8€/Monat für lächerliche 500mHz + 500mb Arbeitsspeicher), oder reinen webspace mit ohne root (kostet fast nix für richtig schnell) leisten soll. Nur mal so nebenbei: wenn ohne root, und ich den Anbieter davon überzeugen kann, mir das eine oder andere Programm zu installieren (v.a. LilyPond) ... Extensions kann ich doch hoffentlich in jedem Fall auch ohne root installieren, oder? Also so Sachen wie DPL und Parser-Functions und so, also reiner PHP-Krams. Hab' ja von server-Gedöhnse keine Ahnung, und ist mir peinlich (und taktisch unklug) den Anbieter sowas zu fragen ...

Grüße,

--WiMu 11:23, 26. Jun. 2009 (NNZ)

Root brauchst du nicht, aber was gehen muss ist PHP und eine SQL-Datenbank brauchst du auch. Alle zusätzlichen Programme, die nicht in PHP geschrieben sind (LaTeX, LilyPond, ...), müsste dir dann aber der Anbieter vorinstallieren, damit's klappt. Es sei denn, du möchtest einfach nur den LaTeX-Quellcode für deine Arbeit in ein Wiki schreiben und gar nicht rendern (: --J* 19:18, 26. Jun. 2009 (NNZ)

Hallo, J* Hab' jetzt das Angebot für mein eigenes Wiki. LaTeX und LilyPond wird vorinstalliert, ansonsten:

1. de Domain
250 MB Speicherplatz
1.500 MB Traffic / Monat
1 eMailpostfach
1 eMailadresse
1 mySQLDatenbank
PHP5, phython
 
Für monatlich 1.25 EUR bei jährlicher Zahlung. 

kann jederzeit up- oder downgegradet werden. Was hältst'n davon? Ist OK, oder?

P.S.: will nur lieber eine .net oder .org domain haben, das muss ich noch abklären ... --WiMu 22:18, 27. Jun. 2009 (NNZ)

Hört sich echt anständig an. Muss mal schaun, was ich eigentlich jährlich für meine Domain zahle (und das ohne Speicherplatz ...!) Sag mal, was ist das denn für ein Anbieter? Vielleicht ist das ja auch mal was für mich (: --J* 23:06, 27. Jun. 2009 (NNZ)

http://www.methfessel-computers.de/ --WiMu 11:33, 28. Jun. 2009 (NNZ)

Hallöle, J*. Das Wiki rennt jetzt unter http://www.b-a-c-h.org/wiki/ ... wenn du mitwerkeln willst, bist herzlichst eingeladen. Hilfe könnte ich gut gebrauchen. Aber falls du Lust hast, melde dich bitte möglichst schnell und (wenn's dir nix ausmacht) mit Klarnamen an (weil wegen Prüfungsamt wäre ein nick evtl. problematisch). In ein paar Tagen mach' ich das Ding dicht, nicht dass mir noch irgendwer meine Diss. schreibt *g*. Grüße, --WiMu 03:30, 4. Jul. 2009 (NNZ)

Plan Be...

mir schwebt da als Bild so eine Idee vor: ein verbeamtetes Kamel vor einem großen Abreißkalender, welches das abgerissene Kalenderblatt (mit Aktenzeichen und gestempelt) eintütet und archiviert.

Jetzt wäre schön, wenn das Bild auch den aktuellen Kalendertag anzeigen würde. Mit J*avascript sollte sowas gehen.

Muss ich jetzt (Version 1) 31 Bilder erzeugen, von denen dann täglich eines angezeigt wird, oder reicht (Plan Be...) ein leeres Kalenderblatt, und das aktuelle Datum wird als zweiter Layer darübergelegt?

Gruß, --c.w. 08:40, 8. Apr. 2009 (CEST)

An sich sollte man da ein Datum drüberlayern können --J* 09:19, 8. Apr. 2009 (CEST)

Kamelopedia:Bildsuche

Hi, J*

Was ist denn mit der Bildsuche passiert? Wo sind denn meine ganzen schönen Spielsachen (Suche nach Lizenz, Technik, usw.)? *heul* --WiMu 18:28, 16. Apr. 2009 (CEST)
P.S.: wollen wir uns in einer nicht allzu fernen Zukunft da nochmal ranwagen, die vielleicht noch ein kleines bisschen glattziehen?

Tja, da hat wohl irgendwer umkategorisiert, und dabei nicht daran gedacht, dass das eine "magische Kategorie" für die Bildsuche war. Müsste in irgendeiner DPL-Query definiert sein in irgendeiner Unterseite der Bildsuche...

Ja, die Bildsuche sollten wir mal glattziehen. Allerdings sollte man sie dann auch gleich richtig zur Hälfte neu schreiben - und nämlich auf die (inzwischen schon erfolgreich in der Zeitmaschine eingesetzte libWiki umstellen. Damit wird dann einiges deutlich einfacher und auch das wir-tun-so-als-ob-wir-die-seite-editieren fällt damit dann weg (naja, libWiki macht so was ähnliches, nur in besser). Auch das ein oder andere Extrawürstchen ließe sich damit leichter einbauen, als mit dem alten, starren (da nur genau dafür geschreibenen) Ding. Woll'n wir mal eine TODO-Liste anlegen? --J* 23:58, 16. Apr. 2009 (CEST)

Kann man das irgendwie weg machen?

Ich hab ein bisschen an meiner Seite rumgebastelt mit choose. Ich habe auch noch ne Inputbox verwendet, um einen neuen Witz zuladen. Leider kann ich aber den 2., und dazu nicht funktionierenden Button nicht wegmachen, da anders das ganze nicht funktioniert. Könntest du den irgendwie entfernen? Natürlich darfst du dafür auch die Seite bearbeiten, geht ja nicht anders :-). Hoffentlich verstehst du, was ich meine...--K-3000(Hbf|Diskette) 17:48, 23. Apr. 2009 (CEST)

So, ein Eintrag bei der Registrierungsbehörde für Kamelbau-Skins, eine neue Unterseite und etwas Kleinkram - et voilà! Bitteschön! --J* 20:28, 23. Apr. 2009 (CEST)

DPLForum

Moin, J*

Was ich an unserem Forum vermisse (was aber mit phpBB geht) ist, ob man den aktuellsten Dung zu einem Thema bereits gelesen hat oder nicht. Eigentlich müsste das mit :visited gehen, aber zumindest mein Firefox interpretiert mir das nicht :-( Evtl. könnte man da ja was scripten (kann man auslesen, ob sich die entsprechende Seite im cache befindet?). Naja, nur so ein Gedanke. Frohes Schaffen noch ... --WiMu 16:51, 24. Apr. 2009 (CEST)

Eigentlich sollte man genau das schon sehen können - wenn man's weiß: Besuchte links sind ja im ganzen Wiki etwas rötlicher als die unbesuchten (zumindest bei mir). Und das Forum linkt nicht generell auf den Artikel sondern auf die jeweils aktuelle Version -> an der Linkfarbe sollte erkennbar sein, ob man schon alles gelesen hat, oder nicht. --J* 17:01, 24. Apr. 2009 (CEST)

Ich glaube, genau das funzt in meinem Firefox aus irgendeinem Grund nicht. Ich kann das im css ja mal etwas deutlicher gestalten, als ein paar Nuancen mehr rot. Am besten gefiele mir ein entsprechendes icon (in unserem alten phpBB, dessen url ich gerade nicht finde, hab' ich das mit silbernen und goldenen Kamelen gabaut ... sah ganz schick aus) ... --WiMu 17:09, 24. Apr. 2009 (CEST)

Icon sollte machbar sein - aber eben auch nur wenn der Browser keine Zicken mit dem css macht - bei mir im Firefox geht's ... --J* 17:15, 24. Apr. 2009 (CEST)

ich probier's mal kurz mit rosa oder so, dann seh' ich gleich, ob mein Firefox oder meine Augen das Problem sind ... --WiMu 17:17, 24. Apr. 2009 (CEST)

ne, mein FF tut's definitiv nicht IE7 dagegen ohne Probleme. Vielleicht irgend eine Einstellungssache? Sowas wie cache deaktiviert, oder so? Ich mach' mich mal schlau ... --WiMu 17:23, 24. Apr. 2009 (CEST)

Moin, J*. Magst du noch eine Kat für Abstimmungen anlegen? Ideal wäre natürlich, wenn man irgendwie schon auf Forums-Hauptseite das aktuelle Ergebnis sehen würde; weiß aber selbst nicht, wie das machbar wäre, da Abstimmungen ja immer anders aussehen (Anzahl der Möglichkeiten, nur Pro oder Pro und Contra, etc.) Egal, eine Abstimmungs-Kat wäre trotzdem sinnig. Grüße, --WiMu 10:47, 27. Apr. 2009 (CEST)
P.S.: das geht in meinem FF einfach nicht weg *heul*

Kamelionary-Preload-script ...

... hab' ich mal eben gebaut. Funzt aber erstmal nur, wenn man sich enableKamelionaryPreload = true; ins monobook.js huft. Später soll's mal andersrum sein, also disableKamelionaryPreload = true;. Kannst du bitte mal drübergucken (nur function insertPreload() ... der Rest ist furchtbar, ich weiß ...)? Es funzt zwar in allen brausern, die ich auftreiben konnte, aber da ich von Ajax und so Zeug nicht die geringste Ahnung hab, wäre es vielleicht ganz gut, wenn das mal wer anschaut, der sich damit auskennt. Vor allem hab ich den Request synchron gebaut, weil's so schön einfach war ... ist aber evtl. suboptimal. Auch könnte es mit deinem Kamel:J*/lib/wiki.js eleganter gehen? Naja, guck's dir halt mal an, und wenn du's OK findest, dann modeln wir das auf disableKamelionaryPreload = true; um, damit alle was von haben. Grüße, --WiMu 15:04, 26. Apr. 2009 (CEST)

Sehe da grundsätzlich kein Problem mit. Ich weiß nur, dass von synchronen Abragen immer abgeraten wird, da der Browser solange "hängt", bis das Ergebnis da ist (und wenn, z.B. wegen Netzwerkproblemen, nix kommt, ist das vielleicht doof).

Das gleiche, fast genau so einfach, als asynchroner Request:

var getPreloadText = new Ajax.Request (
    "http://kamelopedia.net/index.php",
    {
        method:"get",
        parameters: "title=Vorlage:Kamelionary/preload&action=raw",
        onSuccess: function (trans) {
            preloadText = trans.responseText.replace(/<[\/]?pre>/g, "");
            document.getElementById("wpTextbox1").value = preloadText;
        }
    }
);

Oder, falls du's mit der libWiki machen willst:

var getPreloadText = new Async( [
    wiki.getSource,
    function (trans) { document.getElementById("wpTextbox1").value = trans.wiki.source }
]);
getPreloadText.start({wiki:{title:"Vorlage:Kamelionary/preload"}});

... weiß allerdings nicht, wie stabil die derzeit ist... -> Ich würd's vermutlich mit ajax machen.

Grüße --J* 17:35, 26. Apr. 2009 (CEST)

wunderbar ... funzt. Hab' mir vor allem Sorgen gemacht, was passiert, wenn irgendwer die Vorlage löscht oder verschiebt. Nu' wäre das doch auch egal, oder? Ich lass es jetzt auf die Herde los. Grüße, --WiMu 17:59, 26. Apr. 2009 (CEST)

ein kleiner Schnipsel php(?)

Moin, J*

Ich hatte da gerade eine Idee. Was uns (und nicht nur uns, sondern eigentlich grundsätzlich bei MediaWiki) fehlt, ist ja die Möglichkeit, Parameter an eine Seite per link zu übergeben. Klar, dafür gibt es dieses Special:Call von den DPLern und bestimmt eine Handvoll anderer Extensions. Aber was mir vorschwebt, wäre viel einfacher und käme ohne Spezialseite aus. Ganz schlicht ein neues MagicWord namens {{PARAMETER}}, das alles ausspuckt, was hinter ?title={{FULLPAGENAME}} steht. Also jetzt, da ich dir schreibe müsste da &action=edit&section=new drinne stehen, und wenn ich mir meinen Senf ansehe, dann eben &action=submit. Also im Prinzip das Gegenteil von {{fullurl:Seite|Parameter}}. Der Witz daran wäre, dass man sich selbst Parameter ausdenken könnte, die man hinter die URL klebt und diese dann auf der jeweiligen Seite verarbeitet würden, z.B.: [{{fullurl:Projekt:Ka-Mel-Oh!/Karte|Nr=1}} Karte:1] → Karte:1 und auf entsprechender Seite dann eben {{Karte|{{PARAMETER|Nr}}}} ... äh, ja klar, man sollte auch die Möglichkeit haben, nur den Wert bestimmter Parameter auslesen zu können, also z.B. Nr ...

Nun, ich hab' von php nicht die geringste Ahnung, aber ich denke mir mal, dass sowas in einer halben Stunde programmiert wäre und etwa 20 Zeilen Code bedürfe – nicht mehr. Liege ich da richtig? Also wenn du Lust und Zeit hast, kannste das ja mal ausprobieren, dann teste ich das bei mir lokal und wenn's läuft geben wir das JANNiS zum installieren (oder irgendwer *zwinkerzwinker* bemüht sich mal um den Posten als Serverpriester). Ich könnte mir gut vorstellen, dass auch die MediaWiki-Leutz daran Interesse hätten.

Grüße,

--WiMu 10:59, 30. Apr. 2009 (CEST)

Trotz Quick-And-Dirty-Lösung: Ja, sollte schnell zu machen sein, hauptsächlich copy & paste von mediawiki.org. Reichen dir GET-Parameter oder willst du die gePOSTeten auch?

(Hm... Allerdings lässt sich so ein {{#PARAMETER: wrx}} auch mal schnell unauffällig irgendwo einflechten. Und wenn dann irgendwoanders ein Link http://kamelopedia.net/index.php/dieSeiteWo'sVerwendetWurde&wrx=irgendeinBeleidigenderText verteilt wird, ist das nicht nur schlechte Werbung für die KP, es sieht auch so aus, als käme der Text von hier (der Nutzer wird in den 5 Sekunden, in denen er da ist, nicht unbedingt auf die URL achten). Und zwar ohne dass wir es mitbekommen. ... irgendwie nicht so toll)

Grüße --J* 18:41, 30. Apr. 2009 (CEST)

stimmt, da haste Recht. Wie machen die das nochmal gleich bei diesem Call-Dingsbums? Die müssten doch eigentlich das gleiche Problem haben ... ich gucke mal, und sag das ggf. den DPLern. Grüße, --WiMu 18:51, 30. Apr. 2009 (CEST)

P.S.: GET oder POST? Hm ... keine Ahnung.

gerade entdeckt: http://www.mediawiki.org/wiki/Extension:DynamicFunctions#.23arg: ... kommt mit auf die Wunschliste --WiMu 18:08, 4. Mai 2009 (CEST)

Spezial-Seite für Ka-Mel-Oh!-Karten

hab' ich mal eben gebaut ... mein eigener senf da oben hat mich auf die Idee gebracht (evtl. cache entleeren, wenn die links rot sind):

• Spezial:Karte/1
• Spezial:Karte/2

usw. Oder:

• Spezial:Karte/Dromedarminator
• Spezial:Karte/Trikamel

usw. Und das alles ganz ohne server-Zugriff und php *g*. Ist ein fieser {{#if:{{PAGENAME}}-hack aus:

• MediaWiki:Nospecialpagetext
• MediaWiki:Nosuchspecialpage‎
• MediaWiki:Errorpagetitle‎
• MediaWiki:Returnto‎
• ein kleines bisschen MediaWiki:Common.css
• Vorlage:Kartenansicht‎
• und Vorlage:Ka-Mel-Oh!/Kartennavi‎

Drüben in der Test-Kamelo hab' ich noch eine andere Version, die über nicht-existierende Seiten (MediaWiki:Noarticletext‎) funktioniert: http://test.kamelopedia.mormo.org/index.php/Projekt:Ka-Mel-Oh!/Karte:1 usw. Der Vorteil an einer nicht-Existierenden Spezialseite ist einfach der, dass Kamel nicht in Versuchung kommt, die entsprechende Seite anzulegen. Dafür geht's wohl einen Tick schneller (habe ich den Eindruck).

Haste irgendwelchen Einwände, die ich evtl. nicht bedacht hab' oder so? Ich hoffe mal nicht, war ein halber Tag Arbeit und ich bau den link mal in die Ka-Mel-Oh!-Karten ein. Dann könnten wir auch mal so langsam die alten Vorlagen (Projekt:Ka-Mel-Oh!/Karte/1 usw.) ersetzen und anschließend verbuddeln.

Grüße, --WiMu 18:19, 30. Apr. 2009 (CEST)

Hab mir jetzt die zugrundeliegende Technik nicht näher angesehen, aber Einwände hab ich erstmal keine. Vielleicht aber die Parserfetischisten von MediaWiki. Wer weiß, wo die fürs nächste Update am Parser rumgefummelt haben und ob's danach noch geht? --J* 18:32, 30. Apr. 2009 (CEST)

sind alles Seiten, die mit ohne $1 und so auskommen ... ist ja auch nur provisorisch, bis sich jemand findet *zwinkerzwinker*, der das vernünftig programiert :-) --WiMu 18:35, 30. Apr. 2009 (CEST)

Nochmal nachgefrägt. Hm ... die „Spezialseite“ ist vor dem gerendert-werden-müssen gut 0.5mb groß. Das ganz schön viel, für lausige 20kb nach dem rendern, und leider merkt man das auch. Naja, im Moment geht's nicht besser (zumidest wüsste ich nicht wie). Aber nur mal so rummgesponnen: wenn man alle links unter dem ---- (Pfeil vor, Pfeil zurück und so Kram), wenn man diese ganzen links XHTMLHTTPdingenskirchenrequested (kanns mir immer noch nicht merkeln), sind die entsprechenden Seiten dann im cache? Und könnte man die dann von da abrufen, also so wie Ajax eigentlich gedenkt ist? Ich gucke mir eine Karte an und in der Zwüschenzeit werden die 4 - 5 anderen Karten bereits geladen, die ich vermutlich als nächstes angucke? Ginge das irgendwie? --WiMu 00:34, 1. Mai 2009 (CEST)

Also... Ajax ist eigentlich nicht dazu gedacht, irgendwelche Seiten in Caches vorzuladen, und ob man es dazu missbrauchen könnte ...? keine Ahnung.

Man könnte Ajax so benutzen wie es eigentlich gedacht ist: nämlich um Teile einer Seite zu verändern, ohne die komplette Seite neu laden zu müssen. Ist oft schneller, weil weniger Daten übertragen werden müssen, in dem Fall bringts aber nicht viel, weil ja bei uns hauptsächlich das Rendern Zeit braucht.

Ganz vielleicht könnte man das auch so umbauen, dass es vorausläd, aber:

1. die URL ändert sich ncht, wenn man auf weiter, zurück, etc. klickt (klar, ist dann ja mit Ajax)
2. man müsste beim Klick auf einen Button umständlich abfragen, ob die gewünschte Seite schon vorgeladen wurde, anschließend alle anderen AjaxRequests abbrechen (keine Ahnung wie das geht) und dann das Ergebnis auswerten
3. Aus Server-Perspektive: Wenn das Laden so schon ewig dauert, dann sollte man eigentlich die Abfrage vereinfachen und die Serverlast verringern, anstatt den Server auch noch zusätzlich mit weiteren (eben so lange dauernden) Seiten zu belasten...

Grüße --J* 14:50, 1. Mai 2009 (CEST)

Hat sich sowieso schon erledigt. Die doofe Vorlage:NUMBEROFCARDS braucht einen Haufen ressourcen. Hab mal eine abgespeckte Version gebaut und das Ergebnis in eine Variable gepackt. Ist jetzt sogar inkl. Such-Box (eigentlich eine create-box, weil man bei einer such-box keinen Präfix angeben kann ... manchmal könnte ich Wiki ...) nur noch 1/5 so groß und die Performance ist jetzt OK. Grüße, --WiMu 14:59, 1. Mai 2009 (CEST)

Pre-expand include size:

Hi, J*

sorry, dass ich dich ständig nerve ... mein lokales Wiki zeigt mir im html-Quelltext immer nur die Post-expand include size an, die wie in der Kamelo bei maximal 2mb liegt. Nur fehlt mir die Pre-expand include size. Kannst du mir sagen, wie ich das einstellen kann, damit ich nicht ständig feststellen muss, dass der Kram hier nicht funktioniert, der bei mir zu hause ohne Probleme läuft? Hab' auf MediaWiki.org nix dazu gefunden. Grüße, --WiMu 14:08, 3. Mai 2009 (CEST)

Eieiei... Also, gefunden hab ich auch nix. Eigentlich kann ich mir auch keinen vernünftigen Grund dafür vorstellen, warum die Entwickler eine Option für ein separates an- und ausschalten der Pre-expand include size eingeführt haben sollten ... Ich würd einfach mal vermuten, dass das am Parser liegt (wenn ich das richtig sehe, haben sie den Parser erneuert/ausgetauscht) und der das Feature nicht hat weil entweder

• keiner dran gedacht hat es einzubauen
• die Rechnung beim neuen Parser viel zu kompliziert wäre oder
• der neue Parser total anders funktioniert, so dass es überhaupt kein pre-expand mehr gibt.

Aber wirklich Ahnung hab ich da nicht, tut mir leid.

Grüße --J* 14:54, 3. Mai 2009 (CEST)

PS: Notfalls mal bei wikimedia nachfragen ...

hm ... bei der Wikipedia gibt's auch kein Pre-expand include size seh' ich gerade, dann liegt's wohl an der Wiki-Version, und die will ich nu' auch nicht downgraden. Danke nochmal für deine Geduld. --WiMu 15:30, 3. Mai 2009 (CEST)

Kein Ding. Wenn du noch was hast, sag nur Bescheid. --J* 19:49, 3. Mai 2009 (CEST)

Ich hab' (vermutlich) die Antwort gefunden, und zwar da. Ab MediaWiki v1.12alpha gibt es wohl sowas wie ein pre-expand nicht mehr, weil der parser nun erst dann einsetzt, wenn z.B. {{#if:-Bedingungen erfüllt sind, statt wie bei uns erstmal alles zu parsen und hinterher zu gucken, was eigentlich gebraucht wird *grrrr*. Wie ich das sehe, wird bei unserem ganzen dpl-Gedöhnse die Kamelo mit dem nächsten update ungefähr doppelt so schnell ... *g* Hätte gute Lust, bis dahin das Handtuch zu werfen. Habe die letzten zwei Tage mal wieder was gebaut, was bei mir zu hause wie der Teufel rennt, mit mikrigen 100kb oder so, aber hier in der Kamelo gibt es diverse timeout und parser-Fehler ... ARRRGGGHHHS! --WiMu 18:01, 4. Mai 2009 (CEST)

Cool. Wie oft hab ich mich schon geärgert, Variablen nicht mit {{#if:...|{{#vardefine:...}} }} zuweisen zu können (und das müsste dann doch eigentlich gehen, oder?). Grüße --J* 21:49, 4. Mai 2009 (CEST)

Das war auch mein erster Gedanke ... ausprobiert ... funzt :-) Magst du nicht doch mal bei JeLuF anklopfen wegen server-Zugriff? Jetzt kann ich's nicht mehr erwarten ... --WiMu 10:19, 5. Mai 2009 (CEST)

Och nö, eigentlich nicht. Zum einen hab ich nicht wirklich die Zeit mich auch noch um einen Server zu kümmern; zum anderen liefe ich dann in die Gefahr die Kamelopedia mit eperimentellen oder (noch schlimmer) selbstgeschriebenen Extensions zu fluten ... Vielleicht ist es da besser, wenn die finale Entscheidung bei jemandem anders liegt. Grüße --J* 19:50, 5. Mai 2009 (CEST)

Umbau monobook.js

'nabend, J*

Ich mach mir ein wenig Sorgen wegen unseres monobook.js. Schon alleine das prototype wiegt glaube ich 100kb, dazu kommt noch das Klippdings, Gummistiefel und bald deine wikibits-Erweiterung(?), bei mir zuhause warten auch noch 2-3 scripts, und ich befürchte, dass das irgendwann zuviel wird. Nun meine Idee: viele der scripts (z.B. Gummistiefel und KlippKlapp) werden ja über CSS-Klassen oder IDs oder sonstwas gesteuert, d.h. man braucht die ja eigentlich nur, wenn im aktuellen Dokument die entsprechenden Klassen drinne sind. Was hältst du davon, wenn wir zwei neue Funktionen addJSonload und addCSSonload schreiben, die ein externes script holen, nachdem die Seite geladen wurde ... also am besten mit Ajax. Dann könnten wir das monobook entmüllen und alles, was nur gebraucht wird, wenn getElementById('irgendwas') oder getElementsByClass('irgendwas') (müssten wir halt schreiben) oder sogar getCategories('irgendwas') = true auslagern. Das Problem wäre halt das Nachladen selbst, da diese scripts ja erst dann geladen werden können, wenn die Seite bereits da ist. Ist wohl eine Gewissensfrage ... entweder immer ein ganzen Haufen sofort laden müssen, oder Häppchenweise wenn's gebraucht wird, aber dafür mit Verzögerung. Was meinstn?
Ach nochwas: wollen wir den ganzen Kram nicht mal nach MediaWiki:Common.js verlegen? Das schlimmste was bei einem nicht-monobook-skin passieren könnte, wäre doch, dass unsere scripts nicht funktionieren, weil irgendwelche Attribute fehlen. Die funktionieren aber doch erst recht icht, wenn sie gar nicht erst geladen werden ... --WiMu 00:20, 8. Mai 2009 (CEST)

Nachtrag: oder aufs Update warten, ob da vielleicht secureHTML mitkommt? Damit ließe sich bequem und sicher ein .js von einer Kamelo-Seite aus holen (mit Tag-Parser per switch auch nur auf bestimmte, interne scripts beschränkt, damit Niemand Unfug treiben kann). --WiMu 00:26, 8. Mai 2009 (CEST)

Pro: für eine Entmüllung. Aber ob das so eine gute Idee ist, JS-Quellcode nach dem Laden der Seite nachzuladen? Das wird vermutlich die Ladezeit deutlich verzögern (zumindest auf den entsprechenden Seiten), suboptimal. Zu überlegen wäre, ob man Bibliotheken wie Prototype (vielleicht, s.u.), libwiki (die auf jeden Fall) oder Gummistiefel einfach nur auf den seiten läd, die das brauchen, dann aber mit artikelname-basiertem Filter und addJS (so wie Artikel mit skins usw.)

Bei Prototype bin ich mir da allerdings nicht ganz sicher, ob das sinnvoll ist, da man manchmal völlig anders programmieren muss, je nachdem ob prototype geladen ist, oder nicht (z.B. mit Arrays: mit prototype geht for (var i in [1,2,3]) { ... } nicht, und ohne geht [1,2,3].each(function(e){...}) nicht, obwohl sonst beides etwa das gleiche macht)

Ansonsten könnte man einfach mal schauen, wo man code einsparen kann und vielleicht sollte man das ganze mal objektorientiert aufbauen...

Nach Commons.js verschieben? warum nicht... dann aber zusammen mit dem Commons.css ...

Secure-HTML? Hm... Vielleicht gute Idee, müssen dann nur mal sehen, wie sich doppelt eingebundene Scripts auf die Sache auswirken. Oder per #vardefine sowas verhindern ...?

So, mein Senf soweit (bitte nicht wundern, wenn ich um diese Uhrzeit Unsinn schreibe) - bin jetzt allerdings erstmal ne Woche im Urlaub und deshalb weitab der Wüste! Grüße --J* 00:51, 8. Mai 2009 (CEST)

Viel Spaß im Urlaub. Ich sehe das Problem mit nachgeladenen scripts ja auch, sonst hätte ich gar nicht nachgefragt, sondern das einfach gemacht. Das Problem ist einfach, dass man Wiki ja irgendwie sagen müsste, dass sich auf einer Seite z.B. ein Klipp-Dings befindet. Per Seitenname müsste dazu ein riesiges Array geschrieben werden, in dem jede Seite drinsteht, die das Teil verwendet. Ich glaube, das ist nicht machbar. Die Idee war halt, auf bestimmte Seiteninhalte zu reagieren (classes, Ids, Kategorien, usw.), nur sind die halt erst nach dem Laden verfügbar. Wir könnten es ja einfach mal ausprobieren, wie sich die Verzögerung auswirken würde. Prototype würde ich entweder so lassen wie es jetzt ist, oder ganz rausschmeißen; das (wirklich schöne) Ding wird ja wiederum von anderen scripts gebraucht, und das macht die Sache unüberschaubar, wenn man das je nach Bedarf lädt. Aber erhol' dich erstmal gut. Grüße, --WiMu 09:30, 8. Mai 2009 (CEST)

schön, dass du wieder da bist ... und es sind ja auch ein paar gute Dinge in der Zwischenzeit passiert. Apropos Urlaub: passiert sowas nicht immer, wenn du nach kurzer Pause wieder zurück kommst? Einfach keine Pausen mehr machen *g* ... Gruß, --WiMu 07:31, 18. Mai 2009 (UTC)

Forum

... Oh Gott, nein, nicht was du denkst ... Wollte nur kurz bescheid sagen, dass ich drüben in der test-Kamelo am Forum schraube. Unter anderem habe ich die Ausfallsicherung rausgeschmissen, weil man sich mit den neuen Extensions so schön durch alte threats wühlen kann. Will noch das Datum von tt mon yyyy usw auf "gestern", "vor 5 Minuten" usw. umstellen, den threat-Ersteller, Anzahl der Abschnitte usw. anzeigen lassen, manuelle Auswahl der ordermethod, und vieles mehr. Wollen wir uns mal absprechen, oder soll ich einfach machen?

P.S.: habe gerade ein konkret krasses Déjà-vu ... hatten wir das Thema schonmal? Grüße, --WiMu 16:18, 25. Mai 2009 (UTC)

Ne, hatten wir glaub ich noch nicht. Blättern und Datum umstellen ist super, Fred-Ersteller steht doch schon drinne (oder hab ich was verpasst?). Die Anzahl der Abschnitte wäre für mich eher unwichtig (und verbraucht trotzdem Rechenzeit). Ordermethod ist ne nette spielerei, kann man vielleicht schon mal brauchen.

Allerdings fand ich gerade die Ausfallsicherung ganz praktisch (aber vielleicht bin ich da ja auch der einzige...?). Wenn man das Teil richtig nutzt und alle Freds ordentlich als Info oder erledigt markiert, dann stehen auf der Seite die x neusten Freds - und dann eben noch zusätzlich alle Freds die noch offen sind, und die sonst vermutlich längst wieder in vergessenheit geraten würden. (So vielleicht aber trotzdem ...?)

Kann man das vielleicht irgendwie kombinieren? Mal drüber nachdenken ... --J* 20:51, 25. Mai 2009 (UTC)

ich hatte in jedem Fall vor, eine Vorlage {{wichtig}} einzuführen, die Kamel in einen fred bappen kann, so dass der fred dann auf allen Forums-Seiten (1,2,3,...) ganz oben gelistet wird ... wie in jedem anderen Forum halt auch. Im übrigen habe ich eher die umgekehrte Befürchtung, dass mit Seiten-Durchklick-navi ständig der olle Kram wieder ausgegraben wird, der lieber in Vergessenheit geraten sollte *g*. Ach so, mit threat-Ersteller haste natürlich Recht, ich meinte das erstell-Datum, das hätte ich auch gerne drin. Naja, ich pimpe da mal so lange dran rum, bis Wiki aufgibt, und dann reduziere ich die features auf eine erträgliche Ladezeit ... warum kompliziert, wenn's auch umständlich geht ... --WiMu 21:03, 25. Mai 2009 (UTC)

Sonst machen wir halt 2 Seiten draus: 1x alle freds und 1x offene freds, jeweils mit Blätterteig Blätterteil. (Oder wollen wir das alles noch mal im Forum diskutieren? Oder gleich ne extension schreiben? Oder ein Projekt draus machen ... *g*)

Grüße --J* 22:00, 25. Mai 2009 (UTC)

hm ... es wäre eigentlich auch gar kein großes Problem, so ein Klickdings einzuhufen, zum ein- und ausblenden bestimmter threat-Typen (offene-threats, Frage-threats. usw.). Abgesehen davon finde ich, sollten wir mal den sowieso latent vorhandenen Namensraum Forum_Diskussion anlegen, dann hätten wir zwei separate Senf-Ecken, eine zum Diskutieren und die andere zum über das Diskutieren Diskutieren ... *g* --WiMu 22:07, 25. Mai 2009 (UTC)

Ganz ehrlich - es hat mich nicht erst einmal geärgert, dass der fehlt. So zerflückt dann auch die Metakommunikation nicht immer so das eigentliche Thema ... --J* 22:11, 25. Mai 2009 (UTC)

Hi, bräuchte mal wieder deine Hilfe ...

... ich krieg's einfach nicht hin:

[] ... alles wunderbar, aber: [] schmeißt mir einfach alles, was rechts neben "=" steht raus. Hab' heute den ganzen Tag daran rumgebastelt, mit {{urlencode}} versucht, mit tag-Parser, damit man Wikitext verwenden kann (das geht in Vorlagen leider gar nicht), mit #if-Konstruktionen, und, und, und. Ist alles total doof, und nicht der einzige bug im secureHTML, den ich gefunden hab :-( Irgendeine Idee? --WiMu 14:27, 27. Mai 2009 (UTC)

Liegt daran, dass in SecureHTML.body.php, Zeile 216 aus bequemlichkeit explode benutzt wird - das dürfte sich ganz leicht patchen lassen (muss nur irgendwer dann auch in den Server hufen).

Und schon kommt das nächste Problem:

Den Fix momentan noch nicht empfehlen - denn der Bug ist das einzige was momentan verhindert, dass mit einfachsten Methoden beliebiges Javascript ausgeführt werden kann. Ich denke da an sowas wie:

{{#shtml:Vorlage:Img/img|alt=Beschreibungstext" onload="mein_schadcode(); }}

(auf die Gänsefüßchen achten!) bzw. ganz konkret z.B. (ist jetzt noch relativ harmlos):

{{#shtml:Vorlage:Img/img|alt=Beschreibungstext" onload="while (true) alert('ätsch!'); }}

wäre auch jetzt schon möglich, wenn nicht alles nach dem = weggeworfen würde (invalides HTML kommt trotzdem auch jetzt schon dabei raus). {{anchorencode {@{param}@} }} würde das zwar verhindern, aber damit dann auch wirklich das da steht, was da stehen soll, bräuchten wir eigentlich eine Parserfunction die genau das macht wie die PHP-Funktion htmlspecialchars - müsste man sich wohl selbst schreiben...

Ob secureHTML wirklich so ne gute Idee war? (wer weiß was da sonst noch so lauert ...)

Grüße --J* 16:31, 27. Mai 2009 (UTC)

hm ... ja, secureHTML ist wirklich nicht das gelbe vom Ei. Aber prinzipiell würde doch parameter = {{#replace:{{{parameter}}}|"|"}} schon genügen, um auf halbwegs sicherer Seite zu sein. Hab' übrigens verschiedenes selbst schon ausprobiert, um da javascript reinzuhacken, und mir ist es nicht gelungen (will aber nix heißen) ... --WiMu 17:09, 27. Mai 2009 (UTC)

Ja, liegt einfach daran, dass der =-Bug das (noch) zufällig verhindert. Nach Bugfix kommen wir um ein #replace nicht herum (müssen wir eigentlich auch & ersetzen, damit URLs ordentlich funktionieren?). Grüße --J* 17:43, 27. Mai 2009 (UTC)

Ja, & -> & muss auch mit rein. Und ums ganz ordentlich zu machen auch ' -> '. < und > dürfte Wiki eigentlich selbst machen, oder? - Mist nowiki bringt hier nix, schau einfach in den Quelltext! --J* 17:47, 27. Mai 2009 (UTC)

Ganz ehrlich, ich versteh auch diesen ganzen {@{parameter}@}- und Seitenschutz-Quatsch, sowie das nebeneinander von <html>, {{#html}}, {{#shtml}} und – theoretisch – {{#tag:html}} nicht wirklich. Es müsste doch möglich sein, im MediaWiki-Namensraum ganz simples #rawHtml zu gestatten, das dann (inkl. WikiMarkup) als Vorlage {{MediaWiki:Seite}} auf "normalen", ungeschützten Seiten expandiert werden kann. Mit #replace oder Ähnlichem ließe sich das auch mindestens ebenso sicher handhaben, wie dieses "secure"HTML, und wäre in der Handhabung 100mal einfacher und 100mal leistungsfähiger. Stell dir mal die Möglichkeiten in Kombination mit dpl (z.B. hier die Autorenliste) oder <math> vor, aber so ist das zumindest für Vorlagen ziemlich unbrauchbar ... grmpf --WiMu 19:41, 27. Mai 2009 (UTC)

Muss da nochmal drüber schlafen, wo da genau die Zahnräder ineinander greifen (falls sie's denn tun ...). Vielleicht ist das aber auch Absicht, dass es kompliziert ist und nicht mit normal-wiki-Syntax geht - auf diese Weise kommt man nicht in Versuchung, es wirklich für jeden Mist zu benutzen, den man vielleicht auch anders lösen könnte. So, erstmal gute Nacht! --J* 21:49, 27. Mai 2009 (UTC)

Gerade gefunden: das Ding wäre eigentlich das, was wir bräuchten, nur leider erlaubt die Extension keinerlei WikiSyntax und keine ÜbergabeParameter (Ja, ich weiß, das wäre am sichersten ... aber trotzdem doof). Vielleicht wirklich mal was eigenes schreiben ... --WiMu 08:18, 28. Mai 2009 (UTC)

Oder möglicherweise das hier - das kann auch parameter - und den windget-namespace müsste man dann halt schützen lassen (aber würde man dann auch automatisch die ganzen fremd-Widgets drinnehaben? Glaube fast ...) --J* 15:39, 28. Mai 2009 (UTC)

Ich weiß nicht ... ist schon wieder mit so komischen {@{parametern}@} und stammt von dem gleichen Typen, wie das secureHTML-Dingens. Müsste man vorher ausgiebig Testen, am besten lokal ... --WiMu 15:57, 28. Mai 2009 (UTC)

Grad mal installiert - die Fremd-Widgets lassen sich schonmal nicht einfach so per Konfig abschalten (sehr ärgerlich) aber immerhin indem man 4 Zeilen auskommentiert ... Das HTML käme dann in den Widget-Namespace und den müsste man dann mit Wiki-Bordmitteln absichern - hab das allerdings noch nicht ausprobiert. Grüße --J* 16:18, 28. Mai 2009 (UTC)

Oder einfach $wgRawHtml=true; und wir haben das Problem mit unsicheren Extensions gelöst *g* --WiMu 16:22, 28. Mai 2009 (UTC)

Ja, super idee (-: vielleicht löst das dann auch gleich alle anderen Probleme die wir potentiell haben könnten - ich wart schon mal auf die erste DoS (-: --J* 19:21, 28. Mai 2009 (UTC)

SecureWidgets funzt nicht. RawMsg hab ich zwar noch nicht getestet, aber der Quellcode sieht ganz hübsch aus und vermutlich lässt sich das ganze mit 3 Handgriffen so erweitern, dass es sogar Parameter unterstützt! Muss ich mich mal ransetzen, sobald ich mehr Zeit hab. Grüße --J* 21:06, 28. Mai 2009 (UTC)

Nerven macht echt Spaß...

Könntest du mir vielleicht hierbei (letzter Abschnitt) helfen? Erst mal auf die erste Frage antworten, dann kommt der Rest. Bist grade aktiv und ich kanns kaum erwarten, das ganze in fertig zu sehen. Gruß,--K-3000(Hbf|Diskette) 17:35, 3. Jun. 2009 (NNZ)

Ja, Wikia kenn ich (immerhin ist da auch das größte Spoilerwiki zu Nethack, einem meiner Lieblings-Kompjuterspiele - aber hat mit der Frage eigentlich gar nix zu tun ...) Das war doch die Frage, oder? Grüße --J* 17:41, 3. Jun. 2009 (NNZ)

Gut, jetzt kommts zur eigentlichen Frage:Kann man hier so wie bei Wikia Monaco-Sidebars im Bau erstellen? Auf der linke Seite meines Baus kannst du einen Anfang sehen. (Ich glaub, ich bräuchte wieder einen Paten)--K-3000(Hbf|Diskette) 17:47, 3. Jun. 2009 (NNZ)

Die Frage war ja mal gar nicht soo leicht zu beantworten; bisher hab ich nämlich auf Wikia nie was besonderes festgestellt, zumindest nicht, was die Sidebars angeht. Erst als ich durch die Frage auf die Idee gekommen bin, das Javascript anzuschalten... So, genug der Vorrede.

Auf Wikia laufen ganz normale Wikis, also ist die Antwort erstmal "Ja.". Das Geheimnis ist in der MediaWiki:Common.js verborgen, z.B. da [2], Abschnitt Dynamic Navigation Bars (Glaub ich zumindest). Wenn wir den Code auch bei uns in die Commons.js oder die Monobook.js schreiben würden, ging's auch. Allerdings hab ich keine Ahnung, unter welcher Lizenz Wikia den Code veröffentlicht bzw. ob wir den hier einfach so übernehmen dürfen (müsste man vielleicht Fragen, wenn man das will). Und vermutlich müsste man dan Code anpassen, so dass er hier läuft. Und damit er nicht die Navi-Leiste ganz links nimmt, sondern das Teil bei dir im Bau wahrscheinlich auch nochmal. --J* 18:15, 3. Jun. 2009 (NNZ)

*einmisch* also das menue an und für sich lässt sich auch ganz ohne javascript mit css alleine bauen ([] Vorlage:Hilfe), aber das vernünftig in die sidebar zu kriegen, das geht nur mit .js. Aber das will Kamelefant gar nicht, oder? --WiMu 18:22, 3. Jun. 2009 (NNZ)

Bevors falsch verstanden wird, so ähnlich wie bei der Hilfe-Vorlage, nur dass beim draufzeigen der Kasten nach rechts sich öffnet. Und nicht in dem hier, sondern direkt in meinem Bau. Hoffe dass das jm. verstehen kann...--K-3000(Hbf|Diskette) 19:26, 4. Jun. 2009 (NNZ)

hab's verstanden ... und bau' ich dir gleich (hoffe, das geht so leicht, wie ich mir das vorstelle) --WiMu 22:30, 4. Jun. 2009 (NNZ)

Mehr als das hab' ich jetzt in fünf Minuten nicht hingekriegt, aber so würde es in etwa funktionieren (dann natürlich in einer Vorlage und aufgehübst und so):

--WiMu 23:02, 4. Jun. 2009 (NNZ)

so, erstmal feddich. Warum das erste sub-menue so weit nach links eingerückt ist, weiß ich auch nicht. bei mir lokal tut's das nicht. Muss an irgendeinem Kamelo-CSS liegen. Viel Spaß damit. --WiMu 16:50, 5. Jun. 2009 (NNZ)

Und nochmal nerven:Wie krieg ich das Navi ins monobook? Also so, dass ich es von jeder seite aus sehen kann, auch außerhalb meines Kamelbaus, aber andere nur in meinem Kamelbau es sehen können. Geht das überhaupt?--K-3000(Hbf|Diskette) 18:44, 10. Jun. 2009 (NNZ)

Wo willst du's denn haben? Links in der Menüleiste? ... oje, da müsste man das was jetzt dein Quelltext und die Vorlage macht, einmal in komplett Javascript umsetzen ... gehen tut das sicherlich, irgendwie. Hab nur leider grad nicht genug Zeit, das zu basteln. Grüße --J* 19:01, 10. Jun. 2009 (NNZ)

Habs mir anders überlegt, brauche ich gar nicht. Gruß,--K-3000(Hbf|Diskette) 10:26, 11. Jun. 2009 (NNZ)

ParaDingsBums

Hi, J*

ich hab' nun die Extension installiert, und (hätte vielleicht lieber mit was einfacherem anfangen sollen) hab' mal testweise den Kram, den ich bei mir lokal für's Forum gebaut habe auf das Teil umgestellt. Der Quelltext, den das Ding ausspuckt sieht eigentlich ganz brauchbar aus, bis auf eine Kleinigkeit, so dass es leider nicht funzt

Also folgendes: ich habe mir eine Vorlage gebastelt, die so phpBB-mäßig die Seitenzahlen zum Durchklickern anzeigt, und zwar in der Art 5 15 25 ... 31 32 33 34 35 36 37 38 39 ... 45 55 usw., wie man das aus Foren eben so kennt. Die Vorlage enthält neben diversen #loops auch ihr eigenes stylesheet, das aus den Zahlen schöne buttons macht mit :hover und :active und allem was so dazugehört. Deine Extension macht nun aus Zeilenumbrüchen innerhalb von <style type="text/css"> ... </style> (und evtl. auch anderswo?) ein 
, so dass im Quellcode sowas landet:

<style type="text/css">&#13;
table.pagelinks {
	background-color:#fdfced;
	padding-bottom:1px;
	font-size: 10px;
	text-align:center;
	}&#13;
...

Damit ist das schöne CSS natürlich unbrauchbar . Aber immerhin: ich habe alle Dateien ({{#tag:html| ... find' ich Klasse) mit {{filepath:Bildname.xyz}} referenziert, um später mal alles 1:1 rüberkopieren zu können, ohne überall lokalhorst durch kamelo ersetzen zu müssen; und zumindest das funktioniert auch mit deiner Extension. Kannst du das mal eben richten, damit ich weiter testen kann?

Ach und wegen Sicherheit: das einzige, worauf wir achten müssen ist doch, dass Ottonormalkamel kein javascript in irgendwelche Parameter flanscht, oder? Dann würde es doch reichen, mit {{#replace}} einfach das Wort "script" rauszuschmeißen, womit auch jscript, ecmascript, actionscript, usw. ausgeschlossen wäre ...

Grüße,

--WiMu 12:00, 7. Jun. 2009 (NNZ)

Also erstmal zur Sicherheit - wenn man einfach nur was rauswirft (blacklist) kann man immer was vergessen - wenn wir z.B. das Wort script rauswerfen, was ist dann mit dem da:

Grundsätzlich ist es unpraktisch wenn man per {{{parameter}}} irgendwelche attribute einsetzen kann, die man aber nicht einsetzen können soll.

Was die Zeilenumbrüche angeht: Die Extension ersetzt an mehreren Stellen Zeilenumbrüche durch &#13;

1. innerhalb von {{{parametern}}} - die sollen schließlich auch attribute safe sein (Lösung: CSS ohne Zeilenumbrüche einfügen)
2. Die MediaWiki-Funktion, die am Ende das HTML entgegennimmt unterstützt leider teilweise auch Wiki-Syntax ( \n* -> unsortierte Liste, \n# -> sortierte Liste "" macht fett und eben auch \n\n macht Absatz - aber nowiki unterstützt die blöde Funktion nicht). Wenn ich da nicht bei doppelten Zeilenumbrüchen alle außer dem letzten als &#13; codieren würde, würde dann da "</p><p>" drinnestehen (Ergebnis bei angeschaltetem $wgParaMsgAllowWikiParagraphs - bei RawMsg übrigens auch) und das wollte ich vermeiden. Lösung: Einfach keine doppelten Zeilenumbrüche im CSS verwenden. Oder externes css: <link rel="stylesheet" type="text/css" href="{{fullurl:MediaWiki:meinExternesCSS.css|action=raw}}" /> (Ja, nicht so super, meine Lösung, aber ich wüsste nicht, wie ich's fixen sollte)
   Hatte auch überlegt ob ich mehrfache Zeilenumbrüche in einfache umwandeln soll, aber das verändert dann z.B. den Text in textareas, pre-tags usw. Auch nicht so toll...

Schon möglich, dass das irgendwie anders geht, aber bereits jetzt hab ich mehr vom MediaWiki-Parser von innen gesehen, als ich eigentlich jemals vorhatte ... (-:

Grüße --J* 12:35, 7. Jun. 2009 (NNZ)

hm, nur so als Tipp: das <html>-tag erlaubt irgendwie (keine Ahnung) das Wiki-übliche <p></p><p> ... (das ich nebenbei gesagt ziemlich nervtötend finde) in unformatierten Bereichen, als auch "plain-Text" bei <script>, <style>, <a>, usw. ... naja, ich versuch's mal mit Leerzeichen vor .class und #id und so, dann müsste es ja funzen (Leerzeilen weglassen, damit kann ich mich nicht anfreunden ...) --WiMu 12:49, 7. Jun. 2009 (NNZ)

Das mit dem <html> hab ich irgendwie grad nicht ganz verstanden. Und leerzeichen werden von wiki immer als <pre> interpretiert (für die Parameter hab ichs weggemacht, für den Rest glaub vergessen)

Mir ist grad nochmal ne Idee gekommen, muss ich mal heut abend noch ausprobieren. Vielleicht kann man das Ganze vorparsen ...? Grüße --J* 13:04, 7. Jun. 2009 (NNZ)

hm ... ich hatte gerade versucht, was in Richtung //{{#tag:pre zu machen, was leider auch nicht geht. Evtl. die Mehrzeilen-Umbrüche erlauben?, dann ginge das mit //{{#tag:pre. Eine weite Sicherheitslücke sind Vorlagen, die im MediaWiki:Paramsg-xy verwendet werden, da kann IP bequem seinen Schadcode unterbringen (wie das auch schon bei "secure"HTML war). Keine Ahnung, wie man das lösen könnte. Muss los. Wir sprechen uns spätestens heute abend im Chat, falls du da bist (und das Frauchen mich lässt ...) --WiMu 13:55, 7. Jun. 2009 (NNZ)

Du kannst Zeilenumbrüche selbst erlauben, einfach diese Eine Variable auf true setzen (wie unter Konfiguration beschrieben). Vorlagen lassen sich grundsätzlich abschalten, allerdings geht dann auch kein #tag, kein #if, kein #replace usw., eben alles was zwei geschweifte Klammern hat. Ansonsten dort einfach keine Vorlagen verwenden - wenn man das irgendwo erklärt sollte man eigentlich meinen, dass das möglich wäre, sich dran zu halten (das ist anders als secureHTML - da bezog sich das Problem ja auf Seiten, die mit HTML-Verwendung an sich gar nix zu tun hatten). Soweit schon mal. Ansonsten mehr heut abend, falls wir beide da sind. Grüße --J* 14:13, 7. Jun. 2009 (NNZ)

mal so nebenbei: was hast du denn überhaupt mit der Extension vor? Soll die nur bei uns laufen, oder willst du die bei MediaWiki.org hochladen/zur Verfügung stellen? Also weil wenn die nur für uns sein soll, dann kann man sich ja bei der Verwendung auf alles mögliche einstellen, aber wenn daraus 'ne "offizielle" Extension werden soll, wäre für mich sowas wie der Zeilen-Umbruchs-Kram ein showstoper. Naja, egal. Heute abend klappt wahrscheinlich leider doch nicht, weil ich einem Freund bei seiner Dilomarbeit helfen muss. Korrekturlesen und so. Bis dann, --WiMu 14:30, 7. Jun. 2009 (NNZ)

Könnte man auch sicher "offiziell" machen, wenn wirklich alles anständig läuft. Aber trotz MIT-Lizenz würde ich die Extension erst einsetzen wollen (sowohl dort als auch erstrecht hier), wenn's wirklich läuft. Egal. Lass uns einfach demnächst mal irgendwann im Chat treffen --J* 22:26, 7. Jun. 2009 (NNZ)

Hallo, J*. Ich wollte dein ParaDingsbums nun auch online installieren, und kriege auf einmal folgenden Fehler, sobald ich {{#ParaMsg: Test}} probiere: Fatal error: Unsupported operand types in /var/www/webb48/html/wiki/includes/parser/LinkHolderArray.php on line 33 Keine Ahnung, was da schief gelaufen ist, bei mir lokal hat das Ding einwandfrei (bis auf ... s.o.) gefunzt. --WiMu 10:18, 9. Jul. 2009 (NNZ)

Ojeoje ... heißt im Klartext, irgendwas beißt sich da mit der installierten Wiki-Version. Welche Version isses denn? Und was steht in Zeile 33 der LinkHolderArray.php (in "meiner" Version gibt's die Datei nicht mal ...) bzw. kurz davor / kurz danach?

Dann kann ich mir das mal ansehen und vielleicht findet sich dann auch die Lösung! --J* 17:43, 9. Jul. 2009 (NNZ)

aha, sehr schön. Mein confixx lässt mich noch nicht mal den Ordner öffnen und meckert was vonwegen Allowed memory size of 8388608 bytes exhausted (sch*** Programm mit filezilla gehts's). MediaWiki v 1.15. / LinkHolderArray.php:

 1<?php
 2
 3class LinkHolderArray {
 4	var $internals = array(), $interwikis = array();
 5	var $size = 0;
 6	var $parent;
 7
 8	function __construct( $parent ) {
 9		$this->parent = $parent;
10	}
11
12	/**
13	 * Reduce memory usage to reduce the impact of circular references
14	 */
15	function __destruct() {
16		foreach ( $this as $name => $value ) {
17			unset( $this->$name );
18		}
19	}
20
21	/**
22	 * Merge another LinkHolderArray into this one
23	 */
24	function merge( $other ) {
25		foreach ( $other->internals as $ns => $entries ) {
26			$this->size += count( $entries );
27			if ( !isset( $this->internals[$ns] ) ) {
28				$this->internals[$ns] = $entries;
29			} else {
30				$this->internals[$ns] += $entries;
31			}
32		}
33		$this->interwikis += $other->interwikis;
34	}
35
36	/**
37	 * Returns true if the memory requirements of this object are getting large
38	 */
39	function isBig() {
40		global $wgLinkHolderBatchSize;
41		return $this->size > $wgLinkHolderBatchSize;
42	}
43
44	/**
45	 * Clear all stored link holders.
46	 * Make sure you don't have any text left using these link holders, before you call this
47	 */
48	function clear() {
49		$this->internals = array();
50		$this->interwikis = array();
51		$this->size = 0;
52	}

usw.

sorry für's zumüllen, aber ich hab Geshi gerade erst für mich entdeckt :-) --WiMu 18:13, 9. Jul. 2009 (NNZ)

Frage wegen zerschossener Seiten

Moin J*, könntest du dir mal das da Kamelopedia:Vorlagen Kamelbox und das da : Kamelopedia:Artikelnavis bekucken? Es scheint sich um eine häufige Krankheit von Wiki zu handeln, hab das schon oft irgendwo beobachetet. ein div zuviel oder zuwenig irgendwo. Nur wo?? Komm nicht drauf. Kannst du mir mal nen Tipp geben, wo da der Hund begraben liegt? Grüße -- Camel-in-a-box Mach mit! 12:48, 19. Jun. 2009 (NNZ)

Vielleicht ist das meine schuld? War keine Absicht wenn es so ist ... Luzifers Freund 12:53, 19. Jun. 2009 (NNZ)

Und, wenn wir grad beim Thema sind: kuck mal diesen Edit einer Auskenner-IP: [3]... Kannst du mir erklären, was um alles in der Welt die da macht? und warum das funzt? Meine entzündeten Augen sehen da eine ruinierte Tabelle, die aber irgendwie doch funzt. Naja, ist nicht so wichtig. Ich werde diese Feinheiten wohl nie kapieren. Solange es so fähige IPs und Kamele gibt, ist das ja auch völlig wurst... ;) -- Camel-in-a-box Mach mit! 13:22, 19. Jun. 2009 (NNZ)

hat sich erledigt - Grüße -- Camel-in-a-box Mach mit! 12:29, 20. Jun. 2009 (NNZ)

Na, um so besser. Was die ruinierte Tabelle angeht: In Kamelopedia:Portal und der eingebundenen Vorlage:PortalRechts waren einfach unglaublich viele divs die irgendwo auf- und nicht wieder ordentlich zugemacht (oder woanders zugemacht) wurden und die Tabelle wurde innerhalb der Vorlage geschlossen. Ziemlich unübersichtlich und selbst wenns klappt, ist's so eigentlich nicht gedacht. Habs mal umgebaut. --J* 15:02, 20. Jun. 2009 (NNZ)

Ist ja echt irre - Tabellen auf mehrere Vorlagen verteilt... Pervers. wollen wir mal Quellenfroschung betreiben, wer hier Wiki am dollsten geschändet hat?? Naja, möchte nicht wissen, was dereinst die Wüstenarschologie von unserem Spaghetticode denken wird... -- Camel-in-a-box Mach mit! 13:39, 21. Jun. 2009 (NNZ) Schon die zeitgenössische Einschätzung kommt mitunter recht vernichtend rüber... *g*

Benutzer.js

Moin J*,
JS und CSS in deinem Kamelbau und dessen Unterseiten sind standardmäßig geschützt. Nur Du und Kameltreiber können solche Seiten bearbeiten. Die doofe Oberfläche zeigt einem das nicht an, ist aber so ... nur so als Hinweis. --BoTeule 16:11, 20. Jun. 2009 (NNZ)

Ah, danke, gut zu wissen. Naja, lieber einmal zu viel geschützt als zu wenig... Grüße --J* 16:17, 20. Jun. 2009 (NNZ)

Ka-Mel-Oh! - Programmieranfang

Hättest du Interesse, mitzuhelfen? ;)

Habe ein Projekt bei Google Code eingerichtet. Ist bisher noch reines JavaScript (mit Mootools-Framework) und kann noch nicht viel. Testen lässt sich das ganze provisorisch auf meinem Server. Keine Ahnung, was du wie kannst, aber wenn du dich dazu imstande fühlst, würde ich mich sehr über Mithilfe freuen.. --JANNiS 09:52, 25. Jun. 2009 (NNZ)

Also ganz grundsätzlich bin ich an einer Mithilfe interessiert. Die Frage ist allerdings: Was soll das Programm am Ende können? Und wie soll das umgesetzt werden? usw. Lass uns da mal irgendwie kurzschließen (chat? oder hast du vielleicht skype?) und danach irgendwo eine Brainstorm-Seite anlegen, wo wir strukturiert notieren/überlegen, wie das ganze funktionieren soll (vor allem das interne - ui geht ja noch recht einfach). Ich hatte hier auch schon irgendwo ein dingsi gebastelt, mit dem man Karten verschieben und sogar in dafür vorgesehene Felder einrasten lassen konnte (btw. mag ich js-librarys häufig nicht so gerne, zumindest wenn sie sich mit wenig code vermeiden lassen - oft sind die ziemlich groß und machen am ende doch nicht 100% was man will) Nach dem Wochenende bin ich allerdings für irgendwas zwischen 1 Woche und 8 Wochen nicht da. Grüße --J* 17:41, 25. Jun. 2009 (NNZ)

Wann immer ich am Computer bin, bin ich eig. auch im IRC (irc.freenode.net) online - nicht immer auch in #kamelopedia, aber online bin ich schon ;)

Und wegen können, alles was man als Spieler machen kann (Schaden ausrechnen, Siegpunkte zählen, Zusammenrottungen ausführen, ...) will ich auch beim Spieler lassen, weils bei so einer Kartenanzahl schlicht unmöglich ist, das alles von einem Programm machen zu lassen.

Im Grunde also nur das drumrum wie Karten verschieben und bei den anderen anzeigen (PHP & MySQL & AJAX & JSON), Stapel (Oasen) anzeigen mit Karten aufdecken, Handkarten, ... Und die Chips, die da im jetztigen Stand schon zu finden sind, die man als Spieler ja für alles mögliche nutzen kann.. So in etwa halt.

Und js-libs, mit Mootools als Framework hab ich sehr gute Erfahrungen gemacht - vereinfacht sehr viel (wie Prototyping) und bietet sehr viele JavaScript-Sachen, bei denen ich oft finde, die müssten eig. auch im richtigen JavaScript sein ;) Und man kann sich die Teile von Mootools runterladen, die man auch wirklich braucht.. Alle JavaScript-Projekte mache ich mit Mootools, wenn man was anständiges hinbekommen will, gehts bei mir fast nicht ohne.

Hast ja oben nen Link zum Source.. Bei dem Projekt hab ich jetzt Mercurial als Versionsverwaltungssystem. Hatte bisher immer SVN überall, aber hier scheint mir Mercurial ganz praktisch ;)

Schau mal, ob du mich im IRC erwischst, und ja, Skype habe ich auch. Bei Messangern hast du bei mir grundsätzlich alles zur Auswahl ;) --JANNiS 21:44, 25. Jun. 2009 (NNZ)

Monobook-Anti-Forum und Diskussionseiten-Dingens zwischen scnipp und schnapp oder so

Moin J*, ich hab neulich das Teil da von dir kopiert, leider sind Nebenwirkungen eingetreten, normale Diskussionsseiten sind so ziemlich nur noch über die Suche zu finden. Deswegen wurde das ganze unter die Erde befördert, aber anscheinend ist es zum Zombie geworden, trotzdem werden die Links nicht angezeigt... --K-3000(Hbf/Diskette) 10:35, 23. Jul. 2009 (NNZ)

Hat sich erledigt, funktioniert wieder. --K-3000(Hbf/Diskette) 20:25, 23. Jul. 2009 (NNZ)

Das mit den Diskussionsseiten ist Absicht (lässt sich aber auch umstellen) - nach dem Begraben wird's vermutlich der Browsercache gewesen sein.

???

Gibt es die Möglichkeit, wenn man auf den Reiter + klickt, dass <div style="color:#A0522D">Überschrift</div> kommt? K-3000 hat mir gesagt, irgendwas mit JavaScript, konnte mir aber nicht weiterhelfen...--f.c. 10:54, 30. Jul. 2009 (NNZ)

Öhm... Hallo erstmal! Äh - Kannst du mir das bitte etwas konkretisieren? Wo soll <div style="color:#A0522D">Überschrift</div> kommen? Im Eingabefenster? Oder möchtest du einfach alle Überschriften auf der Seite rot machen? Erzähl mir doch bitte ein bisschen mehr, dann kann ich dir vielleicht eher weiterhelfen. Grüße --J* 23:38, 30. Jul. 2009 (NNZ)

Also, würde man den Code, den ich angegeben habe, nicht in die Überschrift-, bzw. Betreffleiste schreiben, dann würde die Überschrift schwarz bleiben. Und da liegt jetzt das Problem: Schwarz auf orrangem Hintergrund sieht man schlecht, deswegen dieser Code. Meine Frage wäre: Gibt es irgendwie die Möglichkeit, diesen Code einfügen zu lassen, wenn man auf den Reiter + klickt, ohne, dass man sich selbst drum kümmenrn muss, ob der Code schon drin ist? Ich weiß, klingt kompliziert, ist vielleicht auch kompliziert, aber ich wüsste jetzt nicht, wie ich das anders schreiben könnte...vielleicht mach ichs mal im Telegrammstil, so wie ich mir das vorstelle:

1. Das Kamel, das auf meiner Diskussion ist, klickt auf den Reiter " + "
2. Wenn das Kamel also auf den Reiter geklickt hat, steht folgender Code da:
   <div style="color:#A0522D">Überschrift</div> (in der Betreffszeile)
3. Zwischen <div style="color:#A0522D"> und </div> muss das Kamel nur noch seinen Betreff angeben - fertig!

So in der Art habe ich mir es vorgestellt. Jetzt alle Fragezeichen weg, oder noch Fragen? f.c. 13:19, 31. Jul. 2009 (NNZ)

Wie ich sehe hat Wimu dein Problem schon gelöst: Das CSS sagt dem Browser einfach, dass er Überschriften grundsätzlich so einfärben soll, auch ohne den Code-Schnipsel, den du oben angegeben hast. Ich hab allerdings auch das Gefühl, dass schwarz deutlich besser lesbar gewesen wäre... --J* 17:38, 31. Jul. 2009 (NNZ)

Tach J*,

1. Fast: Nur die Frage: Ich kann einfach dann diese JavaScript-Seite als meine Disku verlinken, oda wie? ; (Farbe) Na gut, kannste ändern, wenn du's willst...
2. Jetzt meine zweite Frage (ich weiß, ich nerve): Ich habe einen externen Link (in diesem Fall www.deezer.com); und da habe ich ein Problem (Achtung, jetzt wird bissl schwer, das zu verstehen, was ich eigentlich möchte), nämlich:
   Ich habe diesen Link http://www.deezer.com/de/#music/result/all/the_final_countdown , und der Linktext soll so heißen : Und zwar* hier! (lass dich nicht von den <nowikis> irritieren). Das würde reintechnisch gehen, aber nur, wenn ich die Leerzeichen mit _ fülle, aber dann verlinkt das leider nicht auf diese Deezer-Seite, sondern zeigt eine Fehlermeldung (auf der Deezer-Seite) an.
   Was kann ich dagegen machen, dass ich den Linktext richtig anzeigen lasse?
   Hast du's verstanden, oder muss ich bissl mehr detailreicher werden? f.c. 11:07, 13. Aug. 2009 (NNZ)

Moin moin!

1. Wimu hat's ja schon komplett eingerichtet. Deine Diskussionsseite bleibt weiter deine Diskussionsseite, und die CSS-Seite schreibt dem Browser vor, den Text einzufärben. Damit das auch wirklich funktioniert, hat Wimu die CSS-Seite im Zentralregister eingetragen. Und jetzt geht alles automatisch. Voila! (Falls du mehr wissen möchtest, Schau mal bei WP, was CSS ist, oder wir treffen uns einfach mal im Chat ...)
2. Tja, ich muss jetzt etwas blind rumprobieren, weil sich die Seite auf meinem Rechner immer nur beschwert, dass kein Flashplayer installiert sei (was aber gar nicht der Fall ist):
   • So: Und zwar* hier! ?
   • oder sollen da Leerzeichen drauswerden? Dann benutz Wikis urlencode: Und zwar* hier! (das löst sämtliche derartige probleme)
   • oder schreib einfach von Hand ein + statt leerzeichen: Und zwar* hier!

Schau einfach mal, ob was passendes dabei war, ansonsten sag einfach nochmal Bescheid. Grüße --J* 17:43, 13. Aug. 2009 (NNZ)

Danke! Achso, bitte achte darauf, dass du meinen Nick nur am Anfang GROSS schreibst, und dann mit 'nem Punkt trennst, sonst gibt's leider eine Warnung (sieh' am besten selbst oder  Siehe besser nicht:  meine SIG am Ende; nur freundlich gemeint, keine Rüge o.ä. )
Is das beabsichtigt, dass dieser urlencode nicht verlinkt (du kennst ja diesen Icon - bei mir ne Hand - der automatisch kommt, wenn du auf einen Link gehst, oder?)?
Jedenfalls Danke für deine Hilfe!
--f.c. 18:27, 13. Aug. 2009 (NNZ)
P.S.:Nr. 3 von deinen Vorschlägen hat mir sehr geholfen, danke! Mööööeepp! <-- *freundlich*

(BK durch mich verursacht, nur durch die Auto-SIG?!?)

Namensraum-Statistik

Moin J*,
auf Kamelopedia:Statistik wird im Namensraumteil angegeben, dass der Projekt- und der Kamel-Namensraum jeweils einen Anteil von 0% an allen Seiten überhaupt haben. Das kann nicht sein. Auch die anderen Angaben (spez. Dateinamensraum) scheinen z.T. seltsam (mag das nicht nachrechnen, aber der einfachste Beweis ist, dass nicht hundert rauskommt, wenn man alles zusammenzählt :)). Da du Kamelopedia:Statistik/Namespace-Part erstellt hast, wollte ich nachfragen, ob dort ein Fehler vorhanden sein könnte beim Definieren der Variablen oder bei der Formel, welche die Prozentanteile ausrechnet, oder wo auch immer? -- Kam-aeleon 09:10, 5. Aug. 2009 (NNZ)

gefixt [4] --Das kleine Kamel 15:00, 5. Aug. 2009 (NNZ)

Noch da?

Hallo J* bist du noch da? Wir haben seit dem 18. Aug. 2009 nichts mehr vor dir gehört. Alles ok? --Ano-Sopu 12:26, 14. Sep. 2009 (NNZ)

Bitte melde dich! Sonst müssen wir davon ausgehen, dass du... :( --Kamelokronf 18:03, 17. Sep. 2009 (NNZ)

J*/Archiv wird seit 5604 Tagen vermisst!! In grauer Vorzeit war J*/Archiv noch da, und jetzt… da. Ja, genau da! Aber jetzt… J*/Archiv macht schon viel zu lange Urlaub. J*/Archiv hat doch jetzt lang genug entspannt und die Wüste Wüste sein lassen. Das Kamel müsste doch schon längst wieder Dung produzieren; tut es aber nicht! Wir finden das alle sehr traurig!. :"-( Hilfe, ein Stern ist vom Nachthimmel verschwunden! Gott sei Dank nur für 37 Tage vom 18.August bis zum 24. September 2009. Seitdem ist der Stern wieder da. Gez.: Die Herde. …Immer noch LEERE… Die Vermisstenanzeige ist langsam vergilbt… Aber die Herde wird dich für immer in Erinnerung behalten… Wir gedenken der Zeiten als du Kamel noch da warst und lesen ab und zu deinen Dung, Danke dafür!…

J*/Archiv ist vor 5604 Tagen spurlos verschwunden!! Und riesig war die Freude der Herde, als das verlorene Kind der Wüste am 24. September 2009 wieder aus dem Nebel auftauchte! Welcome back J*/Archiv! Ehemalige Vermisstmeldung anzeigen Ehemalige Vermisstmeldung ausblenden Und als es vermisst wurde stand dieses hier: Hilfe, ein Stern ist vom Nachthimmel verschwunden! Gott sei Dank nur für 37 Tage vom 18.August bis zum 24. September 2009. Seitdem ist der Stern wieder da.

*schluchz* --Kamelokronf 21:15, 20. Sep. 2009 (NNZ)

Hoppla! Kein Grund zu weinen, Kronf, ich bin noch da. In letzter Zeit war ich allerdings tatsächlich meistens nur kurz, unangemeldet und read-only da. Und nicht in die Box geguckt. Werde vermutlich nächstens wieder etwas öfter vorbeischaun! Grüße --J* 15:18, 24. Sep. 2009 (NNZ)

*indieluftspringunddreifachensaltomachundautsch...* ;) --Kamelokronf 15:28, 24. Sep. 2009 (NNZ)

Verschiebuns-Logbuch

18:06, 28. Sep. 2009 J* (Diskussion | Beiträge) hat „Kamelionary:Googel“ nach „Kamelionary:Koogel“ verschoben Warum? --f.c. 10:11, 29. Sep. 2009 (NNZ)

Ich antworte so gerne in fremden Boxen, weil bei mir is nix los ;) Schau mal in die Versionsgeschichte. Jemand hat einen Humorantrag gestellt, und J* hat die Verschiebung zur qualitativen Verbesserung vorgenommen. Gruß, Kamelokronf 13:11, 29. Sep. 2009 (NNZ)

Antwort da. --J* 18:28, 29. Sep. 2009 (NNZ)

Vorlage:Bild/Quelle: Locopedia

Hallo J*/Archiv,
vermutlich bist du der Erfinder der Vorlage:Bild, oder? (so steht's in der Versionsgeschichte). Ich hab mal eine weitere Vorlage für die Quelle erfunden, oder "MagicWord"(?)...kannst du da mal rüberschauen, und sagen, ob man das braucht? Danke, final.countdown™ 17:48, 3. Nov. 2009 (NNZ)
P.S.:WiMu hat mir gesagt, dass du dich mit dieser Vorlage auskennst.

Naja, Erfinder nicht wirklich. Der wahre Erfinder ist eigentlich WiMu. Aber ja, auskennen tu ich mich mit dem Ding. Über die Locopedia-Vorlage drübergeschaut hab ich, Quelltext sieht gut aus und ins Klappdings ist sie vollautomatisch eingetragen. Funzt. Falls es noch Fragen gibt, sag einfach Bescheid. --J* 01:06, 4. Nov. 2009 (NNZ)

Dir hat er das auch in die Box kopiert? Wem denn sonst noch... :-) Kameloid 03:00, 4. Nov. 2009 (NNZ)

mein Fehler ... dachte, die Vorlage müsse manuell in's Klapp-Dings eingebaut werden und hab Stronzy gesagt, er solle sich dazu bei euch melden ... --WiMu 12:25, 4. Nov. 2009 (NNZ)

Botdienste

Hallo J*, könntest du als Gebieter deiner Sockenpuppe mal wieder etwas befehlen? Es geht um zwei Aufgaben im Adventure. Zunächst sollen alle Seiten in der Kategorie unter 001, 002 etc. eingeordnet werden. Außerdem wäre eine Ersetzung von den veralteten Linkadressen ...?title=Adventure/... durch ...?title=Projekt:Adventure/... nötig. Ich weiß von keiner der beiden Aufgaben, ob sie technisch umsetzbar ist. Solltest du wider Erwarten etwas von deiner kostbaren Zeit dafür abdrücken können, wäre das erfreulich. ;) Gruß und Mööp, Kamelokronf 00:22, 7. Nov. 2009 (NNZ)

Sollte an sich kein Problem sein. Noch zwei Fragen:

• Wie soll die Nummerierung fürs Sci-Fi adventure aussehen? Oder eigene (Unter-) Kat?
• Gehts beim 2. nur um externe Links oder auch um ganz normale [[...]]-Links?

Ansonsten sollte das überhaupt kein Problem sein. Grüße --J* 00:52, 7. Nov. 2009 (NNZ)

Danke für die rasche Antwort! Das SciFi-Adventure kann eigentlich in der gleichen Kat bleiben, aber dann ein Präfix erhalten (vllt. "SciFi 001" o.ä.). Die internen Links hat der Maliobot damals zusammen mit der Verschiebung erledigt, aber die externen hat er so hinterlassen; es müssten also nur diese noch umgestellt werden. Gruß, Kamelokronf 15:40, 7. Nov. 2009 (NNZ)

Der Vorteil einer eigenen Unterkat wäre halt, dass dann nicht alle SciFis geschlossen unter S eingeordnet würden. Ist aber vielleicht auch nicht so schlimm. --J* 22:20, 7. Nov. 2009 (NNZ)

Done (: --J* 11:48, 9. Nov. 2009 (NNZ)

Super, danke :) --Kamelokronf 14:41, 9. Nov. 2009 (NNZ)

Bräuchte mal wieder dein Rad ...

Hi, J*

bin gerade mal wieder am javascripten ... könntest du mir kurz und knapp erklären, wie ich per ajax die MediaWiki-API ansteuere? Ich bräuchte eigentlich nur eine Funktion, die mir zu einem Bildnamen die passende URL ausspuckt (bei der komischen Ordnerstruktur blickt ja niemand durch ... oder du etwa?). Also schlicht {{filepath:Bildname.jpg}} bloß per javascript. Dank im voraus; Grüße, --WiMu 00:02, 20. Nov. 2009 (NNZ)

Da durchzublicken ist absolut unmöglich.

Für wie man die API benutzt, schaut man am besten auf der API ihrer eigenen Seite: http://kamelopedia.net/api.php. Ganz konkret gibt es da die action=expandtemplates:

http://kamelopedia.net/api.php?action=expandtemplates&text={{filepath:Nacht.png}}

Und dann kann man noch mit format= das Format einstellen. Für Javascript würde ich da json empfehlen (das ist dann nämlich quasi javascript).

Mein Ansatz war damals die libwiki ... die macht das an der Stelle noch ohne API, die konnte das damals nämlich noch gar nicht. Vielleicht lieber nicht einfach so übernehmen ...

Grüße J*

geil :-) ... das ist ja wirklich suuuper einfach. Was haben wir uns damals mit der Bildsuche eins abgebrochen mit Seiten pseudoeditieren und Krams ... --WiMu 02:45, 20. Nov. 2009 (NNZ)

secureHTML

Hi, J*

Ich hab' in letzter Zeit ja viel mit der Extension gemacht und dabei immer unsere Sicherheitsbedenken im Auge gehabt – also jeden Parameter, den man an eine Vorlage übergeben kann erstmal durch {{#replace:{{blablubb}}|"}} und os gejagt. Just in diesem Moment ist mir klar geworden, dass nicht die secureHTML-Extension an sich, sondern deren gesamtes Konzept eigentlich vollkommen für'n A**** ist. Also: <html> kann man nur auf geschützten Seiten verwenden ... soweit, so gut. Will man nun Parameter an eine solche geschützte Seite übergeben, muss man das mit {{#shtm:blahblubb|irgendwas machen; auch gut. Das {{#shtml: muss nicht auf einer geschützten Seite sein ... und da ist der Haken. Unsere Bedenken bezogen sich bislang immer darauf, dass man mit den Parametern auch Schadcode übergeben könnte, was sich aber durch {{#replace:{{blablubb}}|"}} verhindern lässt. Aber was viel schlimmer ist (mir gerade erst klar geworden): jeder (auch nicht-Administratoren) kann ja nun eine Vorlage per {{#shtm:blahblubb|irgendwas aufrufen ... und mit dieser machen, was er will! Alles was an die Vorlage übergeben wird, wird als raw-HTML interpretiert (zumindest soweit das die Extension mit ihren ganzen bugs verkraftet). Naja, wollte ich nur kurz loswerden, bevor ich das wieder vergesse ... muss mir das mal durch den Kopp gehen lassen, ob sich eine sichere Lösung machen lässt ... --WiMu 22:46, 10. Dez. 2009 (NNZ)

Ich sag ja schon länger, dass die Extension ein einziger Dunghaufen ist... wenn ich mich recht entsinne, hatte ich da doch mal eine Alternative entworfen - allerdings müsste man die erstmal ausgiebig testen und auf Lücken prüfen. Vielleicht könnte man das ja mal in irgendeinem Testwiki zum Laufen bringen ... --J* 23:08, 10. Dez. 2009 (NNZ)

Ich bin ja nach wie vor der Meinung, dass es möglich sein müsste, das <html>-tag (das es ja in jedem MediaWiki gibt, das aber im Normalfall deaktiviert ist) auf den MediaWiki-Namensraum zu beschränken. Und wenn an Seiten, die <html> oder {{#tag:html bzw. {{#html benutzen, Parameter übergeben werden, kommen die halt erst durch htmlentities() oder sonst irgend eine PHP-Funktion, die allen Schadcode entfernt. Kann doch nicht so schwer sein ... Naja, PHP muss ich noch in in meinen Kopp kloppen und Wikis sind nicht unbedingt der leichteste Einstieg --WiMu 02:30, 11. Dez. 2009 (NNZ)

Ganz so einfach ist's leider nicht, denn um mit Wiki HTML auszugeben muss man den Parser etwas austricksen. Und zwar indem man der Funktion $parser->insertStripItem das HTML übergibt - die dafür nur eigentlich nicht gedacht ist, denn die benutzt eigentlich der Parser selbst um Objekte einzufügen, bei denen fett, kursiv, Links etc. schon ersetzt sind, aber noch keine Absatzzeichen wie \n: \n* usw. - die dürfen im HTML also nicht mehr drinne sein. Und Parameter muss man, wenn die Formatierungen enthalten können sollen, mit Wikiparser vorparsen, sonst nur ganz bestimmte Zeichen erlauben (z.B. für Attribute in Tags, nicht dass das HTML invalid wird) usw. Wie gesagt, das alles hab ich mit dem oben schon beschriebenen Ding mal probiert.

Klar darfst du gerne auch noch etwas rumprobieren - aber danach wirst du mehr von Wikis Innenleben wissen, als dir lieb ist (-; --J* 18:45, 14. Dez. 2009 (NNZ)

neues KlippKlapp

Mööeepp!

Wir wollten doch immer, dass sich bei diesem KlippKlapp-Zeug das wegklippklappt, auch wenn man irgendwo sonst hinklickt (nicht nur auf den klippklapp-link). Hab' ich nun für die neue Vorlage:GaGA gebaut ([] Gedöhnse). Bin mir etwas unsicher (funktionieren tut's einwandfrei ... mit ein wenig Geschwurble, damit sich auch geklippklappte links noch anklicken lassen). Ist irgendwie viel kürzer als des alte skript (das natürlich immer noch tut). Magste da mal drübergucken? Hab' ich irgendwas übersehen? Wollen wir das alte script auch so machen, so dass nur noch eines übrig bleibt?

Bin schon wieder weg ... --WiMu 17:00, 14. Dez. 2009 (NNZ)

GaGA-Zeugs

Du wolltest ja, dass man das in deinem Bau diskutiert, also hier noch 'ne Kopie nur für dich:

„… nämlich dass ich indirekt auch meine Stimme geben muss (wenn ich eine gebe) für etwas, das ich nicht kenne (nämlich den Artikel von morgen) und dass ich die dann erst aktiv widerrufen muss, damit ich das nicht mehr tue“ ... ganz genau so ist es im Moment! Gibst du deine Stimme bei einer Wahl (nach den derzeitigen Statuten) ab, gilt die ebenfalls bis in alle Ewigkeit, oder bis irgend jemand den Artikel neu wählen lässt. In letztem Fall wird die Stimme – ob du das willst oder nicht – ungültig. Wenn du deine abgegebene Stimme revidieren willst, bis du nach den jetzigen Regeln noch viel mehr dazu gezwungen, dies aktiv zu tun, denn du müsstest dazu eine Neuwahl starten und damit zwangsläufig auch alle anderen Stimmen für ungültig erklären. Da ist doch irgendwo ein Haken in deiner Argumentation --WiMu 14:49, 16. Dez. 2009 (NNZ)

Natürlich kanns mir auch beim aktuellen Modell passieren, dass meine Stimme irgendwo bis in alle Ewigkeit steht (beim neuen steht sie da aber immer bis ewig). Warum ich aber mit den jetzigen Regeln "noch viel mehr" gezwungen bin, das zu tun, ist mir nicht ganz klar. Bei den jetzigen Regeln kann ein beliebiges Kamel eine Neuwahl starten und die alten Stimmen für ungültig erklären (damit ist meine Stimme, die auf veralteten Tatsachen beruht dann weg). Beim neuen Modell kann es nur mit Pro stimmen - aber meine Stimme bleibt immer noch stehen. Ich bezieh mich ja vor allem auf den Fall, dass ich die (Neu-) Abstimmung nicht verfolge / inaktiv bin / die Herde verlassen habe / aus irgendwelchen anderen Gründen nicht aktiv am Wahlprozedere des überarbeiteten Artikels teilnehme ... So, langsam verschwurbelt mir aber auch der Kopf ...! Grüße --J* 17:19, 16. Dez. 2009 (NNZ)

Hehe... das ist unser Ziel. Alle klugen Köpfe verschwurbeln, und dann - zack, Weltherschaft. Hehe... --Kamelokronf 17:26, 16. Dez. 2009 (NNZ)

Ach, darum geht's (: Na dann! --J* 17:34, 16. Dez. 2009 (NNZ)

Alt: du hast deine Meinung zu einem Artikel geändert -> Musstu Neuwahl starten; damit zwingst du die komplette Herde ebenfalls neu zu wählen, vier Wochen zu warten und überhaupt das ganze Prozeder von vorn (willste das wirklich?)
Neu: du hast deine Meinung zu einem Artikel geändert -> dann ändere halt deine Stimme. Feddich.

Alt: ein anderes Kamel hat seine Meinung geändert -> Neuwahl starten; damit zwingst es dich und die komplette Herde ebenfalls neu zu wählen, vier Wochen zu warten und überhaupt das ganze Prozeder von vorn. Biste nicht mehr aktiv, aber wärest heute noch der gleichen Meinung wie damals? Pech gehabt.
Neu: ein anderes Kamel hat seine Meinung geändert -> dann ändert es halt seine Stimme. Feddich. Biste noch aktiv, kannste dir ja dein Votum auch nochmal überlegen, biste nicht mehr aktiv, aber wenn du es wärest, wärst du heute Anderer Meinung? Dann und nur dann wäre das nicht in deinem Interesse.

P.S.: nach BK: diese Seite ist 125kb groß ... also nicht über die läppischen 40kb vom Forum beschweren --WiMu 17:45, 16. Dez. 2009 (NNZ)

Auftrag

moin J*,
bitte schütze diese Seite (wg. secureHTML)
danke, f.c. 10:41, 19. Dez. 2009 (NNZ)

bitteschön! --J* 17:08, 19. Dez. 2009 (NNZ)

danke! weitere Videos folgen bestimmt noch^^naja, muss halt gucken, ob ich welche finde^^...aber das WEB.de diesen "Code" wie bei YouTube nicht hat, is ärgerlich...jeder macht's unterschiedlich...egal was man benutzt im Alltag is irgendwie geDINt^^ich auch^^ f.c. 17:30, 19. Dez. 2009 (NNZ)

Kettenmail

tach J*, deine Änderung verstehe ich nicht...Bitte um Auskunft, danke! f.c. 12:07, 31. Jan. 2010 (NNZ)
P.S.:Dein JeLuF ist richtig toll geworden, dafür funtkiniert bei Datei:Wiki.png die neue Version nicht! [5]

Um ehrlich zu sein - ich verstehe die Änderung auch nicht. Eigentlich sollte da nur das {{sa}} unten rein ... Bei mir funktioniert die neue Version bei Wiki.png - eventuell mal den Browser-Cache leeren? Grüße --J* 12:17, 31. Jan. 2010 (NNZ)

okay, versuch ich mal^^MfM, f.c. 12:18, 31. Jan. 2010 (NNZ)

okay, hat gefunzt *freu*...f.c. 12:20, 31. Jan. 2010 (NNZ)

*auchfreu* --J* 12:21, 31. Jan. 2010 (NNZ)

Kennste das schon?

gerade entdeckt *geil* --WiMu 20:51, 8. Feb. 2010 (NNZ)

Allerdings! (Ne, kannte ich noch nicht). Aber welcher Browser kann schon CSS3 ... --J* 23:06, 8. Feb. 2010 (NNZ)

Projekt-Teaser

Super Idee. :) --Kamelokronf 13:43, 12. Mär. 2010 (NNZ)

Danke. Jetzt müsste man nur noch die ganzen Projekte auch wirklich verteasen ... --J* 13:50, 12. Mär. 2010 (NNZ)

Hm... Kamelopedia:Projekte könnte man eventuell auch ... mal drüber nachdenken --J* 14:10, 12. Mär. 2010 (NNZ)