Das Datenbankmanagement wurde verlagert. Es ist jetzt in Schritt 5, "Export" Auswahl "Export der Website ins Internet". Wenn Du unten rechts auf "Parameter" klickst, wird ein Fenster angezeigt, in dem Du diese Einträge vornimmst. Mit den neuen Versionen kann aber nur noch eine Datenbank angegeben werden!

Du musst die infos zur Datenbank an der der oben beschriebenen Stelle auch im Objekt Database Viewer eintragen. Die Daten aus der Tabelle chronik müssen in die neue Datenbank übernommen  werden. 

Genau das habe ich ja so eingestellt. Es wird nur eine DB genutzt, die Zugangsdaten unter "Parameter" und "Database Viewer" sind identisch:

Nur hier gebe ich noch den Tabellen-Namen ein, aber es wird offensichtlich nicht darauf zugegriffen. Unter der vorherigen Version ging das problemlos (kann man auch an meinen Verlinkungen im ersten Beitrag erkennen), an diesem Objekt wurde auch nichts geändert. Es gibt eigentlich keinen Grund, warum es hier im Viewer ins Leere greift. Viel mehr kann man ja wohl nicht einstellen.

Genau das macht mich ja so wuschig: es gibt eine neue Version, man hält den Atem an und betet, dass nichts Gravierendes eintritt. Technischer Fortschritt ist ja gut, aber dann sollte Incomedia anhand einer To-Do-Beschreibung darstellen, was sich geändert hat und wie man sein laufende Projekt anpassen muss.

Ich bin nun schon seit bald 10 Jahren mit dem Programm involviert, finde es von der Grundidee auch Klasse, aber ich fühle mich oft nach Versionsupdates, wenn es nicht klappt, recht allein gelassen. Einfach frustierend.

Von V2020.2 auf die V2022.1.7 ist kein nächstes Update sondern du hast einige Versionen übersprungen. Wahrscheinlich sind auch einige Updates vom Database Viewer (v20) gemacht worden in der Zwischenzeit.

Vielleicht hat sich die "Liste der ausgeblendeten Spalten" verändert?

Es hat sich nur der Zugriff auf die Datenbank geändert im generellen bei den neuen Versionen. Kann dir aber nicht genau sagen ob sich automatische Tabellennamen eingefügt haben und deshalb nicht auf die alte "chronik" TAbelle zugreift. Vielleicht hat es eine andere Tabelle angelegt!

Richtig, ich habe einige Versionen übersprungen gemäß dem Motto "never touch a running system". Aber jetzt musste ich doch mal einige Ergänzungen machen. Ich betreue auch noch mehrere andere Projekte, wodurch ich mit den Versionsupdates aber immer aktuell geblieben bin. Auch und gerade weil es bei Versionsupdates immer wieder zu Problemen gekomen ist, bin ich mittlerweile mit einigen Projekten zu WordPress umgezogen. Ist zwar aufwändiger, aber ich habe da vieles in eigener Hand. Aber das ist jetzt hier nicht dasa Thema.

Im Projekt "WageMut" gab es in den vergangenen 12 Monaten keine Notwendigkeit, daran etwas zu ändern. Allerdings müssen jetzt einige Ergänzungen vorgenommen werden. Wie schon oben beschrieben, an dem Database Viewer habe ich keine Veränderungen vorgenommen, Tabellen, Spalten, wie auch Liste der ausgeblendeten Spalten wurde seit Start nicht angefasst. Einträge werden manuell mit SQL direkt über phpMyAdmin ergänzt. Dabei hatte ich ja festgestellt, dass mit der jetzt aktuellen Version von WebSiteX5 automatisch neue Tabellen angelegt wurden und das Mitglieder-Login nicht mehr funktioniert. Klar, sind ja auch leer. Also habe ich die Einträge von "meinen" zu den automatisch angelegten Tabellen kopiert. Dasselbe auch für die dynamischen Objekte. Damit funktioniert das Projekt wieder. Nur die "chronik" wird über den Database Viewer nicht mehr angezeigt. Es wurde oder wird auch keine neue Tabelle (automatisch) angelegt.

Ich weiss nicht, wohin der Database Viewer greift. Darüber hätte ich gern Aufklärung. Und ja: ich  habe die aktuellste Version des Database Viewer Objekts (20).

