<!-- Helpful -->
<article class="c-comment h-entry" id="c0001">
<header class="c-comment__header">
<h3 class="c-comment__title p-name h-card">
<a class="p-author u-url" href="https://adactio.com/">
<img class="c-avatar u-photo" src="https://www.gravatar.com/avatar/5ad82c5ba0264363974af89deb743c20?s=96" width="64" height="64" alt="" />
Jeremy Keith
</a>
</h3>
<p class="c-comment__meta">
<a class="c-comment__permalink" rel="bookmark" href="#c0001" title="Permalink to this comment"><time class="dt-published" datetime="2012-12-01T12:24:48-00:00">1 December 2012</time></a>
</p>
</header>
<div class="c-comment__main s-prose e-content">
<p>This is great stuff! I’m terrible at regular expressions—my brain just doesn’t seem to want to remember any of it—but this article contains the clearest description of regular expressions I’ve come across.</p>
<p>I thought I’d share a useful little rewrite rule that I use for cache-busting JavaScript and CSS files. You know the story: you make a change in your JavaScript or CSS and you want to let the browser know that it should grab the new version instead of using what it’s got in its cache.</p>
<p>Now, I could potentially just use a query string when I point to my JS and CSS files ( e.g. /js/myscript.js?20131201 ) …but that can cause issues with proxy servers.</p>
<p>Instead what I what I do is point to files like this: <code>/js/myscript.20131201.js</code></p>
<p>Then I need to tell the server to look for the <strong>actual</strong> file in <code>/js/myscript.js</code></p>
<p>Here’s the rewrite rule I’m using:</p>
<pre><code>RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.).(d).(js|css)$ $1.$3 [L]
</code></pre>
<p>It’s basically telling the server that, if the JS or CSS file doesn’t actually exist and it matches the pattern of having two dots before the file extension (with only numbers after the first dot), to look at the bit before the first dot, and look at the bit after the second dot, but to ignore the bit in between (the numbers).</p>
<p>The server serves up the right file, but browsers fetch the new version because, as far as they’re concerned, this looks like a brand new file that they haven’t got in their cache.</p>
<p>That was a terrible explanation, wasn’t it? I now have even more appreciation for how clearly and concise this article is.</p>
</div>
<footer class="c-comment__footer">
<p>This comment was <a href="/vote/up/c0001/">helpful</a> / <a href="/vote/down/c0001/">unhelpful</a></p>
</footer>
</article>
<!-- Unhelpful -->
<article class="c-comment c-comment--unhelpful h-entry" id="c0002">
<header class="c-comment__header">
<h3 class="c-comment__title p-name h-card">
<a class="p-author u-url" href="https://paulrobertlloyd.com/">
<img class="c-avatar u-photo" src="https://www.gravatar.com/avatar/15091a37bacfa4bdd011282627eaca2b?s=96" width="64" height="64" alt="" />
Paul Robert Lloyd
</a>
</h3>
<p class="c-comment__meta">
<a class="c-comment__permalink" rel="bookmark" href="#c0002" title="Permalink to this comment"><time class="dt-published" datetime="2012-12-12T12:24:48-00:00">12 December 2012</time></a>
</p>
</header>
<div class="c-comment__main s-prose e-content">
<p>You fool! Everything you’ve written here is wrong!</p>
</div>
<footer class="c-comment__footer">
<p>This comment was <a href="/vote/up/c0002/">helpful</a> / <a href="/vote/down/c0002/">unhelpful</a></p>
</footer>
</article>
<article class="c-comment{% for mod in mods %} c-comment--{{ mod }}{% endfor %} h-entry" id="{{ id }}">
<header class="c-comment__header">
<h3 class="c-comment__title p-name h-card">
<a class="p-author u-url" href="{{ href }}">
{% render "@avatar", avatar %}
{{ author | title }}
</a>
</h3>
<p class="c-comment__meta">
<a class="c-comment__permalink" rel="bookmark" href="#{{ id }}" title="Permalink to this comment"><time class="dt-published" datetime="{{ datetime }}">{{ datetime | date('D MMMM YYYY') }}</time></a>
</p>
</header>
<div class="c-comment__main s-prose e-content">
{{ content | markdown | safe }}
</div>
<footer class="c-comment__footer">
<p>This comment was <a href="/vote/up/{{ id }}/">helpful</a> / <a href="/vote/down/{{ id }}/">unhelpful</a></p>
</footer>
</article>
/* Helpful */
{
"site": {
"title": "24 ways",
"handle": "24ways",
"description": "24 ways is the advent calendar for web geeks. Each day throughout December we publish a daily dose of web design and development goodness to bring you all a little Christmas cheer.",
"url": "https://24ways.org",
"feed": "https://feeds.feedburner.com/24ways",
"theme_color": "#f04"
},
"theme": {
"year": [
348,
344,
340,
336,
332,
328,
324,
320,
316,
312,
308,
304,
300,
296,
292,
288
],
"day": [
360,
353,
346,
339,
332,
325,
318,
311,
304,
297,
290,
283,
276,
269,
262,
255,
248,
241,
234,
227,
220,
213,
206,
199
]
},
"id": "c0001",
"href": "https://adactio.com/",
"author": "Jeremy Keith",
"datetime": "2012-12-01T12:24:48-00:00",
"avatar": {
"src": "https://www.gravatar.com/avatar/5ad82c5ba0264363974af89deb743c20?s=96",
"size": 64
},
"content": "This is great stuff! I'm terrible at regular expressions—my brain just doesn't seem to want to remember any of it—but this article contains the clearest description of regular expressions I've come across.\n\nI thought I'd share a useful little rewrite rule that I use for cache-busting JavaScript and CSS files. You know the story: you make a change in your JavaScript or CSS and you want to let the browser know that it should grab the new version instead of using what it's got in its cache.\n\nNow, I could potentially just use a query string when I point to my JS and CSS files ( e.g. /js/myscript.js?20131201 ) …but that can cause issues with proxy servers.\n\nInstead what I what I do is point to files like this: `/js/myscript.20131201.js`\n\nThen I need to tell the server to look for the **actual** file in `/js/myscript.js`\n\nHere's the rewrite rule I'm using:\n\n```\nRewriteCond %{REQUEST_FILENAME} !-f\nRewriteRule ^(.).(d).(js|css)$ $1.$3 [L]\n```\n\nIt's basically telling the server that, if the JS or CSS file doesn't actually exist and it matches the pattern of having two dots before the file extension (with only numbers after the first dot), to look at the bit before the first dot, and look at the bit after the second dot, but to ignore the bit in between (the numbers).\n\nThe server serves up the right file, but browsers fetch the new version because, as far as they're concerned, this looks like a brand new file that they haven't got in their cache.\n\nThat was a terrible explanation, wasn't it? I now have even more appreciation for how clearly and concise this article is.\n"
}
/* Unhelpful */
{
"site": {
"title": "24 ways",
"handle": "24ways",
"description": "24 ways is the advent calendar for web geeks. Each day throughout December we publish a daily dose of web design and development goodness to bring you all a little Christmas cheer.",
"url": "https://24ways.org",
"feed": "https://feeds.feedburner.com/24ways",
"theme_color": "#f04"
},
"theme": {
"year": [
348,
344,
340,
336,
332,
328,
324,
320,
316,
312,
308,
304,
300,
296,
292,
288
],
"day": [
360,
353,
346,
339,
332,
325,
318,
311,
304,
297,
290,
283,
276,
269,
262,
255,
248,
241,
234,
227,
220,
213,
206,
199
]
},
"id": "c0002",
"href": "https://paulrobertlloyd.com/",
"author": "Paul Robert Lloyd",
"datetime": "2012-12-12T12:24:48-00:00",
"mods": [
"unhelpful"
],
"avatar": {
"src": "https://www.gravatar.com/avatar/15091a37bacfa4bdd011282627eaca2b?s=96",
"size": 64
},
"content": "You fool! Everything you've written here is wrong!\n"
}
$comment-avatar--small: map(sizes, large);
$comment-avatar--large: map(sizes, xlarge);
.c-comment {
position: relative;
margin-bottom: map(spaces, large);
padding: map(spaces, large);
padding-left: $comment-avatar--small;
background-color: white;
box-shadow: 1px 1px 0 $prose-color--shadow;
@media (-ms-high-contrast: active) {
border: 1px solid;
}
@media (--from-medium-screen) {
padding-left: $comment-avatar--large;
}
@media (--upto-large-screen) {
margin-left: calc(calc(map(spaces, large) - map(spaces, xsmall)) * -1);
margin-right: calc(calc(map(spaces, large) - map(spaces, xsmall)) * -1);
}
&.c-comment--unhelpful {
background-color: transparent;
box-shadow: 0 0 0 1px $prose-color--shadow;
}
.c-avatar {
position: absolute;
top: 0;
left: calc(map(spaces, large) * -1);
width: map(sizes, large);
@media (--from-medium-screen) {
width: map(sizes, xlarge);
}
}
}
.c-comment__header {
margin-bottom: map(spaces, large);
@media print {
border-top: 1px solid black;
padding-top: map(spaces, small);
}
}
.c-comment__title {
@apply --typeset-summary-title;
}
.c-comment__meta {
@apply --typeset-label;
@media (--from-small-screen) {
position: absolute;
top: 1.75rem;
right: map(spaces, large);
}
}
.c-comment__main {
margin-bottom: map(spaces, large);
}
.c-comment__footer {
@apply --typeset-label;
border-top: 1px solid $prose-color--shadow;
padding-top: map(spaces, medium);
text-align: right;
}
There are no notes for this item.