Seite 13 von 19

Verfasst: 18.11.2008 20:44
von bantu
Sehe ich auch so und sehe ich auch gerne ein.

Verfasst: 18.11.2008 20:47
von Daisy77
HILFE - kann mir mal einer sagen wie man die Konflikte löst? Oder wo das steht? Find nix.... WO finde ich überhaupt den Konflikt wenn ich auf "Unterschiede/Konflikte zeigen" klicke - dann wird mir doch nur, wie bei den zusammengeführten Dateien - angezeigt was wo hinzugefügt, geändert, gelöscht wurde, oder?

edit: Ich seh grad, ich hab's nur bei einer Datei bisher versucht, die includes/functions_user.php und scheine das gleiche Problem wie Würzi zu haben - was muss ich manuell nachbessern?

Verfasst: 18.11.2008 20:51
von nickvergessen
Support-Anfragen bitte im entsprechenden Forum stellen

Verfasst: 18.11.2008 20:56
von Daisy77
wo ist das? *überblick-verlier*

edit: sorry - hab's schon gefunden....

Verfasst: 18.11.2008 21:51
von Acyd Burn
Oder werden alle Tabellen geupdatet am Anfang, nur die Versionsnummer ganz am Schluss?
So ungefähr. Das Update setzt temporär eine neue Versionsnummer, damit das ACP hinterher erkennt ob das Update auch wirklich durchgelaufen ist - ansonsten würden zu viele abbrechen und das Board wäre noch auf 3.0.2, er sagt aber es wäre 3.0.3. Ist eine Sicherheitsmaßnahme. In 3.0.3 haben wir zudem eine Konstante hinzugefügt um das noch besser beim nächsten Update erkennen zu können.

Und anstatt über die Code Changes zu meckern wären wir mehr daran interessiert wie man das Lösen von "Konflikten" im updater besser lösen könnte - denn hier scheint ja eigentlich das Hauptproblem zu liegen.

Verfasst: 18.11.2008 23:34
von Würzi
Danke für die Antwort, ich dachte wirklich die Tabellen werden erst am Ende angelegt, weil beim Abbruch eben noch 3.0.2 stand.
Wenn die Versionsnummer erst am Ende eingetragen wird, dann hat alles gut geklappt.

Und ich mecker nicht über die fehlenden Code Changes, aber würde es besser finden, wenn es sie zusätzlich geben sollte. :wink:

Begründung habe ich schon mal genannt, weil... ja eben weil man bei Konflikten eben einen besseren Überblick hat und auch für Anfänger, welche nicht so richtig wissen, was bei Konflikten zu machen ist. Hab darüber ja schon geschrieben. Mod einbauen kann jeder ohne php Kenntnisse, aber um die Konflikte zu beheben, muss man sich schon ein bisschen besser auskennen.

Würde es ja auch nicht schlimm finden, wenn sie irgendwann wenn Zeit ist, nachgereicht werden.
Reihenfolge:
- Neues Paket
- Autoupdater
- Codechanges Style und Language
-
- Nachreichung Codechanges wenn Zeit ist.

Wer viel Mods einbaut und dadurch Konflikte hat, muss halt eben ein bisschen warten. Aber er weiss, daß sie irgendwann kommen. Muss ja auch nicht in Modx sein. :wink:

Aber wie gesagt... alles nur Vorschläge! :wink:

Nun zu den Konflikten:
Eigentlich fehlt zumindest hier, ne richtige Anleitung wie ein automatisches Update genau verläuft und was genau zu beachten ist, meiner Meinung nach. Ich musste da lang schauen, damit ich nicht aus Unachtsamkeit was kaputt mache.

Oben kriegt man versteckt zum aufklappen, die Dateien angezeigt, welche durch keine Modifikation geändert wurde.
Dann kommen die Dateien, welche verändert wurden durch Modeinbau, aber keine Konflikte entstehen.
Dann kommen die Konflikte, welche besonders zu beachten sind.

