Open pushred opened 10 years ago
Having the site domain available in the page context would be very helpful for setting up absolute image paths for the various responsive image solutions I'm testing out. These services don't work with relative image paths, because I need to send an absolute path through their service.
From http://www.resrc.it/:
<!doctype html>
<html>
<head>
<title>ReSRC Preferred Approach</title>
<style>.resrc {width: 100%}</style>
</head>
<body>
<img data-src="http://app.resrc.it/o=80/http://www.your-site.co/image.jpg" alt="An awesome dog" class="resrc"/>
<script src="//use.resrc.it"></script>
</body>
</html>
I'm currently getting responsive images set up for Blood:Water Mission because of the large banner images on every page. What are the chances we can get this set up soon?
The client is seeing significant load times on 3G networks with these large banner images. I can implement <picturefill>
for the time being, but I'd like to be able to use one solution for all of the images on the site.
After talking to Monika it looks like we only really need the URL's origin
. I figure I can just run url.parse on the current page's URL and save the complicated and messy segments
stuff for some other day.
I'd agree that segments for breadcrumbs should be added separately. Will you include all the other properties url.parse
provides? href
would cover the other open graph/canonical tags use case I mentioned.
I think I might leave some out and add a few in, whatever makes sense for our application. Things like auth
I can't even think of a use for here.
Is this available for me to use with Blood:Water Mission? How do I upgrade my version of Solidus?
It is available as of version 0.1.4: https://github.com/SparkartGroupInc/solidus/releases/tag/0.1.4
You can upgrade your version of solidus by updating your package.json
and running npm install
:
...
"dependencies": {
"solidus": "~0.1.4"
}
...
The info in the URL object on the live site (for Blood:Water Mission at least) has onmodulus.net info and not the URL of the site you're currently on.
@pushred any idea why that might be happening? Maybe it has to do with the way the Modulus load balancers work?
Possibly, can you ask them? www.bloodwatermission.com
is a CNAME record to that hostname, per their documentation.
The theory I provided Modulus:
we have our domain pointing to edgecast, which points to modulus
so i assume edgecast requests from the modulus url, which gives us back that result
it is cached
and then served from the real url
so, I'm hoping there's some way that edgecast can send a fake host header
Looks like we can set a header, I just changed this in the Edgecast configuration but will take up to an hour to see if it works. :pray:
Docs say:
HTTP/1.1 requires a Host header to be sent with each request, to select among multiple virtual domains that may be hosted by a single physical server or load-balanced set of servers. This option determines the value of the Host header that the edge servers will send with each request to the origin server. Typically you will set this value either to one of the hostnames from the http/https hostnames lists, or else to the name of an edge cname that is using this origin.
Yayyy, great success. I'll update the other customer origins we have as well to have the appropriate headers, I was following a bad pattern from earlier instances.
Sometimes it's necessary to specify the current URL in markup. Some examples include:
Providing this as a relative path would give the most flexibility around protocol. It could also be worth it to provide a path for every segment in the route (and each respective title, ideally), which enables easy breadcrumbs. In Orator this looks like:
Not having this resorts to nasty workarounds.