Thanks @constantin.raicovici
I’ll test it and let you know how I get on.
S
Hi @shaneholohan,
Just following up to check if you had a chance to test the update with version 1.60.0 and how it worked out on your side.
Best regards,
Support Team
Browse all Zeroqode Plugins for bubble
HI @constantin.raicovici
I haven’t had a chance to test it yet. It’s on the todo list! I"ll get back to you once I have.
Thanks
Shane
Hi @shaneholohan ,
Thanks for letting us know - no worries at all. We completely understand that it’s on your to-do list and really appreciate you keeping us updated.
Once you’ve had a chance to test it, just drop us a message and we’ll be happy to continue from there.
Looking forward to your feedback when the time comes.
Best regards,
Support Team
Browse all Zeroqode Plugins for bubble
Hi @constantin.raicovici
I upgraded and it threw a load of errors. Now anything that’s looking for the “last clicked marker” is looking for a text, while at the same time the Map Extender element has a field where the marker type needs to be specified and this requires a data type with a geographic address to function. I’ve attached screen grabs, but I quickly went back to the savepoint before I upgraded the plugin. Unless I’ve misunderstood something the change your team have made won’t work.
Shane
Hi @shaneholohan hane,
Thanks for giving this a try and for sharing the screenshots - they make things much clearer.
Since version 1.60.0 changes the Last Clicked Marker to return a text value (instead of a Thing), the workflows that expect a geographic type are running into conflicts. This update was meant to ensure custom markers always return something, but it does require a slightly different setup.
Could you clarify a bit more about your end goal? For example:
- Do you primarily need to capture the geographic location from the clicked marker?
- Or do you need to retrieve a Thing (e.g., your database object) directly from the clicked marker?
Depending on your use case, here are a couple of approaches that might work with the new version:
- Save your Thing’s unique_id or another unique reference into the marker title, then use the text returned by
Last Clicked Markerto “Do a search for” and fetch the full Thing. - If you need geographic data, you could store the coordinates as part of the marker’s identifying text and then parse that to retrieve the location.
This way, even though the state is now text, you can still reconstruct either the Thing or the location as needed.
Would you mind letting us know which of these scenarios fits your workflow best?
Happy to help you further!
Best regards,
Support Team
Browse all Zeroqode Plugins for bubble
Hi @constantin.raicovici
Thanks for getting back to me on this. First let me explain my understanding of how the plugin works, because this explains why the current update has actually broken the plugin’s core functionality.
The MapExtender element requires the marker type to be defined. It can be any database type as long as it includes a field that is a geographic address- in my case this is called a 'WaypointOnly"
Adding pins to a map then works by the workflow sending a list of these datatypes to the MapExtender - note the warning in the documentation that the tuypes must match the type set in the MapExtender element.
Then when a pin is clicked the LastClickedMarker state returns the database object associated with the pin so it can be used - like this:
By changing this to return a text this fundamental process no longer works, which is why I downgraded to the previous version and why I strongly suggest you withdraw this update as anyone else using the plugin will be wondering why their app has stopped working!!!
Now to turn to how Custom Pins work and how they could work.
A custom pin is added using a different action with different options to a standard pin.
Note that there is no option to attach a database type to a Custom Pin. I can send data to it, but the source data object is not attached to the pin.
However I can create a workflow that is triggered by the clicking of a Custom Pin (and which is actually triggered in testing) but which doesn’t return anything (the LastClickedMarker state is empty).
I see two solutions to this that you could implement both of which require the ability to reference a database object in the action that creates the Custom Pin (mirroring what you do for a standard pin) and then either:
- make this database object available through the LastClickedMarker state in exactly the same way as with a standard pin.
- create a new “WhenCustomPinClicked” workflow action that can expose the database object.
The first of these is more seamless, the second more flexible. Either would work for me, but returning a text doesn’t work at all. You could implement returning a text as a workable solution if it only applied to clicking custom pins, but the necessary searching would be cumbersome.
Hope that all makes sense. I’m happy to jump on a zoom to discuss it further if that’s helpful.
Shane
Hi @shaneholohan,
Really appreciate the time you took to outline your full setup and the implications of the recent change - the explanation makes perfect sense and helps us understand exactly how this affects plugin usage.
We’ll bring this feedback directly to the dev team and highlight the importance of reverting or adjusting the update so that it doesn’t break current apps, while also exploring your suggestions for handling custom markers properly.
Thanks again for the detailed breakdown - it’s extremely helpful.
We’ll circle back to you as soon as the team provides a direction on this.
Best regards,
Support Team
Browse all Zeroqode Plugins for bubble
Hi @shaneholohan,
Thanks again for your patience while we looked into this.
The dev team has provided an update regarding the Last Clicked Marker state.
In the latest version, this state now returns only the marker’s unique ID instead of the full marker data. The idea behind this change is that the user can now perform a search in the database using this ID to retrieve the full marker details.
Here’s the workflow update:
- In workflows, you can use the ID returned by the Last Clicked Marker state to perform a “Do a search for” on your database, looking for the marker where the ID equals the returned ID. This will give you the full object with all marker details.
Advantages:
- This method is fast, reliable, and doesn’t require a complex data structure.
- It’s fully compatible with all Bubble functionalities, making it easier for users to implement.
We hope this clears up the confusion! Please let us know how it works on your end after making these adjustments.
Best regards,
Support Team
Browse all Zeroqode Plugins for bubble
Hi @constantin.raicovici
Thanks for getting back to me on this so quickly. I’ve tested the update - which is still 1.160.0, so I’m unsure if another update has been pushed today or if you’re just clarifying what this update does.
Either way, it’s not working as you suggest. I’ve rebuilt a workflow to search for the DB item as you suggested using the text returned as “Last Clicked Marker”
Then I ran a test. You can see that the DB item’s UID is loaded into the Title Marker field here:
But when the pin is clicked the text returned (27170831097) is not related to the UID loaded at all (it’s not the ID of anything) and as a result the DB item is not found.
And if even if this did work I’d still have 14 other workflows to rebuild that use standard pins which no longer work with this change.
I completely understand that changing the last clicked marker state to text seems like a quick solution to this but it really isn’t. If you update your own demo page for the plugin to this new version you’ll see the scale of the problems it creates to pre-existing workflows.
The way I see this is there is a basic contradiction between how standard pins and custom pins are handled by the plugin.
A standard pin has a data type which is captured by the Pin Clicked action in the last clicked pin state - nice and simple.
A custom pin for (some inexplicable reason) doesn’t have an associated data type, but clicks are triggering the Pin Clicked Action, even though the Last Clicked Pin state is receiving nothing (or a number that appears unrelated). So what’s required is a complete process for Custom Pins from adding them, to clicking them, to subsequent workflow actions. I suggest, humbly, that if your team added an optional data source to the creation of a custom pin, which is captured in the Last Clicked Pin state (or a new state) then consistency could be maintained across both types of pins, without disrupting existing workflows for existing apps.
Hopefully this is helpful
Shane
Hi @constantin.raicovici
Just giving this another nudge. Is there any update from your team on my last response?
Thanks
Shane
Hi @shaneholohan !
Thank you for your patience while our devs were looking into this.
Just to clarify your use case: If the item doesn’t yet exist in the database, but you still want to perform some searches or actions with it, would it not work for you to first create the item in the database and then add the marker to the map (so that you have a Bubble Unique ID for your searches)?
Of course, we can consider adding a “Unique ID” field for the “custom marker” action, but we want to make sure this is exactly what you need and that the first solution (creating the DB object first) is not an option for your use case.
Let us know a bit more about your workflow and we’ll do our best to find the most flexible solution!
Regards,
Support Team
Browse all Zeroqode Plugins for bubble
Hi @constantin.raicovici
Thanks for getting back to me.
To clarify my use case the item I want to work with in the database does exist. But the problem I have is that when I create a custom marker, I first find the item in the database, then I extract the latitude and longitude from that item and use them to create the custom marker. That process works perfectly fine. The issue is that when a user clicks on a marker, specifically a custom marker, there is no way for me to return the database object that I used to create the custom marker in the first place.
The way a regular pin works makes perfect sense. The database object is used to create the pin clicking the pin returns that database object.
So to answer your question adding a unique ID field to the custom marker action is exactly what I need, as long as clicking on that marker returns that unique ID. Then everything will be consistent and I won’t need to rewrite existing workflows for standard pins.
Thanks.
Shane
Hi @shaneholohan ,
Good news - the Map Extender plugin has just been updated and published to version 1.61.0 
This release includes a new Marker ID field that should help your use case.
Please go ahead and update the plugin in your app to this latest version and give it a try.
Let us know how it works out for you or if you have any further questions - we’re here to help. 
Best regards,
Support Team
Browse all Zeroqode Plugins for bubble
Thanks @constantin.raicovici
That’s great news. I’ll upgrade to the new version and I’ll let you know how I get on.
Shane
Hi @constantin.raicovici
I ran a test with the new update and I’m afraid to say this is still not a workable solution. When I upgraded to the new version of the plug-in, I got an increased number of errors - up to 23 from 14. All these arise because the plug-in is now looking for any reference to a marker to be a text rather than a database type, as I’ve said before, I think this change is a very bad idea because it breaks everything that has been coded previously by any of the users of this plug-in if they have workflows based on clicking markers.
The test that I ran didn’t even look at custom markers. I simply attempted to rebuild one marker click workflow to see if it would work with this new approach. I’ve attached screen grabs so you can understand what I’ve done but the core of the problem is that with the ad a list of markers workflow there is now a Field asking for a marker ID, as you said there would be. But it asks for a single marker ID text when adding a list of markers to a map. in my test I put in a dynamic formula The generated a list of unique ideas for the database items of each marker, hoping that each item on the list would be aligned with each marker but as you will see in the screen grabs that is not the case. when you click on a single marker, you get all the IDs. So there is no way to show the correct database item.
So to go back to an earlier post I made in this thread I believe the issue is this: in version 59 of the plug-in, and all previous versions as far as I know, the last marker clicked action stores a state and that state is the database item associated with the marker. You should go back to this. Changing the marker type to text is a disaster.
The issue I’ve been consistently raising is that there isn’t an equivalent workflow for custom markers. I strongly suggest your dev team go back to version 59 for normal markers. The plug-in page says there are over 800 apps using this plug-in. That’s 800 apps with workflows that will need to be rebuilt if you don’t do this. I’ve said this before, but you don’t seem to be grasping the reality of this. If I was one of those other customers and I updated the plug-in without realising that this was the consequence, I’d be very unhappy.
While I don’t pretend to understand the process of building a plug-in as I’m not myself a coder, I can see that separating the behaviour of custom markers from regular markers will make it easier to fix this. Custom pins are currently added one at a time so adding a marker ID Field (text) to a custom marker seems like a good step. But in order to return that marker ID when a custom pin is clicked, I think the simplest solution is to have a new action that is triggered when a custom marker is clicked that delivers a new state “last custom marker clicked”. That state can be a text that is used to search for the corresponding database item.
For now, I will continue to use version 59 of the plug-in. This leaves me unable to implement custom markers.
Can you please review the thoughts above and get back to me? We seem to be going around in circles so I suggest a zoom might be a quicker way to get to the bottom of all this. Let me know if that works for you.
Thanks
Shane
Hi @shaneholohan ,
Thank you again for your detailed feedback! 
I’ve shared the information you provided with our dev team, and I’m doing my best to clearly explain your point of view and the issues you’ve encountered with Map Extender v1.61.0.
We’ll be looking into the matter closely and will get back to you with a more complete response as soon as we have an update.
Thanks for your patience!
Best regards,
Support Team
Browse all Zeroqode Plugins for bubble
Hi @constantin.raicovici
If you want to reproduce the issues I’m having with the update I suggest the following:
On your own demo page, create a new dev branch, update to the latest plugin. You’ll see any workflows triggered by the Last Marker Clicked action no longer work - you’ll get errors on the error checker.
Create a workflow that uses the “add a list of markers” workflow - you’ll see that the MarkerID field doesn’t make sense because it is the same for every added marker. To be different for each marker it needs to be a field in a DB item, for example like the field for “icon”
To further see this, check what the “Last Marker Clicked” state returns when one of the list of added markers is clicked.
This is all to show why simply changing the marker type to text produces contradictory results.
Because the Add Custom Marker action works one marker at a time, the marker ID field could work for those markers, but that’s no use if the Add List of Markers is broken as a side effect.
Hopefully this will help your team understand why the approach in version 60 and 61 can’t work.
Shane
Hi @shaneholohan ,
Thanks for sharing the detailed feedback and for your patience!
I will be stepping in this thread to provide an update. We’ve updated the single marker logic so the Marker ID property is now mandatory.
Additionally, we’ve implemented checks that will separate and return only the clicked marker when using the “Add a List of Markers” action. The new version with these fixes should be pushed live tomorrow.
I’ve also recreated the same setup you’ve described and confirmed that the Custom Marker action is working correctly. Please refer to this Loom Video.
Each ID is now set with the one from the Marker ID field. This update will also allow users to have different fields in their DB that can contain the ID and use them when creating markers.
Please let us know if everything works as expected after the update. Appreciate your collaboration and patience!
Best regards,
Support Team
Browse all Zeroqode Plugins for bubble
Thanks @mina.rotari
I’ll try that out over the coming days. There’s a fair bit of rebuilding wfs on my end due to the change to ‘text’ as the marker’s type, but if it all works then it may be worth the effort.
Shane