Author
Topic: mpForm (Read 7281 times)

this works for exactly this used form with exact this number of fields, but not in another form with more or less fieldsmy personal opinion is: for the actual database table structure you need a for each loop for a empty insert of every submitted field (like your example, but dynamic)or set a default value for the fields in the result-table

P.S. your insert-example shows my, that its a mysql-script-problem (needs definition for every submitted field) - and it show's me also, that my script to ask for the sql-mode doesnt work

P.S.: Martin Hecht offert a new version of the module, but its need a lot of work and a lot of input from the users and maybe also any brain storming about the best solution for some problems like this with the sql-mode

this works for exactly this used form with exact this number of fields, but not in another form with more or less fields

Yes I know, it's only a solution for me....

Quote

P.S. your insert-example shows my, that its a mysql-script-problem (needs definition for every submitted field) - and it show's me also, that my script to ask for the sql-mode doesnt work

Yes, I noticed this [/quote]

The bad thing is that this problem is happening for nearly all modules and as I have a couple of websites it's really a lot of manual work to fix it all I already tried a work around by temporally switching off the strict mode but it did not work, maybe I inserted the necessary code in a wrong file...

The bad thing is that this problem is happening for nearly all modules and as I have a couple of websites it's really a lot of manual work to fix it all I already tried a work around by temporally switching off the strict mode but it did not work, maybe I inserted the necessary code in a wrong file...

I had some good results with adding the next line to the config.php (below the last line calling initialize.php)

P.S.: Martin Hecht offert a new version of the module, but its need a lot of work and a lot of input from the users and maybe also any brain storming about the best solution for some problems like this with the sql-mode

at the moment I have a few other things in the queue, but yes, I recognize that sql strict is becoming more and more common. I have noted your settings for enabling it in my test environment, and definitely, I'll start with mpform when going through the modules and making them "future-proof". We can also collect modifications here in the forum and I can merge them into a fork of my current source-tree which then can replace the current module, once it has become stable.

from my point of view: this cannot be the (official) solutionof course - it works, but mysql and the providers offert this strict mode as a "secure feauture" on more and more providers used this mode now and if i switched off and my provider shows me, this was the entry for a hacker, i lost my account and have to pay for the trouble on other domains on the same server. maybe, its allowed in other countries, but i see some possible trouble with the rules in germany

the core and his modules works in strict mode and for some small modules like bookmark, color4code, code2 we found (together with the module autors) a solution and build a upgrade, but its not possible for all the modules at the same time. i talk also with some autors of other modules and not everybody means, a upgrade for mysql-strict-mode make sense so, what can i do? build my own module fork? No, thats not my way

the target must be: all modules in addon area works in strict mode!not today or tomorrow, but in the next half year

what I don't understand is, what's this mpform_results for? The message is stored in mpform_submissions and in the backend I can see all messages. So what is mpform_results for? Can I ignore it?

actually, this is a good question. I have been talking to the former developers of the module (except for Frank who is not active in WB anymore). The only note I can find in the Changelog is Frank's comment in the very first version when he forked mpform. The results tables actually are not read at all in the module. It might be an interface to other modules (maybe shops?) which query these submissions from the results tables. But that's just speculation. Maybe it's simply unfinished code which we could strip off. If anyone has some more insight into the purpose of the results tables, please contact me. Otherwise I would start to clean up the code of mpform with the goal to achieve sql strict compatibility and more stability. I'm pretty sure this can not be done over night, but let's say at some point in the near future.

no response about the results-tables so far? well... ok. maybe we can remove it in a future release, but for now I have an update:- this update does not overwrite the css files and the private functions anymore. At some point in the past this feature got lost.- in the latest version 1.1.20 you can configure the replyto-address now. This was a feature request by user "noname8"

Logged

instantflorian

The "email recipient" feature does not work, unfortunately. I tested with WB 2.8.3 SP6 and "the other one"™. I entered the example adresses from the backend (btw, it should be reading "staff" and not "stuff", in english, I think, and maybe one should better use "example.com" as placeholder domain), and just email adresses without names. In all cases, the select box does not work, for each address only

<option value=""></option>is created.If I switch on PHP error messages, I get

Quote

Notice: Undefined offset: 2 in /.../modules/mpform/paintform.php on line 32Warning: explode(): Empty delimiter in /.../modules/mpform/paintform.php on line 35Notice: Undefined offset: 0 in /.../modules/mpform/paintform.php on line 46

for each possible entry.Problem seems to be caused at line 433 of paintform.php

Only use one picture if you need it, maximal size: 600x100 Pixel and 20kb. The “most important rules” of course are also valid here. Only 1 normal, non-commercial link to a WB-site is allowed. Shortened links are not allowed (tinyurl, etc)

