PHP-Nuke Download Section vs. FileBase
How to import from Filebase ...
- Section 2 - Umsetzung der Filebase Synchronisationsprozedur
Erster Screenshot von der DLIMP PHP-Nuke Admin Console:
Und hier der zweite Versuch mit einer geordneten Liste (Screenshot DLIMP PHP-Nuke Admin Console v0.2):
Nach Umstellung der Datenstruktur Und Anpassung der Import Routing Definition und des Admin Modules um eine
Reihenfolgen Steuerung vornehmen zu können, hier der dritte Screenshot (DLIMP PHP-Nuke Admin Console v0.3):
Funktionen, die in der Admin Konsole bereits umgesetzt sind:
- Änderung des importierten Filearea Titels für PHP-Nukes Download
Categorie oder Download Area.
- Änderung der Reihenfolgen der Kategorien
- Änderung der Reihenfolgen der Download Areas
- Änderung der FileArea zu Kategorie Zuordnung
- Aktivierung/De-Aktivierung von einzelnen oder allen Download/Fileareas
- Zwischenspeicherung der obigen Änderungen
- Fix von Reihenfolgen Konflikten
Die nächste Aufgabe wird sein:
- Speicherung der DLIMP Konfigurationen zum Download Bereich
Damit wäre die Admin Konsole so ziemlich abgeschlossen.
Eine Erweiterung der Groups Import Routine liefert nun zusätzlich die Anzahl der Files in jeder Filearea
damit "tote Areas" bereits in der Bearbeitung identifiziert werden und deaktiviert werden können.
Screenshot DLIMP PHP-Nuke Admin Console v0.31:
FILESIZE- und FILECRC32- Ermittlung der in den FileAreas gefundenen FILES.BBS für die spätere Fileimport Routine
der DLIMP Tabelle hinzugefügt. Die Groups Import Routine liefert nun bereits eine Anzeige über die
FILESIZE und FILECRC32 der Datei FILES.BBS der jeweiligen Filearea.
ACHTUNG: PHP benötigt hierfür die Extension extension=php_mhash.dll ! (edit php.ini, enable php_mhash.dll)
Nach Neustart des Apache2 kam hier noch die Fehlermeldung: impmhash.dll not found.
Da bei PHP4 wohl die angeforderte Datei nicht existiert, aus einem PHP5 Test aber sehr wohl die impmhash.dll
Datei zu finden war, habe ich die Datei PHP4 einmal untergeschoben - und es lief !!!
Nach Abschluss und Speicherung der DLIMP Konfiguration werden die Daten in die *_CATEGORIES Tabelle eingetragen.
Sowohl in der DLIMP Konfigurations Oberfläche, alsauch in der Download Section tauchen die zuvor transferierten
Fileareas nun als Categories auf. Screenshot von der Download Section nach Speicherung der Konfiguration
von DLIMP PHP-Nuke Admin Console v0.31:
[10.7.2005]
Da ich momentan beruflich ausgelastet bin, geht die DLIMP Entwicklung nur schleppend voran.
Die Demo Version bekomme ich momentan auf die Schnelle nicht zum Laufen (zu viele Admin-Abhängigkeiten).
Trotzdem möchte ich heute hier schon den Algorythmus für den Fileimport (Step 4) vorstellen:
Involvierte Tabellen:
*_downloads_downloads
*_downloads_dlimp
neue Tabelle:
*_downloads_dlmgmt
Die neue Tabelle *_downloads_dlmgmt wird benötigt um die Area Verwaltung auf neue und gelöschte
Files zu ermöglichen. Man könnte die Tabellenstruktur *_downloads_downloads erweitern. Das hätte
aber zum Nachteil, dass bei einem Update die Tabellen nicht mehr kompatible wären. Daher habe ich
mich entschlossen die Verwaltung in eine zusätzliche Tabelle auszulagern.
Tabellenstruktur _downloads_dlmgmt
l1 Verweis auf _dlimp L1
l2 Verweis auf _dlimp L2
lid Verweis auf _downloads lid
fe File Exists? True/False
Der Algorythmus in groben Zügen:
/************************************************************************/
* Copyright (c) 07/2005, All rights reserved by U.Schroeter
* http://ambrosia60.dd-dns.de
* This program is free software. You can redistribute it and/or modify
* it under the terms of the
GNU General Public License as published by
* the Free Software Foundation; either version 2, June 1991 of the License.
/************************************************************************/
function Main()
for i = 1 to max(l1) // l1 aus *_dlimp
for j = 1 to max(l2) // l2 aus *_dlimp
workarea = area(l1,l2)
oldcrc = workarea[crc] // aus tabelle *_dlimp
crc = check files.bbs of area workarea // path aus tabelle *_dlimp
if crc = oldcrc
* keine Änderung, skip
else
updatearea(workarea,l1,l2) // update einzelner Area
endif
next
next
* end function main
function updatearea(workarea,l1,l2)
reset_dlmgmt(l1,l2) // downloads, alle Files zuruecksetzen
flag = False // als waeren sie nicht mehr vorhanden
q0 = 0 // danach mit aktuellem Status reaktivieren
q1 = array() // -> FileExists -> Yes
read file workarea-path\files.bbs
do while not eof()
line = readnextline(files.bbs) // Files.Bbs Zeile fuer Zeile lesen
if (not flag)
if (line position 1 <> " ") // naechste zu analysierende Datei
filename = left(line,bis " ") // faengt an Position 1tem Zeichen an
url = baseurl + workarea-path + filename // Url fuer Update mit Datenbank generieren
found = sqlquery(downloads, url) // Datei in DB vorhanden?
if (not found) // Nein: neue Datei gefunden, einspeichern
* neuer File
Flag = True
q0 = 0
q1[q0] = line
else // Ja: Datei bereits vorhanden, Status auf
Flag = False // FileExists True setzen
update(dlmgmt,lid,FE=True)
endif
else
* skip
endif
else
if ((line position 1 <> " ") or (empty line)) // Abbruchbedingung fuer Datensammlung
* vorheriges gefundenes File, infos in q1 array abarbeiten, speichern, FE = True
q0 = 0
q1 = array() // Infos zu neuer Datei zusammenstellen
filename = left(line,bis " ") // und speichern
url = baseurl + workarea-path + filename
found = sqlquery(downloads, url)
if (not found)
* neuer File
Flag = True
q0 = 0
q1[q0] = line
else
Flag = False
update(dlmgmt,lid,FE=True)
endif
else
q0 = q0 + 1
q1[q0] = line
endif
endif
enddo
* check dlmgmt
result = sqlquery(dlmgmt, l1=l1, l2=l2, not FE)
* alle jetzt gefundenen Records sind nicht mehr in der Filebase vorhanden => Löschen
* end function updatearea
function reset_dlmgmt(l1,l2)
update * of _dlmgmt value FE=False
* end function reset_dlmgmt
/************************************************************************/
Anmerkung: URLs mit Files sollten in _DOWNLOADS alle lower() or upper() gespeichert werden!
[19.7.05]
Die erste Einspeicherung von Files in die Downloads Sektion ist geglückt.
Jetzt bedarf es nur noch einiger, kleinerer Korrekturen.
[20.7.05]
Updating ohne Dupes funktioniert ebenfalls.
Als Gimmick habe ich eine Versions Extraktion eingebaut, da die Downloads Sektion ein
Feld
Version anbietet.
Aus den ersten 2 Description Zeilen des Files.Bbs Verzeichnisses zu einem File wird versucht
eine Versionsangabe zu extrahieren. Zunächst wird im Dateinamen nach Versionsnummern gefandet,
die ebenfalls in den nachfolgenden 2 Kommentarzeilen auftauchen können. Wird eine Zahlenkombination
gefunden, ist mit grösster anzunehmender Sicherheit dies die Versionsangabe.
Eindeutiger wird es bei Angaben wie v1.00, 1.0-rc2, 0.9-beta2
Die Titel Angabe beim Import habe ich dahingehend noch einmal korrigiert, dass teilweise
nur mit der ersten Zeile der Description kein eindeutiger Dateititel erstellt werden konnte.
Daher habe ich mich entschlossen, für den Titel eine Kombination aus Dateiname, Beschreibungstext
aus der ersten Zeile der Files.Bbs Beschreibung heranzuziehen.
Da in den Testversuchen einige Dateien zwar noch in den Files.Bbs Files enthalten waren, die aber
tatsächlich in der Filebase fehlten, habe ich an entsprechenden Stellen eine Abfrage
if fileexists(importfile) hinzugefügt. Nun werden weder Dupes noch fehlende Dateilinks
nach PHP-Nuke Downloads Sektion importiert.
PNTCV551.ARJ [00] PntlCvrt-Converter all formats v5.51
+Fake-, Boss-, Point, Poss-Format
+conversions between all formats
+all formats conditional split
+into subsegments, with Nodelist lookup
+Fixes: Zones > 5, ?-handl, Pvt-handl
+Multiple Regions, multi zone aware
+ y2k tested
+Fixed Pvt IP-Only Nodes handling
+Multiple segments input *.upd
+NPK mode for central inbound conversions
+Add auto strip zip code and simple
+dupe pointnumber test and fix.
+new Index Level G for UPDCHCK >=5.50
wird zu:
Datei: PNTCV551.ARJ
Titel: PNTCV551.ARJ, PntlCvrt-Converter all formats v5.51
Version: 5.51
Description: PntlCvrt-Converter all formats v5.51 Fake-, Boss-, Point, Poss-Format conversions between all formats
all formats conditional split
into subsegments, with Nodelist lookup
Fixes: Zones > 5, ?-handl, Pvt-handl
Multiple Regions, multi zone aware
y2k tested
Fixed Pvt IP-Only Nodes handling
Multiple segments input *.upd
NPK mode for central inbound conversions
Add auto strip zip code and simple
dupe pointnumber test and fix.
new Index Level G for UPDCHCK >=5.50
[21.7.05]
Update funktionierte prinzipiell. Im besonderen gab es aber ein Problem.
In der Area
Service sollte die Pr24diff.203 aka .z03 eingespeichert werden.
Es gab aber bereits ein File PR24DIFF.Z03 aus dem Jahre 2004 das bei
der Überprüfung des Filenamens gefunden wurde. Aufgrund des Algorythmus, der bislang
nur den Dateinamen prüft, wurde nicht erkannt, dass es sich hierbei um ein anderes File handelt,
als dasjenige, das eingespeichert werden sollte. Demzufolge wurde die Datei nicht in die Datenbank
transferiert und die "alte" Datei auch nicht entfernt.
Der alte Link hätte zwar weiterhin funktioniert, aber der Titel und die Beschreibung wurde
nicht aktuallisiert, so dass unter der Beschreibung der Datei aus 2004 nun die Datei vom
heutigen Tag im Zugriff stand.
Nun wird eine Prüfung auf Dateiname
und Titel durchgeführt. Da das eigentliche Filedatum
nicht registriert wird, könnte allenfalls die Filesize noch als Unterscheidungskriterium
herangezogen werden. Das ist aber auch zu unsicher, da sich auch die Filesize nicht zwangsläufig
ändern muss. Status:
fixed.
Das Entfernen alter Links funktionierte dagegen auf Anhieb einwandfrei.
[23.7.05]
Ein weiterer Problempunkt bei der Erkennung ob
NEU oder
ALT ist gegeben, wenn die importierten
Files einen statischen Namen und eine statische Beschreibung enthalten. Beispiel Area NODELIST-LAST:
Files.BBS Eintrag
NODELIST.ZIP [00] Aktuellste Fidonet NODELIST ZIP
NODE0002.ZIP [00] Aktuellste Fidonet NODELIST.###
+fuer CDP Freq.
+Magic 'NODE0002'
wird zu
Filename Title
------------- ----------------------------------------------
NODELIST.ZIP NODELIST.ZIP, Aktuellste Fidonet NODELIST ZIP
NODE0002.ZIP NODE0002.ZIP, Aktuellste Fidonet NODELIST.###
In der nächsten Woche bleiben die Einträge genauso wieder stehen, ausser dass die Datei
ersetzt wird, also aktueller ist. Beim Einspeicherungsdatum verbleibt aber das Ältere ....
Das wirft dann auch gleich das nächste Problem auf - wird die Area NODELIST-LAST dann überhaupt
jemals aktuallisiert? Nach dem bisherigen Script lautet die Antwort dann sicherlich
NEIN, da die
CRC32 der Files.BBS sich ja auch nicht verändert, da statisch, würde das Überprüfen
jedes einzelnen Files mit einer CRC32 Checksum alleine auch nichts bewirken, da die Main-Routine keine
Änderung feststellen kann. Die Main-Routine wäre aber wichtig, dass der Script in endlicher
Zeit ablaufen kann, und nicht jedesmal Stunden benötigt um sämtliche Files einer grossen
Filebase zu überprüfen ... Die Tabelle *_Downloads_Downloads jedenfalls gibt nicht mehr
viel her:
CREATE TABLE nuke_downloads_downloads (
lid int(11) NOT NULL auto_increment, // lfd. Pointer
cid int(11) NOT NULL default '0', // categorie ID
sid int(11) NOT NULL default '0', // sub.categorie ID
title varchar(100) NOT NULL default '', // Title, wird bereits geprueft
url varchar(100) NOT NULL default '', // URL, wird bereits geprueft
description text NOT NULL, // Description bleibt gleich
date datetime default NULL, // Date ist hier Einspeicherungs-
name varchar(100) NOT NULL default '', // Datum und nicht Filedate !
email varchar(100) NOT NULL default '', // Username+Email des Submitters
hits int(11) NOT NULL default '0', // Wieviele Zugriffe
submitter varchar(60) NOT NULL default '', // Submitter Name
downloadratingsummary double(6,4) NOT NULL default '0.0000',
totalvotes int(11) NOT NULL default '0',
totalcomments int(11) NOT NULL default '0',
filesize int(11) NOT NULL default '0', // Filesize, muss sich nicht
version varchar(10) NOT NULL default '', // unbedingt veraendern ...
homepage varchar(200) NOT NULL default '',
PRIMARY KEY (lid),
KEY lid (lid),
KEY cid (cid),
KEY sid (sid),
KEY title (title)
) TYPE=MyISAM;
Ich habe jetzt mal die Nodelisten und Points24 der letzten paar Wochen neu vertütet:
N133 ZIP 269.252 23.07.05 10:52
N140 ZIP 268.748 23.07.05 10:51
N147 ZIP 268.767 23.07.05 10:50
N154 ZIP 268.771 23.07.05 10:50
N161 ZIP 266.708 23.07.05 10:49
N168 ZIP 266.209 23.07.05 10:48
N175 ZIP 265.968 23.07.05 10:47
N182 ZIP 265.923 23.07.05 10:47
N189 ZIP 265.493 23.07.05 10:46
N196 ZIP 264.148 23.07.05 10:45
N203 ZIP 263.801 23.07.05 10:43
P014 ZIP 38.124 23.07.05 10:55
P021 ZIP 38.126 23.07.05 10:55
P070 ZIP 36.945 23.07.05 10:57
..
P091 ZIP 37.947 23.07.05 10:58
P154 ZIP 36.055 23.07.05 11:00
P161 ZIP 36.057 23.07.05 11:00
P189 ZIP 35.516 23.07.05 11:01
P196 ZIP 35.517 23.07.05 11:01
Bei den Points24 Archiven sind 4x an aufeinanderfolgenden Wochen ziemlich "naheliegende" Filesizes
zustandegekommen, aber immer noch unterschiedlich, auch wenn nur eine Differenz von 1 oder 2 Byte, so doch
ausreichend einen Unterschied feststellen zu können.
Gibt es mögliche Files, die identisch bleiben?
=> JA
1. Mögliches Szenario, die CDP Nodelisten ... die relativ statisch sind ... sich von Woche
zu Woche nur seltenst ändern ...
2. Filelisten ... Filebase Fileliste, die zwar täglich aktuallisiert wird, bei der aber meist nur
am Wochenende, wenn die ganzen Node- und Pointlisten eintrudeln sich ändern.
Was wären mögliche Alternativen?
Torsten Bamberg lieferte den "
Ticker Ansatz" ...
Der im FTN-System laufende Fileticker "versendet" an eine
imaginäre Point-AKA die
eingehenden Files ....
Funktioniert nur solange, wie keine weiteren File-Einspeisungsquellen vorhanden sind.
Bei mir laufen aber noch mindestens 2 weitere Fileeinspeisungen, die vom Ticker System entkoppelt sind:
a) lokale Filelisten (werden nicht ver-tickt)
b) FTSC Mirror Download (regelmässig wird ein Abgleich der Dokumente auf FTSC.org durchgeführt,
neue Files landen zwar in der Filebase, der Ticker bekommt davon aber nichts mit ...)
c) Pointlist Tools Mirror Download (wie b, nur andere Quelle)
Lösungsansatz?
Eine mögliche Lösung wäre eine Kombination aus Synchronisation
UND Ticker.
Neue Files, können schnell über den Ticker-Ansatz eingespeist werden. Dazu wäre ggf. die
DLIMP Tabelle um eine Spalte TIC-Areaname erweiterbar.
Parallel dazu kann während der täglichen System Maintenance ein Synchronisationslauf initiiert
werden, der dann einen kompletten Abgleich der Filebase durchführt und somit die Files erfasst, die
nicht durch den Ticker laufen. Hier wäre dann auch der Ansatz mit Filesize und File-CRC32
Überprüfung.
Status:
offen
Siehe auch
Umsetzung des TIC Imports ff.
[26.7.05]
Ein weiteres Problem. Beim MakeNl Upgrade in der Filebase gibt es ca. 7 Files mit mn32* beginnend.
Alle 7 Files sind mit Kleinbuchstaben in die Filebase geschrieben, worauf entsprechende DB Einträge
nicht in der Downloads Section auftauchen.
a) Teilweise waren Files in der Files.Bbs fälschlicherweise noch als mn325... statt mn326... bezeichnet.
Die Dateien existierten auch nicht mehr und konnten daraufhin nicht importiert werden.
b) Datei Prüfung wird auf Grossbuchstaben ausgedehnt.
Status:
Fixed
[28.7.05]
DLIMP Demo Aufruf für unter PHP-Nuke registrierte Benutzer endlich in Betrieb genommen.
Die Portierung des Admin Consolen Scripts hat mich weit längere Zeit aufgehalten, als das ich mir
das vorgestellt habe. Nun können aber die ersten Ergebnisse auch livehaftig "erlebt" werden.
Anmeldung im Webinterface - Menüpunkt
DLIMP Demo
