Name - Sprachen - DB Abstraktionen

[xsign.dll]

Gut, damit hier endlich mal was angefangen wird, schreib ich mal alles was mir einfällt:

Es besteht momentan wie gesagt der Namenskonflikt. Clansphere vs. Clansuite.
Ich entscheide mich für Clansphere und ich würde dich vain bitten, das ganze ein wenig locker zu sehen und auch auf clansphere umzusteigen.
Gründe hierfür sind:
1. Auf bxcp.com können viele schon etwas mit dem Begriff clansphere anfangen
2. der irc channel #clansphere existiert schon und ist gefüllt (somit also schon L und später ein Trust möglich für eventuelle Bouncer und/oder später nen Q)

Gegenargument ist ganz klar, dass die Domain clansphere.com schon belegt ist. Hajo, hast du die shcon registriert oder ist das jmd. anders? Ansonsten muss man sich mit dem zuständigen Verwalter der Domain auseinandersetzen. Ich nehme an, dass es schlichtweg nen hosting-betreiber ist, der dort nen platzhalter hinterlegt hat, da die domain schon gekündigt wurde.


Ok - thema 2:
Sprachen und deren Behandlung.
Ich hab da schon gestern ausgiebig mit hajo drüber geredet und mich nochmal in gewissen Foren informiert. Mein grundsätzlicher Ansatz war recht klassisch, nämlich Sprachen Filebasierend laufen zu lassen. Hajo hat angedacht, die DB mit ins Spiel zu bringen.

Gut dann stell ich mal gegenüber:
Filebasierend:
pro:
1. einfache bearbeitung
2. wird von einschlägigen cms wie z.b. joomla ebenso gehandhabt
3. kennen viele vom bxcp
4. performance, da nur ein require() notwendig ist
5. seit file_put_content() auch einfaches schreiben in die file möglich
con:
1. erschwerte on-the-fly bearbeitung bzw. nur mit write-access möglich, also chmod gescheit setzen... und das bekommen manche user nicht auf die reihe
2. es wird immer/meistens eine ganze kategorie geladen, egal, ob man den content tatsächlich brauch oder nicht

DB basierend
pro:
1. on-the-fly bearbeitung möglich
2. gezielte Abfrage von Datensätzen
con:
1. performance einbußen, da entweder der query extrem lang wird (was an sich ja nicht so das problem ist - jedoch haben wir das gestern mal durchdacht - und dabei ist aufgefallen, dass ein langer query nur zustande kommt, wenn man während des $smarty->display() Vorganges nach {$lang->bla} innerhalb des templates sucht... innerhalb von anderen funktionen/klassen muss man dann trotzdem nen zusätzlichen query in die DB machen, falls ein $lang->bla gefordert wird...)
2. unbekannt (für bxcp leute)
3. für programmierer ist eine lokale DB erforderlich, um bestimmte Sachen zu editieren
4. einfügen von variablen erfordert einen zusätzlichen aufwand (sprich entweder über eval() was absolut nicht drin ist oder eben ersetzen lassen)
5. phpmyadmin oder nen edit-panel erforderlich, um zu editieren

Von meiner seite her ist somit die Entscheidung für ein Filesystem. Nicht zu letzt, weil andere CMS das ebenso handhaben.

Ok - thema 3
DB Abstraktionen und Layer
Ich denke die Lösung wurde gestern gefunden (außer du hast Einwände, vain):
PEAR + PDO
Dabei wird noch nen Layer vor beide geschaltet, der dann verteilt. Der User kann dabei in der config wählen, welchen DB-Zugriffstyp er möchte.
Wobei... wenn ich grad so drüber nachdenke... es war ja ausgemacht, PHP 5.1 vorauszusetzen, oder? Von daher könnte man auch gleich auf PDO setzen, da es bei 5.1 mitgeliefert wird. Hmmmmmm... würde einiges vereinfachen und die performance wäre atemberaubend Naja, wenn wir ca. bis 2007 programmieren, und z.b. funpic dazu bekommen auf 5.1 umzusteigen, dann sehe ich grün für so ein vorhaben. Jedoch isses dann mit der abwärtskompatibilität zu php4 komplett hin... (womit man dieses problem auch schnell aus der welt hätt )
Eine recht gute Auflistung, was die anderen Abstraktionen so können findet man hier: http://www.pear-forum.de/ftopic254.html

[Jens-A. Koch]

Thema 1: Namenskonflikt. Clansphere vs. Clansuite

Clansuite ist sowas wie ein Bastelkasten für mich, wo ich Lösungsansätze ausprobieren kann, die ich gut finde. Ich sehe das recht locker, kurzum: ich habe meinen Sandkasten und Clansphere.  In einige Punkten unterscheiden sich die Systeme nach meiner Ansicht, aber die Diskussion hier trägt ja gerade dazu bei, den Aufbau und die Struktur zu klären, zu beschreiben und zu planen.
Kräftemäßig würde ich ein arbeitsteiliges Projekt bevorzugen, vorausgesetzt es ist Open-Source und wir bekommen eine saubere Arbeitsstruktur mit entsprechenden Werkzeugen hin.

Die ersten Schritte machen wir ja gerade.
Den Projektstrukturplan finde ich gut. Lasst uns evtl. die Dinge in diesem Board diskutieren und planen. Das macht die Dinge für alle nachvollziehbar. Sämtliche Anfragen, Stellungsnahmen und auch Requests sind schriftlich fixiert besser und strukturierter zu beantworten, auch werden dadurch Wiederholungen vermieden.

Über Domains habe ich noch nicht nachgedacht.
IRC spielt für mich eine untergeordnete Rolle.

Sehr wichtig ist mir ein Usersupport über ein gutes Board und die entsprechenden Entwicklerwerkzeuge, d.h. Bugtracker, Taskmanager, Supportmanager.
Sei es als Eigenhostung oder auf einem externen Anbieter (gna, berlios, sf).
Bitte die Verfügbarkeit von SVN als Source-Repository sicherstellen.

Thema 2: Sprach/behandlung

