Page 4 of 8

Re: TEST: Template "fhs-left-right-17x"

Posted: Tue Feb 27, 2018 2:58 pm
by cmb
olape wrote:
Tue Feb 27, 2018 2:43 pm
Was ich dann aber immer noch nicht ganz verstehe, warum es, bei zwei mir bekannten Seite, unter 1.6.10 und 1.7.2 funktioniert.
Da muss es ja noch einen Unterschied geben.
Das Zurücksetzen erfolgt erst seit XH 1.7. Bei der 1.7.2 Site kann ich mir vorstellen, dass das JS immer eingebunden wird (eventuell per Konfiguration, oder durch Aufruf im Template).

Re: TEST: Template "fhs-left-right-17x"

Posted: Tue Feb 27, 2018 3:43 pm
by cmb
olape wrote:
Tue Feb 27, 2018 2:24 pm
frase wrote:
Tue Feb 27, 2018 11:10 am
Mit dem Scrollrad ist es wirklich bei viel Inhalt mühselig.
Ich weiss ja nicht, mit was du das testest. Aber Firefox ist gefühlt noch wesentlich schlimmer als Chrome, Edge oder IE.
Hm, ich habe hier im Chrome keinerlei Probleme bezüglich Mausrad-Scrolling, selbst wenn der Viewport nur 100-200 Pixel hoch ist. Das kann aber auch mit der jQuery-Version zu tun haben. Andererseits frage ich mich aber schon, warum zum Scrollen überhaupt JavaScript eingesetzt wird.

Re: TEST: Template "fhs-left-right-17x"

Posted: Tue Feb 27, 2018 5:10 pm
by olape
cmb wrote:
Tue Feb 27, 2018 2:58 pm
Bei der 1.7.2 Site kann ich mir vorstellen, dass das JS immer eingebunden wird (eventuell per Konfiguration, oder durch Aufruf im Template).
Bei beiden Seiten ist Shariff im Template eingebunden. Weitere Optionen um das Script einzubinden gibt es nicht.
JQuery muss für das Einbinden im Template auf autoload stehen. Andere Optionen in der Richtung gibt es nicht.
cmb wrote:
Tue Feb 27, 2018 3:43 pm
Hm, ich habe hier im Chrome keinerlei Probleme bezüglich Mausrad-Scrolling, selbst wenn der Viewport nur 100-200 Pixel hoch ist. Das kann aber auch mit der jQuery-Version zu tun haben. Andererseits frage ich mich aber schon, warum zum Scrollen überhaupt JavaScript eingesetzt wird.
Welche Seite? meine Spielwiese, oder Franks Demo?
Chrome, das hatte ich ja schon geschrieben, geht besser als Firefox.

Die ganze Arie an JS und CSS ist wohl der Sache geschuldet (meine Vermutung), dass man für Firefox, IE, Edge die Scrollbars nicht stylen kann.
Und damit es überall gleich aussieht ...
Bei mir habe ich es erst mal rausgeschmissen.
Sieht jetzt in den benannten Browsern nicht mehr ganz so toll aus, funktioniert aber besser.
Für Chrome kann man ja ein wenig stylen

Re: TEST: Template "fhs-left-right-17x"

