Forum Replies Created
-
Posts
-
Hi!
You can adjust the width of the search bar on the plugins “Theme Options” tab. If the container element is too small, then you should try increase it’s width via CSS. I can’t see the search anywhere so I can’t advice.
For the correct placement you should also consult with the theme developer, he probably knows exactly which spot is the best in the code for the search bar.Hi!
There was an error coming from one of the adf plugins javascript files named jquery.flot.js as you can see here:http://i.imgur.com/J8nx3pA.png
I have switched the js source on the search compatibility options submenu to “Minified Scoped”, that way this 3rd party plugin issue is resolved. Please note the other plugin developer, because this error may cause malfunctions in other plugins as well. I’m sure it wasn’t intentional.
The search preview should work now. Please note that the preview might differ a bit from the actual result, as some stylesheets from the theme might not be loaded on the backend.
I wish you a successful and happy new year!
Indeed, you are right.
Misteriously it was not related to the characters. If you try the topic search, it will work now. The problem was, that the search was unexpectedly excluding some of the categories. But I don’t think that’s the issue there with you, because you get unexpected results.
Are you by any chance using fulltext search? Fulltext mysql database queries are highly sensitive to these special characters and often they percieve them as regular expression operators. If so, then please turn off the fulltext search on the Fulltext search settings submenu: http://i.imgur.com/bmGk51p.png
Hi!
Could you please pass more information on this? The title/content search is UTF-8 and special character ready, so it must be something else.
– What type of content are your searching? (post, page, custom post type, category, taxonomy term, buddypress users etc..)
– Which fields contain the searched phrases? (title, content, excerpt, custom field)
– Is the search working correctly in other cases?Also, could you please provide temporary admin/ftp access for me to see exactly the origin of the issue is? Otherwise it’s extremely hard to tell. In addition please also make a test page (only with the search shortcode), hidden from the public where I can test the plugin.
Hi!
I’ve managed to find the piece of code which prints out the search form. I’ve modified it to show the ajax search pro with id 2.
The modified file is: wp-content/themes/venedor/inc/functions.php on line 2074
This line was added there:
[php]
echo do_shortcode("[wpdreams_ajaxsearchpro id=2]"); return;
[/php]Screenshot before: https://i.imgur.com/EWnfetl.png
Screenshot after: http://i.imgur.com/DPPSaHJ.png
Of course. I need to go now, but I will start with your ticket tomorrow. I don’t usually do support on the weekends, but I need to fix some issues, so while I’m at it I’ll try to do yours as well. If however something comes up I will surely contact you on monday at the latest. I will make sure to take screenshots as well so you can update your theme safely.
Happy new years to you too!
Oh, I see now what you mean. Unfortunately in wordpress a plugin can’t replace the original search form. That’s why there is a php shortcode provided as well, so you can replace the default wordpress search with that. It’s usually located in the themes header.php file somewhere. I can’t provide customisations and implementation services, but I can take a look and perhaps replace the search form in your header if I find it. Let me know and I will try 😉
It is working for me. Here is a screenshot of it: http://i.imgur.com/xgDxLSW.png
Could you please set up a page where the search is active? Just place the shortcode to any page, it doesn’t have to be visible to anyone, and send me a link to it. I will do some debugging then.
Hi Daren!
Are you sure that the printer models are indeed in the content, and they are not custom fields or categories or tags?
I believe they might be stored as a custom field or tag or a custom taxonomy list, because the search would find it in the content for sure.
Try to enable the search in terms option, it will help if the printers are stored as tags or terms: http://i.imgur.com/t0HK3GP.pngWell, I can’t tell without debugging unfortunately. It can be anything.
In case you had an older version installed, you should try to go through the secure update steps, it usually helps: https://wp-dreams.com/knowledge-base/updating-from-older-versions/
Don’t forget to open up each settings page and save them again. It might be just an inconsistency with the options database.Hi!
Sure thing. It looks like your theme is declaring the same function used in the plugin, but it doesn’t check if it already exsists. The issue is not related to the search plugin per se, but I will help you anyways.
Based on the error messages if you open up the themes functions.php file and go to line 257, you will see something like this:
[php]
function current_page_url() {
…
…
}
[/php]The { and } brackets indicate the beginning and the end of the function. The ending } bracked should be a few lines below line 257. Now, the best solution is to wrap this piece of code into an if statement. This is the standard way to check wether the function is already declared. So you need to wrap the function code like this:
[php]
if (!function_exists("current_page_url")) {
function current_page_url() {
…
…
}
}
[/php]This will fix it immediately. Please also notice the theme developer to wrap all of the functions in his theme functions.php file in such way, because it may cause conflicts with other plugins as well.
Hm. Then let’s try the same css rule but with the !important note. Try to add it to the search plugins “Theme Options -> Custom CSS” tab:
[html]
.proinput input {
min-width: 1000px !important;
}
[/html]I’m 99% sure it should work. The dev tools confirm it as well.
The less elegant solution is to simulate a delayed window load event, as it doesn’t get to the search. Usually the solution described in this knowledgebase article works: https://wp-dreams.com/knowledge-base/tiny-input-box-on-certain-page-positions/
I’m going to be unavailable for the next 2 days, I might not be able to answer until then.
Could you please add proper temporary admin and ftp details so I can check the issue?
I can’t replicate it on my test server.
Hi!
Placing the search inside a slider might delay/ignore some javascript events like the window load and window resize event. The input field width is connected to an initial window resize event, however since the search bar is inside a slider, this event never reaches the search, most likely because it’s propagation is cancelled by the slider plugin.
The best solution in this case is to enforce a minimum width for the input field with a few lines of CSS:
[html]
.proinput input {
min-width: 1000px;
}
[/html]The second issue is not related to the z-index itself. The slider “canvas” has a relative position, so everything inside of it is bounded by it’s borders. Thus doesn’t matter how you change the z-index, every element will stay inside the slide.
The search by default tries to prevent this by placing the result’s div at the bottom of the body element (moving it outside the slide), but only if the results position is set as hovering: http://i.imgur.com/50LHBaB.png
Try to set the results layout position to hovering, it should help.If not, then we will proceed to another, more complicated solution.
