Installation erweitern (premodding phph 3.0.12 +)

[regazer]

Weil ich nicht für jedes erstellte Forum immer alles nach der eigentlichen Installation mühsam einrichten möchte, geht es mir darum, die Installation dahin gehend zu vereinfachen, soviel wie möglich bereits in die Datei schema_data.sql (Verzeichnis install/schemas) zu integrieren. Wie das wahrscheinlich am Einfachsten geht, wurde mir bzgl. BBCodes von HabNurNeFrage
viewtopic.php?f=6&t=232311 empfohlen.

Nun habe ich auf genau diese Weise auch Kategorien, Foren und Beiträge aus der Datenbank übernommen und in schema_data.sql integriert. Dabei habe ich allerdings folgende Probleme:
1.) Die Rechte für Kategorien und Foren werden nicht korrekt übernommen.
2.) Setze ich die Rechte nach der Installation manuell, sind die Beiträge nicht sichtbar. Ich kann sie nur sehen, wenn ich im persönlichen Bereich "eigene Beiträge" wähle.

Kann mir jemand erklären, wie ich die Rechte bereits bei der Installation korrekt setzen kann? Wo bzw. wie sie bei der standardmässig erstellten Beispielkategorie und dem Beispielbeitrag gesetzt werden, war mir leider unersichtlich.

Ein weiteres Problem stellen Modifikationen dar, die zur Funktionalität eigene Installations-Dateien haben. Wie kann ich die darin enthaltenen reinen MySQL-Befehle zum Erweitern der Datenbank in die "normale" Installation integrieren? Nachdem ich viele Wochen damit verbrachte, bei neu angelegten Foren immer wieder alle Modifikationen nach der Installation manuell einbauen zu müssen, habe ich dazu einfach keine Lust mehr. Weil die für die Forenstruktur erforderlichen Daten sich in der selben Datenbank befinden wie später die eigentlichen Foreninhalte, ist gar nicht dran zu denken, das irgendwie aus einer vorhandenen Installation zu extrahieren.

[Elsensee]

Würde es dir was ausmachen, wenn du deine schema_data.sql mal ins Pastebin oder so stellst? Kannst die Texte oder privaten Infos natürlich entfernen, nur die zum Reproduzieren und "Debuggen" benötigten Daten sollten natürlich erhalten bleiben.

[regazer]

Danke erstmal für die Rückmeldung. Alte Tests habe ich nicht belassen, weil sie nicht funktionierten. Aktuell habe ich bei einem neuen Ansatz festgestellt, daß es nicht möglich ist, auf ein verstecktes Forum zuzugreifen, selbst wenn man dafür die Berchtigungen gesetzt hat.

Weil meine Fragen mehrere Bereiche umfassen, erstmal zum Thema Kategorien und Foren (noch ohne Beiträge, vielleicht ergibt sich die Lösung dann nebenbei)

Zusätzlich angelegt wurden eine Kategorie members und darin 2 Foren: "hidden" und "members only"

Bei direktem Anlegen innerhalb des aktiven Forums waren die Rechte so gesetzt, daß auf die Kategorie nur Admins, Moderatoren und Mitglieder zugreifen konnten. Dasselbe gilt für das Forum "members only". Das hat sowiet funktioniert. Das Forum "hidden" wurde so gesetzt, daß nur Admins drauf zugreifen können. Soweit die Theorie. Praktisch war das Forum auch für Admins nicht sichtbar.

Nach Übernahme der Einstellungen in die schema_data.sql und Neuinstallation sind diese Einstellungen auch alle im ACP sichtbar, aber es sind gar keine Gruppen eingetragen. Die stehen alle unten bei "Gruppen hinzufügen" ...

Vor # POSTGRES COMMIT # habe ich in schema_data.sql dies hinzugefügt

Code: Alles auswählen

--
-- Daten für Tabelle `phpbb_forums`
--

