Problem/Motivation

View more link in recipe cards is not fully translated. The bundle is always in English because we are using the bundle machine name.

Proposed resolution

Use the type label() for rendering the translated type name.

Remaining tasks

Patch

User interface changes

None (in English), but will make this translatable.

API changes

None

Data model changes

None

Perhaps we could add another language so we can demo language specific features?

Problem/Motivation

The {node} parameter from node revisions routes are not upcasted. But a contrib module expects to receive full the entity in {node} parameter. Example: \Drupal\ctools\Plugin\Condition\EntityBundle::evaluate().

Proposed resolution

Upcast the {node} parameter for these paths:

• /node/{node}/revisions/{node_revision}/view
• /node/{node}/revisions/{node_revision}/revert
• /node/{node}/revisions/{node_revision}/revert/{langcode}
• /node/{node}/revisions/{node_revision}/delete

For a workaround, either use node_load() and plan to remove it once the bug is fixed or see #18 for the more proper way to do it.

Remaining tasks

1. Review the updated issue summary.
2. Review the change record.

User interface changes

None.

API changes

\Drupal::routeMatch()->getParameter('node') will return a Node object instead of an integer on the node-revision routes listed above.

Data model changes

None.

Updated: Comment [#516]
Jump to page 2

Problem/Motivation

Install profiles are not inheritable, so if you want to, say, take Drupal Commons, and base your site off of it, but add one or two extra modules in your own customized install profile, you have to clone the entire install profile and change it to your needs. Allowing install profiles to declare base profiles (just like themes can declare base themes) would drastically simplify customizations to existing distributions by:

• Inheriting configuration from a parent install profile (base-profile)
• Overriding specific configuration from the base-profile
• Inheriting customizations in the installer from the base-profile
• Having additional installer tasks and form items to customize their own "start-state"

Additional motivations are detailed on Dries's blog post.

Proposed resolution

• Modify the module load system to take into account base install profiles.
• Modify the install profile system to run parent installer(s) in the correct order.
• One proposed solution was to simply use modules instead of profile inheritance. This was discussedatlength and the prevailing attitude was that the functionality for profile inheritance has valuable use cases that cannot be solved by modules alone.
• An early resolution was to include a tag to exclude dependencies and themes. In an effort to clearly define focus for this patch, this functionality was removed from this patch. The use case for excluded_dependencies and excluded_themes is still very much valid, so this feature request has been given its own issue.

Complications

Implementing this would expose or compound existing problems with the way distributions handle config. Specifically how distributions provide low level config bug fixes and new features to existing sites. #3004662: [META] Standardize the way distributions handle config updates was opened to see if we can get consensus around a solution.

Remaining tasks

• Create plan
• Write useful issue summary
• Fix issue from #405
• Fix issue from #412
• Fix issue from #476
• Update Change Record.
• Make tests pass.
• Extensively test this patch against a real-world base-profile
• Add to existing documentation page (To be published only after patch is applied.)
• Review Documentation to make sure they are up-to-date.

User interface changes

None.

API changes

Install profiles can define base profiles using the syntax base profile: BASE_PROFILE inside their .info.yml files.

Related Issues

• For D7 patch tracking: #2067229: Allow install profiles to declare base profiles for Drupal 7
• For D8 info inheritance patch tracking: #2692403: Make info and configuration inheritable in profiles
• For D8 excluded_dependencies and excluded_themes: #2914389: Allow profiles to exclude dependencies of their parent

Will fill this in later...

Problem/Motivation

The core migrate system needs a way to import things from CSV files.

Immediate use case is for the Umami Demo profile now in core in 8.6.x. The imported content is in CSV files and we have code to read it and create the relevant entries. Having migrate_source_csv in core would allow us to remove that code and use migrate instead.

See #2809635-37: Create experimental installation profile for where @larowlan suggested bring migrate_source_csv into core.

Other good reasons to have CSV as a migration source in core:

• "I use this constantly. I've seen it forked into the Contenta distro, and a few of my own projects (I just want the source plugin, not another module.) It'll also be vital to Commerce integrations as CSV is a common way to import data from an ERP." @mglaman (#4)
• "CSV format is the first format used by non technical professionnals who need to import data and to generate/edit those datas thanks to software they knew (MS Excel without mention it). It's also the easiest way to export data from many ERP and big solutions with datas." @GoZ (#5)
• "CSV is simply a really common used format and it would make migrate more usable by default for many usecases. One could say: Oh it is easy to parse CSV, but it turns out it is not. On top of that the module also doesn't load the entire CSV file upfront, but rather reads line by line. I think this makes it a good candidate also for bigger migrations out there." @dawehner (#14)
• "This would help the Out of the Box Initiative. Let's do it! Consider this my maintainer +1 :)" @phenaproxima (#18)

Proposed resolution

The migrate_source_csv module has a stable release (2.0), has been downloaded almost 100k times, and comes complete with tests. The contenta CMS has been using this for their migrations, too.

Rename the files/namespaces, and move it in, as-is, to the core migrate module.

Since this is a straight port from contrib, discussions about fetchers, etc. are postponed to follow-ups. See #16, #36 and #37 for some of the highlights of the discussion.

Follow-up: #2962091: Adopt fetchers/parsers logic for use by source csv plugin

Remaining tasks

1. Patch that renames files/namespaces and moves the contrib code into core Done.
2. Tests Done.
3. Word-smithing PHPDocs Done.
4. Decide if we're okay with a straight port (done), or if we need to hash out all the fetcher/parser stuff first, figure out the design, class names, avoid conflicts, possible BC hell, etc. Done. See comments #80 through #83. Punted to #2962091: Adopt fetchers/parsers logic for use by source csv plugin.
5. Finish cleaning up the docs and tests.

None.

User interface changes

None.

API changes

Adds a new migrate source plugin called "csv" in migration yml definition files. The class providing the plugin (\Drupal\migrate\Plugin\migrate\source\CSV) is heavily commented with PHPDoc.

Adds a \Drupal\migrate\CSVFileObject class (which extends \SplFileObject).

Existing users of this plugin from contrib are unharmed. The name is the same, but we haven't changed anything about how it works. Contrib users simply disable migrate_source_csv module before upgrading to core 8.X.Y and none of their migration files have to be changed to continue working.

Data model changes

None.

Original report by @smaz

In #2809635: Create experimental installation profile, we are using CSV files to provide default content for a demo installation profile of Drupal.

In a review, @larowlan suggested bringing the CSV migration sources into core:
https://www.drupal.org/project/drupal/issues/2809635#comment-12381619

I agree that a CSV migrate source would be a very useful feature for core.

The migrate_source_csv module has a stable release (2.0), has been downloaded almost 100k times (not sure if that includes composer stats?), and comes complete with tests. The contenta CMS has been using this for their migrations, too.

So would it be ok to look at moving this into Core's migrate module? If so, I'm happy to try and turn the module into a patch.

I have two entities that were imported in two translations from another source. When one of these two entities references the other, and I render the parent entity in its non-default translation, the referenced entity is erroneously rendered in its default translation.

The reason is that my entity returns false for isTranslatable(). Therefore, in EntityViewDisplay::buildMultiple the $view_langcode is set to null and in FormatterBase::view $language is set to the current language.

My entity is translatable, it just does not have content_translation enabled. This module is not needed as the actual process of translation is done outside of my site, before the import. Activating content_translation would solve the problem, but is not the correct way.

The way of determing in which language a field is rendered needs to be changed.

Request: Provide configuration to disable AJAX for Views exposed form submission.

Current Code: If the view is enabled to "use ajax", then form submission and pagers are setup to use AJAX.

Use Case: Non-AJAX form submission with an AJAX pager. This case is useful when there are non-view related content on the page that needs to change based on the views results. Example: Facet blocks for Search API views.

Problem/Motivation

I have encountered multiple issues/bugs combining Content translations and User preferences. The following steps were tested on a clean Drupal 8.6.2 installation with English as default language and default admin user.

Steps to reproduce:

• Create a basic page
• Enable Configuration Translation, Content Translation, Interface Translation and Language
• Add Swedish language at /admin/config/regional/language/add
• At /admin/config/regional/content-language select Content, Custom block and Custom menu link. Select all inner categories for each of them and save.
• At /admin/config/regional/languages/detection check the box for Account administration pages and save
• Go to /admin/people and edit the admin user. In the Language preferences, select English as the Administration pages language and save
• Go to /admin/content click edit on the previously created basic page, then select the Translate tab and add a Swedish translation. Change the title and body, click save(this translation). After saving the translation, the original english page is displayed
  and a green notice says "basic page xx has been updated". BUG: Add /sv at the end of the URL before /node/1 and the whole site changes to Swedish except for the title and content which remain in english (expected to show the swedish translation)
• BUG: After the previous steps, go to admin/content and you'll see both translations, click edit on the Swedish version when the editor opens, the English version opens instead of the Swedish version, despite /sv being present in the URL (Expected to edit the Swedish translation).
• BUG: Again at /admin/content open the dropdown operations menu for the Swedish translation and select delete, then Drupal asks you to confirm deleting both English and Swedish translations (expected to delete only Swedish translation)
• Other strange behaviour:
  • From /admin/content follow the link to the Swedish translation (You should see the entire site in Swedish except the title and body, which remain in English). Copy the URL, open up a private window in your browser and navigate to the copied URL, you should see the site correctly displayed in Swedish as well as the title and content.
  • When editing the Swedish translation, if you uncheck the "Published" box and save, you will then see that the English version as been unpublished instead (expected to unpublish the Swedish translation)

Proposed resolution

None for now

Remaining tasks

None for now

Problem/Motivation

See screenshot:

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

There is a bug with the "active-trail" class not showing up on <li> for menu items with Drupal 7.14. The problem is that "active-trail" is missing for a menu link to the front page (path "<front>"), all other links have "active-trail" just fine.

The situation is also slightly different for the horizontal primary link tabs that can be switched on from theme settings Toggle display - Main menu, than they are for the vertical navigation in the Main menu block. In the horizontal tabs the front page <li> has "active" but not "active-trail". So "active" could be used to do get around this issue for horizontal menus. But unfortunately if you want the vertical menu, there is no "active" nor "active-trail".

I verified that both "active" and "active-trail" are missing with a fresh install without any added modules on Drupal 7.4 to 7.14. The behaviour is identical with Bartik, Garland and Stark themes, as well as Zen.

Steps to reproduce:

1. Create a fresh install of Drupal 7.14.
2. On the front page go to Structure -> Blocks.
3. Move "Main menu" block to "First sidebar"
4. Create a new "Basic page" with test content and click "Provide a menu link" -> "Parent item" [Main menu]
5. Use e.g. Firebug to verify that the newly created test page link on the sidebar has "active-trail" on <li> but "Home" does not.

Attached is a patch that fixes the bug by adding special handling for the front page when adding the active-trail class. A better solution would be to get the 'in_active_trail' variable correctly set for links to <front>, but unfortunately I could not find out how to do that.

Problem/Motivation

We decided in #2976035-13: [PP-1] Entity type CRUD operations must use the last installed entity type and field storage definitions to drop support for automatic entity updates, for the many reasons stated in that comment.

However, we can add support for changing the entity schema to (non-)revisionable/(non-)translatable by using "manual" entity updates (i.e. explicit update functions), which should work for entity type with and without data.

Proposed resolution

Generalize and improve the code in \Drupal\Core\Entity\Sql\SqlContentEntityStorageSchemaConverter to not use the live entity type and field storage definitions anymore, and make it work as part of SqlContentEntityStorageSchema instead of trying to work around/against it.

Remaining tasks

Review the proposed solution.

User interface changes

Nope.

API changes

API addition: a new updateEntityTypeSchema(EntityTypeInterface $entity_type, array $field_storage_definitions, array &$sandbox = NULL) method added to EntityDefinitionUpdateManager.

Data model changes

Nope.

DrupalSelenium2Driver->getWebDriverSession() == NULL when debugging.
If do "Run" all is OK.
See screenshot and settings.

I have a image field that I extended with the image_widget_crop module. I have 2 ratio's: 21/9 and 16/9 (but the problem occurs with every ratio). I also applied responsive images to this field, so when I save the node it has to create 2 images. One with 21:9 ratio and one with 16:9 ratio. When I crop the image with the 21:9 ratio and save the node, I always get the next error in my reports:
Symfony\Component\HttpKernel\Exception\ServiceUnavailableHttpException: Image generation in progress. Try again shortly. in Drupal\image\Controller\ImageStyleDownloadController->deliver() (line 148 of /Users/seppebeelprez/dev/git/drk8/web/core/modules/image/src/Controller/ImageStyleDownloadController.php).

When I look at my image styles in the files folder, I can see bot directories (ratio_16_9 and ratio_21_9) but not always are my images saved (that's the 503 service unavailable error I'm getting). It happens with small and large files, so the size isn't the problem. Drupal also only creates the images when it reaches the breakpoints that I've said.

Maybe I'm doing something wrong here but in my developers team nobody find where exactly the problem is.

Problem/Motivation

I'm using content moderation in combination with the group.module, so I'm relying on node grants from that for edit access and normal editors do not have "view any unpublished entity".

As a result, /latest works fine for content that the user himself creates as he does have view own unpublished, but it doesn't work for entities that someone else created.

However, the editor can edit that entity and I'm also allowed to view it through /revisions. And on save, he's even redirect to /latest and then sees the access denied page.

Proposed resolution

Not sure what to do, For similar problems with translations, we're handling it through #2972308: Allow users to translate content they can edit, so the access check could look at edit permission, alternatively, we could add an entity type specific check through the handler, so that node can check its access revisions permissions?

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Migrate multilingual data from D6 and D7.

Proposed resolution

D6 migration and much of D7 is working so use those migrations, and their plugins as models for these migrations. It is preferred to improve the existing destination plugins instead of creating new ones.

Remaining tasks

Because D6 is nearing end of life, the D6 multilingual migrations are the highest priority as shown in the list below.

Top Priority

High priority - remaining content migrations

Drupal 7 - Drupal 8 Entity Translation migrations

• #2989627: d7_node_entity_translation migration is in the wrong module and is missing some mappings
• #2845975: Migrate Drupal 6 user profile field value option translations
• #2746541: Migrate D6 and D7 node revision translations to D8
• #2754493: D6 synchronized fields aren't migrated properly

Multilingual taxonomies / content migrations

• #2886609: Migrate translations for D6 i18n taxonomy 'localized' terms
• #2979964: Migrate translations for D7 i18n taxonomy 'localized' terms
• #2859297: Migrate taxonomy term references for D6 Node translations
• #2979966: Migrate D7 i18n taxonomy term language

Comments

• #2981393: Migrate comment type language settings

Medium Priority

Multiligual vocabularies

• #2979970: Migrate D7 vocabulary language settings
• #2980551: Errors When Migrating Books From Multilingual Drupal 7

Low Priority

• #2970847: i18n Variable to config: system site settings [d7]
• #2970849: i18n Variable to config: user settings and user.mail
• #3008025: Migrate D7 i18n block translated strings
• #3008028: Migrate D7 i18n menu links
• #3008029: Migrate D7 i18n CCK field option translations
• #3008030: Migrate D7 i18n CCK fields label and description
• #2746517: Automatically derive auxiliary migrations

To filter out unwanted migrations from your list you can filter on tag for your Drupal version.

drush migrate:status --tag="Drupal 7"
drush migrate:status --tag="Drupal 6"

I've been working for some time trying to upgrade a site from D7 to D8 using https://drupalize.me/blog/201604/custom-drupal-drupal-migrations-migrate... as my guide. There seemed to be artifacts from a D6 to D7 migration, so I did a D2D from 7 to 7 hoping this would remove these artifacts. Having spent much time getting the site from one D7 installation to another I am returning to the D8 upgrade using this "clean" version of the site. It seems to have had little impact. When trying to do my custom upgrade I run "drush migrate-status" and I see that it is looking for non-existing D6 tables.

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'files' doesn't exist: SELECT COUNT(*) AS expression
FROM
(SELECT 1 AS expression
FROM
{files} f) subquery; Array
(
)

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'comments' doesn't exist: SELECT COUNT(*) AS expression
FROM
(SELECT 1 AS expression
FROM
{comments} c
INNER JOIN {node} n ON c.nid = n.nid) subquery; Array
(
)

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'vocabulary' doesn't exist: SELECT COUNT(*) AS expression
FROM
(SELECT 1 AS expression
FROM
{vocabulary} v) subquery; Array
(
)

I am completely at a loss on where to start addressing this. Searches return little useful information. I don't see a way to tell the upgrade to just ignore them.

Thank you,
Sean

Problem/Motivation

#1838242: Provide Views integration for datetime field uses hook_field_views_data() to add proper views integration. However, due to limitations of the Views API, this mechanism does not work for base table fields.
Datetime is the *only* module that adds field types, apparently (the rest have moved into \Drupal\Core), so until #2337515: Allow @FieldType to customize views data is in this might be overly complicated.

Proposed resolution

TBD

Remaining tasks

Find a solution

User interface changes

N/A

API changes

N/A

I recently tried to update our website from Drupal 8.5.5 to Drupal 8.6.1. I keep getting multiple errors. The first two I found tickets for. This third one though, I am finding no information documented on this.

When I run `drush updb -y` I get the following errors at the end:

[error] No entity type for field name_1 on view facets
[error] Update failed: taxonomy_post_update_handle_publishing_status_addition_in_views
[error] Update aborted by: taxonomy_post_update_handle_publishing_status_addition_in_views
[error] Finished performing updates.

No error messages are appearing in the logs.

I do see the following at the top of the updb command:

---------- -------------------------------------------- ------------- ----------------------------------------------------------------------------------------------
Module Update ID Type Description
---------- -------------------------------------------- ------------- ----------------------------------------------------------------------------------------------
taxonomy handle_publishing_status_addition_in_views post-update Add a 'published' = TRUE filter for all Taxonomy term views and converts existing ones that
were using the 'content_translation_status' field.
---------- -------------------------------------------- ------------- ----------------------------------------------------------------------------------------------

I am unsure what is going on. There are no errors in the logs about this. Clearly the taxonomy module has some upgrades that are not quite ready to go live, given all the bugs still being found. I am sure these will be fixed soon though. I will see what I can do to fix it on my end.

The first bug fixes I found were made in these tickets:
https://www.drupal.org/project/drupal/issues/2997982
https://www.drupal.org/project/drupal/issues/2997960

Hi There,

I'm facing a weird issue in views pagination. View pager shows extra un-necessary pages in addition to the actual pages containing items.
The pattern of this is like if you have items in 3 pages then 7-page will show up as total no of pages 3 of them would be the actual ones 1 would be regarding displaying "no result" message and 3 would be blank pages.

I've tried with https://www.drupal.org/project/views_litepager this module and it's working fine but it works as a mini pager.

Please provide some solution regarding views pager.