It was possible use an url like this:
http://maps.google.com/maps?saddr=Current+Location&daddr=44.053442,12.5046472
from August 2017 Google changed the syntax of generic url introducing the "origin" and "destination" keyword, so url SHOULD be
https://www.google.com/maps/dir/?api=1&origin="Current+Location"&destination=44.4949881,11.2725758
Naturally this url is working fine:
samestuff&origin=44.053442,12.5046472&destination=44.4949881,11.2725758
I tried several combination of "Current Location", I tried to omit "origin", no success.
Thanks for any suggestion
Related
Hello I am trying to learn how to develop big cartel themes with the dugway api and I am having trouble linking to the subdomain of a companies current products. Per the documentation it says I need to put in the subdomain in the config file.
This is what I have tried so far, in the dugway.json file I have this "store": {
"subdomain": "kounterfitklothing"
},
and then restarting the dugway server. Once I do that and refresh the page I still see the dugway barebones page.
I also tried adding options[:store] = 'kounterfitklothing' to the config.ru file and nothing happens. Any help would be greatly appreciated.
I can confirm that with the latest version, inserting this into the dugway.json file will load the store properly (config.ru is no longer used for loading the store):
{
"store": {
"subdomain": "kounterfitklothing"
}
}
It could be ignoring the setting if you're missing the first set of open/close braces as well, so double check that - and make sure you're using the latest version of Dugway as well.
I figured it out, I didn't remove the comma after the curly brace.
I could see blog post from 2011 recommending using "-" instead of "~".
What is the best practice to write media URL in Sitecore 6.5 on .NET 4.0/IIS7.5? Should I keep default /~/media/ or follow blog post advice using /-/media/ or while I am there, why not just use /media/?
I suspect the use of ~ is for legacy reasons. The current recommendation is to use -/media as you point out, but you could use whatever you wanted and it would work. The issue you have just using /media/ is if there is any other item with that as part of the name then it will trigger the media handler, rather than serving up your content for example.
For example, as request for /blah/blah/blah/-/media/images/logo.png will serve up the image correctly, /about/media/news/2013/12/20/sitecore.aspx should in fact serve up a page but will trigger the media handler and return a 404 just using /media/. So if you are going to use something else then make sure it is unique, you may need to enforce it since content editors can be a bit funny about remembering things like this.
Since you are currently using Sitecore 6.5 then I can assume you have existing content. Make sure you leave the existing ~/media trigger to allow your Rich Text fields to continue to work
If you update the Media.MediaLinkPrefix setting on a system that
already has some content in a database, Sitecore may not update the
values in all Rich Text Editor fields that contain values in the old
formats, including inline images and links to media items.
Sitecore Idiosyncrasies: Media URLs
I would probably go ahead and set Media.RequestExtension to an empty string so that image urls are served up with the correct media extension too.
I know this problem appear just when are you using .Net Framework 2.0
Please see next link .
If you run your website under .Net Framework 4.0 and IIS 7.5 you don't have this vulnerability.
Also this document explain a little bit about using of tilde.
Also you can check John West blog about /~/media
So the conclusion is use -/media for media files.
For projects using Sitecore 7.2, you may want to stick to using a tilde or apply the hot-fix mentioned in the following KB article.
https://kb.sitecore.net/articles/998758
Sitecore 6.6 rev 130214. ECM 2.0 rev. 130123
I'm encountering a number of 404 errors when trying to view the "Messages" and "Reports" links in the left-hand navigation of ECM. (Links like "Recently Dispatched", "Search Messages", "Messages in Progress", etc)
What I've found is that the links being generated are embedding the language. In my case, the URL generated includes "en" in the path. When this is included I get a 404 when clicking on them. When I remove the "en" from the path, the page renders normally.
Not working:
http://myserver/en/speak/EmailCampaign/Messages/RecentlyDispatched
Working:
http://myserver/speak/EmailCampaign/Messages/RecentlyDispatched
I've got "languageEmbedding" set to "never" in my web.config, but it looks like ECM/Speak may not be taking this into account.
Before I take this to support, has anyone else seen this? Feels like a bug to me.
Thanks!
Craig
I found the same problem and contacted sitecore support. They registered this as a bug and send us a hotfix, but this bug has now been fixed in ECM 2.1 rev.130529.
You can check the release notes here (ref.number 386058): http://sdn.sitecore.net/Products/ECM/ECM%202,-d-,1/Release%20Notes.aspx
regards,
Vicent
We have an application running built on python/django. I get emails whenever there is a missing link (404) or a server error (500). I've noticed that i get a number of links that looks something like this:
Referrer: http://www.mywebsite.com/model/
Requested URL: /model/js/modernizr-1.7.min.cb14102011.js
User agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB7.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
IP address: 41.2.246.84
The issue is the requested url. It requests the js file relative to the current dir, rather than the absolute dir. What makes it bizarre is that I can't reproduce it, and it happens a handful of times a day, even though there are many different users on the site. The consequence of the missing links also sometimes causes 500 errors, depending on the url (due to the django url structure I've defined for the application).
Has anybody seen this kind of issue before? Is there anything that I should check for that might resolve this issue?
Edit:
The js files are accessed through http://www.mywebsite.com/static/js/ The same configuration applies for css files. On further investigation it seems that the 'static' part gets dropped from the url.
Edit (2)
I made a mistake yesterday. not only does the {{ STATIC_URL }} not pull through as defined in the settings file, it is replaced with the current (relative) url. I.e, in the original post "model" should be "static", but its not replaced as such. I'm still at a loss as to why this happens.
Thanks Dennis and Jordan. Your comments helped me a lot.
For my scenario I noticed the problems only happens on 1 url. Since many of the templates use the same base template. I ruled out a base template problem. I also checked the views of the url to see that the context was added correctly (since without context the STATIC_URL variable might not pull through). All good.
I also only saw IE7 in the logs. When I looked at the template I noticed an extra closing " (ie class="bogus"" ). I think that extra quote messed up the template, and IE7 then had trouble rendering the rest of the template.
I've made the changes in production so am not 100% sure that I've fixed the problem, but I'll know within a day or so.
Edit:
The answer, I've realised, lies in the fact that if there is a coding problem (ie the server throws a 500), then the context doesn't get loaded correctly, and so the STATIC_URL doesn't get populated. This also means that each 500 error will have a corresponding 404 error for any files loaded from STATIC_URL
I am using ColdFusion 9.1.2.
I set up a new web site that parses the query string after the domain name and slash. What is left is the MusicianID and then a string used to help with SEO. The URL looks like this:
http://awesomealbums.info/?1085/jim-croce
http://awesomealbums.info/?1077/james-taylor
When I share it using Facebook, Facebook removes the question mark and encodes it. They can't seem to parse it so they display it as the home page.
These throw an error that I can't control:
http://awesomealbums.info/1085/jim-croce
http://awesomealbums.info/1077/james-taylor
I notice that StackOverlfow and other sites are able to exclude the question mark that starts a query string. I would like to do the same. I, however, can't change any IIS or CF Administrator settings. I need to code the solution. I've tried, but I get IIS telling me they can't find the page.
I want my URLs to look like this:
http://awesomealbums.info/1085/jim-croce // same as above but no ?
http://awesomealbums.info/1077/james-taylor // same as above but no ?
Here's the code that I am using right now to parse the URL and get the MusicianID.
<cfscript>
QString = CGI.QUERY_STRING;
if (QString eq "") {
include "Home.cfm";
} else if (QString eq "WhoAmI") {
include "WhoAmI.cfm";
} else {
IndexOfSlash = Find("/", QString);
if (IndexOfSlash eq 5) {
ThisID = left(QString, 4);
if (isNumeric(ThisID)) {
MusicianID = ThisID;
include "Musician.cfm";
}
} else {
location(url="http://www.awesomealbums.info" addtoken="false");
}
}
How can I alter my site so that the question mark can be removed and the web server doesn't get funky and I can parse out the query string?
The keyword you are looking for is URL rewriting. It has to happen on the web server, since you want to handle all requests in the top-level directory. If your web server is the Apache httpd, you can do it like this:
RewriteEngine on
RewriteRule ^/(\d{4})/([\w-]+)$ /?$1/$2 [L]
or
RewriteRule ^/(\d{4})/([\w-]+)$ /Musician.cfm?MusicianID=$1 [L]
Since you can't modify the web server (as Roland correctly suggests) there is one alternative - use URLs that look like this:
http://awesomealbums.info/index.cfm/1085/jim-croce
Structured this way, the webserver (IIS) will still pass control to your script. Then you can start having CF take over control of the processing. Your CGI.query_string will be empty, but your cgi.path_info variable will contain /1085/jim-croce. You can then start parsing that and handling it as needed.
The answer for IIS is basically the same as Roland mentions in his answer. You need to use URL Rewriting, that is the only way to accomplish what you are looking to do. This is because technically the URL that you want to request, does not exist as a real page or resource on the server, and you need to use URL Rewriting to intercept the page request, map it using regular expressions, then pass it to your application as the query string (page parameters) that you are expecting. So, if you are doing this on a hosted server, contact your host and see if they have something setup or installed on the server for doing URL Rewriting. Most any decent host certainly will.
If you are using IIS7, then info on using the built in URL Rewriting can be found at the link:
http://learn.iis.net/page.aspx/460/using-the-url-rewrite-module/
If you are using an older version of IIS, then you need to install an application on the server that will do this as previous versions of IIS do not have built in support for regular expression based rewriting that you would need to properly map your URLs to the correct parameters on your query string. For older versions of IIS, I've used Helicon IsapiRewrite which you can find at:
http://www.isapirewrite.com/
riding off of jfeasel's answer, you can use ColdCourse:
http://coldcourse.riaforge.org/