Sprachvariable mit WCF-Update zurückgesetzt?

Quote from tobiwan

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

Aktuell gar nicht, soweit ich weiß.

Quote from tobiwan

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.

Quote from tobiwan

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"

Quote from tobiwan

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.

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?

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

Quote from Throwholics

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

Quote from SoftCreatR

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

Quote from MysteryCode

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.

Quote from Bibini

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.

Quote from Bibini

dann würden doch auch wieder Fehler entstehen, wenn ichs einfach SO wieder aktiviere, ohne diese umgenannten Variablen zu berücksichtigen..

Dann kannst du es aber eingrenzen weil man die bspw. einzeln aktivieren/deaktivieren kann.
Wenn man aber 300 auf einmal hat muss man estmal die Nadel im Heuhaufen suchen.

du findest aber echt für alles ne ausrede um es schön zu reden

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.

Quote from Bibini

du findest aber echt für alles ne ausrede um es schön zu reden

Naja ausrede Du hast doch gefragt und da wir hier im HILFE Forum sind

Quote from MysteryCode

Man könnte ja einen Vorschlag einreichen,

Man kann natürlich im WCF Vorschlagsforum sich dazu melden

Quote from tobiwan

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.