If you create a "datetime" form element via Form API, you will get doubled pre- and suffix.

$form['datetime'] => [
   '#type'  => 'datetime',
   '#suffix' => 'Suffix',
   '#prefix' => 'Prefix',
];

I don't know if it relates to
https://www.drupal.org/node/2346893
and if it is datetime theme specific. (its theme functions)
This might occur on other fields too.

Comments

seppelM created an issue. See original summary.

hussainweb’s picture

Version: 8.0.1 » 8.0.x-dev

Can you give an example output? What is the HTML that you see?

seppelM’s picture

Prefix<div class="container-inline" id="edit-datetime">
  Prefix<div class="js-form-item form-item js-form-type-date form-type-date js-form-item-datetime-date form-item-datetime-date form-no-label">
      <label class="visually-hidden" for="edit-datetime-date">Datum</label>
        <input type="date" class="form-date hasDatepicker" size="12" value="" name="datetime[date]" id="edit-datetime-date" data-drupal-date-format="Y-m-d" title="Date (e.g. 2015-12-08)" data-drupal-selector="edit-datetime-date">

        </div>
<div class="js-form-item form-item js-form-type-date form-type-date js-form-item-datetime-time form-item-datetime-time form-no-label">
      <label class="visually-hidden" for="edit-datetime-time">Zeit</label>
        <input type="time" class="form-time" size="12" value="" name="datetime[time]" id="edit-datetime-time" step="1" title="Time (e.g. 15:13:14)" data-drupal-selector="edit-datetime-time">

        </div>
Suffix
</div>

Suffix

Thats the output.
Both get added outside and inside the container.

seppelM’s picture

Issue summary: View changes
TR’s picture

Component: render system » markup

Confirmed as a bug. It's even worse if you include a #title because then one of the prefixes is displayed before the title and the other one is displayed after the title.

(I'm pretty sure this has nothing to do with the ajax markup problem cited in the original post.)

There are a number of other issues with the markup here. First is that the #title is displayed as an <h4> instead of as part of the <label> as it is with other form elements. This makes styling of form elements inconsistent. Second, the #title is placed OUTSIDE of the <div class="form-item ..." instead of inside, which means .form-item isn't a good selector for the entire element. Again, this is not consistent with what any of the other form elements does.

Here is a real use case where I added the prefix and suffix to see what would happen:

    $form['shipment']['ship_date'] = array(
      '#type' => 'datetime',
      '#title' => $this->t('Ship date'),
      '#date_date_element' => 'date',
      '#date_time_element' => 'none',
      '#default_value' => DrupalDateTime::createFromTimestamp($ship_date),
      '#prefix' => '<div class="bug">',
      '#suffix' => '</div>',

And here is the markup:

<div class="bug">  <h4 class="label">Ship date</h4>
<div id="edit-ship-date" class="container-inline">
  <div class="bug"><div class="js-form-item form-item js-form-type-date form-type-date js-form-item-ship-date-date form-item-ship-date-date form-no-label">
      <label for="edit-ship-date-date" class="visually-hidden">Date</label>
        <input data-drupal-selector="edit-ship-date-date" title="Date (e.g. 2016-02-02)" type="date" min="1900-01-01" max="2050-12-31" data-drupal-date-format="Y-m-d" id="edit-ship-date-date" name="ship_date[date]" value="2016-02-02" size="12" class="form-date" />

        </div>
</div>
</div>

Using paragraph tags instead of divs it's stranger - note it creates BOTH open and close paragraph tags for the TWO prefixes, then BOTH open and closed tags for the TWO suffixes (but notice the suffix doesn't get the class="bug" ...):

    $form['shipment']['ship_date'] = array(
      '#type' => 'datetime',
      '#title' => $this->t('Ship date'),
      '#date_date_element' => 'date',
      '#date_time_element' => 'none',
      '#default_value' => DrupalDateTime::createFromTimestamp($ship_date),
      '#prefix' => '<p class="bug">',
      '#suffix' => '</p>',
<p class="bug">  </p><h4 class="label">Ship date</h4>
<div id="edit-ship-date" class="container-inline">
  <p class="bug"></p><div class="js-form-item form-item js-form-type-date form-type-date js-form-item-ship-date-date form-item-ship-date-date form-no-label">
      <label for="edit-ship-date-date" class="visually-hidden">Date</label>
        <input data-drupal-selector="edit-ship-date-date" title="Date (e.g. 2016-02-02)" min="1900-01-01" max="2050-12-31" data-drupal-date-format="Y-m-d" id="edit-ship-date-date" name="ship_date[date]" value="2016-02-02" size="12" class="form-date hasDatepicker" type="date">

        </div>
<p></p>
</div>

<p></p>  

EDIT: I had to edit this issue to make it readable again; some HTML tags inside <?php code block in this post disappeared due to #2725111: < within <?php is not escaped for codefilter_prism.

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.

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

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

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

tacituseu’s picture

Component: markup » datetime.module
Status: Active » Closed (duplicate)
Related issues: +#2783617: Datetime FAPI element type duplicates #prefix and #suffix

Even though this issue is earlier, closing in favor of #2783617: Datetime FAPI element type duplicates #prefix and #suffix as it has a patch.

TR’s picture

@tacituseu: I would appreciate it if, before you close an issue, you check to make sure it really is addressed by the newer issue.

My comments from 18 months ago are NOT all addressed by the patch in #2783617: Datetime FAPI element type duplicates #prefix and #suffix. So now I have to re-create the work I did 18 months ago and re-post in that issue, where they're going to tell me that the markup problems are not part of the datetime.module component, they belong in the FAPI queue or the markup component (which is why I did not put this issue into the datetime.module queue, btw ...). Then I'm going to have to open a new issue which is essentially the same as this, but two years newer, in hopes that someone will take a look at this.

That's progress?

tacituseu’s picture

@TR: I suspect the reason it didn't get the attention from the maintainer is because it didn't have proper component assigned, FAPI/markup is just too generic.
They look the same to me, the other one has comments from @mpdonadio, and still is at needs work because not all issues were addressed, feel free to reopen if you feel strongly about it.