Hi,

Check your configuration, make sure the correct post types are selected, as well as the ordering is correct, and under the advanced option panel nothing is excluded. Also check your front-end filters configuration – date, custom field, taxonomy filters will all affect the results. If the search finds some results, that means there is only a configuration related issue.

Best regards,
Ernest Marcinko

In the plugin configuration page, all posts appear, but on the website page, the recent ones do not appear, it is 5 days late, even the cache is clean.

Then this still pints torwards a cache issue, if there is a difference in the back-end and front-end, I can’t see any possible explanation. That explains the difference and the issue perfectly.

Best regards,
Ernest Marcinko

I understand, some cache problem, but the strange thing is that I duplicated 1 form, and the duplicated search, works normally and is updated.

Exactly – the duplicated form has a new ID, and that is a different parameter sent to the results page, which was not yet cached, thus you got the “new” output. This means it is defnitely only a cache issue.

Best regards,
Ernest Marcinko

Thank you very much, I will try to solve it here, great day

Hello, it would be possible to make the version prior to 4.24.1 available, I think the problem was this change in the update.

“Moved the aggregated asset location to the wp-content/cache/asp/ folder for better server compatibility”

I am sorry but no, that feature is definitely not the issue, it has no effect on the results page. The duplicate search instance working proves, that the issue is related to caching, soecifically the page cache. Once you clear it properly, it will be resolved.

Hello, I found the problem, it really is in update 4.24.1 – 2022.11.25 I installed version 4.23.3, everything is working perfectly again.

Can’t I change this: wp-content/cache/asp/ to the previous folder?

I use the site on VPS

But again, that does not explain why a duplicated search bar works on 4.24.1, that should not work then either. That folder only stores the javascript files, that does not affect the items on the results page.

The reason the previous seem to work is, because its cleared from the cache, it uses other query arguments.

I am more than happy to help you with this on the spot, feel free to open a support ticket and I will assist.

A new search bar works as soon as I put it in, but when I add new posts, they don’t show up anymore, it looks like the cache has been stuck since Nov 25th.

Of course, because when you make a search with the new search bar, it redirects to the results page with certain query arguments. If your page cache is aggressive, it will cache that exact url immediately (it should not). Now, you add new posts, make the same query, and instead of the fresh page, you get the old cached page without the new posts – that is the problem, based on your description.

I understand, at the moment I am unable to renew support, here in Brazil 13 usd is a lot of money in reais, as soon as I get it I will renew, thank you

Hello, I found the solution to my problem, I deleted the old folder where the caches were stored, it was in wp-content/upload/asp_upload, in fact I renamed it to asp_upload2, so the plugin does not find it anymore, everything is back to normal , I hope it can help someone who is facing this same old cache problem. I think I can delete this folder? Thanks for the attention.

Sure, you can delete it, that folder is not used for a long time now. Your cache was probably still wanted to server the old files aggressively – once you deleted it, it refreshed itself.

Best regards,
Ernest Marcinko

Hello, the plugin is still creating the “asp_upload” folder inside the directory >> wp-content/upload/

Thank you for the feedback, I will check that, probably a leftover code we forgot to remove.

Hello, every plugin update, it creates the asp_upload folder inside wp-content/upload again, causing the same previous conflict

Hi,

Yes – we had to use a different approach unfortunately. The folder is still required for specific uploads (instance and synonyms exports), but no longer used for assets like stylesheets or scrips. If the issue reappears, then then check your cache configuration, you may have added a file from that folder previously, which no longer exists.

Best, Ernest

Good morning, I understand, but with these two folders (asp_upoload in wp-content/upoload and the “wp-content/cache/asp/” folder) the same conflict of not appearing new posts in the search bar continues, it just returns to normal when I delete the “wp-content/upoload/asp_upload” folder. Can I continue to delete this folder in future updates? is there any problem? Thank you very much

