Juergen

Hello Flo, should it look like this: At the moment the icon will be displayed if a start and/or an end time has been set, but id does not take care if a change will happen in the future (publishing or unpublishing of the page)

Hello Flo, I have pushed the module version now to 1.3.6. This version does not auto populate the fields. I have removed all the Hooks which are responsible for auto population. So this is the one, which fits your requirements and you can use it until the other additions have been implemented. Best regards

Great idea! I will try to publish the new version as soon as possible, but I cannot say when it will be happen.

Making a visible alert/info about the current status and the future status too seems to be a good way and I can agree with it too. I will implement this feature and update the module after test runs.

It is more consistent, if a page is published and the date and time of publishing is visible in the published from field too. Otherswise, it may seem a little bit strange to some users, if the page is published, but the publish from field is still empty. But you are right, if you mean the visibility is handled by ProcessWire only 🙂

Hello Flo This is not so trivial as it may seem at the first sight, because there are use cases where automatic population makes sense: For example: An auto population has to take place if your page is unpublished and you push the publish button, but you do not have entered a date into the from field. In this scenario the current date and time have to be set (auto populated) inside the from field. I will test some other scenarios as well and I will provide another update, if there are some use cases not covered by this version.

Hello Flo, thanks for reporting this issue! You are right - the automatic population of the "from" field should not happen if a page is unpublished at the moment of saving. I will not add a quick fix inside the Hook function only, which is responsible for this behaviour. Instead I will test the module functionality more intense before offering a new update. I guess (hope) I will offer a new update solving this issue til the end of this week. For the moment, please overwrite the "from" date with a far date in the future to prevent the page from beeing published. Best reagards Jürgen

Good Morning @PavelRadvan Now I have tested the latest FrontendForms with the latest dev PW version on a live test server after upgrading to PHP 8.3.1 and in my case it works without problems. So I can confirem, that there is no problem using FrontenForms with PHP 8.3.1. Maybe your problems are caused by a misconfiguration of the server? But without getting error messages it is difficult to trace the problem to its source. I use it on a shared host and I do not make any changes to the server (and I am not an expert at servers). Best regards Jürgen

Ok, I have overread this before. At the moment I can only recommend you to wait until i have installed the module on the 8.3 server. I will give you an information about it. Eventually there are other forum members, which use 8.3 and have some experiences with it.

Thats a very strange behavior 🙄 Are there some errore messages inside the logfiles of PW (maybe a time setout message)... I have no idea, what the cause could be. As you write, this happens directly after you are trying to go to the settings page of the module..... but the only process, that runs in this case is the rendering process. So there must be something the stops this rendering process of the setting form. Maybe it could have something to do with PHP 8.3 because PHP Storm complains about not declared variables inside the setting form for the module. The point is that the creation of the setting form of a module is done via PW API functions and therefore I do not have an influence here. Please check your log files if something has been stored there. On the weekend I transfer a website to a server who uses 8.3. I will check this out to see if some problems occur.

Hello @PavelRadvan Thanks for your info at first. I have not discovered problems like this til now and I guess other users do not run into problems like this too. Otherwise someone has informed me about such a behavior. I only run this module on PHP 8.1, but there I have no problems at all. The code should run on 8.3 too, but I have only tested the syntax on PHP-Storm and not in live situation - so the code should be valid for PHP 8.3 too. Some question: Does the problem consist on every page request? Do you have tried to close all browser windows and open the website after that again (sometimes PW runs into performance issues, with an unknown issue and after "re-start" everything works as expected)? Does this problem persists if you are calling only the backend (without forms output on the frontend). Maybe you could give me some infos about that. Best regards Jürgen

Hello @Flashmaster82 You have only added the required Validator. There are a lot of examples inside the examples folder how to validate an email address (fe at the contact forms). In this folder you will also find a special file with a lot of validation examples: https://github.com/juergenweb/FrontendForms/blob/main/Examples/field-validation.php. This file contains examples of (nearly) all possible validators and how to add them to an input field. There are 2 special validators for validation of an email, which are interesting for you: Validate email address (This is what you are asking for) Validate if email address exists (This checks for an active DNS record) In the next steps I will show you 3 possibilities (option) how to validate an email field. Option 1: Add the additional email validators to your code example // Email $email = new \FrontendForms\InputText('scf_email'); $email->setLabel($fields->get('scf_email')->$label); $email->setRule('required'); $email->setRule('email'); // checks for the right syntax of the email $email->setRule('emailDNS'); // optional: checks if the email has a valid DNS record $form->add($email); This works, but it is not the recommended way for emails. You have used an InputText input field, but for emails there is a special input field, which includes the mentioned validators by default: InputEmail Option 2: Instead of using InputText, it is better to use InputEmail, which includes email valdiation by default // Email $email = new \FrontendForms\InputEmail('scf_email'); // make usage of InputEmail $email->setLabel($fields->get('scf_email')->$label); $email->setRule('required'); $form->add($email); As the last option, I want to show you a pre-defined email input. To simplify life, I have created pre-defined input field types for the most used form fields, like surename, lastname, email, message and so on. You will find all this pre-defined fields inside the defaulf folder. These default fields includes validators and labels for these inputfields and the code is very short. Option 3: This code includes all email validators and the pre-defined email label - it is the shortest version. // Email $email = new \FrontendForms\Email('scf_email'); $email->setRule('required'); $form->add($email); Now you have 3 options, where you can choose from. Best regards Jürgen

Nevermind @mayks! I hope it works as expected, because I do not use Postmark and therefore I have only tested the base function (sending process). Please take care that only 1 external mail module is installed, otherwise you will run into problems, but this is not a module related issue, it is an PW issue. In this case PW takes always the first external module in line and ignores all others (independent of you settings inside this module config).

Hello @bernhard This seems to me also as the most possible reason for this behavior. BTW, I was not confronted with this issue since then, but thank you for reporting an issue at GitHub and for the information. Have a nice day!

Version 1.2.0 ist out! This version supports mail sending with Postmark mail sending service. Read the full changelog.md for more information about Postmark and what has been changed. If you have one of the Postmark modules as mentioned in the changelog installed, you will find a new configuration field inside the module configuration. Here you can select if you want to send your mails with Postmark or not. Selecting "none" means using the default WireMail class for sending mails. In order to work properly, you will need at least FrontendForms 2.1.57 installed (as mentiond in the changelog.md). As always, this is Beta-status, so please take care that everything works as expected. Happy testing! 😃 Jürgen