We are scaling a website and we would like to plan for the future where we may want to host our images in a sub-domain (or perhaps even a separate domain altogether, e.g. a CDN). We currently reference images in our HTML/PHP code using the following HTML:
<img src="/images/ourlogo.jpg" alt="Our Logo" />
I was thinking of starting a company convention to move to:
<img src="<?php echo STAT_IMG;?>ourlogo.jpg" alt="Our Logo" />
where STAT_IMG is a global PHP constant, which would be initially defined to be identical to the current situation, i.e.
define('STAT_IMG', '/images/');
but could later be changed to something such as:
define('STAT_IMG', 'http://www.superfastcdn.com/');
Will I run into any issues doing this?
Things I have already thought about:
- I can see there'll be many more string appends in the code base - but I don't expect it'll be noticeable in terms of performance.
- It makes the code uglier (especially in my example where PHP and HTML have been mixed).
- One issue is that sometimes you need to explicitly use https for images (or vice version). For example, if you put images in a email, many clients (e.g. gmail) use the https protocol, so resources referencing http (i.e. unencrypted protocol) will generate a mixed content warning in some browsers (e.g. IE). This article from encosia has a idea for working around this by defining
STAT_IMG
as "protocol-less", e.g.define('STAT_IMG', '//www.superfastcdn.com/');
. I hope their idea works.- We may need a few other constants to explicitly define the protocol e.g.
define('STAT_IMGS', 'https://www.example.com/images/');
anddefine('STAT_IMGNS', 'http://www.example.com/images/');
in addition to the previous non-absolute version (define('STAT_IMG', '/images/');
).
- We may need a few other constants to explicitly define the protocol e.g.
- I will need to apply the same strategy to other static resources such as javascript and CSS stylesheets.