Ich sehe die Editierbarkeit bei einem Db-Sprachsystem nur eingeschränkt gegeben. Es grenzt den Kreis auf Entwickler ein, normale Benutzer können keine Übersetzungen beitragen, es sei denn man stellt ihnen hierfür ein eigenes Interface zur Seite.

Ein Performanceprobleme sehe ich nicht zwingend.
Die Anzahl der Abfragen, ob nun an Flatfile oder Db, ist identisch.
 
Man könnte eine 2-stufige Sprachverarbeitung zu Grunde legen: Smarty könnte eine Ausgangs-TPL verwenden, und daraus einmal die fertig übersetzte TPL erstellen.
Diese wäre dann der Ausgangpunkt für weitere Variablenassignments.

Die Ausgangs-TPl enthält languagevars, smartyvars.
Vorübersetzte-TPL enthält languagetext, smartyvars.

Die jeweiligen Sprachabfragen wären nur einmal in ihrer Gesamtheit zu tätigen und lägen dann als Vorübersetzefiles vor. Bei Änderung des Ausgangs-Tpls würde die einzelne übersetzte TPL natürlich neu generiert.

Ich finde eine filebasierte Handhabung besser, weil man die Sprachfiles leichter bearbeiten kann.
Es gibt verschiedene taugliche l18n-Ansätze
1. gettext und .pot/.mo Files (es gibt hier auch externe Editoren poedit, etc.)
2. XML basiert (hier für lassen sich auch Editoren finden)
3. simple PHP-File enthält das jeweilige Spracharray (nicht so die elegante Lösung)

Thema 3:  Db-Abstraktionslayer

Meinerseits bestehen keinerlei Einwände gegen die Verwendung von pear:db & PDO.
pear:db ist sehr schlank und unterstützt eine vielzahl von db.
Weitere Lösungen wären adodb oder creole.

Was macht man mit sovielen Db-Anbindungen, wer setzt das wirklich ein?
Ums knallhart zu formulieren: die User brauchen nur mysql, mysqli und haben oftmals auch nur dies zur verfügbung. Mir würde es ausreichen, wenn das DB-Backend "MySQL mit InnoDB" unterstützt.

Thema 4: Abwärtskompatibilität

Die Beachtung der Abwärtskompatibilität war mir wichtig. Das Problem wird natürlich durch die Entscheidung für PHP5 und aufwärts völlig aufgelöst. Das ist ok.
 
Thema 5: Verzeichnisstruktur

Ich habe im Clansphere Grundentwurf gesehn, daß ihr die modulspezifischen Language und TPL Files in zentrale Verzeichnisse einordnet. Ich möchte vorschlagen diese Files eher im jeweiligen  Moduldir einzuordnen.

/modul
+language
+templates
+images
.php

Ergeben sich bei dieser Anordung Schwierigkeiten im Hinblick auf wechselbare Themes (Template_Packs)??
Gedanklich komme ich zu wechselbaren Main-Themes und wechselbaren Modul-Themes.

[hajo]

Sprachen

Am meisten begeistert mich derzeit die XML-Variante, jemand dagegen? Können uns meinetwegen sonst schon auf die festlegen.

Datenbanken

Wie x!sign schon sagte wäre ich trotz das die große Menge mysql(i) benutzt dafür dort offen für möglichst vieles zu sein, dies spart uns möglichen Ärger falls MySQL wegen Lizenz-Änderungen oder besseren Mitbewerbern ausm Rahmen fällt, zudem steigt inzwischen der Anteil an Microsoft-Webservern leider wieder an, z.B. GoDaddy einer der Weltgrößten hat darauf umgestellt. Es sind alles potenzielle Nutzer und vor allem Flexibilität die man dort liegen lassen würde, wenn man sich festlegt auf nur MySQL!

[xsign.dll]

T1: DB Abstraktionslayer
Wenn wir sowieso php 5.1 voraussetzen (funpic stellt z.B. schon ende des jahres auf 5.1 um) , dann können wir uns das ganze sparen und tatsächlich auf PDO setzen. Das hat den Vorteil, dass es sehr zukunftsträchtig ist, aber den Nachteil, dass nicht jeder damit umgehen kann. PDO ist neu, PHP 5.1 auch. Die "normalen" Module Programmierer werden schätze ich erst in 1-2 Jahren sich damit auseinandersetzen.
PEAR ist langsam und unterstüzt, wie hajo schon gesagt hat, zuviele Datenbanken. MySQL und 2/3 andere DBs sollten ausreichen - somit erfüllt PDO unsere Herzenswünsche.

T2: Sprachen
Also ich hab mir heut mal nen Benchmark erstellt, der Arraygestützte Language Files mit define() gestützen vergleicht. Wie zu erwarten ist define() fast doppelt so schnell. Dadurch büßt man jedoch einen entscheidenden comfortfaktor ein: normalerweise lädt man in die Klasse das array und stellt es innerhalb der Klasse über $this->array zur verfügung. In Smarty hat man dann die glückliche Möglichkeit auf Klassen/Objekte zuzugreifen. Somit fällt ein $smarty->assign('sprachbla', _CORE_SPRACHBLA); weg, was bei defines notweändig wäre. Sprich: Ich geh ins Template, schreib {$lang->core['blafasel']} und er spuckt es mir raus.
Warum auf XML, wenns doch über eine PHP File simpler und schlanker geht?

T3: Ordner
Templates,Sprachen und Module sollte man immer strikt trennen. Das liegt schlichtweg daran, dass man später vllt. einen "Übersetzer" hat oder eben nen Grafiker. Der wird dich für die Verzeichnisse innerhalb der Module hassen.
Also ich bin da klar dagegen, da es mich selbst immerwieder verwirrt. Vorallem, was machst du dann mit "Modullosen" templates, wie z.b. Debugger-TPLs oder core-language files? Ich werde mich da eher auf richtige Namensgebung ( modulname.lang.php oder modulname.class.php ) fixieren, da sowas dann eine Ordnerstruktur überflüssig macht. Das is eben recht viel Konventionsreiterei, aber es zahlt sich spätestens beim ersten Programmierer aus, der versteht, wie die Namensgebung ist und somit intuitiv die Module richtig programmiert. Außerdem verlierst du die Möglichkeit, einzelne Ordner zu schützen, sprich außerhalb des Apache Web Roots zu lagern... du kannst entweder die module auslagern oder garnix, und das find ich nicht so klug. Die meisten werden das sowieso nicht machen, aber allein die möglichkeit zur verbesserten sicherheit muss gegeben sein.

