Stable version of MPForm ( Multi Purpose Form)

[FrankH]

See below

[Argos]

Hi Frank,

multipage is very welcome, so great that you are going to work on it. Another thing that has been requested a number of times is the option for the admin to set more than 1 email address for the (receipient of the) form. Also an option for the user to choose a receipient via a menu in the front end is much wanted. Do you see the possibility to incorporate these options as well?

I have a version of the FormX module that has 2 extra options above the default ones: to download submissions to a CSV file (from the backend), and to use an extra field type "numeric". I can send you the module if you like, maybe you can use it.

[chio]

Sounds good!
Will it work with PHP < 5?

A suggestion:
A fixed, hidden field for the referrer. I often use a link to the contact-form in the template footer, where I can add a parameter like "contact.html?ref=$page_id"
I mean something like:
if (isset($_GET("ref")) {automatic add a hidden field "referrer"}
Or have a field with id="the_referrer", so one can set the value with javascript.

[Wizzo]

Formx2 with multiple pages...

I just can't wait!!!

If you need any help or support otherwise let me know!

[erpe]

@all:
To use the module, you willl have to fix a bug in framework/class.admin.php first.
It is described here: http://project.websitebaker2.org/ticket/717

Is this one fixed with 2.8 ?

rgds

erpe

[Argos]

@Argos:
Multiple email addresses: I don't need them, but I think it is possible to include this feature. Maybe not in the first release, though.
Download: this is what the csvexport module is thought for
Numeric field: sounds good, could you send the code snippet?

I'm willing to pay you 50 bucks if you can do the multiple mailadresses for the next version. And another 50 if you can the do the frontend mailadress chooser in the next version.

The numeric fields is added by someones, I'm not a coder myself. i can send you the complete module, so you'll have to figure out yourself how it works. The same goes for the CSV download, which is different from the CSV download module. The module downloads form module entries, so multiple forms all go into the same database table. However, my form CSV download function only downloads that particular module entires, and not all form entries together.

[Argos]

Currently, the new form will only have English and German language files.
It someone wants to make another language file, please let me know.
You will get some work to do soon

I can do Dutch if you like.

[oeh]

Currently, the new form will only have English and German language files.
It someone wants to make another language file, please let me know.
You will get some work to do soon

I'll do the Norwegian translation.

[snark]

I would like a subject field possibillity

something like how you can define a field for the sender in the settings

anyone thought about that yet?

[mr-fan]

hi Frank,

i've got a request - if it possible.... thorn has built a solution for the Form-module to show the output in the frontend sorted....

it would be nice if the mpform can present the result of the e.g. useropinion from a multipleform or to list the fields for a registration list like the request of the formlist-modul was created?

could be a nice feature - not a important need

http://www.websitebaker2.org/forum/index.php/topic,12377.msg75760.html#msg75760
(in german)

regards martin

[Argos]

Hi Frank,

this may be a nice (although not very urgent) feature: http://devkick.com/lab/modalpreview/

[snark]

You mean the subject line of the email should be set by the user instead of the backend?

exactly

[Argos]

Hi Frank,

this may be a nice (although not very urgent) feature: http://devkick.com/lab/modalpreview/

Hi Argos,

because the form module does not provide any text formatting features like an editor, it would not make much sense to have such a preview window. It just will shos the same as the form itself. IMHO, this only makes sense for formatted text.

Valid point, but another reason may be that long text areas are often relatively small, so with longer messages the user doesn't have a good overview of what he has written. A much bigger modal window preview offers a nice way of looking at what you'vre written in a more comfortable to read way.

[Argos]

You mean the subject line of the email should be set by the user instead of the backend?

exactly

If we are there, would it make sense to have an "email body" field as well?
I mean, if such a field exists, only the content of this field would go into the body of the email, nothing else.
Other fields which might exist in the form would only go into the database.
Would this be of any use for someone?

Personally I'm not sure what use both things could have. But maybe a real live example would be enlightening.

[FrankH]

Valid point, but another reason may be that long text areas are often relatively small, so with longer messages the user doesn't have a good overview of what he has written. A much bigger modal window preview offers a nice way of looking at what you'vre written in a more comfortable to read way.

Ok, there is yet another bug in the form(x) modules: They do not save the value for width and height of a textarea.
This will be corrected in the new module. This way, you can make the area as large as needed, and people can better see what they wrote.
The modal window might come in a later version, but i am not sure, yet.

[Argos]

Allright, thanks Frank. I just noticed something else, but I'm not sure if it's related to FormX or what to do about it. In the Netherlands we use quite a lot accented characters like ë, ï, é, etc. I noticed that when you use such characters in the Settings they are not shown correctly in the generated email. For example "patiënten" in the backend settings becomes "patiënten" in the generated email. Both website template and formx module are set to charset=utf-8, so they should be able to show those characters right. Where to look for a solution?

[Argos]

This bug (among quite some others) is already fixed in the new module.
Ever tried to put a ' in the help field in formx, by the way? It won't work at all after you do this.

Great! I'm REALLY looking forward to your new module! I think it's a very big step forward for WB to have a really decent and bugfree form module at last.

No, I never use the help function. I don't like the way it shifts content, and the crummy looks.

[Stefek]

Hello Frank.
I like to use the help.
But I do not like it the way it works in formx right now. I did a (hardcoded) output once so it appears as a tooltip when I go over the help-icon.
Maybe there is some possibility to integrate the help in such a manner that one will be able to controll the output better?
But please do not consider to remove it

Regards,
Stefek

[mr-fan]

hi Frank,

i've got a request - if it possible.... thorn has built a solution for the Form-module to show the output in the frontend sorted....

it would be nice if the mpform can present the result of the e.g. useropinion from a multipleform or to list the fields for a registration list like the request of the formlist-modul was created?

could be a nice feature - not a important need

http://www.websitebaker2.org/forum/index.php/topic,12377.msg75760.html#msg75760
(in german)

regards martin

If it is already in the formlist module, then why should it be in another one, too?

hi frank,  (sry i try in german that i can better explain...)

wegen der list-eigenschaft hätte ich nur gemeint das es einfach ein tolles feature wäre, wenn schon ein mulitform für forms über mehrere seiten (dabei kann man sich userbefragungen/anmeldungen oder sonstiges vorstellen... dann warum nicht mit einer möglichkeit diesen input im frontend darzustellen? in form einer Liste oder ähnlichem...

es ist mir schon klar das es deswegen das formlistmodul gibt - nur es basiert halt zum einen auf dem formmodul und thorn hatt in dem threat eh geschrieben das er übersehen hatte es gleich mit dem formX durchzuziehen...

hab nur gedacht, da du dieses formmodul ja auch für csv-export auslegst hast du die formulardaten nicht wie im alten formmodul in einem body (im backend und DB) also wäre so ein output im frontend leicht zu integrieren!
Deshalb meine request - wenns nicht geht nicht -

(wollt es nur noch mal bisschen konkreter erklären)

 

grüße martin

[Stefek]

Schließe mich Martin's Feature-Request an

@{HELPTXT}
sounds great.

Regards,
Stefek

[Argos]

Schließe mich Martin's Feature-Request an

My philosophie is as follows:
A module is called module because it is for doing a modular task
An form module is for aquiring data with the help of a form.
For the modular task of exporting those data into a csv file, I wrote the csvexport module.
For the modular task of showing those data in the frontend, someone can write another module.

I am sure not everyone wants the aquired data to become public

It's good to have a clear view of what a module should do, but I think it's also good to try to incorporate as many wishes into it as possible. And export and publishing data are in fact very good features to incorporate into the same module.

It is a pity if people are forced to use the very limited formlist module to publish data, if the function can be part of the far more powerful new general form module you create. By doing so the current formlist module (and the regular form module as wel) becomes obsolete and the new module becomes even more powerful.

The same goes for the export. You can use the export function I sent you, and as I explained it has a bonus above your export module because it exports the curretn form only. Your export module is very nice, but it exports all form submissions in the same table. I have sites with many forms, and exporting submissions is only useful for particular forms, instead of all forms together.

I hope you might think it over, and create a general form module with as many as features as possible, even though it might not fit your own idea of how a module should be

[mr-fan]

My philosophie is as follows:
A module is called module because it is for doing a modular task
An form module is for aquiring data with the help of a form.
For the modular task of exporting those data into a csv file, I wrote the csvexport module.
For the modular task of showing those data in the frontend, someone can write another module.

I am sure not everyone wants the aquired data to become public

No problem - i only wanted to explain it better....

I think your philosophie is the right!!

The MAIN thing is to have a new polished formmodule and you have to choose to make this modul!!!

Thank you again for your contribution!

regards martin

[Stefek]

I hope you might think it over, and create a general form module with as many as features as possible, even though it might not fit your own idea of how a module should be

I agree with this, Jurgen.

@Frank
Even if you are not going to implement this featue in the near future, it would be great, if you leave a "open backdoor" for this to implement.

Kind Regards,
Stefek

[mr-fan]

    * You can alwas have only one view.php for the frontend in a module. So the view is the same for all people who can fill out the form. Most often, only part of those people or even another group should be able to see the results. Currently I have no idea how to implement this into the same module.
    * Currently I have no idea how to clearly represent, for instance, a long list with a lot of fields, some of them textareas, and a lot of input on a web page.

sorry frank - i don't know this fact! (stupid nocoder... )

i only read your call for requests.... but i think your solution is a real good suggestion
(someone/time after your mpform is well running make a additional modul for this request! with a separete modul/view.php for the output - then we can overview how the mpform run's and what output&range your module gets)

I think if the discussion will continue, I do not need to write a HowTo anymore, because it is all in this thread wink

i know from my work (no e-workers job...) that is easy to make suggestions - but to realize some - you must think ahead and the catchiest part is not to loose the goal out of sight!

I don't thing that this happend to you - you go straight on   

regards martin

[Argos]

• With your solution you can not have the results from a multi page form in one csv file, with mine you can
• With the new form module, it is no problem to separate the input from different forms - just specify different "Name suffix for results table" in the settings for each form you want to separate and the results will be written into different results tables. You can have as much results tables as you need
  

1: I'm not sure why you think that. My solution exports all complete results of the form from which you export.
2. But that's a good alternative solution, I didn't know that it would be possible to give the form a name suffix. Nice.