Messy html source in searchresults when using tags.
Permalink 1 user found helpful
I have very messy html source when I click on tags and my search result page popups.
The strange things is that when I do a search with the searchbox the html-code looks oke.
What make's that results on tags make the source look like frontpage95 code?
HTML source looks like this:
<div class="searchResult">
<h3>link to blog item</h3>
<span style="background-color:#EFE795;"></span> <span style="background-color:#EFE795;"></span>C<span style="background-color:#EFE795;"></span>r<span style="background-color:#EFE795;"></span>a<span style="background-color:#EFE795;"></span>s<span style="background-color:#EFE795;">.....
The strange things is that when I do a search with the searchbox the html-code looks oke.
What make's that results on tags make the source look like frontpage95 code?
HTML source looks like this:
<div class="searchResult">
<h3>link to blog item</h3>
<span style="background-color:#EFE795;"></span> <span style="background-color:#EFE795;"></span>C<span style="background-color:#EFE795;"></span>r<span style="background-color:#EFE795;"></span>a<span style="background-color:#EFE795;"></span>s<span style="background-color:#EFE795;">.....
hi beebs,
I have seen some inlines styles here and there, but to me it looks like this line of PHP is not ably to see that there are words used as tags and not a messy string of individuel characters.
This is line 36 in the view.php of concrete\blocks\search.
Any help to get this to word in a nicer way?
I have seen some inlines styles here and there, but to me it looks like this line of PHP is not ably to see that there are words used as tags and not a messy string of individuel characters.
<?php echo $this->controller->highlightedMarkup($tt->shortText($r->getDescription()),$query)?>|
This is line 36 in the view.php of concrete\blocks\search.
Any help to get this to word in a nicer way?
The shortText and getDescription don't inject any inline CSS so the only thing you'll need to modify is the controller.php file of the search block.
As you probably already know, to make any changes to the core you simply need to copy the entire /concrete/blocks/search to the root /blocks folder. In this copy, I usually only keep the controller.php and view.php and delete the rest as I typically never need to edit them (and it helps reduce file clutter).
Starting at line 17 of controller.php:
As you can see, they are hardcoding the highlighted color in hex and placing it inline when they generate the HTML on the last line. It's tempting to just define your own color and be done with it, but 6 months down the road you'll probably forget how the **** you changed that and spend an hour digging through your code.
At work, any changes we make to the core have to be thoroughly documented for this very reason, unless we change it in such a way that adjusting it later doesn't require re-editing the core files.
Since documenting is a pain in the a$$ and time-consuming, I simply remove all the inline CSS, ignore the class property that defines the color and add my own class I can easily manipulate from an external CSS file:
As you probably already know, to make any changes to the core you simply need to copy the entire /concrete/blocks/search to the root /blocks folder. In this copy, I usually only keep the controller.php and view.php and delete the rest as I typically never need to edit them (and it helps reduce file clutter).
Starting at line 17 of controller.php:
protected $hColor = '#EFE795'; public function highlightedMarkup($fulltext, $highlight) { $this->hText = $fulltext; $this->hHighlight = str_replace(array('"',"'","""),'',$highlight); // strip the quotes as they mess the regex $this->hText = @preg_replace( "#$this->hHighlight#i", '<span style="background-color:'. $this->hColor .';">$0</span>', $this->hText ); return $this->hText; }
As you can see, they are hardcoding the highlighted color in hex and placing it inline when they generate the HTML on the last line. It's tempting to just define your own color and be done with it, but 6 months down the road you'll probably forget how the **** you changed that and spend an hour digging through your code.
At work, any changes we make to the core have to be thoroughly documented for this very reason, unless we change it in such a way that adjusting it later doesn't require re-editing the core files.
Since documenting is a pain in the a$$ and time-consuming, I simply remove all the inline CSS, ignore the class property that defines the color and add my own class I can easily manipulate from an external CSS file:
$this->hText = @preg_replace( "#$this->hHighlight#i", '<span class="hilite">$0</span>', $this->hText ); return $this->hText;
Thanks for the lessons, but still... my code (only with results on tags btw) looks like
Personally I think that looks very stupid.
<div id="searchResults"> div class="searchResult"><h3>title</h3> <p><span class="woot"></span><span class="woot"></span>D<span class="woot"></span>o<span class="woot"></span>n<span class="woot"></span>e<span class="woot"></span>c<span class="woot"></span> <span class="woot"></span>...
Personally I think that looks very stupid.
Hmm, it looks like the search block assumes there is always highlighted text to show thus it doesn't check for an empty string before wrapping those <span>s around it.
You could try injecting a simple logic check like so:
Line 19 of controller.php from this:
to this:
Give that a try and let me know :)
You could try injecting a simple logic check like so:
Line 19 of controller.php from this:
public function highlightedMarkup($fulltext, $highlight) { $this->hText = $fulltext; $this->hHighlight = str_replace(array('"',"'","""),'',$highlight); // strip the quotes as they mess the regex $this->hText = @preg_replace( "#$this->hHighlight#i", '<span style="background-color:'. $this->hColor .';">$0</span>', $this->hText ); return $this->hText; }
to this:
public function highlightedMarkup($fulltext, $highlight) { $this->hText = $fulltext; $this->hHighlight = str_replace(array('"',"'","""),'',$highlight); // strip the quotes as they mess the regex if(strlen($this->hHighlight) == 0) return ''; // Return empty string $this->hText = @preg_replace( "#$this->hHighlight#i", '<span style="background-color:'. $this->hColor .';">$0</span>', $this->hText ); return $this->hText; }
Give that a try and let me know :)
Did not do anything or much.
still gives me back
still gives me back
<span style="background-color:#EFE795;"></span> <span style="background-color:#EFE795;"></span>V<span style="background-color:#EFE795;">
Sorry, I meant to type:
public function highlightedMarkup($fulltext, $highlight) { $this->hText = $fulltext; $this->hHighlight = str_replace(array('"',"'","""),'',$highlight); // strip the quotes as they mess the regex if(strlen($this->hHighlight) == 0) return ''; // Return empty string $this->hText = @preg_replace( "#$this->hHighlight#i", '<span style="background-color:'. $this->hColor .';">$0</span>', $this->hText ); return $this->hText; }
That changed something ;)
But it is still not optimal:
Do you know of a website where the tags are generating a propper resultpage?
But it is still not optimal:
<p>........................<br/><span class="pageLink"></span></p>
Do you know of a website where the tags are generating a propper resultpage?
I don't typically use tags so I don't have a working example to show, however, I'd really like to get this looking perfect as I, too, hate empty tags in my markup if I can avoid it.
Can you take one of your pages and give me its specific tags and then tell me the exact search term you used?
Can you take one of your pages and give me its specific tags and then tell me the exact search term you used?
Starting from line 32 of the view.php of the search block, replace the "searchResult" div section with this:
<div class="searchResult"> <h3><a href="<?php echo $r->getPath()?>"><?php echo $r->getName()?></a></h3> <p> <?php echo ($currentPageBody ? $currentPageBody .'<br />' : '')?> <?php echo $this->controller->highlightedMarkup($tt->shortText($r->getDescription()),$query)?> <?php $strPageLink = $this->controller->highlightedMarkup($r->getPath(),$query); echo strlen($strPageLink) > 0 ? '<span class="pageLink">' . $strPageLink . '</span>' : ''; ?> </p> </div>
Still no change :(
see the url I have send you.
see the url I have send you.
Hmm, ok. I'll have to get a mock up going on my test server so I can play around with this more easily. Unless someone else beats me to it I'll let you know what I find.
Sorry for the delay as I've been busy with work :(
I set up a local test server, tinkered around and I hope I got it right this time:
Starting from line 29 of the view.php of the default search block, replace the "searchResults" div section with this:
This should be the only modification to the view.php of the search block and you don't need to modify the controller.php file at all so undo any changes you may have done before while you were debugging this.
Basically, searching by tag is not a normal text search query (duh, Brad). While the results are indeed pages thus they have a path and potentially a description and/or content, they are the result of searching by a specific attribute key and its corresponding value.
The ProBlog add-on does something very similar since it masquerades tag searches as category pages.
I set up a local test server, tinkered around and I hope I got it right this time:
Starting from line 29 of the view.php of the default search block, replace the "searchResults" div section with this:
<div id="searchResults"> <?php foreach($results as $r) { $currentPageBody = strlen($query) > 0 ? $this->controller->highlightedExtendedMarkup($r->getBodyContent(), $query) : $txt->shortText($r->getBodyContent());?> <div class="searchResult"> <h3><a href="<?php echo $r->getPath()?>"><?php echo $r->getName()?></a></h3> <p> <?php echo ($currentPageBody ? $currentPageBody .'<br />' : '')?> <?php echo strlen($query) > 0 ? $this->controller->highlightedMarkup($txt->shortText($r->getDescription()),$query) : ''; ?> <span class="pageLink"><?php echo strlen($query) > 0 ? $this->controller->highlightedMarkup($r->getPath(),$query) : $r->getPath(); ?></span> </p> </div> <?php }//foreach search result ?> </div>
This should be the only modification to the view.php of the search block and you don't need to modify the controller.php file at all so undo any changes you may have done before while you were debugging this.
Basically, searching by tag is not a normal text search query (duh, Brad). While the results are indeed pages thus they have a path and potentially a description and/or content, they are the result of searching by a specific attribute key and its corresponding value.
The ProBlog add-on does something very similar since it masquerades tag searches as category pages.
I think some work has been put into this and has been checked into GitHub. Check out the repo:
https://github.com/concrete5/concrete5/tree/master/web/concrete/bloc...
That said, I don't know if those commits have solved this specific problem (I've experienced the same messy source via the search block that you all are talking about). Hat tip for putting in the time.
https://github.com/concrete5/concrete5/tree/master/web/concrete/bloc...
That said, I don't know if those commits have solved this specific problem (I've experienced the same messy source via the search block that you all are talking about). Hat tip for putting in the time.
Thanks for posting the link. I took a look at the controller and view PHP files for the methods in question it looks like no real changes have been made save for cleaning up the code.
I've never worried about those empty <span>s in the past, but it'd be nice if could I nail down a solution that would drop them when they are not needed.
I've never worried about those empty <span>s in the past, but it'd be nice if could I nail down a solution that would drop them when they are not needed.
Copied al the files and tested them, still the same messy result.
The stupid thing is that the highlites for the text (from the tag_cloud) is not even highlited. Aldo I use it in combination with Problog that cannot be the issue I guess.
For now I just take out the span class, maybe it will be solved in 5.5.
The stupid thing is that the highlites for the text (from the tag_cloud) is not even highlited. Aldo I use it in combination with Problog that cannot be the issue I guess.
For now I just take out the span class, maybe it will be solved in 5.5.
<span style="background-color:#efc480;"></span>H<span style="background-color:#efc480;"></span>e<span style="background-color:#efc480;"></span>t<span style="background-color:#efc480;"></span> <span style="background-color:#efc480;"></span>i<span style="background-color:#efc480;"></span>s<span style="background-color:#efc480;"></span> <span style="background-color:#efc480;"></span>d<span style="background-color:#efc480;">
I'm sure there was a reason for the odd HTML I've seen in the core (such as returned normal search results all encased in the <form> tags), but I took a day and made my own C5 skeleton that stripped out any inline CSS and used proper HTML markup.