shinerweb

The error code 304 is this (as shown on the URL you provided)

OXSUS00X_304
550 5.7.1 Connection refused
We could not accept your email because the domain used in the From: header either does not match the MAIL FROM address or the SPF record.

Double check that the Domain you are using in your “From:” header hasn’t changed, and ensure it matches the Mail From address/SPF Record as suggested.

You can change that via the “Emails and Actions” tab on the form editor.
You can edit or create new notification actions to use the correct email addresses.

If your site is using an SMTP plugin (advisable to improve email deliverability), check the settings to make sure this isn’t overriding any email addresses to fix them as the site admin.

Did you remember to scroll down the page and check that this is set correct for PAGE, POST, PORJECTS, FILES as appropriate. (There may be other types depending on your set-up).

I would say that by default, Ninja does not store IP addresses associated with a form entry so yes, unless you explicitly add it yourself, no IP address will be stored.

No sooner than I hit reply did I spot an addon called “User Analytics” (https://ninjaforms.com/docs/user-analytics/)

This lets you store a whole bunch of fields to the form, one of which is the Users IP address. All of the fields are invisible to the end user, but will be stored as form values and hence be stored in the database along with the actual form data submitted via the form user.

Short answer is yes and no. (yes is processes it, but no it doesn’t store it).

It does not appear to be stored in the database (submitted form data is stored in the _postmeta table) however, it is present at form submission time. It possibly be stored but it can be emailed as part of the notification/confirmation.

In your confirmations that you can send to site admins/users, you can output the IP address of the submitter by using the {other:user_ip} but {system:ip} also seems to output the same IP address.

In your confirmation body if you had the following:

{field:all_fields}

{system:date}

{other:user_ip}`

You would receive an email with all the values enter on the form, the date of submission and the IP address.

If you use the action “Export Data Request”, this adds the users data to WordPress’ personal data export tool, allowing admins to comply with the GDPR and other privacy regulations from the site’s front end. I am assuming here as I’ve not actually done this part, but you would hope that one of the fields passed across is the IP address to allow WordPress data management tool to manage it. However, if the IP is not stored by default, then there is no need to WordPress’s personal data tool to manage it. So my assumption here could be wrong.

If you export the submitted data, there doesn’t appear to be an IP field which as we’ve seen above in the _postmeta table, isn’t stored.
However you could possibly create a hidden field and set its value to {other:user_ip}`which would then allow you to export it with the other user submitted fields. If there isn’t already a plugin/function to do that, you could also add your own filter to achieve the same functionality (the filter adds the users IP to a new value stored with the users submitted entries).

Hope that helps more than confuses.

Regards

Chris

Can you post your diagnostics output?

Double check that you have registered the redirect URI in your Google API settings correctly.

If you have forgotten to add it, or there is an error, it can take some time for the new changes to be picked up. So if you do correct it, give in at least an hour if you are still seeing the same error.

“[email protected], Margriet <>”
is a invalid email address.
You don’t want the “, Margaret <>” so I’d look at Caldera forms to see how you are formatting that From: field.

If you are following the instructions as you mentioned in the second email, what do you have your From: address set to outside of Caldera?

@neptun WP Hide Login is a simple plugin and I use it on well over 100+ WP sites without any issues. The issue you describe sounds like a caching issue whereby the old login page was still present in either a local or server cache (or combination of both). (And I note you use WP Rocket on the site, if you are using Sun Comet’s WordPress hosting, they might have additional server-side caching enabled).

I can’t comment on the support as I’ve never had case to use it however most plugin authors do so on a volunteer (unpaid) basis so support can vary from plugin to plugin.
As a fellow user of the plugin, if I had seen your message earlier, I might have been able to help ??
I’m surprised Support at Sun Comet didn’t pick up the caching issue.

Hope all goes with the site from here on.

Chris

• This reply was modified 3 years, 3 months ago by shinerweb.

Do you have Gravity Forms handling your users account set-up?
Check your form notifications if you do.

It appears that you have .htaccess protection enabled on your old wp-login.php page which is not the same as WordPress login.

This plugin changes the your-site.tld/wp-login.php link to something unknown to attackers. So any robots/scripts automatically trying to log into the default WP login page are rejected.

The login page can only be accessed by those you give the new login link to.

On your site, you had two levels of login. .htaccess which is done at the server level and can be set via your hosts cPanel (or similar) and you had the normal WordPress login.

Are you allowed to install this plug-in on WordPress.com?

On your form, you need to click emails and actions, and then add a new action.
You can then build your auto reply.

• This reply was modified 3 years, 6 months ago by shinerweb.

That’s a feature that you setup from within your Google workspace account.

https://support.google.com/a/answer/96474?hl=en