Lots of implementations of this hook do:

  $bundle_info = \Drupal::service('entity_type.bundle.info')->getBundleInfo();

because they want to declare an extra field on all the bundles of an entity.

How about we add that parameter to the hook's signature, so you don't need to get it yourself in the implementation?

Problem/Motivation

jQuery Joyride was added to support tours. It is used in a Views tour and a welcome tour in Umami. However Joyride has not been maintained for the last 2 years. See https://zurb.com/playground/jquery-joyride-feature-tour-plugin and commit history at https://github.com/zurb/joyride

Proposed resolution

Consider replacing Joyride or remove altogether if we don't think its useful. The Umami team thinks it is useful and uses it.

Remaining tasks

Discuss.

User interface changes

TBD.

API changes

TBD.

Data model changes

TBD.

Release notes snippet

TBD.

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

Base field overrides don't like it very much if you delete the field they override.

When doing a config import of a base field override of a deleted field you get a fatal error:
TypeError: Argument 2 passed to Drupal\Core\Entity\ContentEntityStorageBase::onFieldDefinitionUpdate() must implement interface Drupal\Core\Field\FieldDefinitionInterface, null given

Proposed resolution

A) Base field overrides should probably listen to fields being deleted and delete themself; @Berdir
Or B) They should not affect things if the field they are for not there. For robustness’s sake; @alexpott
C) Include an update function in core that does this for all entity types. that would only go along with the code that makes them delete themselves if the base field is deleted; @amateescu

Problem/Motivation

If you make an entity query on config entity with operator IN inside condition it doesn't work or trigger lot of warnings.
My field is a simple sequence of string.
It doesn't work if you send an array inside value of condition, it's trigger this and also no result. :

 mb_strtolower() expects parameter 1 to be string, array given in Drupal\Core\Config\Entity\Query\Condition->match() (line 166 of core/lib/Drupal/Core/Config/Entity/Query/Condition.php).
is trigger

If you send an implode() of your value, you get the result, but the warning above is triggering 4 times

Proposed resolution

I dodn't know if it's the right ways to fix it with allowing array value ? or stay with string and also fix the warning ?

Hi, When I try to update Drupal 8.7.0 db br drush updb I get the following error.

>  [notice] Update started: taxonomy_post_update_make_taxonomy_term_revisionable
>  [error]  Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name' cannot be null: INSERT INTO {tmp_d305d9taxonomy_term_field_data} (tid, revision_id, vid, langcode, name, description__value, description__format, weight, changed, default_langcode, status, revision_translation_affected) 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, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11); Array
> (
>     [:db_insert_placeholder_0] => 1
>     [:db_insert_placeholder_1] => 1
>     [:db_insert_placeholder_2] => tags
>     [:db_insert_placeholder_3] => tr
>     [:db_insert_placeholder_4] =>
>     [:db_insert_placeholder_5] =>
>     [:db_insert_placeholder_6] =>
>     [:db_insert_placeholder_7] =>
>     [:db_insert_placeholder_8] =>
>     [:db_insert_placeholder_9] =>
>     [:db_insert_placeholder_10] =>
>     [:db_insert_placeholder_11] => 1
> )
>  in Drupal\Core\Database\Connection->handleQueryException() (line 689 of /var/www/drupal8/web/core/lib/Drupal/Core/Database/Connection.php).
>  [error]  The entity update process failed while processing the entity type taxonomy_term, ID: 1.
>  [error]  Update failed: taxonomy_post_update_make_taxonomy_term_revisionable
 [error]  Update aborted by: taxonomy_post_update_make_taxonomy_term_revisionable
 [error]  Finished performing updates.

Problem/Motivation
Now that #3045966 is committed we realized that user performing the install may not know that the built-in users are assigned the same password as admin. We should provide a message to the user stating as much.

Proposed resolution
Once the install is complete, display a message that the users have the same password.

Initial suggestion: `The Umami demonstration has built-in users that have been given the same password as the administrator.`

"Users" is a link to the user page for the user to see what's been installed.

Remaining tasks
Discuss.

User interface changes
None.

API changes
None.

Data model changes
None.

Release notes snippet
None.

