Toolbar search not working
By Geoff Chapman on Saturday, 05 September 2015
Posted in Technical Issues
Replies 22
Likes 0
Views 1.5K
Votes 0
I have tried several different themes yet i cannot get the search feature on the toolbar to do anything. No search is ever performed.

Looking in the error console I see the following error reported for the Nomad theme:


Timestamp: 05/09/2015 16:10:31
Error: downloadable font: download failed (font-family: "FontAwesome" style:normal weight:normal stretch:normal src index:1): status=2147746065 source: http://macrotoneconsulting.co.uk/media/foundry/5.0/styles/font-awesome/fonts/fontawesome-webfont.woff2?v=4.3.0
Source File: http://macrotoneconsulting.co.uk/components/com_easyblog/themes/nomad/styles/style.min.css
Line: 1, Column: 71743
Source Code:
@font-face { font-family: "FontAwesome"; font-style: normal; font-weight: normal; src: url("../../../../../media/foundry/5.0/styles/font-awesome/fonts/fontawesome-webfont.eot?#iefix&v=4.3.0") format("embedded-opentype"), url("../../../../../media/foundry/5.0/styles/font-awesome/fonts/fontawesome-webfont.woff2?v=4.3.0") format("woff2"), url("../../../../../media/foundry/5.0/styles/font-awesome/fonts/fontawesome-webfont.woff?v=4.3.0") format("woff"), url("../../../../../media/foundry/5.0/styles/font-awesome/fonts/fontawesome-webfont.ttf?v=4.3.0") format("truetype"), url("../../../../../media/foundry/5.0/styles/font-awesome/fonts/fontawesome-webfont.svg?v=4.3.0#fontawesomeregular") format("svg"); }

Similar errors are shown for different themes. Vintage is shown below.

Timestamp: 05/09/2015 16:13:49
Error: downloadable font: download failed (font-family: "FontAwesome" style:normal weight:normal stretch:normal src index:1): status=2147746065 source: http://macrotoneconsulting.co.uk/media/foundry/5.0/styles/font-awesome/fonts/fontawesome-webfont.woff2?v=4.3.0
Source File: http://macrotoneconsulting.co.uk/components/com_easyblog/themes/vintage/styles/style.min.css
Line: 1, Column: 71743
Source Code:
@font-face { font-family: "FontAwesome"; font-style: normal; font-weight: normal; src: url("../../../../../media/foundry/5.0/styles/font-awesome/fonts/fontawesome-webfont.eot?#iefix&v=4.3.0") format("embedded-opentype"), url("../../../../../media/foundry/5.0/styles/font-awesome/fonts/fontawesome-webfont.woff2?v=4.3.0") format("woff2"), url("../../../../../media/foundry/5.0/styles/font-awesome/fonts/fontawesome-webfont.woff?v=4.3.0") format("woff"), url("../../../../../media/foundry/5.0/styles/font-awesome/fonts/fontawesome-webfont.ttf?v=4.3.0") format("truetype"), url("../../../../../media/foundry/5.0/styles/font-awesome/fonts/fontawesome-webfont.svg?v=4.3.0#fontawesomeregular") format("svg"); }



This may or may not be related. Either way it is a bug that needs to be addressed.
This is with the latest 5.0.25 EasyBlog.
Hey Geoff,

I am really sorry for the delay of this reply as it is a weekend for us here. Hm, when I tried to search on the toolbar on your site, it seems to be working fine. However, it seems like it only works when i click on the "Accept Cookies".

Can you try disabling that plugin and see if that works for you?
Mark
·
Sunday, 06 September 2015 01:30
·
0 Likes
·
0 Votes
·
0 Comments
·
No problem, I thought you already had the details but I will supply them again.
Geoff Chapman
·
Sunday, 06 September 2015 02:33
·
0 Likes
·
0 Votes
·
0 Comments
·
Hey Geoff,

Are you sure the ftp is correct? I created a debug.php file on the site and when accessing the debug.php file, it's not displaying my debug codes, http://macrotoneconsulting.co.uk/debug.php

Also, can you please turn off cache on the site please.
Mark
·
Sunday, 06 September 2015 02:47
·
0 Likes
·
0 Votes
·
0 Comments
·
I notice that you have already disabled the cache, which is fine. There is only Jotcache in use.