I know. I have downloaded the old documentation, but I still have to update it. And I'm still busy with the major mpform upgrade which will then include the documentation. I have already cleaned up large parts of the code, but one thing I still have on the agenda is to make it sql-strict-compatible, and developing a mechanism to repair/recreate the results tables. The release posted today is just a bug fix the French language file.

BTW: I have found the answer what the results-tables are good for: It's indeed an interface to access the posted data, either from another module, or by exporting the tables using the csv-export module.

Another point: Does anybody have a backup of the import-section and export-section modules?

Great. According to archive.org the latest ones were 0.2.4 - but these are at least better than nothing (because the zip files have not been archived there)The reason why I'm looking for these modules is that the old mpform documentation contains a few pages that rely on them, e.g. here, and I think it makes sense at least to look at these "helper" modules as well. I'm not eager to maintain more modules, but maybe I can include the needed functionality into mpform (i.e. importing and exporting forms). I'll have a look.

Hi, my error_log is full of missing success.png which is called in /modules/mpform/ajax/jNotify.jquery.css

missings pics only visible for one or two second after a ajax-action - simple solution is : edit the /modules/mpform/ajax/jNotify.jquery.css and use there the three images from the mpform-images-folderthis images has a size from 16 x 16

Hi, my error_log is full of missing success.png which is called in /modules/mpform/ajax/jNotify.jquery.css Can you confirm this?

it seems these images got lost at some point back in the past - or, more likely, they were never included.

An updated version of the module is attached. It contains the original jnotify images. I have also updated the links for the documentation, pointing to the web archive now (it's really just a workaround until I have a major update for the module ready).

promised long ago and finally finished: Here is the major update of the mpForm module with the following changes:

New Features------------

In the backend of the module you can import and export the whole form(including all fields and settings) as xml file. The submissions andresults tables however are not exported. This mechanism can also beused to install the standard forms which is available together withthe documentation (sse below).

There is a new wizard now, which allows to populate html code sectionssuch that div-sections are shown or hidden, depending on the currentselection of another form element of your choice. They are calledconditionally displayed blocks. They are not really a field type but you can easily populate a html code block with sophisticatedcode, which you can distribute later across several html sectionsin order to show/hide whole parts of the form.

Hidden fields are now available for inserting data into the form submission which is hidden to the user - this can be useful for handingover data between different pages of multi page forms.

Italian language support has been added and the language support in the Ajax helpers has been improved.

Feature Enhancements--------------------

The switch to enable/disable fields is available to all field types now,including html code and headings.

In the past the results tables often were a source of trouble. In thisversion of mpform their structure is always kept up to date. If you happento change the suffix for the results table in the settings, add or copyfields the table is created or the column is inserted if needed.

Additionally, if you wish not to make use of the results tables at all,you can disable them completely by setting the suffix to the string"DISABLED".

For html code fields there is a new switch which allows to specify wherethe code shall be used: In the form on the web page, in the html codefor the site owner, and/or the html code for the user confirmation.

In html code sections normal html comments can be inserted which are shown in the output as well, but as a new feature, if the inner partof the html comment is additionally commented out with php comments,it is suppressed in the output: <!--/* vanishing comment */-->

API Changes-----------

The private functions take more arguments now, because the mpform module does not make use of global variables anymore. Of course, theusual globals like the database object and the superglobals like the session are available. For details see the private.default.php.The examples are more detailed now and better commented.

Documentation-------------

The documentation has been updated and included in the module.(unfortunately the forum software forced me to split it up again intoseparate zip files - you can copy the content of the documentationinto the module in a folder called "docs" so that you can call it from the backend. You might want to protect that directory via .htaccess).

Bug fixes---------

The results tables are correctly removed now, when a mpform section isremoved. In the past unused results tables were kept in the database after removing the forms until one eventually uninstalls the module.This change also implies that you should make a backup of the submissionswhen you remove the form. The results table is of course kept in the casewhen multiple forms write to the same results table.

General Changes---------------

Promised a long time ago and finally finished: The module works in sql strict mode now.

In general the code has been reworked a lot. Long lines have been wrappedand properly indented for better readability of the code and to assistusers when they try to identify a bug. It is not a complete rewrite of thecode but nearly. Module specific global variables are not used anmore.

Old code for WB 2.7 has been removed and code for backwards compatibility to versions of WB 2.8 earlier than 2.8.3 have been made consistent throughoutthe whole code. IDKEY and FTAN are two examples. These features are only used when the core supports them. In general it is not recommended to run old versions without such security features. But anyhow, in the previousversions of mpform, there were checks which allowed to run without them,but not in all parts of the module.

When sending http headers to redirect the user to another page, there is an additional check now, if the headers have already been sent. If so, an alternative redirection link is presented to the user. This can helpwhen other modules/snippets interfere with the way how the content is buffered or sent to the user.