Droplets im Template werden auf Suche-Seite nicht ausgeführt

[instantflorian]

...sondern erscheinen einfach als [[dropletname]]

[WebDesignWorx]

Ist dieser Bug neu hinzugekommen? Oder war der in älteren Versionen auch schon vorhanden? Ggf. müsste @mrbaseman schauen, ob der OutputFilter da greift. Wenn nicht, gibt es außer Droplets auch etwaige andere Probleme. Bin bis zum WE leider nicht wirklich verfügbar.

[mrbaseman]

Fehlt beim Droplet-Filter das Häkchen für Suchresultate? müssen wir ggf. bei der Installation/Update automatisch aktivieren

[instantflorian]

Der Bug ist neu. Das Häkchen war nicht gesetzt, aber auch wenn es gesetzt ist, besteht das Problem weiterhin.

[ghost]

Wurde das Häckchen auch in der DB gesetzt? Klingt verdächtig ähnlich dem Problem das ich habe.

[instantflorian]

doch, irgendwas tut sich da, so weit ich das sehe, schon.

[ghost]

War auf dieser Seite bereits eine 1.4.dev vorhanden oder war das ein upgrade einer 1.3.3 Installation?

[instantflorian]

ist ein update von 1.3.3

[dev4me]

The search routine will never know what the droplet will output. It could generate lots of text or even a complete gallery. It could even replace text of other results! Therefore it is not safe to evaluate the dropletcode in the search results. This is the standard since the new-search in WB2.7

Some rules...

1. The result-content of a droplet is never searched, droplets are not executed in the search.php of modules.
2. The droplet name could be found in the searchdata (it is just text). That could be done better!
3. The [[ and ]] are stripped from result excerpts (leaving the droplet name in there) so droplets cannot be evaluated anymore.

[instantflorian]

Hi Ruud, I think you're misunderstanding (my fault, I should have posted in english). The problem is not the search routine or search results themselves. But I have to clarify the issue description anyway.

On any page which has no page id, for example the search results (search/index.php) or the frontend profile page (/account/preferences.php), droplets, which are called in the frontend template, are not executed. I.E. if you have in your template/index.php the call [[oneliner]], the oneliner droplet will be executed as expected on any usual output page, but not on the "special" pages,

[instantflorian]

So a quick & dirty fix seems to be: in the modules/mod_opf_droplets/filter.php before // check file and include

add if ($page_id==0) {$page_id='frontend';}

Can I do this that way?

[ghost]

Könnte sein dass ich das Problem gefunden habe, dazu mehr im interna

[mrbaseman]

The Droplet filter (currently) is of type 'Page' and for some reason these filters seem not to be applied to searchresults anymore. I'm still puzzled why this is not the case. I thought that the search mechanism includes the index.php the same way as regular pages do, so those filters should be applied in index.php. Another issue is: why isn't searchresults checked by default when you upgrade an installation? Even if the page filters were called properly, without the checkbox for searchesults being checked the filter would not be applied to the output of a search request.

[mrbaseman]

For the second part I have a fix: just update pages_parent in the install.php: 'pages_parent' => 'all,backend,0' but still, the filter has to be executed for that case

[mrbaseman]

I have to double check the proposal of https://github.com/WBCE/WBCE_CMS/issues/428#issuecomment-507717224

[instantflorian]

Hm, the workaround https://github.com/WBCE/WBCE_CMS/issues/428#issuecomment-507717224 breaks the droplet module backend. Bad luck.

[mrbaseman]

without having the possibility to test at the moment I would suggest to test if the === operator makes things better on line 63 of the droplet filter: $content = evalDroplets($content, (($page_id === 'backend') ? 'backend' : 'frontend'));

[instantflorian]

Bingo, that does the trick.

[mrbaseman]

@instantflorian ich hab übersehen dass du den Fix upstream schon drin hattest. Ich hab noch das Changelog aktualisiert - und ich Schussel hab auch vergessen die Versionsnummer durchgängig anzupassen, also noch ein Commit, aber den eigentlich funktionalen Fix hattest du ja schon committed.