Posted: Tue Feb 27, 2018 6:14 pm
by cmb
olape wrote:
Tue Feb 27, 2018 5:10 pm
cmb wrote:
Tue Feb 27, 2018 2:58 pm
Bei der 1.7.2 Site kann ich mir vorstellen, dass das JS immer eingebunden wird (eventuell per Konfiguration, oder durch Aufruf im Template).
Bei beiden Seiten ist Shariff im Template eingebunden. Weitere Optionen um das Script einzubinden gibt es nicht.
JQuery muss für das Einbinden im Template auf autoload stehen. Andere Optionen in der Richtung gibt es nicht.
Das ist seltsam, denn Script-Aufrufe im Template interessiert die Suche eigentlich nicht (da geht es nur um Pluginaufrufe auf einer Inhalts-Seite). Ich könnte mir allerdings vorstellen, dass auf der Site, bei der es nicht funktioniert, irgendwo im Content einen weiten Pluginaufruf gibt – der würde $op_js_count auf 1 setzen, und da wird das <script> Element eben nicht mehr ausgegeben. Schmeiß doch zu Testzwecken die Prüfung auf $op_js_count (index.php:265) mal raus.
olape wrote:
Tue Feb 27, 2018 5:10 pm
cmb wrote:
Tue Feb 27, 2018 3:43 pm
Hm, ich habe hier im Chrome keinerlei Probleme bezüglich Mausrad-Scrolling, selbst wenn der Viewport nur 100-200 Pixel hoch ist. Das kann aber auch mit der jQuery-Version zu tun haben. Andererseits frage ich mich aber schon, warum zum Scrollen überhaupt JavaScript eingesetzt wird.
Welche Seite? meine Spielwiese, oder Franks Demo?
Ah, das war deine Spielwiese – höchst wahrscheinlich nachdem du das JS deaktiviert hattest. Wenn ich bei Franks Demo am Rad drehe, dann drehe ich am Rad.

Re: TEST: Template "fhs-left-right-17x"

Posted: Tue Feb 27, 2018 6:36 pm
by olape
cmb wrote:
Tue Feb 27, 2018 6:14 pm
Ich könnte mir allerdings vorstellen, dass auf der Site, bei der es nicht funktioniert, irgendwo im Content einen weiten Pluginaufruf gibt – der würde $op_js_count auf 1 setzen, und da wird das <script> Element eben nicht mehr ausgegeben. Schmeiß doch zu Testzwecken die Prüfung auf $op_js_count (index.php:265) mal raus.
Na der Ansatz ist schon mal richtig.
Wenn ich die Prüfung $op_js_count rausnehme, dann funktioniert es.
Aber, dann habe ich das Script unter https://new.penschke.net/?CMSimple_XH/P ... Shariff_XH 5x drin.
Deshalb gibt es ja den Counter.

$op_js_count = '1', woher sollte das kommen?
Ich habe ja schon, genau wegen solcher Erfahrungen, eine recht "exotischen" Variablennamen gewählt.
Es gibt in der gesamten Installation nur diese eine Stelle mit dieser Variable.

Re: TEST: Template "fhs-left-right-17x"

Posted: Tue Feb 27, 2018 6:45 pm
by olape
Aber, ich hätte eine Theorie.

Wenn die Suche alle Seiten inkl. aller Pluginausgaben durchgeht, dann könnte dadurch, dass dabei die Seiten Shariff_XH und Backend für Shariff aufgerufen werden, der Counter schon gesetzt werden. So wird er dann nachher in der eigentlichen Ausgabe nicht mehr gesetzt, weil das Plugin der Meinung ist, hab ich schon.

Re: TEST: Template "fhs-left-right-17x"

Posted: Tue Feb 27, 2018 10:00 pm
by cmb
olape wrote:
Tue Feb 27, 2018 6:45 pm
Wenn die Suche alle Seiten inkl. aller Pluginausgaben durchgeht, dann könnte dadurch, dass dabei die Seiten Shariff_XH und Backend für Shariff aufgerufen werden, der Counter schon gesetzt werden. So wird er dann nachher in der eigentlichen Ausgabe nicht mehr gesetzt, weil das Plugin der Meinung ist, hab ich schon.
Ja, genauso ist es wohl. Und das zeigt dann auch sehr schön, dass die automatische Auswertung der Pluginaufrufe bei der Suche eben so oder anders nicht unproblematisch ist. Als Lösungsansatz fällt mir eigentlich nur ein, dass man um die Pluginaufrufauswertung während der Suche ein globales Flag setzt, welches in der Pluginfunktion abgefragt werden könnte. Etwa:

Code: Select all

        $GLOBALS['xh_searching'] = true;
        $content = strip_tags(evaluate_plugincall($content));
        unset($GLOBALS['xh_searching']);
Bei Shariff_XH, wo es ja eigentlich nichts zu suchen gibt, könnte man dann zu Beginn von op_shariff() folgendes einfügen:

Code: Select all

if (isset($GLOBALS['xh_searching']) && $GLOBALS['xh_searching']) return;

