VN Suche - Mobirise Block ( Komplett System)

[Volker]

Ja

[Tommy Herrmann]

yack

[Volker]

Mein ChatGPT macht keine Fehler

[Tommy Herrmann]

jepp - alle Tests auch mit der neuesten Version von Deinem Server laufen einwandfrei. Auch der Cronjob

Ich denke und hoffe - das war's dann mit der Suche


https://www.mobirise-tutorials.com/VN-B ... /Suche.php


P.S.:

Dein VN Backup gucke ich mir etwas später an. Wenn das ebenso falsch sein sollte - dann bitte noch was dazu schreiben ...

[Volker]

Das ist nur eine php datei wenn da was falsch wäre kannst die ja reparieren lassen

[Tommy Herrmann]

[Tommy Herrmann]

Volker,

Der Cronjob war weiterhin fehlerhaft und wurde jetzt vollständig korrigiert.

Mir ist das aufgefallen, weil mein gestern angelegtes neues Verzeichnis zum Testen des Cronjobs — mit einer TXT- und einer PDF-Datei — heute Morgen weder in der Suche zu finden war noch auf der Administrationsseite gelistet wurde. Bisher funktioniert das also nur, wenn zuvor über den Button „Einlesen“ ein vollständiger Scan durchgeführt wurde. Das ist natürlich falsch, denn dann greift der Cronjob nicht: Er muss selbst erkennen, wenn neue Verzeichnisse oder Dateien hinzugekommen sind.

Bitte tausche dieses Skript aus und erstelle eine neue .mbrext-Datei zum Download. Ich habe es bis zum Abwinken geprüft. Gib mir anschließend Bescheid, damit ich die korrigierte Erweiterung auch bei mir einlesen kann.


cron-scan.php

Code: Alles auswählen

<?php

declare(strict_types=1);

/**
 * Automatischer Scan-Endpunkt für Cronjobs / URL-basierte "Geplante
 * Aufgaben" (z.B. Plesk, cPanel). Läuft OHNE Admin-Login, dafür mit einem
 * eigenen, langen Sicherheits-Token (wird im Admin-Bereich angezeigt und
 * kann dort jederzeit neu erzeugt werden).
 *
 * Führt in EINEM Durchlauf alles aus, was beim manuellen "Einlesen" sonst
 * über mehrere Klicks/JS-Schritte passiert: Ordner-Scan, PDF-Textextraktion
 * und PHP-/Sitemap-Seitenabruf - da hier kein Browser da ist, der das
 * normalerweise per JavaScript nacheinander anstößt.
 *
 * Aufruf z.B. per Cronjob:
 *   wget -q -O /dev/null "https://deine-domain.de/assets/vn-search/admin/cron-scan.php?token=DEIN_TOKEN"
 * oder direkt per PHP-CLI (falls vom Hoster unterstützt):
 *   php /pfad/zu/assets/vn-search/admin/cron-scan.php DEIN_TOKEN
 */

require __DIR__ . '/../db.php';
require __DIR__ . '/../html-helper.php';
require __DIR__ . '/../scan-core.php';
require __DIR__ . '/../pdfparser/autoload.php';
require __DIR__ . '/../ocr-helper.php';

// Cronlaeufe duerfen auch bei groesseren Domains nicht durch das normale
// PHP-Zeitlimit abgebrochen werden. Auf Shared Hosting kann der Hoster
// dennoch ein eigenes, unveraenderliches Maximal-Limit vorgeben.
@set_time_limit(0);
ignore_user_abort(true);

header('Content-Type: application/json; charset=utf-8');

function vnRespondCron(bool $success, string $message, array $extra = []): void
{
    http_response_code($success ? 200 : 400);
    echo json_encode(array_merge(['success' => $success, 'message' => $message], $extra), JSON_UNESCAPED_UNICODE);
    exit;
}

$pdo = vnSearchDb();

// Token entweder als GET-Parameter (URL-Cronjob) oder als erstes
// Kommandozeilen-Argument (PHP-CLI-Cronjob) entgegennehmen.
$providedToken = '';
if (PHP_SAPI === 'cli') {
    $providedToken = trim((string)($argv[1] ?? ''));
} else {
    $providedToken = trim((string)($_GET['token'] ?? ''));
}

$storedToken = (string)vnSearchGetSetting($pdo, 'cron_token', '');

