Thanks for following up with details about your discoveries.
It points out an error in my post (PHP files can't be directly accessed) that you have overcome.
You have been busy with your site. I see many hours of work put into it, with all the added exhibits since I last looked at it. I really like that you have avoided use of the clunky main navigation menu of standard Omeka.
It's the first time I've seen the creative approach you use to categorize items as four different item types and then provide a way to browse them as separate groups, without using collections. Nice.
Your curation and development effort shows deep respect for the content. Not many Omeka sites show such effort, even ones that are funded. Thanks for all your work.
Your explanation about the original issue and how you fixed it is very clear.
But, is that really the rewrite rule you added to allow access to the php files in the 'etc' folder?
It appears to enable access to files with URLs that start with 'admin' or 'user', such as
mccleerywolves.com/admin/code/contact_mailer.php
RewriteRule ^(admin|user)($|/) - [L]
- URL path starts with the token 'admin' or 'user'
- the next character is either a slash, or the URL path ends with the first token
- anything after the 'admin/' or 'user/' is allowed
- if this pattern is seen, use it (- for don't rewrite it) and stop processing the rewrite rules (L for last).
Isn't this the rewrite rule that enables files having a URL that start with 'etc/'?
RewriteRule ^etc/.*$ - [L]
- URL path starts with the string 'etc/'
- anything after the 'etc/' is allowed up to the end of URL path, including nothing
- if this pattern is seen, use it (- for don't rewrite it) and stop processing the rewrite rules (L for last).
in context in the .htaccess file
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^etc/.*$ - [L]
RewriteRule !\.php$ - [C]
RewriteRule .* - [L]
It is better for security reasons to not enable EVERY file having a URL starting with 'etc/'. It is better to be precise about what php files to allow, with each specific exception case explicitly defined.
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^etc/code/contact_mailer.php$ - [L]
RewriteRule ^etc/code/memories_mailer.php$ - [L]
RewriteRule !\.php$ - [C]
RewriteRule .* - [L]
If the third-party *_mailer.php files reference other helper php files, such as a confirmation page or error page, those php files would need to be added to the set of explicit URLs to allow.
The reason for being specific and explicit is to prevent access to a normally inaccessible php file by using a relative path from the 'etc' folder (when ANY file starting with 'etc/' is allowed), such as
mccleerywolves.com/etc/../install/constants.php
This example is to show how a relative URL to any php file can be enabled by use of the '/../' syntax when 'etc/' is a wildcard prefix, not to show an example of a security risk.
I don't know of any security risk in Omeka code today that can be created by leaving the 'etc/' wildcard enable in, but there might be one someday.
FYI - I just removed a contact form from a web site because it did nothing but generate emails created by comment-spamming bots. It generated about five bogus emails a day, with the message containing nonsense text along with html links to products. The forum here gets the same sort of automatic posts on the weekend that get cleared by the moderator later.
As your site gets indexed by the search engines and your visitor count goes up, you will eventually be added to the set of sites that the bots visit. Keep up the contact and submission form until then, but be ready to change those to pages that simply give your email address and suggestions on what to email you.
---
For the record, if anyone finds this thread, notice what kecan has surfaced - direct access to a php file by URL is not allowed when using standard Omeka.
The standard Omeka system has a policy to force all requests for action to be handled by the main controller php file, index.php. Other php files may not be accessed directly by URL. Other files, such as html and jpg files may be accessed directly by URL.
My earlier post is correct in how to create URLs to internal files using the global define WEB_ROOT but it is wrong in that it does not mention that a URL to an internal php file will fail because of the rewrite rules in the standard .htaccess file.
In order to enable URLs to internal php files, it requires adding rewrite rules in the .htaccess file to enable the special cases, as kecan discovered.