As for the ftp, the details are correct but you need SFTP protocol, not FTP.
Geoff Chapman
·
Sunday, 06 September 2015 02:56
·
0 Likes
·
0 Votes
·
0 Comments
·
Thanks, SFTP works. Okay, it looks like the plugin "System - Admin Tools" for some reason is preventing enter key from being submitting the search form. After disabling this plugin, it seem to be working. Can you try this now?
Mark
·
Sunday, 06 September 2015 15:35
·
0 Likes
·
0 Votes
·
0 Comments
·
Hmmm.

First I still see the java error message about the downloadable font failing. Obviously not related to the toolbar search then, but still a bug.

But yes with the System - Admin tools plugin disabled I can see that the search works.

Now we have a quandary, since as you are well aware, the Admin tools is a security tool from Akeeba, and disabling it will have consequences. I am a little reluctant to keep the plugin disabled, as you may well understand. The plugin impacts the 'web application firewall', with it disabled there is effectively no protection.

The only solution I can think of at present is to disable the search functionality on the Easyblog toolbar, until such time as a better solution is obtained.,
Geoff Chapman
·
Sunday, 06 September 2015 17:12
·
0 Likes
·
0 Votes
·
0 Comments
·
Given the time in your locale, and being unaware of how long you are expected to be working today (sunday) I think I will have to re-enable the plugins, that were disabled during your tests in order to put the site back into a 'safe' situation. If you have gathered enough information sufficient to understand the problem and possibly suggest an alternative solution, this will then enable some time for further thought upon the best solution.

If I do not hear anything back within the next 30 mins or so, I will assume that you have 'left' work for the day.
Geoff Chapman
·
Sunday, 06 September 2015 17:29
·
0 Likes
·
0 Votes
·
0 Comments
·
Carried out the following tests:

1) Have re-enabled the cookies plugin and the search still works. Required for EU legislation.
2) Also re-enabled the cache and the search still works.

Other than the Admin - System Tools plugin where there any others that you disabled. It will save me searching.
Geoff Chapman
·
Sunday, 06 September 2015 17:39
·
0 Likes
·
0 Votes
·
0 Comments
·
Assuming you have gone home for the day,

I have re-enabled the Admin tools plugin and as expected the toolbar search no longer works. I cannot find anything in the admin tool log to give an indication as to any 'exception' being encountered that might prevent the search from working..

Also re-enabled the system - debug plugin.

This places the site back in the situation where we started.
Geoff Chapman
·
Sunday, 06 September 2015 18:23
·
0 Likes
·
0 Votes
·
0 Comments
·
Hey Geoff,

Sorry, just got back. The issue is probably because admin tools is intercepting the "enter" key somehow and to be honest, I have no work around for this and it's best that you try to get in touch with the developer of Admin Tools if he has an idea of why the enter key is broken after enabling their plugin.
Mark
·
Sunday, 06 September 2015 22:13
·
0 Likes
·
0 Votes
·
0 Comments
·
Hi Mark,

I will raise a ticket with Nicholas (Akeeba) tomorrow and see if he has any ideas.

In the meantime it's not a show stopper, as the Smart Search is an alternative, for searching the blog posts. Can't believe that I am the only site using Admin Tools though, and that nobody else has seen the problem, but there you are.

I'll keep you informed on any progress.

Not to forget the small problem with font loading though.
Geoff Chapman
·
Monday, 07 September 2015 00:16
·
0 Likes
·
0 Votes
·
0 Comments
·
Hey Geoff,

Yeah, I am actually a little puzzled over this too because there is no reason that Admin Tools is preventing the "enter" key from being entered. I am sure there is some explanation to this and probably Nicholas would know better.
Mark
·
Monday, 07 September 2015 00:54
·
0 Likes
·
0 Votes
·
0 Comments
·
Just had a response back from Akeeba which explains the problem and a work around.

"The problem was caused by CSRF protection.
When its level is set to Advanced we inject an invisible input field in the form. Users won't see it, but spam bots think it's a valid field, filling it.
If such field is present in the request, we will block it.
I suspect EasyBlog is using a too broad Javascript selector, resulting in the wrong field "picked up" and no search is done.

I just lowered the level to Basic, so the field is not injected, if you want to use the advanced level, Easyblog developers have to update their code. "