Da gibts ja wirklich die meisten Fragen dazu. Eine bebilderte Anleitung hierzu wäre nicht schlecht. :oops:
Man sieht nur viel Farben, aber wenn man noch nie etwas damit zu tun gehabt hat, versteht man glaub ich recht wenig. Die Beiträge hier im Forum geben mir da Recht.
Nirgendwo wird darauf hingewiesen, daß man eigentlich nur auf folgendes achten muss:
Anfang der derzeitigen Originaldatei /Ende der derzeitigen Originaldatei
Anfang der neuen, aktualisierten Datei /Ende der neuen, aktualisierten Datei


Wenn man sich dies dann inline anzeigen lässt, dann kann man es schön in einen Texteditor kopieren und abarbeiten. Wird ja auch öfters hier von den Supportern beschrieben. Aber ne generelle Anleitung würde hier einigen sehr hilfreich sein.

Weniger Konflikte, weniger Schwierigkeiten:
Dies dürfte deine Hauptfrage gewesen sein, vermute ich.

Also wenn ein Code total verändert wurde ist es klar, daß der Updater dies nicht löst. Dies wird er nie können!
Aber ich hatte einfache Konflikte, wo ich nicht vermutet hatte, daß es da überhaupt Konflikte gibt. Vielleicht könnte man dies noch irgendwie verbessern, ich weiss nicht.

Beispiel includes_functions.php

Code: Alles auswählen

<<<<<<< Anfang der derzeitigen Originaldatei

		'SITE_LOGO_IMG'			=> $user->img('site_logo'))

	);
  

        // Start User Blog Mod
	include($phpbb_root_path . 'blog/header.' . $phpEx);
	// End User Blog Mod

======= Ende der derzeitigen Originaldatei / Anfang der neuen, aktualisierten Datei

		'SITE_LOGO_IMG'			=> $user->img('site_logo'),

		'A_COOKIE_SETTINGS'		=> addslashes('; path=' . $config['cookie_path'] . ((!$config['cookie_domain'] || $config['cookie_domain'] == 'localhost' || $config['cookie_domain'] == '127.0.0.1') ? '' : '; domain=' . $config['cookie_domain']) . ((!$config['cookie_secure']) ? '' : '; secure')),

	));

>>>>>>> Ende der neuen, aktualisierten Datei
Den Blog Mod hat er mir rausgeschmissen, obwohl unter dem site logo img nur was hinzugefügt wurde. Verstehe ich nicht ganz, vielleicht lässt sich da z.B. was verbessern.

Weiter wurde bei mir z.B. der gender rausgeschmissen in der ucp_profile.php, weil dies neu dazugekommen ist.

Code: Alles auswählen

'user_notify_type'	=> $data['notify'],
Weg war:

Code: Alles auswählen

'user_gender'	=> $data['gender'],

Meine ganzen Konflikte 8 (ok ich hab massig Mods drin :lol: ) wären eigentlich nur ich glaub 3 richtige gewesen, wo der code wirklich stark verändert wurde.

Konnte ich dir hiermit weiterhelfen? :)

Verfasst: 18.11.2008 23:46
von D@ve
Hallo Meik,
Ich sehe es aber nicht ein die kostbare Zeit meines Teams für das erstellen von Code Changes zu opfern, die nur eine zusätzliche und keine neue Methode des Updates darstellen.
Die Frage ist, ob man da nicht jemand anderes mit betrauen kann.

Und anstatt über die Code Changes zu meckern wären wir mehr daran interessiert wie man das Lösen von "Konflikten" im updater besser lösen könnte - denn hier scheint ja eigentlich das Hauptproblem zu liegen.
1.
Wenn man auf "Zusammengeführte Datei anzeigen" klickt. Habe ich erstmal recht lange gebraucht nachzuvollziehen, was ich da genau auf meinem Bildschirm habe... Ist mir zwar jetzt klar, aber wenn man mal ein paar Worte über die beiden angezeigten Spalten verlieren wäre das sicherlich nicht verkehrt.

2.
Imo sollte die Anzeige von Konflikten lieber etwas ZU pingelig sein. Ich hab das ein paar mal getestet. Auch wenn keine Konflikte angezeigt wurden, hat er mir die Dateien beim "Zusammenführen" wie oben beschrieben trotzdem total verwurstet und einen bunten Mix aus allen Versionen erzeugt...

