One of our production pages stopped working properly.
Tracked it down to the fact that one of the dependencies does not exist anymore:
http://google-maps-utility-library-v3.googlecode.com/svn/trunk/infobox/src/infobox.js
This URL is used in most of the example codes that were the basis of the webpage.
This is probably easily solved but a quick google showed no one has noticed this, I think it has happened in the last hour and just wanted to put the information out there in case people are panicking.
It seems that the library is being moved to Github (it seems the infobox.js wasn't moved yet), see the announcement on main page: https://code.google.com/p/google-maps-utility-library-v3/
But still, the problem with your code is that it's not a good practise to reference code from code.google.com svn repository. It's like referencing a code from Github, it can be changed/moved/removed any time. You should either download the code and include it in your project as .js file or host it yourself on some CDN server.
UPDATE
The google utility library (including infobox) is hosted here on github now. As said before, it's not mean to be referenced from there in projects.
As Google moved the source over to GitHub a while back, the new GitHub version can be accessed from RawGit by using the following script urls (standard and packed versions):
https://cdn.rawgit.com/googlemaps/v3-utility-library/master/infobox/src/infobox.js
https://cdn.rawgit.com/googlemaps/v3-utility-library/master/infobox/src/infobox_packed.js
Whilst the above urls (with the cdn prefixes) have no traffic limits or throttling and the files are served via a super fast global CDN, please bear in mind that RawGit is a free hosting service and offers no uptime or support guarantees.
Accessing files maintained via GitHub is covered in more detail in the following SO answer:
Link and execute external JavaScript file hosted on GitHub
This post also covers that, if you're linking to files on GitHub, in production you should consider targeting a specific release tag to ensure you're getting a specific release version of the script.
For example, you could target the 1.1.13 release of the InfoBox library with the following script urls (standard and packed versions):
https://cdn.rawgit.com/googlemaps/v3-utility-library/infobox/1.1.13/src/infobox.js
https://cdn.rawgit.com/googlemaps/v3-utility-library/infobox/1.1.13/src/infobox_packed.js
Alternatively, you could download and include the library directly in your project for production purposes.
As an emergency fix I copied the code from here:
https://code.google.com/p/google-maps-utility-library-v3/source/browse/trunk/infobox/src/infobox.js?r=466
and linked locally. This appears to work fine for a quick fix but I will need to look for an alternative that see active updates.
Google code is apparently shut down per the announcement
Bidding farewell to Google Code
Thursday, March 12, 2015
January 25, 2016 - The project hosting service is closed. You will be able to download a tarball of project source, issues, and wikis. These tarballs will be available throughout the rest of 2016.
Certainly wasn't clear from the post that they were going to stop making the hosted code available for use externally.
Managed to get back the Infobox (v.1.1.13) script from the browser cache.
Can be downloaded from http://pastebin.com/PGciVVur, hope this helps someone
I linked to this github repo that seems to be a similar one and my site works again:
https://raw.githubusercontent.com/oytunyuksel/Google-Maps-Infobox.js/master/src/infobox.js
Related
I would like to add URL links into a web-based Google Drive folder. Searching online, it appears that this was once possible with files that ended in a .glink extension. I'm looking for documentation on the file format so that I can create them programmatically.
[EDIT] Why do I want to create .glink files? Because I want links (bookmarks, URLs) to be able to appear in my Google Drive web page and to be able to click on them an go to the page. Microsoft OneDrive supports this functionality.
GLINKS Files
The URL link file feature was available due to a workaround with Back Up and Sync before being deprecated with Drive for Desktop. The .glink seems to be patched and no longer available as it was also part of a third party tool no longer available. It seems it now only saves them as .URL and automatically gives it the icon for Google Docs, as it would take it as a simple file with text.
Checking the .url type file of Windows, when uploading to Drive it does not update as it should, even utilizing Drive for Desktop (as an alternative to sync data like back up and sync) the outcome is the one suggested above.
This is the main reason why there is no longer any documentation about the matter, due to this one not being an official feature and being also fully deleted, it can be confirm by the file type available when creating files with the Drive API:
https://developers.google.com/drive/api/guides/ref-export-formats
I would suggest to request a feature to allow this or to provide a new way to store URL links as before or report it to review if possible any references on how it used to work by submitting a feature request or checking the issue tracker about the matter:
https://issuetracker.google.com/issues/new?component=191650&template=824106
You can also add the details of the previous threads or discussions about the GLINKS.
It appears that markermanager.js is no longer available on googlecode.com which has been closed. I have looked for an equivalent on Github, but so far without success. I can find marker-clusterer etc. but my code is built to run with markermanager.js.
Can anyone tell me where it has gone, please?
Following Google's move of the source, the new GitHub version can be accessed via jsDelivr (a content deliver network with no bandwidth limits that's focused on performance, reliability, and security) by using the following script urls (standard and packed versions):
https://cdn.jsdelivr.net/gh/googlemaps/v3-utility-library#markermanager/1.2/markermanager.js
https://cdn.jsdelivr.net/gh/googlemaps/v3-utility-library#markermanager/1.2/markermanager_packed.js
These urls specifically target the 1.2 release of the markermanager library - as covered in the following SO answer, in production you should consider targeting a specific release tag to ensure you're getting a specific release version of the script:
Link and execute external JavaScript file hosted on GitHub
Alternatively, you could download and include the library directly in your project for production purposes.
I'm using this library for using google maps with delphi: GMLib
This has worked fine for several months, but today when I started my application I got a lot of script errors on the page and everything broke down!
After troubleshooting all day I have concluded that this is outside of my control. To demonstrate this you only need to build & run the demo project as it demonstrate the exact same problem (loads of script errors).
The only reasonable explanation is that the js files that the library loads from the Internet has changed. However this is very hard to pinpoint.
I'm hoping the developer of the library sees this as I'm completely lost on how to even start adressing this.
base on this article
Google Maps JS API (v3) InfoWindow Script Error - JSON Undefined
Delphi's solution step is
modify map.html
rebuild gmmapres.rc（use brcc32.exe）
rebuild GMLib_DXE5.dproj
rebuild your project
You can download the newest version 1.5.4 from 1.5.4
I uploaded a utility in the last few days to google cloud storage.
It's a zip file containing two executables and a readme file.
I tested the download and it worked fine. I then looked into how I could see the download stats and yesterday I enabled logging.
I posted the link to a mailing list this afternoon and clicked it to verify that I had the right link and the download in chrome reports "xxx.zip appears to be malicious".
This did not happen prior to when I enabled logging, but I don't know for sure that is what caused it.
I am using a CNAME alias for the download, and I am a paying google apps customer.
The executables are not malicious in any way. They are simple utilities for doing replacements in text files. They do not access the network at all.
My question is "Why is my zip file being reported as malicious?" and is there any way to remedy this situation?
I looked around for a solution to this problem and I found the following advice:
1) Sign your EXEs. As it turns out, this advice is incorrect. While it has worked for some people, there are people who report that even signed executables are reported as malicious downloads.
2) Use SSL. SSL access is not available for google cloud storage unless you use the commondatastorage.googleapis.com or sandbox.google.com URLs. While this does might work, it doesn't resolve my problem.
3) Use the commondatastorage.googleapis.com URL. This works. The same file using the commondatastorage.googleapis.com url rather than my custom CNAME record does not report that it "appears malicious".
4) Register your site with Google Webmaster Tools. Getting around Chrome's Malicious File Warning According to this stackoverflow entry, the solution is to sign up for Google Webmaster Tools and add your site.
I have tried this one, but it has not made a change just yet. Because this is google cloud storage and not a main site, I added an index.html page, a 404 page, and ran the gsutil commands to enable web configuration within google cloud storage. I added the site to Webmaster Tools and additionally added it to Google Analytics.
I'll give solution 4 a few days to see if it pans out.
It seems like this is more of an issue with Google Chrome and not necessarily Google Cloud Storage. Chrome's methods for identifying malicious files are less than desirable right now.
I am trying to add extra buttons for my wiki editor page and I came across to this page:
http://en.wikipedia.org/wiki/User:MarkS/Extra_edit_buttons#Simple_Install
In the simple install section, I need to add extra code in monobook.js.
However, I cannot find monobook.js in my wiki folder. Can anyone give me some direction?
The "simple install" you linked to is for Wikipedia users who want to enable the gadget from their personal script file.
The correct topic would be #Installing XEB on your own Wiki, however I don't fully agree with that (importScript is deprecated, for example). Your alternatives are:
let your users just import the script from //en.wikipedia.org/w/index.php?title=User:MarkS/extraeditbuttons.js&action=raw&ctype=text/javascript. That's a possible XSS risk, but imported userscripts always are. Bonus: The will always get the latest version.
copy the script, the css and the images to your domain - which means you are in charge to maintain them. You could locate them anywhere in your server's file system, on a wiki page in the MediaWiki: namespace (only admins can edit) or on a user subpage that ends in .js (only that user and admins can edit). The last one was recommended in the help file, but I suggest not to use User:MarkS for that. Ensure nobody whom you don't trust could log into that account.
Then promote that location to your users, so they can import the script from there.
Even better: Install the Gadgets extension and migrate the script to a gadget, which users can easily enable in the settings.
Notice the script is deprecated and might not work with current MediaWiki versions. It depends heavily on script loading order, which needs some hacks to integrate well with the ResourceLoader.
See also Manual:Interface/JavaScript; there are similar customisations at Manual:User group CSS and Javascript and Manual:Page customizations.
The page you linked to talks about a user's monobook.js, which is a page called User:UserName/monobook.js.
If you want to do the same for all users on your wiki, you can use the site-wide monbook.js, which is not a file, but a page called MediaWiki:monobook.js.
Keep in mind that those scripts only apply if you're using the Monobook skin. If you want to have some script for all skins, use User:UserName/common.js or MediaWiki:common.js.