Plugins causing problems during search
Plugins causing problems during search
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
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
Christoph M. Becker – Plugins for CMSimple_XH
Re: Introduce option to disable script evalutation for searc
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
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
Re: Introduce option to disable script evalutation for searc
I agree. I'll try to track the issue down.svasti wrote:I'd really rather prefer that the problem was understood and solved
Christoph M. Becker – Plugins for CMSimple_XH
Re: Plugins causing problems during search
We had success, and the problem has been found: an unfortunate constellation of calling lb_gallery() too often.cmb wrote:I agree. I'll try to track the issue down.
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.
Christoph M. Becker – Plugins for CMSimple_XH
Re: Plugins causing problems during search
An easy solution would becmb wrote: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.
Code: Select all
function myplugin() {
global $s, ...
if($s < 0) return;
do something;
return result;
}
Re: Plugins causing problems during 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.svasti wrote: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.
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);
}
Christoph M. Becker – Plugins for CMSimple_XH
Re: Plugins causing problems during search
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.
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.
Re: Plugins causing problems during search
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.svasti wrote:It would even be better if following the link from the search results the corresponding Expandcontract would open automatically.
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'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 wrote:I'd propose to consider this change in search.php for the next XH version.
Christoph M. Becker – Plugins for CMSimple_XH
Re: Plugins causing problems during search
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 wrote:I think this requires much more testing (for instance, there may be plugins which get confused when called multiple times with different $s).
Re: Plugins causing problems during search
If we wait until XH 1.7, at least some of the testing could be done by the beta testers.svasti wrote:Who could do the testing?
If I only had the time (I'm estimating roughly 5 hours for 50 plugins only for the most basic checking).svasti wrote:At the moment you are the most prolific plugin writer... so you could check your plugins.
Miniblog uses $s to get the category and blog pages.svasti wrote:I don' think there'll be any problem with mylittle plugins.
Christoph M. Becker – Plugins for CMSimple_XH