phpBB.de

idee nummer 1.
(wahrscheinlich zu viel verlangt)
diese installations anleitungen solten ehr so aussehen damit kann ich das ganze copy&pasten in php code

ich selber benutze um zu documentieren welche änderung ich am standard phpbb gemacht habe
vielleicht könnte man die installations anleitungen mehr nach so einen system aufbauen
das hatt viel mehr vorteile

• ich selber habe ein programm das mir nach diesen tags sucht, damit habe ich viel mehr überblick was verändert wurde, kann so leichter upaten usw.
• wenn mod, bugfixes usw. sich auf den orginal code beziehen kann ich ihn noch im code finden

ich will garnicht das ihr //<tag> übernimmt aber irgend was in der richtung wäre nicht schlecht
etwas was ich von einen programm parsen kann

punkt 2.
jedes mal wenn ich ein mod sehe welches template dateien mitbringt muss ich kotzen?
um ein paar config einstellungen abzufragen? brauche ich da echt ein template system,
das template passt sowieso i.d.r. nicht zum standard style des forum,
der vorteil eines templates ist doch das man das aussehn ändern kann aber wozu muss ich das für etwas was ich backend ein paar einstellungen kriegt?
deinstallieren, updaten usw. wird doch echt zu quall wenn man ihn 10 verzeichnissen nach den dateien suchen kann
wenn ihr umbedingt templates haben müsst dann packt sie nicht in den phpbb-template ordner


punkt 3. änderungen an den db, wieso müssen eure mods die einstellungen unter phpbb_config speichern? könnt ihr euch nicht einfach eine tabelle anlegen last doch die standard phpbb tabellen in ruhe

wie bitte soll das update von 2.0 zu 2.2 ablaufen wenn die db ganz anders aussieht?
ich will nicht erst die ganzen mods porten müssen damit 2.2 leuft
das mods porten kommt dann wenn das 2.2 leuft und auch nur die man wirklich braucht
[/code]

Erst mal ein paar einführende Zeilen: die grundlegende Syntax der Einbauanleitung der Mods stammt nicht von uns sondern von der phpBB Group. An diesen Syntax lehnen sich die meisten Autoren an - wenn du da was ändern willst, ist dein richtiger Ansprechparter www.phpbb.com

Zu 1.: es bleibt jedem überlassen, wie er die Änderungen am Code selbst übernimmt. Die Anleitung gibt dir ja nur an, welche Änderungen du durchführen musst - die Dokumentation selbiger im Code ist deine Aufgabe.

Zu 2.: Wie willst du es sonst machen? phpBB hat sich für ein Template-System entschieden - also sollten sich auch die Mods daran halten. Eine Mischung von zwei Systemen macht keinen Sinn - als bleibt ja nur der Weg über ein eigenes Template. Das Problem wird sich allerdings vermutlich bei phpBB 2.2 im Admin-Bereich etwas entschärfen.

Zu 3.: Ganz einfach - weil es keinen Sinn macht, für jeden Mod ein neues System bestehend aus Tabelle und Variablensystem hochzuziehen. Ergänzungen der phpbb_config sollten auch beim Update auf 2.2 kein Problem darstellen - solangen alte Werte nicht gelöscht werden.

Ansonsten bleibt es dir natürlich frei, auf den Einbau entsprechender Mods zu verzichten...

Gruß, Philipp

Die bisherige Schreibweise hat sich eingebürgert (ist vielleicht irgendwo sogar festgesetzt!?) und ist imho auch am bequemsten zu lesen.

//<modifikation>
//<name>...</name>
//<orginal>
/*
...
*/
//</orginal>
...
//</modifikation>

Das sieht für mich unübersichtlich aus, bzw. bläht die Dateien nur unnötig auf.

ich selber habe ein programm das mir nach diesen tags sucht, damit habe ich viel mehr überblick was verändert wurde, kann so leichter upaten usw.

