WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)

WB-2.8.3-SP1 (die weitere, zukünftige Pflege evt. als CE)

<< < (3/12) > >>

DarkViper:

--- Quote from: cwsoft on July 25, 2014, 03:10:40 PM ---Hier die Datenbank Fixes von NorHei/Marmot (mysql_* -> mysqli_*):
Betroffen sind 5 Dateien (habe ne ZIP, kann diese aber nicht anhängen).
--- End quote ---
Ok, wie ich es mir gedacht habe. Es fehlen noch ein paar Dateien. ;-)  z.B. die upgrade.script.php.

Auf der anderen Seite sehe ich, dass es eigentlich fast ausschließlich die mysqli_real_escape_ string() Funktion ist.
Ich fände es sinnvoller, die mysql_* und mysqli_* Funktionen völlig aus dem Code verschwinden zu lassen. Das erspart viele erneute Anpassungen, falls doch mal auf PDO  etc. umgestiegen wird.

Deshalb mein Vorschlag: Ich bau die real_escape so wie in der 2.8.4 in die class.database ein. Sollten noch 1-2 andere Funktionen betroffen sein, so die eben auch noch.
Und schon ist der eigentliche Code vom verwendeten Datenbanktreiber deutlich unabhängiger.


--- Quote from: cwsoft on July 25, 2014, 03:10:40 PM ---Dann gibt es noch ein paar Patches für veraltete PHP Funktionen (preg_replace mit /e modifier, ini_set):
https://code.google.com/p/wbcom/source/detail?r=044d5590904044a29410965167ba1cd547d53797
https://code.google.com/p/wbcom/source/detail?r=c95f7724eb98542e90bf6bb73402197151d5d14e
https://code.google.com/p/wbcom/source/detail?r=77a3874c83959da4a15998302a2e7b856cafef56
Betroffen sind 4 Dateien (habe ne ZIP, kann diese aber nicht anhängen).
--- End quote ---

show_menu2 sollte eigentlich die Version aus der 2.8.4 problemlos einkopierbar sein. Die wurde zwar gefixt, jedoch keine .4 spezifischen Anpassungen eingebaut.


--- Quote from: cwsoft on July 25, 2014, 03:10:40 PM ---Die meisten der anderen Fixes sind "Backports" der künftigen WB 2.8.4, oder "Features"
, für die ich persönlich keine Verwendung habe.
--- End quote ---
Schaug mer mal, wenn was dabei ist, das in .4 sauber läuft und für die .3 auf selbem Weg implementiert wurde, könnte man daraus evt. kleine Zuckerln für Chio machen. ;-)


--- Quote from: cwsoft on July 25, 2014, 03:10:40 PM ---P.S.: Was in zukünftigen Releases vermieden werden sollte. Die WB283-SP1 ist im SVN nicht getaggt, daher nicht wirklich nachvollziehbar. Die ZIP-Datei der WB283-SP1 (REV 1638) auf der WB-Addonseite unterscheidet sich zudem in 2-3 Dateien von der SVN REV 1638. Das ist wenig transparent und fördert nicht gerade das "vertrauen" :wink:
--- End quote ---
Hatte mir auch leichte Bauchschmerzen bereitet, aber zu dem Zeitpunkt, als das SP gepackt wurde, waren bereits zu viele .4 Änderungen zwischen drin, also musste das wie jetzt auch das SP2 manuell zusammengepackt werden.

Das ist ja das große Problem mit der Versionsübergreifen den Revisionierung seit 2005(das Jahr/nicht die Rev-Nr.).
Mit der neuen Version (2.9) werden wir anfangen, nach jedem Rollout ein neues Repo zu starten, das eben immer bei Rev.#1 beginnt. Dadurch bleibt für Vorgängerversionen jederzeit beliebig 'Luft' nach oben für alle Fixes etc.

Manu

cwsoft:
Hallo,

habe nun das geklonte und nach Git konvertierte Repository von NorHei auf GitHub zur Verfügung gestellt:
https://github.com/cwsoft/wbcom


