dmudie β created an issue.
dmudie β created an issue.
I found that I needed an "is-active" class on links (the anchor) for Bootstrap 5 if the item (the list item) is in the active trail. I achieved this in a custom template for the menu like so:
{% if item.in_active_trail %}
{{ link(item.title, item.url, menu_attributes|merge({'class': 'is-active'})) }}
{% else %}
{{ link(item.title, item.url, menu_attributes) }}
{% endif %}
Just adding this comment here in case it helps someone.
Is there a plan to merge this since it's RTBC?
dmudie β created an issue.
After trial and error I was able to generate the linestring by changing the points to:
'points' => [['lat' => $lat1,'lon' => $lng1],['lat' => $lat2,'lon' => $lng2]],
So in case anyone else sees this, you need lat and lon keys in there.
dmudie β created an issue.
Thanks @itamair, that screenshot helped and it's working great now.
dmudie β created an issue.
@EHLOVader when I try to install with the issue fork I get:
Problem 1
- cloudflare/sdk[1.0.0, ..., 1.1.6] require guzzlehttp/guzzle ^6.2.2 -> found guzzlehttp/guzzle[6.2.2, ..., 6.5.8] but the package is fixed to 7.8.1 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
- cloudflare/sdk[1.1.7, ..., 1.3.0] require psr/http-message ~1.0 -> found psr/http-message[1.0, 1.0.1, 1.1] but the package is fixed to 2.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
Note that there are more issues with a Drupal 10.2 install at this point, including requiring cloudflare SDK which in turn requires guzzlehttp/guzzle ^6.2.2. Not that this issue shouldn't be merged but maybe it explains the delay?
@jhuhta. Bummer. Any contrib modules thats might act on a user_insert? How about a hook_entity_create? Is the drupal log showing anything?
dmudie β created an issue.
Since this has been RTBC for a while, could a maintainer please comment on the delay? Thanks in advance.
dmudie β created an issue.
This change is working fine for me on my dev Drupal 10 site also.
Any chance of getting something like this in views so we don't have to hack core?
Thanks a ton @itamair. Works perfectly.
dmudie β created an issue.
Thank you @cbeier! I can confirm that map points do render now with a ZoomControl Position defined. I appreciate the help.
The problem persists on 10.0.15. Still no points loading on a map configured with mymodule_leaflet_map_info in a custom module.
I edited my test to get rid of 'leaflet_map_get_info' and called from the service instead:
$gmap = \Drupal::service('leaflet.service')->leafletMapGetInfo('mymodule_map');
However, same result. No points on the map.
Inspecting the returned arrays of the doesn't reveal anything to me either:
This works:
array:4 [βΌ
"label" => "OSM Mapnik"
"description" => TranslatableMarkup {#420 βΌ
#string: "Leaflet default map."
#arguments: []
#translatedMarkup: null
#options: []
#stringTranslation: null
}
"settings" => array:11 [βΌ
"dragging" => true
"touchZoom" => true
"scrollWheelZoom" => true
"doubleClickZoom" => true
"zoomControl" => true
"zoomControlPosition" => "topleft"
"attributionControl" => true
"trackResize" => true
"fadeAnimation" => true
"zoomAnimation" => true
"closePopupOnClick" => true
]
"layers" => array:1 [βΌ
"earth" => array:2 [βΌ
"urlTemplate" => "//{s}.tile.openstreetmap.org/{z}/{x}/{y}.png"
"options" => array:1 [βΆ]
]
]
]
This does not:
array:5 [βΌ
"label" => "Mymap"
"description" => TranslatableMarkup {#401 βΌ
#string: "This is the custom map style."
#arguments: []
#translatedMarkup: null
#options: []
#stringTranslation: null
}
"settings" => array:15 [βΌ
"dragging" => true
"touchZoom" => true
"scrollWheelZoom" => true
"doubleClickZoom" => true
"zoomControl" => true
"attributionControl" => true
"trackResize" => true
"fadeAnimation" => true
"zoomAnimation" => true
"closePopupOnClick" => true
"minZoom" => 1
"maxZoom" => 18
"zoom" => 2
"layerControl" => true
"layerControlOptions" => array:1 [βΌ
"position" => "topright"
]
]
"layers" => array:1 [βΌ
"layer" => array:4 [βΌ
"type" => "sat"
"ext" => "jpg"
"urlTemplate" => "//server.arcgisonline.com/ArcGIS/rest/services/World_Street_Map/MapServer/tile/{z}/{y}/{x}"
"options" => array:2 [βΆ]
]
]
"plugins" => []
]
I created a simple test. Maybe something has changed in how custom map settings are retrieved?
controller:
/**
* Maptest
*/
public function maptestPage() {
$points = [];
$content['#title'] = t('Map Test');
$map_info = leaflet_map_get_info("mymodule_map");
$lat = '29.779860';
$lng = '-95.257426';
$points[] = array(
'type' => 'point',
'lat' => $lat,
'lon' => $lng,
);
$content['map'] = \Drupal::service('leaflet.service')->leafletRenderMap($map_info, $points, '480px');
return $content;
}
custom module:
function mymodule_leaflet_map_info() {
return [
'mymodule_map' => [
'label' => 'Mymap',
'description' => t('This is a custom map style.'),
'settings' => [
'dragging' => TRUE,
'touchZoom' => TRUE,
'scrollWheelZoom' => TRUE,
'doubleClickZoom' => TRUE,
'zoomControl' => TRUE,
'attributionControl' => TRUE,
'trackResize' => TRUE,
'fadeAnimation' => TRUE,
'zoomAnimation' => TRUE,
'closePopupOnClick' => TRUE,
'minZoom' => 1,
'maxZoom' => 18,
'zoom' => 2,
'layerControl' => TRUE,
'layerControlOptions' => [
'position' => 'topright',
],
],
'layers' => [
'layer' => [
'type' => 'sat',
'ext' => 'jpg',
'urlTemplate' => '//server.arcgisonline.com/ArcGIS/rest/services/World_Street_Map/MapServer/tile/{z}/{y}/{x}',
'options' => [
'attribution' => 'Map tiles © Esri',
'noWrap' => FALSE,
],
],
],
'plugins' => [],
],
];
}
I do not get any points on the map. There must be something with calling the custom map because when I use:
$settings['leaflet_map'] = 'OSM Mapnik';
$map_info = \Drupal::service('leaflet.service')->leafletMapGetInfo($settings['leaflet_map']);
instead of leaflet_map_get_info then the map renders. Thanks for your time.
Upgraded from the 2x version. I flushed cache. I'll try to work on a simple reproducible case since my custom map is anything but simple, but was working previously. As for the snarkiness, I do actually mind that nobody else reported this, but I'm hoping that someone might experience something similar, and 100% of problems have a first report. I'm not saying that it's a bug, but that seemed the best category since console is showing an error. It doesn't really fit "support request."
dmudie β created an issue.
Same issue here. After composer update (composer require 'drupal/blazy:^2.15'), blazy.info.yml still showed "version: 8.x-2.x"
Curious as to why it left the 8.x version.
I resolved by removing blazy module entirely then re-adding.
I ended up generating options like this but please comment if there is a better way. Thanks.
$term_options = [];
$terms = \Drupal::entityTypeManager()->getStorage('taxonomy_term')->loadTree('vid-name',0,NULL,TRUE);
foreach ($terms as $term) {
$termId = $term->id();
if($term->parent->target_id) {
$term_options[$termId] = new CshsOption($term->getName(),$term->parent->target_id);
} else {
$term_options[$termId] = new CshsOption($term->getName());
}
}
dmudie β created an issue.
Follow-up and resolution. Our hook_entity_insert from our custom module is causing an error in some cases and messing up the entity (in this case a new user). I say "some cases" because in our case we have a pool of servers that were not set up correctly. Namely, some recently added servers did not have access to an Oracle server that we hit at user creation time. When I take the entity_insert out of the equation, accounts are formed as normal. Interesting that an account is still created when hook_entity_insert encounters an error.
Some additional info if anybody encounters this in the future. I think our hook_entity_insert from our custom module is causing an error in some cases and messing up the entity (in this case a new user). I say "some cases" because in our case we have a pool of servers that were not set up correctly. Namely, some recently added servers did not have access to an Oracle server that we hit at user creation time. When I take the entity_insert out of the equation, accounts are formed as normal.
None of the newly provisioned "bad" accounts match an existing account (username or email address) so I haven't had the same experience. I had wondered something similar early on and searched for existing data in the users_field_data table.
dmudie β created an issue.
Note that updates to externalauth did not fix the issue. I have had 3 users auto-generated today. 2 were correctly saved as "username". One was incorrectly saved as "simplesamlphp_auth_username."
Current details:
simplesamlphp (library) 1.19.8
php 8.1.14
Drupal 9.5.4
External Auth 2.0.3
SimpleSAMLphp Authentication (module) 8.x-3.3
Any ideas? thanks.
I wonder if this is somehow related to: https://www.drupal.org/project/externalauth/issues/2910506 β
I just had composer update External Auth to v 2.0.3. My system never complained that 8.x-1.4 was out of date but it appears that the version 2.x is more recently updated so I'm going to use that instead.
dmudie β created an issue.
After some digging/testing, it seems that grouping by two fields this way:
->groupBy('sc.field_school_college_target_id, tfd.name');
no longer works but if I isolate each field like this:
->groupBy('sc.field_school_college_target_id')
->groupBy('tfd.name');
it works.
Maybe this will help someone else.