INSERT INTO `phpbb_forums` (`forum_id`, `parent_id`, `left_id`, `right_id`, `forum_parents`, `forum_name`, `forum_desc`, `forum_desc_bitfield`, `forum_desc_options`, `forum_desc_uid`, `forum_link`, `forum_password`, `forum_style`, `forum_image`, `forum_rules`, `forum_rules_link`, `forum_rules_bitfield`, `forum_rules_options`, `forum_rules_uid`, `forum_topics_per_page`, `forum_type`, `forum_status`, `forum_posts`, `forum_topics`, `forum_topics_real`, `forum_last_post_id`, `forum_last_poster_id`, `forum_last_post_subject`, `forum_last_post_time`, `forum_last_poster_name`, `forum_last_poster_colour`, `forum_flags`, `forum_options`, `display_subforum_list`, `display_on_index`, `enable_indexing`, `enable_icons`, `enable_prune`, `prune_next`, `prune_days`, `prune_viewed`, `prune_freq`) VALUES
(3, 0, 5, 10, '', 'members', 'Diese Kategorie soll nur für registrierte Mitglieder sein.', '', 7, '', '', '', 0, '', '', '', '', 7, '', 0, 0, 0, 0, 0, 0, 0, 0, '', 0, '', '', 32, 0, 1, 0, 1, 0, 0, 0, 7, 7, 1),
(4, 3, 6, 7, '', 'hidden', 'Dieses Forum soll nur für Admins sichtbar sein.', '', 7, '', '', '', 0, '', '', '', '', 7, '', 0, 1, 0, 0, 0, 0, 0, 0, '', 0, '', '', 48, 0, 1, 0, 1, 1, 0, 0, 7, 7, 1),
(5, 3, 8, 9, '', 'members only', '', '', 7, '', '', '', 0, '', '', '', '', 7, '', 0, 1, 0, 0, 0, 0, 0, 0, '', 0, '', '', 48, 0, 1, 0, 1, 1, 0, 0, 7, 7, 1);

Eigentlich dachte ich, da wäre die Rechtevorgabe enthalten.

EDIT: Wie ich bei genauer Prüfung der Datenbank (per phpMyAdmin) sah, werden die Rechte in der Tabelle "phpbb_acl_groups" zugewiesen. Also zusätzlich

Code: Alles auswählen

--
-- Daten für Tabelle `phpbb_acl_groups`
--

INSERT INTO `phpbb_acl_groups` (`group_id`, `forum_id`, `auth_option_id`, `auth_role_id`, `auth_setting`) VALUES
(5, 3, 0, 14, 0),
(5, 4, 0, 14, 0),
(5, 5, 0, 14, 0),
(6, 3, 0, 16, 0),
(6, 4, 0, 16, 0),
(6, 5, 0, 16, 0),
(4, 3, 0, 14, 0),
(4, 4, 0, 16, 0),
(4, 5, 0, 14, 0),
(1, 3, 0, 16, 0),
(1, 4, 0, 16, 0),
(1, 5, 0, 16, 0),
(7, 3, 0, 17, 0),
(7, 4, 0, 16, 0),
(7, 5, 0, 17, 0),
(2, 3, 0, 14, 0),
(2, 4, 0, 16, 0),
(2, 5, 0, 14, 0);

Und auf einmal hat sich dieser Bereich tatsächlich erledigt. Auch die vorher für Admins gar nicht sichtbare Gruppe nur für Admins ist jetzt vorhanden.

Der erste Punkt Kategorien und Foren ist somit durch genaueres selbst probieren geklärt. Ich melde mich wieder.

[Elsensee]

Nein, die Rechtevergabe ist in der ACL_USERS_TABLE und ACL_GROUPS_TABLE.

[regazer]

Ah ja, das hat sich jetzt überschnitten. acl_groups hatte ich noch selbst gefunden. Bei acl_users habe ich bisher nur einen Eintrag (user_id =2, auth_role_id=5, alle anderen Werte darin sind 0) ...