Ich hätte von den Moderatoren nur gern gewusst, was passiert jetzt (in dieser Version), wenn der Database Viewer Daten anzeigen soll, auf welche Tabelle wird zugegriffen. Die "chronik" Tabelle (die im Objekt seit 'zig Versionen ordentlich eingetragen ist - siehe oben) kann es ja nicht sein, denn es werden von dort keine Daten mehr abgeholt, oder die gehen unterwegs "verloren".

Diese Frage ist eigentlich relativ einfach, kann aber wahrscheinlich nur von den Moderatoren oder den Entwicklern selbst beantwortet werden. Darum bitte ich.

Ich sehe, dass am Testserver noch der Database Viewer v19 Online ist! Bei der neuen Version ist es die v20!

Sind hier alle Einstellungen gleich gemacht worden?  Ich sehe, dass das Häkchen bei "CSV Exportierung anzeigen" in der alten Version nicht angezeigt wird. Versuche mal diese auszuhaken.  Ausserdem auf dieser Seite mal STRG+Vorschaubutton drücken im Programm.

Ja, ich habe ja zur besseren Vergleichbarkeit BEIDE Versionen bereitgestellt, die "alte" Version unter www.theater-wagemut.de/test/chronik.html  (das ist die V2020.2.5 mit wohl Database Viewer V19). Hier wird die CHRONIK zuverlässig angezeigt. Und die "neue" Version unter https://www.theater-wagemut.de/chronik.html (das ist die V2022.1.7 mit sicher Database Viewer V20), hier wird die CHRONIK nicht angezeigt. Also muss doch zwischen den 2 Versionen etwas verändert worden sein.

Das Häckchen bei "CSV Exportierung anzeigen" habe ich mal rausgenommen, hat keinen Einfluss (siehe "neue" Version). STRG+Vorschau gleichzeitig drücken habe ich mir ohnehin generell angewöhnt.

Was mir noch aufgefallen ist: aus der History des Database Viewer geht hervor, dass die V20 an WSX5 V2021.1 angepasst wurde. Kann es sein, dass es hier Kompatibilitätsprobleme zur WSX5 V2022.1 gibt, denn für die aktuellste Verdsion von WSX5 gibt es keine Anpassung wie bei den vorausgegangenen Hauptversionen:

Ab der V2021.1 gab es die Umstellung auf nur eine Datenbank pro Projekt. Deshalb das Update! Allerdings weis ich nicht ob etwas im Programm bei der V2022.1.7 geändert wurde, wo auch ein Update des Database Viewers erforderlich wäre.  Das kann nur ein Entwickler sagen!

So, ich bin jetzt mal in die Datei-Tiefen von WSX5 eingetaucht und was ich da feststellen musste, macht mich dann schon etwas besorgt.
Ich habe festgestellt, dass die Zugangsdaten zur Datenbank in einer Datei im KLARTEXT gespeichert werden, auch das PASSWORD!

Wer also eine Datenbank benutzt, sollte mal in die Datei "res/x5settings.php" schauen, bei mir ab Zeile 55. Das betrifft sicher die meisten Nutzer mit Online-Shops. Wenn sich also jemand unberechtigten Zugriff auf den Webserver beschafft, greift er alle Informationen ab, um auf die Datenbank zu gelangen. Über die Konsequenzen daraus kann sich ja jeder selbst Gedanken machen.

Diese Diskussion hatten wir schon einmal im Zusammenhang mit der Zugangsverwaltung vor etwa 3 Jahren, siehe  https://helpcenter.websitex5.com/en/post/193999.

Daraufhin wurde dort eine Veränderung vorgenommen, so dass die Passwörter verschlüsselt abgelegt werden. Aber an die Zugangsdaten für die Datenbank wurde da offensichtlich nicht gedacht. Das wäre jetzt wieder ein neues Thema!

Es ist nun offensichtlich richtig, dass es mit 2021.1 eine Umstellung im Datenbank-Handling gegeben hatte, über Sinn und Zweck kann man nur spekulieren.

In meinem Fall wird für das Objekt "DatabaseViewer" im Unterverzeichnis "pluginAppObj" ein Objekt angelegt mit einer Datei "dbviewer.php". Das war auch schön früher so, allerdings werden jetzt (nach der Umstellung) die Zugangsdaten zur Datenbank dort mit hineinkopiert, und das natürlich im Klartext!

Aber irgendwie dann doch wieder laienhaft, denn das letzte Zeichen des (offenen) Passwords wird mit magischer Hand durch kryptische Zeichen ausgetauscht, die etwas an HTML Entities erinnern, aber dann auch wieder nicht richtig. Vielleicht kommt dies auch nur vor, wenn das letzte Zeichen ein Sonderzeichen ist. In meinem Fall ist es ein "<" (spitze Klammer nach links), welches beim Kopieren durch eine Zeichenkette "&amp;lt;" ausgetauscht wird. Das sollten die zuständigen Entwickler klären. Jedenfalls wird dadurch natürlich das Passwort falsch und die Datenbank (und damit die Tabelle) kann nicht geöffnet werden, was zum eingangs geschilderten Problem führt.

D.h. bei allen Projekten, welche zumindest den Database Viewer benutzen und zufällig das Passwort mit einem Sonderzeichen oder vielleicht auch nur mit "<" abschließen, kann das in der aktuellen Version nicht mehr funktionieren.

Ich frage mich nur, ob es bei INCOMEDIA vor der Freigabe einer neuen Version keine (möglichst automatisierte) Qualitätssicherung gibt? Hier sollte unbedingt das Test-Team mal hinterfragt werden.

Ich habe jetzt auf unserem Webserver diese Datei manuell angepasst und siehe da, die Visualisierung meiner CHRONIK funktioniert wieder, unter https://www.theater-wagemut.de/chronik.html kann man es sehen.

Ich bin schon etwas enttäuscht von INCOMEDIA, zumal es mir mind. 10 h Arbeit gekostet hat, die Ursache zu finden.

Vielleicht kann mir INCOMEDIA für meine Testunterstützung und konstruktive Zuarbeit dafür einen Gutschein schicken, damit ich die nächste WSX5-Verlängerung kostenfrei erhalte?

Bitte an die Moderatoren, dass mal bei INCOMEDIA nachfragen, Danke.

Hast Du das Kennwort mal geändert und geprüft ob es dann funktioniert? 

Ich habe den Post an das Incomedia-Team weitergeleitet. 

Dass die FTP Daten nicht in Klartext in einer Datei stehen sollten ist klar. Aber wenn einer deinen FTP Account gehackt hat, ist es egal ob er die Datenbank Zugansdaten in Klartext findet, denn die Daten werden sowieso auf der Website angezeigt.

Nun Incomedia kann natürlich nicht riechen, dass du ein "<" im Passwort hast, denn das ist eher ungewöhnlich und sollte genauso wie +-/{}<> nicht verwendet werden, denn dies Zeichen sind für den Programmcode wichtig.

ICh habe schon einige Datenbanken erzeugt und habe nie diese speziellen Sonderzeichen drinnen, denn das wird von meinen Providern von Haus aus verhindert in der "Erzeugung"!

Wenn du das mit dem Verschlüsseln als Wunsch haben willst, musst du es extra als "Anregung" posten.

@Franz-Josef:

Das Kennwort habe ich bisher nicht geändert, um das zu prüfen. Der Aufwand ist dafür relativ hoch, ich habe bereits schon recht viel Zeit geopfert. Hier sollte man sich eine Testumgebung bauen, im Produktivsystem will ich das nicht ständig verändern.

Aber ich hatte in das Objekt "Database View" das Passwort neu eingegeben mit gleichem (negativen) Ergebnis.

@Andreas:

Ich sehe das mit dem Klartext gerade des Passwords schon etwas anders. Auch auf der Webseite wird dieses mit Sternchen angezeigt und kann nicht so einfach ausgelesen werden. Dazu gehört schon höhere kriminelle Energie und geeignetes Fachwissen dazu. Also sollte man das zumindest (wie mittlerweile bei den Zugangsdaten) verschlüsselt ablegen.

Nun, Incomedia kann natürlich nicht "riechen", welche Zeichen ich in meinem Password verwende. Laut Richtlinien sollte man aber sogar Sonderzeichen verwenden, um die Sicherheit zu erhöhen, das ist also nicht ungewöhnlich, wie Du schreibst.

Zeig mir bitte die Stelle, wo Incomedia die Verwendung von allen oder bestimmten Sonderzeichen ausschließt!

Und selbst Incomedia empfiehlt sogar eine Reihe Sonderzeichen für ein sicheres Passwort (siehe "Einstellung -> Datenschutz und Sicherheit -> Sicherheit"):

Wie Du siehst, ist da sogar das von Dir beanstandete Zeichen "<" dabei.

Ich sehe die Verschlüsselung nicht als WUNSCH, sondern als grundlegende LEISTUNGSANFORDERUNG an das Abspeichern von sensiblen Daten wie z.B. Passwörter.

Die Pro-Version ist kein Produkt für Hobby-Bastler, sondern ein kommerzielles Tool, mit denen viele Nutzer ihre Brötchen verdienen und damit auch Gewährleistungspflichtig sind. Da sehe ich Deine Einstellung schon etwas blauäugig!

Im Übrigen wurde diese Diskussion ja schon, wie bereits oben erwähnt, vor 3 Jahren geführt und Incomedia hatte darauf reagiert. Nur halt nicht komplett.

Hello Hans

I understand what you mean about characters, but what Andreas mentioned I believe is right

When you get a password for your Database on your hosting provider, some characters should simply be avoided, such as the one you mention. In most cases, these are blocked by default when creating the password on the hosting panel, but sometimes they're not

In this case, I can simply recommend avoiding code-specific characters such as ' " < > and &

It is not mandatory that these will always cause trouble, but they might. I advise against using there

I remain available here

Stefano

GOOGLE TRANSLATE ---

Hallo Hans

Ich verstehe, was du mit Charakteren meinst, aber was Andreas erwähnt hat, halte ich für richtig

Wenn Sie bei Ihrem Hosting-Provider ein Passwort für Ihre Datenbank erhalten, sollten einige Zeichen einfach vermieden werden, wie z. B. das von Ihnen erwähnte. In den meisten Fällen werden diese beim Erstellen des Passworts im Hosting-Panel standardmäßig blockiert, manchmal jedoch nicht

In diesem Fall kann ich nur empfehlen, codespezifische Zeichen wie ' " < > und & zu vermeiden.

Es ist nicht zwingend, dass diese immer Probleme verursachen, aber sie könnten. Ich rate davon ab, dort zu verwenden

Ich bleibe hier verfügbar

Stefano