info.php System-Bug?

[evaki]

Trotz Deaktivierung per /* // wird ein Modul installiert.
Erst nach der Entfernung der VAR wird die Installation verweigert.
Ist wohl buggy, oder?

Scheint meinen Anwendern schon länger bekannt zu sein, weil die sich mit dem Installationsvorgan g wohl mal näher beschäftigt haben. Aber ich hab' wie oft mal wieder nix gewußt.
MfG. Evaki

[dbs]

Glaube wegen älteren OFA versionen.
Die Variable $modulname war dort  nicht per String hinterlegt, sondern = $modul_diectory.
Deshalb wurde $modulname nochmal auskommentiert als String darunter geschrieben und bewußt eingelesen.
War also ein Feature.

Warum wird von euch etwas in der info deaktiviert?

[evaki]

Code: [Select]

War also ein Feature.Na , das kann man auch anders sehen, besonders wenn auf Einhaltung bestimmter Regeln - als Feature hervorgehoben - verweist.
Als Kommentar gekennzeichnete Zeilen sollten auch als solche registriert werden, und eben nicht ignoriert.

Code: [Select]

Warum wird von euch etwas in der info deaktiviert?Weil's untersucht werden wollte.
Ist ja mehr als blöd, wenn man die Installation Abbrechen/Fortsetzen möchte, der ganze Kram vor der eigentlichen Installation erst noch ins Zielverzeichnis (wenn nicht genullt oder umgelenkt) kopiert wird.
So zumindest Kommentare von Anwendern.
Habe das soeben halt auch mal nachgestellt, und... ebenso

Was die sich jetzt als Lösung haben einfallen lassen, oder ob die den Umstand hingenommen haben, weiß ich nicht. Habe' nicht nachgehakt. Jedenfalls sah ein Installationsfenste r ganz hübsch aus.
MfG. Evaki

[dbs]

Na , das kann man auch anders sehen, besonders wenn auf Einhaltung bestimmter Regeln - als Feature hervorgehoben - verweist.
Als Kommentar gekennzeichnete Zeilen sollten auch als solche registriert werden, und eben nicht ignoriert.

Hast du recht und ist ja eigentlich auch überholt durch die neueren OFA Versionen.
Werds mal weiterleiten.

[evaki]

Noch'n Nebnschauplatz.
Gibts "irgendwo" schon 'ne praktische Anwendung unter Verwendung des WbAdaptor zu sehen?
Also mal wat leichtes zum gucken und...
MfG. Evaki

[dbs]

Zu WbAdaptor kann ich leider nichts sagen.

Nun muss ich meinen Blödsinn von vorhin nochmal überholen.
Wir haben nichts eingebaut um deaktivierten Code zu erlauben. Der Installer hatte sich geändert. Statt wie früher erstmal alles auszupacken und dann zu installieren, wird in neueren Versionen direkt in das Zip geschaut. Deshalb ist dort auch kein PHP ausführbar, alles wird eingelesen und geprüft. Aber da ist eher Dietmar der Ansprechpartner.

OFA betraf das insoweit, dass in der info ein str_replace auf das Modulverzeichnis angewendet wurde. Was mit dem neuen Installer nicht mehr funktionierte. Neue OFA Versionen haben da kein str_replace mehr.

[evaki]

Code: [Select]

Zip geschaut. Deshalb ist dort auch kein PHP ausführbarWird deshalb wohl alles dann auch als text eingelesen, vermute ich mal.
Somit wäre das Verhalten nachvollziehbar - kommt ja keine Auführung zustande - wenn's sich sich denn so verhält.

Genaueres darüber wäre willkommen, u.a. auch ob's so bleibt, oder sich's z.B. mit WBAdapter wieder ändert, oder die info.php selbst. Fragen über Fragen 

MfG. Evaki

[Gast]

WbAdapter ist nur ein "Übersetzer", der, einfach gesagt, die Programmierung an anderer Stelle vereinfacht, weil ich alle Daten in der Klasse zur Verfügung habe und nicht jedes Kram einzeln einlesen muß. Hier geht vorrangig um OOP Die Funktion selbst wird sich durch den Einsatz der WbAdapter nicht ändern

[Gast]

Gibts "irgendwo" schon 'ne praktische Anwendung unter Verwendung des WbAdaptor zu sehen?
Also mal wat leichtes zum gucken

das einfachste Beispiel wäre wohl das WbLingual und dort die Lingual.php
Wenn man dort die Basis nicht erkennt/versteht, braucht man ohne weitere Schulung nicht weitermachen.

[Gast]

eigentlich doch wieder das typische Evaki-Posting - viel geschrieben, doch nix gesagt    (Smiley nicht übersehen bitte)

Bitte mal genaue Angaben machen, was wie wo deaktiviert wurde, welche Reaktion in welcher Phase deiner/eurer Meinung nach richtig ist bzw sein sollte(n). Ich vermute, Ziel ist ein spurenfreies System nach einem mißglücktem Install (?)

Nur mal als Beispiel, was die Kontrolle der Werte u.U. auch Bedeuten kann. Die Gründerväter haben im Module Primer mal festgelegt, das Templates im Frontend mit der Definition

Code: [Select]

$template_function     = 'template';gekennzeichnet werden sollten.
Gleich vorweg: Einige der Template-Autoren vertreten hier die Meinung, das diese Angabe nur nötig sei, wenn es sich nicht expliziet um ein Fronend-Template handelt, sondern um ein Backend-Theme, dann wäre diese Angabe zu machen

Code: [Select]

$template_function     = 'theme';
Das erscheint von der Logik her kein Problem zu sein, $template_function wird per default als 'template' deklariert und ggf durch den Wert einer info.php überschrieben. Es würde aber unterm Strich bedeuten, das, wenn ich mich einmal verklickt habe beim Module-Install und beim Template-Install geladet bin, ein Modul als ein Template installiert wird, denn diesem fehlt ja ebenfalls solche Definition und es wird dann automatisch zu "template".
Im Zuge der WB 2.10.x kam dann die Frage, abbrechen oder weiter machen? Gestartet haben wir mit "Abbrechen", so ging es (wenn ich mich recht erinnere) in die ersten öffentlichen Test's, die Folge war, das sich reihenweise Templates bestimmter Autoren nicht mehr installieren ließen.
Der Kompromis war dann, weiter machen, aber eine Info in der error-log schreiben, sinngemäß: template-function wurde nicht gesetzt

Und solche Kompromisse muß man überall finden. Einerseits das System auch schützen, andererseits auch nicht zu viel regulieren....
Dazu kommt, das WB kein Produkt für den rein deutschen Markt ist. Solche Begrenzung würde mit deutscher Brille vieles einfacher machen. PHP 7.3.5 ist wohl die aktuellste und eine 5er Version sollte es nirgendwo mehr geben. Das mag in Germany funktionieren, aber kaum in der gesamten Welt, von daher kann ich viele Möglichkeiten neuester PHP-Versionen nicht in jedem Fall verwenden.
Bei uns kann ich davon ausgehen, das ich ein Zip auch analysieren kann, ohne es vorher auszupacken. Funktioniert das, kann ich eine info.php lesen und kontrollieren, ob der liebe Evaki da etwas auskommentiert hat. Das brech ich ganz hart ab. Hat der liebe Uwe aber nur etwas vergessen, einzutragen, ist er eben am Allerwertesten (analog der Geschichte mit dem Templates).
Ist es das, was wir wollen??
Auch mit dem Risiko, das sich Module, die nicht hier gehostet werden und wir somit Einfluß darauf hätten, garnicht mehr installieren lassen könnten?
Es wäre sicher z.b. auch kein Thema, alle solche Templates ohne diese Angabe zur Template-Funktion zu "reparieren" und hier anzubieten, aber ich kann und will nicht beeinflussen, wo User XY sich sein Kram herunter läd. Das man bei AMASP jede Menge Uralt-Module aus 2008/2009 findet und bei diesem Alter Probleme einkalkulieren sollte, müßte mittlerweile jeder mitbekommen haben. Aber es gibt auch hier zahlreiche User, die sich das Update z.b. einer OFA-Version sparen und lieber in den alten Versionen nach Fehlern suchen.

Noch mal die Frage zum Abbruch: Ist es das, was wir wollen??
Ich glaube kaum...
Aber wie gesagt, aktuell vermute ich nur, das es um das "alte Thema" garnicht erst einen Ordner anlegen und dorthin kopieren geht.
Mich selbst stört der Weg sicher am meisten, weil ich viel altes Kram repariere und auch viel Neues produziere. Und habe ich z.b. einen Fehler im Insert beim SQL-Strict-Mode, muß ich erst den Ordner wieder entfernen, bevor ich den nächsten Versuch wage. Über das System komm ich (noch) nicht dran, weil das Modul ja noch nicht registriert ist.
Aber bei all dieser Bastelei weiß ich am Ende: Uwe, das war dein eigener Mist - hättest du es richtig gemacht, wär der Install auch geglückt. Weiß ich das bei geschätzten 1100 anderen Modulen auch?
Ich bin kein Programmierer, aber ich denke, mir würden auch Möglichkeiten einfallen, die einen Roll-Back erlauben, aber dann nur für mich, in meiner Konfiguration. Funktioniert die auch noch in Bolivien, Singapur, Vietnam? Hab ich keine Ahnung.
Und das ist eben die Welt, in der die Dev's denken müssen und du kannst dir sicher sein, das genau dieses Thema (unzip && install) in jeder WB-Version auf der Agenda steht

[evaki]

Schöne Antwort 

Aber wie gesagt, aktuell vermute ich nur, das es um das "alte Thema" garnicht erst einen Ordner anlegen und dorthin kopieren geht.

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.

typische Evaki-Posting

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    (Ich bin kein Programmierer, ...)

[Gast]

Aber es geht oder ging nicht um eine evtl. fehlerhafte info.php

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?

Jetzt kam halt eine Rückfrag wg. der veränderten Installationsroutin e.

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]

Erst jetzt kannst du aktiv werden, ...

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 

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