Beiträge von E. G. Aal

Also, erst einmal vielen Dank für das Lob und zum Zweiten jetzt ein Paar Ergänzungen zum ersten Testbericht:

Die PN-Funktion
Sie ist vorhanden und funktioniert. Was will man mehr Der Admin kann Nutzern erlauben/verbieten PNs zu verschicken, er kann ferner erlauben, nur Nutzern aus dem eigenen Land PNs zuzusenden, auch wenn mit kein Szenario einfällt, wo diese Einstellung sinnvoll wäre.

Die Styles/"Skins"
Wie schon oben geschrieben, gibt es nicht so wahnsinnig davon. Die meisten sind auch noch konvertierte WordPress-Skins, teils von komerziellen Anbietern. Ob das legal ist?

Außerdem machen diese Skins Probleme: So ist häufig die PN-Funktion nicht angepasst, was bei Styles mit heller Schrift auf dunklem Hintergrund Probleme macht, da einerseits die helle Schrift übernommen wird, andererseits die PNs, wie es der Standard vorsieht, auf hellgrauem Hintergrund dargestellt werden.

Außerdem gibt es die css/html-Elementgruppe (?) "clear". Diese wird in WordPress für ausgeblendete Elemente verwendet, in b2evolution für Elemente wie etwa den PN-Text oder die Password-Felder der Password-Änderungsfunktion im Profil. Dies führt dazu, dass dann die entsprechenden Elemente, da im css als "overflow:hidden" formatiert, vom Webbrowser in ihrer Darstellung unterdrückt werden. D.h. der Passwort-Änderungsbereich im Profil besteht dann nur noch aus dem "Passwort-Ändern"-Knopf, wenn man ihn drückt, erhält man die Fehlermeldung, man solle das aktuelle und das neue Passwort doch bitte eingeben, was jedoch nicht nöglich ist, da die entsprechenden Felder immer noch nicht da sind.

Beide Änderungen müssen manuell in der css-Datei des Skins durchgeführt werden.

Das Baukastensystem

Wie bereits beschrieben, kann man einzelne Elemente, wie etwa Kalender, Wer-Ist-Wo-Online-Felder, Kategorienbaum, Link zum Profil und zu den PNs und ein Dutzend anderer Sachen nach Belieben verteilen. einige Elemente sind dabei eher unpassend dargestellt und benötigen eigentlich einer optischen Korrektur, aber das sei dahingestellt.

Außerdem kann man die Elemente sehr einfach hinzufügen (Zwei Klicks pro Element) deaktivieren oder löschen (je ein Klick pro Element). Wenn man ein Element löscht, und es nicht noch einmal (aktiviert oder deaktiviert) vorhanden ist, kann es möglicherweise (sicher bin ich mir da nicht) passieren, dass man es nicht wieder einfügen kann. Außerdem kann man Elemente nur am Ende/am rechten Rand einer Leiste einfügen und auch keine Elemente zueinander verschieben. Daher muss man, wenn man etwa bei einer Seitenleiste mit 10 verschiedenen Elementen ein neues hinzufügen will, welches ganz oben erscheinen soll, zuerst das Element hinzufügen (2 Klicks) und dann alle bereits vorhandenen Elemente in der richtigen Reihenfolge hinzufügen (2*10 Klicks plus eventuelle Fehlklicks) und dann alle alten Elemente wieder löschen (10 Klicks), macht in Summe 31 Klicks. Reichlich ineffizient

Im Übrigen noch eine positive Nachricht: Man kann auf diese Weise auch Sachen wie den Login/Registrierungs-Bereich hinzufügen, sodass ein oben bestehendes Problem dadurch korrigierbar ist!

Die Benutzerrechteverwaltung

Auch diese habe ich mir genauer angeschaut und tatsächlich eine sinnvolle Einstellung nicht gefunden: Man kann zwar Benutzern erlauben, alle/die eigenen Beiträge/Kommentare oder nur die von niederrangigen Benutzern bearbeiten lassen (der Admin ist höherrangig als der Moderator, der Moderator ist höherrangig als der Autor), aber beim Löschen kann man nur das Löschen für ALLE Beiträge/Kommentare erlauben, oder für ALLE Beiträge/Kommentare verbieten. Das ein Nutzer nur die eigenen Beiträge/Kommentare löschen kann, ist nicht vorgesehen.

