formtools / core Goto Github PK

Doesn't appear to work!!! Several cases mentioned in forums where the other themes fail to properly fallback to the default template.

Check out!

It may not be all Windows' servers - that was a leap on my part - but check the following thread:
http://forums.formtools.org/showthread.php?tid=294

Also, renamed "View Group" to "View Field Group" (!)

This is a pain. I've been thinking about this for a while - all I DO know is that the ellipses JS script sucks & that it should be handled server-side.
http://forums.formtools.org/showthread.php?tid=428

N.B. this also ties into another issue with the overflow being set for the main page div. Tricky tricky tricky.

See thread:
http://forums.formtools.org/showthread.php?tid=852

An old bug. Should either increase the default field size for file types or truncate the names to eliminate bad references.

See the Edit Field dialog. Probably a DB data problem.

When I have undated FormTool to the latest release 2.2.7 I started seeing strange things.
For example some of the values available in the "Data" are not showing in the view "Forms" (see attachment). Can you please check this out and let me know.

Fringe case, but should be fixed. If JS is disabled, the Code/Markup field shows a plain textbox. However, newlines are converted to \n then \n, then \n etc. with each update.

Need to add a comment explaining what's going on.

Another non-bug bug report. But it's needed for the Form Builder, so slip this into Core 2.1.9.

The whole themes setup should probably be re-examined.

1. First, we could get a whole lot more mileage out of each theme by allowing them to have their own settings (colours, etc).
2. The main icons for each section - and other images - should all inherit from /default. Not require adding to each and every theme any minor thing is added (like the new Themes icon!)

• Ben

Certain special characters such as £, á,é,í,ó and ú cause the remainder of the message to be cut off as they cannot be parsed for some reason. This of course causes issues where customers may be querying a price, or for foreign customers posting a question via our forms and saying something with the word "arrivé" for example, as seen earlier today. I will be looking into this in further detail myself however for your own benefit I notice in the process.php headers (found through developer tools in google chrome -> network) the "Message" field in form data is "(unable to decode value)". This applies to all browsers however as in follow-up discussions with customers who've hit this snag I've found that they can be using any browser (firefox, chrome, i.e and safari as the main ones).

Steps to reproduce:

post for example the following:

aaaá
oooó
eeeé

and you won't get past "aaa" from what I've seen.

This has been noticed a lot in the forums, but I didn't put 2 and 2 together until someone sent a screenshot.

Should be fixed in next release.

• Ben

This problem is outlined best in this thread:
http://forums.formtools.org/showthread.php?tid=538

N.B. I've encountered something similar on Vancouver Fringe; check out.

The problem is that MySQL database tables have a limit of 64 characters. By limiting it to 15 chars (which should be more than sufficient for most users), it will let us know precisely how long table names can be.

This came up recently with a Form Builder table name. The length custom prefix was 65 chars, which prevented the module from installing properly.

Includes an email_id=Please Select in query string.

After clicking "INSTALL" for a module, clicking refresh in your browser will insert any hooks twice in the DB

When the "Only submissions that fit into the following View(s)" radio is selected, there should be some validation to force the user to select at least one View. This has tripped me up twice now - nothing was selected, preventing the email from being sent & there's no apparent reason why.

.tar.gz files for modules (verified with modules: Arbitrary Settings 1.0.0, Hooks Manager 1.1.3, Extended Client Fields 1.2.6) contain files with absolute path in the form of /home/ftroot/_files/modules/$MODULE_NAME/$MODULE_VERSION/. Those should have the paths constructed like in the .zip downloads instead, i.e. only have relative root folder $MODULE_NAME without version subdirectory in order to match the instructions in http://docs.formtools.org/userdoc2_1/?page=installing_modules and of course common sense.

On "Edit Forms" > "Fields" tab, a critical bug makes editing the form fields impossible.

1. unintended code appears in the window (see below for code snippet)
2. the frame is repeated, appearing as a frame within a frame (screenshot provided)
   Code:
   if the field fails the validation"; g.messages["phrase_no_option_lists_available"] = "No options lists available."; g.messages["phrase_available_option_lists"] = "Available Option Lists"; g.messages["phrase_form_field_contents"] = "Form Field Contents"; g.messages["word_validation"] = "Validation"; //]]>
   see window within a window

Steps to reproduce

1. https directory and connection
2. this is a fresh new internal form
3. i can provide a login for troubleshooters

Reported by Ying/Ian. This is for things when both a module and the Core (or two modules, maybe?) have the same setting name & the wrong one is returned.

Looks like a problem with the Date field type. Not checking for isset?

Notice: Undefined index: timezone_offset in /Applications/MAMP/htdocs/formtools2/global/code/submissions.php(1159) : eval()'d code on line 48

Possible solution here:
http://stackoverflow.com/questions/5387578/jquery-dialog-shrinks-when-i-open-second-time

See thread:
http://forums.formtools.org/showthread.php?tid=745

This is a placeholder for updating the Form Tools Core to support PHP7. Will update with details once I get to this task.

• Move to PDO.

Minor, but odd. Should be made consistent: should be blank by default.

See thread: http://forums.formtools.org/showthread.php?tid=435

