Search issues in 3.2.11

[Kevin]

Noticed that when I use Search, it now displays previous search info before I enter anything.  This is especially weird after using index and then clicking on search, when I get to the search form, it displays a bunch of indexing information.

Spacing seems to be influenced as well since it uses <p> ... </p> between each entry and a <br /> as well.  So there are large gaps between each entry.  It used to only use <br />

In 3.2.9 output looked like:

<a href="http://www.somesite.com/login" >login</a> > <a href="http://www.somesite.com/login/donna" >donna</a><br />
<a href="http://www.somesite.com/login" >login</a> > <a href="http://www.somesite.com/login/greg" >greg</a><br />

Now in 3.2.11 it looks like:

<p><a href="http://www.somesite.com/login" >login</a> > <a href="http://www.somesite.com/login/donna" >donna</a></p>
<br />
<p><a href="http://www.somesite.com/login" >login</a> > <a href="http://www.somesite.com/login/greg" >greg</a></p>
<br />

I seem to loose the bottom zone as well, so that I end up with a normal looking page, but no bottom section.  This might be something to do with my configuration though.

[JJ]

On Nov 4, 9:45 am, Kevin <tnet.servi...@gmail.com> wrote:
> Noticed that when I use Search, it now displays previous search info before
> I enter anything.  This is especially weird after using index and then
> clicking on search, when I get to the search form, it displays a bunch of
> indexing information.
>

I'm on 3.2.10 and have the same search symptoms.
Stuff is there from previous search.

[The Editor]

I'm not sure this is new behavior. It has been this way for a good
long while. Basically your search query gets stored as a session
variable, so if you go back to a page with a search form on it, you
can see the last query results you entered. This allows you to check
several links and keep going back to your search list without having
to regenerate the list.However, I don't think the output of one search
box should show up on a different page. If that is happening we need
to key the session variable to the page or something.

Please confirm... I should also note, no one else should see the
results of your query. It's keyed to the one who did the query.

Cheers,
Dan

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "BoltWire" group.
> To post to this group, send email to bolt...@googlegroups.com
> To unsubscribe from this group, send email to boltwire+u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/boltwire?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>

[JJ]

Dan:

for me it's still an issue on 3.3

Also, search results have extra "</br>"s now?

I confirmed that I am the only one that sees the previous search
results.
I have 1 other user and he didn't see this issue **until** he used the
search function, then he saw the same
affect.

Thanks. :)

On Nov 12, 5:49 pm, The Editor <edi...@fast.st> wrote:
> I'm not sure this is new behavior. It has been this way for a good
> long while. Basically your search query gets stored as a session
> variable, so if you go back to a page with a search form on it, you
> can see the last query results you entered. This allows you to check
> several links and keep going back to your search list without having
> to regenerate the list.However, I don't think the output of one search
> box should show up on a different page. If that is happening we need
> to key the session variable to the page or something.
>
> Please confirm... I should also note, no one else should see the
> results of your query. It's keyed to the one who did the query.
>
> Cheers,
> Dan
>

[Kevin]

The extra <br />'s are still in 3.3 as well.

I took a quick gander looking to see if I could see where it is being added, but didn't see anything that stood out.

I also did a compare between a version that doesn't do this and one that does, but the change appears to have been done outside of the search routines themselves.  ie I didn't spot anything.

[The Editor]

You are right about the search results not being linked to one page. I
will fix that for the next release. Strange though. The LASTQUERY
variable seems to be connected to $pageLink already. Not sure why it
is happening. Odd...

As for the line spacing, can you give me a simple search and template
doing this. The default search template on my site seems to generate
nice <br /> at the end of each line and no <p> tags. If I can
reproduce the problem, I should be able to track the issue down easily
enough.

Cheers,
Dan

[Kevin]

It used to be just <br />'s now it has everything surrounded by <p>'s and a <br/> added to the end of each entry.

My first post included:

In 3.2.9 output looked like:

<a href="http://www.somesite.com/login" >login</a> > <a href="http://www.somesite.com/login/donna" >donna</a><br />
<a href="http://www.somesite.com/login" >login</a> > <a href="http://www.somesite.com/login/greg" >greg</a><br />

Now in 3.2.11 it looks like:

<p><a href="http://www.somesite.com/login" >login</a> > <a href="http://www.somesite.com/login/donna" >donna</a></p>
<br />
<p><a href="http://www.somesite.com/login" >login</a> > <a href="http://www.somesite.com/login/greg" >greg</a></p>
<br />

3.3 is doing the same as 3.2.11 which is causing extra space between each entry.

it happens for every search output.

[The Editor]

Can you give me the markup and template that is producing this output?
I'm not getting the paragraph tags on a normal default search.

Cheers,
Dan

[Kevin]

I am using the system default page for both it (action.search) and templates and markup.

I am overriding some markup in my config.php file for only <hr> like:

# Overrule Markup rules
MarkUp('style', 'hr', '/\n?(&lt;|<)hr(&gt;|>)\n?/', '<hr />'); // hr  horizontal line

