Verfasst: 18.11.2008 20:44
Sehe ich auch so und sehe ich auch gerne ein.
phpBB.de - Die deutsche phpBB-Community
https://www.phpbb.de/community/
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.Oder werden alle Tabellen geupdatet am Anfang, nur die Versionsnummer ganz am Schluss?
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
Code: Alles auswählen
'user_notify_type' => $data['notify'],
Code: Alles auswählen
'user_gender' => $data['gender'],
Die Frage ist, ob man da nicht jemand anderes mit betrauen kann.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.
1.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.
Code: Alles auswählen
/******BEGIN FOO_MOD***************/
$bar = 'foobar';
/******END FOO_MOD*****************/
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: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.
Ich weiß nich, in wiefern das machbar ist, aber das hört sich gut an.D@ve hat geschrieben: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.Code: Alles auswählen
/******BEGIN FOO_MOD***************/ $bar = 'foobar'; /******END FOO_MOD*****************/
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.)D@ve hat geschrieben:Weil in header- und footer-Methode lediglich zwei "Hooks" eingebaut werden und alles andere über externe Dateien laufen würde.
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 anderenD@ve hat geschrieben:Wenn da Mod-Entwickler und und core team mehr zusammenarbeiten würden wäre das sicherlich von enormen Vorteil.
IIRC machen sowas die Coding Guidelines, ansonsten meckert das MOD-DB-Team irgendwannD@ve hat geschrieben:Vielleicht könnte man ähnlich wie bei den Coding-Guidlines auch so eine Art Modding-Guidlines veröffentlichen.