T4: Namenskonflikt
Gut - also clansphere... verwirrt einen doch sonst ^^

[hajo]

Abstraktion

Denke das wir mit PDO "fast" alles vorfinden was wir benötigen, allerdings ist auch wenn die Performance extrem schneller ist als in Php-Code-Abstraktionen wie Ado-DB oder PEAR-DB, alles noch immer langsamer als in den klassischen Erweiterungen.

Sehe daher einen Mittelweg, der eine DB-Klasse csphere_db oder so ähnlich erstellt mit Methoden zum SELECT, INSERT, UPDATE usw. die dann ..

1. Durch einladen der passenden Klassen-Erweiterung wie z.B. PDO, mysql, pgsql etc. die Basis-Klasse erweitern um die Funktionen der Erweiterung

2. Dann z.B. csphere_db->select() auf mysqli_select() weiterleitet wenn mysqli Erweiterung aktiv und Klassen-Erweiterung geladen ist

3. Dabei USER-Input gesichert wird der per Query-Templating im SQL ersetzt wird nach dem escapen des jeweiligen Strings oder Integers, oder anderen Datentyps

4. Dabei vorweg einige Fehler vermieden und vor allem DB-Fehler abgefangen und ausgewertet werden können für Debug und Error-Funktionen

Sprachen

Alternativ zu XML sehe ich sonst zwei Dateien je Modul bei den Sprachen, eine mit generellen Infos wie Modul-Name, Übersetzer, Version, angedacht zu welcher Modul-Version die Übersetzung ist und vll. noch einer Hand voll weiteren Details und die zweite mit der kompletten Übersetzung des Moduls, alles in beiden Dateien je als Array in PHP-Format.

Verzeichnisse

Haben die Wahl zwischen Modul- oder Themen-Trennung, also z.b. kommen alle Templates in news/templates oder templates/news und sollten uns da Mal einigen untereinander. Nutze bisher atm letzteres und wäre nicht abgeneigt das beizubehalten.

[xsign.dll]

Ok in Sachen Sprachen scheint XML die geeignetere Lösung zu sein. Hatte mich schlichtweg noch nicht ausgiebig genug mit dem Thema befasst.

[Jens-A. Koch]

Thema: Sprachen
Wie gesagt, es gibt zahlreiche Lösungsansätze zum Thema i18n/Sprachen.
Ich füge mal den Link zum SmartyWiki ein, dort sind 4 Verfahren beschrieben:
http://smarty.incutio.com/?page=FrontPage

Dabei finde ich den Ansatz, XML zu verwenden und die tpls mit nem SmartyPlugin in die jeweilige Sprache zu compilieren brauchbar.

Thema: Multitheming/ Styles

Wäre es für euch denkbar, die TPL nicht als Files sondern in der DB abzulegen?
 

[xsign.dll]

Thema: Multitheming/Styles

Hatte ich in meinem letzten CMS schon umgesetzt. Dabei stellen sich folgende Probleme:
- übersetzen des templates mit eval()
- selbes problem, wie bei languages in der DB: schlecht verwaltbar

ich persönlich bevorzuge normale .tpl files, da diese recht einfach mit jeglichen html editoren zu editieren sind. ich kenne natürlich auch andere gute Ansätze über die Datenbank an die templates zu kommen (siehe invisionpowerboard). Dabei hat man den Vorteil, dass man online editieren kann.

Hält da Smarty irgendwelche klassen/zusatzfeatures bereit?
/edit: OK Smarty hält da dieses ressourcen modell bereit. Von daher wäre es durchaus denkbar. Der Vorteil daran ist schlichtweg, dass man die templates nichtmehr über den apache ansprechen kann. der nachteil ist eben die verwaltung jener. bin mir also absolut nicht schlüssig, und deswegen tendiere ich zum altbewährten: den files.

Thema: Sprachen
http://smarty.incutio.com/?page=SimpleXML
scheint echt nice zu sein...
hat einer von euch schon gute xml-editor klassen, die sich verwenden lassen könnten ?

Thema: Captcha & Useridentifizierung
Was soll alles durch Captcha secured werden?
- jegliche Gast-Eingaben (Gästebuch z.b.)
- Registrierung
- Passwort-Änderung
-

Die Useridentifizierung läuft nicht via IP. Das ist sehr ungünstig, da z.B. namhafte anbierter wie z.b. aol bei jedem zugriff den proxy des users wechselt und somit die IP wechselt. Auch sogenannte IP-Masquerading Programme arbeiten mit wechselnden Proxies. Somit fällt eine Identifikation via IP weg. Cookies wären noch eine Möglichkeit und eben die Browser Identifikation.

[Jens-A. Koch]

Thema: Multitheming/Styles

Also ein OnlineEditor für die tpl's war ohnehin angedacht, ob's nun file oder db als ressource.
Ich würde Files erstmal den Vorzug geben. Die Verlagerung in die Db kann später ja mal per Mod-Pack oder Patch von der Community gemacht werden...

Das angesprochene Sicherheitsproblem bei Tpls ist einfach zu lösen, denke ich, indem man einfach folgende Zeile der Tpl voranstellt: 
{php} checken ob in_system define gesetzt ist, ansonsten die; {/php}

Thema: Sprachen

XML-Online Editor? Also ne class dafür hab ich nicht. Würde das sehr simpel lösen, einfach die ganzen Werte aus dem XML-File über ne Schleife auslesen und in Textfeld/er, innerhalb eines Formulars packen.

Speziell bezogen auf Übersetzungsvorgänge müsste man ne 2 Seitenansicht haben,
links die Ausgangssprache, rechts die Eingabefelder für die Vokabeln in der Zielsprache.
Aber ein Schritt nach dem anderen.

