Posts by MDMAN

    Korrekt. Es gibt ein PIP, womit man nicht mehr benötigte Dateien von der Install-Routine sauber löschen kann.


    Was man da aber eintragen muss und welche Tags in der entsprechenden XML stehen müssen, da bin ich erstmal überfragt...


    Aber löschbar sind nun Dateien ganz sauber ohne viel Aufwand mit einem einfachen Update... ;)

    Ich denke, man müsste doch vorher schon irgendwie filtern können, was im Template angezeigt werden soll und was nicht. Und erst wenn man alles hat was ausgegeben werden soll, und auch nur das, würde ich zum Template senden und ausgeben.


    Wenn man erst im Template nach einer besonderen Variablen oder einen Wert sucht, wo man dann eine Liste unterbrechen möchte oder so, dann ist es ja schon viel zu spät.


    Man müsste vorher schon die Suche nach dem entsprechenden BREAK machen, bevor es zum Template geht.


    Ich denke das ist mit der Ausführung von Tim Düsterhus gemeint.

    Wäre natürlich schön, wenn so etwas auch nicht nur in der DB gemacht werden kann, sondern auch im FrontEnd oder BackEnd im ACP.


    Man muss natürlich auch dann eine besondere Überwachung und Überprüfung einbinden, damit man nicht plötzlich eine Version 1.0 auf die Version 1.4 ändert, obwohl vorher noch eine Version 1.2 vorhanden ist, die Abhängigkeiten mit der vorherigen Version 1.0 hatte.


    Aber schöner wäre es doch sicherlich, wenn man auch Versionsnummern direkt mit bearbeiten könnte.

    Ich habe plötzlich seit dem Update auf WSC 5.3.0 diesen Fehler im Fehlerprotokoll:



    Ich habe aber nichts an den Einstellungen geändert vom SSL-Zertifikat.


    Auch die Überprüfung sagt ganz klar, dass die "Alternative" Adresse http://www.mdman.de definitiv geschützt ist.


    Siehe auch Anhang.



    Wo könnte das Problem denn liegen?

    Hallo Tim Düsterhus .


    Kannst du mir bitte kurz erklären, wie du das mit dem SELECT ... FOR UPDATE genau meinst?


    Vielleicht wäre eine Funktion seitens des WSC sehr schön, die immer so eine Abfrage vorher automatisch durchführt, und denn erst selbst entscheidet, ob es einen neuen Datensatz anlegt oder doch einen vorhandenen entsprechend der gelieferten Daten einfach Updatet. Das wäre mal eine tolle Idee, finde ich.


    Eigentlich dann es aber in meinem Fall kein "TOCTOU" sind, weil diese Abfrage maximal alle 60 Sekunden stattfindet. Und ich denke, in 60 Sekunden hat jeder Server diese beiden kleinen Querys abgearbeitet... Gleichzeitig wird das nicht erfolgen... Hoffe ich zumindest...

    Weil es dann einfach zu viele Daten in der DB geben würde. Wäre auch sehr blöd, einfach jedes Mal wenn die Abfrage gestartet wird und das Query läuft ein neuer Eintrag in der DB geschrieben würde, obwohl hier nur ein kleines Update eines Parameters hätte gereicht, weil alle anderen Parameter dann gleich sind oder wären.

    Kann man nicht für das Update fromversion 1.0.0 alle Schritte erst einbauen, die von 1.0.0 wichtig sind um auf 2.0.0 zu kommen und dann alle Schritte für das Update von 2.0.0 auf 3.0.0 zu bauen?


    Also wenn es hier um wichtige Updates der DB geht, dann halt 2 Anweisungen schreiben, die dann die Updates in der einen Anweisung nacheinander ausführen.


    So zum Beispiel:


    Code
    <instructions type="update" fromversion="2.0.0">
            <!-- update auf v3 -->
        </instructions>
        
        <instructions type="update" fromversion="1.0.0">
            <!-- update auf v2 -->
            <!-- update auf v3 -->
        </instructions>

    Die Update-Routine wird doch jede Zeile nach und nach von oben nach unten einzeln abarbeiten.

    Kurze Frage:


    gibt es eigentlich von Seite des WSC die Möglichkeit, ein "Duplicate Entry for Key" vor dem INSERT INTO in die Datenbank prüfen zu lassen?


    Ich habe es jetzt so versucht zu lösen, dass ich erst nach dem Key selber in der Datenbank suche. Finde ich diesen Key in der Tabelle, wird nur ein Update der übrigen Parameter gemacht. Finde ich keinen gleichen Key, wird ein INSERT INTO gestartet.


    Allerdings habe ich in sehr seltenen Fällen immer wieder eine Fehlermeldung, die nur bei ganz bestimmten Parametern auftaucht, dass ich keine Eintragung machen kann aufgrund eines


    Duplicate entry '156.146.33.72-::ffff:9c92:2148-1272' for key 'IPv4'


    Klar ist der Key schon vorhanden, aber warum wird dieser bei der vorherigen Suche nicht gefunden? Oder gibt es bei der IPv6 irgendwie ein "schlechtes" Zeichen, sodass die Abfrage vorher nicht richtig funktioniert?

    Alternative wäre es nen Google Docs Dokument zu verwenden und nur einzubinden.

    Derzeit wird in der Tat genau so ein Google Dokument genutzt. Nur es sollte halt irgendwie mit den Rechten vom Forum "genutzt" werden können.


    ilou :

    Es gibt anscheinend noch ein anderes Push. Das findest du hier: Push++ . Auch hier lohnt sich sicherlich mal ein Blick

    Ach das Push++ sagt mir gerade nichts. Aber ich schaue es mir definitiv mal an. Danke für den Hinweis.

    Ui... danke ilou für die Ausführlichen Informationen.


    Ich muss mich da dann erstmal schlau lesen mit den AJAX-Alternativen. Ajax wäre mir auch direkt in den Kopf gekommen, allerdings muss ich echt den Datentransfer sowas von Minimieren...


    Sonst ist der DB-Server nach kurzer Zeit sicher überlastet... Denn es können im Worst-Case-Szenario gleichzeitig bis zu 40 Leute daran arbeiten. Und dann alle X Sekunden in Update... Oha...


    Das wird echt heftig...


    Die anderen Alternativen sind bestimmt gut, ich weiß aber nicht wie ich sowas in den Server installieren kann per PIP... ist eine socket.io Installation per Packet möglich?

    Wie stellt man es am besten an, eine Seite, wo mehrere Personen gleichzeitig Änderungen vornehmen können, diese Seite auch dann sofort für alle refreshed wird?


    Also folgendes:


    Es ist eine große Tabelle vorhanden, wo man einzelne Felder manuell füllen kann und andere Felder per Drop-Down-Menü ausfüllen soll.


    Gleichzeitig sollen auf dieser Seite allerdings mehrere Leute arbeiten.


    Ist sowas überhaupt Umsetzbar und wenn ja, mit welchen Mitteln würdet Ihr das ganze dann umsetzen?

    Gibt es da möglichkeiten sich zu schützen? trotz installationen von 3 Anbietern?

    Wäre es vielleicht denkbar, einfach die Schreibrechte von jedem außer Root auf diese 3 Dateien zu entziehen? Ich denke, dass die weiteren Updates von WoltLab nicht unbedingt immer die LoginForm und dergleichen anpassen werden, oder?


    Ein kleiner Hinweis, sollte es dann doch geändert werden, wäre vielleicht ganz toll... Alexander Ebert


    Aber wäre doch eine Möglichkeit, genau diesen Weg zu sperren. Es wird aber bestimmt immer eine andere Möglichkeit geben, über andere Dateien, die dann kompromittiert werden könnten und auch irgendwelche Daten dadurch geklaut werden könnten, sollte man weiterhin nicht geprüfte Paketserver oder Pakete von Dritte installieren bzw. in der Liste haben...


    Mal in die Runde gefragt: Das wäre doch eine Alternative um genau das zu verhindern, oder?

    Hallo Gianluca1234 .


    Wäre schön, wenn du die Supportanfrage in meinem Forum stellen würdest. Aber ich denke, das Problem wird an einem anderen Plugin liegen, welches die gleiche Tabelle nutzt wie das Benutzer IP-Log-Plugin. Hast du zufällig andere Plugins installiert die auch irgendwas mit IPs von Usern macht oder überprüft?


    Für mich sieht es so aus, als ob da entweder eine ältere Version des Benutzer IP-Logs mal installiert war und beim Deinstallieren nicht korrekt alle Tabellen entfernt wurden, oder es gab mal ein Versuch der Installation und dabei ist dann ein Fehler aufgetreten und die Installation wurde unterbrochen und nicht mit dem Rollback wieder bereinigt.


    Ich würde folgendes machen:


    1. Überprüfen, ob andere Plugins die Tabelle angelegt haben
    2. wenn nicht dann überprüfen ob eine ältere Version von Benutzer IP-Log installiert war oder noch installiert ist

    Wenn eines der Fälle zutrifft, dann die Plugins deinstallieren, damit man dann die neue Version des Benutzer IP-Log installieren kann.


    Andernfalls, sollten es nur noch eine Tabelle von einem alten Installations-Versuch sein, mit phpMyAdmin die Tabelle manuell entfernen und ggf. auch in der Tabelle Install_SQL die entsprechenden Einträge auch löschen, damit es dort zu keiner Kollision kommt.



    Weiteren Support dann bitte nur auf meiner Seite...


    https://www.mdman.de



    Danke.


    Gruß

    Markus

    Moin Ihr!

    Blöd wird es erst bei Upgrades bzw. mehreren Versionssträngen.

    Na, blöd ist das nicht. Man muss halt nur schauen, dass der Sprung von 3.0 auf 3.1 (zum Beispiel) in nur einer Version passiert. Und dann halt erstmal die 3.0 auf die aktuellste Version geupdatet werden muss, bevor dann der Sprung auf die 3.1 passieren kann. Ist aber so kein Problem...

    Exakt und das ist gerade für den Anwender eher störend um das mal ganz freundlich auszudrücken.

    Wieso soll das störend sein, wenn das WSC die Updates der Reihe nach automatisch durchführt?

    Wenn man mit Paketservern arbeitet, fällt dem normalen Benutzer das aber doch gar nicht erst auf, oder doch?
    Den das System bei einem Update sollte doch genau das automatisch machen.

    Das ist korrekt, das System wird ohne einen Handgriff vom Benutzer schön nach einander jede Version aktualisieren, bis die neuste Version am Ende vorhanden ist.

    Machen wir mal absichtlich ein extremes und ggf. leicht unrealistisches Beispiel: Schauen wir mal das WSF 5.1 an. Stelle dir mal vor du hast die 5.1.0 installiert und möchtest auf die aktuelle 5.1 updaten. Das sind dann halt mal 11 Updates alleine für das eine Paket. Dazu kommen noch Abhängigkeiten. Jetzt stell dir vor es wäre möglich das alles mit einem Update pro Paket machen zu können und das ohne, dass er auch alle PIPs ausführt, die er nicht ausführen muss.

    Ja das macht doch nichts. Wie oben schon geschrieben, wird das System jede Version von 5.1.0 über 5.1.1, dann 5.1.2 und dann 5.1.3 usw. nach einander Installieren.


    Das ist in meinen Augen auch sinnvoll, denn so hat man nicht die Schwierigkeit irgendwelche Scripte sich dann anzuschauen und neu schreiben zu müssen, die dann Sprünge erlauben.


    Als Beispiel:

    Update von 5.1.0 auf 5.1.1:

    Ein Script soll beim Update von Version 5.1.0 auf 5.1.1 den Code in von Buchstabe A nach Buchstabe B ändern.


    Update von 5.1.1 auf 5.1.2:

    Ein Script soll beim Update von Version 5.1.1 auf 5.1.2 den Code in von Buchstabe B nach Buchstabe C ändern.


    Update von 5.1.2 auf 5.1.3:

    Ein Script soll beim Update von Version 5.1.2 auf 5.1.3 den Code in von Buchstabe C nach Buchstabe D ändern.



    Damit haben wir jetzt schon dann bei einem Sprung von 5.1.0 auf 5.1.3 nur ein Script mit der Anweisung: Buchstabe A nach Buchstabe D.

    ABER: von 5.1.1 auf 5.1.3 wäre die Anweisung: Buchstabe B nach Buchstabe D.

    UND: von 5.1.2 auf 5.1.3 wäre die Anweisung: Buchstabe C nach Buchstabe D.


    Damit wären statt einem Script schon 3 Scripte nötig, die dann entsprechend der momentanen Version aufgerufen werden müssen.


    Man könnte zwar sagen, sofern es möglich ist, Ändere egal welchen Buchstaben nach D. Dann hätte man wieder nur ein Script. Aber manchmal geht es einfach nicht.


    Und das ist nur ein kleiner Änderungs-Weg. Wenn man Scripte oder andere Pips einsetze, die an der Datenbank-Struktur arbeiten, ist ein Sprung über mehrere Versionen mit mehreren Änderungen immer sehr schwer. Man muss echt auf jede Kleinigkeit achten, damit am Ende der Update-Routine die alte Version genauso aussieht, wie die neue Version frisch installiert. Da ist die Kunst dabei.


    Und darum würde ich immer, gerade bei schweren Änderungen an DB oder anderen Datei-Strukturen, jeden Versionssprung einzeln zu machen und nicht von 5.1.0 auf z.B. 5.1.3 zu springen.


    Dann geschehen auch keine Fehler...


    Gruß

    Markus

    Ja... stimmt auch irgendwie... man kann ja einfach in jeder Version nur die vorherige als Update zulassen. Dann ist die Änderung zwischen mehreren Versionen auch möglich, nur mit dem Unterschied, dass das WSC dann von zum Beispiel Version 3.0.2 erst auf 3.0.3 updatet, dann erst von 3.0.3 auf die 3.0.4 und dann erst von 3.0.4 auf die 3.0.5. Statt direkt von der 3.0.2 zur Version 3.0.5 in einem Zug...