Updated: Comment #69

Problem/Motivation

We nearly allow to configure each part of the HTML element types outputted by views, though it's not possible to configure
the HTML element for grouped views, which is H3 by default and hard-coded into the template.

Proposed resolution

Allow to configure the h3 element for view style plugins.

Remaining tasks

Patch needs review.

User interface changes

H3 element for the view style elements can be configured.

API changes

None.

Original report by dawehner

Files: 
CommentFileSizeAuthor
#86 interdiff-1880100-85-86.txt1.14 KBdman
#86 1880100-86.patch14.8 KBdman
#85 1880100-85.patch13.64 KBdman
#81 1880100-81.patch14.08 KBlokapujya
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 70,561 pass(es). View

Comments

dawehner’s picture

Status: Active » Needs review
FileSize
11.87 KB
FAILED: [[SimpleTest]]: [MySQL] 50,472 pass(es), 1 fail(s), and 0 exception(s). View

First version without some tests.

Status: Needs review » Needs work

The last submitted patch, drupal-1880100-1.patch, failed testing.

dawehner’s picture

Status: Needs work » Needs review
FileSize
5.4 KB
PASSED: [[SimpleTest]]: [MySQL] 50,587 pass(es). View

Removed the unrelated part of the patch (it was another cache related issue).

tim.plunkett’s picture

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/field/FieldPluginBase.phpundefined
@@ -267,7 +267,7 @@ function element_wrapper_type($none_supported = FALSE, $default_empty = FALSE) {
+  static function get_elements() {

Might as well make it public

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/style/StylePluginBase.phpundefined
@@ -285,6 +287,20 @@ public function buildOptionsForm(&$form, &$form_state) {
+        '#options' => FieldPluginBase::get_elements(),

Hmm, this means no overridden version of this will be used

Also, if you're changing every instance of the method at once, maybe it'd be good to just rename to getElements() now

dawehner’s picture

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/style/StylePluginBase.phpundefined
@@ -285,6 +287,20 @@ public function buildOptionsForm(&$form, &$form_state) {
+        '#options' => FieldPluginBase::get_elements(),
Hmm, this means no overridden version of this will be used

In theory we could also move this method to another place like the style plugin?

dawehner’s picture

FileSize
6.02 KB
PASSED: [[SimpleTest]]: [MySQL] 49,693 pass(es). View

Thank you for your feedback.

It seems to be okay to just be override-able by individual fields, because at least on the style plugin level, I don't see a reason why they want to have more then the normal ones.

Status: Needs review » Needs work
Issue tags: -VDC

The last submitted patch, drupal-1880100-6.patch, failed testing.

dawehner’s picture

Status: Needs work » Needs review

#6: drupal-1880100-6.patch queued for re-testing.

dawehner’s picture

Issue tags: +VDC

#6: drupal-1880100-6.patch queued for re-testing.

damiankloip’s picture

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

I think when this has test coverage this is good to go.

Do we have a follow up issue to add more (html5) tags? This could be a good novice issue, as it's just added some more tags the to array in the config file.

damiankloip’s picture

Assigned: Unassigned » damiankloip

Working on fixes and tests for this.

dawehner’s picture

Please wait if you haven't started yet, because I just saw that there is a local branch here called 1880100-tests.

damiankloip’s picture

Status: Needs work » Needs review
FileSize
3.66 KB
9.68 KB
PASSED: [[SimpleTest]]: [MySQL] 50,595 pass(es). View

oops, I think we need to actually print the new variable in the templates? :)

Added some tests too.

This is what I have, so if you have tests too, we can compare.

dawehner’s picture

+++ b/core/modules/views/templates/views-view-table.tpl.phpundefined
@@ -17,11 +17,10 @@
+    <<?php print $title_element_type; ?>><?php print $title; ?></<?php print $title_element_type; ?>>
   <?php endif; ?>

I'm not sure about this one, as caption is somehow special for a11

damiankloip’s picture

Assigned: damiankloip » Unassigned

Ahh, ok. So what shall we do? Not allow this feature on tables?

dawehner’s picture

Adding a tag, maybe someone will see it.

mgifford’s picture

I need to know where to find it first. It does sound like a good idea in theory, but not sure where to find the configs. Should I be able to find them here - admin/structure/views/view/frontpage/edit?

damiankloip’s picture

Title: Allow to configure the h3 element » Allow to configure the h3 element for view style plugins

So this will be on the style settings e.g. table when you add a grouping field to group the results by. You will then see another select field that lets you choose your tag. Hopefully this helps :)

mgifford’s picture

Ok, so there has to be a better way to describe this, but maybe...

Go to:
Format -> Settings -> Grouping field Nr.1

Then select:
Content Title

And you will have a select box pop up with a list of elements to give you a choice of elements:
Title HTML Element

I think it might be useful to indicate here that if you're allowing folks to choose different headings and no headings at all - Choose the HTML element to wrap around the grouping title of a view. - it might be useful to encourage folks to learn how to use headings properly.

I did a quick test in VoiceOver with Safari and it seems to work correctly.

It would be better if you also added the HTML5 hidden attribute as per:
http://www.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidd...

So rather than simply providing the style information via CSS:
<div class="form-item form-type-checkbox form-item-style-options-grouping-0-rendered" style="display: none;">

It would look a bit more like:
<div class="form-item form-type-checkbox form-item-style-options-grouping-0-rendered" style="display: none;" hidden>

That needs to switch along with the style information so that the semantic information is being passed along to AT.

dawehner’s picture

Thanks for helping.

What you describe is the behavior in the admin UI using the states API, so it might make sense to open an issue for that.

What actually wanted to know the following code

+++ b/core/modules/views/templates/views-view-table.tpl.phpundefined
@@ -17,11 +17,10 @@
-    <caption><?php print $title; ?></caption>
+    <<?php print $title_element_type; ?>><?php print $title; ?></<?php print $title_element_type; ?>>

As you can see, this removes caption and replaces it with a configurable event. Do you think this is correct at the end?
Is the caption tag, the only proper way to label a table?

mgifford’s picture

I'm not a Views guy. It's great, but my team works with it much more than I do. I was just trying to get where you were describing.

I can open a new issue and link back here for reference.

I could do that. Captions are optional. But why would you? Captions have meaning while headings have a different meaning. Surely the goal should be to properly style captions in CSS?

A caption is the only way to establish semantic relationships between a heading and a table. I think I'd like to see a good argument to allow folks to change it over. On the other hand, if the defaults are set properly it's probably not going to be a common occurrence.

dawehner’s picture

FileSize
671 bytes
10.33 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal-1880100-22.patch. Unable to apply patch. See the log in the details link for more information. View

I could do that. Captions are optional. But why would you? Captions have meaning while headings have a different meaning. Surely the goal should be to properly style captions in CSS?

Yeah you simply want to be able to configure that html element.

Status: Needs review » Needs work
Issue tags: -Needs tests, -needs accessibility review, -VDC

The last submitted patch, drupal-1880100-22.patch, failed testing.

dawehner’s picture

Status: Needs work » Needs review

#22: drupal-1880100-22.patch queued for re-testing.

dawehner’s picture

#22: drupal-1880100-22.patch queued for re-testing.

mgifford’s picture

#22: drupal-1880100-22.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +Needs tests, +needs accessibility review, +VDC

The last submitted patch, drupal-1880100-22.patch, failed testing.

dawehner’s picture

Status: Needs work » Needs review
FileSize
10.43 KB
FAILED: [[SimpleTest]]: [MySQL] 55,354 pass(es), 4 fail(s), and 4 exception(s). View

Just a rerole.

Status: Needs review » Needs work

The last submitted patch, drupal-1880100-28.patch, failed testing.

dawehner’s picture

Status: Needs work » Needs review
FileSize
726 bytes
10.47 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal-1880100-30.patch. Unable to apply patch. See the log in the details link for more information. View

$view->preview() now returns a render array.

tim.plunkett’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs tests, -needs accessibility review

This exposes a new option in the UI to change the H3 to another tag, but the default is unchanged, so I don't think this needs any accessibility review.
It now also has tests.

The code looks great, and works, so RTBC!

dawehner’s picture

Issue tags: -VDC

#30: drupal-1880100-30.patch queued for re-testing.

damiankloip’s picture

#30: drupal-1880100-30.patch queued for re-testing.

Should be fine but just checking.

tim.plunkett’s picture

#30: drupal-1880100-30.patch queued for re-testing.

Status: Reviewed & tested by the community » Needs work
Issue tags: +VDC

The last submitted patch, drupal-1880100-30.patch, failed testing.

dawehner’s picture

Issue tags: +Needs reroll
pwieck’s picture

Assigned: Unassigned » pwieck

Working on reroll

pwieck’s picture

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

Rerolled to current head

Removed from patch

CONFLICT (modify/delete): core/modules/views/templates/views-view-unformatted.tpl.php deleted in HEAD
CONFLICT (modify/delete): core/modules/views/templates/views-view-table.tpl.php deleted in HEAD
CONFLICT (modify/delete): core/modules/views/templates/views-view-list.tpl.php deleted in HEAD
CONFLICT (modify/delete): core/modules/views/templates/views-view-grid.tpl.php deleted in HEAD

public function getElements() (HEAD) changed to public static function getHTMLElementTypes() (PATCH)

CONFLICT (content): Merge conflict in core/modules/views/lib/Drupal/views/Tests/Handler/FieldWebTest.php
CONFLICT (content): Merge conflict in core/modules/views/lib/Drupal/views/Plugin/views/field/FieldPluginBase.php
dawehner’s picture

Status: Needs review » Needs work

We have to adapt all the twig files.

pwieck’s picture

Adding twig file changes to patch as per @dawehner and @Cottser

pwieck’s picture

Assigned: pwieck » Unassigned
Issue tags: -Needs reroll
FileSize
2.86 KB
11.52 KB
FAILED: [[SimpleTest]]: [MySQL] 58,117 pass(es), 4 fail(s), and 0 exception(s). View

Added to patch per @dawehner and @Cottser on IRC:
<{{ title_element_type }}>{{ title }}</{{ title_element_type }}>

Added on my own:

  * - title: The title of this group of rows.
+ * - title_element_type: The HTML tag element for the title.
  * - rows: A list of rows. Each row contains a list of columns.

To:
core/modules/views/templates/views-view-unformatted.html.twig
core/modules/views/templates/views-view-table.html.twig
core/modules/views/templates/views-view-list.html.twig
core/modules/views/templates/views-view-grid.html.twig

pwieck’s picture

Status: Needs work » Needs review

changed status

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Great!

Status: Reviewed & tested by the community » Needs work
pwieck’s picture

Failing in StyleTest.php

dawehner’s picture

+    $style_plugins = array('default', 'grid', 'table', 'html_list');

but you just changed three twig files.

pwieck’s picture

Did manual testing and found tables not working as expected. All other styles working as expected.

The four failures in patch #41 are due to an incorrectly written test. The test in all of these patches only tests against the table style using $style['type'] = 'table'; in the foreach loop

I did a quick and dirty change to $style['type'] = $plugin; and only table fails. The test would also have to handle rows for grid and html_list styles. Test passes these with exceptions.

#46 miscounted - I did all 4 styles.

dawehner’s picture

Status: Needs work » Needs review
Issue tags: +Twig
FileSize
1.41 KB
12.25 KB
FAILED: [[SimpleTest]]: [MySQL] 58,091 pass(es), 0 fail(s), and 5 exception(s). View

I could fix some of the problems, though there is some odd error message coming from tiwg:

row_classes could not be found in _context in "core/modules/views/templates/views-view.html.twig" at line 64
trigger_error('row_classes could not be found in _context in "core/modules/views/templates/views-view.html.twig" at line 64', 512)
Drupal\Core\Template\TwigTemplate->getContextReference(Array, 'row_classes')
__TwigTemplate_46b7aa7fb0bc1e7759b73a8e1d58f4da->doDisplay(Array, Array)
Twig_Template->displayWithErrorHandling(Array, Array)
Twig_Template->display(Array)
Twig_Template->render(Array)
twig_render_template('core/modules/views/templates/views-view-grid.html.twig', Array)
theme(Array, Array)
drupal_render(Array)
drupal_render(Array)
render(Array)
twig_render_var(Object)
__TwigTemplate_b70bdebde08e7e2ecda2f85615f3e079->doDisplay(Array, Array)
Twig_Template->displayWithErrorHandling(Array, Array)
Twig_Template->display(Array)
Twig_Template->render(Array)
twig_render_template('core/modules/views/templates/views-view.html.twig', Array)
theme(Array, Array)
drupal_render(Array)
Drupal\views\Tests\Plugin\StyleTest->testCustomElementTitle()
Drupal\simpletest\TestBase->run()
_simpletest_batch_operation(Array, '19', Array)
call_user_func_array('_simpletest_batch_operation', Array)
_batch_process()
_batch_do()
_batch_page()
system_batch_page()
call_user_func_array('system_batch_page', Array)
Drupal\Core\EventSubscriber\LegacyControllerSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1)
Drupal\Core\HttpKernel->handle(Object, 1, 1)
Symfony\Component\HttpKernel\Kernel->handle(Object)
drupal_handle_request()

Status: Needs review » Needs work
Issue tags: -Twig

The last submitted patch, vdc-1880100-48.patch, failed testing.

pwieck’s picture

During my manual testing of the styles one by one, I did not get these exceptions with the 'default' style. It started with 'grid'. Of coarse 'table' failed and I did not run 'html_list' through test. I was thinking it was a miss-written test.

I will run all four one by one later today.

dawehner’s picture

Issue tags: +Twig

Adding back Twig.

dawehner’s picture

Status: Needs work » Needs review
FileSize
579 bytes
12.62 KB
PASSED: [[SimpleTest]]: [MySQL] 56,349 pass(es). View
damiankloip’s picture

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/field/FieldPluginBase.phpundefined
@@ -270,7 +270,7 @@ public function elementWrapperType($none_supported = FALSE, $default_empty = FAL
+  public static function getHTMLElementTypes() {

Should we use Html instead of HTML? I can't remember the 'proper' rules on camel casing.

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/style/StylePluginBase.phpundefined
@@ -299,6 +301,20 @@ public function buildOptionsForm(&$form, &$form_state) {
+        '#options' => FieldPluginBase::getHTMLElementTypes(),

Do you think we should move this static method somewhere else? not FieldPluginBase. Just a thought, otherwise this patch is looking good.

dawehner’s picture

FileSize
14.2 KB
FAILED: [[SimpleTest]]: [MySQL] 56,941 pass(es), 41 fail(s), and 27 exception(s). View

There we go.

Status: Needs review » Needs work

The last submitted patch, vdc-1880100-54.patch, failed testing.

dawehner’s picture

Status: Needs work » Needs review
FileSize
962 bytes
14.2 KB
FAILED: [[SimpleTest]]: [MySQL] 56,742 pass(es), 1 fail(s), and 0 exception(s). View

Missed one place.

Status: Needs review » Needs work

The last submitted patch, vdc-1880100-56.patch, failed testing.

dawehner’s picture

Status: Needs work » Needs review
FileSize
764 bytes
14.36 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch vdc-1880100-58.patch. Unable to apply patch. See the log in the details link for more information. View

Fixed the last bit.

damiankloip’s picture

Status: Needs review » Reviewed & tested by the community

I think it living of StylePluginBase is better, using FieldPluginBase::stuff around town looks a bit weird. The rest of the changes look good.

tim.plunkett’s picture

Issue tags: -Twig, -VDC

#58: vdc-1880100-58.patch queued for re-testing.

Status: Reviewed & tested by the community » Needs work
Issue tags: +Twig, +VDC

The last submitted patch, vdc-1880100-58.patch, failed testing.

dawehner’s picture

Status: Needs work » Needs review
FileSize
14.04 KB
FAILED: [[SimpleTest]]: [MySQL] 57,161 pass(es), 1 fail(s), and 0 exception(s). View

Status: Needs review » Needs work

The last submitted patch, vdc-1880100-62.patch, failed testing.

dawehner’s picture

Status: Needs work » Needs review
FileSize
1.88 KB
15.12 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch vdc-1880100-64.patch. Unable to apply patch. See the log in the details link for more information. View

There we go.

dawehner’s picture

64: vdc-1880100-64.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 64: vdc-1880100-64.patch, failed testing.

dawehner’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
14.07 KB
PASSED: [[SimpleTest]]: [MySQL] 59,000 pass(es). View

Just a rerole.

olli’s picture

Nice work! I think this is almost a bug =)

  1. +++ b/core/modules/views/lib/Drupal/views/Plugin/views/field/FieldPluginBase.php
    @@ -548,7 +528,7 @@ public function buildOptionsForm(&$form, &$form_state) {
    -      '#options' => $this->getElements(),
    +      '#options' => StylePluginBase::getHtmlElementTypes(),
    

    Why static? Could we call $this->view->style_plugin->getHtmlElementTypes()? Or make $this->getElements() a wrapper around it? Or...

  2. +++ b/core/modules/views/lib/Drupal/views/Plugin/views/style/StylePluginBase.php
    @@ -376,6 +392,27 @@ public function wizardSubmit(&$form, &$form_state, WizardInterface $wizard, &$di
    +   * Provide a list of elements valid for field HTML.
    +   *
    +   * This function can be overridden by fields that want more or fewer
    +   * elements available, though this seems like it would be an incredibly
    +   * rare occurence.
    +   */
    +  public static function getHtmlElementTypes() {
    

    Why not move this method to pluginbase? This docs needs tuning.

PavanL’s picture

Issue summary: View changes
dawehner’s picture

Issue tags: +phpunit
FileSize
17.54 KB
FAILED: [[SimpleTest]]: [MySQL] 59,067 pass(es), 43 fail(s), and 30 exception(s). View
8.28 KB

Thank you for the good review!

Why static? Could we call $this->view->style_plugin->getHtmlElementTypes()? Or make $this->getElements() a wrapper around it? Or...

It used to be on the field, so the style plugin could not easily access it, but know I think it is fine to just have it as method on the style plugin base. Both field and style can acess it there.

Why not move this method to pluginbase? This docs needs tuning.

I have the feeling that moving it to the plugin base just makes this already gigant file even bigger.

Additional I took the change and started with a unit test.

The last submitted patch, 70: vdc-1880100.patch, failed testing.

dawehner’s picture

The problem with this is now basically that creating an instance of a field requires the style plugin to be already instanciated. While this is not a real problem in reality is still couples the system more as well as makes it harder to test things.

Yes caling $this->initStyle in initHandlers() is actually quite easy, though we have to do the same on the display side. Also quite a lot of the tests actually are in a reduced enviroment in which we don't have actual row/style plugins available. Don't we also create some kind of recursion here?

Field -> Style -> Row (for example fields row style) -> Fields

olli’s picture

The method is only called by buildOptionsForm() and we could get those tests green by calling $this->view->getStyle()->getHtmlElementTypes() but this also means that the style plugin defines what which html elements the field plugin may use. I'm not sure we want that.

How about simply leaving FieldPluginBase::getElements() as is (yes, duplicate the code in style plugin base)? This way there is no coupling, only an api addition and it can still be overridden.

dawehner’s picture

How about simply leaving FieldPluginBase::getElements() as is (yes, duplicate the code in style plugin base)? This way there is no coupling, only an api addition and it can still be overridden.

I don't get why we also can't just use a static method.

olli’s picture

So #67 with that comment fix?

olli’s picture

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/field/FieldPluginBase.php
@@ -593,7 +573,7 @@ public function buildOptionsForm(&$form, &$form_state) {
+      '#options' => StylePluginBase::getHtmlElementTypes(FALSE),
...
+++ b/core/modules/views/lib/Drupal/views/Plugin/views/field/FieldPluginBase.php
@@ -637,7 +617,7 @@ public function buildOptionsForm(&$form, &$form_state) {
+      '#options' => StylePluginBase::getHtmlElementTypes(FALSE),

StylePluginBase::getHtmlElementTypes()

dawehner’s picture

FileSize
14.02 KB
PASSED: [[SimpleTest]]: [MySQL] 59,359 pass(es). View

Went back to the static method approach and fied the part of the previous review.

dawehner’s picture

77: vdc-1880100.patch queued for re-testing.

olli’s picture

Status: Needs review » Needs work

Tested manually with a table. Options none and default does not seem to work: those are rendered as "<0>" and "<>" inside the <caption> element.

mgifford’s picture

Issue tags: +Needs reroll
lokapujya’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
14.08 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 70,561 pass(es). View

Just the reroll here.

lokapujya’s picture

Status: Needs review » Needs work

See #79

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.

dman’s picture

FileSize
13.64 KB

I found this was needed on a project today, so am trying to pick this up and give it a shake.

First patch is an attempt at a reroll of #81 from May, all the way up through some significant versions.
Many of the files have been moved around to different places, but that was the least of it.

Issues still exist, but this is a faithful re-roll of #81 - with many lines re-applied manually due to nearby changes.

With the following two significant changes just to make it work:

  1. Re-introduced the function getElements() into /core/modules/views/lib/Drupal/views/Plugin/views/field/FieldPluginBase.php ... which was being removed here, as discussed around StylePluginBase::getHtmlElementTypes() above. The reason being that the FieldPluginBase.php implements FieldHandlerInterface which requires getElements() due to the abstract definition.
    I have not replaced the usages of it in the forms #options lines yet - as this is currently a no-fix reroll for changes. But I think that those lines should also go back to how they were - as it seems that getElements() is the way things have gone.
  2. Added a line to core/modules/views/config/schema/views.data_types.schema.yml to reflect the new config option. This being absent was causing one of the other unit tests to fail now. With the message
    Drupal\Tests\views\Kernel\Plugin\DisplayKernelTest::testDefaultOptions
    Drupal\Core\Config\Schema\SchemaIncompleteException: Schema errors for views.view.test_display_defaults with the following errors: views.view.test_display_defaults:display.default.display_options.style.options.title_element_type missing schema
    

    This test is found in core/modules/views/tests/src/Kernel/Plugin/DisplayKernelTest.php
    After inserting the schema, that test cleared.

I tried making an interdiff (failed), it was messier than the patch itself due (in large part at least) to all the file renaming.
Experimental manual testing has been promising but glitchy, and I'll review the actual issues next. I'm just pushing this up as a place to roll the next issues from.

This is 'needs work' still, but I'd like to bump it up to see if the testbot can assimilate it OK. (I've been getting an unrelated false positive in local tests today - so I'm half expecting to see a fail from Drupal\Tests\views\Kernel\Handler\FieldDateTest::testFieldDate - but let's see.)

dman’s picture

Updated the test (that applies solely to this patch) to use current test methods, removed deprecated calls that meant that test could not even run.
Tests now run, but fail, as the patch functionality isn't working. Starting with failing tests is at least a solid start :-}

The test in question:
php ./core/scripts/run-tests.sh --verbose --class "Drupal\views\Tests\Plugin\StyleTest::testCustomElementTitle"

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.