Elements Form, missing resources

I created a form (Contact US) with as much of the tipps/suggestions I could find here.
However clicking on the “Submit” (Send this message) button logs this :

Failed to load resource: the server responded with a status of 404 ()
https://www.vps13.org/rw/elements/com.realmac.apipack/api/email

in the browser console.

Which sort of makes sense as there is no “email” (file, directory) in https://www.vps13.org/rw/elements/com.realmac.apipack/api/ .

I tried to publish all (from File menu, etc.) as much as I can, but no “email” in the above path appears.
Any suggestions as to what I maybe missing?

TIA !

Have you chose to send the form by e-mail via SMTP, or to a webhook? And are all settings filled out for it?

Also, maybe check the e-mail field (in case the email part of the path comes from that).

Thanks @Thomas123no, sending the form should results in an email, to the best of my knowledge I filled out/in all fields (I could find).
This is however my first try with the Elements, v0.99, form, so bare with me here …

Would like to help, but not sure what can be going on here.

If you have filled out the SMTP server details, it should send. I guess you’ve checked that the submit button is actually inside the form component? Just in case… And that the button doesn’t have any other click actions.

In Version 0.9.10 also.
The image shows a console error message indicating a failed POST request to a local API endpoint, resulting in a 404 (Not Found) error. (Captioned by AI)

1 Like

Is this the best place to report bugs to the developers?

Hey Ulrich,
Don’t know if it is ‘the best’ place, but yes a number of the RealMac/Elements developers are on here also and regularly give solid feedback.
Which is much appreciated!

1 Like

Hi @Bart-Jan

The reason you’re seeing a 404 for https://www.vps13.org/rw/elements/com.realmac.apipack/api/email is not because there’s supposed to be a physical email file or folder on your server. Instead, the system uses an .htaccess file, which works with Apache’s mod_rewrite module to route any request (like /email, /form, etc.) to a single index.php file behind the scenes.

Think of it like this: you’re making a request to /api/email, and .htaccess says “no matter what the path is, send it to index.php, and let PHP figure out what to do.”

So, if you’re getting a 404, it usually means that the .htaccess file isn’t being read or isn’t working properly (often due to missing server configuration, like AllowOverride All or mod_rewrite not being enabled).

To fix this:

  • Make sure the .htaccess file inside the https://www.vps13.org/rw/elements/com.realmac.apipack/api/ folder is published to the server.
  • Confirm with your hosting provider that .htaccess overrides are allowed, and that mod_rewrite is enabled.

Let me know how you get on, or if you need further explanation as to what’s happening here! :slight_smile:

Hi @Ulrich — see my reply above, could you also check the following:

  • Make sure the .htaccess file inside the https://www.vps13.org/rw/elements/com.realmac.apipack/api/ folder is published to the server.
  • Confirm with your hosting provider that .htaccess overrides are allowed, and that mod_rewrite is enabled.

Thanks! :slight_smile:

Hi ben,

it’s an IIS. So we need a web.config. If i find out how it goes i will post it here.

The public/index.php runs (i added some log messages)
But there are no other messages in the log file.
Maybe i missed some extensions?
PHPInfo: PHP 8.4.10 - phpinfo()

/rw/elements/com.realmac.apipack/api/web.config

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Rewrite to public/index.php" stopProcessing="true">
          <match url="^(.*)$" />
          <conditions>
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
          </conditions>
          <action type="Rewrite" url="public/index.php" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

/rw/elements/com.realmac.apipack/api/public/web.config

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Rewrite to index.php" stopProcessing="true">
          <match url="^(.*)$" />
          <conditions>
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
          </conditions>
          <action type="Rewrite" url="index.php" appendQueryString="true" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

Look here: E-Mail with IIS - how it works

Hi @ben

sorry it took so long to get back to you.

There is a .htaccess in https://www.vps13.org/rw/elements/com.realmac.apipack/api/ I did not however that even though the current version of Elements (in my case 1.1.0) did upload a lot of files (around 2.900) that particular file has not been changed since the first of June.

