Hi there,
This is my first time submit a issue in Drupal, hope i am doing everything right. I am working on Drupal 8 views right now and i figure out views's "Trim this field to a maximum number of characters" does't work correct.

I figured out only title trim not work, i have tried trim on a body fields, it works great. I haven't try other fields yet.

You guys can check on first pictures, when apply trim text to title, title will disappear.

I don't know if this is a bug or my setting problem, so i am trying to use this submit a issue.

Thanks!

Problem/Motivation

In order to convert more tests from WTB to BTB we want to get some estimation of what kind of failures might exist as part of the conversation

Proposed resolution

This issue should provide a gigantic patch which does the following and JUST the following:

• Using this tool: https://www.drupal.org/files/issues/browsertest-convert.php_.txt move every WTB class to the right BTB directory
• Change the use statements
• ¡STOP!

Remaining tasks

• Do it, maybe in a sandbox branch?
• Come up with patterns we see

User interface changes

API changes

Data model changes

Problem/Motivation

• Realname module alters the display name, but at user/1234 the username is shown. This is incorrect.
• Tons of places in core that show the username, but need to show the users display name.
• Comments do not show DisplayName for registered users.
• Security problem as usernames should never shown on websites. With real names you cannot login and try passwords, with a username you can.

Proposed resolution

• Fix all places where getUsername or getAccountName is used, but getDisplayName should be used.
• Change core to enable a DisplayName by default. That is why tons of tests are failing because of wrong usage.

Remaining tasks

Fix broken core.

User interface changes

Users DisplayName will be properly shown.

API changes

API addition: Entity::getDisplayNameTruncated to get the correct abrivation used in theme_preprocess_username() function.

Data model changes

none

Problem/Motivation

I've created a test view and have found in certain circumstances (that I'm yet to figure out exactly what), the links to edit components of the view (Page settings, Format, Fields etc.) do not respond. The spinner appears and then disappears and no modal window is displayed.

I have checked the javascript console in Chrome to check if a javascript error is occurring but nothing is showing. I have been able to reproduce this using both a simplytest.me instance and firing up a drush qd dev site.

Attached is the view I generated that caused this problem although I couldn't say if this particular view configuration triggers the error.

I am a happier person since moving most of my sites to D8 also because it has a core-based in-place editor. Using it saves time and in general super comfortable.

Now, what's less comfortable is accessing it; You need to be on top of the page, click on the pencil button, and then click on quick edit. It can be quite annoying when being done tens if not hundreds of times a day.

You might want to offer a faster way to access it dealing with manipulating the Drupal core (maybe a way to add another button just for that, which can be later styled with CSS).

Description

Because of the multi line approach too few views are visible at any one time in the table forcing a lot of scrolling.

Currently looks like this:

Proposed solution

Make the displays and machine name ordinary table columns as they are elsewhere.
Removes path and makes the name of the view link to the view (at the path)

UI changes

Before

After

I am trying to add ajax callbacks to the taxonomy edit form by using the hook

MY_MODULE_form_taxonomy_form_term_alter.

I am trying to add an ajax callback to one of the form elements in my taxonomy for a select field as shown in the code below.

The problem is when I click on the first select field, nothing happens and no ajax call is made to Drupal.

function MY_MODULE_form_taxonomy_form_term_alter(&$form, &$form_state, $form_id) {
    $form['#after_build'][] = '_MY_MODULE_form_taxonomy_form_term_after_build';
}


function _MY_MODULE_form_taxonomy_form_term_after_build($form, &$form_state) {
// this is a select field which I am trying to extend it with ajax
$form['MY_FIELD_1']['#ajax'] = array('callback' => 'ajax_update_field_2_callback','wrapper' => 'my-field-2-dropdown-second-replace','event' => 'change',
    );

    return $form;
}

    // adding prefix and suffix to my second form element that exists in the $form already
    $form['MY_FIELD_2']['#prefix'] = '
';
    $form['MY_FIELD_2']['#suffix'] = '
';
}

function ajax_update_field_2_callback($form, $form_state){

    // Do some work here.

    return $form;
}

Problem/Motivation

In preparation to expose Drupal Components outside of Drupal we added a composer.json file to every component and a "replace" section to core/composer.json.

But:

- some components requirement declarations are incorrect
- some components are missing from the drupal/core replace section
- some composer files are missing from Drupal\Tests\ComposerIntegrationTest::getPaths()

Examples:

- drupal/core-event-dispatcher declares "symfony/event-dispatcher": "2.7.*", drupal/core replaces "drupal/core-event-dispatcher": "self.version", drupal/core requires "symfony/event-dispatcher": "~2.8"
- drupal/core-dependency-injection declares "symfony/dependency-injection": "2.7.*"; drupal/core requires "symfony/dependency-injection": "~2.8". Here drupal/core-dependency-injection is missing from the drupal/core replace section.
- drupal/core-dependency-injection declares "symfony/expression-language": "2.7.*"; symfony/expression-language is not required by drupal/core.
- #2712647: Update Symfony components to ~3.1 has a patch which updates core/composer.json but not the core component composer files.

