[RC] [3.1] [3.2] [3.3] Style Changer

In diesem Forum können Extension-Autoren ihre Extensions vorstellen, die sich noch im Entwicklungsstatus befinden. Der Einbau in Foren im produktiven Betrieb wird nicht empfohlen.
Benutzeravatar
Kirk
Supporter
Supporter
Beiträge: 6602
Registriert: 24.05.2010 08:31
Kontaktdaten:

Re: [RC] [3.1] [3.2] [3.3] Style Changer

Beitrag von Kirk »

Es gibt ein Update dieser Erweiterung.
Download siehe erster Beitrag!

Benutzeravatar
Kirk
Supporter
Supporter
Beiträge: 6602
Registriert: 24.05.2010 08:31
Kontaktdaten:

Re: [RC] [3.1] [3.2] [3.3] Style Changer

Beitrag von Kirk »

Da mir in der vorherigen Version ein kleiner Fehler unterlaufen ist, gibt ein Update dieser Erweiterung.
Download siehe erster Beitrag!

Benutzeravatar
LukeWCS
Junior Supporter
Beiträge: 476
Registriert: 15.12.2014 10:19
Kontaktdaten:

Re: [RC] [3.1] [3.2] [3.3] Style Changer

Beitrag von LukeWCS »

Hi Udo

Erstmal danke für das Update. :) Sehr hilfreiches Werkzeug, vor allem in einem TB.
Kirk hat geschrieben:
12.01.2020 12:56
Da mir in der vorherigen Version ein kleiner Fehler unterlaufen ist, gibt ein Update dieser Erweiterung.
Download siehe erster Beitrag!
Genau das wollte ich dir eben mitteilen. ^^ Ich hatte mir gestern Abend die 2.6.0 geholt und gemerkt, dass beim Symbol der Name der Sprachvariable ausgegeben wird, statt dem Tooltip. Und den eigentlichen Fehler von 2.6.0 hattest du auch früher schon drin, also schon bei 2.4.0 z.B. wie ich gesehen habe, 2.5.0 hab ich irgendwie nicht mitbekommen.

Der Punkt ist, du hast jetzt für die Fehlerbehebung die eigentlich korrekte Funktion entfernt und stattdessen wieder die veraltete Funktion add_lang_ext() eingebaut. Zu der heisst es jedoch in der Doku:
The previous method of using add_lang_ext() from the User object has been deprecated in 3.2, and will eventually be removed in the future.
Gerade bei deiner 3.2 Version wäre es eigentlich besser/konsequenter, wenn du die - eigentlich korrekte - Funktion von 2.6.0 wieder einbaust und stattdessen auf add_lang_ext() verzichtest. Der Grund warum das bei 2.6.0 und auch bei den Versionen davor nicht funktionierte, ist folgender Block (hier aus 2.6.0):

Code: Alles auswählen

	static public function getSubscribedEvents()
	{
		return array(
			'core.user_setup'					=> 'load_language_on_setup',
			'core.permissions'					=> 'permissions',
			'core.page_header_after'			=> 'select_style_form',
			'core.ucp_display_module_before'	=> 'switch_style',
			'core.user_setup'					=> 'set_guest_style',
			'core.ucp_prefs_modify_common'		=> 'show_hide_ucp_user_style',
		);
	}
 
Schau dir hier das Event core.user_setup an, das kommt zweimal vor. Das hier ist aber ein assoziatives Array und darum darf jedes Event exakt nur einmal in der Liste vorkommen. Anders ausgedrückt: das ist dasselbe, als hättest du sowas geschrieben:

$a = 1;
$a = 2;


Es gibt jedoch eine Möglichkeit einem Event mehr als einen Hook zuzuweisen. Dazu muss der Block so aussehen, dann klappt das auch mit der Funktion die du in 2.6.1 entfernt hast:

Code: Alles auswählen

	static public function getSubscribedEvents()
	{
		return array(
			'core.user_setup'					=> array(array('load_language_on_setup'), array('set_guest_style')),
			'core.permissions'					=> 'permissions',
			'core.page_header_after'			=> 'select_style_form',
			'core.ucp_display_module_before'	=> 'switch_style',
			'core.ucp_prefs_modify_common'		=> 'show_hide_ucp_user_style',
		);
	}
 
Dann kannst du auf add_lang_ext() verzichten. Der Fehler kam übrigens bei älteren Versionen nur deswegen nicht zum tragen, weil du da noch zusätzlich add_lang_ext() benutzt hast.