Also, ft_finalize_form should handle db errors as described in that thread: "Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs".

This isn't the first time this has cropped up.

A couple of updates needed to the Email templates section.

1. Add drag drop sorting. When you have a lot of email templates, this can be handy.
2. Add << prev and next >> links within email templates, to make it consistent with other areas.

The reason being: it's the opposite on the test tab, which is downright weird.

This is a catch-all post to keep track of reported orphans.

ft_field_settings:
http://forums.formtools.org/showthread.php?tid=1813

ft_email_template_recipients, email_templates:
http://forums.formtools.org/showthread.php?tid=1806

I have a site that shows formtools via iFrame (API wasn't an option on this project) and it allows people to log into their accounts via the Submission Accounts module. When they log in, because it's an iFrame showing formtools on an external site the sessions can't be created due to security settings.

• How to fix -
  Add the following as the first php code in global/session_start.php:
  header('P3P: CP="CAO PSA OUR"');
• May need Internet Explorer, because my other browsers already had session data established (I didn't test them separately)
• Put an iFrame on a page that points to the formtools login on an external site
• Try logging in

Not much information on this one. I noticed that a validation rule ("required") for a newly created File Upload field was added to the database, but it was mapped to a WYSIWYG validation rule ID. Thus, it didn't show up in the Edit Field Dialog, but was added to the generated validation JS code, causing an error.

...

Not sure about what caused this.

Haven't found a way to consistently reproduce this, but there's clearly something wonky going on.

Occasionally fields lose their Option Lists. If it's happening to that one setting, chances are it's occurring elsewhere. Check out for 2.1.6.

As described.

See attached screenshot.

The message contains some JS that's specific to the Edit Submission page, I think. Either way, updating the reference isn't necessary since the records are being deleted.

Again, minor. But it's noticed when upgrading to 2.1.0 that the styles look a little wacky.

Suggested by Filip. This is a good idea.

The dates aren't always properly shown on the Form Builder when submitting a form containing a date, when the localization of the form is non-English.

Details:

code/general.php's ft_get_date() method runs two different pieces of code depending on the selected localization:

// if this is an English language (British, US English, English Canadian, etc), just
// use the standard date() functionality (this is faster)
$date_str = "";
if ($LANG["special_language"] == "English")
  $date_str = date($format, $timestamp);
else
{
...

The problem lies when the user is using a non-English lang file (problem seen with the latest Italian lang files), with these lines:

switch($char_ind)
{
  case "F":
    $translated_str = $LANG["date_month_short_$eng_string"];
    break;

  case "M":
    $translated_str = $LANG["date_month_$eng_string"];
    break;

  default:
    $translated_str = $LANG["date_$eng_string"];
    break;
}

Even though error_reporting() is defaulted to 1 on the system I was seeing, notices were still thrown when a form builder form was submitted, and presumably a field contained a date field with the formatting chars defined.

Because the lang file didn't contain these params, the notices appeared, preventing the form builder form from submitting.

See the Edit Menu page.

Minor issue, but an annoying one.

Just use same technique as with the Form Builder code.

If there is a Smarty syntax error in your email template, and you try to test the email--either sending it or displaying it--you will get a Javascript alert box with "Couldn't load page:" and then the URL of the request.

There should be a more helpful error message, since Smarty syntax errors are common and easily fixed. Regular email functions using the template won't work, either, and there is no warning that this is the case.

Steps to reproduce:

Create an email template with a Smarty syntax error. Test it using the admin email test tab.

As per forum thread: http://forums.formtools.org/showthread.php?tid=2999

and as requested by Joe

I had code in the hooks manager for 'ft_update_submission, start' and 'end'. When ft_update_submission was called by edit_submission.php thus
[code]list($g_success, $g_message) = ft_update_submission($form_id, $submission_id, $request);[/code]
the variables $g_success and $g_message were being returned as NULLs. This then resulted in the $failed_validation being true. This was irrespective of the failure or success of my code.

Now although my code was actually working, there are two override variables in the hook manager... $success and $message which I was not manipulating. They were defaulting to NULL.

When the admin/client updating a submissions and the contents change to make it no longer appear in the currently selected View, it should redirect to the main submission listing page where a message is displayed explaining why they were redirected.

I realize this may be annoying for some people, but CLARITY is more important. It's not clear why the << prev next>> line disappears sometimes & it appears to be a bug. In fact, the system is correctly realizing that the submission no longer belongs in the chosen View and doesn't consider it part of the submission group.

I think redirecting with the message is the clearest solution.

{views_dropdown} shows ugly " instead of double quotes if View contains that char

The installation script should run tests on the MySQL user to confirm it has all the permissions needed.

Fringe case, but worthwhile.

Just a usability issue: for larger forms you can spend several minutes confirming each field type, but when going to earlier steps in the form then returning to step 5, all your manually entered info is lost.

This is not intuitive at all. See thread:
http://forums.formtools.org/showthread.php?tid=1743&;pid=6705#pid6705

I found that overriding the default settings with a custom path (identical to default settings) works fine. Using the defaults doesn't, resulting in a generic error message.

Windows-specific.

This was noticed on NV. Could be a DB issue, but check out anyway.