Pavlo

Hi Henry,

This is a support forum for the Live Ajax Search plugin but the issue seems to be related to the SearchWP plugin.
Since we’re already discussing this issue with you in SearchWP plugin support, I’m closing this ticket to avoid duplication.

Please feel free to open a new ticket here if you have any questions regarding the Live Ajax Search plugin.

It’s great to hear that you managed to sort out the styling for the results page!

The {Read More} styling is a part of your theme or other plugin.
SearchWP Modal Search Form has a tiny CSS footprint and strictly targets the contents on the search modal itself without affecting anything else.

The search results page is controlled by your current theme.
SearchWP Modal Search Form plugin only controls the search modal’s styles: https://a.supportally.com/aXEZm2.

Let me know if you are looking to style the elements within the modal and I’ll help you with the exact selectors.

Hi Ted,

SearchWP Modal Search Form doesn’t need SearchWP plugin to operate or apply styling.

The issue with styles can be fixed by adding the “search-form” class to your search input <form> element.
Normally WordPress adds this class to the form by default, but the output can be overriden using the ‘get_search_form’ filter.
This is likely what happens in your theme or in one of the plugins` code.
Try searching for any code that hooks to ‘get_search_form’ in you website’s codebase and change it so the correct class is added.

Here’s a WordPress get_search_form() function code for reference: https://github.com/WordPress/WordPress/blob/master/wp-includes/general-template.php#L239-L362.

Once “search-form” class is added back to your search input <form> element, the styling gets back to normal.

• This reply was modified 2 years, 4 months ago by Pavlo.

I have several ideas on what potentially could happen but need some more input to narrow down the options.

The issue is not reproducible on my side, so I need one extra test to be made on your website.
Could you please change the theme to one of the WordPress’s standard themes like Twenty Twenty or Twenty Twenty-One and see if the issue persists.

The other potential fix would be to add add_filter( 'run_wptexturize', '__return_false' ); hook to your functions.php or a separate plugin like SearchWP Customizations plugin.

The link from your screenshot doesn’t appear to be a SearchWP Modal Search Form menu link.
Our links have an href attribute starting from #searchwp-modal- as seen on this screenshot: https://a.supportally.com/YAph1J.
It might be some other code converting the apostrophe into a question mark in your menu.

But to be sure, let’s make a test:
1. Remove a SearchWP Modal Search Form menu link from the menu.
2. Save the menu.
3. Deactivate SearchWP Modal Search Form plugin.
4. Try saving the apostrophe again and see if deactivating SearchWP Modal Search Form changes anything.

Could you please right click on the menu item with a question mark and click “Inspect” in your browser and take a screenshot?
Sharing a screenshot of the HTML might help us solve the issue for you.
Here’s an example of the screenshot: https://a.supportally.com/YAph1J

We managed to track the issue and released a fix in version 1.7.2.

Hi Divanshu,

Thanks for reaching out!

Could you post a stack trace of the error so we can track what causes it?

Hey @agridesigns,

Do you have AJAX submissions enabled in the form settings?
https://a.supportally.com/Sl6ptD

Same here but the author doesn’t seem to bother.

Here’s the fix:

The string wp-content/plugins/woocommerce-conversion-tracking/includes/integration.php:83

should be

function validate_textarea_field( $key, $value ) {

instead of

function validate_textarea_field( $key ) {

Could be a good point.
Thanks for your time and good luck with new releases!
Closing the topic.

Yes the info is crazy indeed. ??
Will be glad to hear your idea. Not in details of course, just general direction of thinking.
It’s interesting how people deal with issues like this.

I spent all day debugging and found what was wrong.

One of the installed plugins (let it be APlugin) needs to determine if user is logged in when APlugin is loaded. Function is_user_logged_in() is unavailable while plugins are loading. To enable this function APlugin includes pluggable.php which sets current user to zero.

Plugin loading order is alphabetical which means that by the time your plugin is loaded APlugin already set current user to zero.

Believe it or not but renaming your plugin to AWP OAuth Server will improve its compatibility. ??

I hope it will help you in development. WordPress has its ways to surprise.

If you need more information about this case, feel free to ask. I’m happy to help.

Looks like add_filter( 'determine_current_user', array( $this, '_wo_authenicate_bypass' ), 21 ); runs after determine_current_user filter is fired. Thus _wo_authenicate_bypass() function is never executed.