Die Datenbank-Tabellen
Zum Schluss noch ein Kritikpunkt, der zwar nicht von breitem Interesse ist, aber doch ganz interessant: Selten eine so unaufgeräumte Datenbankstruktur gesehen: Das Ding kommt mit 81 Tabellen daher (für phpBB genügen 67), die zudem auch noch seltsam benannt sind: Wer hätte gedacht, dass die Beiträge in der Tabelle "evo_items__item" versteckt sind, wenn sie im Quelltext/in den Diskussionen nirgens sonst als "items" bezeichnet werden? bei einigen Tabellen, wie etwa "evo_messaging__contact_groups" erschließt sich mir der Sinn nicht ganz. Vermutlich kann man ganze Gruppen als Kontakte hinzufügen, und diese werden darin gespeichert Dies macht vermutlich auch den Bau eines Importers etwas aufwendiger, daher gibt es laut Homepage auch nur genau zwei Importer für Daten anderer Software, bei beiden Formaten (LiveJournal und OPML handelt es sich (lt. Pluginbeschreibung) um Formate von Blog/Newslettersoftware, zu denen es verutlich auch keine Konvertierer aus Forensoftware gibt. Außerdem gäbe es hierfür noch das Problem der Namensverwaltung: Die Loginnamen von b2ecolution enthalten keine Leerzeichen, die "richtigen" Namen sind auf Vor- und Nachname aufgeteilt. Wie bringt man dann der Software bei, welchen Namen sie nun zu verwenden hat und wie teilt man allen Nutzern den "neuen" Loginnamen mit?

2. Funktionsweise und Konfiguration

Die Software ist so aufgebaut, dass der Admin (oder von ihm Berechtigte) relativ schnell in der Lage sind, sogenannte "Sammlungen" anzulegen. Diese können entweder Blogs, Foren, Wikis oder Anderes sein. Diese teilen sich gemeinsam die Benutzer- und Gruppenlisten, die zur Verfügung stehenden Plugins und Styles (letztere bei b2evolution "Skins" genannt) und einige grundlegende Einstellungen. Dies ist zwar ganz praktisch, da es so möglich ist, etwa z.B. mal eben schnell einen Blog für eine Zeitung anzulegen und den zukünftigenRedakteuren die Editionsrechte zuzuteilen, hat aber den Nachteil, dass prinzipiell jegliche Menüs vom Namen her doppelt vorhanden sind (einmal global und einmal für die jeweilige Sammlung), aber dann jeweils unterschiedliche Einstellungen bieten; optisch ist leider nicht immer so einfach zu erkennen, wo im großen Einstellungsgewirr man sich gerade befindet.

Wenn man eine neue Sammlung startet, kann es dazu kommen, dass diese nicht angezeigt werden kann. Die Ursache ist technischer Natur, sie liegt darin, dass es zwei Möglichkeiten gibt, Webseiten in der Linkzeile Parameter mitzugeben. Die eine hat die Form www.mn-wiki.de/index.php?title=Hauptseite, hier wird explizit der Seite "www.mn-wiki.de/index.php" der Parameter "title" auf den Wert "Hauptseite" gesetzt. Die andere hat die Form de.wikipedia.org/wiki/Hauptseite, auch hier wird bei der Seite "de.wikipedia.org/wiki/index.php" der Parameter "title" auf den Wert "Hauptseite" gesetzt, während dem Nutzer suggeriert wird, es handle sich um ein Dokument mit dem Titel "Hauptseite", welcher im Ordner "de.wikipedia.org/wiki/" läge. Diese implizite Parametersetzung, bei b2evolution die Standardeinstellung, muss vom Webserver explizit erlaubt werden; dies war bei mir nicht der Fall, weshalb tatsächlich nach einem (nicht vorhandenen) Dokument gesucht wurde (das dann natürlich nicht gefunden wurde); daher müssen bei jeder neuen Sammlung zunächst einmal die Links korrigiert werden, was allerdings niocht nur recht einfach, sondern auch recht flexibel möglich ist – wenn man die Stelle im Administrationsbereich einmal gefunden hat, kann man zwischen einer großen Menge verschiedener Kombinationen auswählen.

Überhaupt ist die Software sehr flexibel konfigurierbar; mit dem Problem, dass man erst einmal den richtigen Ort im Admin-Bereich finden muss. Es ist zwar bei vielen Konfigurationsbereichen eine Verlinkung zur entsprechenden Selle des Benutzerhandbuchs angelegt, leider ist dies nicht in allen Punkten ausführlich, einige Handbuchseiten sind sogar nicht vorhanden oder leer.

Zur Funktionsweise ist noch eine andere Sache zu sagen: Man kann/muss den Sammlungen einen Typ zuweisen, dieser ist "Blog", "Forum" oder "Manual" (es gibt noch ein paar andere Möglichkeiten, aber diee sollten für die MNs weniger von Belang sein), Hierbei ist jedoch zu sagen, dass die Unterschiede nur in der unterschiedlichen Verteilung der Standardrechteverteilung und der Optik sind, technisch gesehen sind auch die "Foren" nur Blogs, bei denen der erste Beitrag im Thread als Blogpost, alle Antworten auf diesen als Kommentare betrachtet werden. Da die einzelnen Elemente zwar im Baukastensystem an- und ausschaltbar sind, es aber letztendlich vom Style/Skin abhängt, welche der ausgewählten Beiträge tatsächlich angezeigt werden, werden für Foren spezielle Foren-Skins benötigt; hier gibt es in den Weiten des Internets nur etwa vier verschiedene, so dass man entweder damit leben muss, dass die Optik des Forums und des Blogs/der Hauptseite sich grundlegend unterscheiden, oder man selbst Hand anlegen muss.

Dieses durch den Skin beeinflusste Baukastensystem hat noch einen weiteren Nachteil, da bei einigen Skins bestimmte Elemente nicht oder zwingend vorgesehen sind, so gab es einen Skin, der keinen Link zum Anmelde/Registrierungsformular bot {Korrektur: Man muss diesen Link explizit im Admin-Bereich setzen} oder einen, der mir unbedingt noch eine unbebötigte, hässliche Randspalte aufdrängen wollte.

Ein "nettes Feature" ist die Regionalauswahl: Die Nutzer können sich ihr Herkunftsland inkl. Region auswählen, bestimmte Dinge, wie etwa die vom Nutzer bevorzugte Währung werden automatisch daran angepasst (welche praktischen Auswirkungen das auch immer haben mag). An sich eine ganz gute Idee, wer als Admin die Energie hat, alle RL-Länder, amerikanischen Bundesstaaten und französischen Departements einzeln zu entfernen, danach durch MNs, ihre Regionen und Währungen zu ersetzen und die Liste längerfristig aktuelle zu halten, hat auf jeden Fall etwas Einmaliges :D.

3. die Benutzeroberfläche und das Nutzerprofil

Im Gegensatz zum Administrationsportal ist die Benutzeroberfläche nicht nur vollständig übersetzt, sondern auch einfach bedienbar. Auffällig ist hierbei das Namenssystem: Jeder Nutzer hat einen Loginnamen, welcher kein Leerzeichen enthalten darf, daher nicht dem ID-Namen entsprechen kann. Dafür erhält er Benutzerfelder, wo er seinen Vor- und Nachnamen sowie Spitznamen angeben kann, die aber nicht auf Einmaligkeit überprft werde, es kann also eine beliebige Anzahl von Namensvettern geben. Der Admin kann einstellen, dass 1. anstelle des Loginnamens der "richtige Name" oder, wenn vorhanden der Spitname angezeigt wird, und 2. bereits bei der Registrierung der Vorname angegeben werden kann/muss. Eine Angabe des Nachnamens bei der Registration ist nicht einstellbar, hier muss selbst Hand angelegt und der Code manipuliert werden (auch wenn es Ansätze im Code gibt, die darauf hindeuten, dass sich dies in zukünftigen Versionen ändern könnte)

Ich konnte es, ohne mich im Detail mit dem Programm auseinander zu setzen, nur erreichen, dass man den Nachnamen angeben kann, eine Verpflichtung dazu konnte ich nicht erreichen (was aber auch für die MNs ganz praktisch sein kann)

Normalerweise enthält das Profil dieVerfügbarkeit von Links zu allen möglichen Messengern und sozialen Netzwerken (inkl. github); letztere sind beim Admin-Konto sogar auf die Seiten der Softwareentwickler eingestellt, die Profilfelder können allerdings von der Administration geändert und entfernt werden, ihr Inhalt ist in der Regel von jedem Nutzer anpassbar.

Zusätzlich zu den vom Skin beeinflussten Teilen der Sammlung gibt es noch zwei globale Leisten, welche allerdings treisterweise von manchen Skins unterdrückt werden und dadurch zu Funktionseinbrüchen führen können(s.o.): Die untere, breite schwarze Leiste, die auch in der oben verlinkten Demo zu sehen ist, beinhaltet die einzelnen Sammlungen und den Registrierungslink. Für Blogs zwingend notwendig, um Beiträge zu erstellen ist noch eine schmale graue Leiste oberhalb dieser, von der aus zwischen "Front-Office" (normaler Ansicht) und "Back-Office" (enthält, je nach Nutzergruppe das gesamte Admin-Portal, die (bei Blogs einzige!) Möglichkeit, Beiträge zu erstellen oder alles Mögliche dazwischen). Diese Leiste und der Zugriff fürs Back-Office müssen bei Blogs explizit zur Verfügung gestellt werden, sonst kann der Nutzer, auch wenn er eigentlich Schreibrechte für den jeweiligen Blog hat, keine neuen Einträge erstellen (bei Foren ist dies nicht notwendig, zum Kommentieren von Blogs auch nicht)

Noch ein weiterer Unterschied ist zu Standart-Foren-Software auffällig: b2evolution unterscheidet nicht zwischen Profilbildern und Avataren, der Nutzer kann beliebig viele (?, auf jeden Fall mehrere) Profilbilder hochladen, das erste dieser Bilder wird als Avatar gewählt.

Nach entsprechender Einstellung kann dann der Nutzer selbstständig Beiträge verfassen und formatieren, hierzu verwendet das Forum standardmäßig html – um dies auf BB-Code umzustellen, muss der Admin 1. die Verwendugn von BBCode global erlauben und 2. für jede Sammlung (und jeden Beitragstyp) einzeln die Ausführung von html verbieten. Außerdem sollte der Admin seinen Nutzern auch die Verwendung von css verbieten, da diese sonst den gesamten Forenstil kaputt machen können. Dies geht glücklicherweise global in der Gruppeneinstellung.

4. Fazit

Die Software ist für die meisten Nutzer angenehm zu bedienen; ds einzige Problem ist die Administration, wer die Software einsetzen will, sollte zunächst eine Testinstallation durchführen, dort mehrere Benutzer (für mehrere Gruppen) anlegen und ein paar Tage an der Konfiguration herumprobieren. Eine Migration von klassischen MNs nach b2evolution lohnt sich nicht, da es keinen Importer für Foren-Datenbanken gibt. Auch ein ID-Switcher müsste noch programmiert werden Für experimentierfreudige Multi-Blog-Staaten, die auch auf ein kleiens Forum für Bedarfsfälle/Außenpolitik nicht verzichten wollen, kann die Software jedoch gut geeignet sein.

Homepage von b2evolution
Kurzüberblick über die Software auf Wikipedia

Auf Basis einer von de Rossi angestoßenen Diskussion über Blogstaaten war ich neulich auf der Suche nach geeigneter Software dafür. Natürlich, es gibt WordPress (+Plugins), welche der mit einem gewissen Abstand vor Typo3 und Joomla die wahrscheinlich verbreitetste Software für diese Zwecke herstellen. Aber ich wollte schauen, ob es vielleicht kleinere Anbieter gibt, die ähnlich gut geeignete, wenn nicht gar geeignetere Software anbieten. Dabei stieß ich auf b2evolution, eine kostenlose Open-Source-Software, die laut Anbietern in der Lage sein soll, mehrere Blogs, Foren und "manuals", also wiki-artige Handbücher, gleichzeitig anzubieten.

Bislang beschränkt sich meine Erfahrung mit Web-Administration auf ein paar Wochen Aushilfsadmin in einer MN mit WBB, dem Erstellen eines Forums auf irgendsoeiner "bastel dir dein eignes Forum in fünf Schritten"-Seite, sowie auf Versuche, MyBB und phpBB aufzuschrauben, um sie multi-ID tauglicher zu machen. Mit Blogsoftware hatte ich also keine Erfahrung.

Nun zum Test der Software, die nicht auf einem Produktivsystem, sondern "nur" auf einem Test-Webspace stattfand und nicht mehr über das Internet zu erreichen ist.

1. Installation

Die Software benötigt im Prinzip nur php und MySQL. Sie braucht einige Bildbearbeitungsfunktionen für php, bie denen ich mir nicht sicher bin, ob diese generell von php mitgeliefert werden oder auf dem Test-Webspace freundlicherweise vorinstalliert waren, auch weiß ich nicht, was passiert, wenn diese nicht installiert sind.

Auffällig ist die seltsame Installationsroutine: Im Gegensatz zu handelsüblicher Forensoftware genügt es nicht, für die Erstinstallation die Startseite der Software aufzurufen, sondern stattdessen muss die Seite "http://installationspfad/install/index.php" explizit aufgerufen werden. Danach kann/muss man in einer relativ simple gehaltenen Installationsroutine so Sachen wie die Sprache oder die Datenbankverbindung konfigurieren. Außerdem kann man zwei Dinge auswählen: Ist die installation eine lokale Installation oder eine "richtige" – wobei ich nicht ausprobiert habe, worin da der Unterschied liegt, und sollen bereits Testdaten vorinstalliert werden. Diese Testdaten beinhalten zwei Blogs und ein Forum mit einer Hand voll Beiträgen und eine Reihe von Nutzern mit Babyfotos als Benutzerbilder. Sie sollen dazu dienen, die Software kennenzulernen und sind auch im Internet unter http://demo.b2evolution.net/ als Test abrufbar. Da es eine ganze Reihe von Sachen sind, die dann auch einzeln gelöscht/deaktiviert werden müssen, sollten diese für ein Produktionssystem abgewählt werden.

Am Ede der Installation wird der Admin angelegt, dieser erhält einen vorgegebenen Benutzernamen und ein zufallsgeneriertes Passwort, beie können jedoch nach der Installation jederzeit geändert werden.

Im Anschluss an die Installation wird wie bei jeder Web-Software empfohlen, das "install"-Verzeichnis der Installation zu löschen.

Zitat von Viktor Kaschinski

Viel zu liberal. 1 Japan. 1 USA. Ein Deutschland.

aber immerhin ein vÄquatorialguinea

Wenn du dir mal die Beiträge angeschaut hast, die dort im vergangenen halben Jahr so geschrieben wurden, kannst du nicht mehr wirklich von Sim sprechen…

Edit: Gut mit Ausnahme eines Stranges. Daher ist da wirklich noch ein Rest Aktivität…

Zum Thema Polit-Sim: Das geht auch ohne Forum. Hörntal hat das damals versucht und das es gescheitert ist, lag nur sekundär daran, dass keiner aus dem Ausland mitsimmen wollte, sondern dass das dahinterstehende Staaten/Kulturkonzept seltsam und daher die eins, zwei Leute, die Interesse hatten staatsbürgerschaftlich aktiv zu werden, entsprechend vergrault wurden. Das damals vorgestellte Grundkonzept (Simulation ausschließlich in fremden Foren als "Ausländer") und das System der Blogstaaten lässt sich auch miteinander kombinieren. Man tritt im Ausland auf und das Innenleben wird in einem Blog abgehandelt…

Wenngleich noch nicht viel da war, aber auch der Hansebund ist down.

Im Gegensatz dazu laufen andere Doren (Der Marktplatz etwa oder Chinopien) auf WBB4 und ganz normal…

Wobei mittlerweile die Binnen-Markierungsschreibweise nicht nur für Personen gilt: An der mitteldeutschen Uni gab es mal eine Broschüre, in der von VerhandlungspartnerInnen gesprochen wurde – und gemeint waren nicht etwa die verhandelnden Personen nein, das Binnen-I war nötig weil zwischen dem (maskulin) Student*$?~_[]Innen-Rat und der (feminin) Bahn über ein Semesterticket verhandelt wurde

Aber erstere Vereinigung hat auch bei Diskussionen die Regel eingeführt, dass Aufgrund von Gleichberechtigung nach einem Beitrag eines männlichen Diskussionsteilnehmers der eines (oder einer?) weiblichen kommen muss (und umgekehrt).

Derzeit (d.h. seit Anfang 2014 und bis auf weiteres) wird zumindest von mir nichts mehr weiterentwickelt. (Ich bin auch seit Anfang des Jahres nicht mehr in den MNs aktiv gewesen…).

Ich würde mich sehr freuen, wenn jemand anders die Entwicklung übernehmen würde. (Obgleich ich weiß, dass das bei meiner umwerfenden Kommentierung und meinem unglaublichen Englisch zur Benennung der Funktionen etc. zeimlich schwer werden dürfte)- Auch werde ich mich selbst sicher irgendwann wieder an der Entwicklung beteiligen, aber wohl nicht mehr in diesem Jahr.

Ich hatte zwischendurch auch schon mal überlegt, den ganzen Kram komplett neu zu schreiben, und mir diesmal von vornherein gleich sinnvollere Algorithmen zum Spielablauf zu überlegen (und mir sogar ein (relativ brauchbares) Buch zu dem Thema versorgt), aber dann kam wieder was dazwischen, so dass ich es sein gelassen habe. Aber falls e jemanden interessiert, es handelt sich bei dem Buch um Tolan, Mehin: So werden wir Weltmeister. Die Physik des Fußballspiels. 3. Auflage München u.a. 2010. Gibt es bereits für unter 10 € gebraucht im Internet.

Zitat von Márton Mechtl

Ich weiß, dass Timbleed Erfahrung braucht. Ich habe endlich 4 Mitspieler gefunden und das ist ja auch schon mal was
Das mit dem eigenen Blog hab ich mir auch überlegt, nur das ließt keiner und dann ist es eh sinnlos.

Es gibt auch die recht weit verbreitete Variante, dass irgendwo eines der obersten Unterforen der MN als "Nachrichten"-Forum verwendet wird, in dem Geschehnisse im Nachrichtenstil als virtuelle Zeitungsartikel oder Nachrichtensendungen gepostet werden.

Da ich Ende Januar/Anfang Februar wahrscheinlich hier Zeit zum Weiterentwickeln haben werde und nicht jeder (mich eingeschlossen) hier jeden Tag vorbei schaut möchte ich mal eine Umfrage an die Benutzer starten, um anhand der Ergebnisse zu entschieden, welche Funktionen ich einbauen könnte/sollte bzw. ob sich eine Weiterentwicklung überhaupt lohnt und ich nicht eher ein ganz anderes Programm schreiben (oder etwas ganz anderes tun) sollte.

1. Wie wird das Programm verwendet? (lokales Testsystem/ Testsystem im Internet/ produktiv)
2. Wie stark wird das Programm in die Simulation eingebunden?
3. Wäre eine automatische Einbindung ins Forum erwünscht? (in der Form, dass 1. die Einstellungssachen ins Foren-ACP verlagert werden und 2. die Veröffentlichung der Beiträge als Foren-Post geschehen) Wenn ja, für welches Foren--System?¹
4. Wäre ein Umbau / eine Erweiterung für andere Sportarten erwünscht? (in der Form, dass bei der Erstinstallation die Sportart ausgewählt werden kann und das Programm sich dann automatisch so konfiguriert, dass die Einstellungen an die Sportart angepasst sind) Wenn ja, für welche Sportarten?
5. Wie wichtig wären die oben angekündigten Modifikationen? (Einstellbarkeit der Wochentage der Ergebnisbekanntgabe, Verwendung aller Ortsnamen bei der Mannschaftsgenerierung, Erweiterbarkeit auf mehrere Saisons)
6. Wäre die stärkere Auskommentierung des Quelltextes erwünscht²?
7. Welche sonstigen Erweiterungen wären erwünscht?
8. Gäbe es Interesse an einem der folgenden Programme:

• Gerenator/ Ersteller für Fahnen und Wappen
• Malprogramm für Karten³

*******
¹ Bei Wbb-nichtlite und anderen kostenpflichtigen Forensystemen wäre dazuzusagen, dass ich dort nur entwickle, wenn es irgendwo eine Dokumentation für Mod-Entwickler gibt. Und auch in diesem Fall wäre die Enwicklung ungetestet, da ich kein Forum (weder in Bezug auf die MNs noch außerhalb) habe/administriere und dies auch nicht plane. Ich müsste mir daher eine Lizens ausschließlich zum Testen des Add-Ons zulegen, wofür ich ehrlich gesagt zu geizig bin.
² Diese Kommentierung würde in deutscher Sprache erfolgen. Im Rahmen dieser Kommentierung würden wahrscheinlich auch die Variablennamen etc. auf Deutsch umgestellt werden.
³ Gemeint ist wirklich nur ein einfaches Vektor-Graphik-Malprogramm, kein GIS

Zitat von mockauer

Arbeitest du hier noch dran?

Mir wirft die neue Version Fehler.

Einen hab ich noch
Du könntest mal versuchen, den relativen Pfad in $data_folder in einen Absoluten umzuwandeln.

Das ist egal, ob es lokal (als cli- oder als cgi-Skript) oder irgendwo im Netz läuft. Die Fehlermeldung sagt, dass das Skript keie (ausreichenden) Rechte hat, um auf bestimmte Dateien (league.data und template.html) zuzugreifen. Das kann daran liegen, dass sie umbenannt sind, verschoben wurden, oder das Skript von einem anderen Benutzer ausgeführt wird als es erstellt/das Archiv entpackt wurde (zahlreiche Webserver arbeiten als Benutzer "www-data", wenn du das Skript als normaler Nutzer auf einem lokalen Webser gespeichert hast, hat dieser Nutzer des Webservers möglicherweise nicht die entsprechenden Zugriffsrechte.

An alle Anderen:
Zu Weihnachten gibt es jetzt eine neue Version:
In Version 0.2.0 wurde das "alles in einer Datei"-Konzept aufgegeben und das Skript auf insgesamt 5 Dateien verteilt. Die Datei "cli_mode.php" enthält hierbei nur für Testzwecke interessante Dinge. Sie wird für den Produktiveinsatz nicht benötigt und braucht daher auch für eine Verwendung im Internet nicht auf den Webserver hochgeladen werden.
Das Programm wird über die "index.php"-Datei gestartet.

Die Liga-Tabelle zeigt nunmehr auch noch bei jeder Mannschaft die erziehlten Tore und die erhaltenen Gegentore an.

Weiterhin wurde auf Basis eines Vorschlags von Wolfram Lande die einzelnen Bestandteile der zu generierenden Namen in externe Textdateien ausgelagert. Diese sind jetzt über das ACP bearbeitbar, welches deutlich aufgeräumter gestaltet wurde.

Ferner wurde versucht, die Verwendbarkeit des Skripts auch mit älteren php-Versionen zu verbessern.

Nach wie vor geplant sind:

• Die Einstellbarkeit fester Wochentage zur Ergebnisbekanntgabe (Idee von Gao Lin)
• Die Verwendung aller angegebenen Orte bei der Generierung der Mannschaftsnamen (Idee von Hendrik Wegland)
• Die Erweiterbarkeit auf mehrere Saisons (Idee von mir)

Die Speicherstände der Version 0.1.1 sind vermutlich wieder verwendbar. (Dies ist allerdings ungetestet!)
Viel Spaß beim Testen, Experimentieren und Weiterentwickeln. Frohe und Gesegnete Weihnachten!

Ja, ich arbeite noch bzw. wieder daran und werde die Tage (hoffentlich schaffe ich es noch heute) eine neue Version rausbringen.
Dein Fehler hat allerdings nur bedingt was mit meinem Code zutun, vielmehr hat das Script keine Schreibrechte. Diese kannst nur du bzw. der Admin deiner Seite ihm geben.
(D.h., du müsstest die Rechte des Ordners "soccer_data" auf mindestens 700 ändern, vgl. http://de.wikipedia.org/wiki/Chmod#Numerisch

So, ich habe jetzt die Ergebnisgenerierung ein wenig überarbeitet und die Gelegenheit genutzt, um die Tabelle ein wenig zu überarbeiten. Die Überarbeitung des ACP (Verbesserung der Übersichtlichkeit und der Einstellung des Datums, Auslagerung der Namensbestandteile, Auswahl der Orte) folgt als nächstes. Geplant ist, im Anschluss eine Möglichkeit zur Erweiterung auf mehrere Spielzeiten zu bauen.

Zitat von Hendrik Wegland

Ich hätte noch eine Verbesserung:

Ich hatte mal testweise ne Liga mit 16 Teams angelegt und dafür 10 Städte eingetragen. Es resultierte darin, dass manche Orte doppelt und dreifach vertreten waren und mache gar nicht.

Es wäre schön schön, wenn alle Städte berücksichtigt werden, die man angibt. Macht aber natürlich nur Sinn, wenn die Anzahl der Städte <= Anzahl der Teams ist.

Die Orte werden zufällig ausgewählt, wobei auch die angegebene Ortsgröße berücksichtigt wird. (genauer gesagt: Es wird eine Liste erstellt. in der 8-(angegebene Größe auf Skala von 0-7)x jeder Ort vertreten ist. Aus dieser Liste wird dann der Ort für die Mannschaft zufällig ausgewählt.) Das Verhalten war also auch mehr oder weniger so geplant. Aber du hast recht, es ist möglicherweise nicht so sinnvoll/toll. Ich werde mir mal Gedanken darüber machen, wie ich das ändere. Alternativer (nicht besonders toller) Workaround für bisherige Versionen ist auf jeden Fall, zunächst eine Liga erstellen zu lassen und dann manuell die Mannschaftsnamen im Admin-Login-Bereich anzupassen (oder gleich beim ersten Generieren fertige Vereinsnamen anzugeben. Diese werden nämlich, solange sie in ihrer Anzahl <= der Anzahl der erstellten Teams sind in jedem Fall berücksichtigt.)

Zitat von mockauer

SuperSache, ich kann es leider erst Montag bzw die nächste Woche richtig testen. Aber bisher klingt alles super.

2. Was mir aufgefallen, wie auchschon anderen vieel 0:0 und ein "exotisches" Ergebnis auch kaum dabei, also meistens die gleichen Ergebnisse. Könnte man da eventl. noch was drehen?

Nun, sooo selten ist ein 0:0 im RL-Fußball auch nicht. Aber allgemein gesagt/zu den exotischen Ergebnissen: Die Anzahl maximaler Tore/Spiel (und Mannschaft) ist momentan auf 5 festgelegt, wodurch nur sehr selten 6 Tore erzielt werden können, 7+ Tore gar nicht. Du kannst ja mal den entstprechenden Wert in der league.data erhöhen und schauen, was passiert. Aber ich werde auch trotzdem noch mal schauen, an welchen Rädern im Code ich drehen kann…

Nach eifrigem Herumgebastle ist eine neue Version, die Version 0.1.0 draußen. nebst vielen Änderungen unter der Haube wurden auch einige andere Dinge eingefügt:

Zitat von E. G. Aal

Die Daten, sowohl die vom Benutzer eingegebenen als auch die generierten, müssen noch einmal gründlich überarbeitet werden, damit die gespeicherten Daten 1. leichter editierbar 2. besser vor Download geschützt und 3. besser vor ungewollter Bearbeitung geschützt sind.

Ist erledigt. I.B. die Passwort-Sicherheit wurde ein wenig verbessert. Alle vom Programm benötigten und erstellten Dateien befinden sich im "soccer-data"-Verzeichnis. Aus diesem Grunde werden auch Speicherstände von alten Versionen eiskalt ignoriert und es wird empfohlen diese zu löschen. ;). Allerdings, ist das folgende (noch) nicht implementiert:

Zitat von Wolfram Lande

Nur als Denkanstoss:
Du könntest doch mögliche Namen(steile) in eine *.txt dabei packen, die könnte dann jeder manuell bearbeiten. Nur weil ich gerade Sachen wie "name_Athletik" und "name_Kickers" gesehen habe.
Also z.B. zwei txt Dateien eine mit Stadtnamen des Landes und in die andere packt man Sachen wie Athletiko, Turbo und was weiss ich rein.

Dafür kann jetzt jeder in der "league.data"-Datei des Unterverzeichnisses ohne größere Probleme die Zahlen eintragen, um die Liga an andere Sportarten anzupassen.
Ferner wurde auch das folgende implementiert:

Zitat von Gao Lín

- In das gleiche Horn bläst auch der zweite Vorschlag: Einstellbarkeit von festen Uhrzeiten der Ergebnisbekanntgabe.

Zitat von Gao Lín

Zunächst einmal ein riesiges Kompliment für den Erfindungsreichtum und den Einsatz bei der Erstellung dieses Programms! Nachdem ich einen Testlauf durchgeführt habe, möchte ich einige kleinere Änderungen vorschlagen, um das System für den "operativen Dienst" etwas besser einsetzbar zu machen:

- Anstatt den Spieltagsabstand in Tagen festzulegen, würde ich feste Wochentage einstellbar machen. Dadurch dass die Woche eben sieben Tage hat, rutschen die Spieltage ansonsten durch sie hindurch (z. B. bei drei Tagen Abstand: Samstag - Dienstag - Freitag - Montag - Donnerstag - Sonntag usw.).

Ich habe es jetzt ermöglicht, dass der Spieltagsabstand auch in Wochen einstellbar ist. Zusammen mit einer Festlegung des Starttags ist eine solche Planung dann möglich. Ich habe jedoch zusätzlich das bisherige System der Spieltagseinstellung beibehalten, damit auch Nationen mit alternativen Kalendersystemen und möglicherweise anderen "Wochen"-Dauern eine Liga haben, deren Spieltagsabstände an den ihrigen Kalender angepasst sind. Allerdings werde ich die Datumseinstellungsmöglichkeiten vllt. trotzdem irgendwann und irgendwie modifizieren, da diese im Moment sehr unhandlich sind.

Ferner habe ich eine Lizenz-Datei hinzugefügt, so dass das Ganze jetzt offiziell unter der CC0-Lizenz steht. Außerdem steht jetzt nur noch eine 0 vorne in der Versionsnummer. Jeder kann die Software also kostenfrei nutzen, verändern und weiterverbreiten, ohne zu fragen.

Zitat von Hendrik Wegland

Bei mir kommt dieser Fehler:
Edit: Hat sich gerade erledigt, die .htacces-Datei darf nicht auf 5.2 verweisen, sondern nur auf 5, also:

PHP

AddHandler php5-cgi .php

Danke für die Information. Da auf meinem Testserver php5.3 läuft, kann es bei älteren Versionen zu Fehlern kommen.

Last but not least: Vielen Dank an Alle für die Lorbeeren. Und ich suche immer noch einen Namen für die Software. Aber das hat Zeit. Viel Spaß beim Fehler finden! Gute Nacht!

Danke für die Lorbeeren (von Dir und auch von allen anderen hier!)

Zitat von mockauer

Ich habe noch kleinen fehler festegestellt, wenn man editiert sind die Umlaute HTML-Codiert und ändert Sie nicht wieder um in ä,ö usw. wenn man es wieder absendet.

Danke. Zum fixen des Bugs muss Zeile 925 des Skripts (

$formulatext[] = '                <input type="text"  name="team' . $i . '" size="15" maxlength="50" value="' . htmlentities($this->list_of_names[$i-1]) . '"><br />';

) durch

$formulatext[] = '                <input type="text"  name="team' . $i . '" size="15" maxlength="50" value="' . $this->list_of_names[$i-1] . '"><br />';

ersetzt werden, also das "htmlentities(" und das ")" nach "$this->list_of_names[$i-1]" entfernt werden. Für die Leute, die das nicht selbst machen können/wollen habe ich die Pakete von oben mal aktualisiert. Speicherstände müssen nicht aktualisiert werden…

Als Input für eventuelle Programmierversuche und als Ersatz für die lausige Kommentierung meinerseits: Zur Bearbeitung der Punkte für Sieg/Unentschieden muss die team->getPoints()-Methode bearbeitet werden, zur Bearbeitung der Tore pro Spiel die league->play(). Ersteres wird auf jeden Fall irgendwann in die league verschoben werden, da dort ohnehin die gesamten Spiele im league->results-Array gespeichert sind. Dies würde es auch ermöglichen eine neue Saison mit den selben Teams weiterzuführen (ohne die Team-Klassen bearbeiten zu müssen). Es muss zudem bei einem Wechsel der Sportarten auch der gespeicherte Spielstand neu geladen werden, da im Moment die gesamten team-Objekte gespeichert werden (mittels serialize(), in der list->writeData()-Methode). Dies wird noch bearbeitet, da 1. ohnehin bereits geplant ist, die Speicherstände zu überarbeiten (s.o.), 2. die serialize()-Funktion in bestimmten php-Versionen fehleranfällig sein soll und 3. jegliche(!) Veränderung der team-Objekte die Löschung und Neuerstellung des gesamten Speicher-Prozesses einfordert.
Außerdem überlege ich, ob es nicht vielleicht sinnvoll wäre in diesem Rahmen auch gleich die league->loadData()- und league->writeData()-Methoden aufzusplitten, damit nur der jeweils notwendige Teil geladen und gespeichert wird. (Im Moment wird bei jedem neuen Spieltag nicht nur die Ergebnisse jedesmal neu abgespeichert, sondern auch Passwort inkl. Salt, die Tage zur Generierung der einzelnen Spieltage und einiges mehr.)

Es ist also noch einiges geplant, weshalb ich für Ideen von fähigen Leuten sehr dankbar wäre.