if ($storedToken === '' || $providedToken === '' || !hash_equals($storedToken, $providedToken)) {
    vnRespondCron(false, 'Ungültiges oder fehlendes Sicherheits-Token.');
}

// Eigener Ein/Aus-Schalter, unabhängig vom Cronjob beim Hoster selbst - so
// kann der Admin den automatischen Scan jederzeit hier im Admin-Bereich
// pausieren, ohne den Cronjob beim Hoster löschen/anpassen zu müssen.
$cronEnabled = vnSearchGetSetting($pdo, 'cron_enabled', '1') === '1';
if (!$cronEnabled) {
    vnRespondCron(false, 'Automatischer Scan ist im Admin-Bereich deaktiviert.');
}

// Der Cronjob soll bewusst IMMER den gesamten eingestellten Scan-Wurzelordner
// neu durchsuchen. Er darf deshalb NICHT den zuletzt manuell verwendeten
// Unterordner aus "last_scan_folder" uebernehmen. Nur so werden neue
// Verzeichnisse auf der Domain automatisch entdeckt, auch wenn der Admin
// zuvor einmal gezielt einen einzelnen Unterordner eingelesen hat.
$folderRaw = '';

// Die Optionen fuer PHP-Seiten und zusaetzliche Dateiendungen duerfen dagegen
// weiterhin aus dem letzten manuellen Scan uebernommen werden.
$includePhpPages = vnSearchGetSetting($pdo, 'last_scan_include_php', '') === '1';
$extraExtRaw = (string)vnSearchGetSetting($pdo, 'last_scan_extra_ext', '');

// Eigener Hostname wird für die PHP-Seiten-URLs benötigt - bei einem
// CLI-Cronjob gibt es kein HTTP_HOST, deshalb als Einstellung hinterlegt
// (wird beim Speichern des Tokens mit gesichert, siehe save-settings.php).
$httpHost = (string)vnSearchGetSetting($pdo, 'cron_http_host', '');

$scanResult = vnSearchRunScan($pdo, $folderRaw, $includePhpPages, $extraExtRaw, $httpHost);

// Bisher lief der Cronjob selbst bei einem fehlgeschlagenen Ordner-Scan mit
// der Verarbeitung bereits vorhandener Warteschlangen weiter und meldete am
// Ende trotzdem "Automatischer Scan abgeschlossen". Dadurch konnte der
// Eindruck entstehen, der Vollscan habe funktioniert, obwohl keine neuen
// Ordner oder Dateien eingelesen worden waren.
if (empty($scanResult['success'])) {
    vnSearchSetSetting($pdo, 'cron_last_run', (string)time());
    vnRespondCron(false, 'Der automatische Vollscan ist fehlgeschlagen: ' . (string)($scanResult['message'] ?? 'Unbekannter Scanfehler.'), [
        'scan' => $scanResult,
        'pdfProcessed' => 0,
        'pdfErrors' => 0,
        'pageProcessed' => 0,
    ]);
}

// --- PDFs: alle ausstehenden jetzt komplett abarbeiten (nicht nur einen
//     kleinen Batch wie beim manuellen Klick, da hier ja niemand mehrfach
//     nachklicken kann) ---
$pdfProcessed = 0;
$pdfErrors = 0;

