Moved site to root folder - extra PHP file I added won't work

I moved my Omeka site from my /project directory to my root directory today, because I'm ready for it to go public. I just dropped and dragged all the files and folders into the root directory. Everything seems fine so far, except for one issue.

This is my contact form:

The code for the contact form is written in the simple page itself, and it references a php page in an "/etc" directory I made, so the path is:

The code that references the php file is:

<form name="comments" action="etc/code/contact_mailer.php" method="post">

I've also tried "/etc/code/contact_mailer.php" (extra slash at the beginning) to no avail. It worked just fine when my site was in the /project directory (and the /etc directory was in the same place as it is now) before the release. I modified all the paths so that it should reference it correctly, but when I click "submit" on the contact form, it says:

"/etc/code/contact_mailer.php is not a valid URL."

I also have an /images directory in this /etc directory, and those show up just fine, so I imagine it's something to do with the php only.

I hope I explained this problem adequately. I would sincerely appreciate any help! Thanks!

EDIT: I got it to work by uploading the contact_mailer.php file to a different host and linking to it. But I won't be keeping that additional host for much longer so I'd still like to know how to fix this issue if possible. :)

I tried several ways to get the correct URL to various files for my site before seeing examples using PHP defines that are set in the top level Omeka bootstrap.php file. They are available for use by all PHP code within the site.

For getting files within the Omeka area via URL, whether the Omeka root is at the top level of the domain or down a folder or two, use the define WEB_ROOT to set the prefix of the URL to the Omeka root.

This means that if you have a form action named "etc/code/contact_mailer.php" relative to the Omeka root, the URL to it can be set by using

$action = WEB_ROOT . "/etc/code/contact_mailer.php";

To use this with the HTML form statement you are using, change it to this

$action = WEB_ROOT . "/etc/code/contact_mailer.php";
<form name="comments" action="<?php echo $action; ?>" method="post">


<form name="comments" action="<?php echo WEB_ROOT; ?>/etc/code/contact_mailer.php" method="post">

This could have been used when Omeka was installed down a folder and it would continue to work when the Omeka root was moved up to the top level of the domain.

As a precise way of talking about this, it is not a "path", it is a "URL". The term "path" is used when referring to the file system location of a file, when PHP code is going to read/write the file in the file system, referring to the file by it's "path". "URL" is the address to the file via the web server in the world of HTTP requests.

If you were going to open and read the file "etc/code/contact_mailer.php" for some reason (not anything you are currently doing) then you would use the define BASE_DIR to define the file system path to the file.

Code to access that file in the file system would be something like this:

$filePath = BASE_DIR . "/etc/code/contact_mailer.php";

I use the file system path to files when building a site map and updating the robots.txt file in the top level folder.

$robotsPath = BASE_DIR . "/robots.txt";
$sitemapPath = BASE_DIR . "/sitemap.xml";
if (is_writable($robotsPath) {

Here are examples of both the "URL" and "path" values to show the difference.

The URL to the contact_mailer.php (based on setting the action using the "WEB_ROOT" define would be

The "path" to the contact_mailer.php (based on setting the path using the "BASE_DIR" define would be something like


(I'm not sure what the start of the file path would be to get to the "public_html" folder of your domain because that depends on the server you are using.)

If you use the "WEB_ROOT" define to provide the correct HTTP prefix for accessing a file via a URL, it will work. A URL is needed for a form action and it is also needed for referencing an image.

What is confusing to me, and to you as you state, is your report that reference to images in the folder /etc/images/ are working ok. If these are referenced by HTML such as
<img src="etc/images/file.jpg">, then I am very confused. That use should only work for images referenced in the top level index.php file. Any simple pages using those images with that HTML should fail.

Here is what I would do to reference an image in that "etc/images" folder in all places it is referenced, with "file.jpg" changed to be the specific image file.

<img src="<?php echo WEB_ROOT; ?>/etc/images/file.jpg">

This will provide a valid URL to the image file when Omeka is installed at the top level of the server or down a folder or two.

My apologies for how long it took me to respond! Bob - thank you SO much for your in-depth help! Unfortunately, that solution did not work.

However, I found out why it isn't working, and I found a solution.

Omeka's .htaccess file has "ReWrite Rules" which allow direct access to files except PHP files. Before I released my site, I had the entire site (including the .htaccess file) in a /project directory, which was a subfolder of the root directory. I had my PHP files for my contact form in the /etc directory, which was another subfolder of the root directory, not affected by the .htaccess file in the /project directory. When I moved my site (including the .htaccess file) to the root directory, the .htaccess file stopped allowing access to the PHP files in the /etc directory.

Therefore, I had to exclude the /etc directory from the rules established by the .htaccess file.

I did this by adding this line of code immediately under the "ReWrite Rules" heading in the .htaccess file:

RewriteRule ^(admin|user)($|/) - [L]

Now I can access the PHP files in the /etc directory, and they work just fine with my contact form.

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

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

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.