The main problem is, that changing or deleting the folder will not resolve the actual cause of the issue. It is very much possible, that even moving that folder will recreate this problem. I still recommend finding the core cause. Something must be triggering on the server side, when that folder is found. A permalink structure, firewall etc..

The folder is going to be needed (even if renamed), because the above mentioned files can’t be in the cache directory.

Anyways, you can try to circumvent this by changing this path via this custom code:

add_filter('asp_glob_upload_dir', 'change_asp_glob_upload_dir');
function change_asp_glob_upload_dir($dir) {
    $dir['basedir'] = 'asp_upload1';

    return $dir;
}

This will change that directory, and should create asp_upload1 istead of asp_upload. However I still strongly recommend finding out why a directory existence breaks the cache – because it can happen again in the future with any module.

Best regards,
Ernest Marcinko

I’m going to have to rename it for now, could you tell me where I put this code you made available?

Try the functions.php in your theme directory, that should very likely do the trick.

Best regards,
Ernest Marcinko

Hi,

That is not a bug, the file is generated automatically from the required script assets to greatly reduce the browser requests overhead. You should not delete it, there is no reason to do so, those are the required plugin scripts.

Best regards,
Ernest Marcinko

But the search didn’t work & went into INFINITE LOOP!!! The Console wrote it CANNOT READ THIS FILE!!! After downgrade to previous version the search works fine.

So waiving me away claiming there is no bug is YOUR PROBLEM, which you choose to ignore!

We do not ignore anything. You did not specify, that your browser could not read that file. Based on your description I assumed you kept deleting the file, which caused the issue. If the file is not accessible for the browser, it signifies a server related problem – as it should be accessible, the plugin can’t make it unaccessible. It could be a firewall/.htaccess related problem, probably your server does not allow accessing the file. If the access runs into an infinite loop, then it is more likely a .htaccess issue.

You can open a support ticket or a bug report with specific details, so we can take a closer look if you want to.

Best regards,
Ernest Marcinko

I’m truly curious what makes you think it is server issue while the server handles it very well on with previous plugin version. To me personally, it makes no sense!

It actually does, and it is very likely the only explanation. See the file location has changed, and it is very much possible to have different mod_rewrite rules on different folders, it is quite common. The server can have a no-access rule setup for specific folders. It was not apparent, because this location was not yet used for the script assets. The plugin can’t detect that, it is only detectable from the client side. If the file exists on the system and it is not accessible, then the only thing that can stop it is access blocking. It can be a browser extension (or an addon) on the client side, or the server.

It is much easier to open a bug report or support ticket, we might be able to help you either way.

Best regards,
Ernest Marcinko

I’m sorry, but the page has no form or a button to report. only showing 2 reports, So I’m not able to open. There are no rules on the server to block this folder from access. It happens on different browsers & also on private pages. I believe the issue is on your plugin & since I’m not able to report a bug or open a support ticket, I’ll wait for next version in hope it will be fixed.

Here you can open a ticket. Also, here you can open a bug report. If you don’t have an account, you can quickly register one, no verification needed.

Best regards,
Ernest Marcinko

Sorry if I wasn’t clear enough. I’m logged into that page, however it doesn’t let me send. I tried a few times. I must do some other things as well in my life, so I can try again tomorrow, However I believe something is not user friendly on your system. Thanks anyway.

Sure, it’s all right! I just tried to post a Test topic, and it works perfectly, it might be something temporary.

Best regards,
Ernest Marcinko

Thanks for trying to resolve it on today’s update. Unfortunately it doesn’t work. I get the following error: Uncaught TypeError: Cannot read properties of undefined (reading ‘infinite’)

I will retry to submit a ticket on your link

I sent yesterday & waiting for your check

Hi,

It will only work with the first widget in that case. The reason is, that even if that was “enabled”, both of the widgets would have the same exact contents, which is redundant. We can make that work if you want to, but I am not sure if you want to see the same items in the widgets.

Best regards,
Ernest Marcinko

