Plugins causing problems during search

[cmb]

Hello Community,

Hartmut reported problems with CMSimple_XH's online search functionality. The exact cause couldn't be found, but obviously it is related to the script evaluation.

It might be a good idea to introduce a config option so a user can disable the script evaluation for the search. It might be reasonable to hide this option (it's probably not needed by many installations), and maybe a good name would be $cf['search']['disable_scripting'].

Thoughts?

Christoph

[svasti]

Not really a fan of that many hidden options, especially that we do have a small problem keeping documenting up to date.
I'd really rather prefer that the problem was understood and solved, or that in such cases the core would automatically change the search functionality accordingly

[cmb]

I'd really rather prefer that the problem was understood and solved

I agree. I'll try to track the issue down.

[cmb]

I agree. I'll try to track the issue down.

We had success, and the problem has been found: an unfortunate constellation of calling lb_gallery() too often.

However, another issue had been found, which was related to Register_XH. Because the search evaluates all plugin calls, the access protection ({{{access();}}}) will be triggered, and so the searching visitor will be redirected to the "Access forbidden" page. I will make a bugfix available ASAP.

And there is a more general problem, probably affecting several plugins: the use of $s. Normally, this holds the index of the current page (i.e. where the plugin is called), but during the search $s == -1. If a plugin uses $s during the search, this is likely to result in undesired behavior. I suggest to check all plugins for this use, and to try to work around the issue. If that is not possible, it might be best to simply bail out of the function, if $s < 0.

[svasti]

the use of $s. Normally, this holds the index of the current page (i.e. where the plugin is called), but during the search $s == -1.

An easy solution would be

Code: Select all

function myplugin() {
    global $s, ...
    if($s < 0) return;
    do something;
    return result;
} 

but what about the search? For instance it would be nice if the quote of Quoteoftheday would be in the search results. I just checked, the quote is indeed in the seach results, because the plugin doesn't use $s ! I wonder if there would be a possibility for a plugin to retain the original value of $s, when $s has become -1 because of the search.

[cmb]

I wonder if there would be a possibility for a plugin to retain the original value of $s, when $s has become -1 because of the search.

It would be possible to set the global $s when iterating over the pages during the search, and reset $s afterwards to -1. I'm not sure, though, if that won't bring undesired side-effects. At least we'd have to test this with many plugins.

A patch:

Code: Select all

Index: Search.php
===================================================================
--- Search.php	(revision 3)
+++ Search.php	(working copy)
@@ -123,7 +123,7 @@
         foreach ($c as $i => $content) {
             if (!hide($i) || $cf['show_hidden']['pages_search'] == 'true') {
                 $found  = true;
-                $content = $this->prepareContent($content);
+                $content = $this->prepareContent($content, $i);
                 foreach ($words as $word) {
                     if (utf8_stripos($content, $word) === false) {
                         $found = false;
@@ -141,15 +141,20 @@
     /**
      * Prepares content to be searched.
      *
-     * @param string $content A content.
+     * @param string $content   A content.
+     * @param string $pageIndex A page index.
      *
      * @return string
      *
      * @access protected
      */
-    function prepareContent($content)
+    function prepareContent($content, $pageIndex)
     {
+        global $s;
+
+        $s = $pageIndex;
         $content = strip_tags(evaluate_plugincall($content));
+        $s = -1;
         if (method_exists('Normalizer', 'normalize')) {
             $content = Normalizer::normalize($content);
         }

[svasti]

Wow, it works... with Expandcontract.

It would even be better if following the link from the search results the corresponding Expandcontract would open automatically.

I'd propose to consider this change in search.php for the next XH version.

[cmb]

It would even be better if following the link from the search results the corresponding Expandcontract would open automatically.

I agree. However, that would require the plugin(s) to actively participate in the search (by means of an API). That would offer great possibilities to expand the built-in search to Realblog_XH (has its own search), Forum_XH (isn't searchable at all) and Coco_XH (offers an optional replacement for searchbox()), for instance.

Some ideas regarding the API off the top of my head: plugins could register that they want to participate in the search, and if so they are passed the search words, and they return the search results in a structured manner (i.e. not HTML, but rather a list of object or records). Afterwards the core should sort the all plugins' and content search results, and present them appropriately. For plugins that have registered for the search, their plugin calls could be disabled to avoid duplicate search results.

I'd propose to consider this change in search.php for the next XH version.

I'm not against it, but I think this requires much more testing (for instance, there may be plugins which get confused when called multiple times with different $s).

[svasti]

I think this requires much more testing (for instance, there may be plugins which get confused when called multiple times with different $s).

Who could do the testing? We could check first which plugins use $s, to narrow the testing. It seems there are a little less than 80 plugins active at the moment according to Hartmut's list. At the moment you are the most prolific plugin writer... so you could check your plugins. I don' think there'll be any problem with mylittle plugins.

[cmb]

Who could do the testing?

If we wait until XH 1.7, at least some of the testing could be done by the beta testers.

At the moment you are the most prolific plugin writer... so you could check your plugins.

If I only had the time (I'm estimating roughly 5 hours for 50 plugins only for the most basic checking).

I don' think there'll be any problem with mylittle plugins.

Miniblog uses $s to get the category and blog pages.