3.
Es wäre praktisch, wenn der Installer beim Zusammenführen die Codefragmente die nicht eindeutig sind, nicht einfach löscht sondern auskommentiert (zumindestens sollte man das optional einstellen können). Gibt zwar dann beim nächsten Update wahrscheinlich Probleme, aber erfahrenere Benutzer würden davon sicher profitieren.

4.
Wäre es nicht möglich eine Art Konvention für Modder einzuführen
Meine Änderungen am Code sehen in der Regel eh immer so aus:

Code: Alles auswählen

	/******BEGIN FOO_MOD***************/
	$bar = 'foobar';
	/******END FOO_MOD*****************/
Wenn man das standardisiert und vielleicht noch eine Konvention einführt, die einen Updater erkennen lassen ob es sich um EDIT ADD oder REPLACE handelt, könnte man damit doch Konflikte evtl reduzieren oder zumindestens eingrenzen.


Generell würde ich weniger beim Updater ansetzen als einfach von vornherein Modding-Funktionen mit zu berücksichtigen. Ich habe da viel experimentiert. Wenn man an bestimmten Stellen so eine Art Hook-Funktionen integriert, kommt man für SEHR viele Mods komplett ohne direkte Code-Änderungen aus.
Wir haben ein komplettes CMS mit angehängtem CRM entwickelt das komplett auf phpBB aufsetzt. Der "Mod" ist in weniger als einer Minute eingebaut... Weil in header- und footer-Methode lediglich zwei "Hooks" eingebaut werden und alles andere über externe Dateien laufen würde.

Wenn da Mod-Entwickler und und core team mehr zusammenarbeiten würden wäre das sicherlich von enormen Vorteil.

Was ich in Mods auch immer mal wieder sehe ist, dass die Entwickler da einfach keine Ahnung von den Möglichkeiten haben die phpBB hergibt. Da werden Änderungen in irgendwelche Sprachdateien geschrieben anstatt eigene files zu integrieren, oder man hantiert mit Befugnissen über die $config-Variablen rum anstatt eigene Permission-Files zu integrieren usw... Vielleicht könnte man ähnlich wie bei den Coding-Guidlines auch so eine Art Modding-Guidlines veröffentlichen.

Klar... ist alles Aufwand, aber imo spart man das dann letztlich beim Support wieder ein.

Gruß, Dave

Verfasst: 19.11.2008 00:13
von nickvergessen
D@ve hat geschrieben:3.
Es wäre praktisch, wenn der Installer beim Zusammenführen die Codefragmente die nicht eindeutig sind, nicht einfach löscht sondern auskommentiert (zumindestens sollte man das optional einstellen können). Gibt zwar dann beim nächsten Update wahrscheinlich Probleme, aber erfahrenere Benutzer würden davon sicher profitieren.
Das wär ne Interessante Idee, dann gibt's beim nächsten Update wieder Probleme, weil da n auskommentierter Block drin steht. :-?
D@ve hat geschrieben:

Code: Alles auswählen

	/******BEGIN FOO_MOD***************/
	$bar = 'foobar';
	/******END FOO_MOD*****************/
