[3.3] [3.2] Viewlegend [Final]

[Talk19zehn]

Änderungen V_2.3.5
Diese Version hat zusätzlich weitere Styles erhalten, die auch als Muster zur Verfügung stehen könn(t)en, auf prosilver basieren (parent-style):
360Elite, AllanStyle-SUBSILVER, Anna, DVGFX, DVGFX2, EchoTech, greengolden, phpbb_retro, proDVGFX.

Archiv Dateigröße rund 137 KB.

Die Sprachvariable SHOW_VL_MINI_EXPLAIN (viewlegend_acp.php) und die readme.txt ergänzt.


Viele Grüße

[Talk19zehn]

Hallo, schwerwiegende persönliche Gründe ließen für mich nur einen Vorgang zu. Alle Rechte an meiner Extension Viewlegend auf
Prosk8er im Oktober/November 2024 zu übertragen.
Credits mit Dank an Kirk als Mitwirkender, Ideengeber, Tester und seit 2019 als Co-Autor bis Januar 2024. Credits und Dank gehen auch an vfrblue als Assistent (Mitwirkender) 2019 - 2020.

Danke für euer Verständnis.

Herzliche Grüße

[Kirk]

Nur als Hinweis, die mirgations Dateien v_2_3_1.php bis v_2_3_5.php hätte man nicht gebraucht. Bis auf den Inhalt von public static function depends_on() und class sind diese identisch. So lange im ACP Modul keine neue Einstellungen dazu kommen, wegfallen oder config Variablen sich ändern, ist keine neue mirgations Datei notwendig.

[Talk19zehn]

Hm, der Versions-Check liegt doch auf der Hauptdomain. Jedenfalls bisher war es so. Oder was hatte ich in den Jahren nicht verstanden? Dieser funktionierte doch immer nur in der Form bei einer Abfrage.

[Kirk]

Es geht nicht um den Versions-Check, dies wird über die composer geregelt. Es geht um die oben genannten mirgations Dateien im Vz. viewlegend/migrations, in früheren Versionen wurde die EXT Versionsnummer im ACP Modul über eine mirgations Datei (z.B. so var $vl_version = '2.2.8';) geregelt, dies wurde ja geändert so das es über die composer ausgelesen wird. deswegen wurde in der v_2_3_0.php dies per config.remove gelöscht. Dieses config.remove wiederholt sich in den folgenden mirgations Dateien, dies meinte ich mit "hätte man nicht gebraucht".

[Talk19zehn]

Okay, mangels fehlender Informationen der *spontanen Änderungen deinerseits, da du gerade Zeit hattest: V-230

Code: Alles auswählen

namespace ongray\viewlegend\migrations;

class v_2_3_0 extends \phpbb\db\migration\migration
{
	public function effectively_installed()
	{
		return isset($this->config['vl_version']);
	}

	public static function depends_on()
	{
		return ['\ongray\viewlegend\migrations\v_0_2_5'];
	}

	public function update_data()
	{
		return [
			['config.remove', ['vl_version']],
		];
	}
}

, ging mein weiteres Prozedere augenscheinlich an der PHP-phpBB3-System vorbei, da du ja nachgebessert hattest. Ich diese Vorgänge jedoch nicht kontrollierte.

Tja, und nun?

*Ich hatte mich seinerzeit darauf verlassen, Migrationen beizubehalten. Meinst du, sie können nun Schaden anrichten?

LG

[Kirk]

Davon mal abgesehen das dies sicherlich keine spontane Änderungen (diese wurden dir immer mitgeteilt) meinerseits war, wurde die Anzeige der EXT Version im ACP Modul ab diesem Zeitpunkt nicht mehr über eine migrations Datei sondern über composer ausgelesen.
Nachträglich kann und sollte man dran nichts ändern, deswegen schrieb ich ja:

So lange im ACP Modul keine neue Einstellungen dazu kommen, wegfallen oder config Variablen sich ändern, ist keine neue mirgations Datei notwendig.

Meinst du, sie können nun Schaden anrichten?

Du hast es ja vor der Veröffentlichung der 2.3.5 Version bestimmt getestet und festgestellt das alles funktioniert. So lange du es so lässt wird es auch kein Schaden anrichten.

Edit:
Du hättest je einfach fragen können ob dies notwendig ist oder nicht, ist ja keine Schande. Geholfen wird hier jedem.

[Talk19zehn]

Hello again,

VL-Update auf die Version 2.3.7

Wichtig: Mit dem Update der VL-Erweiterung (Version 2.3.7 – Januar 2025) ist die composer.json geändert:

Anforderungen für PHP: "7.0.0,<8.5.0". Die ext.php wurde ebenfalls auf die PHP Anforderung angepasst "7.0.0,<8.5.0".

CSS: background-size wurde entfernt. Dadurch werden die Foldersymbole in ihrer Originalgröße geladen. Allerdings gibt es bei einigen Styles Ausnahmen, die eine spezielle CSS-Anweisung erfordern.

Die CSS-Anweisung (prosilver)
{% INCLUDECSS '@ongray_viewlegend/viewlegend.css' %}
wurde direkt in die viewlegend.html verschoben.
Dies hat den Vorteil, dass das CSS erst beim Aufruf der Extension durch die viewlegend.html geladen, sich die Ladezeit geringfügig verkürzt und das CSS nicht dauerhaft geladen wird (vgl. Seitenquelltext im Browser).

Weggefallen ist daher die overall_header_head_append.html, da sie nicht mehr benötigt wird.

Eine Erweiterung aktualisieren:

• Deaktiviere die Erweiterung

• Lösche die Dateien der Erweiterung aus dem Dateisystem / (FTP)

• Lade die neuen Dateien hoch

• Aktiviere die Erweiterung

Ergänzend teile ich euch mit, dass bereits mit der VL-Version 2.3.6 im Verzeichnis migrations die Migrationsdateien v_2.3.1 - v_2.3.5 entfernt worden sind.

LG

[Mike-on-Tour]

Ergänzend teile ich euch mit, dass bereits mit der VL-Version 2.3.6 im Verzeichnis migrations die Migrationsdateien v_2.3.1 - v_2.3.5 entfernt worden sind.

Was bedeutet, dass die bei der Installation bzw. einem Update mittels dieser Dateien vorgenommenen Änderungen beim De-Installieren der Erweiterung nicht mehr rückgängig gemacht werden können, weil der Erweiterungsmanager die Migrationsdateien dabei quasi "rückwärts" abarbeitet.
Das führt dann mindestens zu verbleibenden Rückständen der Erweiterung bzw. kann dann auch zu Fehlern führen, weil eine Migrationsdatei mit kleinerer Versionsnummer plötzlich etwas nicht finden kann.

Bei der Validierung von Erweiterungen wird wohl genau deshalb streng darauf geachtet, dass Migrationsdateien nicht verändert werden.

[vfrblue]

....
Wichtig:
Die alte Version 2.3.5 muss bei der Aktualisierung der viewlegend deinstalliert werden, da die alten Dateien gelöscht werden müssen. Vgl. "Eine Erweiterung komplett aus dem Board entfernen" und folgend "Eine Erweiterung installieren"!
.....

Man beachte diese Anweisung im 1. Beitrag.