Re: TEST: Template "fhs-left-right-17x"

Posted: Wed Feb 28, 2018 7:50 am
by olape
cmb wrote:
Tue Feb 27, 2018 10:00 pm
olape wrote:
Tue Feb 27, 2018 6:45 pm
Wenn die Suche alle Seiten inkl. aller Pluginausgaben durchgeht, dann könnte dadurch, dass dabei die Seiten Shariff_XH und Backend für Shariff aufgerufen werden, der Counter schon gesetzt werden. So wird er dann nachher in der eigentlichen Ausgabe nicht mehr gesetzt, weil das Plugin der Meinung ist, hab ich schon.
Ja, genauso ist es wohl. Und das zeigt dann auch sehr schön, dass die automatische Auswertung der Pluginaufrufe bei der Suche eben so oder anders nicht unproblematisch ist. Als Lösungsansatz fällt mir eigentlich nur ein, dass man um die Pluginaufrufauswertung während der Suche ein globales Flag setzt, welches in der Pluginfunktion abgefragt werden könnte. Etwa:

Code: Select all

        $GLOBALS['xh_searching'] = true;
        $content = strip_tags(evaluate_plugincall($content));
        unset($GLOBALS['xh_searching']);
Bei Shariff_XH, wo es ja eigentlich nichts zu suchen gibt, könnte man dann zu Beginn von op_shariff() folgendes einfügen:

Code: Select all

if (isset($GLOBALS['xh_searching']) && $GLOBALS['xh_searching']) return;
So würde es funktionieren.
Und die Suche müsste nicht auf die vollständige Ausführung der Plugins warten, bei denen es eh nix zu holen gibt.
Bleibt dann nur das alte Problem. Die Plugins müssen mitspielen.

Re: TEST: Template "fhs-left-right-17x"

Posted: Wed Feb 28, 2018 11:49 am
by olape
cmb wrote:
Tue Feb 27, 2018 10:00 pm
olape wrote:
Tue Feb 27, 2018 6:45 pm
Wenn die Suche alle Seiten inkl. aller Pluginausgaben durchgeht, dann könnte dadurch, dass dabei die Seiten Shariff_XH und Backend für Shariff aufgerufen werden, der Counter schon gesetzt werden. So wird er dann nachher in der eigentlichen Ausgabe nicht mehr gesetzt, weil das Plugin der Meinung ist, hab ich schon.
Ja, genauso ist es wohl. Und das zeigt dann auch sehr schön, dass die automatische Auswertung der Pluginaufrufe bei der Suche eben so oder anders nicht unproblematisch ist. Als Lösungsansatz fällt mir eigentlich nur ein, dass man um die Pluginaufrufauswertung während der Suche ein globales Flag setzt, welches in der Pluginfunktion abgefragt werden könnte. Etwa:

Code: Select all

        $GLOBALS['xh_searching'] = true;
        $content = strip_tags(evaluate_plugincall($content));
        unset($GLOBALS['xh_searching']);
Bei Shariff_XH, wo es ja eigentlich nichts zu suchen gibt, könnte man dann zu Beginn von op_shariff() folgendes einfügen:

Code: Select all

if (isset($GLOBALS['xh_searching']) && $GLOBALS['xh_searching']) return;
Funktioniert prima

https://new.penschke.net/?search=plugin&function=search

Re: TEST: Template "fhs-left-right-17x"

Posted: Wed Feb 28, 2018 12:15 pm
by cmb
olape wrote:
Wed Feb 28, 2018 7:50 am
So würde es funktionieren.
Und die Suche müsste nicht auf die vollständige Ausführung der Plugins warten, bei denen es eh nix zu holen gibt.
Bleibt dann nur das alte Problem. Die Plugins müssen mitspielen.
Ja, das ist das Problem. Und ich würde ungern eine solche Änderung einführen ohne auch gleich eine API anzubieten, so dass Plugins zusätzliche Suchergebnisse liefern können. Details sollten aber in einem anderen Thread diskutiert werden – diesen haben wir wohl ohnehin schon zu sehr gekapert.