Des Weiteren gibt es laut EPV bei 2.6.0 und auch 2.6.1 noch eine "potentielle Sicherheitslücke". Ich habe mir den Code angeschaut: diese "Lücke" kann nicht ausgenutzt werden, weil die dafür verantwortliche Variable explizit als Integer abgerufen wird. Aber sowas sollte natürlich trotzdem nicht vorkommen.

Bei 2.6.1 die Zeile 132:

Code: Alles auswählen

			$sql = 'UPDATE ' . USERS_TABLE . ' SET user_style = ' . intval($style) . ' WHERE user_id = ' . $this->user->data['user_id'];
durch das ersetzen:

Code: Alles auswählen

			$sql = 'UPDATE ' . USERS_TABLE . ' SET user_style = ' . (int) $style . ' WHERE user_id = ' . (int) $this->user->data['user_id'];
Die "Sicherheitslücke" ist die fehlende explizite Typdeklaration bei $this->user->data['user_id']. Und ich habe hier ausserdem intval() durch (int) ersetzt. intval() braucht man eigentlich nur, wenn man von einer Quelle mit anderer Basis konvertieren will, was hier aber gar nicht der Fall ist, darum ist intval() überflüssig.

Wenn du das geändert hast, dann hat EPV auch nix mehr zu meckern, alles andere ist Grün. :wink:

Ich hab übrigens beide Änderungen bei mir mit 2.6.0 am Laufen.

P.S.: die Änderung mit dem Symbol statt dem Text, gefällt mir sehr gut. Der Text "Board Style" war doch ziemlich sperrig, weshalb ich das bei mir auch schlicht in "Style" geändert hatte. Aber das mit dem Symbol ist eine gute Lösung und sieht schick aus.
Möge das Backup mit dir sein. Immer.

Meine Erweiterungen: Monospace font for Posting Editor
Meine Erweiterungs-Forks: LF who was here, ModBreak eXtended

Benutzeravatar
Kirk
Supporter
Supporter
Beiträge: 6602
Registriert: 24.05.2010 08:31
Kontaktdaten:

Re: [RC] [3.1] [3.2] [3.3] Style Changer

Beitrag von Kirk »

Hi Patrick
Zu meiner Schande muss ich gestehen das es mir nicht aufgefallen ist das ich 2x das gleiche Event benutzt habe :oops:
Das hier $this->language->add_lang hatte ich schon seit V 2.3.0 drin, habe jetzt deine Vorschläge umgesetzt, funktioniert bestens.
Vielen Dank für deine Hilfe! :)
Die .zip Datei wurde nur ausgetauscht, es gibt keine neue Versionsnummer.

Benutzeravatar
LukeWCS
Junior Supporter
Beiträge: 476
Registriert: 15.12.2014 10:19
Kontaktdaten:

Re: [RC] [3.1] [3.2] [3.3] Style Changer

Beitrag von LukeWCS »

Kirk hat geschrieben:
12.01.2020 15:14
Zu meiner Schande muss ich gestehen das es mir nicht aufgefallen ist das ich 2x das gleiche Event benutzt habe :oops:
Und ich muss gestehen, dass ich ne ganze Weile gebraucht habe den Fehler zu finden. :lol: Für mich sah bei 2.6.0 alles gut aus und ich konnte mir nicht erklären, warum es nicht ging. Bis ich dann das doppelte Event sah.
Das hier $this->language->add_lang hatte ich schon seit V 2.3.0 drin,
Ja, war auch notwendig, weil dein load_language_on_setup($event) bislang gar nicht ausgeführt wurde, wegen dem doppelten Event.
Möge das Backup mit dir sein. Immer.

Meine Erweiterungen: Monospace font for Posting Editor
Meine Erweiterungs-Forks: LF who was here, ModBreak eXtended

Benutzeravatar
Kirk
Supporter
Supporter
Beiträge: 6602
Registriert: 24.05.2010 08:31
Kontaktdaten:

Re: [RC] [3.1] [3.2] [3.3] Style Changer

Beitrag von Kirk »

Genau deshalb ist es mir die ganze Zeit nicht aufgefallen, hatte ja alles funktioniert.

Benutzeravatar
Kirk
Supporter
Supporter
Beiträge: 6602
Registriert: 24.05.2010 08:31
Kontaktdaten:

Re: [RC] [3.1] [3.2] [3.3] Style Changer

Beitrag von Kirk »

Da es bei einer kleinen 3.2er Version beim Aufruf des ACP Modules zu einer Fehlermeldung kommt, gibt es ein Update.
Download siehe erster Beitrag!

Antworten

Zurück zu „Extensions in Entwicklung“