--- Quote from: DarkViper ---Ich fände es sinnvoller, die mysql_* und mysqli_* Funktionen völlig aus dem Code verschwinden zu lassen. Das erspart viele erneute Anpassungen, falls doch mal auf PDO  etc. umgestiegen wird.
--- End quote ---
Ist sicher die sauberste Lösung. In der aktuellen Situation sollte man aber aufhören Sachen zu "vergolden". Sprich sich jetzt auf das wesentliche konzentrieren und die WB 2.8.4 (oder 2.8.3 SP2) rausbringen, nicht nochmals Monate mit technisch zwar besseren, aber für den Endanwender nicht sichtbaren Änderungen zu vertrötteln.


--- Quote from: DarkViper ---Das ist ja das große Problem mit der Versionsübergreifen den Revisionierung seit 2005(das Jahr/nicht die Rev-Nr.).
Mit der neuen Version (2.9) werden wir anfangen, nach jedem Rollout ein neues Repo zu starten, das eben immer bei Rev.#1 beginnt. Dadurch bleibt für Vorgängerversionen jederzeit beliebig 'Luft' nach oben für alle Fixes etc.
--- End quote ---
In einem verteiltem SVN wie Git/Mercurial machen die ollen SVN keywords ($Id, $Date, $Revision, $HeadURL ...) eh keinen Sinn und sollten aus den Kommentarblöcken der Dateien ersatzlos gestrichen werden (z.B. über einfach Regex in Notepad++).

In Git erstellt man bei einem neuen Softwarerelease (z.B. SP1) einfach einen neuen Tag (z.B. WB 2.8.3-SP1). Danach kann man einfach weiter entwickeln (z.B. fünf Änderungen ins Repo einführen). Der Git-Befehl: "git describe" spuckt dann sowas wie folgt aus: 2.8.3-SP1-5-g79cae1e (rot:=letzter offizieller Tag, grün:= Anzahl Änderungen seit dieser Version, blau:=Kurzform des SHA1 Hashes des aktuellen Standes = letzter Commit). Mit der Kurzform des SHA1 Hashes hat man den Backlink zur Version im Repository.

Gruss cwsoft

rjgamer:
Hi,

hab mich gerade durchgelesen und will als langjähriger Nutzniesser von WB auch noch meinen Senf dazu geben: Ihr seid die besten - weiter so konstruktiv - ich freue mich auf das SP für WB2.8.3!

Gruss

DarkViper:

--- Quote from: BlackBird on July 30, 2014, 11:16:40 AM ---Ich hab da mal ne Frage, bitte nicht schon wieder als Provokation auffassen...
--- End quote ---
Wenn ich solch eine -eigentlich berechtigte- Frage als Provokation auffassen würde, dann wäre es echt Zeit für Rente und Rosenbeet. ;-)
Obwohl, die Frage gehört ja eigentlich in den/einen 2.8.4 Thread. ;-)
Aber egal, solange sich aus einem kurzen OT keine Dauerdiskussion entwickelt, können wir das schon kurz dazwischen schieben.


--- Quote from: BlackBird on July 30, 2014, 11:16:40 AM ---@Manu: Was spricht eigentlich dagegen, mit den bisherigen Quellen für 2.8.4 den Sprung auf Versionsnummer 2.9 zu wagen? WB verweilt schon viel zu lange im 2.8-Zweig, die umfangreichen Änderungen rechtfertigen den Versionssprung hinreichend, und es würde auch viele andere Dinge einfacher machen. (Z.B. die Tatsache zu begründen, warum manche Module nicht mehr funktionieren, wenn sie $database oder die DB_*-Konstanten benutzen.)
--- End quote ---
Ich hatte das schon Mitte Mai zu erklären versucht:

--- Quote from: DarkViper on May 14, 2014, 07:19:58 PM ---[...]
Viele haben sich bereits gewundert, weshalb ich die Versionsnummer nicht bereits jetzt schon deutlich erhöht habe. Die 2.8.4 enthält ja inzwischen schon viele Komponenten, die bereits auf die Nachfolgeversion 2.9 ausgerichtet sind. Jedoch ist diese Version noch weitestgehend abwärtskompatibel. Deshalb blieb sie trotz der ganzen Änderungen in der 2.8.x - Reihe.[...]
--- End quote ---
Bis zur 2.8.4 sind -bis auf ganz wenige Ausnahmen- viele älteren Techniken nur DEPRECATED, und nicht grundsätzlich verboten. Was auch bedeutet, dass auch ältere, halbwegs sauber codierten Module weiterhin funktionieren werden(abwärtskompatibel).
Fehlfunktionen von Modulen auf Grund von Änderungen in neueren PHP-Versionen spielen in einer anderen Liga, da diese auch ohne jede Änderung an WB selbst genauso aufgetreten wären und behoben werden müssten.
Erst mit der 2.9 werden zwangsweise erste, ernsthaftere Inkompatiblitäten auftreten.