Wenn man das standardisiert und vielleicht noch eine Konvention einführt, die einen Updater erkennen lassen ob es sich um EDIT ADD oder REPLACE handelt, könnte man damit doch Konflikte evtl reduzieren oder zumindestens eingrenzen.
Ich weiß nich, in wiefern das machbar ist, aber das hört sich gut an.
D@ve hat geschrieben:Weil in header- und footer-Methode lediglich zwei "Hooks" eingebaut werden und alles andere über externe Dateien laufen würde.
Nun, bliebe nach das Problem der MODs, die denn Benutzernamen und Benutzerfarbe mit speichern. Ich denke da sind dann vorallem größere MODs von betroffen (Gallery, KB, Bugtracker, Arcade usw.)
Bei genau diesen MODs gibt's wohl auch die meisten Probleme bezüglich der Berechtigungen, da man sie wohl am liebsten Alben/Kategorie/Spiel abhängig gestallten möchte. Da wär ich n Stückles weit schon froh, wenn
D@ve hat geschrieben:Wenn da Mod-Entwickler und und core team mehr zusammenarbeiten würden wäre das sicherlich von enormen Vorteil.
der Fall wäre. Denn ich sag mal so, dass ganze dürfte für jemanden der sowohl das Rechtemanagement im ACP geschrieben hat, als auch für denn der sie in der includes/auth.php ausliest besser verständlich sein, als für so manch anderen :-? (Ich bekomms jedenfalls nicht hin, dass auf phpBB-Art zulösen, siehe Gallery)
D@ve hat geschrieben:Vielleicht könnte man ähnlich wie bei den Coding-Guidlines auch so eine Art Modding-Guidlines veröffentlichen.
IIRC machen sowas die Coding Guidelines, ansonsten meckert das MOD-DB-Team irgendwann ;) Sowas als Pflicht zu setzen ist immer schwierig. Weil irgendjemand baut was, was jemand braucht und dann will ihm jemand sagen, dass er dass so nicht machen soll, sondern komplizierter (für ihn) obwohl es so funktionsfähig ist.

Verfasst: 19.11.2008 00:21
von Daisy77
@Würzi: Ging das an mich? Glaub nicht - aber trotzdem danke für die Erklärung, auch wenn sie inzwischen zu spät kommt - habe einfach alle (5) Konflikte mit dem zweiten Button "gelöst" - ich weiß einfach nicht wie man sie manuell vorher lösen sollte? Jedenfalls hab ich die entsprechenden Dateien notiert und alle meine Mods überprüft ob sie mit diesen Dateien was zu tun haben und nachgesehen ob da was rausgeflogen ist. Das war dann nur noch bei 3 der Fall, die hab ich dann nach dem Download der Zip-Datei korrigiert und in mein (neues Test- :lol: )Forum hochgeladen. Dann noch meine 2 Styles geupdatet - 1h :o - Frag mich wie Du das mit 15 so schnell hingekriegt hast! Jetzt hab ich echt keinen Bock mehr, getestet wird morgen ....

Was ich aber eigentlich sagen wollte: Meine große Update-Angst war unbegründet, irgendwie wurschtelt man sich doch da durch! Ich find das Automatische Update ok, auch für Neulinge (aber wie Würzi schon richtig sagt wäre eine Anleitung wie man Konflikte löst ganz hilfreich), wenn ich bedenke ich hätte 180 Dateien im Stil der Code-Modifikationen der Styles durcharbeiten müssen, ich glaub da schleichen sich Flüchtigkeitsfehler ein... Zumindest sollte man das nicht mitten in der Nacht machen.

In diesem Sinne: Gute Nacht phpbb-Deutschland!

Verfasst: 19.11.2008 01:07
von D@ve
[quote]Das wär ne Interessante Idee, dann gibt's beim nächsten Update wieder Probleme, weil da n auskommentierter Block drin steht.[/quote]

Wie gesagt, optional. Ich hab auch kein Problem wenn ich einer PHP-Datei $update.cfg irgendwelche Flags setzen müsste (womit man es umgehen würde, dass unerfahrene Benutzer sich nur noch mehr Stress mit machen).

[quote]Ich weiß nich, in wiefern das machbar ist, aber das hört sich gut an. [/quote]

Ja eigentlich schon... Der Vorteil wäre, dass der Updater schon wüsste wo Problemstellen vorhanden wären. Man könnte hier auch wieder ein Flag in einer Configdatei setzen, wo alle anderen Änderungen ignoriert und einfach überschrieben werden.

Jetzt mal ganz primitiv gedacht:
[code] /******BEGIN FOO_MOD DELETE_BLOCK***************/
$bar = 'foobar';
/******END FOO_MOD DELETE_BLOCK*****************/[/code]

=> okay hier wurde Originalcode gelöscht. Den kann man folglich auch in der neuen Version löschen.

[code] /******BEGIN FOO_MOD INSERT_AFTER_BLOCK***************/
$bar = 'foobar';
/******END FOO_MOD INSERT_AFTER_BLOCK*****************/[/code]

