Problem

  • Form handlers and API code manually calls trim() on values too many times.
  • It's unclear who is responsible for trimming text values / user input.
  • The lack of custom trim() calls can trigger error messages that are hard to recognize and resolve by a user, in case a submitted form value contains leading or trailing white-space (which is not visible/apparent).

Proposed solution

  1. Introduce a generic #trim property for all form elements that accept #input.
  2. Make #trim default to TRUE for all form element types that accept text as user input.
  3. Process #trim directly in form_handle_input_element(). If the resulting #value is an empty string, trigger the regular processing flow that would be triggered for no user input - including #required validation.
  4. Allow code that does not want this behavior to opt-out by setting #trim to FALSE. (There's no use-case for that in core, but still...)
  5. Remove all manual calls into trim() from API code. Whoever is calling into APIs is expected to provide proper (trimmed) values.

Original summary:

If the user registers and by mistake includes and extra space before or after their email address, the system will reject the email address with an error message that is difficult to understand (as there is nothing obvious wrong with the email address). I have seen this several times when I paste my email address into the email address box and mistakenly include a trailing space. I just tried it on the Drupal.org site and got the error:

"The e-mail address testaccount@test.org is not valid."

My guess is that this problem might affect 2-3% of all users who ever try to set up Drupal accounts and leave them a bit frustrated.

It would be very easy to have the form on the page user/register trim the spaces off of the email address, to solve this problem.

Files: 
CommentFileSizeAuthor
#73 drupal8.form-trim.73.patch28.51 KBsun
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal8.form-trim.73.patch. Unable to apply patch. See the log in the details link for more information. View
#70 drupal8-form-trim-70.patch26.5 KBaaron
FAILED: [[SimpleTest]]: [MySQL] 49,706 pass(es), 4 fail(s), and 0 exception(s). View
#65 drupal8.form-trim.65.patch27.34 KBsun
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal8.form-trim.65.patch. Unable to apply patch. See the log in the details link for more information. View
#59 drupal8.form-trim.59.patch24.2 KBsun
FAILED: [[SimpleTest]]: [MySQL] 48,722 pass(es), 2 fail(s), and 0 exception(s). View
#56 drupal8.form-trim.56.patch26.43 KBsun
FAILED: [[SimpleTest]]: [MySQL] 48,629 pass(es), 7 fail(s), and 0 exception(s). View
#53 drupal-trim-67769-52.patch8.2 KBaaron
FAILED: [[SimpleTest]]: [MySQL] 49,567 pass(es), 41 fail(s), and 3 exception(s). View
#50 drupal-trim-67769-50.patch6.06 KBaaron
FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed. View
#44 drupal-trim.patch11.35 KBJax
Failed: Failed to apply patch. View
#39 textfield_trim.patch10.39 KBFrando
Failed: Failed to apply patch. View
#37 remove-trim.patch15.94 KBtic2000
Failed: Failed to apply patch. View
#33 remove-trim.patch26.57 KBtic2000
Failed: Failed to apply patch. View
#31 textfield_trim.patch2.07 KBFrando
Failed: Failed to apply patch. View
#29 textfield_trim.patch2.09 KBFrando
Failed: Failed to apply patch. View
#26 textfield_trim.patch439 bytesFrando
Failed: Failed to apply patch. View
#16 email-trim-67769-16.patch3.95 KBWorldFallz
Failed: Failed to apply patch. View
#12 add-new-comment.png15.17 KBdropcube
#12 contact-form.png30.62 KBdropcube
#12 create-new-account.png33.57 KBdropcube
#12 install-site-configuration.png41.72 KBdropcube
#12 site-information.png29.05 KBdropcube
#12 user-edit-account.png28.98 KBdropcube
#12 email-trim-67769-12.patch5.38 KBdropcube
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in email-trim-67769-12.patch. View
#6 user.email_.patch453 bytesmarcingy
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in user.email_.patch. View
#1 user.module_57.patch349 bytesJax
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch user.module_57.patch. Unable to apply patch. See the log in the details link for more information. View

Comments

Jax’s picture

Status: Active » Needs review
FileSize
349 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch user.module_57.patch. Unable to apply patch. See the log in the details link for more information. View

I also think that it would be more user-friendly to trim the email address before the validation. This patch trims the email address field before the validation.

beginner’s picture