Vermutlich ist das der von mir angelegte Testuser. Kann ich denn hier bereits weitere User eintragen?

So - das nächste Problem: Beiträge
In die Datei schema_data.sql habe ich nun 2 Beiträge kopiert, einen ins Forum das nur Mitglieder lesen können, den anderen nur für Admins. Doch beide werden nach der Installation nicht gezeigt. phpMyAdmin erkennt sie. Was muß ich anpassen, damit sie korrekt übernommen werden?

Code: Alles auswählen

INSERT INTO `phpbb_posts` (`post_id`, `topic_id`, `forum_id`, `poster_id`, `icon_id`, `poster_ip`, `post_time`, `post_approved`, `post_reported`, `enable_bbcode`, `enable_smilies`, `enable_magic_url`, `enable_sig`, `post_username`, `post_subject`, `post_text`, `post_checksum`, `post_attachment`, `bbcode_bitfield`, `bbcode_uid`, `post_postcount`, `post_edit_time`, `post_edit_reason`, `post_edit_user`, `post_edit_count`, `post_edit_locked`) VALUES
(2, 2, 5, 2, 14, '127.0.0.1', 1413139990, 1, 0, 1, 1, 1, 1, '', 'Dieses Forum ist nur für registrierte Mitglieder sichtbar.', 'Zur ganz besonderen Freude ist es möglich, Beiträge vor unberechtigten Personen zu verstecken.\n\nDieses Forum kann nur von Mitgliedern gelesen werden. Wer länger dabei ist, darf hier auch Beiträge schreiben, sonst erstmal nur lesen. <!-- s:glubsch: --><img src="{SMILIES_PATH}/zopfie_glubsch.gif" alt=":glubsch:" title="Zopfie glubscht" /><!-- s:glubsch: -->', 'c9c120ba464ce7e73465a60f2072bbe0', 0, '', '1zacxunn', 1, 0, '', 0, 0, 0),
(3, 3, 4, 2, 13, '127.0.0.1', 1413140100, 1, 0, 1, 1, 1, 1, '', 'JA, das gibt es auch ...', 'Hier können nur ADMINS lesen (und schreiben).   <!-- s:P --><img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Hänseln" /><!-- s:P --> Das ist also mehr oder weniger für private Notizen geeignet. <!-- s:cleaning: --><img src="{SMILIES_PATH}/phil_35.gif" alt=":cleaning:" title="Sauber machen" /><!-- s:cleaning: -->', 'b307c31c8cbfd08ea70c4933b816cccc', 0, '', '2dcz63i8', 1, 0, '', 0, 0, 0);

[Elsensee]

Die user_id 2 hat immer der erste User im Forum, also der Administrator. Es folgen 45 Bots. Du könntest nun also ab user_id 48 eigene anlegen, aber ist das auch sinnvoll?
Und mir fällt auch gerade auf, dass acl_users eher irrelevant ist für dein Vorhaben. Das wäre nur, wenn du einzelnen Usern unabhängig von deren Gruppenzugehörigkeit Zugriff auf ein Forum geben möchtest.

[regazer]

O.K. - Wie ich nach mehreren zwischenzeitlichen Tests feststellte, müssen ausser der Beiträge in phpbb_posts auch noch phpbb_topics und phpbb_topics_posted übernommen werden. Und die Änderungen bei phpbb_forums sind zu berücksichtigen, damit die Übersicht stimmt. Habe ich was vergessen?

EDIT: Ja, ich habe was vergessen, weiß aber nicht wo. Die Zahl der Beiträge des Users (in dem Fall des Admins) muß auch erhöht werden.

[regazer]

Hab's rausgefunden: bei phpbb_users im Feld user_posts

Mein nächstes Problem beim premodding ist schwieriger und da kann ich auch kein konkretes Code-Beispiel geben.

