Juergen

Hello Flo,

5 hours ago, snck said:

And I just had another idea 😄: Pages that will be changed by the module in the future could also be marked in the page tree, e.g. prefixed with a "clock" icon.

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

7 minutes ago, snck said:

I would appreciate a solution that does not populate dates automatically

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

39 minutes ago, PavelRadvan said:

In logs was only that MySQL shutted down and no extra info more...

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

2 hours ago, Flashmaster82 said:

// Email
$email = new \FrontendForms\InputText('scf_email');
$email->setLabel($fields->get('scf_email')->$label);
$email->setRule('required');
$form->add($email);

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

12 minutes ago, bernhard said:

I think the reason why the language is always the default one is because the hook adds to an URL that looks like the default language in PW - which makes sense.

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.3.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

Just a hint:

$form->getValue('fileuploads')

will output only the filenames.

If you need the path to the filenames too, you can use the following method:

$form->getUploadedFiles()

Best regards

@ngrmm

Please update to 2.1.58 - this version should fix your problems.

Please add the new validator to your fileupload field:

$fileuploads->setRule('uniqueFilenameInDir', true);

The following method

$form->getValue('fileuploads') 

should now show the sanitized and/or overwritten filenames as well.

The full explanation of the additions can be read here in the Changelogs.

As always, please take care if everything works as expected after the update!! 🙂

Thanks!! I will check this later on, but for now I am working on the first issue .

Hello @ngrmm

Interesting aspect I have not thought of before 🙄!

I am afraid, but there is no inbuilt method to prevent this.

I am thinking of a creating a new validator (fe uniqueFilename) to check if there is a file with the same name present inside the given directory. If so the validator should throw an error.

Maybe another possibility would be to add a new method to the file upload class (fe $field->renameDuplicates()), which renames duplicates by adding fe a number after the filename (fe. filename, filename-1, filename-2,...)

What do you think?

If you want to check your max upload file size, please add this code to your template:

echo ini_get("upload_max_filesize");

This will output the value as set inside your php.ini file.

You can see the line of code inside the InputFile.php: https://github.com/juergenweb/FrontendForms/blob/main/Formelements/Inputelements/Inputs/InputFile.php#L41

Good Morning @ngrmm

By default, the file upload field takes care about your max upload file size value that has been set inside your php.ini (server config file).

https://www.php.net/manual/en/configuration.file.php

2048 is the max file upload size as set inside your php.ini in this case.

You can disable this behavior by adding the following rule to your file input field:

$file1->removeRule('phpIniFilesize');

This disables the check of the php.ini max file size and you will get the desired result, but it is not the recommended way. If you have access to your server php.ini file, make your changes there and set a higher value for the max upload file size.

If you have a local installation (fe. Xampp), you can change it by yourself, if you have a site on a shared host, maybe you will need to contact the server admin, if he can change the max. value for file uploads or you can login to your account and make your changes there.

Hope this helps

No, I mean I have tested it locally on Xampp after adding some code to the "Password forgotten" page only for testing purposes. The version on GitHub is not updated!!

Sorry, this was a little bit confusing written by me.

Hello @mayks

 I have installed the module and I have sent 2 mails with it (I have clicked the "Password forgotten" link to send me a mail, where I can change my password). From the statistic data, it seems to work (only the "Sent" will be displayed, but I guess this is because I have the trial plan).

I have tested it only on the "Password forgotten" page, but at the first sight, it seems that only the mail object instantiation is a little bit different than like the WireMail, but all other methods are equal.

I cannot promise at 100% that I will implement it and if so I do not know when I will find the time (not today and not tomorrow), but it seems not to be so complicated.

I did not know this module or this mail service before and personally I will not use it, because I do not want to pay for it, but it could be interesting for users, who want a statistic.

My idea: If I implement it, I would add a Select option inside the module configuration with the options "WireMail" and "Postmark", so you can select, which kind you want to use.

Best regards Jürgen

Hello @mayks

Thank you for your comment. I will have to take a look first, how this works and after that I will decide if I implement it or not.  Best regards.