if (extension_loaded('mbstring')) {
    $defaultWebRoot = realpath(__DIR__ . '/../../..');
    $webRoot = vnSearchResolveScanRoot($pdo, $defaultWebRoot);
    $uploadDir = __DIR__ . '/../uploads/pdfs';
    $parser = new \Smalot\PdfParser\Parser();

    // Sicherheitsgrenze, damit ein Cronjob nicht endlos läuft, falls
    // extrem viele PDFs neu hinzugekommen sind - der naechste Cronjob-
    // Durchlauf macht dann einfach weiter.
    $maxPdfPerRun = 200;

    while ($pdfProcessed < $maxPdfPerRun) {
        $stmt = $pdo->prepare('SELECT id, original_name, stored_filename, source FROM pdf_files WHERE indexed_at IS NULL LIMIT 5');
        $stmt->execute();
        $pending = $stmt->fetchAll();
        if (empty($pending)) {
            break;
        }

        foreach ($pending as $row) {
            $filePath = $row['source'] === 'uploaded'
                ? $uploadDir . '/' . $row['stored_filename']
                : $webRoot . '/' . $row['stored_filename'];

            $error = null;
            $text = '';

            if (!file_exists($filePath)) {
                $error = 'Datei nicht gefunden (evtl. verschoben/gelöscht).';
            } else {
                try {
                    $pdf = $parser->parseFile($filePath);
                    $text = trim((string)$pdf->getText());

                    if ($text === '') {
                        $ocrText = vnSearchOcrExtract($filePath);
                        if ($ocrText !== null) {
                            $text = $ocrText;
                        }
                    }

                    if ($text === '') {
                        $error = vnSearchOcrAvailable()
                            ? 'Kein Text erkennbar (auch nicht per OCR-Texterkennung).'
                            : 'Kein Text extrahierbar (evtl. gescanntes Dokument ohne Texterkennung).';
                    }
                } catch (\Throwable $e) {
                    $error = 'Fehler beim Lesen: ' . $e->getMessage();
                }
            }

            if ($error === null) {
                $url = $row['source'] === 'uploaded'
                    ? '/assets/vn-search/uploads/pdfs/' . $row['stored_filename']
                    : '/' . $row['stored_filename'];

                $ftsRowid = vnSearchIndexUpsert($pdo, null, $row['original_name'], $text, $url, 'pdf');

                $upd = $pdo->prepare('UPDATE pdf_files SET indexed_at = :ia, fts_rowid = :fr, error = NULL WHERE id = :id');
                $upd->execute(['ia' => time(), 'fr' => $ftsRowid, 'id' => $row['id']]);
            } else {
                $upd = $pdo->prepare('UPDATE pdf_files SET indexed_at = :ia, error = :err WHERE id = :id');
                $upd->execute(['ia' => time(), 'err' => $error, 'id' => $row['id']]);
                $pdfErrors++;
            }

            $pdfProcessed++;
        }
    }
}

// --- Seiten (Sitemap/PHP-Abruf): ebenfalls komplett abarbeiten ---
$pageProcessed = 0;
$maxPagesPerRun = 500;
$context = stream_context_create(['http' => ['timeout' => 10], 'ssl' => ['verify_peer' => false, 'verify_peer_name' => false]]);

while ($pageProcessed < $maxPagesPerRun) {
    $stmt = $pdo->prepare('SELECT id, url FROM indexed_pages WHERE indexed_at IS NULL LIMIT 5');
    $stmt->execute();
    $pending = $stmt->fetchAll();
    if (empty($pending)) {
        break;
    }

    foreach ($pending as $row) {
        $html = @file_get_contents($row['url'], false, $context);

        if ($html === false) {
            $upd = $pdo->prepare('UPDATE indexed_pages SET indexed_at = :ia, title = :t WHERE id = :id');
            $upd->execute(['ia' => time(), 't' => '(Fehler beim Abrufen)', 'id' => $row['id']]);
            $pageProcessed++;
            continue;
        }

        [$title, $text] = vnSearchExtractPageContent($html);
        if ($title === '') {
            $title = $row['url'];
        }

        $ftsRowid = vnSearchIndexUpsert($pdo, null, $title, $text, $row['url'], 'page');

        $upd = $pdo->prepare('UPDATE indexed_pages SET title = :t, indexed_at = :ia, fts_rowid = :fr WHERE id = :id');
        $upd->execute(['t' => $title, 'ia' => time(), 'fr' => $ftsRowid, 'id' => $row['id']]);

        $pageProcessed++;
    }
}

vnSearchSetSetting($pdo, 'cron_last_run', (string)time());

vnRespondCron(true, 'Automatischer Scan abgeschlossen.', [
    'scan' => $scanResult,
    'pdfProcessed' => $pdfProcessed,
    'pdfErrors' => $pdfErrors,
    'pageProcessed' => $pageProcessed,
]);

Das wurde korrigiert:

Der Fehler steckt in:

Code: Alles auswählen

/assets/vn-search/admin/cron-scan.php

Dort stand bisher:

Code: Alles auswählen

$folderRaw = (string)vnSearchGetSetting($pdo, 'last_scan_folder', '');

