[3.3] Probleme beim Hinzufügen von Modulen zum Schnellzugriff im ACP

[Cowboy of Bottrop]

Danke für deine Arbeit Mike!

[Mike-on-Tour]

Meine entsprechende Frage auf phpbb.com hat keine Antworten ergeben, aber ich habe mal weiter in den phpBB-Skripten gestöbert und bin zu dem Ergebnis gekommen, dass dieses Verhalten nicht Zufall, sondern Absicht ist, denn es werden die Namensfelder (sowohl des Moduls selbst als auch der "Mode"-Einträge) aller im ACP eingerichteten Module erfasst und miteinander verglichen. Dies geschieht über alle Tabs (also von "Allgemein" bis "Erweiterungen". Wird nun in "Erweiterungen" ein identisches Modul gefunden, das bereits unter "Allgemein -> Schnellzugriff" existiert, wird für letzteres ein Flag is_duplicate gesetzt und damit erhält es im Array der anzuzeigenden Module statt seiner module_id das Attribut "false", und letzteres verursacht dann die Fehlermeldung.

Mein erster Ansatz, den ich mit der kleinen Test-Erweiterung erfolgreich anwenden konnte, scheint aber - aus welchen Gründen auch immer - mit umfangreicheren Modulen nicht zu funktionieren, warum das so ist, habe ich noch nicht raus. Vorgestern dachte ich, ich hätte einen Weg gefunden, der ist aber gestern gescheitert, deshalb wird Userreminder nach wie vor dieses Feature (ein Modul sowohl im Schnellzugriff als auch bei den Erweiterungen aufrufen zu können) nicht bieten. Ich bleibe aber am Ball.

[HaioPaio]

Das ist sicher sinnvoll wenn Erweiterungen Modulnamen verwenden würden, die von phpBB auch schon verwendet werden.
Es ist aber offensichtlich Blödsinn dass das auftritt wenn ich eine Erweiterung über den Schnellzugriff aufrufe.
Hier hat eine sinnvolle Schutzfunktion evtl. einen unerwünschten Nebeneffekt.
Bei einigen wenigen Erweiterungen tritt das Problem aber nicht auf. Es muss also noch was anderes dahinter stecken.
Aber wenn sich sonst keiner dafür interessiert, kannst auch du die Welt nicht retten.

[chris1278]

Also wenn jemand über migration seiner Extenion etwas in den Schnellzugrif anhängen möchte dann kann man dies so tun:

Hier mal der Beispielcode dafür:


in der Migration:

Code: Alles auswählen

public function update_data()
	{
		return [
			['module.add', [
				'acp',
				'ACP_CAT_DOT_MODS',
				'ACP_TEST_TITLE'
			]],
			['module.add', [
				'acp',
				'ACP_TEST_TITLE', [
					'module_basename'	=> '\autor\extname\acp\test_module',
					'module_langname'	=> 'ACP_TEST_SETTINGS',
					'module_mode'		=> 'overview',
					'module_auth'		=> 'ext_autor/extname && acl_a_board',
				]
			]],
			['module.add', [
				'acp',
				'ACP_QUICK_ACCESS', [
					'module_basename'	=> '\autor\extname\acp\test_module',
					'module_langname'	=> 'ACP_QUICK_TEST_SETTINGS',
					'module_mode'		=> 'acp_test_quick',
					'module_auth'		=> 'ext_autor/extname && acl_a_board',
				]
			]],
		];
	}

Man fügt einfach so dies in den Schnellzugrif ein und kann dann beides nutzen.

Man mus aber auch entsprechend den Eintrag in der test_info.php im ordner acp der extension anlegen diese sähe dann so aus:

Code: Alles auswählen

class test_info
{
	function module()
	{
		return [
			'filename'		=> 'autor\extname\test_module',
			'title'			=> 'ACP_TEST_TITLE',
			'version'		=> '1.0.0',
			'modes'			=> [
				'settings'    => [
					'title'		=> 'ACP_TEST_SETTINGS',
					'auth'		=> 'ext_autor/extname&& acl_a_board',
					'cat'		=> ['ACP_TEST_TITLE']
				]
			],
		];
		return [
			'filename'		=> 'autor\extname\test_module',
			'title'			=> 'ACP_QUICK_ACCESS',
			'version'		=> '1.0.0',
			'modes'			=> [
				'settings'    => [
					'title'		=> 'ACP_TEST_SETTINGS',
					'auth'		=> 'ext_autor/extname&& acl_a_board',
					'cat'		=> ['ACP_TEST_TITLE']
				]
			],
		];
	}
}

Damit wird bei beiden die selbe Datei benutzt. Das sollte das Problem lösen. Bitte aufpassen ich habe diesen Code im short-array geschrieben.

[LukeWCS]

Interessante Problematik. Da hier auch LFWWH genannt wurde und ich ausserdem z.Z. eh eine Menge Details hinterfrage, bin ich der Sache auch mal nachgegangen. Das ist nicht trivial und ich habe einige Stunden gebraucht, um mal die Zusammenhänge zu verstehen. Werde später mehr dazu schreiben, wenn ich alles habe. Eines muss ich aber fragen:

Fehler tritt nicht auf bei:
LF who was here 2
vse/dbtool

LFWWH ist klar, ich weiss inzwischen warum. Aber dbtool kann ich nicht nachvollziehen. In dem Moment wo ich das in den Schnellzugriff hinzufüge, kann ich die Einstellungen an der original Stelle nicht mehr aufrufen und es kommt zum bekannten Fehler. Getestet mit dbtool 1.2.0. Jetzt wäre die Frage, warum das bei dir anders ist.

Also wenn jemand über migration seiner Extenion etwas in den Schnellzugrif anhängen möchte dann kann man dies so tun:

Was deinen ersten Code angeht: Das ist aber eher was für Ext Coder, weniger für Endbenutzer. Insbesondere wenn man die Mechanismen dahinter nicht kennt, kann man über falsche Modul Kommandos sich auch mal ganz elegant aus dem ACP aussperren und darf dann erstmal in der DB herumfuhrwerken.

Was deinen zweiten Code angeht, wir hatten erst kürzlich ausgiebig über return gesprochen und ich dachte du hättest das verstanden. Dein zweites return wird niemals ausgeführt. Davon abgesehen kann in einer *_info.php nur ein Modul definiert werden, nicht mehrere. Es können aber mehrere Modi definiert werden, aber das ist was anderes. Du versuchst jedoch zwei Module zu definieren.

[HaioPaio]

Getestet mit dbtool 1.2.0. Jetzt wäre die Frage, warum das bei dir anders ist.

Leider weiß ich nicht mehr wie das damals genau war. Heute bekomme ich folgende Fehlermeldung:

Code: Alles auswählen

Allgemeiner Fehler
Auf das Modul kann nicht zugegriffen werden

BACKTRACE

FILE: (not given by php)
LINE: (not given by php)
CALL: msg_handler()

FILE: [ROOT]/includes/functions_module.php
LINE: 565
CALL: trigger_error()

FILE: [ROOT]/adm/index.php
LINE: 81
CALL: p_master->load_active()

[LukeWCS]

Leider weiß ich nicht mehr wie das damals genau war. Heute bekomme ich folgende Fehlermeldung:

Alles klar, dann haken wir das als "nicht mehr nachvollziehbares Mysterium" ab. Alleine der Cache kann ja schon manchmal für seltsame Phänomene sorgen, die dann später nicht mehr nachvollzogen werden können.

Jupp, die jetzige Meldung entspricht dem erwarteten Verhalten in dem Fall.

[chris1278]

Getestet mit dbtool 1.2.0. Jetzt wäre die Frage, warum das bei dir anders ist.

Leider weiß ich nicht mehr wie das damals genau war. Heute bekomme ich folgende Fehlermeldung:

Code: Alles auswählen

Allgemeiner Fehler
Auf das Modul kann nicht zugegriffen werden

BACKTRACE

FILE: (not given by php)
LINE: (not given by php)
CALL: msg_handler()

FILE: [ROOT]/includes/functions_module.php
LINE: 565
CALL: trigger_error()

FILE: [ROOT]/adm/index.php
LINE: 81
CALL: p_master->load_active()

Hallo mal ne frage. ist das modul auf welches du zugreifen willst in den schnelleinstellungen und in dem reiter erweiterungen aktiv. also angezeigt.

[LukeWCS]

Leider konnte ich nicht alles in Erfahrung bringen, weil die Doku nicht ausreichend ist und bestimmte Tests auch nichts schlüssiges ergaben. Aber hier die bisherigen Erkenntnisse. Das folgende ist vor allem auch an Mike adressiert, also nicht wundern über das Technik Gedöns. ^^

Bei einigen wenigen Erweiterungen tritt das Problem aber nicht auf. Es muss also noch was anderes dahinter stecken.

So wie es momentan aussieht, tritt das Problem nur da auf, wo die Modul-Definition einwandfrei und nach "Lehrbuch" gemacht wurde. Das funktioniert nur dort problemlos, wo ein "Fehler" in der Modul-Definition gemacht wurde. Als ich das Thema von Anfang an gelesen hatte, habe ich parallel Versuche gemacht. Dann kam durch Mikes Recherche und Versuche ein wichtiger Hinweis:

Der Unterschied ist die Benennung der "Modes" für die ACP-Module. Stimmen die Namen in der Migrationsdatei (module_mode) und in der entsprechenden _info.php Datei (Definition modes) überein, funktioniert nach Hinzufügen des Moduls in den Schnellzugriff nur noch dieser, der Link im Erweiterungen Reiter produziert den Fehler. Benutzt der Entwickler unterschiedliche Benennungen (was die Entwicklerdokumentation so nicht andeutet), funktioniert es.

Ich habe mir dazu den Stand von User Reminder angeschaut, wie er zu dem Zeitpunkt war, als Mike schrieb. Dann habe ich mit LFWWH2 verglichen. LFWWH2 ist eine komplett eigenständige Ext die von LFWWH1 abgeleitet wurde. Diese wiederum war eine direkte Weiterentwicklung von NVWWH (3.1 Ext von Anvar). Das heisst, auch wenn die Codebasis und viele Dateien inzwischen radikal anders sind, gibt es dennoch Strukturen die noch von Anvar erstellt wurden.

Man könnte jetzt verschiedene Exts vergleichen, ich konzentriere mich aber auf LFWWH das ich zwangsläufig sehr gut kenne und User Reminder von Mike, das er wiederum sehr gut kennt. Somit haben wir beide ideale Voraussetzungen. Der primäre Unterschied bei den Modulen beider Exts ist, dass LFWWH den "manuellen" Modus bezüglich Modul-Integration nutzt, während UR den "automatischen" nutzt, wie die meisten Exts. Das es diese beiden Modi gibt weiss ich auch erst seit gestern, als ich dieses Thema las und anfing nach Infos zu suchen. Nachzulesen in der Doku unter "Migrations » Tools » Module Tool".

Jetzt zum interessanten Teil: im manuellen Modus sind die Modul-Definitionen in einer *_info.php schlicht irrelevant, wie ich durch Versuche herausfand. Ich habe bei einer Test Installation sogar diese Datei komplett gelöscht. Installation war trotzdem fehlerfrei und auch das ACP Modul war vorhanden und funktionierte problemlos. Ebenso interessant ist, das man ein Modul in der Modul-Verwaltung überhaupt nur dann woanders einhängen kann, wenn der Ext Coder auch eine passende *_info.php erstellt hat. Eine Ext bräuchte diese Datei aber nicht zwingend, deren ACP Modul würde auch problemlos ohne diese Datei funktionieren, wenn der Ext Coder den manuellen Modus gewählt hat.

Ganz anders sieht das aus wenn man den automatischen Modus für die Modul-Integration nutzt, hier sind die Daten in einer *_info.php absolut relevant. Anvar hat den manuellen Modus gewählt und die abweichenden Angaben bei *_info.php und in der Migration sind hier quasi bedeutungslos. Der Versuch LFWWH zusätzlich in den Schnellzugriff zu legen hat also nur deswegen funktioniert, weil phpBB zu dieser Aktion die *_info.php genutzt hat und weil der Modus-Name, wie Mike schon festgestellt hat, anders lautet als per Migration vorgegeben. phpBB hat also beides als zwei verschiedene Module betrachtet und darum ging das.

@HaioPaio
Aktuell sieht es für mich so aus, als wenn es nie vorgesehen war, das ACP Modul einer Ext noch zusätzlich irgendwo anders einzuhängen. Das zeigen zumindest meine Versuche und die Tatsache, das phpBB tatsächlich auf Modul-Duplikate prüft, wie Mike ja auch schon festgestellt hat. Warum allerdings phpBB keine kontrollierte Fehlermeldung bringt, ist mir ein Rätsel. Eventuell hängt es auch mit einem der Frameworks zusammen, vielleicht Symfony.

Wundern tut mich also jetzt eher nicht, dass man Module nicht doppelt einhängen kann sondern nur der Umstand, dass phpBB keine ordentliche Fehlermeldung oder Warnung bringt.

[HaioPaio]

Luke
Ich bin dir sehr dankbar dass du dich hier so tief eingefuchst hast. Ich kann natürlich nicht den technischen Details folgen, aber die Zusammenfassung ist ja klar verständlich.
Nach wie vor halte ich den Aufruf von Extension Modulen über einen Schnellzugriff für sinnvoll und wünschenswert.
Es gibt Erweiterungen die mal bei der Installation einrichtet werden und die dann nie wieder angefasst werden müssen.
Dann gibt es welche die ich täglich benutze um Informationen abzufragen oder Aktionen auszulösen.
Für diese Gruppe von Erweiterungen ist ein Zugang über einen Schnellzugriff wirklich sinnvoll.

Wäre es denkbar eine Erweiterung zu bauen die einen zweiten, einfach konfigurierbaren Schnellzugriff für Extension Module im ACP einfügt und diese Einschränkung des Standard phpBB umgeht, so dass es bei allen Erweiterungen klappt?
Damit möchte ich nicht dir Arbeit zuschieben sondern hätte nur gerne deine Einschätzung zu Machbarkeit und Komplexität eines solchen Vorhabens. Vielleicht findet sich ja dann jemand der das anpacken möchte.