Problem/Motivation

As suggested by @alexpott in #3052492-12: ViewsEntitySchemaSubscriber should not make an entity update fail if a view cannot be resaved, the current code in ViewsEntitySchemaSubscriber could be made easier to read/understand if we would pass a single view object to the various methods that need to update it (processHandlers(), baseTableRename(), etc.)

Proposed resolution

Do it :)

Remaining tasks

Write a patch, reviews, etc.

User interface changes

Nope.

API changes

Nope. Event subscribers specifically are excluded from core's bc policy.

Data model changes

Nope.

Release notes snippet

Nope.

Problem/Motivation

The file setter functions do not return $this, and do not chain. This is inconsistent with many other objects.

Proposed resolution

Make the file setter functions chain, and use it in a few uncontroversial places to prove/test that they work.

Remaining tasks

Apply setter in more places, where it makes sense, and as that code is changed.

User interface changes

None

API changes

The File setter functions will return $this where they previously returned nothing. This is backwards compatible.

Data model changes

None

Release notes snippet

The File setter functions setFilename(), setFileUri(), setMimetype(), setSize(), setPermanent(), and setTemporary() now return $this and can be used in chained operations.

I imagine it is a fairly common wish to create a new route or local task that is only applicable to a certain bundle or bundles.

At the moment that requires some custom access code.

Perhaps we could add an optional _bundles parameter to the requirements key for routes in routing.yml? OR modify the _entity_access key to accept a bundle argument in the way that the entity_access contrib project does.

I am currently running drupal 8.6.15 site. I tried to upgrade my site to the drupal version 8.7.1 using drush commands. But could not upgrade, instead it get terminated due to an unrecoverable error. Any solution to this?

My PHP version is 7.2.14.

In the terminal where drush commands are running, the following error is shown :

PHP Fatal error: Uncaught TypeError: Argument 3 passed to Drupal\views\EntityViewsData::mapFieldDefinition() must implement interface Drupal\Core\Field\FieldDefinitionInterface, null given, called in /opt/web/core/modules/views/src/EntityViewsData.php on line 290 and defined in /opt/web/core/modules/views/src/EntityViewsData.php:387
Stack trace:
#0 /opt/web/core/modules/views/src/EntityViewsData.php(290): Drupal\views\EntityViewsData->mapFieldDefinition('file_managed', 'type', NULL, Object(Drupal\Core\Entity\Sql\DefaultTableMapping), Array)
#1 /opt/web/core/modules/file/src/FileViewsData.php(16): Drupal\views\EntityViewsData->getViewsData()
#2 /opt/web/core/modules/views/views.views.inc(178): Drupal\file\FileViewsData->getViewsData()
#3 [internal function]: views_views_data()
#4 /opt/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(392): call_user_func_array('views_views_dat...', Array)
#5 /opt/web/core/modules/views/src/ViewsData.php(243): Drupal\Core\Extension\ModuleHandler->invoke('views', 'views_data')
#6 /opt/web/cor in /opt/web/core/modules/views/src/EntityViewsData.php on line 387
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Uncaught TypeError: Argument 3 passed to
Drupal\views\EntityViewsData::mapFieldDefinition() must implement
interface Drupal\Core\Field\FieldDefinitionInterface, null given,
called in /opt/web/core/modules/views/src/EntityViewsData.php on line
290 and defined in
/opt/web/core/modules/views/src/EntityViewsData.php:387
Stack trace:
#0 /opt/web/core/modules/views/src/EntityViewsData.php(290):
Drupal\views\EntityViewsData->mapFieldDefinition('file_managed',
'type', NULL, Object(Drupal\Core\Entity\Sql\DefaultTableMapping),
Array)
#1 /opt/web/core/modules/file/src/FileViewsData.php(16):
Drupal\views\EntityViewsData->getViewsData()
#2 /opt/web/core/modules/views/views.views.inc(178):
Drupal\file\FileViewsData->getViewsData()
#3 [internal function]: views_views_data()
#4 /opt/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(392):
call_user_func_array('views_views_dat...', Array)
#5 /opt/web/core/modules/views/src/ViewsData.php(243):
Drupal\Core\Extension\ModuleHandler->invoke('views', 'views_data')
#6 /opt/web/cor in
/opt/web/core/modules/views/src/EntityViewsData.php, line 387
The external command could not be executed due to an application [error]
error.
You have pending database updates. Run `drush updatedb` or visit [warning]
update.php in your browser.
Backups were restored successfully. [ok]