Du hast ein Programm, aber wer hat das noch, sprich wer würde von solchen Änderungen noch profitieren ausser dir?

jedes mal wenn ich ein mod sehe welches template dateien mitbringt muss ich kotzen?
um ein paar config einstellungen abzufragen? brauche ich da echt ein template system,
das template passt sowieso i.d.r. nicht zum standard style des forum

Das Templatesystem ist eine Stärke von phpBB. Warum sollte man sich zurückentwickeln und wieder alles in PHP Dateien schreiben? Ist doch unsinnig imho. Und die meisten zusätzlichen Templates werden auf subSilver ausgerichtet. Wenn es dann bei einem komplett anders aufgebauten Template anders aussieht, dürfte klar sein.

punkt 3. änderungen an den db, wieso müssen eure mods die einstellungen unter phpbb_config speichern? könnt ihr euch nicht einfach eine tabelle anlegen last doch die standard phpbb tabellen in ruhe

Jeder Bereich im phpBB hat seine Tabelle(n). Der Bereich im ACP der Boardkonfiguration nutzt die Tabelle phpbb_config. Warum sollte man eine extra Tabelle anlegen, wenn ein Mod diesen Bereich erweitert?

wie bitte soll das update von 2.0 zu 2.2 ablaufen wenn die db ganz anders aussieht?

Wieso anders aussehen? Die original Tabellen werden ja nicht total verändert, sondern nur Felder hinzugefügt oder ganz neue Tabellen erstellt. Der Updater wird wohl so weit sein, original von neuen Tabellen zu unterscheiden...

Zu 1:
Grundsatzlich ein guter Ansatz. Ich mache das bei einigen Kunden von mir auch so, dass ich Änderungen so einbaue:
Ds überall zu machen wäre allerdings relativ sinnfrei, da das den Einbautext eines Mods in etwa verdreifacht. Das macht es dann nicht einfacher sondern komplizierter.

zu2:
Das macht man weil es für den User einfacher ist. Man muss nicht tausend tpl-Dateien abändern sondern nur eine neue Template-Datei hochladen. Du hast eben gesagt Du willst den Update-Prozess bei Mods erleichtern... nun je mehr der Mod auf eigene Dateien zurückgreift desto einfacher ist das Update.
Auch Non-subSilver Templates wird das Anpassen eines Mods der eigene tpl-Dateien mitbringt imho leichter. Denn auch wenn man einen Mod in eine bestehendes Template einbaut, kann man als Autor nur Subsilver berücksichtigen und wenn man die Änderungen nun in EINER Datei machen muss ist das wesentlich leichter als wenn man sich die Styleänderungen durch den Mod aus allen betroffenen Templates erst zusammensuchen muss...

zu3:
Dazu ist die config-Tabelle nunmal da. Überleg mal, wenn jeder Mod der nur ein oder zwei Parameter speichern muss eine eigene Tabelle für die config erstellen würde. Dann hätten Boards mit vielen Mods bald 30 Tabellen mehr nur für die config der einzelnen Mods.
Außerdem:
- das Nutzen der Config-Tabelle ist performanter (man muss keinen eigenen Query erstellen, sondern kann auf den phpBB-internen Code zurückgreifen in dem die Config ausgelesen wird)
- aus dem gleichen Grund ist das Modden leichter einfach $board_config['eigener_parameter'] statt einem Query
- dementsprechend wird auch der Quelltext des Mods geringer und er lässt sich leichter einbauen
- dementsprechend lässt er sich auch leichter wieder ausbauen, da er näher an dem Ur-phpBB dran ist.

Was das Update auf 2.2 angeht: Man kann eh davon ausgehen dass man so gut wie alle Mods neuprogrammieren muss. Ich kann mir allerdings nicht vorstellen, dass die config-Tabelle groß abgeändert wird und wenn wird es sicher ein Equivalent dazu geben.

Gruß, Dave