Der Cronjob führte somit nicht zwingend einen vollständigen Domain-Scan aus, sondern übernahm den Ordner des letzten manuellen Scanvorgangs. War dort irgendwann ein bestimmter Ordner gespeichert, suchte der Cronjob nur noch innerhalb dieses Bereichs. Neue Verzeichnisse außerhalb davon konnten nicht gefunden werden.

Zusätzlich gab es einen zweiten Fehler: Schlug der eigentliche Verzeichnis-Scan fehl, arbeitete der Cronjob trotzdem bereits bekannte PDF- und Seiteneinträge ab und meldete anschließend:

Code: Alles auswählen

Automatischer Scan abgeschlossen.

Dadurch sah es so aus, als hätte der vollständige Scan funktioniert. Tatsächlich wurden aber eventuell nur Dateien verarbeitet, die zuvor durch den Button „Einlesen“ in die Datenbank gelangt waren. Das passt genau zu Deiner Beobachtung.

Der Scan funktioniert nun auch, nachdem Dateien und Verzeichnisse manuell gelöscht wurden.

Da der Cronjob jetzt einen vollständigen Domain-Scan ausführt, passiert beim nächsten Lauf Folgendes:

> Die bisherigen automatisch gescannten Einträge werden aus dem Suchindex entfernt.
> Der aktuell vorhandene Verzeichnisbaum wird neu eingelesen.
> Dateien und Verzeichnisse, die Du inzwischen am Server gelöscht hast, werden nicht erneut gefunden.
> Dadurch verschwinden deren Suchtreffer automatisch aus der Suche und aus den Listen der Adminseite.

Das gilt für:

PDFs,
TXT und andere zusätzliche Dateitypen,
HTML- und HTM-Seiten,
PHP-Seiten, sofern deren Erfassung aktiviert ist.

Deine Ausgabe bestätigt, dass der vollständige Neuaufbau jetzt funktioniert!

[Volker]

Moin Tommy,

ist drin

[Tommy Herrmann]

Moin,

ich habe das gerade noch einmal prüfen lassen; alles ist in Ordnung.

ChatGPT hat allerdings eine kleine Anmerkung, die für dich interessant sein könnte. Wenn du das noch ändern lassen möchtest, gib mir bitte kurz Bescheid.

Einen kleinen Punkt habe ich beim Durchsehen noch entdeckt

Das hat nichts mit Deiner gerade behobenen Cronjob-Problematik zu tun, sollte aber für später im Hinterkopf bleiben.

Für PDFs gibt es diese Begrenzung:

Code: Alles auswählen

$maxPdfPerRun = 200;

und für PHP-Seiten:

Code: Alles auswählen

$maxPagesPerRun = 500;

Der Kommentar bei den PDFs sagt:

Code: Alles auswählen

// der naechste Cronjob-
// Durchlauf macht dann einfach weiter.

Das stimmt bei der jetzigen Vollscan-Strategie nicht unbedingt. Da bei jedem Cronjob zunächst der komplette automatisch erzeugte Bestand neu aufgebaut wird, werden die gescannten PDFs wieder als noch nicht indexiert angelegt. Bei irgendwann mehr als 200 PDFs könnte daher jedes Mal wieder vorne begonnen werden, anstatt beim 201. PDF fortzufahren. Entsprechendes gilt theoretisch bei mehr als 500 abzurufenden PHP-Seiten.

[Volker]

Gegeben die Unsicherheit über die genaue Anzahl, baue ich die grundsätzlich robustere Lösung: Statt bei jedem Lauf ALLES zurückzusetzen und neu zu beginnen, sollen nur tatsächlich neue oder verschwundene Dateien behandelt werden – unverändert vorhandene bleiben mit ihrem bestehenden Status stehen. Das löst das Problem komplett, unabhängig von der Anzahl:

Orchestrierte Pfad-Berechnung und Pruning-Logik für Dateiverwaltung
Orchestrierte Pfad-Berechnung und Pruning-Logik für Dateiverwaltung

Jetzt die Aufrufstelle anpassen – die aktuell gefundenen Pfade berechnen und der neuen Funktion übergeben:

Überprüfte Datenfluss und Duplikatverhinderung in Abfragefunktion
Überprüfte Datenfluss und Duplikatverhinderung in Abfragefunktion

Jetzt den Rest der Funktion ansehen, um sicherzustellen, dass die Einfüge-Logik konsistent mit dem neuen Ansatz ist:

