WBCE CMS – Way Better Content Editing.
You are not logged in.
Das mpForm Modul hatte schon länger mal ene gründliche Renovierung nötig. Endlich bin ich damit fertig und hier ist das Ergebnis (bitte mal kurz testen, bevor ich es nach so umfangreichen Umbauten ins Repo schiebe):
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 and
results tables however are not exported. This mechanism can also be
used to install the standard forms which is available together with
the documentation (sse below).
There is a new wizard now, which allows to populate html code sections
such that div-sections are shown or hidden, depending on the current
selection of another form element of your choice. They are called
conditionally displayed blocks. They are not really a field type
but you can easily populate a html code block with sophisticated
code, which you can distribute later across several html sections
in 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 handing
over 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 this
version of mpform their structure is always kept up to date. If you happen
to change the suffix for the results table in the settings, add or copy
fields 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 where
the code shall be used: In the form on the web page, in the html code
for 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 part
of 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, the
usual 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 (I hope
that the forum lets me upload the file - if it is too large, I'll
make it available as a separate zip archive).
Bug fixes
---------
The results tables are correctly removed now, when a mpform section is
removed. 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 submissions
when you remove the form. The results table is of course kept in the case
when 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 wrapped
and properly indented for better readability of the code and to assist
users when they try to identify a bug. It is not a complete rewrite of the
code 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 throughout
the 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 previous
versions 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 help
when other modules/snippets interfere with the way how the content is
buffered or sent to the user.
Edit: deleted the attachment, see follow-up post for the corrected one
Last edited by mrbaseman (29.07.2016 16:27:35)
Offline
something in the build process went wrong yesterday. Text from the release notes has been inserted by mistake into all php files. I'm sorry.
Here is a fixed version (and also fixed the redirection to the documentation when clicking on the help item in the backend)
Offline
Not tested yet, I will have a look at it later.
You may want to remove or replace the 1.2.0 download file ?
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
You may want to remove or replace the 1.2.0 download file ?
oh, thanks for the hint. I didn't expect to have the permissions for editing the post even on the next day. Cool.
Offline
So here are some test results.
Frontend:
- form is not displayed in frontend:
Parse error: syntax error, unexpected 'return' (T_RETURN), expecting '{' in /.../modules/mpform/private.php on line 63
WBCE 1.1.6, PHP 5.6 (indeed, there's a curly bracket missing in line 52)
After fixing this everything works fine.
(Just some grumbling: Its a disadvantage that the module still generates 1995-style table code per default. Also the huge CSS file makes it hard to customize the frontend view. Compare this with miniform: that module is responsive by default, looks good in nearly any page design without bigger customizing and can also display more than one field per row.)
Backend:
- I don't understand how to use the conditional field. There are no switches or input fields at all and the frontend output doesn't change neither. Could you explain a bit more how and under which circumstances this wizard can be used?
- no drag&drop sorting of fields with Fraggy BE theme / Flat BE theme
- personally, the "Eingaben gespeichert" Ajax message annoys me extremely, it appears too long (the duration is independent from the value wich is set at "Grundeinstellungen")
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
So here are some test results.
Frontend:
- form is not displayed in frontend:Parse error: syntax error, unexpected 'return' (T_RETURN), expecting '{' in /.../modules/mpform/private.php on line 63
WBCE 1.1.6, PHP 5.6 (indeed, there's a curly bracket missing in line 52)
After fixing this everything works fine.
oh, thanks, fixed in my sources, it will be in 1.2.1 when I'll update the github repo
(Just some grumbling: Its a disadvantage that the module still generates 1995-style table code per default.
You know, back in the late '90s, tables were the only reliable thing to position content on a html page... (just kidding)
But seriously, div-based layout is possible with mpform. Yes, it's still not the default, and I take the message on my todo list for one of the next releases. For the frontend I think it's not a big deal. For the backend however, it's probably not that easy.
Also the huge CSS file makes it hard to customize the frontend view. Compare this with miniform: that module is responsive by default, looks good in nearly any page design without bigger customizing and can also display more than one field per row.)
hmm, it might also be the right time to optimize the style file, when I address your first point
Backend:
- I don't understand how to use the conditional field. There are no switches or input fields at all and the frontend output doesn't change neither. Could you explain a bit more how and under which circumstances this wizard can be used?
Oh, I should have elaborated that in more detail.
First you have to add checkboxes, radio buttons or a dropdown list and add the options to that field.
You can have several of these, e.g. radio buttons for buying "1 license", "5 licenses bundle", "site license" and a checkbox to select "commercial use"
Maybe you have more fields like shipment address, billing address etc.
Then, to show the customer once more what he has selected right above the submit button, you can add such a conditionally displayed block. The backend lets you select on which of the supported fields it shall depend. The dropdown list shows only supported fields. Once selected you can press save and the field type turns into a html code field, already filled in with javascript code with the options of the field you have selected.
- no drag&drop sorting of fields with Fraggy BE theme / Flat BE theme
- personally, the "Eingaben gespeichert" Ajax message annoys me extremely, it appears too long (the duration is independent from the value wich is set at "Grundeinstellungen")
Ok, thanks, I have to look into these. I put the items on my list.
Offline
I have pushed first final version to github now (it's the repository linked in the addons section):
https://github.com/WebsiteBaker-modules … /tag/1.2.1
The missing curly brace is fixed there. Thanks to florian for reporting (as you can see, I have put your other points on my todo list for the next releases). In general thanks to all who have tested, and sorry again for the trouble with the first 1.2.0 package which I have posted here.
Cheers,
Martin
Offline
Updated the AOR entry.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
an updated version is available from the github repo
[...]
- no drag&drop sorting of fields with Fraggy BE theme / Flat BE theme
- personally, the "Eingaben gespeichert" Ajax message annoys me extremely, it appears too long (the duration is independent from the value wich is set at "Grundeinstellungen")
these two issues should be solved now, cleanup of the style file and switching to div-layout by default are still on the agenda
Offline
Offline
I have prepared a new version of mpForm:
Release Notes for mpForm 1.3.x
General Changes
---------------
By default switched to a div-based layout. All pages created with earlier versions
of course keep their layout as it is (by default it was a table based layout in the past)
The style file has been cleaned up and a few new definitions have been added
for the help popup dialog in div-based layout. Remember to copy the default style
files manually (or merge the changes into your local modifications) in order to
pick up the improved style settings.
New Features
------------
In multi page forms the access to following pages is denied to all following pages
unless the previous page has been submitted successfully
Feature Improvements
--------------------
In multi page forms submissions are handed over between the individual pages so that
the last page can send confirmation mails about all the submissions of the current page
and now also all previous pages. The data is stored in the session indexed by the
submission id and could in principle be used in the private functions as well.
The {HELP} placeholder works not only in table based layouts, but in general now.
French and Italian language support did not cover the error messages in the pear
file uploader tool. These missing language files have been added now.
Security Enhancements
---------------------
IDKEYs were not used throughout the module. In fact they were only used when
Javascript and therefore Ajax was disabled. Now the Ajax-Helpers also use IDKEYs.
Also the Noscript-fallbacks for moving fields up and down use IDKEYs now.
Documentation
-------------
The feature changes described here are also reflected in the documentation.
The standard forms have also been updated and are based on div-layout now.
Bug fixes
---------
In the 1.2.x releases the icons for import/export for these buttons have been missing.
Now they are included in the module package.
The ajax drag&drop helper did use a wrong url for a icon in one of the message boxes.
It has been corrected now.
A few other minor fixes in Ajax-Helpers, and their Noscript-fallbacks.
The updated package is attached to this post, and it is also available
on github
Offline
I have just pushed an updated version to the github-repository
from the changelog (only changes between 1.3.0 and this release):
add export for results table
introduce constants.user.php and move the defaults for the field loop there
let delete_submission.php also delete entries from the results table
for this, also introduce submission_id in new results tables
fix javascript bug in view_submission.php
update documentation, especially the faq page
For a more prosa-like version see the description at the above-link. It is however a combined description of all changes in the 1.3.x branch with respect to prior versions.
Offline
I've found some minor errors in the DE.php. Due to a mixup of " and ' error messages were displayed with an unwanted dot in the middle.
So the DE.php has to be corrected as follows
// Text outputs for the frontend
$LANG['frontend'] = array(
'MAX_FILESIZE' => 'Maximale Dateigröße: '
. '%d Kilobyte<br />Erlaubte Dateitypen: %s',
'integer_error' => 'Ganze Zahlen dürfen nur '
. 'aus Ziffern bestehen',
'decimal_error' => 'Bitte geben Sie eine gültige '
. 'Dezimalzahl ein',
'err_too_large' => 'Dateigröße ist %d Byte, '
. 'erlaubt sind nur %d Byte!',
'err_too_large2' => 'Datei ist zu groß, '
. 'erlaubt sind nur %d Byte!',
'err_partial_upload' => 'Nur ein Teil der Datei wurde hochgeladen!',
'err_no_upload' => 'Die Datei wurde nicht hochgeladen!',
'err_upload' => 'Fehler beim Hochladen der Datei: %s (%s), bitte versuchen Sie es nochmals!',
'select' => "Bitte auswählen...",
'select_recip' => "Sie müssen einen Empfänger für das Formular auswählen",
'REQUIRED_FIELDS' => "Bitte die rot markierten Angaben ergänzen bzw. korrigieren!",
'INCORRECT_CAPTCHA' => "Die eingegebene Prüfziffer ist nicht korrekt.",
'VERIFICATION' => "Prüfcode (SPAM-Schutz)"
A feature request:
For styling, I throw all the code in the frontend.css away - sorry, it's still bloated and for me it's easier to create all needed styles from the scratch.
Since the site where I probably will make use of the form has no grid system, I implemented gridism, so the field loop looks as follows
<div class="grid no-gutters">
<div class="unit one-third {CLASSES}">{TITLE}{REQUIRED}:</div>
<div class="unit two-thirds">{FIELD}{ERRORTEXT}</div>
</div>
Nevertheless, imho the mpform output unfortunately still looks less elegant than the miniform output, due to the lack of possibility to use different field sizes or place multiple fields in a row. So in a future version it wolud be great if extra fields for styling attributes where added to the field definition sets.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
thanks for the bug report about the language file. I'll come up with an updated version.
About your feature request: Do I understand you correctly that when you edit a field, apart from the field type, field length, default value, you would like to have a text box for inserting style attributes for this particular field, which then would be inserted in the field loop instead of a place holder, e.g. {STYLEATTRIBUTES} ?
Would that fit your needs?
Offline
Correct. I think this could be helpful.
Sth. like {HTML_BEFORE} and {HTML_AFTER} too (just a single line of text).
But it's just a vague idea, on the other hand the module should not become too complicated either...
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
maybe {HTML_BEFORE} and {HTML_AFTER} is already covered by an extra field of type "HTML" - The field loop would probably look a bit different, then.
On the other hand I can imagine that it would become quite a large effort to adjust such fine-tuning of the html output around each single field, and as you already mentioned, it should not become too complicated.
Maybe we need a different concept then. Maybe a template, similar to the field loop, but on the level of each field, where you can override the field loop, and if that template it is empty, the globally defined field-loop is used....
Offline
A future approach could be indeed a switch to a template based layout like it is in download_gallery 3, although I must confess that's not so easy to build a template that way.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Found a bug: Deleting a field ends up in an JS error "Post arguments missing".
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Hi, ich habe zwei Bugs entdeckt:
1. Beim Upgrade von 1.2.x auf 1.3.x werden die Allgemeinen Einstellungen fehlerhaft übertragen.
2. mpForm hat Probleme beim versenden von längeren Texten die auf mehrere Absätze aufgeteilt sind. Der Absender bekommt die Bestätigungsmail aber der Siitenbetreiber bekommt die Mail nicht.
Offline
I have released version 1.3.2 on github.
here the changelog:
fix language files (thanks to florian for reporting)
merge Bugfix for deleting fields in backend (Dietrich Roland Pehlke: 14-Nov-2016)
added maxlength option for textareas (thanks to alexx for suggesting)
add place holder {EMAIL} within mail templates (thanks to John for suggesting)
introduce field templates to locally override the field loop if desired
support mod_opf_Email as a replacement of the classical email output filter
updated documentation in a few places and the hints in the backend
highlight missing required radio/checkbox fields (thanks to alexx for reporting)
keep uploaded files when returning to paintform (thanks to alexx for suggesting)
correctly enclose body in tags in html mails (thanks to astrid for reporting)
add more css classes for more styling flexibility (gottfried, florian)
insert newlines in xml export for better readability (request by gottfried)
insert field number in backend overview (thanks to gottfried for suggesting)
as you can see, I have implemented a lot of small feature requests and a couple of bugfixes. Anyhow, I still have a few things on the agenda.
Offline
Hi, ich habe zwei Bugs entdeckt:
1. Beim Upgrade von 1.2.x auf 1.3.x werden die Allgemeinen Einstellungen fehlerhaft übertragen.
In wiefern? was geht verloren?
2. mpForm hat Probleme beim versenden von längeren Texten die auf mehrere Absätze aufgeteilt sind. Der Absender bekommt die Bestätigungsmail aber der Siitenbetreiber bekommt die Mail nicht.
welche Felder sind im Formular, und kommen denn kürzere Texte an?
Offline
Correct. I think this could be helpful.
Sth. like {HTML_BEFORE} and {HTML_AFTER} too (just a single line of text).
But it's just a vague idea, on the other hand the module should not become too complicated either...
Hi Florian,
in version 1.3.2 you can insert {TEMPLATE} in the field loop. This makes an additional text field appear in the settings of each field. There you can insert html code which will be inserted for the place holder. You also can use all the place holders of the field loop in this template, and surround it with individual code for each field. Would that fit your requirements?
Martin
Offline
Found a bug: Deleting a field ends up in an JS error "Post arguments missing".
this should be fixed in 1.3.2 now
Offline
updated AOR, will have a look at it later
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Hi, ich habe zwei Bugs entdeckt:
1. Beim Upgrade von 1.2.x auf 1.3.x werden die Allgemeinen Einstellungen fehlerhaft übertragen.
Ich habe mal im Changelog geschaut was hier das Problem sein könnte: Mit 1.3.0 kam die Umstellung auf div basiertes Layout als Default aber das sollte nur neu angelegte Sections betreffen. Bereits existierende müssten ihre Settings behalten.
Offline