Got the following error notice in Recent log messages :

Notice: Undefined index: type in Drupal\views\EntityViewsData->getViewsData() (line 290 of /opt/web/core/modules/views/src/EntityViewsData.php) #0 /opt/web/core/includes/bootstrap.inc(587): _drupal_error_handler_real(8, 'Undefined index...', '/opt/web/core/m...', 290, Array) #1 /opt/web/core/modules/views/src/EntityViewsData.php(290): _drupal_error_handler(8, 'Undefined index...', '/opt/web/core/m...', 290, Array) #2 /opt/web/core/modules/file/src/FileViewsData.php(16): Drupal\views\EntityViewsData->getViewsData() #3 /opt/web/core/modules/views/views.views.inc(178): Drupal\file\FileViewsData->getViewsData() #4 [internal function]: views_views_data() #5 /opt/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(392): call_user_func_array('views_views_dat...', Array) #6 /opt/web/core/modules/views/src/ViewsData.php(243): Drupal\Core\Extension\ModuleHandler->invoke('views', 'views_data') #7 /opt/web/core/modules/views/src/ViewsData.php(160): Drupal\views\ViewsData->getData() #8 /opt/web/modules/contrib/ds/src/Plugin/Derivative/DsEntityRow.php(91): Drupal\views\ViewsData->get('block_content') #9 /opt/web/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(101): Drupal\ds\Plugin\Derivative\DsEntityRow->getDerivativeDefinitions(Array) #10 /opt/web/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(87): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives(Array) #11 /opt/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(284): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions() #12 /opt/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(175): Drupal\Core\Plugin\DefaultPluginManager->findDefinitions() #13 /opt/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryCachedTrait.php(22): Drupal\Core\Plugin\DefaultPluginManager->getDefinitions() #14 /opt/web/core/lib/Drupal/Core/Plugin/Factory/ContainerFactory.php(16): Drupal\Core\Plugin\DefaultPluginManager->getDefinition('search_view') #15 /opt/web/core/lib/Drupal/Component/Plugin/PluginManagerBase.php(83): Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('search_view', Array) #16 /opt/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(817): Drupal\Component\Plugin\PluginManagerBase->createInstance('search_view') #17 /opt/web/core/modules/views/src/Plugin/views/style/StylePluginBase.php(122): Drupal\views\Plugin\views\display\DisplayPluginBase->getPlugin('row') #18 /opt/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(820): Drupal\views\Plugin\views\style\StylePluginBase->init(Object(Drupal\views\ViewExecutable), Object(Drupal\views\Plugin\views\display\Page), Array) #19 /opt/web/core/modules/views/src/ViewExecutable.php(882): Drupal\views\Plugin\views\display\DisplayPluginBase->getPlugin('style') #20 /opt/web/core/modules/views/src/ViewExecutable.php(1842): Drupal\views\ViewExecutable->initStyle() #21 /opt/web/core/modules/views/src/Plugin/views/display/PathPluginBase.php(132): Drupal\views\ViewExecutable->getTitle() #22 /opt/web/core/modules/views/src/Plugin/views/display/Page.php(91): Drupal\views\Plugin\views\display\PathPluginBase->getRoute('dashboard', 'page_1') #23 /opt/web/core/modules/views/src/Plugin/views/display/PathPluginBase.php(220): Drupal\views\Plugin\views\display\Page->getRoute('dashboard', 'page_1') #24 /opt/web/core/modules/views/src/EventSubscriber/RouteSubscriber.php(120): Drupal\views\Plugin\views\display\PathPluginBase->collectRoutes(Object(Symfony\Component\Routing\RouteCollection)) #25 [internal function]: Drupal\views\EventSubscriber\RouteSubscriber->routes() #26 /opt/web/core/lib/Drupal/Core/Routing/RouteBuilder.php(146): call_user_func(Array) #27 /opt/web/core/lib/Drupal/Core/ProxyClass/Routing/RouteBuilder.php(83): Drupal\Core\Routing\RouteBuilder->rebuild() #28 /opt/web/core/includes/common.inc(1170): Drupal\Core\ProxyClass\Routing\RouteBuilder->rebuild() #29 /opt/web/core/includes/utility.inc(52): drupal_flush_all_caches() #30 phar:///usr/bin/drush/commands/core/cache.drush.inc(302): drupal_rebuild(Object(Composer\Autoload\ClassLoader), Object(Symfony\Component\HttpFoundation\Request)) #31 phar:///usr/bin/drush/includes/command.inc(422): drush_cache_rebuild() #32 phar:///usr/bin/drush/includes/command.inc(231): _drush_invoke_hooks(Array, Array) #33 phar:///usr/bin/drush/includes/command.inc(199): drush_command() #34 phar:///usr/bin/drush/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch(Array) #35 phar:///usr/bin/drush/includes/preflight.inc(66): Drush\Boot\BaseBoot->bootstrap_and_dispatch() #36 phar:///usr/bin/drush/includes/startup.inc(465): drush_main() #37 phar:///usr/bin/drush/includes/startup.inc(369): drush_run_main(false, '/', 'Phar detected. ...') #38 phar:///usr/bin/drush/drush(114): drush_startup(Array) #39 /usr/bin/drush(10): require('phar:///usr/bin...') #40 {main}.