Validierte bestehende Logik zur Duplikatvermeidung und Datenverwaltung
Validierte bestehende Logik zur Duplikatvermeidung und Datenverwaltung

Syntax prüfen und die PDF-Einfüge-Logik gegenchecken:

Orchestrierte umfassende Tests für Dateiindexierung und Löschszenarien
Orchestrierte umfassende Tests für Dateiindexierung und Löschszenarien

Jetzt umfassend testen – das ist der wichtigste Test heute, muss alle drei Szenarien gleichzeitig abdecken:

Vorbereitung: OrdnerA scannen, a1 indexieren, a2 pending lassen
Vorbereitung: OrdnerA scannen, a1 indexieren, a2 pending lassen

Beide wurden gleich indexiert (Batch-Größe reichte). Kein Problem – ich teste stattdessen: erneut scannen, während a2 zwischenzeitlich gelöscht wird, und prüfe ob a1s Zeitstempel unverändert bleibt (Kernfrage):

Verifizierte erfolgreiche Dateientfernung und Indexintegrität
Verifizierte erfolgreiche Dateientfernung und Indexintegrität

Perfekt bestätigt – genau der gewünschte Effekt: a2.pdf (gelöscht) korrekt entfernt, a1.pdf behält exakt denselben alten Zeitstempel (nicht zurückgesetzt!). Das löst ChatGPTs Bedenken vollständig – bei vielen PDFs müsste ein Cronjob jetzt nicht mehr bei jedem Lauf von vorne anfangen. Kurz noch die OrdnerA/OrdnerB-Unabhängigkeit erneut bestätigen:

Ordner-Unabhängigkeit erneut bestätigen
Ordner-Unabhängigkeit erneut bestätigen

Alle drei Kernszenarien bestätigt korrekt. Jetzt einbetten und final packen:

Einbetten und verifizieren
Einbetten und verifizieren

Vollständige Verifikation und packen:

Hat einen Befehl ausgeführt, datei lesen
Hat einen Befehl ausgeführt, datei lesen

vn-search.mbrext – ChatGPTs Bedenken war berechtigt, jetzt richtig gelöst:

Statt bei jedem Scan ALLES im Bereich zu löschen und komplett neu aufzubauen (was bei über 200 PDFs / 500 Seiten tatsächlich zum "immer wieder von vorne"-Problem geführt hätte), wird jetzt gezielt nur verglichen: Nur Dateien/Seiten, die beim aktuellen Scan wirklich nicht mehr gefunden werden, fliegen raus. Alles, was weiterhin existiert, bleibt mit seinem bisherigen Status (bereits indexiert oder noch ausstehend) unangetastet.

Mit drei echten Tests bestätigt:

Datei physisch gelöscht → korrekt aus dem Index entfernt
Unveränderte, bereits indexierte Datei → behält exakt denselben alten Zeitstempel (wird NICHT zurückgesetzt) – das ist der Kern des Fixes
Separat gescannte Ordner (OrdnerA, dann OrdnerB) → beide bleiben weiterhin unabhängig erhalten

Das bedeutet: Ein Cronjob mit sehr vielen PDFs muss jetzt nicht mehr bei jedem Lauf bei Null anfangen – nur echte Neuzugänge werden zur Warteschlange hinzugefügt, alles Bestehende bleibt stehen. Damit ist die 200er/500er-Grenze aus cron-scan.php unproblematisch, wie ChatGPT zurecht angemerkt hat.

Bitte an Tommy/ChatGPT weiterleiten und gerne nochmal gegenprüfen lassen – und danke für den aufmerksamen Blick, das war ein echter, nicht offensichtlicher Bug.

Ist jetzt aktuell im Download- Lass die Chat Tante das mal checken

[Tommy Herrmann]

Wo genau wurde das denn geändert? Die Datei "cron-scan.php" ist ja unverändert noch gleich

[Volker]

scan-core.php

cron-scan.php selbst enthält weiterhin die Zeilen $maxPdfPerRun = 200; und $maxPagesPerRun = 500; – die hab ich unverändert gelassen. Das Problem lag nicht in dieser Verarbeitungs-Grenze selbst, sondern davor: In scan-core.php wurden bisher bei JEDEM Scan alle bereits fertig indexierten Dateien wieder auf "noch nicht indexiert" zurückgesetzt (durch die alte vnSearchResetScannedIndex-Funktion) – dadurch mussten bei jedem Cronjob-Lauf wieder ALLE PDFs neu verarbeitet werden, auch die, die längst fertig waren.

