Forum Replies Created
-
Posts
-
Hi!
I think I understand now. If you want to exclude posts from a specific category or taxonomy term, then it’s on the Advanced Options panel: http://i.imgur.com/KaKZ2tc.png
There is definitely an error message somewhere, but it’s either supressed, or turned off somewhere. The ajax request returns a completely emtpy response, so the search looses the control at some point for some reason. In case of no results there should be something in the response body, so there must be an error somewhere.
Have you found out why is the no-cache header added so many times?
The only option I can see here is for me to check your back-end and debug the code through FTP. There is no error message, nor an indication of errors so the only option is debugging the code directly. Could you please provide temporary back-end and FTP access to the test server so I can debug through the code? You can upload them in a .txt file, it’s not accessible to anyone but me and you.
Hi Eno!
Sorry for the long delay, I got lots of tickets and mails to take care of. Well, there is no quick fix for grouped results in this case, because in the recent version I changed up a few things, and it’s a bit more difficult to access and modify the grouped results array correctly.
I’ll have a bit more time for development tomorrow morning, I will try to come up with a solid solution for you. There is definitely a solution, but this time I have to test it properly to avoid errors 🙂
Hi!
The default engine cannot search author names connected to posts, the data is stored separately so it won’t work. The 2 posts there are only visible, because the both of the content has the thext “sten” in them, it’s not because of the author unfortunately.
However, the plugin version 4.5 and upper has a feature called the index table, which can generate an index including the author details. I think this is what you are looking for. Please read these chapters in the documentation on how to enable, generate and use this index table. If you don’t like it, you can always switch back to the regular engine at any time.
Hi!
The categories are parsed by ID, and they have a different ID in different languages, as far as I know. Are those certain categories working correctly (correct url) on other pages? Can you tell me a few which is the correct url for the “quito” category?
Have you managed to fix the problem? I just typed in the keyword “Arquitectura” and it’s working. I’m interested on how you solved this problem, if it was a bug in the search I could fix it.
Hi!
1. I’m not sure if I understand this correctly. Could you please perhaps demonstrate with a screenshot, or with more description? Once I understand the problem, then I might be able to suggest a solution.
2. I think you are looking for the Custom field selectors. Here is a detailed guide in the documentation of it’s usage.
3. By turning ON the Open the results in a new window? option on the Layout Options -> Results Behavior panel.
Hi!
Yes, the first option on the Frontend Search Settings page: http://i.imgur.com/Fu8oYlu.png
That will make the options disappear. There is also a chapter in the documentation about these options if you need more information.
Hi!
The overlapping issue was not yet fixed, I think I accidentally forgot to add that, I just check the version control system.
The other issue is fixed.
I’ll fix the other one as well and upload a minor bugfix version tomorrow to solve that once and for all. I’m sorry for the delay.
Hi!
Please make sure you are using the latest version of the plugin (4.5.1). If not, then please update.
If you are using the latest version, then could you please link me to a page where the search is active, and also provide temporary FTP and back-end details to your test environment. (you should open a new support ticket for this in the support forums, not here in the bug reporting section).
Hi!
Since the error message does not contain information about ajax search pro files, I’m not able to tell what might cause this. As described it sounds like a missing file, but strangely it works when the plugin is disabled. The search plugin loads almost nothing on the editor pages to prevent any possible issues, so this might be somewhere in the initialization script.
I’ve installed the ithemes exchange free version on my test site, but I can’t find any shortcodes to test or use. I have to see or re-create the issue to suggest a solution, it can be literally anything. Do I have to enable a core add-on?
If you can provide temporary FTP and back-end access to your test server when I can debug the problem, that would be the best possible solution. I would probably find and fix the cause as well. I’m not sure if I can re-create this on my test environment.
Hi!
You can change the colors on the ajax search pro instance settings page on the Theme Options -> Typography panel. I think you are looking for the first option there the “Results title link font”.
Hi again!
It’s actually a good idea to check for uploaded versions in the theme folder. It would solve the problem of making those files persistent. Great idea! I’m putting this on the TODO list right away.
Actually there is an option to increase the viewport size to disable the scrolling. Open the search instance options, then Theme Options -> Vertical Results panel, and scroll to the Results box viewport (in item numbers) option. By default it’s 4. Change that to something bigger, like 100. That should get rid off the scrollbar.
Hi!
Well, there is a reason why that script is in that file. The problem with shortcode usage. There is currently no solid way of “detecting” which search shortcodes are used on the server side, before the footer loading. (not to mention that the user can use the shortcode directly in the theme files, which makes it even more difficult). So the only solution would be to instantiate every search instance created within the header or the footer – it’s excessive code, I’m not sure about the performance impact.
I figured out a solution though, but I haven’t had time yet to implement. Basically, I would create another javascript file instead of the script tags, which would only initialize the instances it finds on the page – and the configuration would be stored in a separate element or within a base64 encoded serialized data attribute. This solution should completely get rid off the inline scripts – but I see potential issues with dynamically loaded pages and other stuff.
I guess what I can do for the next release is to add a compatibility option for the user to choose to initialize the search instances by:
– Inline scripts (default)
– Header script
– Footer script
– Dynamically in the footer (the solution I just described)I’m working on bugfixes and updates on this plugin on a daily basis, I will try to prioritize your request as much as I can.
Hi!
If you are not using the polaroid layout, you can configure to exclude this script. It’s the official modernizer library, I don’t think there is anything we can do about it, it’s a 3rd party open source script developed on github.
If you don’t use the polaroid layout, then ho to the Compatibility Options submenu, and turn off the Load the polaroid gallery JS? option: http://i.imgur.com/MuDKvsB.png
The script then won’t load anymore. That’s the best solution I can think of.