Es geht darum, daß viele Modifikationen ausser Änderungen in diversen php- und html-Dateien auch den zusätzlichen Aufruf eines eigenen Installations-Programms erfordern. Offenbar geht es dabei nicht nur um das Ausführen von MySQL-Befehlen. Kann mir jemand dabei helfen, die Funktionsweise solcher Intallationsdateien zu verstehen? Vielleicht lassen sie sich ja in die "normale" Foreninstallation integrieren ...

Um nicht mißverstanden zu werden, hier nochmal mein Anliegen: Zur Installation möchte ich beim Benutzer keine weiteren Vorkenntnisse voraussetzen müssen. Jede manuellen Aufrufe weiterer Installationsdateien sollen dabei ebenso wegfallen wie manuell vorzunehmende Einstellungen im ACP (wie z.B. bei Static Pages) ...

Bei Static Pages kann ich beispielsweise zwar die MySQL-Anweisungen in schema_data.sql übernehmen, aber sobald ich dort auch die Zuweisung vornehme, landet dessen Menüpunkt im ACP immer ganz vorne, noch vor ALLGEMEIN. Bei anderen Mods, die sich (im Gegensatz zu Static Pages) im MODS-Tab eintragen lassen, ist es genauso. Bei Integration der Zuweisung in schema_data.sql landet der jeweilige Eintrag dann ebenfalls separat ganz vorn und nicht unter MODS.

[Elsensee]

Offenbar geht es dabei nicht nur um das Ausführen von MySQL-Befehlen.

Das ist aber das einzige, was diese Installationsskripte machen. Was sollen sie sonst noch machen? Klar, sie rufen Funktionen auf, die Module anlegen, aber die Module müssen ja auch irgendwo konfiguriert und gespeichert werden. Normalerweise passen sie sich dabei dem derzeitigen Forenstand an, aber bei frisch installierten, sind diese in der Regel ja fast alle gleich.

Eine andere Option wäre es, den Inhalt dieser Dateien in die Installationsroutine einzubauen, sodass man quasi einfach von Seite zu Seite kommt und auf jeder Seite dann eine andere Modifikation installiert wird.

[regazer]

Diese Installationsscripte benutzen immer UMIL - und da steige ich nicht durch.

Beispielsweise würde ich gerne Separate Login and User Name fest integrieren, weil die Bearbeitung der vielen Einzeldateien sehr langwierig und damit Zeit raubend ist. Einfach die neuen Felder mit in schema_data.sql reinnehmen reicht nicht.

Aber nehmen wir doch mal nur das schon erwähnte Static Pages, das ja ohne Installationsroutine auskommt. Wie kann man solche Sachen derart integrieren, daß sie sich nicht vor alle andere setzen?

Eine andere Option wäre es, den Inhalt dieser Dateien in die Installationsroutine einzubauen, sodass man quasi einfach von Seite zu Seite kommt und auf jeder Seite dann eine andere Modifikation installiert wird.

Das wäre sicher sinnvoll, aber wenn ich wüßte, wie das sequentlelle Abarbeiten der Installation abläuft (bzw. wo die entsprechenden Stellen zu finden sind) würde ich wahrscheinlich erstmal einige der aktuell vorhandenen Schritte ändern bzw. einiges (rein optisch) überspringen lassen. Reine Meldungen, das alles funktioniert hat, sind dann störend, wenn man sie auch noch einzeln bestätigen muß. Und wenn es Fehler gibt, sollte man die bisher angelegten Daten nicht mühsam manuell löschen müssen, sondern das sollte automatisch erfolgen. Generell wäre eine RESET-Funktion zum Löschen gerade bei Testinstallationen sinnvoll. Mal sehen, ob ich sowas selbst hinbekomme. Im Grunde müßte wohl dazu ich mein entsprechendes, separates Script nur ins ACP integrieren. Allerdings dann wirklich mit Sicherheitsabfrage und ggf. vorherigem Sichern der Datenbank. Aber das waren jetzt abschweifende Überlegungen.