[BUG] Issue with Recents Redirect

[NathanLochala]

After searching a few times, I have a number of recents listed when I click search. This is a great feature, however, the URL is redirecting to the wrong location. It seems to be an issue with the result.url. The actual <a href=...> is correct, but the page that I am directed to is incorrect.

[CharrafiMed]

hey @NathanLochala

I'm trying to understand the issue, but I'm having trouble. If the bound href attribute is correct in the <a> DOM element, why does it lead to the wrong destination?

Does this issue occur when using the first search query, or does it happen after clicking one of the recent items and then it becomes the wrong hrefattribute, where the href then becomes incorrect?

[NathanLochala]

I apologize for not being specific. When I perform a normal search, the links are correct. However, here is the scenario: When I click on the search bar and your modal search window appears, the problem happens when I click on an entry from the list of recent searches (other than the first one).

To reproduce:

1. Perform several searches so that you have several "recent searches" listed in the modal window when you click on the search bar at the top of the page.
2. Click on the 2nd or 3rd recent searches in the modal window. You should see an incorrect redirect.
3. If you click on the top recent search in the list, it works fine. Anything after the top one redirects incorrectly.

Does that make sense? If not, I can provide screenshots.

[NathanLochala]

[CharrafiMed]

hey @NathanLochala

Unfortunately, I wasn't able to reproduce the issue, but I'll be releasing some stricter code in the next few hours, which might address these odd behaviors.

I do have a few questions, though. Have you been refreshing or re-seeding your data locally multiple times? The recent search feature persists data into local storage, so it may be holding onto outdated URLs. If you've changed the data, you might need to manually clear the local storage to ensure it's using the new URLs generated from updated IDs or slugs.

(This issue of clearing local storage manually doesn't appear in production since we don't refresh data in the database there. Let me know if that helps!)

[CharrafiMed]

i think also this concern should be added to the documentation to help prevent issues related to URL caching when frequently re-seeding data in a local development environment.

[NathanLochala]

Dude, you're exactly right!!!! I am performing extracts from external sources and populating my database each night. Sounds like I need to just not use recents, or maybe limit it to only one recent.

[CharrafiMed]

No, you shouldn't disable the recent search feature (it's one of the most important features in the plugin). However, whenever you refresh the database, make sure to clear the relevant local storage keys.

As shown in the screenshot below:

There are two keys you need to clear. Both are prefixed with your panel name:

• _recent_search
• _favorites_search For production, you're safe from this concern since you won't be refreshing the database regularly.

[CharrafiMed]

I will leave this issue open until we see if this is a bug in the code or just a concern we must be aware of in the local development

[NathanLochala]

That solved the problem. Thank you, once again, for your help. This would be important to note in your readme, I think. In production, there are situations in which this issue can arise. In our specific instance, we interacting with 3 different external APIs to refresh data in our database daily. It would be nice, though not a priority, if there was a method that I can call statically to clear the cache of the recents and favorites. So that, at the end of each night, I can call that method via a schedule'd task, and clear the cache.

[CharrafiMed]

Thank you for catching this bug and bringing up these concerns. I appreciate your insight, and you're right—I added documentation for these concerns this morning. I'll be researching efficient mechanisms to handle scenarios like yours, so we can address this more seamlessly in the future.

leave this issue open to make others aware of this concern