Stop clearing markers so often: fixes Message: GMap is unable to save the marker bundle. Markers will not work!

subscribe

It seems that you can easily fix that. I also installed gmap and gmap location via drush and got the same error.
Then I checked the permissions in the in the module directory sites/all/modules of the gmap module. theses where slightly different so I changed them to 775, where the owner/group is www-data.

Then I checked the permissions in the sites/default/files directory where actually my js files get stored. For some reason the owner was root instead of www-data so I changed the owner and group to www-data.

sudo chown www-data -R js
sudo chgrp www-data -R js

hope this works for you.

This worked for me.
sorry, I changed owner/group even permissions to 777 on the entire directory (/sites/all/modules/gmap) and still no luck when I "Regenerate marker cache"

This is still a problem. I just hit it using 7.x-1.x from git.

The module was installed with drush make, but enabled in via the webgui. Even "drush dre -y gmap" didn't fix it. In sites/default/files/js I have gmap_markers.js

Let me know if you need more info to track it down.

still got this error after running cron. I'd chmod to 775 and the gmap_markers.js is already changed to user and group of the webserver (www-data).

I've just tried the method of #1167594: Saving gmap_markers.js needs catch errors. I'd edited the "gmap.module" and found that the error message was printed by the below "if" statement (it is false), around line 555:

if (file_prepare_directory($dir, FILE_CREATE_DIRECTORY)) {
...

Just before this if condition statement the $dir was defined:

$dir = "public://js/";

So I'd changed it to a hard coded path:

$dir = "/var/www/xxx/sites/default/files/js/";

Now the error message was gone. So the culprit is that "public://" prefix. Do you have any idea to deal with it?

That worked for me metakel :)
For migration purpose i changed line 547:

$dir = $base_path . "/sites/default/files/js/";

Why this so nice solution of "public://" file paths does not work in this instance i do not know.

Your solution still does not work with a multisite configuration (but should be good enough for most people).

I have come up with another problem which deal with the public:// prefix here regarding the filefield_path module

#1051736: Unable to upload files: writing to "~/public_html/public:" and "~/public_html/private:"

I can't tell whether it is related. I would like to find more information on the mystical public:// but I can find none. I wish I can hard code it in some place like settings.php rather than letting the system to detect on its own.

subscribe

subscribe

I think the problem arises with the is_writable call inside file_prepare_directory.
With my (writable!) "js" folder:

is_writable("public://js/")

gives false and

is_writable(drupal_realpath("public://js/"))

gives true.

Windows server here.
I ran into this, and after a few days, found a solution. I've ascertained that when file_save_data is called with drupal's default file scheme 'public://', drupal will create a temporary file using the system's temp directory, and then it copies the file out of the temp directory to where it's actual home will reside. Why it won't just create the file where it's supposed to go in the first place is beyond me. There are too many layers of abstraction for a someone who picked up drupal a week ago to really find out, and I really don't care - it works now. Anyone who runs drupal on their own WAMP box should run ProcessMonitor and just see the number of filesystem calls that one pageview generates - I was absolutely staggared. ok, /end old crotchety performance snob rant.

Anyways, the problem was, for some reason, apache did not have read access to the system temp folder. On windows, it was using the system environment variable TEMP or TMP - which, as you could guess, pointed to c:\windows\temp\ on my system.

I gave the apache service read access to this directory, and the problem disappeared. I have full admin access to my machine, so way back when, I've set up the apache process to run under it's own user account so I can assign permissions with more granularity. I don't know if this caused my problem in the first place, or made it more secure and easy to fix. Either way, it immediately started working after the permissions change.

Metakel, take a look at the API documentation for: file_save_data, it briefly describes what public:// is. It also states that the function requires the destination to be a stream wrapper API. Placing an absolute directory path in there is apparently "not a good idea." However, I suppose if it works, & you only have one drupal install/site to mess with, do it. You may want to check your system & apache logs to make sure you aren't stuffing them with warnings about the directory/
http://api.drupal.org/api/drupal/includes--file.inc/function/file_save_data

same issue, +1

Subscribe

subscribe