Bislang hab ich die eine TMX-konforme Class (http://www.lisa.org/tmx/tmx.htm) für die Sprachen verwendet. Die Daten könnte man an Smarty übergeben.

Thema: Useridentifizierung

Die aufgeworfenen IP-Probleme sind zutreffend, aber für jede andere ermittelbare Userinformation gilt dies auch (Browserinfos, usw.). Ein User ist im Rahmen von PHP-Anwendungen immer nur im Nebel zu erfassen. Mit den wenigen evtl. richtigen Userdaten lässt sich aber eine relative Sicherheit erzeugen. Richtig Sicher gehts nicht! Dauerhaft sowieso nicht.

Ich würde folgendes vorschlagen:
1. Mit Sessions arbeiten
2. via Session den User indentifizieren.
3. Ip+BrowserInfo in der Session ablegen und gegenchecken
4. Erhöhung der relativen Sicherheit durch Session-Timeout (30min) nach User-Inaktivität. Dadurch ist zumindest das Handlungs-Zeitfenster des evtl. geklauten Cookies etwas eingeschränkt.

Diesen Weg hab ich so bereits umgesetzt und das Sessionhandling auf Mysql umgestellt. Die Queries sind schätzungsweise Db-kompatibel, so daß man das wohl anpassen könnte.

Thema: Captcha
Ja, erstmal alle öffentlich zugänglichen Bereiche die Spamattacken unterliegen könnten, sollten auch geschützt werden.

Eine gut verwendbare Captcha Class:
http://www.phpclasses.org/browse/package/1569.html
http://www.nogajski.de/horst/php/captcha/


Thema: Arbeitsorganisation

Wir sollten aus den hier aufgeworfenen Punkten konkrete Aufgaben ableiten und diese in den Taskmanager eintragen. Dann eine Bearbeiterzuordnung treffen. So kommen wir einfacher arbeitsteilig voran.

[xsign.dll]

Thema: Language
Mich hat das nicht in Ruhe gelassen und ich hab jetzt mal die XML implementiert. Das war ein wenig frickel-kack, aber letztendlich läufts ja auf ein bissl hin und her "ge-tagge" hinaus. Dann hats mich aber doch mal interessiert und ich hab nen benchmark gemacht. Und das für mich erstaunliche resultat ist: XML ist schneller als nen simples Array. Da hab ich dann auch nicht schlecht geschaut und mir erstmal die Verwunderung aus den Augen gerieben. Somit isses eindeutig die bessere Wahl.
Zu TMX: Das würde eine Ordnerstruktur /de /en /ru überflüssig machen,da ja alle Übersetzungen dann durch den Tag <tuv xml:lang="EN"> etc. deklariert sind, ja? Sieht für mich auf den ersten Blick zwar transparent aus, aber isses das auch für die User? Naja, solangs dafür nen gescheiten Editor gibt, is das kein Problem. Praktisch hab ich damit noch nichts zutun gehabt.

Thema: User/Sessions
Sessions in DB storen is denke ich das kleinste übel

Thema: Themes schützen
hehe. wenn du die .tpl files direkt ausm apache ansprichst, dann gelangen die nicht durch den interpreter. Und erst recht nicht durch smarty - somit sind die {php} tags hinfälllig. auch ein normales <?php if(defined(IN_CS) ... ?> dürfte schwierig werden... außer smarty kommt damit zurecht. dann müsste man aber die .tpl files in .php umbenennen. Insofern wäre die DB sicherlich eine alternative. Wenn wir sowieso nen Online Editor a la WYIMGEADSFASG (oder wie die abkürzung da auch immer is) hinbekommen, dann seh ich dafür auch grünes licht. Aber für die 0.1 Alpha sollten wir uns vorerst auf files beschränken, da es einfacher ist, damit umzugehen - fürs erste.

Thema Arbeitsorga
Das wird...lästig... vorallem beim core. In der Anfangsphase ist sowas sehr schwierig zu handhaben, da viele Leute hier den Brei sehr stark verderben. Schließlich arbeitet man fast schon gegeneinander, wenn man etwas am core ändert. Bei Modulen sieht das natürlich komplett anders aus.
Z.B. bei deinem clansuite, vain, wirds für mich schwierig etwas zu ändern - da schon soviele Sachen ineinander verstrickt sind. Bei meinem source gehts grad noch, da alles halbwegs erklärt ist und auch nur in etwa die hälfte drin ist, was du drin hast. Ich hab alles nur ganz rar angedeutet, damit eine etwaige Änderung sehr schnell von statten gehn kann.
Ich denke an diesem Punkt müssen wir uns entscheiden: Bauen wir auf deine clansuite version, auf meine clansphere version oder setzen wir uns einen Nachmittag ins TS und basteln kurz aus beiden Versionen etwas neues, damit wir eine gesunde Basis haben. Denn wenn schon die Wurzel verkrüppelt ist, wie soll dann jemals ein Baum gedeihen?

[xsign.dll]

Ich fasse zusammen:

Name: Clansphere
Projekturl: http://gna.org/projects/clansphere
PHP Version: >= 5.1.4
Versionsverwaltung: SVN
Templates: Smarty, Files, *.tpl
Languages: XML, *.lang.xml
Datenbank: PDO + native PHP DB Funcs (also noch nen Layer davorschalten)
Ordner: http://x-sign.net/psp.html
Lizenz: GNU v2 oder LGPL oder nen BSD Ableger (?)

Bei Lizenz hätt ich gern mal noch nen kleines Statement von euch. Wenn's irgendwelche groben Einwände gibt, dann bitte jetzt loswerden und nicht erst in 2 monaten, nachdem das meiste dann schon steht. Hajo, bist du auf gna.org angemeldet ? @vain: lassen wir clansuite auf gna ruhig drauf, als kleine/große spielwiese für alles mögliche.

Hab ich was vergessen ?

[Jens-A. Koch]

Thema: Db-Konventionen
 Ich hab mir verschiedene Db's angesehn, es wird unterschiedlich gehandhabt. Eine allgemeine Regel, daß man die Tupel nach der Haupttabelle benennen sollte, hab ich nirgendwo gefunden und auch nicht ableiten können. Ich gehe davon aus, daß z.b. die user_id als Schlüssel übergreifend auf alle Tabellen gesehen wird. Der Schlüssel würde seine Funktion verlieren, wenn man grouptabelle_user_id, usertabelle_user_id, news_user_id daraus macht. Die Fields können ausreichend klar angesprochen werden:  user.user_id, group.user_id, news.user_id. (Anderenfalls wäre es group.group_user_id, etc.) Das bei dieser Benennung ein Kollisionseffekt auftreten soll, kann ich immernoch nicht nachvollziehen. Ich bitte um weitere Ausführen bzw. Links zu dem Problem.

Thema: Themes schützen

ja, stimmt daran habe ich nicht gedacht.
a. das define ist ja gar nicht zugewiesen beim einzelzugriff auf das tpl.
b. die frage ist, ob beim apache tpl's als php interpretiert werden. 
dann prüfe ich andersrum

Code:

{if $in_system == 0}
<?php exit; oder die;
{/if} 
<b>versteckter tplinhalt</b>

bessere lösung über htaccess oder leere bzw. redirect index.php im pfad der templates.

Code:

<Files ~ "\.(tpl|inc|cfg|css)%body%quot;>
order deny,allow
deny from all
</files>

andererseits, stellt sich die frage warum man die tpls überhaupt sichern sollte.
eigentlich kann auch ein read-access auf tpl gewährt werden, jedenfalls solange man nur über upload bzw. online-edit eine datenveränderung vornehmen kann.
zu verstecken ist ja in den tpl's nichts, die user können sich ja die tpls auch im svn ansehn.
also was soll's: aus meiner sicht:  thema TPL Schutz closed.

Thema: Namenskonflikt / Projektzusammenfassung
Clansphere hat die klare Zielsetzung PHP5.1 + PDO orientiert zu arbeiten.

Für Clansuite werde ich versuchen die Abwärtskompatibilität zu gewährleisten, d.h. ich verzichte bewusst auf neue PHP Features zugunsten der Läuffähigkeit.
Clansuite bleibt bei Gna gehostet. Dieses Hosting ist gebunden an eine freie Lizenz.
Ich werde es als meine Spielwiese weiterführen.
Gemeinsam entwickeln wir dann auf Clansphere.

D.h. mit dem Registrieren von Clansphere hast du die Weichen auf freie Lizenzen eingeschränkt. Hajo sollte entscheiden, was er möchte.

Dem bisherigen Coreentwurf kann ich zustimmen -  er könnte ins Clansphere SVN gestellt werden. Auf meinen Bastelkasten sollte nich aufgebaut werden, er ist nicht PHP5.1 konform und soll es wie gesagt auch nicht sein - es sei denn man beschließt die Umstellung. Die Sachen sind nicht so verstrickt, daß man nicht daran arbeiten könnte.

Thema: Rechtesystem
Wird Clansphere pear:liveuser oder phpgacl oder ähnliches verwenden?

Thema: Arbeitsorganisation

Wir könnten die zu implementierenden Features im Forum ansprechen und evtl. leere Functionen mit Beschreibung erstellen. Dann ist es leichter das umzusetzen und die Funktionszusammenhänge zu erkennen.
Evtl. könnte man auch mit dem Locking arbeiten, wenn das nicht zu Blockierungen führt.
D.h. es wird nur eine Datei (bzw. Arbeitsgebiet) zum Arbeiten ausgecheckt, gelockt gegen andere Veränderungen, verändert geuppt und wieder freigegeben.

Bei Modulen ist das ja halbwegs überschaulich.
Ich möchte hier entgegen Hajos Konzeption nochmal vorschlagen, keine extra files für die handlungen zu erstellen, sondern einen handlungsverteiler auf entsprechende funktionen zu verwenden, so wie es ja bereits in der index.class.php gemacht wird.
(do sollte action benannt werden)

Code:

 switch ($input['do'])
    {
      case 'show':
        $this->show();
        break;
      default:
        $this->show();
        break;  
    }

Handlungsformen bitte nach CRUD-Aktionensystem.
z.b. news_create() oder news_delete();

php	sql
create	insert
read	select
update	update
delete	delete

Thema: Modrewrite

Zumindest ansprechen möchte ich die Url vereinfachung per modrewrite, was beim Apache funktioniert. Also zuerst auf Apache Verwendung beim User checken, dann entsprechende .htaccess generieren.

Etwa folgende Funktion:
http://www.root.de/index.php?modul=news&action=edit&news_id=2
wird zu
http://www.root.de/news/edit/2

Grund: Suchmaschinen- + Bookmarkfreundlichkeit.
Meinungen dazu?

Thema: Debug
a. es steht die SmartyDebugConsole zur Verfügung
b. darauf aufbauend ein allgemeine Debuganzeige für Entwickler ohne xdebug

c. da pear verwendet wird bietet sich phpunit2 http://www.phpunit.de/pocket_guide/2.3/de/index.html an. meinungen dazu?

Thema: Multilanguage
Smartybasierte Übersetzungsfunktion hinzugefügt. Siehe Anhang.
Bitte testen und Info dazu.

[hajo]

Datenbanken

Bin auch dafür fest auf PDO zu bauen, wäre halt schön wenn da nen Layer zwischen kommt über den man die Daten absichert und die Kompatiblität zu den "klassischen" Erweiterungen rettet.

Templates

Bin auch für Smarty und dafür die Sprachen über XML-Dateien einzulesen, finde nur überflüssig die Templates zu schützen, selbst wenn reicht wie von vain erwähnt eine htaccess die den Zugriff vom HTTP aus verhindert auf diese Dateien.

Was denke noch zu klären ist wäre eine Trennung zwischen den Unterseiten-Templates und einem globalen Template, sowie wie das Designen ermöglicht wird, mir wär am liebsten viel überCSS damit es die Gestalter einfacher haben das Zusammenspiel zu ändern zwischen den Template Dateien.

Lizenz

Hatte ja beim BXCP 0.1 und 0.2 mit  GPL v2 angefangen, allerdings ist diese Lizenz recht "lasch" da der Copyright-Vermerk schlichtweg weggelassen werden darf.

Daher die Änderung auf die BSD 3 way Lizenz seit dem BXCP 0.3 und siehe da, Problem mit fehlenden About-Seiten wird laufend geringer.

Klingt fies und vllt. auch etwas weniger "frei", aber die BSD Lizenzen sind einfach Liberaler als die GPL und behalten dem Autor das Minimalrecht der Erwähnung von wem es denn nun ist. Zudem macht es kommerzielle Erweiterungen möglich.

Bisher ist daher die BSD 3 way auch noch immer mein Favorit, allerdings kommt ja gegen Anfang 2007 wohl schon die GPL v3 die frischen Wind unter die helfenden Lizenzen für Opensource-Projekte bringt. Sollten es daher unter unser persönliches Copyright nach deutschem Recht stellen bis GPL v3 da ist oder uns ne Alternative suchen mit der alle zufrieden sind. Um das zu können sollte jeder Mal aufschreiben was ihm an der rechtlichen Seite wichtig ist!

Sessions und Cookies

Bin hier ganz klar dafür Session-Cookies zu erzwingen und optional einen Forever-Login per richtigem Cookie anzubieten. Die ID des Session-Cookies sollte in der Datenbank zum Benutzer gesichert und überprüft werden, vll. wegen Performance in eine Extra-Tabelle namens Logins oder ähnliches worüber sich dann auch statistische Auswertungen möglich machen. Ein Session-Timeout erachte ich als sinnvoll, solange davon feste Cookies nicht betroffen sind, finde einen Timeout von 30 Minuten auch aus sicht des Benutzers annehmbar und aus unserer ein recht geringes Risiko in der Zeit viel Blödsinn zu veranstalten wenn es zu Problemen kam.

Minimale PHP-Version

Habe die letzten Tage "heimlich" Zeitzonen-Support in das BXCP 0.3 eingebaut testweise und es einem Clan zum testen gegeben der auf nem US-Server ist und daher Zeitprobleme hatte in dieser Richtung. Die sind begeistert bisher und ich hatte ne Menge arbeit das ganze zu realisieren weil es PHP 4-kompatibel bleiben sollte. Erst mit Php 5.1.1 und einige sogar bei 5.1.3 kamen erweiterte Datums-Funktionen die mir hier das Leben erheblich erleichtet hätten, bin daher dafür als minimale PHP-Version sogar 5.1.4 vorauszusetzen!

PEAR und PEAR-GO bzw. PEAR-Klassen

Bin ich kein Fan von, bitte rauslassen wenns ok ist

Diese Rechte-Klasse die auch Mambo/Joomla nutzt gefällt mir vom ersten Eindruck prima und bin auch weiterhin gewillt zu 90% nach PEAR-Coding-Standard zu arbeiten beim Coden unter uns sofern das für euch ok ist. Bin noch immer dabei mir Smarty anzusehen und mit PHP 5.1-Klassen herumzutesten, habe allerdings wenig Zeit da ich mich auf mündliche Abschlussprüfung anfang Juli vorbereiten muss. Versuche euch so aktiv wie möglich zu unterstützen und das BXCP 0.3 auch in naher zukunft für einige Wochen auszusetzen nach dem nächsten Patch.

GNA

Hab mich angemeldet, schaltet mich mal bitte frei ins Projekt

SVN

Benutzen wir alle einheitlich TortoiseSVN oder nutzt jemand etwas anderes?

THX

Danke fürs lesen macht Spaß mit euch Leute   

[xsign.dll]

T: DB Konventionen
Ich hatte da mal früher nen ausgiebigen Thread im flashforum gehabt. Der erklärt die problematik recht gut... *such* http://www.flashforum.de/forum/showthread.php?t=188220
Aber ok Ich kann auch mit der andren Variante leben... Daran soll es nun nicht scheitern.


T: DB Struktur
Einer schon was parat?


T: Lizenz
Ich hab das Projekt nun schlichtweg einmal unter den Scheffel von GPL v2 gestellt, da man eine Lizenzform für GNA gebraucht hat. Änderungen diesbezüglich sind jedoch möglich.

T: Debug
jo geht klar - phpunit

T: Arbeitsorga
k... also $input['do'] zu $input['action']
CURD dürfte kein Problem sein.
Module switchen wie gesagt den Input an die Funktionen weiter. Gute Editoren haben dann schlichtweg die Funktionalität, alle funktionen innerhalb des sources anzuzeigen -> einfaches Debuggen/Coden/Übersichtlichkeit.

@vain:
Modul: news
Funktionen: news_create(), news_blabla()
Meinst das so? Joah... hätt ich nix dagegen.

T: Modrewirte
Ja - aber optional einstellbar im ACP z.b.

T: Sessions
Hm? D.h. cookies verpflichtend ohne GET Session variablen?

T: Tpls schützen
K - dann lassen wirs erstmal weg. Man kann theoretischer Weise auch den Apache zwingen per .htaccess, die .tpls als PHP zu interpretieren, aber is auch irgendwo schmufug.

T: Globale Tpls
Ich hab die Tpls, die keinem Modul gehören, trotzdem in unterordner gepackt. Oder man macht einen unterordner "/templates/global" und packt da alles rein.

@hajo: thx @ thx Und ja, turtoiseSvn.

[hajo]

DB Konventionen

Hören wir mal auf den elias dort, der hatte als einiger von wenigen im Forum scheinbar Ahnung

DB Struktur

Können ja Mal sehen was Joomla, Xoops und CO so als DB-Struktur haben um uns alternative Meinungen zu holen bevor wir unsere fest legen

Lizenz

Dann geben wir halt eben nix frei als Release bevor das nicht geklärt ist, wäre auch dafür die daily SVN Downloads von GNA zu deaktivieren bis wir relativ stable sind und uns hier geeinigt haben auf eine Lizenz

Debug

Hier wäre gut wenn wir das wie beim BXCP 0.3 hinbekommen das es irgendwo auf der Seite frei wählbar angezeigt werden kann, damit ich es wie für mich favorisiert als festen Bereich im Kopf setzen kann mit Scrollbalken bei zu langem oder breitem Inhalt, mag nicht wenn wie bei Smarty per Default nen Popup mit Infos kommt, muss dann immer auf geblocktes Popup Fenster anzeigen klicken und das dann auch noch in Vordergrund und Hintergrund schieben ...

Sessions

Müssen zusehen das alle gefährdeten bzw. wichtigen Daten darin geprüft werden vor der ersten Nutzung dieser, geht hier um ein großes Sicherheitsrisiko.

Design-Templates

Trenne die Templates jetzt einfach Mal in Modul- und Design-Templates, wobei Design-Templates für die gesamte Seite sind. Würd das gern wie derzeit bei mir etwaig fortführen vom Prinzip her das die eine Info-Datei bekommen und geparsed werden, bei uns am besten mit Smarty auch.

Templates die nicht fest zu Modulen gehören, aber in diesen genutzt werden könnte man in nen reserviertes Verzeichnis packen, global klingt da schon passend

Webserver

Die Krone von Apache bröckelt, Mini-Lösungen wie Light HTTPD z.B. sind auf dem Vormarsch, finde es gefährlich auf Module eines Webservers zu setzen wie bei modrewrite oder ähnlichem! Zudem sind die moderne Suchmaschinen schlau genug PHP-Anweisungen in Adressen zu lesen.

ACP

Dieses Wort ist altmodisch, ein modernes CMS kennt in meinen Augen nur eine Oberfläche und die ist je nach verfügbarem Zugriff auf dessen Teile aufgebaut. So wie es z.B. Webspell oder CMPro hat mag ich das garnicht. Erspart auch Arbeit weil man dann keine zwei verschiedenen Bereiche bauen muss.

[xsign.dll]

Webserver
Jo... also verschieben wir das mal auf nen späteres release.

GNA und SVN privatisieren
Ich schau gleich mal, ob wir das privat bekommen.
/edit: https://gna.org/support/?func=detailitem&item_id=1093
Schöne scheiße...

Debug
Also derzeit hab ich alles in ein Popup gepackt, fand die Lösung an sich nicht schlecht. Aber ich krieg das sogar als Auswahl in den Anfangsbereich der Site, das dürfte kein Problem darstellen.
/edit: Habs in die config gepackt, ob man popup will, oder direkt als html debugger

ACP
Bei nem ACP hast du halt immer den Vorteil, dass User und Admin strikt getrennt ist. Da machst du einmal die Abfarge $user['can_access_acp'] und hast somit nen großes Sicherheitsrisiko weniger. Sonst musst du immer tausende Abfragen machen, ob der User jetzt den Bereich sehen darf, oder nicht.
Nungut - ich find beide Methoden nicht schlecht, nur muss es gescheit programmiert sein. Wir sollten ganz dringend Gruppen diskutieren. User mit einzelnen Rechten auszustatten ist zwar nice, aber aufwändig für den Admin der Website.

Welche Gruppen sollen wir von vornherein mitbringen? (aussagekräftige Namen wären von Vorteil)
- Administratoren
- Clanleader
- Squadleader
- Clanmitglieder
- Benutzer
- Gäste

Templates
Ja ich hab das derzeit so gehandhabt, dass es eine index.tpl gibt, von der aus alles aufgerufen werden kann. Funktionen mit Rückgabewert (sowas wie {func:navlogin} im bxcp - nur hier eben {$modul->function()}) und eben {$content}, in dem der content des gesamten Moduls, was aufgerufen wurde, geparsed wird. Ich mach nachher gleichmal nen simples Design, mit dem wir zukünftig dann arbeiten. Is ja im Prinzip egal was, hauptsache es is in etwa nen Design...


DB Konventionen
Ok - dann machen wir das so: Primary Keys sind in der ganzen DB unique, andere Keys heißen äquivalent zu den Primary Keys (falls vorhanden)... ooookay

DB Struktur
Schau ich mir direkt mal... später an Muss nömlich jetzt noch updates in der Firma fahrn und Geburtstags CDs brennen ...
/edit: Also bei joomla sieht das ganze so aus:

cms_banner
cms_bannerclient
cms_bannerfinish
cms_categories
cms_components
cms_contact_details
cms_content
cms_content_frontpage
cms_content_rating
cms_core_acl_aro
cms_core_acl_aro_groups
cms_core_acl_aro_sections
cms_core_acl_groups_aro_map
cms_core_log_items
cms_core_log_searches
cms_groups
cms_mambots
cms_menu
cms_messages
cms_messages_cfg
cms_modules
cms_modules_menu
cms_newsfeeds
cms_polls
cms_poll_data
cms_poll_date
cms_poll_menu
cms_sections
cms_session
cms_stats_agents
cms_templates_menu
cms_template_positions
cms_users
cms_usertypes
cms_weblinks


find ich absolut beschissen... keinerlei konvention, und auch die PKs sind alle  auf "id" genamed... sehr unvorteilhaft in meinen augen. aber es ist auch ne alte joomla version, von daher verzeihen wir das den jungs. Übernehmen würde ich folgendes:

cms_groups
cms_session
cms_users

die module haben dann sowieso nochmals die ganzen tables wie z.b.

cms_news
cms_forum
cms_...etc...

Verschlüsselungen
md5, sha1 und was gibt es noch? crypt? Ich würde gern einige unbekannte Sachen mit anbieten...

[Jens-A. Koch]

Thema: Verschlüsselung & Hashing
blowfish, einfachers und erweitertes des, md5. mehr wird meines wissens nach nicht von crypt() unterstützt. twofish gibts da noch, und natürlich AES als erbe von DES. dafür müsste man wohl selbst etwas bastlen.

Gut ist auch base64_decode($data) und base64_encode($data), das ist keine Verschlüsselung sondern ne Kodierung (Schlüssel fehlt).

Ansonten gibts tausende Algorithmen. Angefangen bei Verschiebechiffren á la Cäsar bis zu Kombinationen aus PublicHash und PrivateHash um einen GeneralHashKey zu entschlüsseln.

Kommt auch immer drauf an wozu man das macht.

Hier gilt auch der OpenGrundsatz: eine Verschlüsselung ohne Offenlegung wird nicht als vertrauenswürdig betrachtet.

Thema: Styles

Ich würde Vorschlagen Themes/Styles mit anderen Systemen austauschbar zu halten.
Wir könnten auf einem schon entwickelten Standarddesign von z.B. Wordpress oder einem anderen Blog bzw. CMS arbeiten. Bzw. dadurch gleich den Theme-wechsler einbauen.

Thema: Db-Konventionen

Ich habe den Thread gelesen und kann daraus entnehmen, daß die beim where bzw. join zu vergleichenden Spaltennamen wegen der Übersichtlichkeit auch gleich lauten sollten.
(zB: group.group_id = user.group_id) . Zwingend ist dies jedoch nicht.

Das bedeutet aber nicht das sie group[group_group_id] und user[user_group_id] lauten!

Ich bin daher dagegen den Tabellennamen in Spalten voranzustellen, aber für einheitliche Benennung des gleichen Merkmals.

Ihr werdet feststellen, daß die angesprochenen Entwicklungen (joomla,etc.) ebenso strukturieren.

MySQL-Referenzhandbuch: http://dev.mysql.com/doc/

Thema: Db-Entwurf

Bitte keinen kompletten Db-Entwurf auf den Tisch packen.
Eher so verfahren, daß die zu bearbeitenden Bereiche zuerst in Input / Output Daten zerlegt und dann in Tabellen aufgeteilt werden. Ansonsten sind Bereiche in der Db vollgestopft und entworfen die noch nicht gebraucht werden.

Beispiel: Wenn wir jetzt User-Anmeldung und Sessionhandling implementieren wollen, dann nur Usertable und Sessiontable. Hierin wiederrum nur die dafür relevanten Felder. Also nicht Lieblingsdrink im Usertable. Das wäre ergänzend, wenn man beim UserProfil angelangt ist bzw. die Userverwaltung macht.
Wenn wir Newsmodul etc. anfangen, dann die entsprechenden Tables dafür besprechen und einfügen.

Thema: GNA und SVN Tools privatisieren

Oh ha!  Die Anfrage GNA das SVN zu verstecken bzw. public-access abzustellen schockiert mich etwas und stellt das Prinzip Open-Source Entwicklung ja völlig auf den Kopf. Dazu gehört doch das alle Entwicklerwerkzeuge öffentlich zugänglich sind und als Voraussetzung zur Weiterentwicklung auch der Source öffentlich verfügbar ist.
http://www.gnu.org/philosophy/free-sw.html

Ich hoffe ihr wollt so entwickeln? GPL raufzuschreiben und den Code zurückzuhalten ist widersprüchliches und völlig perplexes Verhalten. Quasi so als ob man auf nen bewachten Parkplatz fährt und dem Wachmann sagt, mein Auto brauchen sie nicht bewachen und ich zahle daher auch nicht.

Ich bin auch gegen das Zurückhalten von Features, denn was angesprochen, diskutiert und geplant wurde kann als Aufgabe eingestellt und assigned werden. Ein anderes Verhalten würde geschlossene Entwicklung bedeuten. User entscheiden im Zweifel für Transparenz und offene Weiterentwicklung. Das wird kein Reddot oder Vignette, das abertausende kostet und Übertrumpfende-Features erst bei Release bekannt gibt.

Auch möchte ich mich aus vorgenannten Gründen gegen ein privates Hosten des SVN aussprechen. Der Bugtracker von GNA ist völlig zureichend. Soweit die von mir gehosteten, Clansphere betreffenden Tracker nicht mehr benötigt werden, gehen sie nach Datensicherung/übertrag off.
Nebenher sollte privat für Support und Diskussion ein Board gehostet sein, denn das ist bei GNA nicht enthalten (so wie dieses). Die GNA Webseite unterstützt kein vernünftiges Hosting, diese ebenfalls privat hosten.

Ansonsten, ein Wort: Dagegen!

Thema: Debug

Ich hab Debug abgestellt, wegen Dopplung mit Xdebug.


Thema: Adminbereich

Ich bin für die Trennung in Content-Verwaltungsbereich und Content-Anzeigebereich.
Wie auch immer man das nennt: ACP, Adminberich/interface, Intern whatever.

[hajo]

ACP

Mh ist dann wohl 2 gegen 1, gebe mich geschlagen

Debug

Hab XDebug wieder gelöscht, die Infos die zusätzlich kamen brachten mir keine Vorteile

Zurückhalten von Daten

Möchte ich auch nicht, allerdings fand ich es eben schwachfug das GNA das Daily SVN Snaphsot zum Download anbietet vom Projekt bevor was stabiles bzw. nutzbares da ist. Für uns wäre das Feature nützlich wenn einer sein Inet verliert und woanders aktualisieren will, aber find es für public gebrauch eben fies. Ansonsten habe ich ja nichts dagegen alles direkt und öffentlich zu entwickeln, bis auf zukünftig geplante Features mit denen noch nicht begonnen wurde diese umzusetzen, bin mir nicht sicher ob diese auch schon in den Bugtracker kommen sollten als Public.

[Jens-A. Koch]

Die zukünftigen geplanten Features könnten nach meiner Auffassung auch Public eingestellt werden. Wir können diese aber als Privat deklarieren, so daß sie nicht angezeigt werden.

Wir können es ja so handhaben, daß man immer die Aufgaben sieht, die tatsächlich gerade bearbeitet werden. Planung wird Privat eingetragen. Mit dem Assign wirds public. Wäre das ok?

[hajo]

jetzt wo ich nochmal darüber nachdenke könnte es bedeuten das andere feature wünsche doppelt und dreifach eintragen, wohl doch das beste alles public zu lassen.