PHP-Nuke Download Section vs. FileBase
How to import from Filebase ...
- Section 12 - Weiterentwicklungen, Fixes
[25.2.06] DLTIC BugTrack rep060225.000
Beim Test der TIC Import Funktion wollte ich die 3 Testareas, die im Allfix bereits konfiguriert
waren in den PHP-Nuke Downloads Bereich aufnehmen. Hierzu musste ich eine der 3 Testareas zunächst
neu hinzufügen (siehe auch Add Area). Hierbei gab es nun eine Schwierigkeit.
Da alle 3 TIC Areas in ein und dasselbe Verzeichnis verweisen, wurde zwar eins der TIC Areas in
PHP-Nuke Downloads aktiviert, aber die beiden anderen TIC Areas liessen sich, obwohl nun
das Verzeichnis für Downloads existierte, nicht aktivieren.
Nachdem ich den Admin Consolen Script um eine Überprüfung beim Hinzufügen neuer
Areas erweitert habe, indem auch alle anderen Areas die dieses Verzeichnis benutzen für die
Aktivierung in PHP-Nuke Downloads freigeschaltet werden, stehen nun auch alle weiteren TIC Areas
in der Admin Console für die Aktivierung zur Verfügung.
Status: fixed.
[25.2.06] DLIMP/DLTIC BugTrack rep060225.001
Nach dem Hinzufügen neuer Areas im Zusammenhang mit TIC Areas kann eine Dateninkosistenz auftreten,
hervorgerufen durch die asynchrone Verarbeitung durch den Synchronisationsprozess (DLIMP) und
einer vorzeitigen Bearbeitung durch DLTIC.
Wenn in der Admin Console in der AFIX Areas Konfiguration eine Area hinzugefügt wird, in der
bereits etliche Files in der realen Filebase existieren, werden beim DLTIC Import nur die
neuen Files nach PHP-Nuke Downloads importiert. Alle älteren Files bleiben aussen vor.
Da auch ein Update der Files.Bbs Informationen erfolgt kann somit bei einem späteren
DLIMP Synchronisationslauf diese Area nicht mehr mit dem Status geändert erkannt werden.
Ein automatisches Triggern einer DLIMP Synchronisation ist nicht so ohne weiteres möglich, da
die Steuermechanismen (Semaphore File?) für die Synchronisation auf jedem System unterschiedlich
sein können. Hierzu müsste dann zusätzlich in der DLIMP Konfiguration das
zu verwendende Semaphore File definiert werden. Da auf manchen Systemen die Synchronisation aber
auch ohne Semaphore File auskommen könnte, ergibt sich hieraus nun ein Dilemna.
Generell gilt: nach Anlegen einer neuen Area in der AFIX Areakonfiguration muss eine DLIMP
Synchronisation angestossen werden, um die neue Area komplett nach PHP-Nuke Downloads zu importieren.
Eine Möglichkeit würde jetzt noch bestehen: die Synchronisation einer Area in
der DLIMP/DLTIC Admin Konsole nach dem Hinzufügen einer neuen Area nachzubilden.
[13.3.06]
Beim DLTIC Import werden nun beim Auswerten des TIC Files, nachdem der AreaTag festgestellt wurde,
zusätzlich die Sync Informationen für DLIMP aus der DB ausgelesen und geprüft. Wird ein TIC
zu einer bislang inaktiven Area verarbeitet, wird ein automatischer DLIMP UpdateArea() Aufruf für
diese Area gezündet und abgearbeitet. Anschliessend wird das TIC zusätzlich in die Area
mit aufgenommen. In diesem Zusammenhang habe ich sämtliche von DLIMP und DLTIC gemeinsam benutzte
Funktionen in ein Include File includes\func_dli.php ausgelagert.
Status: fixed
[26.2.06] DLTIC BugTrack rep060226.001
Werden für den DLTIC Downlink TIC Files von inaktiven TIC Areas ins Spoolverzeichnis geschoben,
behandelt DLTIC die Files wie folgt:
TIC Files werden in .BAD umbenannt. Die dazugehörigen vertickten Files verbleiben ebenfalls
wie die BAD Files im Spoolverzeichnis.
Status: added
[28.2.06] DLTIC BugTrack rep060228.001
Problem Report: Im Unterschied zur FileBase Synchronisation wurden beim DLTIC Import Beschreibungen nur in
Kurzform übernommen.
Beim Auswerten der TIC Files wird nun auch das Feld Ldesc ausgelesen. Sollte im TIC ein Feld Ldesc
vorhanden sein, wird statt der Kurzform Desc die Langfassung der Beschreibung aus Ldesc
importiert. In der AFIX Konfiguration erscheint nun beim entsprechenden TIC Typ nun zusätzlich
ein Hinweis besser in den Advanced TIC file mode umzuschalten falls dieser auf None
oder Normal gesetzt ist. Dies kann aber nur im ASETUP selbst umgeschaltet werden.
Status: fixed
[28.2.06] DLTIC BugTrack rep060228.002
Problem Report: Beim Wechsel von ASETUP Downlink HoldDir auf Binkley Outbound lieferte
die DLIMP2.PHP Console im AFIX Konfigurationsmenü falsche Ergebnisse.
Zunächst blieb das HoldDir auf dem eingestelltem alternativem DLIMP Spoolpath.
Nachdem ich das Feld DLTIC Alternatetives Spool Verzeichnis und Datei(en) auf den Default
Wert von AFIX Uplink Binkley Primärer Zonen Outbound gesetzt habe, wurde der berechnete
Spoolpath korrekt angezeigt und in die Konfiguration übernommen.
Fixed. Jetzt besteht aber die Möglichkeit, dass vergessen wird die neue Konfiguration zu speichern.
Zwar wird der Path (Files) laut aktueller ASETUP Einstellung angezeigt. Das heisst aber nicht, dass auch
die aktuellen Werte in der DLTIC Konfiguration gespeichert sind.
In Erweiterung erscheint nun neben der Anzeige von DLTIC Alternatives Spool Verzeichnis und Datei(en)
solange ein Hinweis, bis die neue Konfiguration gespeichert wurde.
Status: fixed
[7.3.06] DLIMP/DLTIC BugTrack rep060307.002
Versionsnummern Analyse macht nicht das was sie soll. Generelle Überarbeitung der Funktion ....
[12.3.06] Version() v2 arbeitet nun mit verschiedenen Mustererkennungen. i.e. v#.#, v.#.#, version #, usw.
Status: fixed
[18.3.06] DLIMP/DLTIC BugTrack rep060318.003
'Hinzugefügt am' spiegelt nicht das eigentliche Filedatum wieder. (Reported by Torsten Bamberg)
Für und Wider einer Erweiterung um ein Filedate Parameter:
Das Downloads Modul ist offen für unterschiedlichste Downloads Quellen. Ob das File nun lokal
auf dem eigenen Server liegt oder remote auf einem Fremdsystem ist unerheblich. Aus diesem Grund muss
auch beim manuellen Hinzufügen eines Downloads die Filesize manuell eingetippt werden und kann
nicht automatisch ermittelt werden (lokal würde das zwar funktionieren, nicht aber remote).
Hieraus ergibt sich nun die Schwierigkeit, dass zwar für lokale Files ein Filedate ermittelt
und in die Datenbank eingetragen werden kann. Bei Dateien von Fremdservern würde diese Information
aber fehlen.
[21.3.06] Schrittweise Implementierung:
Ich habe eine Spalte filedate nun zusätzlich in die DLIMP Management Tabelle eingetragen
und mit einem zusätzlichen Script alle fehlenden Werte nachgetragen. Die Implementierung zur Ausgabe
des Filedatums unter PHP-Nuke Downloads ist dagegen abgeschlossen.
Eine besondere Schwierigkeit dürfte die Aktuallisierung unter DLIMP werden. Beispielsweise
ändern die Files unter Filelist selten die Dateigrösse, die als Trigger für eine
DLIMP Synchronisation herhalten könnte, noch ergibt sich aus der Files.Bbs Beschreibung
eine Änderung, die dafür sorgen könnte, dass DLIMP anspringen würde. Da
die Filelisten nicht täglich ge-hatcht werden, ist auch ein Update durch DLTIC nicht
zu erwarten. Wie also können Updates getriggert werden? .... to be continued ....
[22.3.06]
Die Implementierung in DLIMP und DLTIC, so dass auch bei aktuellen, neuen Files das Filedate ermittelt
und in die erweiterte Datenbank eingetragen wird, funktioniert nun auch. Das Triggern der DLIMP
Synchronisation ist aber noch nicht befriedigend abgeschlossen. Dass Problem zur Erkennung
von Änderungen besteht weiterhin. Im DLIMP102.ZIP
Paket sind als Workaround 3 Update Tools enthalten, mit denen fehlende Filedates nachgetragen werden
können.
Status: closed
Erweiterung des PHP-Nuke Downloads Moduls (DLIMP/DLTIC v1.02 related)
- Ersetzung aller LIST() Aufrufe, Auflösung durch Einzelübergabe der Parameter
(list() funktioniert nicht unter sämtlichen win32 Installationen)
- Fixed function getparentlink() für Anzeige mehrfacher Kategorie Ebenen
- Erweiterung um ein 'minimales' Permissions System, add _CATEGORIES - PERM
Value 0: Public Access, Value 1: restricted Access für registrierte Benutzer only
Ausblendung der nicht zugriffsberechtigten Kategorien bei Gastzugang
- Removal aller $ttitle Übergabeparameters in allen Subfunktionen. $ttitle kann notfalls
von der jeweiligen Subfunction mit dem Übergabeparameter $LID aus downloads_downloads
abgefragt werden. Einige Sonderzeichen in Titeln haben PHP Errors erzeugt. Ein Konvertieren
wäre zu aufwendig (encode/decode). Da der Parameter in den meisten Fällen sowieso nicht
benötigt wurde, wurde zwar von Funktion zu Funktion weitergereicht aber nur in
einer Sub-Funktion wohl tatsächlich im Einsatz, habe ich den Parameter entfernt.
- Fixed locale date/time Settings Problem in der Anzeige neuer Files in newdownloadgraphic() und
categorynewdownloadgraphic()
Vergleichsdatum wurde auf locale umgesetzt, DB Wert auf eine feste Definition. Jetzt wird
sowohl Vergleichsdatum alsauch DB Datumswert auf locale Datum normalisiert.
- Änderung der NewDownloads() Anzeige von 'Übersicht' zur 'Anzeige der letzten 7 Tage'
Mich hat es schon ewig geärgert, bei der Ansicht der neuen Files erst noch immer
eine zusätzliche Übersicht zu erhalten, wenn ich im nächsten Fenster
auch noch die Auswahl treffen kann ...
- Ersatz für die A/D (Aufsteigend/Absteigend Sortierung) Anzeige mit sort-a.gif, sort-d.gif
- Fix für das Highlighting von Such Begriffen in der Downloads Sektion (case insensitive)
Bei der Suche nach 'R24PNT' wurde bislang auch nur 'R24PNT' markiert, nicht aber 'R24Pnt' oder
'r24pnt' obwohl die Datensätze die 'R24PNT' in allen möglichen Schreibweisen enthielten
angezeigt wurden ...
- Filedate/Time Anzeige zusätzlich zur 'Hinzugefügt am' Anzeige sofern vorhanden.
Erweiterung der DLIMP Tabelle downloads_dlmgmt um filedate. Files auf Remoteservern liefern kein Filedatum.
Daher bleibt in diesen Fällen die Anzeige leer.
[28.3.06] DLIMP/DLTIC BugTrack rep060328.004
Tagtäglich wird nachfolgender Eintrag von DLIMP neu re-importiert, obwohl die Datei
selbst nicht neu ist (Filedatum 1997, letzter Zugriff auch nicht viel früher)
02432215.ZIP, 2432/215, Ellermanns BBS Heute neu
Beschreibung: 2432/215, Ellermanns BBS
Version: 32/21 Dateigröße: 723.24 Kb
Filedate: 04-Jun-1997
Hinzugefügt am: 27-Mrz-2006 Downloads: 0
Homepage | Bewerten | Fehlerhaften Link melden | Details
Kategorie: FILEBASE/FILELIST
In der Files.BBS erscheint die Zeile:
02432215.ZIP [00] 2432/215, Ellermann's BBS
^
An der gekennzeichneten Stelle ist ein Apostroph noch in der Zeichenkette enthalten. In der importierten
Beschreibung fehlt das Apostrophzeichen.
Solution: mit AddSlashes() und StripSlahes() Beschreibung "maskieren". Sowohl für Titel alsauch
für die Beschreibung.
Workaround: Apostroph aus der Files.Bbs Zeile entfernen.
Fixed dlimp3.php (updatearea() in func_dli.php) and dltic3.php. Removal Apostrophe.
Status: Fixed (ab v1.03)
[20.4.06]
DLIMP/DLTIC BugTrack rep060420.005
Anlegen einer neuen Area unter ALLFIX.
Anlegen einer neuen Area unter Maximus in FileArea.Ctl.
Aufruf DLTIC1 Script.
Aufruf DLIMP2 Admin Console unter PHP-Nuke.
Jetzt erscheint die neu angelegte Area noch als
inactive (soweit noch richtig).
Anlegen neuer Download Area.
Aktivierung neuer Download Area unter DLIMP2.
Überprüfung der neu angelegten Area unter PHP-Nuke Downloads.
Result: Area taucht nicht auf.
In der Tabelle
*_downloads_categories taucht die neue Area nicht auf. Stattdessen wird
in den Tabellen
*_downloads_dlimp und
*_downloads_dlimp2 die neue Area unter der zuletzt
temporären Area ID *Test Area* #392 statt der nächst höheren #393 angezeigt.
[22.4.06] Problem resultierte aus geänderter _Categories Tabellenstruktur für ein
simples Permission Handling (Tabelle enthält nun 5 statt 4 (default) Felder) wodurch
beim Einfügen der neuen Kategorie ein Fehler auftrat.
Dieser Fall wird jetzt abgefangen.
Status: Fixed (ab v1.03)
[12.5.06]
DLIMP BugTrack rep060512.006
Environment:
- OS/2
- Apache 1.3.33
- PHP 4.3.10
- PHPNUKE 7.3
- MySQL 4.1.7
- MySQL Client 3.23.49
Nach Grundkonfiguration laut Install.TXT, Aufruf von DLIMP1.PHP
Error, mhash() undefined.
In der vorliegenden PHP 4.3.10 OS/2 Version gibt es keine MHASH.DLL. Aus einem früheren
Paket gibt es zwar eine MHASH.DLL. Wenn diese aber in PHP.INI eingebunden wird
ändert sich die Fehlermeldung in:
Error, ungültige DLL Version, ist keine PHP DLL
[28.7.06] Added new function hmac() ab v1.10.
Die Funktion hmac() ersetzt die Library Funktion mhash(), so dass keine Datei MHASH.DLL
mehr benötigt wird.
Aktuallisierung von dlimp1.php, dlimp3.php, dltic3.php, func_dli.php
Status: Fixed (ab v1.10)
[12.5.06]
DLIMP BugTrack rep060512.007
Environment:
- OS/2
- Apache 1.3.33
- PHP 4.3.10
- PHPNUKE 7.3
- MySQL 4.1.7
- MySQL Client 3.23.49
Fehler: Nach Entpacken und Verschieben der HTML Files aus dem Installationspaket funktioniert
der ADMIN.PHP Aufruf nicht mehr.
Vor PHP-NUKE Revision 7.6 wurden direkte Modulaufrufe mit nachfolgendem Code abgefangen:
if (!eregi("admin.php", $_SERVER['PHP_SELF'])) { die ("Access Denied"); }
Ab Version > 7.5 wird einer der beiden nachfolgenden Aufrufe benutzt um Direktaufrufe
abzufangen. DLIMP benutzt nachfolgende Version. Das führt aber beim ADMIN.PHP Aufruf zu
Problemen, wenn ADMIN_FILE in config.php nicht definiert ist.
if ( !defined('ADMIN_FILE') )
{
die ("Access Denied");
}
if (!eregi("".$admin_file.".php", $_SERVER['PHP_SELF'])) { die ("Access Denied"); }
Workaround: nachträgliches Einfügen der nachfolgenden Zeile in PHP-Nukes config.php
$admin_file = "admin";
Status: Fixed (ab v1.03)
[28.7.06]
DLIMP BugTrack rep060728.008
Nach Upgrade zu v1.10 und Import Initialisierung funktioniert keiner der
Download Links mehr. Error: File not found.
Die Downloads/Fetch/GetIt Routinen lieferten als Ergebnis fehlerhafte Links.
Bei der weiteren Analyse zeigte sich, dass die BASEPATH und HOMEPAGE Konfiguration
x1)
aus der SQL Datenbank verschwunden waren.
Im Zusammenhang der Analyse fiel aber auf, dass ein entscheidender Konfigurationsschritt
bei der Installation des Gesamtpakets, der hardcoded Homepage/Basepath Eintrag in der
Datei
DOWNLOADS.PHP im PHPNUKE Verzeichnis überflüssig ist, da die Information
ja aus der Datenbank abgerufen werden kann.
Status: Fixed (ab v1.11)
[29.7.06]
DLIMP BugTrack rep060729.009
Nach Upgrade zu v1.11 funktioniert der Download Link mit http:// im Text nicht. Error: File not found.
Die Downloads/Fetch/GetIt Routine liefert als Ergebnis Basepath + http-URL als Link
x1).
Weitere Korrektur des DOWNLOAD Moduls
index.php
Ebenso File not found bei http-URL Link unter Guest Status.
Status: Fixed (ab v1.12)
x1)
Die DLIMP und DLTIC Routinen erzeugen Link Einträge, ohne HOMEPAGE und BASEPATH Informationen
in der Datenbank. Beim Datei Request werden die Informationen HOMEPAGE, BASEPATH und
die Sub-URL-Link-Information zum absoluten Link neu zusammengefügt. Beim manuellen Einstellen
einer Datei in die Downloads Section kann auch ein HTTP Link eingestellt und in die Datenbank
geschrieben werden. Das führte dann zu einer fehlerhaften Link-Generierung von
Basepath + http:// Url
[19.8.06]
DLIMP BugTrack rep060819.010
>> Jetzt wollte ich an DLIMP ran und schon beim ersten Versuch passiert
>> folgendes :-(
>>
>> DLIMP script started.
>> Import lines GROUPS.LST: 20
>> save record DLIMP failed.
>> save record DLIMP failed.
>> Import lines C:\MAX\FILEAREA.CTL: 2738
>> PARAMETER NOT FOUND !!! FILEDIVISIONBEGIN A TRANSIENT . LOKALER
>> BEREICH Filepath: F:\FILES\INFO\
>>
>> Fatal error: Call to undefined function: hmac() in
>> C:\apache\fbmaint\dlimp1.php on line 857
>>
>> Any ideas?
include("includes/func_dli.php");
if (defined('FUNC_DLI')) {
/* ok */
} else {
print "Error: func_dli undefined.\n";
}
fehlen in der DLIMP1.PHP Routine (hatte nicht erneut den Step 1 durchgetestet, nur die Routinen
umgeschrieben, dabei aber vergessen die entsprechende Routine einzubinden ...)
Workaround:
Obige 6 Zeilen in DLIMP1.PHP _NACH_ dem Block der mit
if (!defined("SQL_LAYER") AND !defined("SQL_LAYER_ON")) {
beginnt einfuegen ... ;)
func_dli.php enthält die Ersatzfunktion fuer die Hash Ermittlung .. ;)
Ebenfalls in DLTIC1.PHP hinzugefügt.
Status: Fixed (ab v1.13)
[21.8.06]
DLIMP BugTrack rep060821.011
DLIMP (1) script started.
Fatal error: Cannot redeclare rat() (previously declared in
C:\apache\fbmaint\dlimp1.php:306)
in C:\apache\fbmaint\includes\func_dli.php on line 126
func_dli.php enthält eine Hilfsfunktion rat(), die erst nach Abschluss der Entwicklung
von DLIMP1.PHP später in FUNC_DLI.PHP eingefügt wurde. Zentrale Bibliotheksroutine
beibehalten. Aus DLIMP1.PHP entfernt.
Status: Fixed (ab v1.14)
[29.8.06]
DLIMP/DLTIC BugTrack rep060829.012
Tabelle
_DOWNLOADS_DOWNLOADS enthält teilweise Full URLs nach Einspeicherung
neuer Files. Sollte um den Homelink und den Basepath gekürzt sein.
i.e.
url: http://ambrosia60.dd-dns.de/12345678/service/r24pnt.z99
expected: service/r24pnt.z99
Für das DLIMP System ist die Einspeicherung auf drive/path/file reduziert.
Noch ausstehend: Überprüfung des DLTIC Systems.
16.10. DLTIC3 checked, fixed.
Status: Fixed (ab v1.15)
[30.8.06]
DLIMP/DLTIC BugTrack rep060830.013
Installationsprozedur:
DLIMP1.php liefert für sämtliche Records:
Filepath: Q:\path\subpath\
Filesize .: 123456
File CRC32: 880fddcaccd9d80e363397fb4b357680
save record DLIMP failed. <== !!!!!
Der Debug Modus liefert:
Filepath: Q:\TREIBERN\PACKER\
Filesize .: 112812
File CRC32: 880fddcaccd9d80e363397fb4b357680
Add new Title: TRN_AR
INSERT INTO nuke_downloads_dlimp VALUES (NULL,'TRN_AR','TRN_AR',0,0,'TREIBERN','
Q:\\TREIBERN\\PACKER\\','TRN_AR','TRN_AR','TreiberNet - Packprogramme','TRN_AR',
'PRIVIL',50,0,0,0,18,1,553,0,'')
save record DLIMP failed.
function add_rec_dlimp() missing value sumfsize.
Die in DLIMP v1.01 vom 29.1.06 erweiterte Struktur der Tabelle nuke_downloads_dlimp um die Spalte
sumfsize wurde nicht in der Funktion add_rec_dlimp() von DLIMP1.php eingepflegt.
Status: Fixed ab v1.15
[19.8.06]
DLIMP BugTrack rep060819.014
I:\Apache\Apache2\fbmaint.114>dli1
DLIMP (1) script started.
Import lines GROUPS.LST: 78
Add new Title: BAHN1
Add new Title: BAHN2
Import lines C:\MAX\FILEAREA.CTL: 2738
PARAMETER NOT FOUND !!! FILEDIVISIONBEGIN A TRANSIENT . LOKALER BEREICH
Dl(1) Path : F:\FILES\INFO\
Dl(2) Path : F:\FILES\INFO\
Filepath: F:\FILES\INFO\
FILEAREA.CTL Structure Problem ...
Added Known Parameters:
FileDivisionBegin, FileDivisionEnd, Upload
Status: Fixed ab v1.15
[22.8.06]
DLIMP BugTrack rep060822.015
PHP-Logfile Report:
Fatal error: Call to a member function on a non-object in C:\apache\fbmaint\dlimp1.php
on line 838
Reproduzierter PHP-Errorlog Auszug:
[07-Sep-2006 00:06:33] PHP Warning: dir(J:\FILES\GERNET\): failed to open dir:
Invalid argument in i:\apache\apache2\fbmaint.114\dlimp1.php
on line 871
[07-Sep-2006 00:06:33] PHP Fatal error: Call to a member function on a non-object
in i:\apache\apache2\fbmaint.114\dlimp1.php on line 873
Mögliche Fehlerursachen:
a) Auf Laufwerk J: kann nicht zugegriffen werden (Drive Offline). i.e. nicht mehr zur Verfügung stehendes CD-Laufwerk oder CR-Rom.
b) Pfad existiert nicht. i.e. deaktivierte und in der Config vergessene FileArea.
Check auf:
- if exist(Drive)
- if exist(Path)
- if exist(Drive+Path+FILES.BBS)
- otherwise: Error, Skip
In dem Zusammenhang erhebt sich die Frage, ob eingebundene CDs immer eine FILES.BBS
mitliefern. Eher unwahrscheinlich. Wie sollen nun aber CDs eingebunden werden?
Entweder müsste für den Fall einer CD Einspielung ein Feld für
das Nicht-Existieren einer FILES.BBS eingefügt werden, als Schalter in der Datenbank
oder aber ein Temporär Verzeichnis mit virtuellen FILES.BBS Dateien die
als FileAreas auf den CDs existieren, nach denen dann DLIMP einen Abgleich
durchführen kann. Hierfür müsste DLIMP einen lapidaren DIR() Aufruf in die Hilfs-FILES.BBS
vornehmen, um wenigstens die Dateinamen innerhalb einer FileArea auflisten zu können.
Da sich bei einer CD der FileArea Inhalt nie verändert, könnte der Hinweis auf
die spezielle Behandlung der FILES.BBS als Flag in der DLIMP-Tabelle mit der Übernahme
des FileCRCs des Hilfs-FILES.BBS erfolgen.
Beim Updatevorgang (DLIMP3.PHP) könnte der FILES.BBS Abgleich aufgrund des Flags
dann übersprungen werden.
- Grundlegende Überarbeitung der DLIMP1 Import Routine um CD-Rom Support (Erkennung ob das Laufwerk
ein CD-Rom Laufwerk oder eine Harddisk ist) (done).
- Überarbeitung der DLIMP2 PHP-Nuke Adminconsolen Steuerung. Unterstützung der erweiterten
Flags und abhängige Areaaktivierungsmöglichkeit (nicht mehr existierende FileAreas können
nun nicht mehr aktiviert werden, CD-Rom Areas werden mit einem CD Symbol
kenntlich gemacht) (done).
- Identifizierung Laufwerk, Pfad, Files.Bbs Existenz und Eintrag in die Datenbank zur späteren
unterschiedlichen Verarbeitungsweise (done).
11.9.: dlimp1 + dlimp2 updated.
13.9.: dlimp3 + Downloads Section (Webzugriff) updated.
Überprüfung des DLTIC Systems.
20.9.: dltic1 checked, + dlimp2 updated (add new TIC area).
16.10.: dltic3 checked + updated.
Status: Added, Fixed ab v1.15
[6.9.06]
DLIMP BugTrack rep060906.016
I:\Apache\Apache2\fbmaint.114>dli1
DLIMP (1) script started.
Import lines GROUPS.LST: 78
Add new Title: BAHN1
Add new Title: BAHN2
Import lines C:\MAX\FILEAREA.CTL: 2738
Dl(1) Path : F:\FILES\INFO\
Dl(2) Path : F:\FILES\INFO\
Filepath: F:\FILES\INFO\
Import bricht nach der ersten Maximus FileArea Definition ab.
a) Maximum execution time of 60 seconds exceeded
set dlimp1.php line 20: set_time_limit(86400); // 1 full day
b) see BugTrack
rep060822.015
Status: Fixed ab v1.15
[7.9.06]
DLIMP BugTrack rep060907.017
I:\Apache\Apache2\fbmaint.114>dli1
DLIMP (1) script started.
Import lines GROUPS.LST: 78
Import lines C:\MAX\FILEAREA.CTL: 2738
Filepath: H:\FILES\I_FAQ\
save record DLIMP failed.
Hin und wieder erscheinen Meldungen, dass einzelne Records nicht gespeichert
werden können.
Bei der Analyse stellte sich heraus, dass in allen Fällen Sonderzeichen
in der Filearea Beschreibung vorhanden waren: ' < >
Status: Fixed ab v1.15
[8.9.06]
DLIMP BugTrack/Erweiterung rep060908.018
Stufe 1: Import Maximus FileArea.Ctl via Groups.Lst in die Datenbank
Die Philosophie des Programmablaufs sieht zunächst einen vollständigen
Import sämtlicher FileArea.Ctl Areas in die Datenbank vor.
Die Vollständigkeit des Imports aller FileAreas ergibt sich aus der Notwendigkeit,
dass im Laufe des Betriebs der Phpnuke Downloads Section in Maximus oder Allfix hinzukommende
Areas nur noch in der Phpnuke Admin Console hinzugefügt werden. Ein nachträglicher
Transfer aller fehlenden Area Definitionen wird in der Phpnuke Admin Consolen Ansicht
schnell unübersichtlich und äusserst zeitaufwendig.
Abb.1 DLIMP Modelling
Mit den Angaben in der Datei Groups.Lst werden die Areas, die in der Maximus FileArea.Ctl
eindimensional vorliegen in eine Ordnung und Baumstruktur gelenkt. Nicht definierte Zuordnungen sollten
letztendlich im Root landen (BugTrack, landen in der letzten aktiven Group). Im zweiten Schritt
(dlimp2 in der Phpnuke Admin Console) werden erst Definitionen vorgenommen, ob Areas in die Phpnuke
Downloads Section übernommen und aktiviert werden oder nicht.
Wenn Groups.Lst unvollständig ist, werden nicht zuordnenbare FileAreas
in der Datenbank ins Root gelegt (so die Theorie). Faktisch landen zur Zeit alle undefinierbaren
FileAreas in der zum Zeitpunkt des Imports zuletzt aktiven Gruppe. Werden nur 2 von vielleicht 20
möglichen Definitionen vorgenommen, landet somit der Grossteil der Maximus FileAreas
im Datenbank Modell an Stellen zu denen sie nicht gehören. Status: fixed ab v1.15
Ein weiteres Problem entsteht durch inaktive FileAreas (i.e. CD-Rom Filebase, bei
deaktivierter CD-Rom) auf die in FileArea.Ctl noch verwiesen wird (siehe auch
rep060822.015).
Nun gibt es in Maximus selbst ein Grouping (siehe auch
rep060819.014) mit den
Parametern: FileDivisionBegin, FileDivisionEnd.
In diesem Zusammenhang ergeben sich jetzt weitere Möglichkeiten:
- Strickte Gruppierung nach Groups.Lst Vorgaben.
Undefinierte Areas landen im Root. Fixed in v1.15
- Gruppierung nach Groups.Lst und FileDivision* Vorgaben.
Gibt es fehlende Grouping Definitionen
in der Groups.Lst landen die unzugeordneten Areas entweder im Root, oder wenn es FileDivision*
Statements in der Maximus-FileArea.Ctl Datei gibt in Gruppen die durch FileDivision* Vorgaben
definiert werden (Mixed Mode).
- Auto-Grouping anhand von FileDivision* Vorgaben (Auto-Generierung von Groups.Lst)
Hierbei werden sämtliche Groups.Lst Definitionen ausser [Exclude] und [Root] überschrieben
und die Datei Groups.Lst durch FileDivision* Vorgaben neu geschrieben. Im zweiten Schritt
erfolgt der eigentliche Import.
[19.10.06] Added Merge Mode für Maximus FileDivision Grouping Definitionen, wenn FileArea
laut Groups.Lst nicht zugeordnet werden kann.
Added Config Parameter in
includes\constants.php:
// *0 Handle Groups by GROUPS.LST only, orphan fileareas adding to Root
// 1 Handle Groups by GROUPS.LST, merge undefined areas
// by Maximus filedivision groups, merge mode
// (autoadd FileDivision Groups if neccessary)
// 2 Handle Groups by Maximus filedivision definitions only
// * default: 0
define('MXGRPMERGE',1);
FileDivision Groups können/dürfen geschachtelt sein (Baumstruktur).
[23.10.06] Added FileDivision Groups Mode für Maximus FileDivision Grouping Definitionen.
Wenn keine Datei
GROUPS.LST vorliegt und die Gruppeneinteilung unter Maximus in die phpNuke
Downloads Section 1:1 übernommen werden soll, ist mit dem Wert
2 für den Parameter
MXGRPMERGE die Maximus Gruppenzuordnung transferierbar.
Structure Änderung in
_downloads_tempimp: added MXDESCRIPTION für die Übernahme
der Gruppenbeschreibung unter Maximus.
Anders als in der ursprünglichen Vorstellung des Auto-Groupings wird die Datei Groups.Lst nicht
beschrieben. Die Datei Groups.Lst wird erst garnicht benutzt. Stattdessen erfolgt ein direkter Import
in die Datenbank in die Tabelle
*_downloads_tempimp. Hierbei wird die FileDivision Gruppenbeschreibung
gleich mit importiert. Eine Gruppenbeschreibung gibt es unter der Groups.Lst Importmethode nicht.
Nach abschliessendem Test, wie sich das Programm bei fehlenden FileDivision Statements in der FileArea.Ctl
verhält, habe ich noch eine Überprüfung hinzugefügt, die mindestens ein FileDivision
Statement verlangt. Andernfalls wird der Import abgebrochen.
Im Merge Mode landen alle nicht zugeordneten FileAreas automatisch im Root. Ebenso im Groups.Lst Mode.
Empfehlung: Definiere eine Gruppe
REST in Groups.Lst und definiere entweder sämtliche Laufwerks
Rootverzeichnisse (falls die Filebase über mehrere Laufwerke verteilt ist), oder das Rootverzeichnis
des Laufwerks in dem alle FileAreas abgelegt sind:
Bsp.: Datei Groups.Lst
...
[REST]
parent=0
Q:\
Somit wird sichergestellt, dass sämtliche zu importierenden FileAreas nach dem Import Vorgang
einer Gruppe zugeordnet sind.
Status: Abschliessend umgesetzt in v1.16
[8.9.06]
DLIMP BugTrack/Erweiterung rep060908.019
Bislang können keine mehrfachen Laufwerke als Filebase Quelle definiert werden.
Schritt 1, Import der FileArea.Ctl funktioniert zwar noch, aber spätestens bei
Schritt 2 oder 3 kann die Laufwerksdefinition nicht in die Homepage + Basepath Definition
überführt werden.
Möglicher Ansatz: Erweiterung der
[ path / [ path / ]] file . ext Definition für die Einspeicherung
in
[ drive $ / ] [ path / [ path / ]] file . ext Definition.
Die Zusammenführung mehrerer Laufwerke in ein virtuelles Verzeichnis unter Apache kann durch die Mehrfachdefinition
einer zusätzlichen Verzeichnisebene realisiert werden:
Alias /12345678/Q "Q:/"
Alias /12345678/D "D:/"
Alias /12345678/E "E:/"
Alias /12345678/F "F:/"
Alias /12345678/H "H:/"
Eine Unterscheidung von Q$/Files zu F$/Files kann somit bewerkstelligt werden. Auch eine weitere detailiertere
Unterscheidung:
Alias /12345678/Q/Files "Q:/Files/"
Alias /12345678/D/Bahn "D:/Bahn/"
Alias /12345678/D/Files "D:/Files/"
Alias /12345678/E/Files "E:/Files/"
Alias /12345678/F/Files "F:/Files/"
Alias /12345678/H/Files "H:/Files/"
ist möglich. Jedoch werden hier die Pfade Case-Sensitive ausgewertet (!?). Der Aufruf von /12345678/d/bahn
liefert Error 404, Not found.
Hier kommt die
AliasMatch Directive zum Tragen:
AliasMatch (?i)^/12345678/q/files/(.*) "Q:/Files/$1"
AliasMatch (?i)^/12345678/d/bahn/(.*) "D:/Bahn/$1"
AliasMatch (?i)^/12345678/d/files/(.*) "D:/Files/$1"
AliasMatch (?i)^/12345678/e/files/(.*) "E:/Files/$1"
AliasMatch (?i)^/12345678/f/files/(.*) "F:/Files/$1"
AliasMatch (?i)^/12345678/h/files/(.*) "H:/Files/$1"
Der Aufruf von /12345678/d/bahn alsauch der Aufruf von /12345678/D/Bahn oder /12345678/D/BAHN liefern
nun das gewünschte Ergebnis. Der Aufruf /12345678/q liefert wie erwartet Error 404, not found
(Security für die eigenen Festplatten! Es sollen ja keine anderen Verzeichnisse auf Laufwerk Q:
vom Webserver aus zugegriffen werden.).
Nun erhebt sich noch die Frage, ob überhaupt eine Kodierung von Q: nach Q$ vorgenommen werden
muss, oder ob nicht gleich Q:/Files/path/filename in die Datenbank eingespeichert werden kann ...
Bei der Suche nach einer Datei Q:/Files/readme.txt kann eine Übersetzung nach
/12345678/q/files/readme.txt dadurch erfolgen, dass vom Q:/ Anteil der Doppelpunkt nur entfernt
wird und der Basepath vorangestellt wird:
'/12345678/' + ( 'Q:/Files/readme.txt' - ':' )
'/12345678/' + 'Q/Files/readme.txt'
= '/12345678/Q/Files/readme.txt'
Für DLIMP ist die multiple Drives Unterstützung nun eingebaut.
Einspeicherung in der Form: Q/Files/readme.txt
Anpassung des Webzugriffs auf die Downloads Section (index.php) und der AddOns (download.php, fetch.php).
Noch ausstehend: Überprüfung des DLTIC Systems.
[16.10.06] DLTIC Outbound: checked, fixed, OK
[16.10.06] DLTIC Spooldir: checked, fixed, OK
Status: Added in v1.15
[11.9.06]
DLIMP BugTrack rep060911.020
Function DLIMPEditSave():
Hin und wieder wird der
Basepath Konfigurationsparameter zurückgesetzt. Ein vorhandener
Wert wird einfach überschrieben. Zurück bleibt ein leerer Eintrag.
In der Function DLIMPEditSave() werden IMMER die Konfigurationsparameter
Basepath und
Homepage
aktuallisiert. In der Funktion DLIMPEDit(), der einzigen Funktion die DLIMPEditSave() aufruft, wird aber
kein Parameter
Basepath und
Homepage übergeben oder vordefiniert.
Basepath und
Homepage Aktuallisierung aus DLIMPEditSave() entfernt.
Status: Fixed ab v1.15
[11.9.06]
DLIMP BugTrack rep060911.021
Bei Datenbank Neuaufbau erscheint in der PHP-Nuke DLIMP Admin Console als Konfigurationsparameter
nur der Parameter
BasePath. Der Parameter
HomePage bleibt ausgeblendet.
Bei der DLIMP Datenbank Initialisierung wird der Parameter
BasePath mit dem Inhalt '/' angelegt.
Der Parameter
HomePage ist noch unbelegt. Beim erstmaligen Aufruf der PHP-Nuke DLIMP Admin Console
wird der Parameter
HomePage mit dem Wert der NUKE_CONFIG Tabelle und dem Parameterinhalt von
NUKEURL vorbelegt.
Status: Fixed ab v1.15
[11.9.06]
DLIMP BugTrack rep060911.022
Bei Datenbank Neuaufbau wird die Aktivierung der DLIMP Konfiguration nach PHP-Nuke Downloads Section
nicht übernommen.
Nach Erweiterung des Downloads Systems um ein rudimentäres Permission System wurden
Categories nicht mehr neu angelegt, weil die Tabelle nun eine zusätzliche Spalte (Perm) enthält.
Status: Fixed ab v1.15
[11.9.06]
DLIMP BugTrack rep060911.023
Step 1: nach initialem DLIMP1 Import und Aktivierung einiger Areas in der PHP-Nuke DLIMP Admin Console,
Modifikation der
Groups.Lst 'Routing' Konfiguration.
Step 2: Erneuter Aufruf DLIMP1.PHP
Step 3: Aufruf PHP-Nuke DLIMP Admin Console, Aktivierung einzelner neuer Area Gruppen
Step 4: Funktion
Aktiviere DLIMP Konfiguration
Nach Step 4 tauchen in der PHP-Nuke Downloads Section zuvor aktive Area Gruppen einfach nicht
mehr auf. Dafür sind jetzt die neuen Categories und FileAreas aktiv.
In der Tabelle
*_downloads_categories wurde ein Hauptgruppeneintrag, der wiederum die
alten Untergruppen und FileAreas enthielt von einer FileArea Definition überschrieben, die
Bestandteil einer dieser Untergruppen war. Dieser Eintrag taucht übrigens doppelt auf:
Record 71: Title 'CD162'
Record 72: Title 'CD162'
Description, ParentID und Permissions sind voll ausgefüllt. Es sieht so aus, als wäre der
Eintrag bei der letzten
DLIMP Aktivierung der Konfiguration überschrieben worden.
Die fragliche Routine in DLIMP2.PHP wäre: DLIMPQSave()
In der Tabelle
*_downloads_dlimp verweisen die neuen Gruppen auf die ID 73, sollte aber auf
die ID 72 verweisen. Unzählige Einträge enthalten als Ownid immer die selbe ID 72 während
die Neuzugäge eine fortlaufende neue Nummer enthalten.
Die Reihenfolge der ParentIDs und der Baumstruktur folgt nicht einem Top-Down Muster. Nachdem zunächst nur
2 Gruppen im ersten Schritt aktiviert waren, wurde die Hauptkategorie erst später hinzugefügt
und erhielt somit eine höhere Ownid. Aufgrund der verdrehten Reihenfolge könnte die
Möglichkeit bestehen, dass aus diesem Grund die Hauptkategorie überschrieben wurde. Aber
auch ein einfacher Pointer-Versatz (Differenz von 1 bei der CID) könnte als mögliche
Ursache für das Problem in Frage kommen.
Eine weitere Fehlerursache - nach dem zweiten Import war ein Durchlauf
Fix DLIMPs Reihenfolge Konflikt
notwendig, der ebenso diesen Versatz hätte produzieren können? - In der Funktion fixDLIMPw()
wird nur die Tabelle
*_downloads_dlimp upgedatet. Kommt also nicht in Frage.
Tabelle
*_downloads_categories wird in den nachfolgenden Funktionen modifiziert:
- DLIMPQSave()
- DLAFFAASV() - Beschreibung: save / create new area from allfix configuration, kommt also nicht in Frage
DLIMPQSave() liefert als Lösungsansatz die Variante, dass der entsprechende
OWNID Eintrag in
*_downloads_dlimp in der Tabelle
*_downloads_categories den entsprechenden
CID
Eintrag modifiziert. Da nun in
*_downloads_dlimp etliche Einträge mit
OWNID = 72
zu finden sind, ist davon auszugehen, dass jeder
*_downloads_dlimp Record mit der
OWNID 72
den entsprechenden
*_downloads_categories Eintrag modifiziert hat. Wie kommt nun aber der
Umstand zustande, dass viele
*_downloads_dlimp Records die
OWNID 72 führen? An sich
sollte jeder Record seine eigene OWNID führen.
Da auf diesem Analyseweg keine weitere Eingrenzung möglich ist, Versuch der Reproduzierung:
Groups Structure
Root --+ A --+ A1
| + A2
| + B1
| + B2
+ C
- Reset DBs
- Import 1 mit kurzer Groups.Lst (Categories: empty, Dlimp: parentId + OwnID all 0
- Aufruf DLIMP2 (383 Areas in Root, Cat A, Cat A1 Areas 2-8 C01-C07, Cat A2 Areas 2-63 CD101-CD162)
- Edit HomePage + BasePath, Save
- Block activate A1 (op=ChgDLIMPStatus&tid=0&l1=2)
Dlimp: 383 Areas mit Parentname ROOT, A1 Areas mit Parentname A1, A2 Areas mit Parentname A2, ansonsten ParentID
und OwnID jeweils 0, ipa bei den aktivierten Areas = 2
- Block activate A2 (op=ChgDLIMPStatus&tid=0&l1=3)
Status wie zuvor, zusätzlich ipa=2 bei aktivierten Areas A2
- Start Aktiviere DLIMP Konfiguration
383 Root Areas PID=0, ID=0; Group A: PID=0, ID=0; Group A1: Pid=0 Id=1; Areas A1: Pid=1, Ids=2-8;
Group A2: Pid=0 Id=9; Areas A2: Pid=9, Ids=10-71. Soweit OK.
Categories: Group A1 Cid=1 ParentID=0, Areas A1 Cid=2-8 ParentID=1, Group A2 Cid=9 ParentID=0,
Areas A2 Cid=10-71 ParentID=9
Dlimp: Group A1 ParentID=0 OwnID=1, Group A2 ParentID=0 OwnID=9, Areas A1 ParentID=1 OwnIDs 2-8,
Areas A2 ParentID=9 OwnIDs=10-71. Soweit auch OK.
- Aktivierung Group A (op=ChgDLIMPStatus&tid=0&l1=1)
Categories und Dlimp unverändert (ausser ipa=2 bei aktivierter Group A).
- Start Aktiviere DLIMP Konfiguration
383 Root Areas PID=0, ID=0; Group A: PID=0, ID=72; Group A1: Pid=72 Id=1; Areas A1: Pid=1, Ids=2-8;
Group A2: Pid=72 Id=9; Areas A2: Pid=9, Ids=10-71. Soweit OK.
Categories: Group A1 Cid=1 ParentID=72, Areas A1 Cid=2-8 ParentID=1, Group A2 Cid=9 ParentID=72,
Areas A2 Cid=10-71 ParentID=9, Group A Cid=72 ParentID=0
Dlimp: Group A ParentID=0 OwnID=72, Group A1 ParentID=072 OwnID=1, Group A2 ParentID=072 OwnID=9,
Areas A1 ParentID=1 OwnIDs 2-8, Areas A2 ParentID=9 OwnIDs=10-71. Soweit auch OK.
- Austausch Groups.Lst Kurzversion gegen Vollständig
- Start Import 2: DLIMP1.php
Categories: keine Änderung, Dlimp: Area A ParentID=0 OwnID=72 (ok), Area A1 ParentID=72 OwnID=1 (ok),
Area A2 ParentID=72 OwnID=9 (ok)
Areas A1 ParentID=1 (ok) OwnID=72 ALLE! (not OK !!!), Areas A2 ParentID=9 (ok) OwnID=72 ALLE! (not OK !!!)
- Aufruf DLIMP2 Anzeige
Aktive Areas A1 PID=1 ID=72 ALLE!, Areas A2 PID=9 ID=72 ALLE!
- Aufruf Fix DLIMPs Reihenfolge Konflikt
ID=72 für sämtliche Einträge wird nicht gefixt!
Tabellen Categories und Dlimp ansonsten aber soweit noch ok (bis auf Dlimp alle OwnId=72).
Schlussfolgerung: Erweiterung der Funktion fixDLIMPw() um Bereinigung der OWNID Werte.
Fixed.
Daraus folgt nun, dass ein nachträglicher Import mit DLIMP1.php die Datenbankstruktur
durcheinanderbringt. Eine Aktivierung neuerer Einstellungen wäre problematisch. Hieraus
folgt nun, entweder DLIMP1.php nach erstmaligem Aufruf vollkommen zu sperren, oder vor weiterer
Verarbeitung unter DLIMP2.php erst einen
Fix DLIMPs Reihenfolge Konflikt Aufruf zu
erzwingen.
DLIMP1 Abfrage: Config Parameter PREVENT1 ?
Wenn Ja: Wert = 1 ?
Wenn Ja: Abbruch ?
oder
DLIMP2 - Aktiviere DLIMP Konfiguration - Setze PREVENT1 auf 1
Bei DLIMP1 Aufruf - Abfrage Config Parameter PREVENT1
Wert vorhanden ?
Auslesen - Wert = 1 ?
Wenn Ja, setze Wert auf 2
DLIMP2 Aufruf, bei allen Funktionen, Abfrage Config Parameter PREVENT1, Wert > 1`?
Wenn Ja, Abbruch der Funktion, Hinweis auf Ausführung
Fix DLIMPs Reihenfolge Konflikt
Nach Fix Routine, Zurücksetzen von PREVENT1 auf 1
Status: Fixed ab v1.15
[13.9.06]
DLIMP BugTrack rep060913.024
Wie in BugTrack
rep060911.023 gibt es noch eine weiter Stelle der
Datenbank Inkonsistenz, die im Zusammenhang mit der erweiterten CD-Rom Support Funktion
steht. Wird eine CD-Rom Gruppe aktiviert, zu der aber die CD-Rom fehlt, wird bei der
Aktivierung der Areas die jeweilige Area NICHT aktiviert (fba=0). Bei einem nachträglichen
DLIMP1 Durchlauf werden aber die Areas durch die aktivierte Gruppe automatisch aktiviert und
erhalten eine fehlerhafte Zuordnung (ParentID=72) wie es unter BugTrack
rep060911.023
bereits umfassend beschrieben wurde.
Erweiterung der Funktion FixDlimpW() um Reset all OwnIDs
(fba braucht hier nicht zusätzlich berücksichtigt werden).
Status: Fixed ab v1.15
[20.9.06]
DLIMP Erweiterung rep060920.025
Wenn in der DLIMP Admin Console nur Gruppen ohne dazugehörige Areas aktiviert werden sollen,
so muss derzeit noch über den Umweg
Block aktivieren, danach mühselig jede einzelne
Area wieder deaktiviert werden.
Erweiterung um die Funktion
Area aktivieren bei Gruppen.
Status: Added in v1.15
[20.9.06]
DLIMP Erweiterung rep060920.026
In der DLIMP Admin Console Anzeige wird die Zeile aufgrund der Anzahl der Informationen immer
enger. Umstellung der Aktionslinks um Symbole? i.e. Area aktivieren: +, Area deaktivieren: -
Block aktivieren: ++, Block deaktivieren: --, Edit: E; ähnlich zu phpBB2.
Ebenso Änderung der Status Spalte: Aktiv Häkchen, Inaktiv Kreuz, Aktivierungs Request Häkchen in
Klammern oder anderes Symbol.
Abb.2 DLIMP Admin Console mit Symbolen
Added in DLIMP Adminconsole Seite 1 + 2.
Status: Added in v1.15
[16.10.06]
DLIMP BugTrack rep061016.027
W3C html validation:
DLIMP Admin Console Anzeige Seite 2: W3C 0 errors, 9 warnings.
DLIMP Admin Console Anzeige Seite 3: W3C 2 errors, 6 warnings.
Nach ereg_replace(&,&,descriptions) auf Seite 2, 0 errors, 1 warning.
Nach Umstellung der Forms auf Seite 3, 0 errors, 1 warning.
Seite 1, 0 errors, 1 warning.
Status: Fixed (ab v1.15)
[18.10.06]
DLIMP BugTrack rep061018.028
see also DLIMP BugTrack
rep060822.015 vom 22.8.06
Nach Studium der Maximus 3.xx Doku fiel auf, dass die Maximus FileArea Definition
einen Parameter
Type CD kennt mit dem CD Rom FileAreas gegenüber Maximus
identifiziert werden. Dieser Parameter könnte auch durch DLIMP zur Identifizierung
von CD-Rom Areas verwendet werden. Der Parameter Type wird bislang übersprungen.
Status: Added in v1.15
[20.10.06]
DLIMP BugTrack rep061020.029
includes/constants.php Parameter:
// MXTYPE 0=ASCII filearea.ctl, 1=binary FAREA.DAT
define('MXTYPE',0);
gibt vor, dass eine Konvertierung der binären FAREA.DAT möglich sei.
Dem ist aber so nicht. Bislang wird der Wert MXTYPE auch nicht weiter geprüft,
sondern es wird angenommen, dass immer die ASCII Datei FILEAREA.CTL zum Auslesen der
Maximus FileAreas verwendet wird. Zwar liegen einige Daten im ASCII Format vor:
Bsp.: W95GRF Q:\WIN95\grafik\ Privil Win95:_Grafik
aber das betrifft "nur" den FileAreaTag, den Pfad, die Permissions und die
Beschreibung, nicht aber eine mögliche FileDivision Gruppenzuordnung. Hier ist
auf alle Fälle noch Nacharbeit notwendig. Entweder in Form einer Umsetzung
oder zumindest einer Überprüfung des Werts MXTYPE und ggf. einer Stop Meldung
dass die Funktion des Einlesens der binären FAREA.DAT derzeit noch nicht implementiert
ist.
MXTYPE wird nun abgefangen. Binary FAREA.DAT wird derzeit noch nicht unterstützt.
Status: Added in v1.16
[20.10.06]
DLIMP BugTrack rep061020.030
Durchreichen von Fehlermeldungen bis zum Programmende ist derzeit noch nicht implementiert.
Fehlermeldungen in der Konfiguration werden schlimmstenfalls übergangen.
Im Hinblick auf die fehlende FAREA.DAT Verarbeitung sollten die 3 Hauptverarbeitungsschritte
übersprungen werden.
error = 0
proc.1.begin
if fehler
error = 1
proc.1.end
proc.2.begin
if !error
*proc 2 ausführen
...
if fehler
error = 87
endif
proc.2.end
usw.
Abschluss:
if error
echo FATAL ERROR: fehlernummer
endif
ggf. abgeschlossene Teilroutinen in Funktionen() fassen.
Status: Added in v1.15
[24.10.06]
DLIMP Erweiterung rep061024.031
PHPNUKE Tabelle wurde für die Simple Downloads Permissions um die Spalte PERM
erweitert. Bislang kann die Tabelle nur über die MySQL Admin Console nacheditiert
werden.
Hinzufügen der Editierfunktion für die Filebase Permission Guest oder Registered User
in der DLIMP Admin Console Seite 1.
In der Umsetzung sind nachfolgende Änderungsmöglichkeiten nun möglich:
- Einzelne FileArea: Wechsel zwischen Gastzugang erlauben, nur registrierte Benutzer erlauben
- Alle FileAreas einer Gruppe: Gastzugang erlauben, nur registrierte Benutzer
- Alle FileAreas: Gastzugang erlauben, nur registrierte Benutzer
Status: Added in v1.16
Switch zu Version 2.00rc1
Erstellung einer Upgrade Prozedur zum automatischen Upgrade der Datenbank Strukturen.
Anders als in PHPNUKE muss die Upgrade Prozedur ohne Output Buffering arbeiten.
Durch die Notwendigkeit mainfile.php in das Sktipt einbinden zu müssen, wurde das
Output Buffering immmer enabled. Das zwang mich die mainfile.php Prozedur in modifizierter
Fassung komplett in das Upgrade Skript mit aufzunehmen.
Während die modifizierte Downloads Version in DLIMP v1.xx optional war, ist nun die
modifizierte Downloads Version integraler Bestandteil des DLIMP v2.00 Pakets.
DLIMP / DLTIC / Downloads ist nun angepasst an die Unterstützung mehrerer physikalischer
Laufwerke.
Ggf. müssen weitere Programme und Tools an das neue Filelink Format ( [/basepath/] drive/areapath/ )
angepasst werden.
i.e. BBS2WEB, BBS2WEB.INI, FileLinkPath=...
Zur Unterstützung mehrerer Laufwerke unter BBS2WEB müsste noch MapDrive= herangezogen werden:
Sample BBS2WEB.INI
MapDrive=Q: Q/
MapDrive=D: D/
FileLinkPath=/phpnuke/download.php?f=
[30.10.06] DLIMP / DLTIC v2.00rc1 BugTrack rep061030.032
Upgrade v2.00rc1, BBS2WEB.INI Modifikation MapDrive=Q: Q/ und FileLinkPath=/phpnuke/download.php?f=
liefern entgegen der Beschreibung als Filelink
/phpnuke/download.php?f=/q/files/irgendwas.txt
^.... ein Backslash zu viel ...
Mit der oben aufgeführten Methode sind keine mehrfachen Laufwerkszuordnungen
unter BBS2WEB möglich, da MapDrive aufgegeben werden musste und auf
FileLinkPath=/phpnuke/download.php?f=q
erweitert werden musste damit es funktioniert.
Der FileLink muss also statt drive/path/file auf /drive/path/file mit zusätzlich
vorangestelltem Slash erweitert werden.
Damit der Anfang des Links eindeutig als Laufwerkskennzeichnung identifiziert werden kann
muss eine zusätzliche Erweiterung eingeführt werden:
i.e. /drv_Q/path/file
wobei /drv_ als reservierter Parameter für die Laufwerkszuordnung anzusehen ist.
| dlimp1 | checked |
| dlimp2 Part 1 | checked |
| dlimp3, func_dli | checked, fixed |
| download | checked, fixed |
| fetch | checked |
| modules/downloads/index | checked |
| apache | checked, fixed |
| dltic1 | checked |
| dlimp2 Part 2 | checked |
| dltic3 | checked, fixed |
| upgr1to2 | checked, fixed, added file version# fix |
Status: Fixed in v2.00rc1
[31.10.06]
DLIMP/DLTIC BugTrack rep061031.033
Minor changes in Version() Ermittlung
- Standard Fnews, Gnews, Embbs, Embul handling: #.## aus Dateiname (volume.issue).
- Verbesserte v#.# Erkennung.
- Wenn keine Versionsnummer gefunden wurde und Datei Extension numerischen Teil enthält,
Fallback zu x##
- Unterscheidung zwischen # Versionsnummernverweis und Texttrenner
- Entschärfung des "Z2" Filters durch Reduzierung auf "Z2PNT"
- TAG und DAY Keywords Erkennung, Ermittlung des Jahrgangs durch Filedatum
Zahlen wie 95, 97, 98 (Win95, W97, Windows98) werden vor Versionsermittlung gefiltert. Das führt dazu dass Nodelisten und
Pointlisten mit Tagesnummern #95, #97, #98 keine Versionsnummer erhalten. Durch die Fallback Methode
erhalten diese Dateien nun zumindest eine #9x Versionsnummer.
Als letzte Fallback Methode kommt nun das Filedate zum Einsatz sofern es ermittelt werden kann aus
dem dann das Datum ##.##.## die Versionsnummer ergibt (i.e. Filelisten und andere Files ohne Versionsangaben).
version() v2.05, Vollupdate in Upgr1to2 eingebaut, Überarbeitung sämtlicher alten Einträge.
Status: Added in v2.00rc1
[31.10.06]
DLIMP/DLTIC BugTrack rep061031.034
Für das Upgrade der DLIMP/DLTIC Version von v1.xx auf v2.00-rc1 gibt
es mittlerweile eine Upgrade Prozedur. Dabei werden die notwendigen Tabellenerweiterungen
und Modifikationen mittels eines Scripts durchgeführt. Als Basis dient eine
unter PHPNUKE 7.6 installierte DLIMP/DLTIC Fassung v1.14.
Da von dem Ursprungspaket v1.01, v1.02 bereits auf die Version v1.14 eine Anzahl
von Änderungen durchgeführt wurden, die aber in der Upgradeprozedur
unberücksichtigt blieben, ist jetzt beim Versuch der Erstellung einer Installationsprozedur
das Problem aufgetaucht:
Auf welche PHP, PHPNUKE, DLIMP/DLTIC Version setzte ich die Installation auf?
- Wie kann ich die unterschiedlichen PHPNUKE Versionen berücksichtigen?
- Was habe ich zu berücksichtigen? (i.e. geänderte Tabellenstruktur? geändertes Permissionssystem?)
Was bei der Upgrade Prozedur noch durch Annahmen vorrausgesetzt werden konnte, fehlt jetzt
bei der Installationsprozedur völlig.
Nach meinem Kenntnisstand gab es alleine zwischen PHPNUKE v7.00 und v7.60 eine massive
Strukturänderung bzgl. Admin Zugriff.
In einer Testinstallation konnte ich beobachten, dass die DLTIMP1 Prozedur mit einer früheren
PHPNUKE Version nicht zurecht kam weil mit einem neueren Securityzugriff auf das alte Securityschema
zugegriffen werden sollte und diese PHPNUKE Version die weiteren Dienste versagte.
Bei einem Versuch von PHPNUKE 7.6 auf eine höhere Version umzustellen bin ich gescheitert.
Beim anschliessenden Recovery des Ausgangszustands (PHPNUKE v7.6) waren allerhand Änderungen
an der Datenbankstruktur rückgängig zu machen.
Eine einfache Installation mittels SQL Script sehe ich als schwierig an, auf die jeweilige
Umgebung eine passende Berücksichtigung zu finden (wie können die DLIMP/DLTIC Scripts an die
geänderte Umgebung angepasst werden?!? oder anders gefragt: was muss in die Scripts zusätzlich
hinzugefügt werden, damit die Scripte Versionsunabhängig laufen?!?).
Ein Reset zum Grundzustand wäre dagegen eher simple (drop zusätzliche Tables, drop Spalte
PERM in Tabelle _categories).
Nach erster Durchsicht der Structures Änderungen von PHP-NUKE 7.0 bis einschl. 7.8
sind essentielle Änderungen die Downloads Section betreffend nur beim Upgrade
7.4 auf 7.5 vorgenommen worden:
ALTER TABLE nuke_authors DROP radmindownload
Demnach wären Änderungen nur im Downloads Modul und da auch nur im Zusammenhang
mit Admin-Level Abfragen zu berücksichtigen. Der Parameter RADMINSUPER wird aber
bereits seit v7.0 unterstützt.
Da Admin Level in allen Versionen mit der Funktion is_admin() abgefragt wird, bleibt nur
der Unterschied pre-7.6 hardcoded
admin.php vs. ab 7.6 per config.php definiertes
[admin_file].php zu berücksichtigen.
if php-nuke-version < 7.6 then
admin_file = admin
endif
In diesem Zusammenhang sind alle DLIMP Admin Consolenscripte nun an Pre-v7.6 Unterstützung
angepasst.
Ebenfalls überarbeitet wurde das komplette PHP-NUKE Downloads Modul (das seit DLIMP/DLTIC v2.00
integraler Bestandteil des DLIMP Pakets ist) für Abwärtskompatibilität
zur PHP-NUKE Version 7.6.
Da dieses auf zentrale PHP-Nuke Scripte zurückgreift, musste ich auch 3 zentrale PHP-Nuke Scripte
admin.php
header.php
mainfile.php
anpassen, da sonst das Downloads Modul oder aber das gesamte PHP-Nuke < v7.6 sonst nicht
mehr gelaufen wäre.
Diverseste Fehlermeldungen wie:
PHP Fatal error: Call to undefined function: stripos_clone() in ...\phpnuke\admin.php on line 33
PHP Fatal error: Cannot redeclare opentable() in ...\phpnuke\themes\Ambrosia\theme.php on line 22
PHP Warning: imagecreatefromjpeg(images/code_bg.jpg): failed to open stream:
No such file or directory in ...\phpnuke\mainfile.php on line 1150
und Folgefehler
PHP Warning: head(): Failed opening 'includes/ipban.php' for inclusion
waren aufgrund von Änderungen und Erweiterungen ab PHP-Nuke v7.3 veranwortlich.
Die im Paket enthaltenen Scripte sind um Versionsabhängige Unterscheidungen angepasste
v7.6 Scripte die abwärtskompatibel zu PHP-Nuke Versionen kleiner als 7.6 sind. Laufen
also sowohl unter PHP-Nuke v7.3 alsauch unter v7.6.
Wird ein Upgrade von beispielsweise v7.3 auf v7.4 oder v7.5 vorgenommen, müssen anschliessend
die 3 oben genannten Scripte aus dem DLIMP v2.00 Paket wieder drüberinstalliert werden.
Ab PHP-Nuke v7.6 wird kein Update dieser 3 Scripte mehr benötigt. Ein Merge der Language Files
ist aber in allen Fällen nötig, da die Nuke Upgrades die vorherigen Language Files
in aller Regel überschreiben. Zum Merge der Language Files die jeweilige Datei
_lang-[sprache]-DIFF.php
in die neue PHP-Nuke Sprachdatei (Dateien ggf. vorher mit dem Tool unix2dos unter Windows
vom Unix in Dos Line-Endings konvertieren, i.e. for %a in (*.php) do unix2dos %a)
lang-[sprache].php
einpflegen.
Bugfix Downloads: Unter Guest Account konnten Dateien trotz aktiviertem Permission System
gedownloadet werden. Ursache war an einer Stelle die Abfrage auf
isset(user) statt mit
der Funktion
is_user(user). Weitere kleine Bugfixes.
Die Basis für eine Installationsprozedur ist nun gelegt. Unter PHP-Nuke v7.3 erfolgreich
getestet. Ein Abschlusstest mit einem Upgrade von PHP-Nuke von v7.3 auf v7.6 ist gleichfalls
erfolgreich verlaufen. Anschliessend haben noch sämtliche DLIMP Funktionen wie gewünscht
ihren Dienst verrichtet. Der Abschlusstest unter der PHP-Nuke Version 7.6 ist nun nach
sämtlichen Anpassungen für die Version 7.3 noch immer lauffähig.
Status: Fixed in v2.00-rc1
[01.11.06]
DLIMP/DLTIC BugTrack rep061101.035
Nach Umstellung des Filelink Handlings unter
rep061030.032 wurden zwar Downloads
bei angemeldeten Usern durchgeführt. Aber der Download unter dem Guest Account meldete immer einen
"File not found" Error.
Die Link Überprüfung ergab, dass die gelieferte URL zwar korrekt war, damit aber in fetch.php
keine file_exist() Abfrage durchgeführt werden konnte. Erst mit der Rückübersetzung
der URL in einen physikalischen Link wäre die file_exist() Abfrage möglich.
Das Problem muss schon seit längerer Zeit bestanden haben, und zwar genau seit der Einführung
der Maskierung des Download Pfads.
(siehe Section 8, [12.2.06]
Hinweis zur FileBase Security).
Status: Fixed in 2.00rc1
[03.11.06]
DLTIC BugTrack rep061103.036
Beim Import von Files mit DLTIC v2.00-rc1 resultiert der erzeugte Filelink einen
defekten Link. Aus dem Format
/drv_#/path/file wird
/drv_file
ohne Path und Drive (areapath undefined).
In der entsprechenden Routine wurde PATH statt AREAPATH verwendet, was im weiteren
Verlauf die fehlende Verzeichnis Information bewirkte.
Status: Fixed in 2.00-rc1
[07.11.06]
DLTIC Erweiterung rep061107.037
In der DLIMP Admin Console auf der Seite 2, nach Import der Allfix FileArea Konfiguration, besteht die Möglichkeit
AreaTags von Allfix nach PHP-Nuke Downloads zu übernehmen. Wenn man 100 und mehr Areas nachbearbeitet
wird das zu einem mühseeligen Geschäft. Hilfreich wäre für die Funktionen:
[ Kopiere AFIX nach FileBase AreaTag ]
[ Kopiere AFIX nach FileBase Area Beschreibung ]
eine Erweiterung auf die Gruppe durchzufüren. Alle Allfix AreaTags der Gruppe, dessen FileArea
gerade bearbeitet wird sollen ebenfalls die AreaTags von Allfix übernehmen.
Die gleich Funktion betrifft die Beschreibungen.
Die Funktion wirkt sich nur auf aktivierte FileAreas aus. Inaktive Areas werden übersprungen und müssen
später ggf. nachbearbeitet werden.
(Evtl. noch Problem dass TITLE statt DTITLE upgedatet wird?!? DTITLE wie DisplayTITLE?)
In den Scripten scheint es teilweise noch Unstimmigkeiten bzgl. der zu verwendenden Titel (AreaTag) Angabe
zu geben. Auf Seite 2 der DLIMP Admin Console müsste vermutlich noch eine dritte AreaTag Angabe
erfolgen um eine "eindeutige" Definition der verwendeten und angegebenen AreaTags zu erhalten.
Derzeit werden 2 AreaTag Angaben angezeigt. 1. der Allfix importierte AreaTag (dlimp2::areatag),
2. Der aktive Downloads AreaTag (dlimp::title).
Es fehlt also noch der ursprüngliche Maximus AreaTag (dlimp::maxareaname), der nicht unbedingt mit dem
aktiven FileAreaTag übereinstimmen muss, da dieser auch geändert werden kann. Weiterhin
kann es bei den unten in der Tabelle mit (
1) markierten Einträgen zu abweichenden
Einträgen kommen, so dass der aktuelle AreaTag nicht an allen Scriptstellen korrekt
wiedergegeben wird.
Updated dlimp2.php und downloads index.php.
In den Tabellen gibt es mehrere Stellen an denen der Titel (AreaTag) definiert wird:
| Tabelle | Spalte | Beschreibung |
| tempimp | title | Wird für Kategorienamen zweckentfremdet |
| | dtitle | Wird für Kategorienamen zweckentfremdet |
| dlimp | title | (1) Primärer Downloads Filearea Name, upper() formatiert |
| | dtitle | (1) Displayname des Downloads Filearea Name, Wird beim erstmaligen Erstellen erzeugt |
| | maxareaname | Orginal Areaname Bezeichnung aus der Maximus Konfiguration, upper() formatiert |
| | dmaxareaname | Orginal Displayname der Areaname Bezeichnung aus der Maximus Konfiguration |
| | phpnareaname | (1) Orginal Downloads Filearea Name |
| dlimp2 | areatag | Orginal AreaTag der Allfix Tic Filearea |
| categories | title | (1) Downloads Filearea Name |
(
1)
bei Änderung des Downloads Section Filearea Namens muss dieser Eintrag aktuallisiert werden.
Status: Added in 2.00-rc1
[10.11.06]
DLIMP BugTrack rep061110.038
DLIMP Admin Console Seite 2, Änderung des AreaTags einer Area.
Änderungen werden in dlimp::phpnareaname durchgeführt. Nicht aber in
den anderen 3 weiteren aktiven Title/AreaTag Definitionen:
dlimp::title
dlimp::dtitle
categories::title
DLIMP2.PHP in Funktion DLIMPEDITSAVE() wird die manuelle Änderung des Areanamens für
die Downloads Section nur im Feld
phpnareaname aktuallisiert. Die anderen Felder müssen
aber auch upgedatet werden.
Nach Korrektur erscheint nun in der DLIMP Admin Console auf Seite 2 der korrekte aktuelle AreaTag.
Ebenso unter Downloads in der Auflistung der Areas alsauch in der Detailansicht.
Status: Fixed in v2.00-rc1
[10.11.06]
DLIMP BugTrack rep061110.039
Nach Upgrade von PHP-Nuke v7.3 auf v7.6 und anschliessendem Überkopieren des
DLIMP Update Pakets fehlten sowohl im Admin Modus (PHP-Nuke Admin Consolen Aufruf)
alsauch unter Downloads im Usermodus einige Sprachelemente.
Sprachdateien ins Upgradepaket mit eingebunden.
Status: Fixed in v2.00-rc1
[10.11.06]
DLIMP BugTrack rep061110.040
Trotz neuer Version() Funktion mit jeder Menge Fallback Optionen tauchen in der Datenbank
2 Einträge ohne Versionsnummern auf (EZR.RAR, EZACE.RAR).
Bei der Übergabe des Filelinks gab es ein weiteres, bislang unberücksichtigtes
Format. Weiterhin gab es eine PHP Merkwürdigkeit: Codeschnipsel der bislang ohne Probleme
und ohne Beanstandungen durchlief, verursachte nun einen Parse Error (Suche nach ':/' bzw. ':\').
String nun mit Hilfe Chr() Funktion "maskiert".
Status: Fixed in v2.00-rc1
[10.11.06]
DLTIC BugTrack rep061110.041
Wöchentliche Updates. Eine Datei wurde in der Files.Bbs mit "_" (Unterstrich, Underscore)
geschrieben. Beim TIC Import wurden die "_" nicht in Leerzeichen gewandelt. Dadurch wurde
die gleiche/selbe Datei ein zweites mal in die Datenbank eingetragen.
Status: Fixed in v2.00-rc1
[14.11.06]
DLIMP/DLTIC BugTrack rep061114.042
Tabelle
_downloads_dlicfg: Version# missing bei PHP-Nuke v7.3 nach v7.6 Upgrade Test.
Vermutlich ist das darauf zurückzuführen, dass beim Test die Installationsroutine
noch nicht existierte. Dass die Tabellenerstellung noch manuell mit einem SQL Script erstellt
wurde. Beim PHP-Nuke Upgrade von 7.3 nach 7.6 kommt jedenfalls keine DLIMP/DLTIC Installations-
oder Upgradeprozedur zum Tragen, so dass auch eine Versionsnummer in der Tabelle DLICFG nie
eingetragen wurde.
Status: Fixed in v2.00-rc1
[20.11.06]
DLIMP/DLTIC Erweiterung rep061120.043
Installations- und Update Routinen sind für das v2.00-rc1 release schon fertiggestellt.
Zusätzlich zum Installations- und Updatepaket bedarf eines Updates der Language Files.
Dies sollte im Zuge des Installations- oder Upgrade Scripts erfolgen.
Allerdings gibt es noch reichlich Schwierigkeiten bei der Umsetzung.
Die PHP eigenen Array Funktionen bieten nicht die Option, die dazu nötig wäre um
schnell und einfach ein Merge zweier Language Files durchzufüren. PHP liefert zwar
eine Array Merge Funktion, die ist aber für die PHP-Nuke Language Files völlig
ungeeignet.
Bislang sind mehrere Versuche gescheitert, ein halbwegs lauffähiges Update Script zu
entwickeln, um aus einem Basis Language File und einem zweiten zusätzlichem Updatefile
ein neues Resultat zu erhalten, in dem sämtliche neueren Werte übernommen, ersetzt oder angefügt
werden.
Mit einer Mischung aus Array() handling und manuellem Abgleich ist es nun endlich gelungen brauchbare
Ergebnisse bei einem Language File Merge zustande zu bekommen.
Status: Added to Setup routine in v2.00-rc1
[21.11.06]
DLIMP/DLTIC Erweiterung rep061121.044
Installations- und Update Routinen:
Laut Anleitung müssen bislang noch die Start Batches (dli1.cmd, dli3.cmd, dlt1.cmd, dlt3.cmd)
für die DLIMP und DLTIC Scripte
manuell editiert werden. Eine Möglichkeit wäre in der Setup Routine wie auch
schon die Language File Updates dies durch die Setup Prozedur automatisch erledigen zu lassen.
Eine Schwierigkeit gibt es dabei aber: Während die Language Files in der PHPNUKE Verzeichnisstruktur
liegen, muss das FBMAINT.200 Verzeichnis erst gesucht werden um die nötigen Änderungen vornehmen
zu können.
_SERVER["PATH"] liefert die Path Environment Variable. Mit Glück ist einer der Paths das
PHP Verzeichnis (Test auf
PHP.EXE).
_SERVER["DOCUMENT_ROOT"] liefert den Webserver Root. Parallel dazu müsste das FBMAINT.200
Verzeichnis zu finden sein (Test auf
DLIMP1.PHP).
Status: Added in v2.00-rc1
[21.11.06]
DLIMP/DLTIC BugTrack rep061121.045
PHP-Nuke v7.3: bei aktiviertem GFX Check wird kein Sicherheitscode angezeigt.
... und immer noch keinen blassen Schimmer wo es hängt ....
PHP GD Extension ist enabled (eine entsprechende Zeile aus PHP.INI auskommentiert kam auch
sofort die Meldung GD nicht verfügbar. Mit einem minimalistischen Testscript erscheint
auch eine Grafikausgabe. Nur nicht unter PHP-Nuke 7.3. Im v7.3 Basiszustand liefert die
Funktion aber eine Grafikanzeige, so dass die Änderungen an den v7.6 Scripten
bzgl. Abwärtskompatibilität mit den Problemen in Zusammenhang zu bringen ist.
Einen möglichen Lösungsansatz habe ich unter
Admin Security login jpeg not showing
(Beitrag von Darius) gefunden. Jetzt wird zwar die Grafik angezeigt, ein Login bleibt dennoch erfolglos: Login fehlerhaft ...
Beim Debuggen erscheint nach Aufruf
Your_Account:main() ein Code, der nach Ausführung des
Formscripts
Your_Account:login() bei der Parameterübergabe einen anderen Code liefert
als der in
Your_Account:main() angezeigte:
Bsp.: Aufruf
Your_Account:main(), Code Anzeige
449757. Nach Start des Formscripts
Your_Account:login() liefert die Parameterübergabe für den Code einen Wert
936535 und für den GFX Check übermittelten Wert
449757. Bei der
entsprechenden Abfrage ob beide Werte gleich sind, scheitert die Routine. Also muss bei der
Parameterübergabe irgendetwas schieflaufen oder der Wert für
random_num hat
in der Zwischenzeit gewechselt und auch der Übergabeparameter wurde modifiziert (??!?!?).
Des Rätsels Lösung:
Die ausgelagerte GFX() Routine enthielt nicht den Code zur Umwandlung für die
random_num.
require("config.php");
$datekey = date("F j");
$rcode = hexdec(md5($_SERVER[HTTP_USER_AGENT] . $sitekey . $random_num . $datekey));
$code = substr($rcode, 2, 6);
Die Code Anzeige durfte nicht den
random_num enthalten, sondern den Inhalt von
code.
Um die GFX Funktion nun Abwärtskompatibel zu erhalten müssen die GFX Abfragen der folgenden
Scripte angepasst werden:
phpnuke/admin.php
phpnuke/mainfile.php
phpnuke/blocks/block-login.php
phpnuke/modules/Your_Account/index.php
Ggf. muss die Download Routine mit dem Download Fetching Hack by MGCJerry für die
Codeabfrage angepasst werden, da diese Routine ebenfalls eine Funktion gfx(), allerdings ohne
code
Konvertierung enthält.
Code Change von
old => $content .= ""._SECURITYCODE.":
<img src='modules.php?name=Your_Account&op=gfx&random_num=$random_num'
border='1' alt='"._SECURITYCODE."' title='"._SECURITYCODE."'><br>\n";
nach
new => $content .= ""._SECURITYCODE.":
<img src='gfx.php?random_num=$random_num'
border='1' alt='"._SECURITYCODE."' title='"._SECURITYCODE."'><br>\n";
Downloads Security Code:
"modules.php?name=Downloads&d_op=getit" liefert ebenfalls keine Code Ausgabe.
[24.11.06] Downloads Securitycode System komplett überarbeitet und an das übliche Account Securitycode
System angepasst.
[27.11.06] Mit PHP-Nuke Versionen 7.3 bis einschl. 7.6 getestet.
Status: Fixed in v2.00-rc1
[27.11.06]
DLIMP/DLTIC BugTrack rep061127.046
Nach PHP-Nuke Upgrades (i.e. 7.3 nach 7.4, 7.4 nach 7.6 usw.) werden die DLIMP spezifischen Erweiterungen
überschrieben.
Wurde beispielsweise das DLIMP v2.00-rc1 Paket unter PHP-Nuke 7.3 installiert und wird nun ein PHP-Nuke
Upgrade auf v7.5 durchgeführt sind die Erweiterungen des DLIMP v2.00-rc1 Pakets verschwunden. Das betrifft
vor allem die Language Files. Aber auch das GFX System ist davon betroffen.
Upgrade Prozedur für PHP-Nuke Upgrades den DLIMP v2.00-rc1 Paketen hinzugefügt.
In allen Fällen muss nachdem alle PHP-Nuke Upgrade Aktionen durchgeführt wurden
das komplette DLIMP v2.00-rc1 Upgrade Paket
über das PHP-Nuke Paket überkopiert werden. Danach muss noch ein Language-Merge.Php
Script laufen gelassen werden, damit die Sprachdateien Erweiterungen wieder hinzugefügt werden.
Die Scripts SETUP.PHP oder UPGR1TO2.PHP aus den DLIMP v2.00-rc1 Paketen müssen allerdings nicht erneut
aufgerufen werden.
Status: Fixed in v2.00-rc1
Freigabe der Version 2.00rc1
-
Während die modifizierte Downloads Version in DLIMP v1.xx optional war, ist nun die
modifizierte Downloads Version integraler Bestandteil des DLIMP v2.00 Pakets.
- DLIMP / DLTIC / Downloads ist nun angepasst an die Unterstützung mehrerer physikalischer
Laufwerke.
- CD-Rom Filebase Unterstützung
- PHP-Nuke 7.3 bis einschl. 7.6 getestet
- Jede Menge Bugfixes
- Neues Link-Speicherformat (/drv_drive/path/file)
(siehe auch Report #019 vom 7.8.06 und Report #032 vom 30.10.06)
Beim Upgrade werden die Links automatisch konvertiert
- Neues DLIMP Admin Consolen Design
- Überarbeitetes DOWNLOADS Modul integriert
- GFX unter dem DOWNLOADS Modul ist integriert
- Simples Permissions System: 0=Guest allowed, 1=Registered Users only
Ggf. müssen weitere Programme und Tools an das neue Filelink Format ( [/basepath/] drive/areapath/ )
angepasst werden.
i.e. BBS2WEB, BBS2WEB.INI, FileLinkPath=...
Zur Unterstützung mehrerer Laufwerke unter BBS2WEB müsste noch MapDrive= herangezogen werden:
Sample BBS2WEB.INI
MapDrive=q: /drv_q/
MapDrive=D: /drv_D/
FileLinkPath=/phpnuke/download.php?f=
Die Downloads sind in der Downloads Section zu finden:
Downloads
