I’ll post a link in the next message if you can have a look?

The localhost install is a clone of the live site, so it isn’t a setting in wp or gd that has changed.

I installed a clone on a sub domain and it worked fine.

I has a look at the htaccess file and ithemes security had added some restrictions on the live site, after I removed those the search is working again.

This is what I removed, any suggestions as to what might be interfering with the search would be appreciated, I feel a bit naked without ithemes security!

# BEGIN iThemes Security
	# BEGIN Tweaks
		# Rules to block access to WordPress specific files
		<files .htaccess>
			Order allow,deny
			Deny from all
		</files>
		<files readme.html>
			Order allow,deny
			Deny from all
		</files>
		<files readme.txt>
			Order allow,deny
			Deny from all
		</files>
		<files install.php>
			Order allow,deny
			Deny from all
		</files>
		<files wp-config.php>
			Order allow,deny
			Deny from all
		</files>
		
		# Rules to disable directory browsing
		Options -Indexes
		
		<IfModule mod_rewrite.c>
			RewriteEngine On
		
			# Rules to protect wp-includes
			RewriteRule ^wp-admin/includes/ - [F]
			RewriteRule !^wp-includes/ - [S=3]
			RewriteCond %{SCRIPT_FILENAME} !^(.*)wp-includes/ms-files.php
			RewriteRule ^wp-includes/[^/]+.php$ - [F]
			RewriteRule ^wp-includes/js/tinymce/langs/.+.php - [F]
			RewriteRule ^wp-includes/theme-compat/ - [F]
		
			# Rules to prevent php execution in uploads
			RewriteRule ^(.*)/uploads/(.*).php(.?) - [F]
		
			# Rules to block unneeded HTTP methods
			RewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK) [NC]
			RewriteRule ^(.*)$ - [F]
		
			# Rules to block suspicious URIs
			RewriteCond %{QUERY_STRING} ../ [NC,OR]
			RewriteCond %{QUERY_STRING} ^.*.(bash|git|hg|log|svn|swp|cvs) [NC,OR]
			RewriteCond %{QUERY_STRING} etc/passwd [NC,OR]
			RewriteCond %{QUERY_STRING} boot.ini [NC,OR]
			RewriteCond %{QUERY_STRING} ftp:  [NC,OR]
			RewriteCond %{QUERY_STRING} http:  [NC,OR]
			RewriteCond %{QUERY_STRING} https:  [NC,OR]
			RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR]
			RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]
			RewriteCond %{QUERY_STRING} base64_encode.*(.*) [NC,OR]
			RewriteCond %{QUERY_STRING} ^.*([|]|(|)|<|>|ê|"|;|?|*|=$).* [NC,OR]
			RewriteCond %{QUERY_STRING} ^.*("|'|<|>|\|{||).* [NC,OR]
			RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]
			RewriteCond %{QUERY_STRING} ^.*(127.0).* [NC,OR]
			RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
			RewriteCond %{QUERY_STRING} ^.*(request|concat|insert|union|declare).* [NC]
			RewriteCond %{QUERY_STRING} !^loggedout=true
			RewriteCond %{QUERY_STRING} !^action=jetpack-sso
			RewriteCond %{QUERY_STRING} !^action=rp
			RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
			RewriteCond %{HTTP_REFERER} !^http://maps.googleapis.com(.*)$
			RewriteRule ^(.*)$ - [F]
		
			# Rules to block foreign characters in URLs
			RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F).* [NC]
			RewriteRule ^(.*)$ - [F]
		
			# Rules to help reduce spam
			RewriteCond %{REQUEST_METHOD} POST
			RewriteCond %{REQUEST_URI} ^(.*)wp-comments-post.php*
			RewriteCond %{HTTP_REFERER} !^(.*)com.au.* 
			RewriteCond %{HTTP_REFERER} !^http://jetpack.wordpress.com/jetpack-comment/ [OR]
			RewriteCond %{HTTP_USER_AGENT} ^$
			RewriteRule ^(.*)$ - [F]
		</IfModule>
	# END Tweaks
# END iThemes Security

You can mark this as resolved.

Stiofan

Interesting as I run iThemes Security and Wordfence both and haven’t come across any issues yet. If there is a conflict, it would be great to find out “the specific rule” if possible.

Or was it in combination with a specific search, phrase or characters maybe?

It’s the option to block suspicious query strings, if you turn it off and on you should see the change to the htaccess file. When enabled, a search (simple GD search, not advanced) for anything without a “near” value just fails, does nothing. The query string is…

?geodir_search=1&stype=gd_place&s=larx&snear=&sgeo_lat=&sgeo_lon=

I think the lack of values after the “=” signs probably triggered the filter, because adding a “near” value results in a query string that worked.

?geodir_search=1&stype=gd_place&s=larx&snear=mona+vale&sgeo_lat=-33.6779878&sgeo_lon=151.30334199999993