Other than that, it should be stock as as what is sent out in the 3.3 code.

--

You received this message because you are subscribed to the Google Groups "BoltWire" group.

To post to this group, send email to bolt...@googlegroups.com.
To unsubscribe from this group, send email to boltwire+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/boltwire?hl=.

[The Editor]

Ok, I see the problem now. I'll look into it and get back to you.
Thanks for pointing this out.

Cheers,
Dan

[The Editor]

Ok, I've been looking at this Kevin, and while one fix is easy, it
opens up a can with a couple other worms. Here's the scoop (that is,
I'm just thinking out loud at this point...):

First, the domarkup function has this line:

if ($zone != '' && $zone != 'SKIN') $out = $out . "\n\n";

You'll see the \n\n used to generate paragraph tags are blocked by
$zone being set to '' or SKIN. When the BOLTdisplayTemplate calls the
domarkup function, it sets the zone to the current zone, which causes
the \n\n to be inserted.

Easy solution: go through the BOLTdisplayTemplate (engine.php 666+)
and change the $zone parameters in the various domarkup function calls
to ''. Problem solved. To make it even easier, we could change the
SKIN call to '' and then just have this in domarkup:

if ($zone != '') $out = $out . "\n\n";

However, what if I want to know the $zone? Perhaps I have a custom
function used in a search template that displays output differently in
the side bar vs the main zone? So my next thought was how about this:

if ($zone == strtolower($zone)) $out = $out . "\n\n";

Then SKIN is ok, and I could do strtoupper($zone) in the
displayTemplate function. So I'd have access to the zone, just upper
case.

But then after some fiddling around I noticed the $zone variable is
not really available anyway. I have it passed to about a half dozen
markup rules as a parameter, (mostly to the functions) but it is never
used anywhere in the core. I was just thinking it might be useful info
for a custom script. So how do we get it to pass properly? If I
change the top few lines of domarkup to this we can get it to work:

function BOLTdomarkup($content, $page='', $zone='', $rules='',
$replace=true, $escape='') {
global $MarkUpTable, $BOLTrules, $Token, $BOLTvar, $pageLink,
$BOLTstripTags, $BOLTmsgOut, $lastquery, $query, $BOLTzone;
$BOLTzone = $zone;

Then we have a global $BOLTzone variable to your functions. Of course
this means all those $zone='' parameters in the various functions are
irrelevant, likewise the markup rules with a zone parameter. And they
should be scrapped. And if I use the lowercase test for adding \n\n I
need to check there are no domarkup functions that pass a '' zone
parameter. Well, perhaps I could just leave both checks in for now...

Ok, so that's the plan.

1) Add the global $BOLTzone to the domarkup function.
2) Use this line as the test for adding \n\n
if ($zone != '' && $zone == strtolower($zone)) $out = $out . "\n\n";
3) I left all the $zone parameters in the displayTemplate calls to
domarkup, but added this line around 688. This way I get the zone, but
not \n\n.
$zone = strtoupper($zone);
4) Now I'm going through and stripping out the $zone markups out of
the markup rules, and the various markup functions that use them.
5) Actually, just added global $BOLTzone to BOLTMfunc and changed
$zone to strtolower($BOLTzone) in the last line, and that now works!
6) Similarly, fixed the BOLTMrules by using the global BOLTzones.

There was one slight problem with all this fixing I encountered.
Currently the BOLTvars function takes a $zone variable as the second
parameter, but it is nonfunctional and only used for system/zone
variables (bet you didn't even know those were possible). So
logically, that parameter should be replaced with a call to the
global, and the $auth parameter bumped up to second place. But this
could break functions that use the $auth function. In all the core,
there are 27 calls to BOLTvars, and only 2 (both in the BOLTXlogin
function) use it. They are easy enough to change. But I'm concerned
there may be custom plugins out there that will be affected. However,
I don't see any way quite around it.

There is another problem I anticipate. Suppose you are in the main
zone and you have a function using the $BOLTzone variable. But there
is a search function or something that changes the zone... Then
because it is global you have a problem... We could perhaps do
$BOLTzone = strotolower($zone); at the end of BOLTdomarkup. Or store
the previous value in a temp location. That would restore it. And
there's no reason I can't pass strtolower($zone) out of the BOLTMfunc
function... So we get nice zone behavior in functions, as expected.

For that matter, we need to make sure we use strtolower in the
BOLTvars and BOLTMrules functions or we could miss the zone in a
search template. Ok, it's all coming together now. And working on my
system. At least on every test I can come up with.

Kind of a quirky solution to a very simple problem, but I prefer the
idea of fixing it properly and not losing functionality of zone
specific behavior, even if it is not currently being used to my
knowledge, and it didn't work like it was supposed to anyway before.
The only disadvantage is plugins might break that rely on the $auth
parameter in the BOLTvars function to bypass permissions for special
purposes. All this will be in the next release.

Cheers,
Dan