Custom Icon Size for map not working?
Closed this issue · 12 comments
So im trying to build a map with custom styles, and a custom icon graphic. In js it would be something like this
var myIcon = {
url: "/images/map-pin.png",
scaledSize: new google.maps.Size(20,30)
};
map.setOptions({icon:myIcon})
its the "scaledSize" property. Im able to get it to load a custom url but no real way to load a custom size on the marker?
this is what i have now
{% if entry.map %}
{{ craft.googleMaps.data('map', entry.map, { fitBounds: false }) }}
{% set markers = entry.map.markers() %}
{% set marker = {
content: entry.place,
lat: markers[0].lat,
lng: markers[0].lng,
fitBounds: false,
options: {
icon: {
url: "/images/map-pin.png",
scaledSize: [20,30]
}
}
} %}
{{ craft.googleMaps.marker('map', marker) }}
{{ craft.googleMaps.center('map', markers[0].lat, markers[0].lng) }}
everything besides the scaled size works fine.
Should i just do this part from javascript?
I should not i also tried it using the options on the marker data object
https://github.com/objectivehtml/Google-Maps-for-Craft/wiki/Template-Reference#data
which seemed to let me set iconSize but not iconUrl?
I am going to look into this and possible rework this a little bit. I don't like these arbitrary parameters without the ability to fully override everything as you would with pure JS. I will definitely get a solution to this, but will most likely break the existing API (which is exactly why this software is still beta).
I didn't publish the new code as a release, but your code should work now. I added the ability to define a size or scaledSize in the exact same syntax you posted. You can even define it using the craft.googleMaps.data
method too. If you don't define a url, the marker url you have assigned in the FT is used, and if no url is assigned at all, the default marker is used.
Let me know if this works for you. Just download the latest master branch and update the add-on with the latest code.
{{ craft.googleMaps.data('map', entry.yourMapField, {
markerOptions: {
icon: {
scaledSize: [24, 24]
}
}
}) }}
Great! will give it a shot later this week.
I didnt know you could set up a marker graphic at the field level? where do i set that?
Oh i see,
But there isn’t a way to to set a default icon for an entire field, i.e. that all the entries using that field would default to the same icon graphic
—
Keith Mancuso
Familiar
O: (646) 678-3731
M: (646) 256-3982
On Mon, Nov 10, 2014 at 12:15 PM, Justin Kimbrell
notifications@github.com wrote:
The custom marker icon has been supported since the early builds of the plugin. But last night I added the ability for users to define a scaled width/height to each marker individually in the FT, and the ability to override or define one in the template. Here are some screenshots.
Reply to this email directly or view it on GitHub:
#18 (comment)
Not currently, but I think that would be a good default setting to add to the FT setup screen. So I will add a new setting "Default Marker Icon", allow you to select an image. And you will be able to optionally define a default scaled width/height too.
Does that sound like a good solution to you?
yea that would be perfect for our needs
—
Keith Mancuso
Familiar
O: (646) 678-3731
M: (646) 256-3982
On Mon, Nov 10, 2014 at 5:57 PM, Justin Kimbrell notifications@github.com
wrote:
Not currently, but I think that would be a good default setting to add to the FT setup screen. So I will add a new setting "Default Marker Icon", allow you to select an image. And you will be able to optionally define a default scaled width/height too.
Does that sound like a good solution to you?
Reply to this email directly or view it on GitHub:
#18 (comment)
not to ask for the world but it would be similarly helpful to set the default “styles” the styles is basically just a big block of son with color settings and it our case we want all of our event detail pages to show a little map of where they are..
so we want them all to have the same style and icon.
Not picturing a really complicated custom styling tool but a way to just copy and past some json style settings along with the custom icon at the field type level
—
Keith Mancuso
Familiar
O: (646) 678-3731
M: (646) 256-3982
On Mon, Nov 10, 2014 at 5:57 PM, Justin Kimbrell notifications@github.com
wrote:
Not currently, but I think that would be a good default setting to add to the FT setup screen. So I will add a new setting "Default Marker Icon", allow you to select an image. And you will be able to optionally define a default scaled width/height too.
Does that sound like a good solution to you?
Reply to this email directly or view it on GitHub:
#18 (comment)
Are you talking about the JSON object to alter the map's styles? You can already add that JSON to the template, is this not ideal?
Hmm yea i guess its best to keep it in the template, just feels strange to
set the icon in one place and the styles in the other since they seem so
similar.
On Mon Nov 10 2014 at 6:07:19 PM Justin Kimbrell notifications@github.com
wrote:
Are you talking about the JSON object to alter the map's styles? You can
already add that JSON to the template, is this not ideal?—
Reply to this email directly or view it on GitHub
#18 (comment)
.
Well in this case, technically it's two entirely different things. In the field type, the user is merely plotting data – telling the CMS what content to display on the front-end. The map on the template is in no way generated by the field type (hence the craft.googleMaps.map
tag). So in concept, just like the EE version, the map on the front-end is created and displayed independently of the field type. That's my logic anyway.
You could for example, have multiple maps on the same page and feed different data to each of them with various sections of content. The way it's setup, it gives maximum flexibility and control to developers. I could perhaps see some sort of global config option to automatically set the map styles if you are outputting those maps on various pages. But even in this case, one could make the argument for a Twig macro or include to keep things DRY without having to include this in the core.
(My only reservation for including anything in the core is to keep the code as clean as possible for the future iterations.)