zoorock's #2 simple permissioning fix just worked for me now. With the footnote that you then need to hit the "regenerate" button on the GMap configuration page. Thanks!

Hi all,

I have tried all the suggestions above but am still getting the error:
* The data could not be saved, because the destination is invalid. More information is available in the system log.
* Notice: Trying to get property of non-object in gmap_regenerate_markers() (line 555 of /var/www/clients/client0/web1/web/sites/all/modules/gmap/gmap.module).

This started after I moved the site to a new server. The site is Drupal 7.8. I think I have tried all variations of owner / permissions on the gmap module directories and default/files/js.

Any help or ideas would be most welcome.

The error can be seen here: http://www.hadrianorganics.co.uk/buy

Many thanks,

Liam

Seems to be working now, not sure exactly why, but it might have been the creation of a new tmp directory in sites/default. Not sure if this is wise, but it seems to have worked for me.

I noticed that the gmap_markers.js file inside /sietes/default/files was the only file in there that was not owned by my drupal-user, and in the group of my drupal-user. For some reason it retained the permissions of the module (where it originated).

I didn't even know it was possible for the server to copy a file retaining it's original owner and group, but let's figure it out :)

Just as an aside to this topic, it may happen that if you are transferring a site from one server to another, and you have the old gmap_markers.js file in the sites/default/files/js directory, you may just want to blow it away and let it recreate it. That is the only thing that made the error go away for me. It was creating files just fine in my tmp directory but still giving me the error. I think there was some cached file id that it was trying to find in the filesystem because it could see that the file existed, but wouldn't load it. Weird.

That worked for me too, thanks for the tip.

subscribe

#22, Thank you, CrashTest_

It works. So easy.

idem for me too :
#22, Thank you, CrashTest_
It works. So easy.

#22 didn't fix it for me, but changing line 550 in gmap.module from $dir = "public://js/"; to $dir = drupal_realpath("public://js/");
fixed the errors.

Patch attached in case anyone else is still having this issue.

Had the same issue. Was caused by incorrect permission on the public file system path (usually sites/default/files) which prevented files being created in that folder. Setting the permission to 755 on that folder fixed the problem.

It is strange that I always set the "files" directory's premission to 775 (which the Apache server's "www-data" is both the user and the group of that directory). However the error message still appears. But when I applied the modification of #27, the error is gone.

I still have this issue,although tried all above methods.Not only I take this message,but also when I save a marker it doesn't save.

#22 works for me too

#27 solved similar issue for me.

Thanks for this. It worked for me.

shortcut;

sudo chown www-data:www-data -R js

#27's a neat little fix. Thank you, RadioActiv. Permissions on the public://js dir in my case were wide open www:www 775 and yet GMap was throwing this error whenever I attempted to use drush to update.

I've found other examples which call file_prepare_directory("public://js"); so it appears to be an accepted paradigm. What's mystifying is that file_prepare_directory() simple calls is_dir() on public://js without translating it to a file system path first.

I only see this error when running drush (as root); and gmap_markers.js usually has today's date; so I have to think that the drush runtime environment somehow lacks a public schema translation effect? (enter Rod Serling stage right). One also has to wonder why the file needs to be written so often?

Oopsie....
(removed issue tags)

#22 did NOT work for me
#27 did work for me

~thanks

Thanks,

#27 also worked for me

#27 Works.

RTBC++

Same here: #22 does not fix it, but #27 is working.

2¢: a simple fix, worth a commit

#22 work s for me. Thanks..:)

fixing title

#27 commited to 7.x-2.x branch

thanks!!!

#27 commited to 7.x-1.x branch

thanks!!!

status

#1831410: Single Markers disappeared after upgrade to version 2.6
possibly related
reopening issue

#44 reverted due to #1831410: Single Markers disappeared after upgrade to version 2.6
need work

#27 works for me... again.

I had noticed this error message occasionally on cache-clears, but it was never a problem for me until I tried updating drupal core with drush, and the error caused drush to abort the upgrade.

