Neu PHP in Plugin hinzufügen und von dort auf Datenbank/Variablen zugreifen

[Th3_J0k3]

Hallo,
Ich möchte von einer Form in einem FrontendLink ein externes PHP Script ausführen, welches im Frontend Ordner liegt:

<form action="{$oPlugin->cFrontendPfadURL}submit_form.php">
    <input type="submit">
</form>

Das funktioniert auch sehr gut, nur stellt sich das Problem, dass von dieser PHP Datei aus auf keine globalen Variablen zugegriffen werden kann.
z.B. wird folgendes nicht ausgeführt:

<?php
    echo $oPlugin->cName;
?>

Kann ich die PHP Datei irgendwie näher ins Plugin einbinden? Oder wie kann ich auch von dort auf solche Variablen zugreifen?
LG

 

[FPrüfer]

Hallo,
ein Frontendlink ist zunächst einmal eine normale Einsprungseite für den Shop und muss deshalb auch den Regeln dafür folgen. Mindestens sollte also die /includes/globalinclude.php inkludiert werden, um das "normale" Shop-Framework zur Verfügung zu haben.
Minimal könnte das also so aussehen:

<?php

use JTL\Plugin\Helper;

require_once __DIR__ . '/../../../includes/globalinclude.php';

$plugin = Helper::getPluginById('meinePluginID');

In $plugin hast du dann eine Instanz deines Plugins zur Verfügung.

 

[FPrüfer]

Wenn man es mehr Klassenorientiert mag und eigenen Content im Inhaltsbereich des Shops anzeigen möchte, dann hat man mit dem Plugin-Bootstrapping von Shop5 auch noch die Möglichkeit die Methode prepareFrontend zu nutzen. Dazu wird in der info.xml der Knoten Filename weggelassen.

<FrontendLink>
    <Link>
        <Name>Testlink</Name>
        <Template>testlink.tpl</Template>
        <VisibleAfterLogin>N</VisibleAfterLogin>
        <PrintButton>N</PrintButton>
        <SSL>0</SSL>
        <LinkLanguage iso="GER">
            ...
        </LinkLanguage>
    </Link>
</FrontendLink>

In der eigenen Bootstrap-Klasse wird dann die Methode prepareFrontend überschrieben.

/**
 * @inheritDoc
 */
public function prepareFrontend(LinkInterface $link, JTLSmarty $smarty): bool
{
    parent::prepareFrontend($link, $smarty);
    if ($link->getTemplate() === 'testlink.tpl') {
        /* do some logic... */
        $myVar = 'Hello World...';
        $smarty->assign('greeting', $myVar)

        return true;
    }

    return false;
}

Mit diesem Verfahren, welches die Nutzung des Links HOOK_SEITE_PAGE_IF_LINKART ersetzt, braucht man sich dann nicht um das Laden des Shop-Framework zu kümmern, da dies bereits erfolgt ist. Vorrangig geeignet ist dies für Frontendlinks, die eigenen Content im Inhaltsbereich des Shops anzeigen.

 

[Steve Iva]

Hallo,
ein Frontendlink ist zunächst einmal eine normale Einsprungseite für den Shop und muss deshalb auch den Regeln dafür folgen. Mindestens sollte also die /includes/globalinclude.php inkludiert werden, um das "normale" Shop-Framework zur Verfügung zu haben.
Minimal könnte das also so aussehen:

<?php

use JTL\Plugin\Helper;

require_once __DIR__ . '/../../../includes/globalinclude.php';

$plugin = Helper::getPluginById('meinePluginID');

In $plugin hast du dann eine Instanz deines Plugins zur Verfügung.

Hierzu habe ich eine Frage:

require_once __DIR__ . '/../../../includes/globalinclude.php';

kann ich da nicht einfach sagen:

use JTL\Shop;

 

[FPrüfer]

Nein, das funktioniert nicht. includes/globalinclude.php muss auch in Shop5 explizit inkludiert werden, da darüber u.a. der Autoload-Mechanismus initialisiert wird, ohne den das use nicht funktioniert.

 

