Not a programmer or PHP expert here: please assume entry-level knowledge.
For security reasons, I'd like to allocate the contents of the index.php in my main WordPress folder to something else -- say, fish.php and just have an index.php that calls it, like so:
<html>
<body>
<?php include 'fish.php'; ?>
</body>
</html>
The fish.php file would contain everything that's usually in index.php. It would just be named fish.php.
Will this completely break WordPress? Is a full, detailed index.php file absolutely necessary for it to function, or is it a one-time "load and go" php file that isn't referred to again once WP is in the browser?
Your question is confusing. So you want another file that then includes the contents of index.php in WordPress? What are you trying to achieve? The basic gist of your question seems to be this line:
Is a full, detailed index.php file absolutely necessary for it to function, or is it a one-time "load and go" php file that isn't referred to again once WP is in the browser?
The way content management systems—or virtually any controller based system—works is to flitter all request in one file & then act on them. In WordPress, that is index.php. And it does more than just load the homepage. It’s the gateway page to all other pages. So you can muck around with it, but why? And for what benefit?
EDIT: The original poster in the comments to my answer explains that they are thinking of ways to prevent a WordPress site from being hacked. Renaming a file will not work. Especially since index.php is only seen on the server side. Let’s say by some crazy config the original poster adjusts Apache to always load fish.php as their index. The web browser—and users & bots—will still get WordPress content. Instead I do the following as a slid brute-force way of avoiding hacks: I place .htaccess password protection on the admin areas of CMS systems. The logic being—and it has worked so far—that most CMS systems are attacked by scripts that hack vulnerabilities in the admin or login process. Yes, some bots might get through. But you can eliminate tons of “low hanging fruit” with this method.
For example, below is part of the Apache virtual host config that I will use as an example for a site I am calling mygreatsite.com that I have based in the standard /var/www. Note that I am adding authorization for wp-login.php and wp-admin but allowing admin-ajax.php to pass since many functions use it. Now users who administer the site will need to remember an additional—somewhat generic—htpasswd_wordpress_admin user/password combination on top of their standard WordPress credentials. But guess what? Most CMS hacking scripts give up when faced with a browser based password coming from Apache like this.
# Added for WordPress CMS protection.
<Directory /var/www/mygreatstite.com/wordpress/wp-login.php>
Options FollowSymLinks
AllowOverride all
AuthName "WordPress Login"
AuthType Basic
require valid-user
AuthUserFile /etc/apache2/htpasswd_wordpress_admin
Order Deny,Allow
Deny from all
Satisfy Any
</Directory>
# Added for WordPress CMS protection.
<Directory /var/www/mygreatstite.com/wordpress/wp-admin>
Options FollowSymLinks
AllowOverride all
AuthName "WordPress Admin"
AuthType Basic
require valid-user
AuthUserFile /etc/apache2/htpasswd_cms_admin
Order Deny,Allow
Deny from all
# Allow 'admin-ajax.php' to pass.
<Files admin-ajax.php>
# Order Allow,Deny
Allow from all
</Files>
Satisfy Any
</Directory>