The problem appears not to be with gmap.module per se, but with file permissions. If you run a drush cc, for instance, as a user other than the webserver, gmap's attempt to overwrite gmap_markers.js will fail, because it's owned by www-data:www-data (or similar for your server.) If you sudo and run the same command as www-data, you will succeed. Or, manually change the ownership of gmap_markers.js to you:www-data with group-writable permissions (which will persist as Drupal overwrites the file during cron). Either way, I don't think this is a problem with gmap's code.

Also re: #27, changing the URI to an absolute path shouldn't make any difference; file_prepare_directory handles URI's or paths interchangably.

@bradjones1 - I also have this problem only when clearing cache with drush, but tweaking permissions didn't help. I tried the "you:www-data" with 776 on the file and the parent directory but that didn't help. I tried chmod -R 777 (on my dev site, of course) and that also didn't help.

Assuming this is only a problem for people using drush to clear cache in some way, what if we just don't run this in cli mode?

I'll admit that I don't think I've ever actually had a problem with gmap where clearing the markers was the solution, so it's possible that I'm not considering how important it is to clear this on every cache clear.

I see this problem a lot with this module - in places where the permission seems OK to me

Would it make sense to modify file permissions if these are detected as incorrect ?

eg

file_prepare_directory($public_files_directory, FILE_CREATE_DIRECTORY | FILE_MODIFY_PERMISSIONS);

as far as I can see the code doesn't even try to do this so if it detects what it thinks are incorrect permissions it will fail

NB I've seen this error when running as root - I think that is_writable() fails to take into account that root can ignore the set permissions

I am unsure if it can account for permissions set via setfacl

#50 worked for me.

Please consider for inclusion as soon as possible. As someone who is responsable for patching a large number of Drupal sites, Drush functionality is borderline manditory.

Patch in #50 works for drush cc all error here

@greggles - +1 for applying the old medical adage, "if it hurts when you do X, just stop doing it."

I think this would be good for RTBC but the testbot is out to lunch on the patch in #50?

Patch in #50 fixed it for me

For folks saying that #50 works, it would be interesting to know if you see any new bugs introduced.

#50 looks like "I do not want to see a bug" but not a real fix

@podarok - that's roughly right, but do we have any idea why the markers are getting cleared on every single site-wide cache clear? Maybe doing that in the first place is the actual bug here. That action should probably only be taken when it needs not and not quite to indiscriminately.

I dug back and the change was made in 2008 but there's no issue in the queue associated with the change.

http://drupalcode.org/project/gmap.git/commitdiff/377bdc3298ebc146620acb...

Prior to that it could be cleared explicitly from a gmap admin page, but wasn't cleared as part of the global cache clearing.

This bug breaks getting updates for this module using drush

#62 what king of review this needs?

The review needed is more description of what a "real" fix would look like if you are truly unhappy with this one.

Several people have delivered functional reviews (#57 #54, #53, #52) saying that the patch in #50 works for them and they didn't notice any side effects. So, we know that the patch in #50 fixes an annoying real problem for people.

I did research to find that the "feature" was introduced without discussion of merit of either the idea or the implementation.

I find it upsetting and demotivating that buggy code was introduced in 2008 and now we can't get rid of it because the proposed fix doesn't feel "real" enough.

If you need more information from me to understand why this is a problem I'd be happy to give that information. Here are the steps I went through to try to get rid of the issue:

1. Confirmed ownership of everything in my files directory to be the same user as the webserver
2. Tried setting the gmap directory and files to 777 permissions

Neither of those fixed it though both my own investigation and comments from others made me think that they should help.

Turns out that for us this broke more than just updating this module with drush. It appears to break almost any drush command.

Uninstalling module allows us to use drush again. So I can definitively attribute our drush problems to gmap.

May I ask the rationale behind calling regenerate_markers so often? Shouldn't this be something just done at install and maybe a clear cache hook?

@rurri - can you test the patch in #50?

#50 commited pushed to 7.x-2.x and 7.x-1.x
thanks to @greggles

My thanks to you, podarok :)

tag

#50 got me up and running on 7.x-2.3

#22 and #27 fixed it for GMAP 7.x-2.9 three years later :)

I basically just changed the permissions to 775 at sites/default/files to reflect 775 and it fixed my problem. I guess everyone's got a different issue. Mine was particularly with the webform entirety module. Talk about learning the school of hard knocks. :)