Tested and can confirm it is working correctly in our environment.
This is breaking with custom forms that extend EntityForm. I'm not sure where this should be addressed, but this breaks the loading of the access_scheme forms for workbench_access.
Specifically this line, https://git.drupalcode.org/project/simple_sitemap/-/merge_requests/114/d...
I created the MR from the existing patch. I'm not sure I have time to dedicate to working on this issue. Does anyone have any suggestions for fixing this? I'm not sure just checking if the method getBundleEntityType exists is enough.
I get an error when I try to set a mimetype that has a '.' in it in config.
Drupal\Core\Config\ConfigValueException: application/vnd.ms-excel.addin.macroEnabled.12 key contains a dot which is not supported. in Drupal\Core\Config\ConfigBase->validateKeys() (line 209 of core/lib/Drupal/Core/Config/ConfigBase.php).
This appears to be happening in the filterFileMimeTypesOptions in the patch.
I don't know if this is the best approach, but could we change the '.' in the config key to something like a '_' instead so that the config can save?
private function filterFileMimeTypesOptions(array $types_allowed = [], $by_extension = TRUE) {
$all_file_types = $this->getAllFileMimeTypesOptions();
$mimetypes_key = preg_replace('/\./', '_', $all_file_types['mimetypes']);
if (empty($types_allowed)) {
$options = ['' => $this->t('- All types -')];
$options += array_combine($mimetypes_key, $all_file_types['mimetypes']);
return $options;
}
if ($by_extension) {
return $this->filterFileMimeTypesOptionsByExtension($all_file_types, $types_allowed);
}
return $this->filterFileMimeTypesOptionsByMimeType($all_file_types, $types_allowed);
}
vetchneons → created an issue.
Are the files managed in Drupal or these are just links pointing to files in disk that happen to be at these locations? If the files are not file entities in Drupal (ie in the file_managed table), then this module won't track them, by design.
That makes sense. I can confirm that this was the case for us. sites/default/files/<filepath> was tracking correctly, while sites/files/<filepath> was not.
I actually dug into this today and it turns out, in our environment, that the relative paths were tracking, but the absolute links were not.
return $this->pathValidator()->getUrlIfValidWithoutAccessCheck($url);
in the processUrl inside EntityUsageTrackBase.php was always returning false for file that were using absolute links in ckeditor. The same files using relative paths are getting counted correctly.
+1 as well. I have been doing the same thing the OP has been. I don't think most people are going to look at the source code to figure out how to best to configure the module.
Same issue here. I am looking into information on it.
This MR requires the patch that adds the media settings config from [Error "recursive rendering detected" when rendering media 20+ times]( https://www.drupal.org/project/drupal/issues/3151977#comment-15825683 🐛 Error "recursive rendering detected" when rendering media 20+ times Postponed ) to work correctly.
We're experiencing the same issue with the EntityEmbedFilter. It looks like the problem can also occur in EntityReferenceRevisionsEntityFormatter. I can create an MR to account for these classes.
vetchneons → made their first commit to this issue’s fork.
Patch #6 worked for me as well.
vetchneons → created an issue.
vetchneons → made their first commit to this issue’s fork.
vetchneons → created an issue.
Ignore my previous comment. For anyone else that was using the patch, and looking to upgrade to 10.3.1 from 10.2.x, this change was added to 10.3.0.
I am running into the same issue as @teknocat. The following patch fails for me when upgrading to 10.3.1:
https://git.drupalcode.org/project/drupal/-/commit/fcd17502ff4e0a3599022...
The phpcs extension by Ioannis Kappas is deprecated.
Makes sense!
In its current version, I think the simplest way to get this to work would be to focus on putting some logic into the .module file for the that works for the entity browser forms. Attached is a copy of a patch we used in our environment to get this to work with the media browser and media directories module. Full disclosure, this was a quick and dirty fix to get it working so that we could keep other plates spinning.
Hello @pcambra!
This module is absolutely still in development and we would be happy to have your help with it!
Right now, the module only works with media library and we were hoping to make it more flexible so that it will work with other module’s media forms. Another nice to have feature would be to have the image size validate when reusing media (e.g. prevent an image that has already been uploaded from being used on a field that does not pass the size restrictions set for it).
Do you have anything on your wish list for this module?
Thank you again for the help! :)
The patch in #4 has been updated to to use the lowercase "now" as the default field value so it works with the YearOnlyDefaultWidget 'now' check.
vetchneons → created an issue.
vetchneons → made their first commit to this issue’s fork.
vetchneons → made their first commit to this issue’s fork.
vetchneons → created an issue.
Is now fixed as part of the 2.0.0 branch.
Are there any plans to release a new stable version with this fix in it soon?