NOTE: A review of the issue queue and multiple efforts to search via Google did not turn up any relevant results to my issue. All issues that came up regarding this were from years ago and not relevant to unsupported operand types.

Running PHP 5.5.14 with Drupal 8 locally. Requirements state PHP 5.5.9 and above so I should be covered. I was receiving the below fatal error after migrating a site from D6 to D8. Sorry I don't have exact steps to reproduce, but I think the issue is a pretty clear one just reviewing the code.

Fatal error: Unsupported operand types in /Users/jessenicola/projects/jessenicola.com/docroot/core/lib/Drupal/Core/Utility/LinkGenerator.php on line 153

The code on line 153:
$attributes = array('href' => '') + $variables['options']['attributes'];

As you can see, it's trying to bring two arrays together just using +, when array merge seems to really be the correct way of accomplishing this.

This code resolves the issue for me:
$attributes = array_merge(array('href' => ''), $variables['options']['attributes']);

Steps to reproduce are rather prohibitive for the casual issue queue goer, but are as follows:

1. Create a Drupal 6 site.
2. Use CCK, and link modules.
3. Create a content type with links.
4. Create content with links (Devel generate is advised).
5. Port site from D6 to D8.
6. Attempt to view content, enjoy fatal error.

Problem

When I use the domain_access module, I can restrict the access for content editing to only people which are assigned to the proper domains. But, the content translate functionality is still not restricted. So even if I can choose to let an editor to edit or not a node on his domains, I cannot choose to let the user translate or not that content.

Solution proposal

The domain_access module could expose special permissions for content translation: "Translate any content on assigned domains" and "%type_name: Translate any content on assigned domains".

Problem/Motivation

Since we don't support PHP5 #3053363: Remove support for PHP 5 in Drupal 8.8 we no longer need to maintain \Drupal\Component\Utility\Crypt::hashEquals()

Proposed resolution

Deprecate the method for removal in Drupal 9.

Remaining tasks

Create change record
Add @deprecated to docblock
Add @trigger_error() to code
Remove all usages in core
Add legacy test to ensure we don;t break it for the remainder of Drupal 8 lifetime.

User interface changes

None

API changes

\Drupal\Component\Utility\Crypt::hashEquals() is deprecated

Data model changes

None

Release notes snippet

N/a

Problem/Motivation

If you don't want to translate your URL alias, the original URL alias won't work with your translations.

Steps to reproduce:

1. Install with standard
2. Enable language and content translation.
3. Add a language (e.g. Spanish)
4. Go to content translation settings and enable article translations. Uncheck the URL alias field.
5. Create a node, assign an URL alias in the form (e.g. /my-alias)
6. Translate the node. The URL alias is prepopulated with your source alias (e.g. /my-alias).
7. Submit the form.