[Steve Iva]

Danke für die schnelle Antwort!

D.h. im Umkehrschluss: ich muss das includes/globalincludes.php IMMER mindestens einmal inkludieren, um die anderen, von JTL vorgegebenen, Namespaces, wie zum Beispiel
JTL\Plugin\Bootstrapper, JTL\Events\Dispatcher, JTL\Smarty\JTLSmarty nutzen zu können... richtig?

 

[FMoche]

Ja. Aber das gilt wie gesagt nur, wenn du ein GET- oder POST-Request direkt an eine PHP-Datei senden willst, ohne den Shop dazwischen zu nutzen.
Bei der Lösung über die info.xml oder über prepareFrontend() in der Bootstrap.php nicht.

Es gibt eigentlich fast keinen Grund, sich das selbst zu bauen.

 

[FPrüfer]

Hinzu kommt noch, dass das direkte Ausführen von PHP-Dateien im /plugin-Verzeichnis grundsätzlich per .htaccess verboten ist. Die Verwendung solcher direkten Aufrufe

<form action="{$oPlugin->cFrontendPfadURL}submit_form.php">
    <input type="submit">
</form>

unter Umgehung eines Shop-Frontenlinks erfordert immer auch eine Konfigurationsänderung bzw. eine eigene Plugin-.htaccess die den direkten Aufruf dieser Datei wieder erlaubt.
Es gibt also nicht nur fast keinen Grund sich das selbst zu bauen, sondern auch mehrere gute Gründe die explizit dagegen sprechen.

 

[Steve Iva]

Hierzu habe ich noch eine Frage. Ich habe aktuell 2 dropdowns, deren <option> beide via SQL queries befüllt werden. Problem hier ist, dass das erste Dropdown die SQL Query für das zweite Dropdown parametrisieren soll. Sprich, in Abhängigkeit zur Auswahl des Nutzers in erstem Dropdown, soll dann das zweite dynamisch befüllt werden. Beispiel: Wenn jemand in Dropdown 1 die Farbe "ROT" auswählt, soll das zweite Dropdown nur die T-Shirts in ROT anzeigen. Initiales Vorladen und dann via JS Filtern geht leider nicht, weil die DB von uns tausende Einträge dazu hat.

Ich nutze hierfür AJAX, und feuer einen asynchronen Request ab, sobald der User im Dropdown etwas auswählt. Ich stoße aber aktuell auf das Problem, dass ich ein 403 forbidden Fehler bekomme, weil ich im AJAX dann entsprechend die .php Datei, die den SQL Query aufrufen soll, direkt ansprechen möchte. Das ist doch genau das, was ihr hier mit dem .htaccess beschreibt, richtig?

Ich habe gesehen, dass z.B. das JTL_search plugin das so machen möchte, wie ich es mache: https://gitlab.com/jtl-software/jtl-shop/plugins/jtl_search/-/blob/master/frontend/js/suggest.js

Habt ihr hier die .htaccess ändern müssen?

Wenn ihr hier eine Idee haben könntet, wie ich das hier besser (und ohne AJAX) lösen kann, lasst es mich bitte wissen.

Danke,
Steve

 

[FPrüfer]

Hallo Steve,
wenn du deine AJAX-Calls explizit an eine eigene PHP-Datei absetzen möchtest, dann musst du für dein Plugin eine eigene .htaccess mitliefern, die dafür eine Ausnahme definiert.
Der Shop stellt aber durchaus einen Weg für AJAX-Calls für Plugins zur Verfügung. Dazu kann der Hook HOOK_IO_HANDLE_REQUEST verwendet werden, um eigene IO-Listener zu registrieren. Dieser IO-Listener wird dann automatisch aufgerufen, wenn der AJAX-Call an /io.php im Shop-Root geht.
Rudimentär sieht das so aus:
Bootstrap.php deines Plugins

