Auf der Suche nach einer geeigneten SiteSearch Funktion, die
- einen dynamischen Index verwendet
- aktuallisierbar per CRON und Commandline
- auf Perl oder PHP Basis arbeitet
- in bestehende WebSites integriert werden kann
- möglicherweise auf MySQL zurückgreifen kann
- in einer ausreichenden Geschwindigkeit Ergebnisse liefert
bin ich auf
PHPDig =>
http://www.phpdig.net/ gestossen.
PHPDig vereinigt sämtliche zuvor
aufgeführten Forderungen. Liefert ein kleine Installationsroutine und ist schnell in
der Ursprungsfassung betriebsbereit.
Die Indizierung kann mittels Webbrowser Aufruf oder via Commandline erfolgen.
Der erste Start war dann über einen Webbrowser:
Problem: /sitesearch/admin/index.php Update von grossen Datenbestaenden (> 100 Seiten)
schlägt meist nach einiger Zeit fehl. In der Browser Commandline steht:
http://192.168.1.33/search/admin/spider.php?site_id=2&mode=small
Dr. Watson und die Nachricht
"The page cannot be displayed"
Der Vorschlag der seitens Installationshinweise gemacht wird:
Auto Update via Shell ...
in Instructions zum Paket (section 8):
Launching the script :
#php -f [PHPDIG_DIR]/admin/spider.php [option]
List of options :
- all (default) : Update all hosts ;
- forceall : Force update all hosts ;
- http://mondomaine.tld : Add or update the url ;
- path/file : Add or update all urls listed in the given file.
Examples :
#php -f [PHPDIG_DIR]/admin/spider.php http://host.mydomain.com
As any shell command, the output can be redirected to a textfile.
(If you want some logs.)
#php -f [PHPDIG_DIR]/admin/spider.php all >> /var/log/phpdig.log
The [PHPDIG_DIR]/admin/spider.php can be launch by a cron task too, in order to auto update
the index. The recommended periodicity is 7 days. The updated documents you want to see
immediately in the searches can be updated manually.
- Thread: is it real to increase indexing time with web interface?
Also Suche nach "PHP in Shell laufen lassen" ...
Update via Shell ... zunächst auf LYNX und CRONTAB verwiesen.
Das hatte ich schon einmal im Zusammenhang mit CYGWIN.
see
Lynx for Windows
CRONTAB gibt es aber noch nicht unter
LYNX
noch im Zusammenhang mit
CYGWIN.
Also erneute Suche nach CRONTAB -> Crontab via Perl.
Verweis auf
http://cronw.sourceforge.net/ gefunden.
Da Crontab mit Lynx und Spider.php nicht liefen, bin ich wieder an der Erforschung der Lynx Version gelandet.
Ein 2tes Lynx Paket:
http://www.jim.spath.com/lynx_win32/
Exe + Cfg und manuell index.php gestartet.
Das Script laeuft jetzt schon einmal fuer eine Weile.
Aber auch mit Lynx gibt's eine Exception :-(
OleMainThreadWndName: Apache.exe Application Error
The instruction at "0x100b7d47" referenced memory at "0x07275002".
The memory could not be "written".
Ok to terminate, Cancel to debug
Apache 2.0.45 Win32 PHP4 Bug
Also ist das Problem weder beim IE noch beim LYNX zu suchen,
als vielmehr bei der eingesetzten Apache2 Version.
apache_2.0.45-win32-x86 mit Perl 5.8.
Known Problem see:
http://bugs.php.net/bug.php?id=25586
Versuch mit PHP 5:
http://snaps.php.net/
Apache2 startet zwar ohne Fehler. PHP wird aber nicht ausgeführt.
Ok, wieder step back.
php4, läuft!
???????????????????????????
Many hints on:
Apache Installations Anweisung
Zweimaliger Versuch nach dieser Anleitung PHP5 ins
Laufen zu bekommen ist fehlgeschlagen.
Erneuter Versuch mit PHP4
Erneuter Versuch mit PHP4: Spider single page
http://192.168.1.33/search/admin/spider.php?http://192.168.1.33/bbsfiles/r24pfq.htm
Hier wird zwar auch wieder index.htm ausgewertet und sämtliche Files
abgeklappert, aber ...
nach 216 Files und Laufzeit von 1:55:13 ist der Script immer noch
am Laufen ...
(entgegen dem Index.php/spider.php Aufruf fehlt hier der Übergabe
Parameter "=small")
In der Zwischenzeit eine Liste mit 20 Single Pages erstellt,
die per Fileliste dem Spider übergeben werden könnten, sofern
Single Page Update möglich wäre ...
PHP4 Shell unter DOS mit der CGI EXE
In der PHPDig Anleitung war ja die Kurzform:
#php -f spider.php
angegeben. Da ich im Zusammenhang mit der PHP5 Installation auch
wieder ueber das PHP Installationsverzeichnis gestolpert bin, in der
auch die CGI Version (installiert habe ich die Apache2 Modul Version) liegt.
Fuer
#php -f spider.php evtl. die CGI Mode Umsetzung benutzen?
cd [sitesearch]/admin
I:\Apache\Apache2\sitesearch\admin>i:\apache\php\..
php.exe -f mspider.php i:/apache/apache2/sitesearch/admin/spider2.txt
Anm.: spider2.txt enthält eine kleine Liste mit einzelnen Webpages zum Indizieren in der Form:
http://192.168.1.33/bbsfiles/servic.htm
http://192.168.1.33/bbsfiles/servic01.htm
http://192.168.1.33/bbsfiles/servic02.htm
http://192.168.1.33/bbsfiles/r24pfq.htm
Fehlermeldung:
"no files found" ...
spider.php nach mspider.php kopiert.
Im Duplikat mspider.php die 2 Remark Zeilen geöffnet (für die Auswertung
der Übergabeparameter):
$argc = $_SERVER["argc"];
$argv = $_SERVER["argv"];
Läuft!
Das liesse sich nun in den Task Scheduler einbauen ....
Sitesearch Search Page nun "experimental" als Sub-Page
eingebaut.
Customize SiteSearch into existing Website
Beim ersten Versuch habe ich von einer Website einen direkten Link für
die Search Seite eingetragen:
Search Site
Die Search Results lieferten folgendes Ergebnis:
- Die Page Navigation war OK.
- Die gefundenen Hits benutzten die "interne" Addressierung aus der Spider Search Site Information
Die Search Results zeigten also auf die "internen" Links: points to 192.168.1.33 ;(
Nach einigem Suchen wurde ich in
search_function.php fündig und fügte einige Modifikationen ein =>
removed "site_url"
orig: $url = eregi_replace("([a-z0-9])[/]+",
"\\1/",$content['site_url'].$content['path'].$content['file']);
new : $url = eregi_replace("([a-z0-9])[/]+",
"\\1/","/".$content['path'].$content['file']);
Jetzt wird als "Site_URL" die Aufrufseite verwendet.
Aus dem Internet, die jeweilige Aufruf Domain i.e. http://ambrosia60.goip.de/...
Im Intranet als http://192.168.1.33/..
Nun kam noch ein spannender Teil, wie bekomme ich die Search FORM in
eine existierende Website?
Da der SiteSearch Aufruf auf jedem Seitenkopf zusammen mit anderen Servicefunktionen
zu erreichen sein soll, hatte ich diese Service Links bereits in eine
PHP Inclusion eingebaut:
Inclusion into Header:
<td> nowrap align="right">
<form action='/search/search.php' method='get'>
>input type='hidden' name='site' value='2'>
<input type='hidden' name='path' value='/'>
<input type='hidden' name='template_demo' value='corporate.html'>
<input type='hidden' name='result_page' value='search.php'>
<INPUT NAME="query_string" VALUE="" TYPE="text" SIZE=15 MAXLENGTH=30>
</form>
</td>
Resultat: lässt sich schon sehen. Aber das Input Field ist
gegenüber dem restlichen Text in der Zeile noch nach oben "versetzt".
Hängt wohl damit zusammen "wo" der Parameter
</FORM>
(End-Form)
im HTML Code steht. Die End-Form am Ende der Tabelle justiert (wie durch ein Wunder)
die Eingabezeilen zu den danebenliegenden Links ...
Nach weiteren Anpassungen an der Corporate Results Form
ist nun auch die Ergebnis Ausgabe wunschgemäss.
Using PDF Filter with PHPDig
Die Benutzung des PDF Filters unter PHPDig gestaltet sich etwas schwierig. Ich habe den Filter
jedefalls nicht zum Laufen bekommen. Allerdings habe ich einen Weg zu Fuss gefunden.
In der
Config.Php ist als Option die Funktion PDF Filter vorgesehen:
define('PHPDIG_INDEX_PDF',false);
define('PHPDIG_PARSE_PDF','/usr/local/bin/pstotext');
define('PHPDIG_OPTION_PDF','-cork');
Die Suche über Google nach "pstotext" führte mich zu Ghostscript
http://research.compaq.com/SRC/virtualpaper/pstotext.html
weiter über den Windows ->
GSView Link, weiter
über den
GSview release v4.6 Link zum
Obtaining AFPL Ghostscript 8.14 Download Link.
Hier nun endlich waren beide Pakete für Win32
AFPL Ghostscript 8.14
und
GSView 4.6 zusammen verfügbar.
Nach Download und Installation enthielt das AFPL Ghostscript Paket auch ein PSTOTEXT Verzeichnis. Allerdings war die ausführbare Exe nicht die im
PHPDig Config vorgegebene ausführbare Datei, sondern eine Datei unter dem Namen
pstotxt3.exe.
Diese Datei nun in die
Config.php eingetragen lieferte zunächst Fehlermeldungen:
Datei nicht gefunden..
Nachdem ich noch die BIN Pfade von Ghostscript und GSView in das PATH Environment eingebaut hatte, lief das Programm
selbst dann zumindest ohne Fehlermeldung. Zusammen mit PHPDig und dem Spider Vorgang gab es dennoch keinerlei Ergebnisse.
Zwar wurden Textextrakte erstellt (konnte ich im TEMP Verzeichnis sehen), aber die Übergabe nach PHPDig klappte
aus unerfindlichen Gründen dann nicht mehr. Trotz der in der Config.Php nachfolgenden
Konfiguration:
//---------EXTERNAL TOOLS EXTENSIONS
// if external binary is not STDOUT or different extension is needed
// for example, use '.txt' if external binary writes to filename.txt
..
define('PHPDIG_PDF_EXTENSION','.txt');
konnte der Extrakt nicht nach PHPDig eingebunden werden. Auch wurden im
PHPDig
text_content Verzeichnis keine Extrakte abgelegt.
Letztendlich bin ich zu der Überzeugung gelangt, das PDF Filtering zu Fuss durchzuführen. Das macht insbesondere
dann Sinn, wenn die Anzahl der zu indizierenden PDF Dokumente sich noch in einem überschaubaren Umfang befinden.
Was macht das PDF Filtering?
Zunächst wird das PDF Dokument mittels PSTOTEXT in ein ASCII Text Format gewandelt. Das kann ich auch manuell:
GSView - File - Open -> PDF Dokument auswählen -> Edit - Text Extract - All - OK.
GSView beginnt mit dem Extrahieren des Textes nach ASCII.
Save As -> hier nun den Dateinamen der PDF Datei verwenden, mit der Endung TXT.
Da das PDF Dokument nicht mehr angezeigt wird: -> File - Close.
Die TXT Dateien sollten zusammen mit dem PDF Dokument in ein und demselben Verzeichnis abgelegt werden. Um im nächsten
Schritt beim PHPDig Spider Vorgang alle PDF Dokumente und die Konvertierungen in einem Verzeichnis zusammen zu haben, empfiehlt
es sich saemtliche PDF Dokumente in einem Verzeichnis zusammenzuführen und in der entsprechenden Website einen Link auf
dieses Verzeichnis zu verwenden. Beispiel ->
PDFDOC
Im nächsten Schritt lässt man nun den PHPDig Spider über dieses Verzeichnis laufen.
i:\apache\php\php -f mspider.php i:/apache/apache2/sitesearch/admin/spider5.txt
wobei in
SPIDER5.TXT das
PDFDOC Verzeichnis angegeben ist.
Nach dem PHPDig Spider Lauf wurden nun die TXT Extrakte indiziert.
Nun müssen die in der PHPDig Datenbank angelegten Links mit der Endung
TXT noch
in
PDF umbenannt werden.
i.e. MySQL Control Center -> Tabelle
phpdig_spider Sortierung nach Spalte
PATH.
In den Spalten
FILE und
FIRST_WORDS den Verweis auf die Datei
*.TXT gegen
*.PDF
ersetzen.
Nun wird bei der Suche nach Inhalten aus der PDF Datei die entsprechende PDF Datei, die ja auch noch
in dem
PDFDOC Verzeichnis steht, in der Query Result Liste angezeigt.
Uli, im Juli 2004