Version: 4.7.2 » x.y.z
Status: Needs review » Needs work

tested.

1) there is a little problem: the validation works with the trimmed email, but the UNtrimmed email is saved in the DB (have a look at user/$uid/edit: the leading/trailing space is still there.
2) the problem exists in cvs: please give a patch for cvs first and it will be backported.
3) provide a patch from the Drupal root directory. see: http://drupal.org/patch

Jax’s picture

Strange, when you submit the user form the modifications to the $edit in the user_user function are not kept between calls.

  if ($type == 'validate' && $category == 'account') {
    echo "
VALIDATE
"; var_dump($edit['mail']); $res = _user_edit_validate(arg(1), $edit); var_dump($edit['mail']); } if ($type == 'submit' && $category == 'account') { echo "
SUBMIT
"; var_dump($edit['mail']); return _user_edit_submit(arg(1), $edit); }

If I submit this with email address " person@example.com" the first dump shows the same. After the validation (with the trim patch applied) it's "person@example.com" (good) but once you come back in the 'submit' part it's again " person@example.com" (not good).

Shouldn't the modifications in the validate part go to the submit part? Or should the modifications applied in the validate part be applied again in the submit part? The latter seems somewhat strange to me.

Jax’s picture

Ok, one cannot modify the form data in the validate step (http://drupal.org/node/22218#node_hook_order). The doc is for node submits but I guess this is also true for user data submits.

So there is the 'prepare' and 'form' step left to make the change. The user_user function does not get a 'prepare' step, so the only possible place is 'form'. But when you make changes to the $edit array they are not reflected in the subsequent steps! When you make changes in the 'form' step, shouldn't the 'submit' step see those changes?

bdragon’s picture

Version: x.y.z » 6.x-dev
Status: Needs work » Active

Still an issue.

marcingy’s picture

Status: Active » Needs review
FileSize
453 bytes
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in user.email_.patch. View

As we now have form_state we can modify during the validate.

Patch provided to tirm the email address.

Rowanw’s picture

Carriage returns were stripped during the patch, but it works for me. However, should it be used for all email fields in Drupal or is the registration page a special case? I also noticed that the request new password form already ignores any surrounding spaces.

robertgarrigos’s picture

It should be checked, also, the email while installing and in the contact form

alasda’s picture

Status: Needs review » Needs work

Verified issue
installed patch
now receive 404 errors on /user/password and /user/register

alasda’s picture

Verified issue
installed patch
now receive 404 errors on /user/password and /user/register

marcingy’s picture

Status: Needs work » Needs review

Have just applied this patch to the current cvs version of drupal and I can not replicate this issue.

Please roll back the patch and confirm that the issue goes away.

Also please try a fresh install of drupal 6.

This patch doesn't touch the menu system so there is no reason for a 404 to occur.

dropcube’s picture

Title: Confusing Registration Error when User Includes Trailing Space in Email Field » Confusing Validation Error when user provides an email with trailing spaces (or leading) in several forms throughout the system
Component: user.module » other
Assigned: Unassigned » dropcube
FileSize
5.38 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in email-trim-67769-12.patch. View
28.98 KB
29.05 KB
41.72 KB
33.57 KB
30.62 KB
15.17 KB

Yes, I think this is very confusing for final users. the system will reject the email address with an error message that is contradictory and confusing since there is nothing apparently wrong with the email address.

It does not apply only to the user registration form. There are many forms throughout Drupal where an email address is requested.

The patch trim the spaces off of the email address in all the forms that currently requires an email address. The email is modified over the $form_state variable (or a reference) such that the submit handler saves the trimmed version to the database.

Affected files are:
user.module
comment.module
contact.pages.inc
system.module
system.admin.inc
install.php

Take a look to the screen shots for details.

Please test, This is a bug that would be good to fix for the next release of Drupal.

marcingy’s picture

I agree that we need to patch all areas in drupal where the email is an issue. If we don't I think the situation could end up being even more confusing for users.

I suppose the question now is whether or not the the version number for this issue should be set to 7.x-dev. This approach will allow a better discussion to take place about the issue.

Matt V.’s picture

I installed dropcube's patch to Drupal 6 RC2 and I verified the fix on the following pages:

My account
Site information
Configure site
Add user
Contact Form
Comments

Freso’s picture

Version: 6.x-dev » 7.x-dev
Status: Needs review » Needs work

This should go against HEAD first, before being backported.

Also, the patch introduces trailing white-space (which is kind of ironic, I think :)) on line 1495 of user.module.

WorldFallz’s picture

Status: Needs work » Needs review
FileSize
3.95 KB
Failed: Failed to apply patch. View

Rerolled against head.

Dries’s picture

I wonder if trimming should simply be part of the Form API; i.e an get applied to all fields?

WorldFallz’s picture

@Dries -- that's an interesting point. I'm trying to think of a valid use case for not trimming text and I can't think of any. Any one else think of one?

tic2000’s picture

The fact that we can't think of one it doesn't mean there can't be one. But apart that, I think trimming should be done on all fields.

Dries’s picture

If we trim on all fields, I think we might be able to remove quite a few trims. :-)