Current outcome:
In the alias list, you have (/my-alias, EN).
Going to /es/my-alias gives a 404.

Expected outcome:
In the alias list, you should have (/my-alias, UND).
Going to /es/my-alias gives a 200 and displays the Spanish translation.

Proposed resolution

• If the entity OR the path field are not translatable, save the path alias with the langcode 'und'.
• If the entity AND the path field are translatable, save the path alias with the langcode of the entity (or translation).

Remaining tasks

• Agree on proposed resolution
• Review

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

The default action on /admin/content is "Delete selected content". It's really easy to push "Apply" button by mistake, thinking it will apply the filter, because of the button title, and because it's positioned at the bottom of the form, typically where people expect to look for submit buttons. (This actually happened to me today, and I've been using Drupal for 8 years.)

Proposed resolution

• Use the D7 sort order (#3)
• Make the default action something safer (or make the default a no-op).
• Change the "Apply" button back to "Update" (like D7), "Execute", or even something action specific ("Delete").

Proposed alternatives

Alternatives for order of operations. The first operation in a list is the default.

Alternative 1: D7-like

• Publish content
• Unpublish content
• Promote content to front page
• Remove content from front page
• Make content sticky
• Make content unsticky
• Delete content
• Save content

Variation: Unpublish as default, by swapping Publish and Unpublish. This has the same Cons. For consistency the other operation pairs should also be swapped.

Alternative 2: Safe default

• - None -
• Publish content
• Unpublish content
• Delete content
• Save content
• Promote content to front page
• Remove content from front page
• Make content sticky
• Make content unsticky

Variation: Place Delete and Save at the bottom of the list as in D7.

Alternative 3: Safe first

• Make content sticky
• Make content unsticky
• Promote content to front page
• Remove content from front page
• Publish content
• Unpublish content
• Delete content
• Save content

Variation: Use Promote/Demote as first operation pair.

Remaining tasks

• Implement the suggestion in Comment #75
• Fix the failing tests: see Comment #72
• Make follow-up to delete the Save content option

User interface changes

Yes!

API changes

N/A

Problem/Motivation

Drupal.behaviors.dialog.prepareDialogButtons contains the following code:

// Hidden form buttons need special attention. For browser consistency,
        // the button needs to be "visible" in order to have the enter key fire
        // the form submit event. So instead of a simple "hide" or
        // "display: none", we set its dimensions to zero.
        // See http://mattsnider.com/how-forms-submit-when-pressing-enter/
        const $originalButton = $(this).css({
          display: 'block',
          width: 0,
          height: 0,
          padding: 0,
          border: 0,
          overflow: 'hidden',
        });

This is the inline css variant of the visually-hidden class.

Proposed resolution

Use the visually-hidden class to visually hide the buttons, so the css can be overridden by themes.

Remaining tasks

1. Write a patch
2. Review
3. Commit

User interface changes

None.

API changes

None.

Data model changes

None.

Hoping to upgrade from MariaDB 10.1 to 10.3. Is MariaDB 10.3 fully supported?

Also I am using a WHM VPS. Has anyone successfully just upgraded from MariaDB 10.1 to 10.3 from with WHM?

MariaDB 10.3 has some changes related to MySQL Strict Mode.

My site is showing me an error message after which i updated it and reconfigured the settings.php and default.settings.php
I also deleted the users and recreated a new user.
This is my error message below
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'afriwalldb.semaphore' doesn't exist: SELECT expire, value FROM {semaphore} WHERE name = :name; Array ( [:name] => variable_init ) in lock_may_be_available() (line 167 of /home/f4ix35tnppps/public_html/includes/lock.inc).

I upgraded manually on our development system which is running ubuntu 16.04 & PHP 7.0.33 with no errors.
When I upgraded manually on our test system which is running CentOS 6.6 & PHP 5.3.3 I received this error

Fatal error: Interface 'TYPO3\PharStreamWrapper\Collectable' not found in /var/www/html/misc/typo3/phar-stream-wrapper/src/Resolver/PharInvocationCollection.php on line 17

Thanks for any help