PhilippK hat geschrieben:Zu 1.: es bleibt jedem überlassen, wie er die Änderungen am Code selbst übernimmt. Die Anleitung gibt dir ja nur an, welche Änderungen du durchführen musst - die Dokumentation selbiger im Code ist deine Aufgabe.

spricht doch nix gegen das mit der mod autor arbeit abnimmt, für ihn ist es auch nicht viel mehr arbeit
meine aufgabe, deine aufgabe, ist doch egal

@Leuchte ob das jetzt gut lesbar ist doch blos gewöhnungs sache und die tatsache das nur ich das program habe ist echt kein problem, jeder php-anfänge kriegt sowas hin

PhilippK hat geschrieben: Zu 2.: Wie willst du es sonst machen? phpBB hat sich für ein Template-System entschieden - also sollten sich auch die Mods daran halten. Eine Mischung von zwei Systemen macht keinen Sinn - als bleibt ja nur der Weg über ein eigenes Template. Das Problem wird sich allerdings vermutlich bei phpBB 2.2 im Admin-Bereich etwas entschärfen.

was spricht dagegen überhaupt kein template system zu benutzen? (ich rede jetzt vom backend nicht vom frontend)
das mit 2.2 hört sich gut an

Leuchte hat geschrieben:Das Templatesystem ist eine Stärke von phpBB. Warum sollte man sich zurückentwickeln und wieder alles in PHP Dateien schreiben? Ist doch unsinnig imho. Und die meisten zusätzlichen Templates werden auf subSilver ausgerichtet. Wenn es dann bei einem komplett anders aufgebauten Template anders aussieht, dürfte klar sein.

weil der aufwand höher ist als der nutzen (ich reden vom backend)



zu 3. ok phpbb_config ist ein schlechtes bsp aber es gibt sonst noch viele andere mods die an anderen tabellen sachen ändern, mag sein das das update noch klapt aber die daten (die des mods) sind dan sicherlich verloren
und wie kann ich dann noch erkennen was standard phpbb ist und was mod?


ich finde das phpbb ist einfach plugin unfreundlich,

ich finde das phpbb ist einfach plugin unfreundlich,

rofl... was ist denn dann PlugIn freundlich???? Wir reden ja hier auch in der Regel nicht von PlugIns sondern von Mods. Mod = Modifikation = Änderung des Quellcodes.

Schau Dir mal andere Opensource-Projekte an. Wo ich es gerade offen habe, kennst Du OS-Commerce? Eines der bekanntesten OS-Shop-Systeme. Hier mal ein Auszug aus dem Quellcode:
So sieht eine Software OHNE Template-System aus. PHP und HTML-Source wahllos vermischt. Wenn Du da auch nur kleine Veränderungen machen willst, brauchst Du Stunden um Dir überhaupt erstmal die Stelle zu finden wo Du ansetzen willst.

Für jeden Mod eine extra Tabelle... das würde einfach nicht funktionieren. Überleg mal: Ein einfacher Mod der im Profil ein weiteres Feld hinzufügt, das im Posting angezeigt würde. So fügst Du das Feld einfach in die users-Tabelle ein, packst ein paar Variablen dazu und fertig. Wenn das ganze über eine eigene Tabelle laufen würde, würden einige DB-Abfragen, wahrscheinlich sogar JOINs dazu kommen und Boards mit mehr als 15 Mods könnte man auf normalem Webspace schon garnicht mehr betreiben, sondern bräuchte einen eigenen Server weil die Performance so dermaßen in die Knie gehen würde.

Gruß, Dave

Meine Comments dazu:

Da das PHPBB ohnehin ein riesiges Projekt ist was übersichtlich sein soll, ist es nur gut das man auf Templates zurückgreift anstatt wie schon von @Dave angedeutet sich in dieses endloses begreifen und suchen zu verstricken.

Deiner Meinung nach sollte man Mods (=Modifikationen) in eigene Hohheitsgebiete unterordnen anstatt auf bestehende Tabellen zurückzugreifen.
Das mag wohl auf den ersten Blick sinnvoll erscheinen doch die Frage des wie? ist schwierig.