Mein Fix (die neue vnSearchPruneStaleEntries-Funktion, ebenfalls in scan-core.php) sorgt dafür, dass bereits fertig indexierte, unveränderte Dateien gar nicht mehr zurückgesetzt werden – nur echte Neuzugänge landen in der Warteschlange.

Das Ergebnis: Die 200er/500er-Grenze in cron-scan.php bleibt zwar technisch bestehen, wird aber praktisch kaum noch relevant – weil bei jedem Lauf nur noch die paar tatsächlich NEUEN Dateien verarbeitet werden müssen, nicht mehr der komplette Bestand. Bei z. B. 500 PDFs, von denen 495 schon fertig sind, bleiben nur noch 5 zu verarbeiten übrig – weit unter dem Limit.

Falls dir das trotzdem zu unsicher ist (z. B. bei einem außergewöhnlich großen einmaligen Zuwachs), könnte ich die Grenze in cron-scan.php zusätzlich noch erhöhen oder ganz entfernen – sag Bescheid, falls gewünscht.

[Tommy Herrmann]

Warte - wir erstellen eine neue .mbrext-Datei:

Ich habe zwei zusätzliche Punkte gefunden, die in Claudes Beschreibung nicht erwähnt sind und die ich vor dem Neuverpacken korrigieren möchte: geänderte Dateien mit gleichem Pfad werden derzeit nicht neu indexiert, und der Unterordner-Abgleich kann bei ähnlich beginnenden Ordnernamen zu breit greifen. Das betrifft also nicht nur Cronjob-Fortsetzung, sondern die Aktualität des Suchindex selbst.

P.S.:

Beim vollständigen Abgleich ist noch ein echter Aktualisierungsfehler sichtbar: Der neue Code erkennt „vorhanden“ nur am Pfad. Wird z. B. eine bereits indexierte PDF oder HTML/PHP-Datei inhaltlich geändert, aber nicht umbenannt, bleibt der alte Suchinhalt stehen. Ich korrigiere das jetzt über Änderungszeitstempel, ohne den erreichten Fortschritt der 200/500-Warteschlange wieder zu zerstören.

P.S.:

Die Korrektur ist jetzt in der eigentlichen Logik eingebaut: unveränderte Einträge behalten ihren Status, gelöschte werden entfernt, geänderte PDFs/HTML/PHP-Dateien werden gezielt neu indexiert, und Unterordner werden sauber voneinander abgegrenzt. Ich teste diese Fälle jetzt in einer separaten SQLite-Testumgebung, bevor ich die .mbrext neu packe.

Die .mbrext-Datei sende ich Dir gleich via "PN" - bitte gib dann Bescheid:

Geändert habe ich:

plugins/vn-search/scan-core.php
Claudes neue „nur verschwundene Einträge löschen“-Logik bleibt erhalten.
Unveränderte Dateien behalten ihren bisherigen Indexierungsstatus.
Neu hinzugekommene Dateien werden korrekt ergänzt.
Gelöschte Dateien werden entfernt.
Zusätzlich korrigiert: Bereits vorhandene PDFs, HTML- und PHP-Dateien werden jetzt auch erkannt, wenn sich ihr Inhalt bei gleichem Dateinamen/Pfad geändert hat.
Unterordner wie Test und Test2 werden beim gezielten Scan sauber voneinander getrennt.

plugins/vn-search/db.php
Neue Spalte file_mtime, damit Änderungen bestehender Dateien zuverlässig erkannt werden können.
Die Migration funktioniert auch mit Deiner bereits vorhandenen SQLite-Datenbank; die Datenbank muss nicht gelöscht werden.

app.js
Die korrigierten Fassungen von db.php und scan-core.php wurden auch in die Base64-internen Dateien der Mobirise-Erweiterung übernommen.

cron-scan.php war bereits korrekt und musste nicht geändert werden; ich habe zusätzlich kontrolliert, dass die in app.js eingebettete Version identisch ist.