catch’s picture

Title: Confusing Validation Error when user provides an email with trailing spaces (or leading) in several forms throughout the system » Add trim to all text field submissions
Status: Needs review » Needs work

Works for me too. At least a couple of times I've looked for a node title direct in the database and not found it because of a leading space, or it's messed up a views alpha listing.

Let's try it at least. Changing issue scope.

WorldFallz’s picture

I took at look at form.inc (which is still pretty much a black hole to me), but what about something like (from _form_validate):

<?php
  // Recurse through all children.
  foreach (element_children($elements) as $key) {
    if (is_string($elements[$key]) {
      $elements[$key] = rtrim(ltrim($elements[$key]));
    }
    if (isset($elements[$key]) && $elements[$key]) {
      _form_validate($elements[$key], $form_state);
    }
  }
?>

don't laugh too hard if it's totally off ;-)

tic2000’s picture

@WorldFallz
Why not just a trim()? Anyway, a proper patch file is needed.

WorldFallz’s picture

i didn't use trim, because there could be valid reasons for white space in the middle of a string depending on the input format and i didn't realize trim() only touches the beginning/end, lol.

And I didn't want to waste time on a patch that was completely off-base. If this is the correct way to handle it, i'll roll a proper patch (including removal of any existing trim()'s where necessary).

Frando’s picture

_form_validate and valdiation handlers aren't supposed to change an element's value. The correct place to perform the trim() is in function form_type_textfield_value().

Frando’s picture

FileSize
439 bytes
Failed: Failed to apply patch. View

One-line patch attached.

Frando’s picture

Status: Needs work » Needs review
Damien Tournoud’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

Makes a lot of sense, but let's add a little test for that.

Frando’s picture

Status: Needs work » Needs review
FileSize
2.09 KB
Failed: Failed to apply patch. View

Sure.

Damien Tournoud’s picture

Status: Needs review » Needs work

The doxygens are a little bit off. Also, I would feel more comfortable if we made a request to a real form on the child site instead of using FAPI internal functions for this.

Frando’s picture

Status: Needs work » Needs review
FileSize
2.07 KB
Failed: Failed to apply patch. View

Better spelling and docs. No time right now to write another test that uses the browser. If anyone wants to have a go, great! Otherwise, IMO the test as it stands is enough. We test that submitting forms via the browser works in many many places..

Dries’s picture

Thanks for taking this for a test drive -- I think it might work. One thing we should do is try to figure out if there are some trims() that can be removed from submit handlers now. Candidates:

deimos:drupal-cvs dries$ grep -r form_state . | grep "trim("
./modules/block/block.admin.inc:        'pages' => trim($form_state['values']['pages']),
./modules/block/block.admin.inc:        'pages' => trim($form_state['values']['pages']),
./modules/filter/filter.admin.inc:    $name = trim($form_state['values']['name']);
./modules/filter/filter.admin.inc:  $name = trim($form_state['values']['name']);
./modules/node/content_types.inc:  $type->type = trim($form_state['values']['type']);
./modules/node/content_types.inc:  $type->name = trim($form_state['values']['name']);
./modules/node/content_types.inc:  $old_type = trim($form_state['values']['old_type']);
./modules/node/content_types.inc:  $type->type = trim($form_state['values']['type']);
./modules/node/content_types.inc:  $type->name = trim($form_state['values']['name']);
./modules/node/content_types.inc:  $type->orig_type = trim($form_state['values']['orig_type']);
./modules/node/node.module:    if (trim($form_state['values']['teaser_js'])) {
./modules/node/node.module:      $body = trim($form_state['values']['teaser_js']) . "\r\n<!--break-->\r\n" . trim($form_state['values']['body']);
./modules/node/node.module:    form_set_value($form['basic']['inline']['processed_keys'], trim($keys), $form_state);
./modules/path/path.admin.inc:  $form_state['redirect'] = 'admin/build/path/list/' . trim($form_state['values']['filter']);
./modules/search/search.module:  $form_state['redirect'] = 'search/node/' . trim($form_state['values'][$form_id]);
./modules/search/search.pages.inc:  form_set_value($form['basic']['inline']['processed_keys'], trim($form_state['values']['keys']), $form_state);
./modules/system/system.admin.inc:  $ip = trim($form_state['values']['ip']);
./modules/system/system.admin.inc:  $ip = trim($form_state['values']['ip']);
./modules/update/update.settings.inc:    foreach (explode("\n", trim($form_state['values']['update_notify_emails'])) as $email) {
./modules/user/user.pages.inc:  $name = trim($form_state['values']['name']);
tic2000’s picture

FileSize
26.57 KB
Failed: Failed to apply patch. View

First try to remove all trim(). I don't know if passwords are affected by the trim patch, so I didn't remove those that were in password validations.

Jax’s picture

The Zend_Form components let's you specify filters on form fields:

class ExampleForm extends Zend_Form {
	public function init() {
		$this->addElement('text', 'description', array(
				'label' => 'Description',
				'filters' => array('StringTrim'),
		));
	}
}

So maybe the filter functionality can be added to the form API in stead of trimming all strings by default? This patch doesn't even allow people to not trim a text field...

Zend Framework also lets you apply filters to all the elements on a form which might also be an option for the Drupal form api.

Frando’s picture

It does allow not to trim a textfield by setting a custom #value_callback on the element.

Implementing multiple value filters is still a nice idea. This could maybe be achieved by making #value_callback an array and passing the value through all #value_calback functions. Let's keep that for a seperate issue, though.

Dries’s picture

I agree with Frando in #35 but it is something which can be left for a future patch. We could add a TODO to the code if desirable, but it shouldn't hold up this patch.

It looks like this patch has another patch embedded into it. Somehow that does not bother the test bot so we might be alright here. Given that the test bot is happy, I think it is safe to proceed with this patch.

tic2000’s picture

FileSize
15.94 KB
Failed: Failed to apply patch. View

This one should be better and incorporates Frando's patch too.

Status: Needs review » Needs work

The last submitted patch failed testing.

Frando’s picture

FileSize
10.39 KB
Failed: Failed to apply patch. View

tic2000, the patch you submitted is malformed or broken.

Proper reroll attached. Quickly skimmed the places where trim() was removed now that it's default on textfield and it looked good. Removed the changes to search.module, though (they aren't directly coming from textfield value so we better leave the trim()s in).

Let's see what testbot says.

Frando’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch failed testing.

Frando’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch failed testing.

Jax’s picture

FileSize
11.35 KB
Failed: Failed to apply patch. View

I've rerolled the patch for current head.

Jax’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch failed testing.

Freso’s picture

Version: 7.x-dev » 8.x-dev

Bumping to 8.x (wow, that looks weird :x).

Also, I want to stress tic2000's concern in comment 33, that trimming all fields will affect passwords as well - which might have deliberate whitespace at the beginning or end.

Damien Tournoud’s picture

Category: bug » feature

Only feature requests and tasks can be assigned to D8 for now, because the Drupal 8 tree is not opened yet.

Fortunately, this is a feature request.

sun’s picture

I think this is a fair assumption to make, but unconditionally applying trim() to all input=text field values without providing an opt-out is not a fair thing to do.

In other words: Let's turn this into a #value_trim property for textfields in system_element_info(), which defaults to TRUE.

Use-cases that re-use textfields for other applications can easily opt-out then.

Btw, this functionality is also interesting for #type textarea, though a default of FALSE might be more appropriate for them.

aaron’s picture

Status: Needs work » Needs review
FileSize
6.06 KB
FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed. View

I have taken a stab at this. It needs tests still.

sun’s picture

Component: other » forms system
Category: feature » task
Issue tags: +Configuration system, +Configurables

Thanks for reviving this, @aaron!

This topic came up very recently in a lot of config system conversions, since we're currently trimming values in entity storage controllers, too.

Personally, I think that whenever someone calls into an entity API directly, we should assume that developers know what they are doing. Contrary to that, user input supplied via forms can contain arbitrary leading and trailing white-space, and we only need to cater for that.

I like the new #trim property in #50. However, I'd almost move its processing as a generic facility into form_handle_input_element(), before any value callback is invoked; i.e., something along the lines of this:

if (!empty($element['#trim']) {
  $input = trim($input);
  // If the trimmed input is empty, ensure that #required and
  // other validation handlers are triggered accordingly.
  if ($input === '') {
    $input = NULL;
  }
}

What do you think?

Status: Needs review » Needs work

The last submitted patch, drupal-trim-67769-50.patch, failed testing.

aaron’s picture

Component: forms system » other
Category: task » feature
Status: Needs work » Needs review
FileSize
8.2 KB
FAILED: [[SimpleTest]]: [MySQL] 49,567 pass(es), 41 fail(s), and 3 exception(s). View

ok

aaron’s picture

Component: other » forms system
Assigned: dropcube » aaron
Category: feature » task

Status: Needs review » Needs work

The last submitted patch, drupal-trim-67769-52.patch, failed testing.

sun’s picture

Status: Needs work » Needs review
FileSize
26.43 KB
FAILED: [[SimpleTest]]: [MySQL] 48,629 pass(es), 7 fail(s), and 0 exception(s). View

Sorry, my snippet was misleading/wrong. The following code checks for $input_exists instead of $input, so we need to force that to FALSE.

I've adjusted that, and additionally:

- Changed #type 'textarea' have a default #trim of TRUE.

- Actually added #trim to all text-input element types. I think that simply makes sense as a default for all text input elements in forms and results in consistency. :)

- Grepped for 'trim(' throughout core and replaced all instances that are obsolete.

So let's see what the bot thinks :)

Status: Needs review » Needs work

The last submitted patch, drupal8.form-trim.56.patch, failed testing.

sun’s picture

Status: Needs work » Needs review

Much better :)

AFAICS, there are two types of failures remaining:

1) ShortcutSetsTest + PageTitleFilteringTest are most likely bogus test expectations that simply need to be updated. (I didn't verify that though.)

2) The FormTest on the password_confirm field... I don't know. Perhaps we should simply remove the #trim from #type 'password' for now, and look into that later? That would mean we'd have to revert all related trim() removals from the user register/login form validation handlers. Personally, I'd be more than happy with ignoring that for now (i.e., reverting #trim on #type password). The massive simplifications elsewhere across the code base are worth to have regardless of those password-specifics. :)

sun’s picture

FileSize
24.2 KB
FAILED: [[SimpleTest]]: [MySQL] 48,722 pass(es), 2 fail(s), and 0 exception(s). View

Reverted #trim for #type password.

Hopefully, that leaves us with #58.1) only.

sun’s picture

 function shortcut_set_switch_validate($form, &$form_state) {
   if ($form_state['values']['set'] == 'new') {
-    // Check to prevent creating a shortcut set with an empty title.
-    if (trim($form_state['values']['label']) == '') {
-      form_set_error('new', t('The new set label is required.'));
-    }

And I can only guess that the Shortcut test is looking for this custom error message :)

However, with the new #trim behavior, the default #required message of "!name field is required." will be shown. :)

Thus, the test needs to be adjusted.

--

PageTitleFilteringTest, OTOH, is a security test, so might be doing something very spooky ;) Needs analysis.

@aaron: Can you look into those two tests? :)

