Use libraries api module for storing markers

I noticed this as well. I investigated the code base and found that some of the leg work for doing this is already done. GMap refers to a variable stored within variable_get called gmap_markerfiles. Storing it there makes it so that it can be configured and stored within drupal. To my dismay, the UI does not allow for the setting of this feature. I performed the following hack within my drupal theme to set my custom directory:

1. Created a local 'markers' directory within my theme
2. Created a sym link to the GMap markers directory within my themes 'markers' directory
3. Added the following lines of code to the top of my template.php
   

   if (is_null(variable_get('gmap_markerfiles', null))) {
       variable_set( 'gmap_markerfiles', 
           drupal_get_path('theme', 'boredco') . '/markers');
   }
       

4. Cleared my drupal installations cache... or, toggled the theme

It isn't exactly necessary for you to point back to the GMap 'markers' directory with a sym link. But the gmap module is written it to recursively search the sub directories for markers. So, by adding the sym link, you essentially make all default markers available.

Good luck,

Geno

Can there be a hook that modules can call to include their markers?

+1 from me as well. I was glad to see I at least didn't have to hack the module and just did variable_set('gmap_markerfiles', drupal_get_path('module', 'cromods') .'/markers'); but non coder users aren't going to know to do that.

Michelle

Wow, #1 should be a separate documentation task. That's a great solution.

But +1 for the task in general, we shouldn't need to 'trick' the module.

Edit: for reference, I modified the approach in #1 using hook_init().

/**
 * Implementation of hook_init().
 */
function mymodule_init() {
  // Set the Gmap markers directory to our theme.
  if (is_null(variable_get('gmap_markerfiles', null))) {
    variable_set('gmap_markerfiles', drupal_get_path('theme', 'mytheme') . '/markers');
  }    
}

Sorry for asking, if this would work for Drupal 6.x? And for non-coder but willing to do so, what is the "sym link", would really appreciate for more explanation on step 2.

Thank you!

