See #2735005: Convert all Simpletest web tests to BrowserTestBase (or UnitTestBase/KernelTestBase)
This issue is postponed, blocked by #2911915: Add getHttpClient() to BrowserTestBase
Scope:
- ContextualDynamicContextTest
Everything else is already done!
Continuing from https://www.drupal.org/project/drupal/issues/2951715#comment-12559059
core/modules/migrate/src/Plugin/migrate/process/MenuLinkParent.php:100:
throw new MigrateSkipRowException()Log a message to MigrateSkipRowException to clearly explain why the row is skipped.
Patch
NA
NA
NA
The seven theme tries to include some CSS inside a form alter that affects all media forms:
/**
* Implements hook_form_BASE_FORM_ID_alter() for \Drupal\media\MediaForm.
*/
function seven_form_media_form_alter(&$form, FormStateInterface $form_state) {
// @todo Revisit after https://www.drupal.org/node/2892304 is in. It
// introduces a footer region to these forms which will allow for us to
// display a top border over the published checkbox by defining a
// media-edit-form.html.twig template the same way node does.
$form['#attached']['library'][] = 'seven/media-form';
}
However, it is possible that a site is using Media Entity 1.x instead of core Media, so this library won't be available in that case.
Only include the core CSS library if we are using core Media, not contrib.
Updated: Comment #1
Image field allows site administrator to define default image on field and/or instance level. file_managed Form API element is used to provide this functionality. Form element includes "Remove" button which is used to remove default image form the configuration.
It is easy to reproduce this:
- install Drupal with "Standard" profile
- log in as admin
- navigate to admin/structure/types/manage/article/fields/node.article.field_image
- upload default image
- save configuration
- navigate back to admin/structure/types/manage/article/fields/node.article.field_image
- try to remove default image by clicking "Remove" button
- image stays there
This might be more general problem of file_managed form element. It definitely needs test coverage.
No solution found yet.
- fix bug
N/A
N/A
- Bug found in #1205822-23: File(s) silently deleted when #access=false
Layout discovery doesn't load layout suggestions unless the layout definition is prefixed with layout__ and the template with layout--.
This break any existing site using the (deprecated) Layouts contrib module, where the prefixing wasn't necessary.
Additionally site-builders and developers get confused as twig debug comments suggest wrong [as in: not-prefixed] template suggestions names, i.e. (from: #2905197: Template override is not working):
layouts definitions file: naurodvolleys.layouts.yml
naurodvolleys_1x1:
label: "naurodvolleys 1x1"
category: "naurodvolleys"
template: "templates/content-layout/naurodvolleys_1x1"
regions:
main:
label: "Main"Template suggestions:
Target suggestion: naurodvolleys-1x1--node-result-1x1.html.twig
Suggestion is not loaded.
For further investigation you can read #2862683: 'base hook' key prevents template suggestions from working comments from #25 on going.
The first task should be to understand if prefixing layouts with layout__/layout-- as core does is the right way.
- If it is then we need to update the documentation pages How to register layouts and How to upgrade from Layout Plugin, together with updating the twig debug comment suggestions.
- if it is NOT, then we need to fix the issue in order for layout suggestions to be loaded correctly.
@tim.plunkett on #9 confirmed this is actually a bug, themes and modules layout templates suggestions needs to be loaded in accordance with their definitions.
This is a pure code change, so no UI changes expected.
There may be Layout API changes, depending what the result of task 1) will be.
drupalPostAjaxForm() is simulating the behaviour of ajax.js, so using it, doesn't really provide fundamental guarantees.
#2809161: Convert Javascript/AJAX testing to use JavascriptTestBase suggests to convert them to JavascriptTestBase
Follow up to #2982740: Convert \Drupal\drupal_system_listing_compatible_test\Tests\SystemListingCompatibleTest to KernelTestBase
\Drupal\Tests\drupal_system_listing_compatible_test\Kernel\SystemListingCompatibleTest says:
/**
* Attempt to enable a module from the Testing profile.
*
* This test uses the Minimal profile, but enables a module from the Testing
* profile to confirm that a different profile can be used for running tests.
*
* @var array
*/
public static $modules = ['drupal_system_listing_compatible_test'];
It turns out, this test no longer really tests that we can install a module outside the installed profile in the test, since there is a copy of the drupal_system_listing_compatible_test module in the system module. So if it can't find the version in the profile, it just installs the one in the system module.
The system version is used by \Drupal\Tests\system\Kernel\Common\SystemListingTest::testDirectoryPrecedence to check that modules placed in a profile override other versions of the same module. So we can't just remove the system version.
I have tested that code:
process:
uri:
plugin: file_copy
reuse: true
source:
- source_file_path_remote
- destination_file_path
In the transform method of file_copy process plugin the download process plugin is called when a source file is remote. So the file is downloaded ignoring the reuse option.
Add a new configuration key 'file_exists' that holds a value declaring what action to take when the destination file exists. The options are
replace - Replace the existing destination file
rename - Make the destination filename unique by adding '_N'
use existing - Take no action
Review
Add change record
drupalPostAjaxForm() is simulating the behaviour of ajax.js, so using it, doesn't really provide fundamental guarantees.
#2809161: Convert Javascript/AJAX testing to use JavascriptTestBase suggests to convert them to JavascriptTestBase
Convert system functional tests to phpunit.
Scope:
./System/ErrorHandlerTest.php
In core/modules/menu_link_content/src/Plugin/Menu/MenuLinkContent.php line 201
The documentation says that it should return the menu link ID but it was not returning anything.
/**
* Returns the unique ID representing the menu link.
*
* @return string
* The menu link ID.
*/
protected function getUuid() {
$this->getDerivativeId();
}This is a part of the attempt to fix #2572645: [plan] Fix 'Drupal.Commenting.FunctionComment' coding standard
This issue is created to tackle the sub-sniffs
Drupal.Commenting.FunctionComment.IncorrectTypeHint
Drupal.Commenting.FunctionComment.InvalidTypeHint
When you currently enable a module, you'll notice that new local tasks are not visible. They only appear after clearing cache.
The problem was noticed in the field group module (#2848314: Add group button is not available at manage form display). But i notice that this is also the case for Field UI.
Steps to Reproduce:
Make sure that local tasks are also correctly rebuild when enabling modules.
I can't get submenus to work with Drupal 8.4 and PostgreSQL.
The following two attached screenshots (dropdown1 and dropdown2) show that I've set up the "enabled", "show as expanded" and parent
links correctly:
Here is the value of $data at line 272 of \Drupal\Core\Menu\MenuLinkTree#build_items():
It shows that the subtree is missing, even though 'hasChildren' is true. Thus $element['below'] is
not set -- this is used in the templates to generate the submenus. See the menu.png file.
Currently we are always running into problems that for the 80% of use cases, when you are outputting nodes, you are doing so in lists or teasers. Viewing a node at node/[node:nid] with the 'full' view mode is often the special case. We are getting more used to creating different view modes as we need them for listings, and when you configure your view modes in the 'Manage display' tab, when you are changing the 'Default', this really only affects the full view mode. I think the 'Default' should instead affect the teaser view modes and *not* the 'Full' view mode. Not sure if this makes sense.
I was trying to do this:
// Create a file in '/tmp/some-path'.
$file = drupal_tempnam('temporary://some-path', 'prefix');
But the returned filename will always reside in the base directory of the 'temporary' wrapper, because the implementation of drupal_tempnam uses the wrappers getDirectoryPath method, which basically returns the root of the filesystem represented by the wrapper.
Is this on purpose? Or a bug that needs fixing?
If the former, the docs need changing.
You need to be able to see the actual edit version of a past revision in order to properly retrieve content.
Eg:
1. User A puts some complex formatted HTML in the node body
2. User B removes it while making other edits
3. User A wants it back.
You need to see the body text in an actual edit form for this to work. See Wikipedia, for example.
It's a follow-up from #1796604: Make constructor parameters consistent
There's a inconsistensy in parameters order for:
- entity_create($entity_type, array $values)
- EntityInterface::__construct(array $values, $entity_type)
Also all derived interfaces & implementations are usingContentEntityInterface::__construct(array $values = array(), $entity_type) with defaults
Make $entity_type the first and required parameter and optional $values array line entity_create() does
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...
This was added in Drupal 7 for the case of loading taxonomy vocabularies. Those are now config entities and there's no other use case which can't be handled by grabbing every ID then loading based on that. Let's just remove support.