Auch die derzeit noch globale Variable $database funktioniert in der 2.8.4 noch ohne Probleme.
Was jedoch nicht mehr geht ist:   $x = new database();  bzw. eben $x = new WbDatabase();. Ein simpler S&R reicht da jedoch völlig aus um alle new database() gegen $GLOBALS['database'] auszutauschen.

Ob ich jetzt innerhalb einer Funktion/Methode/Klasse mit
global $database;
importiere oder mit
$GLOBALS['database']->doQuery();
direkt anspreche oder mit
$database = WbDatabase::getInstance();,
wiederum importiere, ist für den Moment im Prinzip völlig identisch.
Der Unterschied macht sich erst in der nächsten Version bemerkbar, wenn das 3. Beispiel weiterhin funktioniert und die beiden ersten nicht mehr.

Gut, die alten Konstanten mit den Datenbank-Zugangsdaten die sind ersatzlos weg. Das erfolgte allerdings rein aus Sicherheitsgründen, ebenso wie die Umstellung von der config.php auf die setup.ini.php und hat erst ein mal mit einem Upgrade etc. nichts zu tun..
Wer die Zugangsdaten in seinem Code benötigt, kann sie jederzeit mittels der, durch framework/initialize.php zur Verfügung gestellten Funktionen (aber bitte, bitte die initialize.php auf keinen Fall extra nochmal includen! Die ist grundsätzlich immer bereits geladen!)

(array) function initReadSetupFile()
und
(array) initGetDbConnectDat a(array $aCfg, string $sDbConnectType = 'url')
in Kombination:
= initGetDbConnectDat a(initReadSetupFile(), 'url');
abrufen, wobei eine Verbindungs-URL zurückgeliefert wird, die mit dem normalen PHP-Statement parse_url() in ihre Elemente zerlegt werden kann.

Wobei eigentlich der Aufbau einer zweiten Instanz von WbBatabase auf die selben Datenverbindung irgendwie sinnfrei erscheint. Von einem direkten Einsatz von Treiber-Kommandos ala msql_open() bzw. mysqli_open() etc. ausserhalb der WbDatabase wird dringendst abgeraten!

Völlig anders sieht es natürlich aus, wenn z.B. ein Modul33 zusätzlich auf eine zweite, andere Datenbank zugreifen muss.
Aber auch das ist mit der WbDatabase kein Problem mehr:

--- Code: ---<?php

$oMyDb = WbDatabase::getInstance('Module33');
if ($oMyDb->doConnect('mysqli://user:password@example.com:3306/DatabaseName?Charset=utf8&TablePrefix=xx_')
{

// mit
$oMyDb = WbDatabase::getInstance('Module33');
// kann dann spaeter jederzeit diese Instanz importiert werden, ohne ueber globale Variablen gehen zu muessen.

--- End code ---

hgs:

--- Quote from: rjgamer on July 30, 2014, 10:42:29 AM ---Hi,

hab mich gerade durchgelesen und will als langjähriger Nutzniesser von WB auch noch meinen Senf dazu geben: Ihr seid die besten - weiter so konstruktiv - ich freue mich auf das SP für WB2.8.3!

Gruss

--- End quote ---
Dito!
und liebe(r) BlackBird
als "nur Nutzer" habe ich die Argumente für die 2.8.4 verstanden.
Also weiter so konstruktive und wie gesagt: Freue mich auf das SP für die 2.8.3 und bei Neuigkeiten auf die Tests mit 2.8.4
Meine Testversion 2.8.4 Rev2101 läuft und läuft und...

Navigation

[0] Message Index

[#] Next page

[*] Previous page