Proposed resolution

- Fix the drupal/core replace section to have all drupal/core-* components declared.
- Fix Drupal\Tests\ComposerIntegrationTest::getPaths() to cover all drupal/core-* composer files.
- Track down all drupal/core-* components external dependencies that are also required by drupal/core but still have have an old version requirement declaration after drupal/core updated its version requirement. Update the components composer.json to match drupal/core in this respect.
- Test coverage?

#2720811: Fix package names of drupal/core-fileCache and drupal/core-phpStorage
#2744357: drupal/core-* components Symfony requirements conflict with drupal/core
#2744383: drupal/core-dependency-injection is missing from the drupal/core replace section
#2747083: drupal/core-dependency-injection wrongly requires symfony/expression-language
#2752119: drupal/core-render is missing from the drupal/core replace section
#2752127: drupal/core-assertion is missing from the drupal/core replace section
#2759839: Rename drupal/core-httpFoundation, add it to drupal/core replace section

In #2638140: drupal_log_error() should log a backtrace we made _drupal_log_error use a 'backtrace_string' argument if passed in. In order to display this we had to move it to '@backtrace_string'. In Drupal 9 we should just change the error methods to create a '@backtrace_string' property instead.

Currently, when using BrowserTestBase and FunctionalJavascriptTestBase, when you log in user and stay on the same page or go to other pages using clickLink, the user session expires after 30 seconds, mostly resulting in 403 pages and thus failing tests.

Cases in point:
#2754985: Add javascript test coverage for adding an exposed filter in Views UI
#2771187: Add javascript testing for pagination on AJAX enabled views

This might have something to do with my local environment setup, but since I get exactly the same errors when uploading these tests to d.o I think it's something in the base setup.

I'll add a test-test here that basically clicks on the same link 15 times in a row. There is no reason this shouldn't work, but it stops working after about the 6th click (and on inspection will show a 403 page). If you re-login after every 4 clicks, the 15 clicks get done in the end.
The test is in BrowserTestBase but the same happens for FunctionalJavascriptTests as can be seen in the related issues.

The problem is the timestamp in the SIMPLETEST_USER_AGENT cookie that only allows requests within 5 seconds of it being set.

Problem/Motivation

Symfony 3 is here, we decided to adopt it for Drupal 8 in #2395443: [policy, no patch] Follow symfony 2.7 or 3.0., this is the question.

Proposed resolution

Prepare Drupal core to use Symfony 3.

Remaining tasks

Fix #2712633: Update symfony-cmf/routing to 1.4.0.
Fix #2712637: Update stack/builder for Symfony 3 compatibility.
Fix #2712643: Update behat/* to 1.7.1 and fabpot/goutte to 3.1.2.
Fix #2720869: Remove the use of deprecated CssSelector and use CssSelectorConverter instead.
Fix #2720891: Replace ContainerAware with ContainerAwareTrait
Fix #2721139: Replace deprecated files ParameterBag usage.
Fix #2721179: Replace deprecated Symfony ExecutionContextInterface.
Fix #2726645: Do not @deprecate EntityManager until all usages are removed (helps the Symfony 3 update).
Fix #2728815: Batch API uses request attributes instead of query in Symfony 3.
Fix #2730129: DrupalKernel must never persist service_container for Symfony 3 update.
Fix #2682373: Implement ContainerAwareEventDispatcher::getListenerPriority().
Fix fails.
Review.
Commit.

User interface changes

None

API changes

Hopefully none

Data model changes

Not yet

Problem/Motivation

BrowserTestBase::getTextContent() wrongly returns the raw content. See the attached "test only" patch.

Proposed resolution

Fix it.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

This issue might turn into a plan with several [policy, no patch]-type sub issues.

In #2735005: Convert all Simpletest web tests to BrowserTestBase (or UnitTestBase/KernelTestBase) there is some great work being done to deprecate SimpleTest in favor of a third-party standard testing framework, which will reduce our need to maintain duplicate code and also potentially make Drupal's test suite more learnable for developers familiar with (e.g.) Symfony's, and vice versa.

What I haven't seen yet though is a higher-level discussion of what the testing framework we want in the end is though, aside from "remove SimpleTest". So we have what we want to move away from, and specific strategies from moving away from it smoothly, but less clear objectives about what we want to move to. I'm deliberately keeping this as a separate discussion, in order to not derail simple conversions being done elsewhere.

Some of the questions we should consider follow.

API of the new test suite

