Forum Replies Created
-
Posts
-
Hi!
The issue was the caching. Since it was enabled and set to 1 day it retrieved results from the search cache, which not yet contained the test posts. You can empty the cache and re-enable it if you want, but I highly suggest not using it unless you have more then 10000 visitors a day.
Thank you for the proper information, it helped me a lot!Hi Sean!
If by inline stylesheets you mean the “style=..” on some nodes, then I would not recommend doing anything about it. Some of them are coming from the php code, some of them from the javascript. I’m highly against inline stylesheet solutions, but there was a very solid reason to implement them – compatibility. The plugin also uses 3rd party javascripts, some of them are also doing the same, it’s the cross browser, cross javascript madness and only if there was a better way to deal with it. By trying to remove some of them will most likely cost you an unexpected error, which you may not even notice.
Also, if you examine the stylesheets, you will notice that each of the search instances are marked with an id, like “#ajaxsearchpro1 .proinput etc…”, and this is also a highly unadvised way of making css files. However following the conventional class, sub-class selectors I was facing so many support tickets for various layout problems, that I couldn’t deal with them. There was no way to prevent other plugin/theme stylesheets from overriding my selectors but to use id-s. As you probably know id selectors in CSS have a precedence over classes, thus putting a code under id-s will fix most of these problems. I’m on the way of releasing a new product and it looks like I may have found a better solution, but it needs to be tested first 🙂
I whish I could join your project, however my timetable is full for the next couple of months. Besides that I promised myself I would only focus my energy exclusively on envato products.
If you have more questions I’m happy to help you, I usually answer in 24 hours (except for weekends).
Hi!
Most likely the best way to do this is by disabling the code, that is responsible for the stylesheet addition.
Open up the wp-content/plugins/ajax-search-pro/includes/shortcodes.php file. On the line 50 you should see this:
add_action('wp_print_styles', 'search_stylesheets');Comment out that line, and the complete styling should disappear:
//add_action('wp_print_styles', 'search_stylesheets');Hi Steve!
I know you did, I can see it from the source code. But I’m asking if you saved the search settings after creating it?
Here are the screenshots of what I mean:http://i.imgur.com/uxZMmbB.png
http://i.imgur.com/Z5qysR8.pngYou need to do this, because the seach won’t generate the stylesheet file.
Once again, please make a new search box and save it’s settings once, without saving it won’t overwrite the stylesheet files, that’s why it’s messed up. And you can’t use the same search box twice on one page, it wont work.
Did you delete the previous search as I asked in the previous post?
Please create a new search as I suggested and save it’s settings. You don’t need to change any settings just save them after creating the new search.The one I have uploaded is not the same as the old, you need to create a new search and save the settings once.
Thank you. That looks normal, it confirmes that there is something wrong with the data storage. In the meantime I had made some changes to the search on my test server. I’m not sure if it will help, but lets hope for the best. I’ve attached it to this post, please do the following:
– Delete all the search instances you had created on the search options page (http://i.imgur.com/qbPrcVY.png)
– Disable then delete the plugin in the plugin manager
– Download the attached file to this post and install it
– You should see the ajax search pro again on the sidebar
– Create a new search, hopefully the mysql_real_escape… error will not appear
– Open the search options for the newly created search instance
– Save the options – regardless you changed them or not
– Place the shortcode to a page, or make a widgetLet me know if anything is changed!
Hi!
This is what I was able to determine based on the front-end:
- The search function is fortunately working without errors, that’s a good thing
- The problem is in the search configuration – however I’m not sure if the frontend configuration corresponds to the backend values.
So far what I see is that it’s either the search in posts, search in pages, search in content options are disabled on the general options page (http://i.imgur.com/VraGQIp.png)
or despite the configuration the frontend shows something entirely different.Can you check your general settings page, and perhaps make a screenshot of it? It would confirm if the error is related to the database.
Okay. The error log unfortunately contains nothing useful. I think it’s because the errors are outputted right onto the page.
Can you make a random post or page that would only contain the search? Then you can send the page/post url to me, at least I could see if it looks normal, and maybe I can fetch some errors from the developer console.
In addition, if you can’t provide access, maybe the error log file would also help a lot. You can find it in the plugins/wp-content/ajax-search-pro/ directory. The file is named simply error_log with no extension.
You will maybe have to zip it before uploading, I’m not sure if the web uploader handles files without extensions.
Hi!
I’m currently working on a solution, but the thing is that I can’t reproduce the issues on any of my servers 🙁
I have never experienced sush problems before, and I was unable to work this weekend. I was trying to play with the server configuration, I’m sure that it’s related to that as well.
Can you by any chance provide temporary ftp and administrator access to your clients website, or to a test environment where the search is installed? I can start working on solutions step by step, but I’m afraid something new would come up every time.
You can try for a refund at envato, but I’m afraid they will refuse it as you had already downloaded the product. Digital products refund policy is very strict unfortunately.
Hi!
I’ve looked into the issue, and it looks like that in some cases (for specific php versions) the mysql_real_escape_string function throws a warning message if a mysql link is not specified. It shouldn’t affect the outcome – so if you are able to change the search settings and use the search it shouldn’t be an issue.
I’m definitely replacing these lines with alternative solutions for the next bugfixed version as others may experience it as well.
Thank you for noticing me!
Thanks for the error log, unfortunately nothing related to your site, just old dated test errors 🙁
In the meantime I had changed a few things regarding the menu structure that might help. I attached a fixed plugin file, please uninstall and delete the old one and install this one instead.
I tested this on a strict debug enabled environment, so hopefully it will help. Let me know!