...
public function boot(Dispatcher $dispatcher): void
{
    ...
    $dispatcher->listen('shop.hook.' . \HOOK_IO_HANDLE_REQUEST, [$this, 'myIORequestListener']);
    ...
}
...
/**
 * @param array $args
 */
public function myIORequestListener(array $args): void
{
    /** @var IO $io */
    $io = $args['io'];
    try {
        $io->register('meine_plugin_id.meinAjaxCall', [$this, 'doMyAjaxCall']);
    } catch (Exception $e) {
       ... do some error handling
    }
}
...
/**
 * @param string $meineAjaxVariable
 * @return object
 */
public function doMyAjaxCall(string $meineAjaxVariable): object
{
    $result = new IOResponse();
    $result->assignDom('my-message-container span', 'innerHTML', $meineAjaxVariable);
    ...
    return $result;
}

JS in deinem Frontend-Template

$.evo.io().call(
    'meine_plugin_id.meinAjaxCall',
    {meineAjaxVariable: 'Hello world!'},
    {},
    function (error, data) {
        ... do some stuff if ajax call returns
    }
)

 

[Frank Hoffmeister]

@FPrüfer
Hallo, ich versuche schon seit mehreren Tagen, leider erfolglos, so einen io call in der Bootstrap für ein Childtemplate zu registrieren,
Hätten Sie da evtl auch eine Beispiel dafür?

Vielen Dank
Gruß Frank Hoffmeister

 

[FPrüfer]

Hallo,
über die Bootstrap eines Templates können keine Ajax-Endpoints registriert werden, da diese erst beim Initialisieren des Templates ausgeführt wird. Dieser Zeitpunkt ist für ein erfolgreiches Ajax-Routing viel zu spät. Hierzu sollte das eigene (Child-)Template besser mit einem zugehörigen Plugin kombiniert werden.

 

[andrenalin]

Hallo zusammen,

ich muss diese Thema noch einmal aufwecken da ich nun sehr lange suche und probiere.

Ich habe ein AlertPopup welches nach X mal schließen nicht mehr aufgehen soll, das funktioniert mit JS auf
einer Seite, sobald ich die Seite wechsle, wird neu gezählt.

Daher möchte ich das per Session tracken und abfragen, ich kann nur die Rückmledung nicht lesen. die Session wird gezählt.
Ob ich das per Object ioResponse oder als string mit json_encode zurückgebe, das Ergebnis bliebt gleich.
Ich habe verschiedenste Ansätze getestet, aber ich werde nicht schlauer.

public function boot(Dispatcher $dispatcher)
    {
        parent::boot($dispatcher);
        
        $dispatcher->listen('shop.hook.' . \HOOK_IO_HANDLE_REQUEST, [$this, 'registerAjaxCloseSessionChecker']);
        }

/**
     * @param array $args
     */
    public function registerAjaxCloseSessionChecker(array $args): void
    {
        /** @var IO $io */
        $io = $args['io'];
        try {
            $io->register('crispySocialProof.checkCloseStatus', [$this, 'checkCloseSession']);
        } catch (\Exception $e) {
        }
    }


    public function checkCloseSession($var): string
    {
        $ioResponse = new IOResponse();
        $_SESSION['scpCloseCounter']++;
        #if ($_SESSION['scpCloseCounter'] >= $_SESSION['scpStopLoop']) {
        if ($_SESSION['scpCloseCounter'] >= 20) {
            $isEnough = 'Y';
        } else {
            $isEnough = 'N';
        }
        $ioResponse->assignVar('isEnough', $isEnough);
        #return $ioResponse;
        return json_encode(['isEnough' => $isEnough]);
    }

    $.evo.io().call('crispySocialProof.checkCloseStatus', {'var':1}, this, function (error, data) {
            
        console.log(data);
          
            if (error) {
                console.log(error);
                loopActive = false;
                return;
            }
            if (data == 'Y') {
                loopActive = false;
            }
        }
    )

$var habe ich nur als Platzhalter gelassen, muss nicht genutzt werden.
Eventuell hat jemand eine Idee wie ich das fixen kann.

Vielen Dank!