Sprachvariable mit WCF-Update zurückgesetzt?

  • Hallo,


    ich bin offenbar nicht versiert genug, um den folgenden Fall zu verstehen. Es geht um einen Textbaustein (Sprachvariable), den ich angepasst habe und für den also ein eigener Text benutzt wurde. Die Checkbox bei "eigene Version verwenden" war bis zum 21.06. gesetzt. Dann installierte das aktuelle Update des WCF sowie des WBB, Blogs und einiger Plugins. Nach den Updates war "eigene Version verwenden" bei meinen Texten nicht mehr gesetzt und es wurde die Default-Variante verwendet.


    Ich kann es glücklicherweise so präzise belegen: Bis zum 21.06. wurde mein eigener Textbaustein verwendet, dann erfolgt das Update, danach wurde die Default-Version des Textbausteins verwendet. Heute habe ich den Fehler bemerkt, die Checkbox "eigene Version verwenden" beim Textbaustein wieder aktiviert und das Problem damit behoben.


    Das wirft für mich folgende Fragen auf:


    1.) Woran kann ich erkennen, welche Textbausteine (Sprachvariablen) durch Updates zurückgesetzt wurden?


    2.) Warum werden angepasste Textbausteine überhaupt durch Updates zurückgesetzt?


    Bin dankbar für Eure Kommentare!

  • 1.) Woran kann ich erkennen, welche Textbausteine (Sprachvariablen) durch Updates zurückgesetzt wurden?


    Aktuell gar nicht, soweit ich weiß.



    2.) Warum werden angepasste Textbausteine überhaupt durch Updates zurückgesetzt?


    Weil es sonst u.U. zu Fehlern kommen kann. Vorallem dann, wenn Template-Variablen genutzt werden und diese durch das Update beispielsweise umbenannt wurden. Eigene Versionen von Sprachvariablen werden also immer dann deaktiviert, wenn sich die jeweiligen Sprachvariablen geändert haben um eventuelle Fehler (die dann auch im ACP auftreten könnten) zu verhindern.

  • Ich fände es nett (oder sogar erforderlich), dass von Woltlab vor einem Update alle Dateien/Templates/Sprachvariablen aufgelistet werden, die geändert wurden. Dürfte für Woltlab ja kein großer Aufwand sein, aber uns hilft es, auf solche "unfassbaren" ;) Vorgänge zu reagieren.

  • Das ist ziemlich unfassbar. Aber danke für Deine Antwort @SoftCreatR!

    Hat ja nichts mit unfassbar zu tun. Es ist einfach aus Sicherheitsgründen damit die Seite weiterhin vernünftig läuft.


    gehe auf Suchen, dann klick auf "Eigene Sprachvariablen"
    und dann werden dir alle aufgelistet.
    Da machst du ganz einfach dann die Checkbox bei allen wieder rein und dann ist das auch schnell wieder "behoben"

  • 1.) Woran kann ich erkennen, welche Textbausteine (Sprachvariablen) durch Updates zurückgesetzt wurden?

    Na ja, geht nicht ... hmm, man kann sich doch unter Darstellung -> Sprachen -> Texte verwalten alle Sprachvariablen anzeigen lassen, die man selber verändert hat.



    Oder wird wirklich der eigene Text durch das Update entfernt? Denn ansonsten wird die Sprachvariable hier auch dann gelistet, wenn der Haken zur Verwendung nicht gesetzt wurde? Ich dachte immer, nur diese würde bei einem Update eventuell entfernt.


    Eine Liste aller Dateien, die sich verändert haben, fände ich aber auch sehr hilfreich, damit man gleich weiß, wo man suchen muss.


    Ah, da war schon jemand schneller, sorry.

    Liebe Grüße
    Susi

  • Da machst du ganz einfach dann die Checkbox bei allen wieder rein und dann ist das auch schnell wieder "behoben"

    Naja schnell... es sind halt über 300 X/


    Abgesehen davon sind ja einige Checkboxen vielleicht absichtlch nicht gesetzt, z.B. weil man hier und da mal etwas ausprobiert, das nicht gleich in die Production soll. Eine Liste der vom Update geänderten Einstellungen wäre wirklich wünschenswert. Vielleicht nicht nur in diesem Bereich.

  • Oh je, 300 ist krass. Da tust du mir echt leid.


    Aber mal ganz allgemein frage ich mich, wann denn diese Haken heraus genommen werden. Ich habe das letzte Update z.B. gemacht (nur WCF und Forum) und meine eigenen Sprachvariablen waren alle noch da. Das Problem wurde hier ja schon häufiger geschildert, aber ich hatte es noch nie selber. Läuft da bei mir etwas schief?

    Liebe Grüße
    Susi

  • wann denn diese Haken heraus genommen werden. Ich habe das letzte Update z.B. gemacht (nur WCF und Forum) und meine eigenen Sprachvariablen waren alle noch da

    Wenn sich die Sprachvariable im Vergleich zur bestehenden Version beim Update ändert, wird der Haken entfernt; anderenfalls passiert nichts.

  • So, und nun erklärt mir mal bitte, wie sich das hier dann miteinander vereinbart ... das kapier ich grad nicht..



    Da machst du ganz einfach dann die Checkbox bei allen wieder rein und dann ist das auch schnell wieder "behoben"


    Weil es sonst u.U. zu Fehlern kommen kann. Vorallem dann, wenn Template-Variablen genutzt werden und diese durch das Update beispielsweise umbenannt wurden.


    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..


    Fragen über Fragen, aber ich denke, durchaus berechtigt, dies widerspricht grad jeglicher logischen Denkweise, sorry...

  • Wenn sich die Sprachvariable im Vergleich zur bestehenden Version beim Update ändert, wird der Haken entfernt; anderenfalls passiert nichts.

    Ah, o.k., das ist doch dann aber eine gute Nachricht, denn man muss nur die Sprachvariablen prüfen, wo es eigenen Text gibt, der Haken aber deaktiviert ist. Das kann man zwar über das ACP nicht abfragen, aber sicherlich über die Datenbank.


    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.

    Na ja, mit "einfach aktivieren" ist da wohl nichts. Man muss sie vergleichen und an die neue Version anpassen, würde ich sagen. Neue Variablennamen würde man beim betrachten ja sehen.


    Aber wenn der Haken nur dort fehlt, wo es Änderungen gab, dann bräuchte man nur die Abfrage, wo das der Fall ist und hat sicherlich überschaubaren Aufwand. Man muss sich dann eben disziplinieren und darf nicht überall Texte speichern, die man nicht benutzt.

    Liebe Grüße
    Susi

    • Official Post

    Hallo,


    es wurden nicht notwendigerweise Änderungen an Templatescripting vorgenommen, sondern möglicherweise schlicht ein Tippfehler korrigiert. Das kann das WCF aber natürlich nicht unterscheiden.

  • Ich hätte ehrlich gesagt lieber kaputte Variablen, denn die Fehler sollten ja dann im Log auftauchen. Wenn die Variablen einfach nur deaktiviert werden, dann kann es sein, dass ich den Fehler nie bemerke, die User aber ständig in den Tiefen der Anwendung darüber stolpern. Oder wie ist es mit SEO... plötzlich fallen die Textbausteine auf Entwicklerkauderwelsch zurück und machen mir Teile der Keyword-Optimierung kaputt.


    Das ist doch ganz klar ein Bug, selbst wenn es dafür irgendwie nachvollziehbare Gründe geben mag.


    Ein einfaches Log über automatisch geänderte Einstellungen wäre die Lösung.

  • Man könnte ja einen Vorschlag einreichen, der sowas wie <critical>1</critical> in der XML-Datei erlaubt und die Variablen dann nur noch bei gesetztem Wert "zurückgesetzt" werden.

  • Ein einfaches Log über automatisch geänderte Einstellungen wäre die Lösung.

    Das würde ich auch sehr begrüßen. Dann weiß man was zu tun ist, ohne danach suchen zu müssen. Das das Vorgehen ist, wie es ist, finde ich schon nachvollziehbar und in Ordnung. Sicherheit geht nunmal vor und das man bei einem Update seine eigenen Änderungen abpassen muss, ist wohl auch immer so.

    Liebe Grüße
    Susi

  • Sicherheit geht nunmal vor und das man bei einem Update seine eigenen Änderungen abpassen muss, ist wohl auch immer so.

    Das ist auf jeden Fall richtig. Mit einem Änderungs-Log wäre das auch möglich, ohne leider nur mit hohem Aufwand.

    Man könnte ja einen Vorschlag einreichen, der sowas wie <critical>1</critical> in der XML-Datei erlaubt und die Variablen dann nur noch bei gesetztem Wert "zurückgesetzt" werden.

    Als Ergänzung wäre das bestimmt schön. Nur löst es das Problem nicht, weil man trotzdem nach den geänderten Sprachvariablen suchen müsste und auch nicht wüsste, ob die eigene Variante ursprünglich aktiv war oder nicht.


    Eine andere Lösung wäre, in der Tabelle wcf_language_item einen Änderungs-Timestamp zu speichern. Nach dem Update könnte man einfach nachsehen, welche Sprachvariablen zuletzt geändert wurden. So ein Backlog der letzten Anpassungen wäre ohnehin sehr praktisch.

Participate now!

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