Home › Forums › Product Support Forums › Ajax Search Pro for WordPress Support › 4 Unrelated Issues on a New Ajax Search Pro Integration › Reply To: 4 Unrelated Issues on a New Ajax Search Pro Integration
I will try to answer as much as possible, please let me know if I miss anything:
Q1 – Folder names and files
While I agree that it would be much better to have them separated, but there is a reason why there is only one folder there. File/Folder related actions in PHP can be quite costly, depending on the disk speed and other factors as well. Occasionally, the plugin needs to check their existence. Having a single folder solves this folder. There is also a possibility that the PHP folder permission check returns positive result, while the ownership of the parent folders may be incorrect. In those cases a fall-back is implemented, with a possibility for the user to create those folders manually if needed. Again, instructing to create a single folder is much less problematic.
I will however definitely consider the naming you proposed regarding the image caching and results caching options.
Q2 – Post format issue
Unfortunately the issue turns out to be more problematic than that in this case. One great features of the plugin is that it can handle taxonomy based exclusions/inclusions in one single, optimized query – not during a post process or follow-up queries. This creates a rather difficult situation with items that are not marked with a taxonomy term, that does not exists, yet it is displayed by WordPress as existent. I understand why though, it saves a lot of database space, but it is unusual. Forcing to display another filter is not going to solve it in this case. I will have to write a back-end code as well as to coop with all the term logics and possibilities whenever the 'fake' post format is selected.
This should be ready within the next release.
Isotopic image issue
Will test this with SVG images, and see if I can replicate and fix it.
Isotopic default image
You are correct. I will find a way to get around it within the next release.
I will try to implement the results type filter as soon as possible of course, I believe that is the only reasonable solution for now.
Attachments does not have parent objects by default, or at least as far as I know they don't. Maybe you are reffering to pages where the attachments are visible/used? Unfortunately I don't think there is a backwards link or any other way to track the attachments post page from the attachment object itself.
However if the attachment indeed has a parent page (like in pages), then this could be solveable with a custom code. Let me know, and I will try to work out something.
Make sure that the attachments are also indexed under the index table submenu: https://i.imgur.com/ZyyE3lp.png
This option is still under development/beta testing, just been added in the latest release, so there is a chance that it may not work 100% correctly at all times.
I hope this helps!Best,
If you like my products, don't forget to rate them on codecanyon :)