Issue fork patch
Patch file
Adding patch while waiting for the MR.
omahm → created an issue.
The issue with the namespaces has been fixed.
@hestenet that's great and I really appreciate you cleaning up the namespaces.
Uploaded patch of changes in fork
I'm afraid so. I've raised a ticket with the infrastructure team ( https://www.drupal.org/project/project_composer/issues/3447445 💬 Request to clean up published_state_indicator namespace Active ) regarding the namespacing issue this project is experiencing. I'd recommend following/commenting on that issue.
I created a new project using the full name as the short name but now the releases use both as the composer package name.
composer require 'drupal/published_state_indicator-published_state_indicator:^1.0'
What is going on?
There is a release but nobody is using it because I just created it and realised the short name was used.
The issue with creating another project is that I cannot now use that project name as it's taken.
Many thanks Christian,
I created a 4.x branch for
https://www.drupal.org/project/geolocation/issues/3423933
📌
google.maps.Marker is deprecated
Active
and updated some of the JS and node package requirements but it's still not working. Do you know when you'll get a chance to look at this as it affects the map marker settings?
Implemented IntersectionObserver to delay loading of maps until visible in the browser with Threshold option as part of the display settings.
This is working but the map is zoomed out (same with the custom and button options) and I suspect this is due to the google.maps.Marker is deprecated 📌 google.maps.Marker is deprecated Active issue.
Wow, thanks for the speedy resolution Christian.
Thanks @Kasey_MK I had to roll out another quick release to fix some issues when the scan command ran.
I'm angling towards a new V3 release for entity scanning with the plan to provide plugin support to allow people to roll their own indexing features. I don't have a release timeframe for this (probably won't be for a while) as I'm pretty much starting from scratch and I'm still defining the architecture for how this will work but I've some proof of concept code in progress.
I'm working on getting this patch into the current dev version and then into a new release.
It's taking a bit longer than I hoped as I'm having to do a quite a bit of testing and fixing any issues.
Merged into dev. Thanks all.
Fixed with solr config export.
I have the same issue with a custom access handler that extends NodeAccessControlHandler. The custom handler restricts create access to certain content types and this works when viewing /node/add, but the content types still appear in the admin toolbar Content -> add dropdown.
Spend 30 mins wondering why 'homepage editor' wouldn't work in the _role requirements. The documentation makes no mention that you need to use the machine name of the role.
Fixed for both release, thanks Noah.
The priority order is a good idea but I still think it'd be better to have the dropdown to select the Domain and the rational is that you'd need to log into each individual domain to save the config for each. Given that the dropdown will only appear if you have the Domain module installed I don't think it'll inconvenience the majority of users of this module.
Yeah, the Domain dropdown only appears if you check the 'Enable Domain support for favicons' (see the attached file) and that checkbox only appears if the Domain module is installed. I made that optional as I figured some multi-domain installs will share the same favicons across all domains.
When you select a Domain, it appends the id onto the end of the 'Path to responsive favicon files' and that's the functionality that I'd really like some input into as it's only way I could get this to work without altering the module config schema.
The attached Gif animation is how I'd like to present the required sub-dir options, you can use the domain id or if that is undesirable, then a custom dir. To provide this I'd need to add some additional entries into the module schema.
I've done some initial work on this.
The changes are the addition of a select element from which to choose your Domain. From that the upload path will have the Domain id appended to it to ensure there is a unique favicons directory for each Domain. Config is stored on a per Domain basis, this allows for variations on tags etc. Requests to favicons are rerouted based on the current Domain to each unique favicon directory.
Still some work to do on this but any thoughts are welcome.
#42 Patch works for me (9.5.5 PHP 8.1) for a site running the Domain module. One caveat is that if you have Twig debugging enabled the field comments will passed into fromURI() which isn't a problem on production sites.
InvalidArgumentException: The URI ' <!-- THEME DEBUG --> <!-- THEME HOOK: 'views_view_field' --> <!-- BEGIN OUTPUT from 'core/themes/stable/templates/views/views-view-field.html.twig' -->