#ContributionWeekend2020

There needs to be at least an item in the README file and preferably a config form.

@cmlara Very interesting article. I had no idea WordPress did that. I definitely agree that Drupal should only collect what it needs. I think that if users are given more granular control over which data is sent, they are more likely to allow it.

https://duanestorey.com/posts/down-the-rabbit-hole-a-deep-look-at-the-wo... is likely worth a read as it relates to Wordpress and the recent concern that Wordpress.org may have used telemetry data for less than ideal purposes (the Wordpress Engine Tracker site) raising questions about data collection in general by a CMS.

There is a lot of talk in this issue about collecting random data on a whim of someone had the idea it would be useful.

I would suggest that if this initiative ever does go forward that the first question asked regarding any data point should be "what problem will this solve in the next 3-6 months?" if you can not identify a specific concrete problem that can not be solved without the data point the collection is questionable.

I note this in other issues, even the collection of a site specific ID is enough to cause Update Manager to be disabled in many environments I work with. In general, the more data collection you add the less likely users are to be willing to share it.

Hrm, looks like I still need this patch, so here is a re-roll for D11.1.1 that adds the `use` statement just to get past this error.

In general this patch needs more work to deal with the changes to how core is handling hooks as per #3483599 where the views.module file was refactored.

NOTE that in 11.1.x, the line in views.module:

use Drupal\Core\Entity\EntityInterface;

was removed. So the hooks added via this issue patch cause a problem because the autoloader doesn't resolve the class properly. In the hook:

function views_block_update(EntityInterface $entity) {

when a `Drupal\block\Entity\Block` entity is passed to the hook, it gives an error:

TypeError: views_block_update(): Argument #1 ($entity) must be of type EntityInterface, Drupal\block\Entity\Block given in views_block_update() (line 482 of /var/www/docroot/core/modules/views/views.module).

This happens when you try to do a clean install of any profile that contains config for blocks.

I don't have a real chance to test this patch or update it at the moment, but at least the `use` statement needs to be re-added to the top of views.module file.

@capysara: Excerpts are already created without any HTML (except for the highlighting tags, of course) by the Highlight processor, so there is nothing more to display for the view. By switching to “Do not allow HTML” you could just make the <strong> tags (or whatever you have configured) around matches visible.

If you want HTML preserved inside the excerpt you’ll need to implement your own code for creating the it and use that instead of the Highlight processor.