This does at least enable the search to work, but does of course possibly permit spam bots to submit data to forms on the site. Over to you Mark.
:-)
Geoff Chapman
·
Monday, 07 September 2015 19:52
·
0 Likes
·
0 Votes
·
0 Comments
·
Hm, the search form on the toolbar doesn't actually utilize any "javascript". Instead, it's simply just a basic html form
Mark
·
Monday, 07 September 2015 23:57
·
0 Likes
·
0 Votes
·
0 Comments
·
I think the key point is the population of the 'hidden' field which is what Admin Tools is finding populated and hence preventing the search from working. Whether that is by javascript is perhaps secondary. I can confirm that the change of setting does indeed get the search working,
Geoff Chapman
·
Tuesday, 08 September 2015 00:24
·
0 Likes
·
0 Votes
·
0 Comments
·
Hey Geoff,

Hm, the hidden inputs are pretty common and I don't see why is Admin tools trying to block this. There is only 3 hidden input in the search form as shown on my screen shot here, http://screencast.com/t/X78zkvP6MmMQ
Mark
·
Tuesday, 08 September 2015 02:06
·
0 Likes
·
0 Votes
·
0 Comments
·
Here is the admin tools doc on the 'feature':

CSRF/Anti-spam form protection (CSRFShield)

One of the major concerns regarding web forms –like login forms, contact forms, etc– is that they can be exploited by automated scripts (bots). This is usually performed to send spam messages or brute-force passwords. Admin Tools has two methods to prevent such abuse, depending on the setting of this option:

No. Turns off this feature.

Basic. Performs basic referer filtering. If the browser of the visitor reports that the previous page was not one belonging to your site, Admin Tools will block processing of the form. This is enough to thwart script kiddies and unsophisticated spam bots, but will do nothing for more serious attacks.

Advanced. On top of the basic protection, Admin Tools will automatically inject a hidden field on all forms. Spambots will usually try to fill all fields on a form, including the hidden one. WHen this happens, Admin Tools will block the request. This is a better method, but it's much slower and not recommended for high-traffic (several dozen of thousands of visitors per day) websites.

The setting in use of the site was 'Advanced'. Currently set to basic.
Not sure which field has been 'created/inserted' that is being filled in! To be honest I am not sure how you would know either!
Geoff Chapman
·
Tuesday, 08 September 2015 02:45
·
0 Likes
·
0 Votes
·
0 Comments
·
One other thing that could be done in Admin Tools is to set up a WAF Exception for the page. Not used this specific work around before so there may be a little bit of testing required, but its a possibility.
Geoff Chapman
·
Tuesday, 08 September 2015 02:53
·
0 Likes
·
0 Votes
·
0 Comments
·
Reading up about creating a WAF exception, and need to specify the URL, however the URL is displayed as:

http://site.co.uk/index.php/Blog/COM_EASYBLOG_SH404_ROUTER_SEARCH.html?query=xxxxxxx

What should COM_EASYBLOG_SH404_ROUTER_SEARCH actually be if the string were specified? I can try with it as it is currently but obviously when we have the actually string it would need re-specifying again. Something else to fix.
Geoff Chapman
·
Tuesday, 08 September 2015 03:21
·
0 Likes
·
0 Votes
·
0 Comments
·
Hey Geoff,

Add the following into the language file /language/en-GB/en-GB.com_easyblog.ini



COM_EASYBLOG_SH404_ROUTER_SEARCH="Search"


Then, purge SH404's cache.
Mark
·
Tuesday, 08 September 2015 04:01
·
0 Likes
·
0 Votes
·
0 Comments
·
Well the string was what I expected it to be. I am a little puzzled though since I appear to have a file named en-GB.com-easyblog.ini ( with a dash) and the expected file named en-GB.com_easyblog.ini (with an underscore). The first one I presume is a misnomer. Either way I have made the change (ensured it's in both) and now the string appears correctly in the URL.

Have created a WAF exception for the search view but it doesn't seem to be working. [How difficult can it be, there are only two parameters required? ]

Have read the WAF docs and I don't think I have missed anything, will keep looking.
Geoff Chapman
·
Tuesday, 08 September 2015 15:33
·
0 Likes
·
0 Votes
·
0 Comments
·
Hey Geoff,

I am sorry for the delay of this reply, been really occupied with development works over the week. Sure, let me know how this goes.
Mark
·
Friday, 11 September 2015 02:12
·
0 Likes
·
0 Votes
·
0 Comments
·
View Full Post