✔ Das eigene Forum
- Themenstarter Alice
- Beginndatum
sheel
I love Asm
Hab im Internet einmal eine lange Diskussion gesehen, welches der großen Forentemplatesysteme am einfachsten ist. Die Stimmen für XF und für VB waren ca. gleich viel 
...
Plugin Basics
Ein Plugin kann im wesentlichen in 4 Bereichen arbeiten:
a) Überall im Xenforo-Kern verstreut sind Hooks, für die man eigene PHP-Methoden registrieren kann, die dort dann zusätzlich ausgeführt werden.
b) Templates (und Phrasen und...) "ändern" (oder auch weitere anlegen, die bei anderen Templates verschachtelt eingebunden werden können). Die Änderung ist allerdings nicht vergleichbar mit den händischen Änderungen: Es sind im Wesentlichen Ersetzungsregeln, "ersetze Text X" oder "ersetze Regexp Y" mit was Anderem (oder auch "gib PHP-Callback Z das Template und lass es noch daran herumändern, bevor es ausgegeben wird"). Die Ersetzungsregeln werden bei Deinstallation auch wieder mitgelöscht und hinterlassen das Template im Originalzustand. Aufgelistet werden die Änderungsregeln, sortiert nach Plugin, im Navipunkt "Templateanpassungen (TMS)" im AdminCP.
c) Bei Installation und Deinstallation übers AdminCP PHP-Callbacks aufrufen. Nützlich zB. für weitere SQL-Tabellen, wenn man welche braucht, usw.usw.
d) Das Plugin kann sich selbst Einstellungsseiten im AdminCP machen.
Du kannst dir jetzt sicher schon denken, wo das hingeht? Genau, das Plugin wird laut Punkt b) ein Template so abändern, dass eben ein PHP-Callback die IP ausgibt. So wie oben, nur in ein schön installierbares Plugin verpackt.
Und was ist jetzt ein Plugin?
Grundsätzlich nur eine XML-Datei, die außer ein paar Grundinfos noch die Templateregeln für b) und die Namen der Callbacks für a) und c) enthält. Wenn man irgendwo ein PHP-Callback zu einer selbstgeschriebenen PHP-Funktion verwendet, wäre die PHP-Datei auch noch gut zu haben. Und je nach Anwendungfall zusätzliche Bilder etc.etc., was man halt braucht. Bei Plugindownloads bekommt man üblicherweise ein ZIP mit allem, und Anweisungen wo die PHP-Dateien/Bilder/... am Server hinzuspeichern sind, bevor man die XML-Datei über das AdminCP installiert. So muss es auch sein, für das AdminCP ist nur die XML-Datei interessant, Zip-entpacken etc. macht es nicht.
Zur Erstellung der XML-Datei selber, die kann man sich ganz nett im Adminpanel zusammenklicken
Vorbereitung von XF für die Pluginentwicklung
In einer Datei library/config.php kann man eine Debug-Variable auf true setzen (bzw. das Kommentarzeichen bei Zeile, wo sie auch true gesetzt wird, entfernen). Außer besseren Fehlersuchmöglichkeiten im XF-Kerncode bekommt man im AdminCP einen ganzen weiteren Tab, "Entwicklung", und auch in den anderen Tabs mehr Möglichkeiten.
Nachteil ist, dass das Forum im Debugmode langsamer ist.
Man braucht den Debugmode nur, bis das Plugin fertig ist, dann kanns wieder ausgeschaltet werden.
Wenn man sich sein "Haupt"-Forum nicht verlangsamen will, die Lizenz erlaubt eine (eine, nicht mehr) private Kopie für Entwicklungszwecke, unter der Bedingung dass diese in keiner Weise öffentlich erreichbar ist.
htaccess+htpasswd helfen.
Beim Klonen muss man ein paar Sachen aufpassen. Zuerst natürlich die Dateien und DB klonen, bei den Dateien aufpassen dass man den Besitzer und die Zugriffsrechte mitkopiert. Dann
a) in library/config.php von der Kopie die DB-Zugangsdaten (und das Debug-Flag) ändern
b) die .htaccess-Datei anpassen, und zwar die Redirects. Und natürlich auch die htpasswd-Sache.
c) Auch ein paar der Unterordner haben .htaccess'es.
d) Im geklonten Adminpanel, bevor man irgendwas Anderes macht, bei den Forengrundeinstellungen die Urls auf den Klon ändern.
e) Falls man Elasticsearch verwendet, bei den Sucheinstellungen ausmachen. Das kommt nicht wirklich mit zwei Foren zurecht (anderer Indexname reicht nicht). Und nach dem Ausmachen im Hauptforum prüfen, obs da wohl nicht auch aus ist. Da Elasticsearch ja ein unabhängiges Programm ist, nicht in der DB oder so, und es glaubt schlauer als wir zu sein...
Die eigentliche Pluginerstellung
Ich werde hier nur auf die Basics und die Templateanpassungssache eingehen. Hooks im Kerncode und eigene Plugineinstellungen im AdminCP gehen hier zu weit, und außerdem müsste ich das selber erst besser kennenlernen Für einen Schnupperkurs in die Richtung, siehe https://xenforo.com/community/threads/creating-an-addon.5416/
Also, als Erstes kann man sich im Tab Entwicklung ein neues Addon erstellen.
Name usw. einfach aussuchen.
Falls man das Plugin auch veröffentlicht sollte zumindest die untere der zwei Versionsnummern vor jeder Veröffentlichung erhöht werden. Sonst könnte es evt. nicht installierbar sein, weil XF denkt dass sich nichts geändert hat.
Die Klassen- und Funktionsnamen der Callbacks für Installation und Deinstallation sind optional; wenn eingetragen sollten die Funktionen aber schon existieren. Die Installationsfunktion außerdem so schreiben, dass sie auch mehrmals aufgerufen werden kann (wenn es zB. eine neue SQL-Tabelle anlegt, zuerst prüfen obs die Tabelle nicht schon gibt)
Punkt zwei, Tab Erscheinungsbild, Menüpunkt Templateanpassungen: Da hat man jetzt einen "Neu"-Button.
Templatename zuerst eingeben (falls man ihn nicht weiß, zuerst bei TemplateVerwalten oder TemplatesDurchsuchen eben suchen, und es gibt auch eien Autovervollständigung).
Man sieht dann das Template, und kann sich irgendein Stück zum Ersetzen suchen. Das unten eingeben, und wie es durch was ersetzt werden soll. Für uns hier eben die Einbindung eines PHP-Callbacks dazumachen, und die PHP-Funktion auch bereitstellen.
Punkt drei, Tab Allgemeines, Plugins verwalten: Hier das eigene Plugin exportieren. Man bekommt die XML-Datei fertig heraus. Noch die eigenen PHP-Dateien dazu, und in eine Zip-Datei verpacken...mehr ists nicht (solange nicht Kernhooks und Configseiten ins Spiel kommen).
Bevor man den Debugmode wieder ausmacht, das eigene Plugin sicherheitshalber deinstallieren (wie andere Plugins über die Pluginverwaltung), und nach Debug-Ausmachung wie ein normales heruntergeladenes Plugin wieder installieren.
...
Hab nicht jeden Schritt selber mitgemacht, aber wenns hilft kann ich (später) so ein IP-Plugin auch als Zip anbieten, zum Vergleichen.
...
Plugin Basics
Ein Plugin kann im wesentlichen in 4 Bereichen arbeiten:
a) Überall im Xenforo-Kern verstreut sind Hooks, für die man eigene PHP-Methoden registrieren kann, die dort dann zusätzlich ausgeführt werden.
b) Templates (und Phrasen und...) "ändern" (oder auch weitere anlegen, die bei anderen Templates verschachtelt eingebunden werden können). Die Änderung ist allerdings nicht vergleichbar mit den händischen Änderungen: Es sind im Wesentlichen Ersetzungsregeln, "ersetze Text X" oder "ersetze Regexp Y" mit was Anderem (oder auch "gib PHP-Callback Z das Template und lass es noch daran herumändern, bevor es ausgegeben wird"). Die Ersetzungsregeln werden bei Deinstallation auch wieder mitgelöscht und hinterlassen das Template im Originalzustand. Aufgelistet werden die Änderungsregeln, sortiert nach Plugin, im Navipunkt "Templateanpassungen (TMS)" im AdminCP.
c) Bei Installation und Deinstallation übers AdminCP PHP-Callbacks aufrufen. Nützlich zB. für weitere SQL-Tabellen, wenn man welche braucht, usw.usw.
d) Das Plugin kann sich selbst Einstellungsseiten im AdminCP machen.
Du kannst dir jetzt sicher schon denken, wo das hingeht? Genau, das Plugin wird laut Punkt b) ein Template so abändern, dass eben ein PHP-Callback die IP ausgibt. So wie oben, nur in ein schön installierbares Plugin verpackt.
Und was ist jetzt ein Plugin?
Grundsätzlich nur eine XML-Datei, die außer ein paar Grundinfos noch die Templateregeln für b) und die Namen der Callbacks für a) und c) enthält. Wenn man irgendwo ein PHP-Callback zu einer selbstgeschriebenen PHP-Funktion verwendet, wäre die PHP-Datei auch noch gut zu haben. Und je nach Anwendungfall zusätzliche Bilder etc.etc., was man halt braucht. Bei Plugindownloads bekommt man üblicherweise ein ZIP mit allem, und Anweisungen wo die PHP-Dateien/Bilder/... am Server hinzuspeichern sind, bevor man die XML-Datei über das AdminCP installiert. So muss es auch sein, für das AdminCP ist nur die XML-Datei interessant, Zip-entpacken etc. macht es nicht.
Zur Erstellung der XML-Datei selber, die kann man sich ganz nett im Adminpanel zusammenklicken
Vorbereitung von XF für die Pluginentwicklung
In einer Datei library/config.php kann man eine Debug-Variable auf true setzen (bzw. das Kommentarzeichen bei Zeile, wo sie auch true gesetzt wird, entfernen). Außer besseren Fehlersuchmöglichkeiten im XF-Kerncode bekommt man im AdminCP einen ganzen weiteren Tab, "Entwicklung", und auch in den anderen Tabs mehr Möglichkeiten.
Nachteil ist, dass das Forum im Debugmode langsamer ist.
Man braucht den Debugmode nur, bis das Plugin fertig ist, dann kanns wieder ausgeschaltet werden.
Wenn man sich sein "Haupt"-Forum nicht verlangsamen will, die Lizenz erlaubt eine (eine, nicht mehr) private Kopie für Entwicklungszwecke, unter der Bedingung dass diese in keiner Weise öffentlich erreichbar ist.
htaccess+htpasswd helfen.
Beim Klonen muss man ein paar Sachen aufpassen. Zuerst natürlich die Dateien und DB klonen, bei den Dateien aufpassen dass man den Besitzer und die Zugriffsrechte mitkopiert. Dann
a) in library/config.php von der Kopie die DB-Zugangsdaten (und das Debug-Flag) ändern
b) die .htaccess-Datei anpassen, und zwar die Redirects. Und natürlich auch die htpasswd-Sache.
c) Auch ein paar der Unterordner haben .htaccess'es.
d) Im geklonten Adminpanel, bevor man irgendwas Anderes macht, bei den Forengrundeinstellungen die Urls auf den Klon ändern.
e) Falls man Elasticsearch verwendet, bei den Sucheinstellungen ausmachen. Das kommt nicht wirklich mit zwei Foren zurecht (anderer Indexname reicht nicht). Und nach dem Ausmachen im Hauptforum prüfen, obs da wohl nicht auch aus ist
. Da Elasticsearch ja ein unabhängiges Programm ist, nicht in der DB oder so, und es glaubt schlauer als wir zu sein...Die eigentliche Pluginerstellung
Ich werde hier nur auf die Basics und die Templateanpassungssache eingehen. Hooks im Kerncode und eigene Plugineinstellungen im AdminCP gehen hier zu weit, und außerdem müsste ich das selber erst besser kennenlernen
Für einen Schnupperkurs in die Richtung, siehe https://xenforo.com/community/threads/creating-an-addon.5416/Also, als Erstes kann man sich im Tab Entwicklung ein neues Addon erstellen.
Name usw. einfach aussuchen.
Falls man das Plugin auch veröffentlicht sollte zumindest die untere der zwei Versionsnummern vor jeder Veröffentlichung erhöht werden. Sonst könnte es evt. nicht installierbar sein, weil XF denkt dass sich nichts geändert hat.
Die Klassen- und Funktionsnamen der Callbacks für Installation und Deinstallation sind optional; wenn eingetragen sollten die Funktionen aber schon existieren. Die Installationsfunktion außerdem so schreiben, dass sie auch mehrmals aufgerufen werden kann (wenn es zB. eine neue SQL-Tabelle anlegt, zuerst prüfen obs die Tabelle nicht schon gibt)
Punkt zwei, Tab Erscheinungsbild, Menüpunkt Templateanpassungen: Da hat man jetzt einen "Neu"-Button.
Templatename zuerst eingeben (falls man ihn nicht weiß, zuerst bei TemplateVerwalten oder TemplatesDurchsuchen eben suchen, und es gibt auch eien Autovervollständigung).
Man sieht dann das Template, und kann sich irgendein Stück zum Ersetzen suchen. Das unten eingeben, und wie es durch was ersetzt werden soll. Für uns hier eben die Einbindung eines PHP-Callbacks dazumachen, und die PHP-Funktion auch bereitstellen.
Punkt drei, Tab Allgemeines, Plugins verwalten: Hier das eigene Plugin exportieren. Man bekommt die XML-Datei fertig heraus. Noch die eigenen PHP-Dateien dazu, und in eine Zip-Datei verpacken...mehr ists nicht (solange nicht Kernhooks und Configseiten ins Spiel kommen).
Bevor man den Debugmode wieder ausmacht, das eigene Plugin sicherheitshalber deinstallieren (wie andere Plugins über die Pluginverwaltung), und nach Debug-Ausmachung wie ein normales heruntergeladenes Plugin wieder installieren.
...
Hab nicht jeden Schritt selber mitgemacht, aber wenns hilft kann ich (später) so ein IP-Plugin auch als Zip anbieten, zum Vergleichen.
Zuletzt bearbeitet:
