htaccess rewrite for author query string when WP is in subfolder

<IfModule mod_rewrite.c>
    RewriteCond %{QUERY_STRING} ^author=([0-9]*)
    RewriteRule (.*)  https://www.google.com/search?q=?author=%1 [L,R=301]
</IfModule>

Sorry, forgot to add part in [L,R=301] Otherwise you could get unexpected results.

My site redirects the ?author={#id} query string to do a Google search for the query string itself.

I accomplished this by adding the following to my .htaccess file:

# Block User ID Phishing Requests
<IfModule mod_rewrite.c>
    RewriteCond %{QUERY_STRING} ^author=([0-9]*)
    RewriteRule (.*)  https://www.google.com/search?q=?author=%1
</IfModule>

This is probably best handled the "WordPress way" as @Iceable suggests, rather than using .htaccess, however, to answer your specific queries...

But no matter how I try to edit the second part...

You don't need to edit the "second part". The "second part" simply checks the query string, not the URL-path, which does not change when WordPress is installed in a subdirectory.

Also, assuming the .htaccess file is located inside the subdirectory that WordPress is installed in then your directives can be simplified. There is no need to reference the subdirectory:

RewriteRule ^author/ - [F]
RewriteCond %{QUERY_STRING} ^author=([0-9]*)
RewriteRule .* - [F]

These directives will work regardless of where WP is installed, providing the .htaccess file is located in the root of the WP install.

It is more efficient to check the URL-path using the RewriteRule pattern (when possible), rather than checking against the REQUEST_URI server variable. Also, the RewriteRule pattern matches against the URL-path less the directory-prefix (so this naturally works for any subdirectory without additional work). Whereas the REQUEST_URI server variable contains the entire URL-path, so any subdirectory must be explicitly accounted for.

Also, there is no need for the <IfModule mod_rewrite.c> container, unless these directives are intended to be optional.

I assume you are trying to prevent scanners obtaining your site's user names. And for security I believe in blocking at the first perimeter gate possible i.e. .htaccess not PHP.

No idea why subdirs cause an issue; you could try adding your condition to htaccess files in both root and your WP subdir it certainly won't do any harm. I use a rewrite condition pretty similar to yours and it works for me on sites with WP in subdir or not:

RewriteCond %{QUERY_STRING} author=
# redirect away from site
RewriteRule (.*) https://www.fbi.gov/investigate/cyber/%1 [R=302,L]

I also use a modified version of Jeff Starr's 6G "firewall" to additionally check for the WPScan User Agent. This scanner is popular with hackers and also used by some online "enter a URL" security scanners to identify admin users, use of vulnerable plugins etc etc. Obviously users can change the UA but legitimate online scanners and script kiddies don't seem to bother:

<IfModule mod_setenvif.c>
  # numerous 6G UA Checks (OMITTED)
  #check for WPScan
  SetEnvIfNoCase User-Agent "WPScan" bad_bot
  # Apache >= 2.3
  <IfModule mod_authz_core.c>
    <RequireAll>
    Require all Granted
    Require not env bad_bot
    </RequireAll>
  </IfModule>
</IfModule>

re M Kaplun's comment on OP:

I wasn't aware of Mark's plugin; and despite my comments on PHP it is obviously a great out of the box one stop solution. I take a different approach (which "solves" the problem of username leakage by themes also mentioned by Mark).

Change display name (via WP Dashboard) and author slug (edit "user_nicename" in users table; or use Edit Author Slug plugin) to be completely different to username.

So:

1. requests with author querystring (hackers) are redirected (2 lines of htaccess above).

2. author links added to posts by themes still friendly & work. They take you to relevant "author's page" - but the author slug no longer identifies username. e.g. on my site the (valid) author link (display name "AW") takes you to https://wptest.means.us.com/author/not-for-scanners/ for a list of my posts.

This is not practical for sites with lots of authors. Maybe ( @Mark Kaplun @mark-kaplun )'s plugin could be extended to automate slug changes (hashing all user_nicename in the DB?)?

Are publicly viewable usernames a risk?

Wordpress.org consensus is that user name "leakage" is not a security risk . Yet it provides the potential for some users to be hacked on first attempt (no brute force needed).

You do not need to be a genius to realise that the friendly url slug /author/hclintongmailcom means their is an author with email and (case insensitive) user name of [email protected].

There are hacker password lists for 1 Billion plus (? from recollection) email addresses (try yours against a small subset https://haveibeenpwned.com/); and many users use the same never changing password across sites. So an author with an email username and a password compromised on another site might be "hacked" at first attempt on your site.

The question is about doing this with .htaccess, but why not disabling author pages from within WordPress instead?

This would achieve the same result while making the subdirectory concern irrelevant altogether (and also works regardless of permalink structure settings)

Sample code that sets all urls to author pages to a 404 error:

add_action( 'template_redirect',
        function() {
                if ( isset( $_GET['author'] ) || is_author() ) {
                        global $wp_query;
                        $wp_query->set_404();
                        status_header( 404 );
                        nocache_headers();
                }
        }, 1 );
add_filter( 'author_link', function() { return '#'; }, 99 );
add_filter( 'the_author_posts_link', '__return_empty_string', 99 );

(code taken from this plugin: Disable Author Archives)