I see, I thought that if I had two post widgets with different content queries (let’s say one showing category ‘travel’ only, and the other category ‘motorsport’ only), they would also show different filtered content, but this is not the case? Seeing that the search bar also searches by title and content, you can still have relevant keyword hits from posts in different categories. I hope this makes sense.

Oh I understand now. No, the search would override anything in the widgets according to it’s configuration.

Best regards,
Ernest Marcinko

Alright, so the search overrides any filters already present in the query. Would there be a way to set it up so that it doesn’t, or does that require massive adjustments to the plugin?

My use case is that I want to create a Knowledge Base page with different post lists that are sorted by category. Like this:

Ideally, I’d have one search bar that can filter all posts, so that only the relevant ones are shown.

To clarify, I mean the post lists at the bottom part of that image. The orange outlined part has nothing to do with it.

That would be very very problematic in general, custom coding the whole thing bottom-up to this specific requirement might be less work.

Instead of elementor widgets I would rather go with the vertical results, with results grouping feature enabled. Then apply some custom CSS as needed or even a bit of results templating.

Best regards,
Ernest Marcinko

Thanks for thinking along Ernest, I appreciate it. The results grouping looks good, I can make that work.

In my case, when initially loading the page, I already need to show all grouped queried content. Does the plugin allow this?

Yes – auto populating results on page load is possible, for example: https://ajaxsearchpro.com/property-search/

Best regards,
Ernest Marcinko

Hi,

Those fields are required to pass some parameters to the search, but they should have an aria-label attributes as far as checking the source. I will check on this to add aria-hidden attributes as well so that the checker ignores them.

For now, you can deal with this via the filters templating feature. Make a template for the

wp-content/plugins/ajax-search-pro/includes/views/filters/generic/asp-generic-checkboxes.php

Best regards,
Ernest Marcinko

Hi and thanks for your fast reply. I have two things in response:

1. Your fix seems straightforward, but it’s not working for me. I’ve uploaded the file to this path /wp-content/themes/total-child/asp/filters/generic/asp-generic-checkboxes.php and also tried /new.frcog.org/public_html/wp-content/themes/total-child/asp/filters/asp-generic-checkboxes.php but to no avail. I also flushed the cache (SG Optimizer) and don’t believe there are any other caches active that could keep the override from running. Am I missing something obvious? Yep, I’m a designer, not a developer. 2. It sounds like a permanent fix for this issue will come in the next plugin update. If that’s true, and if you’ll be pushing the update soon, there’s no need to address #1 above, since this will be working by the time I need to launch the site

I am going to add this to the next release I am sure about that – therefore you can also try to replace the core file in

wp-content/plugins/ajax-search-pro/includes/views/filters/generic/asp-generic-checkboxes.php

Best regards,
Ernest Marcinko

Nevermind, that will not help, WCAG checker still does not like that, it won’t work. It will report no compliance, however invisible elements should not even be considered, so I don’t understand what it wants..

Anyways, you can put an end to this for now via making a change to a different file:

wp-content\plugins\ajax-search-pro\includes\views\asp.shortcode.general.php

I will try to rework this to not use labels and such, but I have a feeling there is an issue with the checker tool as well, not considering aria-hidden and display: none styles.

Best regards,
Ernest Marcinko

Hi, I really appreciate your responsiveness! Unfortunately when I replaced asp.shortcode.general.php with the code provided, the page breaks :/ see screenshot https://prnt.sc/p2YZCnYWyjS_

Looks like it breaks right after the main Search box. . . maybe an unbalanced or something that’s not crashing the code, just not displaying right? I glanced at the PHP, but I didn’t see any obvious divs or spans or anything that made sense to me, so sorry I can’t try to make the spot fix.

It’s all right, I managed to find a better solution to completely exclude the query arguments and remove these unnceccesary input. Expect an update around the end of this week.

Best regards,
Ernest Marcinko

I am all in favor of better solutions and am happy to wait until the end of the week. Will this come as a plugin update, or will you drop some code into these comments for now?