General Community > Development 2.10.x

info.php System-Bug?

<< < (3/3)

evaki:
Schöne Antwort  (Y)

--- Quote ---Aber wie gesagt, aktuell vermute ich nur, das es um das "alte Thema" garnicht erst einen Ordner anlegen und dorthin kopieren geht.
--- End quote ---
Ja, und nur darum geht oder ging es, weiß ja sonst nix über deren Versuche. Wenn ich nicht selbst richtig nachhake, kommt da nix - außer etwas klappt zum Verrecken nicht. . Aber es geht oder ging nicht um eine evtl. fehlerhafte info.php.
Die Sache steht nur mit der etwas anderen Installation: "Schöner Installieren",  mit einer Info und 'nem Form für weiter/abbrechen in Verbindung, die ich wohl mal vor längerer Zeit angeregt hatte. Jetzt kam halt eine Rückfrag wg. der veränderten Installationsroutin e. Bei welchem Vorgang, Modul oder sonstwas das aufgefallen ist, und warum erst jetzt - keine Ahnung.

Da ich aber schauen wollte, was sich da angeblich geändert hat, habe ich es selbst mal näher angeschaut, und eben...
Das ist alles.


--- Quote --- typische Evaki-Posting
--- End quote ---
Das wird in vielen Fällen auch weiter so daherkommen, wenn ich selbst auch nur Gehacktes vorgelegt bekomme: Laien und Zugucker, erzählen 'nem anderen Laien, also mir, daß was aufgefallen, verkehrt oder Hiiiiilfe..... erforderlich ist. Ist fast so'n Durcheinander wie im Kindergarten. Da kannste aber sofort reagieren und sehen ob Du richtig liegst.
MfG. Evaki
ps. Understatement kannst Du ja  (Y)  (Ich bin kein Programmierer, ...)

Gast:

--- Quote from: evaki on May 29, 2019, 01:00:23 PM --- Aber es geht oder ging nicht um eine evtl. fehlerhafte info.php

--- End quote ---

setzen wir mal voraus, diese info.php passt, sie entspricht den Vorgaben.
Dann bleibt fehlerhafter Code in den PHP-Dateien, z.b. ein falsch gesetzter Insert beim Anlegen der Module-Tabellen. Da ein User selbst keine Möglichkeit hat, einen Install abzubrechen, bleibt ja nur solch Fehler - richtig?
Um solche Datei wie eben die install.php überhaupt zu starten, muß das Modul doch schon am richtigem Ort entpackt sein - auch richtig, oder?
Ich werde nicht Zeile für Zeile eines Scripts vorab prüfen können und im Falle von MYSQL-STRICT kann solch Insert auf einen NON-STRICT-Server von der Syntax her ja auch noch richtig sein

Was ich als Rollback kenne, funktioniert allesamt mit Dateilisten, eine Textdatei mit Pfaden drin, pro Zeile ein Pfad. Damit arbeiten eine Menge Systeme. Starte ich das Rollback, wird Zeile für Zeile abgearbeitet und somit Pfad für Pfad gelöscht
Nutze ich solch Rollback für ein Upgrade, macht das System erst ein Backup im fest definiertem Ordner, löscht die neu installierten Dateien aus der Liste und kopiert das Backup wieder an deren Stelle.

Mag sein, das es heute bessere Methoden gibt, aber diese erscheint mir die sicherste zu sein, egal..
Es würde aber in der Praxis bedeuten, das einem Module-Zip solche Datei beigelegt ist oder das System sich solch Liste selbst erstellen muß. Falls letzteres, wohin? Und was passiert, wenn mein Redakteur die gleiche Idee hat und wir zeitgleich oder zeitähnlich agieren?


--- Quote ---Jetzt kam halt eine Rückfrag wg. der veränderten Installationsroutin e.
--- End quote ---
Unterschied zu vorher hatte dbs ja genannt.

P.S.: Früher wurde erst in den tmp-Ordner entpackt, dann verschoben, dann die info.php gelesen. Heute wird erst reingeschaut

Dabei wird die info.php gelesen mit all den Parametern, diese werden dann abgeglichen, z.b. eben eine Module Versionsnummer, Ordnername usw. Insgesamt 8 Parameter, 4 davon werden geprüft (Ordnername, Version, Funktion, Modulname), die anderen 4 enthalten Informationen wie Beschreibung, Autor, Lizens und Plattform, die nur in den Module-Infos dargstellt werden. Ist dort alles gegeben, die Versionsnummer nicht bereits vorhanden, der Ordner nicht schon da, wird das Modul in diesen Ordner entpackt, das Modul im System registriert (DB-Tabelle "addons") und die install.php gestartet. Diese legt die Module-Tabellen an und ggf auch Verzeichnisse, wenn benötigt. Manche Module benötigen auch vordefinierte Daten wie z.b. WysiwygAdmin mit den Basiseinstellungen. In meinen Modulen auch die Twig-Templates, die aus der Datenbank kommen.

Wie oben schon gesagt, gibt es bis hier keine Möglichkeit, den Vorgang manuell abzubrechen außer eben mit Browserfenster schließen (wenn man denn schnell genug ist). Einmal angeschupst, wird es der Server alleine richten, das ZIP ist so oder so am vorgesehenem Platz.
Erst jetzt kannst du aktiv werden, sei es durch Hinzufügen des Modul in der Sectionverwaltung oder durch manuelle Aktivitäten wie erneuter Install, manuelles Upgrade, manuelle Deinstallation. Bei solch Deinstallation werden die DB-Tabellen entfernt und der Module-Ordner gelöscht. Anschließend werden die Addons neu eingelesen und registriert.

evaki:

--- Quote ---Erst jetzt kannst du aktiv werden, ...
--- End quote ---
Genauso ist es! - Hab's aus Neugierde selbst mal vollzogen.
Anscheinend hat "man" in der install.php 'nen Stop eingelegt - a bisserl verschönert - um dann die Wahl zu haben: Installieren/Fortsetzen oder Abbruch/Dateienaufräum.

Denen ging's nur ums Design - Logo des Vereins oder Initiative rein - und gut ists. Mehr sollte es wohl nie werden, obwohl ich selbst damals angeregt hatte, damit auch eine Dateienüberprüfung zu realisieren, wofür die Dateien schon auf dem Server sein sollten  :-D

Na, das Thema scheint abgeschlössen, nachdem man verstanden hat, was aktuell ist.
Es läuft ja nach wie vor.
Vermutlich wollte man die "alten" Verfahrensweise (per php einlesen) für irgendwas nutzen.
Deshalb stieß man wohl auf das andere Verhalten.

MfG. Evaki

Navigation

[0] Message Index

[*] Previous page