=> Hier wurde zusätzlicher Code eingefügt. Auch das sollte nicht zu Konflikten führen (zumindestens zu keinen die man automatisch erkennen könnte) und kann übernommen werden


[code] /******BEGIN FOO_MOD REPLACE_BLOCK***************/
$bar = 'foobar';
/******END FOO_MOD REPLACE_BLOCK*****************/[/code]

=> Code wurde ersetzt. Hier braucht man nicht lange nachdenken, das IST per Definition ein Konflikt

[quote]Nun, bliebe nach das Problem der MODs, die denn Benutzernamen und Benutzerfarbe mit speichern. Ich denke da sind dann vorallem größere MODs von betroffen (Gallery, KB, Bugtracker, Arcade usw.) [/quote]
Alles könnte man mit derartigen Hooks natürlich nicht abfangen... Aber MEHR als man denkt. So kann man zum Beispiel Template-Variablen einfach überschreiben. So kann man zB den 'PAGE_TITLE' einfach über nochmaliges Ausführen der assign_vars-Methode überschreiben wenn man was anderes braucht... Gleiches ginge natürlich auch mit SQL-Statements und dergleichen.
Ich habe bei mir zum Beispiel auch einen einfachen Chat entwickelt, welcher neue Forenbeiträge automatisch im Chat postet. Ich hatte dazu erst Änderungen in der Posting.php gemacht. Mittlerweile habe ich einfach in meinem Footer-Hook abgefragt, ob ich in der posting.php bin und über $mode und $redirect_url die Topic-ID ausgelesen und entsprechend einen Link auf das Topic in den Chat eingefügt - klappt wunderprächtig.

Also ich bin mir relativ sicher, dass wenn man sich damit mal etwas auseinandersetzen würde und dort ein Konzept entwickeln würde, man SEHR viele Moding-Probleme komplett ohne Änderungen im Code erschlagen könnte (um Template-Änderungen kommt man natürlich meist nicht drumrum).
Ich hab bei mir ein Verzeichnis
/mod_includes da gibt es mehrere files
mod_header.php
mod_footer.php
mod_constants.php
mod_functions.php
mod_functions_advertise.php
functions_seo_urls.php
usw.

Bis auf den SEO-mod habe ich alle Mods auf diese Weise integriert. Klappt wunderprächtig. Sind drei Änderungen: zwei in der functions für die beiden Hookdateien und eine in der adm/index.php um im acp auch Konstanten und funktionen zur Verfügung zu haben. Ich hab extra Language-Dateien, extra Permissionsdateien und wenn der SEO-Mod nicht wäre, würde ein Update also nur aus überschreiben der kompletten Files bestehen und Neueinbauen des "Modding-Mods" bestehen

Ich hab das selber nur auf einem sehr einfachen Level. Wenn man sowas direkt out-of-the-box integrieren würde könnte man das natürlich sehr viel weiter treiben und in jeder Datei wichtige Hookpunkte integrieren (zB vor SQL-Statements, bei assign_block_vars etc).
Hab mir da schon mehrfach Gedanken drüber gemacht, sowas macht aber entsprechend nur Sinn wenn man das in den Core integriert, wäre dann aber eine spannende Sache. Wenn man diese Modding-Funktionen von vornherein anbietet würden, das sicher viele Modder auch aufgreifen...

Man muss hier sicherlich auch unterscheiden ob eine Community kommerziell oder hobbymäßig betrieben wird. Kommerzielle Forenbetreiber haben andere Bedürfnisse (und bauen sich idR keine 46 Hacks ein ;-).
Für letztere wäre es zum Beispiel auch interessant, wenn man die Updates in sicherheitskritische und nicht-sicherheitskritische Aspekte unterteilt. So könnte man nur die wenigen Sicherheitsupdates vornehmen und die sonstigen Updates dann alle auf einen Schwung machen. Viele Bugs die im 03er Release gefixt wurden habe ich garnicht gemerkt. Und wenn ich jetzt zwei drei Releases überspringen könnte hätte das eine Menge vorteile...

Aber okay, das wäre reines Wunschdenken... Man muss auch mal spinnen können.

Gruß, Dave