I can edit the file by hand though (FTP, etc.)

Its current content being :

RewriteEngine On

# Route all requests to the ‘public’ directory

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ public/index.php \[L\]

According to my provider mod_rewrite is allowed. However they do recommend that one should include 2 things before every RewriteRule :

RewriteEngine On
RewriteBase /
RewriteRule ^([a-z]+)\.html$ /index.php?$1 [R,L] 

Unfortunately that did not make a difference.

So I decided to remove all files from the directory where “VPS13” is hosted. Publish All and try again.

Then the error message is a 404 on https://www.vps13.org/rw/elements/com.realmac.corepack/api/email (there is no ..apipack …)

(assuming this was changed in 1.10?)

But also (manually) adding RewriteBase / before the RewriteRule in http://www.VPS13.org/rw/elements/com.realmac.corepack/api/.htaccess

does not make things work.

As always appreciate your feedback, and open to more suggestions.

Bart-Jan.

That’s correct, internally we moved all our components in to one single “core pack”. So you won’t find an “apipack” folder any longer.

Hmmm, interesting. I am trying to get an htaccess file that works consistently across all hosts, but it’s not easy.

Could you share with me the entire .htaccess file that is working for you? And could you let me know who you’re hosting with?

Thanks!

Hey @ben ,

thanks for the speedy response.
Sorry for my confusing way of describing the status on my side, but unfortunately I cannot share a “working .htaccess”, as I did not get it to work (yet) :frowning: Sorry

VPS13.org is being hosted at IONOS - check out https://www.ionos.com, https://www.ionos.de - apparently the biggest cloud provider in Germany (as they are part of United Internet, I am guessing).

Any further info I can supply to help us solve this problem? Any log files/info which help you get a grip on this (I do appreciate that "getting to work across all hosts is a challenge, so please let me know what I can do to help)?

Hi Ben,
I have exactly the same problem. Instead of email, I use webhooks, which send the data to zepier.com and then enter it into a Google Sheet. This works perfectly on the zepier site. In the contact form, I always get a 404 error. I have checked the .HTACCESS file.

========================================

# REWRITES

# ========================================

<IfModule mod_rewrite.c>
    RewriteEngine On
RewriteCond %{HTTP:Authorization} .
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]

RewriteRule ^(.*)$ index.php [QSA,L]
</IfModule>

What could be the problem?

Thanks a lot…!
Tony

who are you hosting with?

One issue could be that your host only allows htaccess files at the root of the server (so no htaccess files in sub folders). I believe this has caused an issue with one host previously. Could you check with your host if they allow htaccess files anywhere on the server, or if it needs to be in the root? :slight_smile:

Hi Ben,
Thanks for your quick reply. I host the website with IONOS (formerly known as 1und1) in Germany. According to their support team, the respective .HTACCESS is respected in the subdirectories. On their recommendation, I changed the access rights from 604 to 644. Unfortunately, this did not solve the problem. Do you have any other ideas that might fix it?

Otherwise, I have to say that Elements is a great product and a successful further development of the Rapidweaver world. Even if it represents a system break for some.
BR
Tony

@Tony1, Could be a setup issue… Can you run through this checklist?

If it’s still not working can you check the form logs on your server?

Hi Dan,
Thanks for your checklist. I had already done all of that beforehand. To test everything independently of the host IONOS, I installed “Servbay” locally as you recommended. It doesn’t work with the default NGINX server. I then switched Servbay to Apache with PHP version 8.3 and it works. Zapier is a good recommendation, and I’m making an entry in GSheets and then sending an email to my info account in a further step. So far, so good. Now I just need to figure out why it’s not working with IONOS.

A minor issue arose after I installed Servbay: the Publish object from Elements no longer worked, either locally or hosted via SFTP. As soon as I stop Servbay, it works again. I haven’t been able to figure out why this is happening. Maybe you have an idea. For now, I can live with the workaround.

If you have any idea why it’s not working with the host IONOS, I would be grateful for any advice.

Tony