In #2759879: Additional assertions for WebAssert and AssertLegacyTrait, part 2, when reviewing the patch, I noticed that we were implicitly making some decisions/compromises about the API we were converting to in the process of deprecating SimpleTest. For example, the deprecation of the legacy trait version of assertUniqueText():

+   * @deprecated Scheduled for removal in Drupal 9.0.0.
+   *   Use $this->getSession()->getPage()->getText() and substr_count() instead.

That is making a decision for later that we should not have assertUniqueText(). As @Lendude and @catch have pointed out, there are a few reasons we might want to remove a method:

• It's not used enough to justify the maintenance burden.
• It's redundant.
• Having too many methods can actually make it harder to pick the right one.

However, the competing concern is that having a well-named API of test methods improves readability, DX, and maintainability by not repeating boilerplate code over and over (which then in turn can have a bug introduced in any one place and we won't know).

So, we should have an architectural design discussion of what assertions we want to have or not, and use data from core and contrib test suites to justify keeping or removing each.

This also probably applies at other levels of the API, not just assertions, but it was the simple case I encountered. I also have concerns about (e.g.) the verbosity of our unit tests, and I want to make sure we don't end up in a place where our functional tests are equally difficult to follow.

In general, we should be striving for a test suite that is readable, maintainable, and easy for even novice developers to understand.

Structure of the test suite

As @catch pointed out in #2735005: Convert all Simpletest web tests to BrowserTestBase (or UnitTestBase/KernelTestBase):

There's a fair bit of duplication between the test coverage for modules like node/taxonomy and entity system tests. Similarly between tests in Views module vs. tests in views-data-providing modules. That's no fun to pick apart but would be good if we did.

So issues by theme, then sub-issues for those sounds good.

In general, I'd advise against blocking the conversion of any test on a redesign of it -- that leads to problematic scoping that makes initiatives like these get stalled. However, as we do 1:1 conversions of tests, we should also discuss, separately, whether the tests even make sense and whether they should be the kind of tests that they are (kernel, unit, web test, etc.). Some high-level research would be great here, as would tracking observations folks make as they work on other tests.

Other stuff

There is probably more.

Proposed resolution

Discuss!

Remaining tasks

Sub-issues?

User interface changes

N/A

API changes

TBD

Data model changes

N/A

Please credit also @klausi for this issue!

Problem/Motivation

Mink/BrowserKit uses PHP's DOMElement to get the value of an HTML tag. It will provide the value HTML entity decoded, so we need to do the same with the string passed to assertion to actually match.

Mink thinks every time that the test is a human using a real browser. So, now assertText($text) converts the HTML entities in the character actually viewed by a human.

Let's say the the returned page contains this piece of markup: <p>Bad html &lt;script&gt;alert(123);&lt;/script&gt;</p>

In WebTestBase this test passes because it wrongly consider that the text means only stripping tags:

$this->assertText('Bad html <script>alert(123);</script>');

In BrowserTestBase will fail but next will pass because Mink is converting HTML entities as is displayed to a human:

$this->assertText('Bad html <script>alert(123);</script>');

The unit test proves the bug.

Proposed resolution

Fix it. Solution taken from #2763013: Convert web tests to browser tests for link module.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

For #2735005: Convert all Simpletest web tests to BrowserTestBase (or UnitTestBase/KernelTestBase) we need more assertion helper methods to provide a richer page elements assertion experience for our PHPUnit browser tests and to make converting exiting web tests easier. The first part was done in #2750941: Additional BC assertions from WebTestBase to BrowserTestBase.

Proposed resolution

Add assertion methods as we find and need them.

Remaining tasks

Patch.

User interface changes

None.

API changes

Only API additions.

Data model changes

None.

Problem/Motivation

Right now using the core menu block subtrees aren't show unless they are in the active trail. This isn't ideal for things like primary navigation which require subtrees to be shown regardless of which item the user is viewing.

Proposed resolution

Add an option to the core system menu block to make this behavior configurable.

Remaining tasks

Write a patch + tests.

User interface changes

Adds a checkbox.

API changes

Data model changes

Problem/Motivation

1. The root cause of this mess: the fact that Drupal generates file URLs without knowledge about the context those URLs will be used in. But the place where a file URL is generated in may itself not know the context either! For example, an image may be rendered into HTML and then that HTML may happen to be sent in an e-mail (or RSS), and therefore the URL should be absolute. But that was impossible to know at the time when the image template was being rendered (for example when rendering an article to be sent via e-mail, the rendering of the article is not at all different: it's still rendered to HTML).
2. Any time you're sending HTML in a non-web context (for example: e-mail, RSS), you have to make sure all URLs are absolute. But file_create_url() is only invoked on files referenced by code. A complete solution would already have to make all relative URLs absolute anyway, including those in user-generated content.

Proposed resolution

The only sensible solution is to solve the problem at its root. Write a response event subscriber (a response filter in Symfony terminology) that updates all relative URLs in RSS responses to be absolute.

Remaining tasks

• Test coverage.
• Reviews.

User interface changes

None.

API changes

None.

Data model changes

None.

Original issue summary

The feeds Drupal creates include node->teaser or node->body (depending on configuration) in the description fields items. This text can contain relative links to other content on the same domain. Many aggregators, including Drupal's own and bloglines.com, can not handle these relative links. The RSS specification specifies that all links should be absolute.

The attached patch fixes the feed descriptions in format_rss_items (common.inc). It adds a function named 'filter_absolute_urls' to common.inc, which can also be used by aggregator.module and other modules that need absolute urls (such as modules that send out emails).

There are alternative approaches to this fix. One could be to use nodeapi 'rss items' hook, using a contrib module. However in the current implementation of this hook in node.module, modules can not modify the body and/or teaser of items. The cleanfeeds module uses this approach, and needs a patch for node.module to get it to work.

Another approach would be to enable the filter system for feeds, and make a filter which creates absolute urls. Having a 'filter_absolute_urls' function in common.inc would still be very usefull in this scenario.

The 'filter_absolute_urls' function can probably be made a little bit more efficient; I currently have two regexps, one for relative urls ("path/to/somewhere") and one for urls relative to the domain root ("/path/to/somewhere").

Problem/Motivation

1. Install standard
2. Install configuration translation, language
3. add a second language and make it the default
4. Create a new node page view using fields.
5. Save the view
6. Translate the view, set a different label for the title field
7. Save the translation
8. Remove the title field and replace it with a NID field
9. Goto the translated page view:

This also causes:

Field translations are not being removed from the config table when a field is removed from a view.

To reproduce, add a field to a view. Create a translation of this field. Now remove the field from the view.

If you then `select * from config where name = 'views.view.yourview' - you'll see the translations for the field you have removed still exist in config, for languages where the field has been translated.

In my example view, it's using a table layout, and I have additional columns in the table, from the old translation data, that should not exist.

From the duplicate issue #2774789: Field translations not removed from views config when deleting a field

Expected behaviour

It works, no translation though for the field

Actual

( ! ) Fatal error: Unsupported operand types in core/modules/views/src/Plugin/views/field/FieldPluginBase.php on line 1161

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

1. Currently, "page" views override all GET routes with the same path.
2. Consequence: REST GET routes are overridden too.
3. Consequence: the default Taxonomy Term view makes it literally impossible to GET a Taxonomy Term via REST.

Proposed resolution

1. \Drupal\views\Plugin\views\display\Page should only override routes that are render array-based, i.e. that have no _format
2. (although perhaps those routes should get a default _format route requirement, just like \Drupal\Core\EventSubscriber\RouteMethodSubscriber::onRouteBuilding() already sets a default _method requirement?)
3. \Drupal\rest\Plugin\views\display\RestExport shouldn't alter any routes

Remaining tasks

TBD

User interface changes

None.

API changes

TBD

Data model changes

None.

Testing if Drupal can run with webDriver [1] which allowed running tests under real Browsers.[2]

[1] Bahat official webDriver: http://mink.behat.org/en/latest/drivers/selenium2.html
[2] Testing with different browsers: http://www.seleniumhq.org/download/

Pre-setup:
1. Apply patch
2. `composer require behat/mink-selenium2-driver`

Testing (Firefox):
1. You can follow http://mink.behat.org/en/latest/drivers/selenium2.html to start selenium2

2. Make sure you have Firefox installed in system DEFAULT dir

3. Run PHPUnit test ( same as current system )
e.g.

.\vendor\bin\phpunit.bat -c core core\modules\simpletest\tests\src\FunctionalJavascript\BrowserWithJavascriptTest.php

@droplet created a new simple standard test to avoid Drupal issue

.\vendor\bin\phpunit.bat -c core core\modules\simpletest\tests\src\FunctionalJavascript\StandardTest.php

4. It started firefox and running tests without any problems.

Testing (Phantomjs):
1. Start `phantomjs --webdriver=4444`
(If you have selenium2, you can run via selenium2 also)

2. Change `firefox` to `phantomjs` in $this->minkDefaultDriverArgs
(@see my patch's comment)

3. Same as above step 3 ~ 4

@droplet reports:
Chrome & Firefox:
It run with current testbots system smoothly.

Phantomjs:
Current testbot framework:
It can run but crashed

Unknown errors with Session

$this->drupalGet('<front>');

Patched:
@see FunctionalJavascript\StandardTest.php

It worked!!

I don't familiar with Drupal testbots framework. Looking forward to your feedback from who worked for Drupal JavaScript testbots.