Die 200-PDF-/500-Seiten-Grenzen im Cronjob bleiben bestehen und funktionieren nun so, wie vorgesehen: Bereits fertig indexierte unveränderte Dateien werden beim nächsten Lauf nicht erneut auf Null gesetzt.

Ich habe außerdem sämtliche 73 PHP-Dateien auf Syntaxfehler geprüft und die fertige .mbrext anschließend nochmals als ZIP-Archiv validiert.

[Tommy Herrmann]

Den Link zum Download der neuen .mbrext-Datei habe ich Dir via "PN" gesendet.

Bitte gib mir Bescheid.

Ich habe die neue mbrext-Datei selbst weder installiert noch getestet, denn ich warte auf den Download von Dir.

Bitte schreibe mir ob Du diese nun unverändert übernommen hast oder was noch geändert worden ist.

[Tommy Herrmann]

Volker,

offensichtlich hast Du auch gerade etwas anderes zu tun. Ich war jetzt 90 Minuten am Telefon mit der Wildtierbehörde wegen meiner Waschbären. Da kannst Du quasi nichts machen - nur hoffen, dass die im Herbst abhauen.

Ich werde jetzt die neueste .mbrext-Datei von ChatGPT installieren (Du hast die in einer "PN") und dann berichten.

[Tommy Herrmann]

Also - alles getestet. Das geht jetzt blitzschnell, weil nur noch Änderungen verarbeitet werden müssen. Ich möchte das jetzt eigentlich so lassen. Bitte prüfe es auch.

https://www.mobirise-tutorials.com/VN-B ... /Suche.php



Eingabe der URL vom Cronjob:

> Neues Verzeichnis wurde sofort gescannt. 1 TXT + 2 PDF Dateien

> 1 PDF (1 PDF Backup) Datei geändert > neuer Scan hat das sofort erkannt und auch so ausgegeben

> Verzeichnis wieder am Server gelöscht > neuer Scan hat das erkannt und entfernt

Neues Verzeichnis mit 2 PDF und 1 TXT Dateien:

success true
message "Automatischer Scan abgeschlossen."
scan
success true
message "Der Suchindex wurde vollständig abgeglichen: 3 neue und 0 geänderte Datei(en)/Seite(n) wurden übernommen (PDFs werden noch nach Text durchsucht, HTML-Seiten sind sofort mit echtem Inhalt durchsuchbar, andere Dateien nur per Dateiname)."
found 594
new 3
changed 0
phpQueued 0
accessWarnings []
pdfProcessed 2
pdfErrors 0
pageProcessed 0

In neuem Verzeichnis 2 PDF geändert:

success true
message "Automatischer Scan abgeschlossen."
scan
success true
message "Der Suchindex wurde vollständig abgeglichen: 0 neue und 2 geänderte Datei(en)/Seite(n) wurden übernommen (PDFs werden noch nach Text durchsucht, HTML-Seiten sind sofort mit echtem Inhalt durchsuchbar, andere Dateien nur per Dateiname)."
found 594
new 0
changed 2
phpQueued 0
accessWarnings []
pdfProcessed 2
pdfErrors 0
pageProcessed 0

Ja, nach Deinen Tests sieht das jetzt sehr sauber aus.

Du hast damit praktisch alle wichtigen Fälle geprüft: neue Dateien werden erkannt, geänderte Dateien werden gezielt neu indexiert, unveränderte bleiben unangetastet und gelöschte Einträge verschwinden wieder. Genau so sollte ein Cronjob-basierter Abgleich arbeiten.

Ich würde diese Version jetzt tatsächlich als stabilen Stand beibehalten und nicht weiter daran drehen, solange im normalen Betrieb nichts Auffälliges mehr auftaucht.

[Volker]

Ist im Download.

Bin mal wieder alleine unterwegs also mehr Arbeit

[Tommy Herrmann]

Kannst Du mir bitt noch sagen, ob die jetzt unverändert im Download ist. Ich habe langsam keinen Bock mehr auf testen

[Volker]

ist deine im download

[Tommy Herrmann]

OK - ist oben.

Ich erwarte nämlich ab 12:00 - 18:00 Uhr den automatischen Cronjob von IONOS. Das steht noch aus ...
... wurde von IONOS erledigt.

Dann werden (oder sollten) wieder mit der Eingabe von cron das neue Verzeichnis mit 2 PDF und 1 TXT Datei automatisch gefunden werden.