A "sym link" is a symbolic link to another folder - kinda like a fancy version of a Windows short-cut but for Linux/Mac OSX only (unless you have CygWin, but that's another story). You really don't need it. It is equally valid to just copy any markers you need from the module /markers folder to your theme's markers folder, so don't worry about that. Just copy them over.

The rest of it works for Drupal 6, yes.

@greg.harvey, really appreciate for your quick response, let's see how it works. I will try!

I think this should be an option in the config page of Gmaps, a value to fill in where the custom markers are placed. I do not think it's wise to always link this to a theme, since this will create a interaction between multiple themes. For example, my admin theme "Garland" should not interact with the theme "CustomTheme", but (with the solution suggested above) when configuring Gmaps on the admin page it would search in my "CustomTheme" folder while currently being in the theme "Garland".

I think it should be an optional setting in the Gmaps config page to set your "custom markers"-folder path. And I think the best place to set the folder is "/sites/yoursite.ext/markers/" so that it's reachable by the Gmaps module. But ofcourse, it's up to the Drupal admin to choose the folder to it's liking...

Please review and comment...

I think that's a sensible idea. Though the possibility of different marker sets for different themes might also be nice, the more I thought about it the more I realised that would be way too complicated, certainly not one for this issue.

So yes, +1 from me, optional custom markers directory path as a settings field makes total sense.

Re-titling to describe the suggestion in #8.

I needed this option anyway so I just created an patch... It creates the ability to point out to your own custom marker folder in the Gmap config page. I've rewritten the logics a bit, so a thorough review would be in place...

Please review and comment...

Presumably the patch is against 6.x-1.x-dev?

Oh, sorry for the lack of information. No, this patch is against our own currently installed 6.x-1.1. Second time I've created an Drupal patch. Any tips / advice would be more then welcome.

Thanks

General rule is only patch against -dev (so maintainers can apply it directly). Also generally provide patches for the version stated in the issue (in this case 7.x-1.x-dev). Many maintainers only accept feature requests against the latest dev version (7.x) but it varies. If I were you I'd re-roll the patch against 6.x-1.x-dev, attach it here and change the version to that. Worst that can happen is a maintainer will say "sorry, not accepting D6 patches for new features" and set it back to 7.x-1.x-dev. If it were my project, I'd accept the patch and then set it to be ported, but I can't speak for others, clearly. =)

Darn... I was actually happy that I finally could make a patch because I did not do any wrongly timed commits in my git repo. But... I can't really diff it to the Dev version now, can I? To much changes? Not really a hero in the creation of patches...

Don't despair... you patch applies to the current 6.x version, it is useful and it probably does apply to -dev. Did you try? Often the latest release is close enough to the dev release that the patch still applies, in which case you can just apply it to -dev and roll it again. =)

Cool, then I have one more question. What do you think is the best way to create a patch against the dev version? Is this the best solution:

- Download the Dev
- Unpack the dev version (gmap-dev/) on beside my build (gmap/).
- $ diff -upN gmap-dev/ gmap/ > patch_file.patch
- Replace al the "gmap-dev/" references in the patch file to "gmap/"

Is that the easiest / best way?

Ps. Sorry for cluttering this issue about this..

I noticed a little bug in my patch... Path that is passed to the JS is relative, not absolute, which causes 404 errors in the JS. New patch soon, also against the latest dev..

Btw, re: #17 - yes, that is the easiest way - see http://drupal.org/patch/create =)

New patch, this time it's against the latest 6.x-1.x-dev. Also the fix against the bug I mentioned above is in this patch. Please review...

I applied your patch, but it didn't work for me.
- The markers were found, but only half of each icon was transparant
- Markers did show up on custom Views-displays, but not on standard page node/map.
Couldn't figure out the cause. For now, I put my custom markers in the module directory :-(
P.S. do you know the Libraries module? It allows a third module to find the files in the libraries-folder. Could be a helper for this feature.

But then again, we tried to apply the patch to Gmap 7.x; I better wait for a stable GMap module or a 7.x patch..

subscribing

In my opinion, we should make use of something like

drupal_alter('gmap_marker_folders', $marker_folders);

thus modules can add their custom marker folders.

I'm not sure if there should be a solution for the theming layer too?

@ #21 & #22 - Yes, the patch is built against the 6.x-1.x-dev. I think that's why my patch seems to fail for you. I'm not into the 7. yet, so I think you'll have to wait for someone to rewrite my patch or come up with a completely new patch.

Many modules (eg Wysiywg) are already using the Library API for such external / third-party files. So why in the first place using another logic and re-inventing the wheel?

Agreed, we should use the libraries api module.

I also want to go to using libraries instead of the thirdparty directory but that is another issue.

Marked #586956: Markers candidate to use with libraries? as duplicate of this.

Marked #881564: Setting marker directory through the UI as duplicate of this issue.

Great, that really sounds promising!

Any news on this?

sub

+1

+another

Attached is a patch against latest 7.x-2.x found in git, which solves this, supporting both a custom marker directory _AND_ libraries (if available). The patch even applies cleanly to 7.x-2.6 (latest supported stable version) with some offsets.

#34 looks good for me
commited pushed to 7.x-2.x
this one needs testing coverage, especially libraries support, added by patch

Thanks!
Looking forward for tests

tagged new beta release http://drupal.org/node/1987146

If it had tests, they'd have revealed that my previous solution was buggy. Here's a patch that fixes it; unfortunately still without tests, so I'm leaving it as one that needs work. :S

bot

#37: gmap-custom_marker_folder-and-libraries-support-901596-37.patch queued for re-testing.

#37 commited pushed to 7.x-2.x-dev

Reopen this issue because it break the marker icons in some cases.

Actually the patch from #34 (http://drupalcode.org/project/gmap.git/blobdiff/31d6aaf977fe5b21b0f53230...) break the marker appearing. When map is in address different than frontpage markers not showing.

However, I am providing a patch that should fix this miss.

Changing title back

#43 commited pushed to 7.x-2.x-dev
Will be tagged in upcoming beta release
Thanks!!!!

Patch in #43 is partly the cause of #2017565: Path Prefixes (i18n) breaks marker path, Drupal.settings.pathPrefix should not be added to marker's paths.

#48: gmap-path-prefix-breaks-marker-path-2017565.patch queued for re-testing.