aaron’s picture

why not try the following?

function shortcut_set_switch_validate($form, &$form_state) {
   if ($form_state['values']['set'] == 'new') {
    // Check to prevent creating a shortcut set with an empty title.
    if ($form_state['values']['label'] == '') {
      form_set_error('new', t('The new set label is required.'));
    }

Status: Needs review » Needs work

The last submitted patch, drupal8.form-trim.59.patch, failed testing.

sun’s picture

Well, the purpose of this patch is to remove all the custom trim() handling that was previously required. In turn, that means that the behavior of the system is slightly changed. The (current) behavior is covered by tests though, in order to verify our current expectations.

But due to this patch, our expectations are changing. We do not expect a form validation handler to have to worry about trimming submitted form values anymore, because the operation is performed centrally already. Due to the changed expectation, existing form validation handler code that previously threw a custom error message is no longer needed and thus won't throw that custom error message anymore. As a result, the expectation in our current tests has to be changed. :)

As predicted in #58, the only two remaining failures are in ShortcutSetsTest + PageTitleFilteringTest. The first one should really just be a trivial matter of adjusting the form validation error message string that the test apparently seems to look for. The page title test OTOH might try to verify some edge-case expectation; e.g., submitting a node with a title consisting of spaces only (or similar), which we need to look into; it's also perfectly possible that it's equally a trivial expectation change though. :)

aaron’s picture

It appears to be setting the title to

<span>&lt;/title&gt;&lt;script type=&quot;text/javascript&quot;&gt;alert(&quot;Title XSS!&quot;);&lt;/script&gt; &amp; &lt; &gt; &quot; \&#039;</span>

I do not know what it should be doing in regards to our trimming, so I post this for posterity.

sun’s picture

Status: Needs work » Needs review
FileSize
27.34 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal8.form-trim.65.patch. Unable to apply patch. See the log in the details link for more information. View

I looked into both tests and corresponding code and adjusted them accordingly.

With that, I consider this patch ready.

aaron’s picture

It looks good to me now. Although, I wonder why you removed the assertion messages from that test. I would mark this RTBC, but I am unable to, being one of the authors of this patch.

dman’s picture

I wanted to test and green-light this, but sorry, a few failures to apply today. looks like HEAD is moving too fast and this touched a lot of different files.
OTOH, maybe it's just me. re-queuing against todays code..

dman’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests, +Configuration system, +Configurables

The last submitted patch, drupal8.form-trim.65.patch, failed testing.

aaron’s picture

Status: Needs work » Needs review
FileSize
26.5 KB
FAILED: [[SimpleTest]]: [MySQL] 49,706 pass(es), 4 fail(s), and 0 exception(s). View

This patch is a re-roll against HEAD. There were some changes to the node/content-types.inc. I couldn't find any trim statements within menu/menu-admin.inc.

Status: Needs review » Needs work

The last submitted patch, drupal8-form-trim-70.patch, failed testing.

dman’s picture

That test fail looks like it's probably genuine. Code in point looks like

    // Configure the Styles plugin, and ensure the updated settings are saved.
    $edit = array(
      'editor[settings][plugins][stylescombo][styles]' => "h1.title|Title\np.callout|Callout\n\n",
    );
    $this->drupalPost(NULL, $edit, t('Save configuration'));
    $expected_settings['plugins']['stylescombo']['styles'] = "h1.title|Title\np.callout|Callout\n\n";
    $editor = entity_load('editor', 'filtered_html');
    $this->assertTrue($editor instanceof Editor, 'An Editor config entity exists.');
    $this->assertIdentical($expected_settings, $editor->settings, 'The Editor config entity has the correct settings.');

- for some reason they WANTED those trailing newlines to be hanging around. Is that by design to raise a red flag incase something like this DOES unexpectedly trim the user input?

sun’s picture

Status: Needs work » Needs review
FileSize
28.51 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal8.form-trim.73.patch. Unable to apply patch. See the log in the details link for more information. View

That's just whitespace garbage. Doesn't serve any purpose. Can we safely removed.

Done so in attached patch.

Status: Needs review » Needs work
Issue tags: -Needs tests, -Configuration system, -Configurables

The last submitted patch, drupal8.form-trim.73.patch, failed testing.

sun’s picture

Status: Needs work » Needs review

#73: drupal8.form-trim.73.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, drupal8.form-trim.73.patch, failed testing.

aaron’s picture

Status: Needs work » Needs review

#73: drupal8.form-trim.73.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +Needs tests, +Configuration system, +Configurables

The last submitted patch, drupal8.form-trim.73.patch, failed testing.

aaron’s picture

I'm not sure what's up with the bot. I am able to apply the patch just fine, however when I install Drupal with the patch applied, it does not log me in automatically. I am not certain, but I think that the bot is being confused by this, and giving us the wrong error message for some reason.

tim.plunkett’s picture

Removing unrelated tags

mtift’s picture

Let's try again (removing those config tags, which apparently are not removable)

mtift’s picture

Issue summary: View changes

Updated issue summary.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.