Sprachvariable mit WCF-Update zurückgesetzt?

  • wenn ich doch eh gleich wieder, so wie es ist, aktivieren kann, ohne selbst Änderungen vorzunehmen....
    warum dann aus "Sicherheitsgründen" deaktivieren ...

    oder anders rum, wenns aus Sicherheitsgründen, eben weil zb Template-Variablen umgenannt wurden..deaktiviert wurde..
    dann würden doch auch wieder Fehler entstehen, wenn ichs einfach SO wieder aktiviere, ohne diese umgenannten Variablen zu berücksichtigen..


    Wenn du dir selbst die Seite zerschießt, ist das ja dein eigenes Problem. WoltLab möchte für derartige Ausfälle aber nicht verantwortlich sein.

  • Wenn du dir selbst die Seite zerschießt, ist das ja dein eigenes Problem. WoltLab möchte für derartige Ausfälle aber nicht verantwortlich sein.


    Hahhaaa... *gröhl* ach ja, sehr nett xD

    man deaktiviert es also ... informiert aber nicht, warum es wirklich deaktiviert wurde und dass man sich ggf. was mit dem erneuten aktivieren der (nun veralteten) geänderten Sprachvariablen zerschiessen könnte.... aber man ist ja dann nicht schuld...

    auch eine Lösung - für mich aber ein wenig mies ..sorry... ;)

  • Wenn du dir selbst die Seite zerschießt, ist das ja dein eigenes Problem. WoltLab möchte für derartige Ausfälle aber nicht verantwortlich sein.

    Nach der Logik könnte man mit jedem Update den Default-Zustand wieder herstellen und hätte theoretisch nichts kaputtgemacht, weil danach ja alles so ist, wie Woltlab es verkauft hat. ;)

    In meinem Fall hat das Update etwas wichtiges kaputt gemacht und das Problem fiel erst nach einer Woche auf. Das ist auch insofern spannend, weil bei der Update-Beschreibung IMHO sinngemäß stand, es gäbe Textkorrekturen, die wegen ihrer Geringfügigkeit nicht aufgelistet würden. :thumbup:

  • Es setzt ausnahmslos alle Variablen mit einem Custom-Wert zurück auf CustomValue, welche den Custom-Value Wert nicht NULL haben.

    Leider auch alles, was man absichtlich deaktiviert hatte. Und auch alles, was tatsächlich lieber durch den Admin geprüft werden sollte.

    Die beste Methode ist wohl, einen SQL-Dump der Tabelle vor dem Update ziehen und danach einen Diff machen. Wundervoll :saint:

    PS: Hey da kommt mir die Idee eines Update-Diff-Plugins das die Auswirkungen eines Updates lückenlos protokolliert und vielleicht sogar zurückrollen kann. Na die Herren (und Damen), wer baut so etwas? Das wäre den meisten Admins bestimmt mehr als den üblichen Heiermann wert!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!