Auf der einen Seite muss
-> die Übersicht gewart bleiben was man nicht erreichen kann wenn man Mod Felder in neue Tabellen einordnet statt auf bestehende wie z.B. Config.
Ich suche eine Konfiguration und suche dies in der Config Datei. Anstatt in mehreren individuell angelegten File. Die Administration und entsprechende Anpassungen sind übersichtlicher.
Auf der anderen Seite
-> sollen alle Mod Sachen zusammenhängend bleiben um sie leichter zu entfernen. Das würde man mit deinen Andeutungen schaffen nur könnte dies erhebliche unübersichtliche und Performancerellevante Aspekte bedeuten die nicht erwünscht sind.

Weiterer Aspekt:
-> Durch die vielen Mods können an ein und der selben Stelle mehrere Anpassungen vorgenommen werden. Der erste Mod kann es noch richtig deuten, der Zweite schon vielleicht nicht mehr.
Wenn man von der Easymod u.A. Gebrauch macht.
Das macht die Sache bei umfangreichen Mods schwierig sei es mit oder ohne Easymod.

Und ein User der nicht weiss was er genau tut, hat hier schon seine Probleme. Ein Programmierer dagegen wiederrum nicht. Er muss halt nervenauftreibende Arbeit erledigen.

Ich würde liebend gerne Plugins anstatt Mods verwenden und anpassen anstatt umgekehrt nur sind Mods eben nur möglich und machen am meisten Sinn.

Der Aspekt des Modens in DB und Code ist aber eine Sache für sich, eine richtige Lösung gibt es auch nicht.


paar Ideen:
- Nun haben wir ja die Easymod ein nettes Tool was zwar Codestellen modifizieren kann aber nicht unbedingt SQL einsetzen kann.
Hier wäre der Ansatz SQL Statements zu parsen und eine File evtl. zu erzeugen die DB-Anpassungen protokolliert. Wie z.B. Feld X, in Table Y hinzugefügt am xx.xx.xxxx um xx:xx uhr.
So wäre schon mal ein DB Rollback zu Zeitpunkt X denkbar
- Codemodify:
das ist ein heftiger Aspekt.
Problem hierbei ist man müsste den ungemoddeten Zustand der File X festhalten oder kennzeichnen. Was die Sache schwierig macht schließlich kann die Suchroutine des Mods X von einem anderen IST-Zustand ausgehen als Mod Y.
Wie aber unterscheiden?
Wenn man von z.B.
Haus,Baum,Auto,Zebra,Wurm

ausgeht.
Mod X macht After-Add Baum, -> Wald,

und es nun heisst:
Haus,Baum,Wald,Auto,Zebra,Wurm

Mod Y macht find Haus,Baum,Auto
würde es nicht funktionieren da ein geänderter Ist-Zustand vorliegt


Wenn aber Mod Y wissen würde das ein Mod an seiner Stelle bereits modifiziert hat und erkennen würde das sein find nicht mehr aktuell ist und dieses entsprechend anpassen würde.

Wäre es perfekt....

Da aber die Zeilen meistens nicht exakt sind wird es schwierig die exakte Position zu finden fürs modify. Wenn man aber eine feste Einfügmarke hätte die signalisiert hier ist Bereich X wäre denke ich besser.

Aber alles in allem ist die funktionsweise sehr waage

btw:
man kann in php auch mit # auskommentieren
du musst die dinger also nicht durch // ersetzen

mfg saerdnaer

saerdnaer hat geschrieben:btw:
man kann in php auch mit # auskommentieren
du musst die dinger also nicht durch // ersetzen

mfg saerdnaer

Ach jetzt verstehe ich was er damit meint *blick*

solten ehr so aussehen

Code: Alles auswählen

// 
//-----[ COPY ]------------------------------------------ 
//

D.VE