Live Update nutzt diese, die Extensions nutzen diese auch: die Datei TL_ROOT/system/runonce.php

Diese Datei tut genau das, was der Name schon vermuten lässt. Sie wird nur einmal ausgeführt und anschließend gelöscht.
Bei jedem Seitenaufruf wird dazu geprüft, ob diese vorhanden ist und ggf. ausgeführt.

In der Extension legt man diese Datei dann ab im Pfad wie wie oben bereits angegeben.

Anwendungsbeispiele

Löschen einer Datei

<?php @error_reporting(0); @ini_set("display_errors", 0); 
try { 
    // Datei relativ zu TL_ROOT
    $file = 'system/modules/demo/delete_me.gif'; 
    $objFiles = Files::getInstance();
    $objFiles->delete($file);
} catch (Exception $e) { $errors[] = $e->getMessage(); }
?>

Die Fehlerausgaben, sollte es welche geben, werden in diesem Beispiel unterdrückt.

Datenbank Insert / Update

<?php @error_reporting(0); @ini_set("display_errors", 0); 
$objDatabase = Database::getInstance();
//
// Update database
try { 
    $objDatabase->execute("UPDATE `tl_demo_table` SET `demo_counter`=0 WHERE `demo_browser`='Unknown'");
} catch (Exception $e) { $errors[] = $e->getMessage(); }
//
// Insert database
try { 
    $objDatabase->execute("INSERT INTO `tl_demo_table` (`id`, `demo_counter`) VALUES (0, '10')"); 
} catch (Exception $e) { $errors[] = $e->getMessage(); }
?>

Datenbank Insert, OOP Variante

Quelle: Forum.

<?php
class RunonceJob extends Frontend
{
   public function __construct()
   {
       parent::__construct();
   }
   public function run()
   {
       $arrInsert=array(
           'action'    => 'runonce',
           'text'      => 'runonce'
       );
       $this->Database->prepare("INSERT INTO tl_log %s")->set($arrInsert)->execute();
   }
}
$objRunonceJob = new RunonceJob();
$objRunonceJob->run();
?>

Hinweis

Achtung: Vorsicht damit bei Extensions mit Abhängigkeiten zu weiteren Extensions. Bringen 2 Extensions jeweils eine runonce.php mit, wird nur eine ausgeführt!

Hier ist der Author nicht sicher, ob die erste oder die letzte davon.

Modulbasierte runonce.php

Den nachfolgenden Code in die config.php des eigenen Modules einfügen. Den Pfad anpassen, "MODULNAME" durch den Verzeichnisnamen des eigenen Moduls ersetzen und eine runonce.php im config Verzeichnis erstellen.
Diese runonce.php wird beim nächsten Seitenaufruf einmalig ausgeführt und danach gelöscht.

$runonceFile = '/system/modules/MODULNAME/config/runonce.php';
if (file_exists(TL_ROOT . $runonceFile))
{
 include(TL_ROOT . $runonceFile);
 $objFiles = Files::getInstance();
 $objFiles->delete($runonceFile);
}

Nachteil dieser Variante, die ER Verwaltung meckert, das Modul sei unvollständig, da nun eine Datei fehlt.
Idee: die Datei nicht löschen sondern überschreiben:

$runonceFile = 'system/modules/MODULNAME/config/runonce.php'; // relativ zu TL_ROOT
if (file_exists(TL_ROOT . '/' . $runonceFile))
{
   $GLOBALS['runonce']['MODULNAME'] = false;
   include(TL_ROOT . '/' . $runonceFile);
   if ($GLOBALS['runonce']['MODULNAME'] === false) 
   {
       $objFiles = Files::getInstance();
       $objFiles->delete($runonceFile); // hier wird intern ein "TL_ROOT/" vorgesetzt
       //nun wieder neu anlegen mit neuem Inhalt
       $objFile = new File($runonceFile); // hier wird intern ein "TL_ROOT/" vorgesetzt
       $objFile->write("<?php \$GLOBALS['runonce']['MODULNAME'] = true; ?>");
       $objFile->close();
   }
}

Wobei man nun die file_exists Prüfung weglassen könnte.
Andererseits könnte man diesen Abschnitt immer im Modul lassen und nur durch Setzen der Variablen $runonceFile bestimmen, ob es was zu tun gibt oder nicht.

Probleme

Einen kleinen Nebeneffekt hat die ganze Sache. Egal ob die funktions- oder objektorientierte Variante, es kommt zu einer Fehlermeldung, sobald man die Datenbank Instanz nutzt.
Am Ende der Seite erscheint die Meldung:

Fatal error: Exception thrown without a stack frame in Unknown  on line 0

Das Script selbst wird dabei ohne Probleme abgearbeitet, auch das Backend selbst wird dadurch nicht gestört.

Anmerkung: Lösung hier bitte angeben oder an BugBuster melden, Danke

--BugBuster 19:18, 17. Jul. 2010 (CEST)