AMBROSIA60 Portal  

 
| | News | Sitemap | Startseite | Kontakt | Impressum |

Project: PHP-Nuke - 12. FileBase to Download Import - DLIMP, DLTIC Weiterentwicklungen, Fixes

AMBROSIA60-Portal  FileBase to Download Import Project



PHP-Nuke Download Section vs. FileBase
How to import from Filebase ...




Übersicht:
Start....Übersicht
Section 1....Analyse I, Filebase Synchronisation
Section 2....Umsetzung der Filebase Synchronisationsprozedur
Section 3....FileBase Import, Allgemeine Beschreibung
Section 4....Analyse II, Ticker Import
Section 5....Umsetzung des TIC Imports
Section 6....TIC Import, Allgemeine Beschreibung
Section 7....Einbindung DLIMP / DLTIC in die Maintenance
Section 8....Hinweis zur FileBase Security
Section 9....Übersicht und Status Gesamtprojekt
Section 10....References
Section 11....Download
Section 12....Weiterentwicklungen, Fixes




Top

  • 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)

  1. Ersetzung aller LIST() Aufrufe, Auflösung durch Einzelübergabe der Parameter (list() funktioniert nicht unter sämtlichen win32 Installationen)
  2. Fixed function getparentlink() für Anzeige mehrfacher Kategorie Ebenen
  3. 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
  4. 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.
  5. 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.
  6. Ä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 ...
  7. Ersatz für die A/D (Aufsteigend/Absteigend Sortierung) Anzeige mit sort-a.gif, sort-d.gif
  8. 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 ...
  9. 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:
  1. if exist(Drive)
  2. if exist(Path)
  3. if exist(Drive+Path+FILES.BBS)
  4. 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.

DLIMP Modelling
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
  1. Reset DBs
  2. Import 1 mit kurzer Groups.Lst (Categories: empty, Dlimp: parentId + OwnID all 0
  3. Aufruf DLIMP2 (383 Areas in Root, Cat A, Cat A1 Areas 2-8 C01-C07, Cat A2 Areas 2-63 CD101-CD162)
  4. Edit HomePage + BasePath, Save
  5. 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
  6. Block activate A2 (op=ChgDLIMPStatus&tid=0&l1=3)
    Status wie zuvor, zusätzlich ipa=2 bei aktivierten Areas A2
  7. 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.
  8. Aktivierung Group A (op=ChgDLIMPStatus&tid=0&l1=1)
    Categories und Dlimp unverändert (ausser ipa=2 bei aktivierter Group A).
  9. 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.
  10. Austausch Groups.Lst Kurzversion gegen Vollständig
  11. 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 !!!)
  12. Aufruf DLIMP2 Anzeige
    Aktive Areas A1 PID=1 ID=72 ALLE!, Areas A2 PID=9 ID=72 ALLE!
  13. 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.

DLIMP Symbole
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(&,&amp;,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.
dlimp1checked
dlimp2 Part 1checked
dlimp3, func_dlichecked, fixed
downloadchecked, fixed
fetchchecked
modules/downloads/indexchecked
apachechecked, fixed
dltic1checked
dlimp2 Part 2checked
dltic3checked, fixed
upgr1to2checked, 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:
TabelleSpalteBeschreibung
tempimptitleWird für Kategorienamen zweckentfremdet
 dtitleWird für Kategorienamen zweckentfremdet
dlimptitle(1) Primärer Downloads Filearea Name, upper() formatiert
 dtitle(1) Displayname des Downloads Filearea Name, Wird beim erstmaligen Erstellen erzeugt
 maxareanameOrginal Areaname Bezeichnung aus der Maximus Konfiguration, upper() formatiert
 dmaxareanameOrginal Displayname der Areaname Bezeichnung aus der Maximus Konfiguration
 phpnareaname(1) Orginal Downloads Filearea Name
dlimp2areatagOrginal AreaTag der Allfix Tic Filearea
categoriestitle(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






Top


AMBROSIA60 News RSS 2.0 feed [Valid RSS]
Future4Fido
[ Join Now | Ring Hub | Random | << Prev | Next >> ]

©WebRing Inc.
FidoNet World Wide WebRing
<< Prev | Ring Hub | Join | Rate| Next >>
www.CAcert.org
SSL Powered
© 2003-2017 by Ulrich Schroeter Besucherzaehler