ArgumentStringTest makes no HTTP requests but is a functional test
Convert ArgumentStringTest into a Kernel test
None.
None.
None.
None.
N/A
In #2981392: Comment migration corrupts data with multilingual sites we found out that the comment type language settings are not migrated sensibly when the source content type has multilingual support enabled.
Migrations generate one comment type for each Drupal 6 content type (except Forum which uses the hard coded comment_forum). The D8 comment type has a default language for new comments, see the screenshot below.
Currently we leave the default language (for new comments created in D8) to site default language. We also do not show the language selector for comments so that users could change the comment language when they are creating / editing the comments.
1. If the Drupal 6 content type has multilingual support 'disabled'.
Drupal 6 fixture: story.
2. If the Drupal 6 content type has multilingual support 'enabled'.
Drupal 6 fixture: sponsor
This means that the nodes can have a language code but the different nodes cannot be linked as translations of each other.
3. If the Drupal 6 content type has multilingual support 'Enabled, with translation'.
Drupal 6 fixture: article and employee. .
This means that the nodes can have a language code and the nodes with different language codes can be linked as translations of each other. The different node language versions will have their independent comments i.e. the comments are not translations of each other.
NOTE: The scope of this issue is D6-D8 only. The D7-D8 migration will be handled in #3024460: Migrate D7 comment type language settings.
1. Patch
2. Review and test
3. Commit
Enables the comment language selector + changes the default comment language for multilingual sites.
None.
None.
FilterEntityBundleTest makes no HTTP requests but is a functional test
Convert FilterEntityBundleTest into a Kernel test
None.
None.
None.
None.
N/A
At least in Chrome, if a Drupal date field gets disabled in a form_alter (by setting #disabled => TRUE), the disabled attribute is correctly applied to the element (causing it to be non-interactive), but the input element does not get themed the way that other disabled form elements do, as shown in the screenshot.
(I'm uncertain of whether this should be considered a bug with the Seven theme or with the Datetime module. It's more about the intersection of the two than about either one in particular. Datetime shouldn't make many assumptions about how the fields will be themed, but code that only relates to specific modules may not belong in the Seven theme either. I've associated this issue with the theme for now since it does seem more theming related than functionality related.)
Seven
Bartik
Test Drupal\Tests\user\Functional\UserEntityCallbacksTest doesn't make any HTTP request but is a functional test.
UserEntityLabelCallbackTest.None.
None.
None.
None.
N/A
ViewsSqlExceptionTest makes no HTTP requests but is a functional test
Convert ViewsSqlExceptionTest into a Kernel test
None.
None.
None.
None.
N/A
StyleTest makes no HTTP requests but is a functional test
Convert StyleTest into a Kernel test
None.
None.
None.
None.
N/A
When I set a certain block to be cached for up to e.g. 15 minutes, then I expect that the containing page also emits a corresponding header. And I also expect Drupal's page cache to honor this.
TBD
We need to fix these issues first:
RedirectFormBlock still contains max-age 0.None.
None.
UserMailNotifyTest is Kernel test but for some reason wrongly lives under Functional tests namespace.
Move UserMailNotifyTest under Kernel tests namespace.
None.
None.
None.
None.
N/A
LatestRevisionFilterTest makes no HTTP requests but is a functional test
Convert LatestRevisionFilterTest into a Kernel test
None.
None.
None.
None.
N/A
HandlerArgumentUserUidTest makes no HTTP requests but is a functional test
Convert HandlerArgumentUserUidTest into a Kernel test
None.
None.
None.
None.
N/A
UpdateDeleteFileIfStaleTest makes no HTTP requests but is a functional test
Convert UpdateDeleteFileIfStaleTest into a Kernel test
None.
None.
None.
None.
N/A
In #2912353: Handle menu_items related to Drupal 6 and 7 node translations with different IDs we added a new configuration option validate_route to ignore route validation but there is no documentation in the plugin's annotation to document it.
Let's document this plugin.
Also, we should figure out and document (or fix) why the plugin expects an array and then only use the first item:
public function transform($value, MigrateExecutableInterface $migrate_executable, Row $row, $destination_property) {
list($path) = $value;
[...]
}
None.
None.
None.
While working with Paragraphs (contrib module), we noticed that the field widgets don't offer any fucus or active state. For example, would be useful to toggle an active state when the user adds/edits an entity, especially when we have many of them on one node.
Would it be possible to handle active elements in core in node edit forms?
- States are handled by core?
- Field widgets should offer some interactions and not stop event handler propagation?
- any other solution?
Similar to https://www.drupal.org/project/drupal/issues/2994909.
The workspace toolbar tab button size is a bit weird on really small viewport width (below 16.5em, unoriented toolbar mode) and it's RTL styles are incomplete.
Float the item only if the toolbar is oriented.
Workspace toolbar tab will be similar to other tabs if viewport width is less than 16.5em.
RTL is fixed.
Nothing.
Nothing.
Consider using the same approach (media queries) as Contextual or Tour modules.
See the related issues.
Umami demo recipes have a section (field label) Recipe Instruction which sounds confusing.
Change to a label used by other leading recipe websites: Directions or one of the options below:
List of most popular recipe websites and the wording they use for that section:
https://www.yummly.com - Directions
https://www.geniuskitchen.com - Directions
https://www.foodnetwork.com - Directions
https://www.chowhound.com - Instructions
https://www.thekitchn.com - Instructions
https://www.myrecipes.com - How to Make it
https://www.cookinglight.com - How to Make It
http://www.eatingwell.com - Preparation
https://www.epicurious.com - Preparation
https://www.simplyrecipes.com - Method
https://www.bettycrocker.com - Steps
Create a patch to update Umami's recipe with the new label.
Our team uses Cucumber and Selenium for automated acceptance testing. Our test suite runs over a dozen test scenarios concurrently. As a result, we see many errors that rarely occur in production but severely inhibit our automated testing efforts with frequent failures.
The issue relates to the _block_rehash() function in modules/block/block.module. If multiple test runners trigger _block_rehash() at the same time (via cache_clear_all(), insert_block module, or other), the following error occurs:
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry THEME-CONTENT_TYPE-DELTA for key 'tmd': INSERT INTO {block} (module, delta, theme, status, weight, region, pages) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] => CONTENT_TYPE [:db_insert_placeholder_1] => DELTA [:db_insert_placeholder_2] => THEME [:db_insert_placeholder_3] => 0 [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => -1 [:db_insert_placeholder_6] => ) in drupal_write_record() (line 7239 of includes/common.inc)
(Note: replaced actual values with generic: THEME, CONTENT_TYPE, DELTA)
Our test suite results in multiple simultaneous block creation, block deletion, cache clears, and _block_rehash() calls. I believe this error is occurring because _block_rehash() is being called multiple times simultaneously.
The proposed solution is to prevent _block_rehash() from being called by multiple requests. Specifically, the included patch adds a lock on the _block_rehash() function using lock_acquire(), lock_wait(), and lock_release(). After applying this patch, our test suite has not received a single failure due to SQL Integrity constraint violation errors, having run the entire suite about 40 times.
The lock is added around the entire _block_rehash() function, which may not be necessary and could have some negative performance impact, though no performance analysis has been made. I'm looking for some subject-matter expertise to review the proposed patch regarding if the lock can or should be made on a smaller sub-section of the function to reduce the theoretical performance impact.
Also of note is that these exact SQL errors have been reported before in some contrib modules, and the propsed fix was usually a workaround that avoided calling _block_rehash() as frequently. However, these efforts I believe are insufficient as the error should be reproducible with only core blocks. The proposed patch solves the issue at the source.
We are using Drupal 7.34, in the process of updating to 7.35. The patch applies cleanly to 7.x branch as well as 7.34 and 7.35 since no changes have been made to the block.module file in any of these versions.
Patch needs review.
None.
None.
The offcanvas workspace dialog lacks RTL styles.
Add the missing RTL styles.
Patch.
Proper RTL dialog and item layout.
Nothing
Nothing
Modules need a way to declare their migration status and give a short description on the Migrate Upgrade review page, /upgrade. The short description can have a link to a documentation page for example for known issues.
The Review form lists all modules on the source site in either a 'will be upgraded' or 'will not be upgraded' list. However, determining which section to add a module too is not robust. If the module has migrations, it will be displayed in the 'will be upgraded' list, even if it only has one migration and needs more than one to be complete. We need a mechanism that can explain this situation in the UI.
The mechanism needs to be flexible to accommodate the many scenarios possible. See #71 and #72 for details.
This work here is to only create and implement such a system, to make the first step, for what is a complicated problem. Changes may be made to the UI but are expected to be minimal. However, a UX review is planned. When that feedback is given it needs to be decided what can be done in this issue and what must be moved to followups.
Note: in #2914974: Migrate UI - handle sources that do not need an upgrade we defined a list of modules that do not need any migrations (e.g. Overlay, Help) or the contrib functionality has moved into core and there is not a D8 core module with the same name. These modules are listed in ReviewForm::$noUpgradePaths
In a migrate meeting, using a hook or an event was discussed. A possible solution, using hook_form_alter, was implemented in #2914974: Migrate UI - handle sources that do not need an upgrade and removed after a review #176. That review asked some questions, listed below, which should be resolved here.
After framework manager review the status information moved from .info.yml to module.migrate.yml, the format stays the same. And later it moved to migrate_drupal.yml since this is only for drupal sources.
Add the following to migate_drupal.yml to any module providing or needing migrations, include field migrations.
finished:
6:
source_module_A: destination_module_A, destination_module_C
source_module_B: destination_module_B
7:
source_module_A: destination_module_A
source_module_B: destination_module_B
not_finished:
6:
source_module_C: destination_module_D, destination_module_E
In 'finished' is a list of all source module/destination module pairs for migrations that are complete in the module. If migrations are found in the module it will be assumed that the migrations are not finished. In 'not_finished' is a list of all the migrations this module intends to provide but either do not exist or are incomplete for any reason. The 'not_finished' is needed when more than one module will have migrations for a source module and at least one of the modules uses the 'finished' key. The 'not_finished' one will ensure that the source module is listed in the 'will not be upgraded' list. Say Module A and Module B provide migrations for Module C. Module A is finished and uses 'finished'. Then, if Module B has no migrations, it needs to use 'not_finished'.
All the logic to determine whether a source module will be upgraded or not is now in a service (See suggestion in #137.9, migrate_drupal.migration_state.
See the full details in #72 and #77
Now, for the screen shots which need some attention. The difference between the before and after is that on the after screenshots the modules in the Drupal 8 column are listed in a single line separated by commas whereas in the before screenshots they are on separate lines. That's all.
But the screens should provide some information or direction to the user on what to do about the modules in the 'will not be upgraded' section. After all, if a module they need is listed here they need a next step right on this page. How best to inform them of what to do? A single help text somewhere on the page or something else? The user also needs support on what to do about the other modules that will not be upgraded. See #87
Also, the idea of allowing modules to add text to the page via a hook, in a possible followup, has been discussed by the team. Any decision here should be aware of that.
To navigate to the Review page you need a D6 or D7 Database Then install Migrate Drupal UI and go to /upgrade.
Screens shots when using a Drupal 6 database, the test fixture in Commerce Migrate.
Before
Module that will not be upgraded section
After
Modules that will not be upgraded section
The checklist referred to is https://www.drupal.org/docs/8/upgrade/upgrade-using-web-browser#pre-upgr...
The first proposal which came from a migrate meeting was to add the migrate status of the module and a description string to be displayed on the Review Page to info.yml . This was tweaked a few times. See #7 and #8. See #10. Eventually, the description was removed as to difficult to maintain an html string in .info but the version key remained.
Hello,
I am not sure whether this is a true bug as I am nowhere close to be a D8 savvy, but here's what I've got: when you're rendering an entity with image field attached to it and when the image formatter is configured to link to the entity, the resulting link does not account in which language it is being rendered and always links to the entity's original language. Alright, now translating this to English, here are some basic steps to reproduce:
(this bug disappears if we enable translation of the image field)
To me it seems more logical to link image to the translation language in which its entity is currently being rendered even if the image field is not translatable.
For some reason (I just can't debug whole drupal core to figure it out) in Drupal\image\Plugin\Field\FieldFormatter\ImageFormatter::viewElements() the parent entity of the provided items list is set up to be in LANGCODE_DEFAULT instead of having explicitly set spanish language (since precisely in this language the entity is being rendered). What I currently do in image formatter method to overcome this issue is to force the parent entity to look up its translation in the language in which rendering is happening.