forked from shadowfacts/shadowfacts.net
Fix comments on posts due to permalink format change
This commit is contained in:
parent
1175f0ce74
commit
9d0da15173
|
@ -28,6 +28,10 @@ metadata.layout = "default.html.ejs"
|
||||||
</article>
|
</article>
|
||||||
|
|
||||||
<script>
|
<script>
|
||||||
|
<% if (metadata.useOldPermalinkForComments) { %>
|
||||||
|
const permalink = "<%= metadata.oldPermalink %>";
|
||||||
|
<% } else { %>
|
||||||
const permalink = "<%= metadata.permalink %>";
|
const permalink = "<%= metadata.permalink %>";
|
||||||
|
<% } %>
|
||||||
</script>
|
</script>
|
||||||
<script src="/js/comments.js" async></script>
|
<script src="/js/comments.js" async></script>
|
||||||
|
|
|
@ -4,6 +4,7 @@ metadata.category = "meta"
|
||||||
metadata.date = "2019-09-18 10:34:42 -0400"
|
metadata.date = "2019-09-18 10:34:42 -0400"
|
||||||
metadata.shortDesc = "Stand by for reincarnation."
|
metadata.shortDesc = "Stand by for reincarnation."
|
||||||
metadata.oldPermalink = "/meta/2019/reincarnation/"
|
metadata.oldPermalink = "/meta/2019/reincarnation/"
|
||||||
|
metadata.useOldPermalinkForComments = true
|
||||||
```
|
```
|
||||||
|
|
||||||
<figure>
|
<figure>
|
||||||
|
|
|
@ -4,6 +4,7 @@ metadata.category = "activitypub"
|
||||||
metadata.date = "2019-09-22 17:50:42 -0400"
|
metadata.date = "2019-09-22 17:50:42 -0400"
|
||||||
metadata.shortDesc = "A compilation of resources I found useful in learning/implementing ActivityPub."
|
metadata.shortDesc = "A compilation of resources I found useful in learning/implementing ActivityPub."
|
||||||
metadata.oldPermalink = "/activitypub/2019/activity-pub-resources/"
|
metadata.oldPermalink = "/activitypub/2019/activity-pub-resources/"
|
||||||
|
metadata.useOldPermalinkForComments = true
|
||||||
```
|
```
|
||||||
|
|
||||||
This isn't really going to be a blog most, but more of a collection of tidbits and resources I found helpful in implenting the [ActivityPub integration](/meta/2019/reincarnation/#activity-pub) for the new version of my blog.
|
This isn't really going to be a blog most, but more of a collection of tidbits and resources I found helpful in implenting the [ActivityPub integration](/meta/2019/reincarnation/#activity-pub) for the new version of my blog.
|
||||||
|
|
|
@ -4,6 +4,7 @@ metadata.category = "elixir"
|
||||||
metadata.date = "2019-10-10 12:29:42 -0400"
|
metadata.date = "2019-10-10 12:29:42 -0400"
|
||||||
metadata.shortDesc = "How I learned Elixir and why I love it."
|
metadata.shortDesc = "How I learned Elixir and why I love it."
|
||||||
metadata.oldPermalink = "/elixir/2019/learning-elixir/"
|
metadata.oldPermalink = "/elixir/2019/learning-elixir/"
|
||||||
|
metadata.useOldPermalinkForComments = true
|
||||||
```
|
```
|
||||||
|
|
||||||
About a year ago, I set out to learn the [Elixir](https://elixir-lang.org) programming language. At the time, it was mainly so I could contribute to [Pleroma](https://pleroma.social), but I've since fallen in love with the language.
|
About a year ago, I set out to learn the [Elixir](https://elixir-lang.org) programming language. At the time, it was mainly so I could contribute to [Pleroma](https://pleroma.social), but I've since fallen in love with the language.
|
||||||
|
|
|
@ -5,6 +5,7 @@ metadata.date = "2019-11-11 21:08:42 -0400"
|
||||||
metadata.shortDesc = "Building a slide-over hamburger menu without using JavaScript."
|
metadata.shortDesc = "Building a slide-over hamburger menu without using JavaScript."
|
||||||
metadata.oldPermalink = "/web/2019/js-free-hamburger-menu/"
|
metadata.oldPermalink = "/web/2019/js-free-hamburger-menu/"
|
||||||
metadata.slug = "js-free-hamburger-menu"
|
metadata.slug = "js-free-hamburger-menu"
|
||||||
|
metadata.useOldPermalinkForComments = true
|
||||||
```
|
```
|
||||||
|
|
||||||
Slide-over menus on the web are a pretty common design pattern, especially on mobile. Unfortunately, they seem to generally be accompanied by massive, bloated web apps pulling in megabytes of JavaScript for the simplest of functionality. But fear not, even if you're building a JavaScript-free web app, or simply prefer to fail gracefully in the event the user has disabled JavaScript, it's still possible to use this technique by (ab)using HTML form and label elements.
|
Slide-over menus on the web are a pretty common design pattern, especially on mobile. Unfortunately, they seem to generally be accompanied by massive, bloated web apps pulling in megabytes of JavaScript for the simplest of functionality. But fear not, even if you're building a JavaScript-free web app, or simply prefer to fail gracefully in the event the user has disabled JavaScript, it's still possible to use this technique by (ab)using HTML form and label elements.
|
||||||
|
|
|
@ -5,6 +5,7 @@ metadata.date = "2019-12-22 19:12:42 -0400"
|
||||||
metadata.shortDesc = "Integrating a tiny web server into your Xcode UI test target to mock HTTP requests."
|
metadata.shortDesc = "Integrating a tiny web server into your Xcode UI test target to mock HTTP requests."
|
||||||
metadata.oldPermalink = "/ios/2019/mock-http-ios-ui-testing/"
|
metadata.oldPermalink = "/ios/2019/mock-http-ios-ui-testing/"
|
||||||
metadata.slug = "mock-http-ios-ui-testing"
|
metadata.slug = "mock-http-ios-ui-testing"
|
||||||
|
metadata.useOldPermalinkForComments = true
|
||||||
```
|
```
|
||||||
|
|
||||||
I recently decided to start writing User Interface tests for [Tusker](https://git.shadowfacts.net/shadowfacts/Tusker), my iOS app for Mastodon and Pleroma. But I couldn't just write tests that interacted with an account on any real instance, as that would be far too unpredictable and mean my tests could have an impact on other people. The solution to this problem is, of course, mocking. The core idea is that instead of interacting with external things, your program interacts with mock versions of them, which appear to be their real counterparts, but don't actually perform any of the operations they claim to. This allows for very tight control over what data the application receives, making it much more amenable to testing.
|
I recently decided to start writing User Interface tests for [Tusker](https://git.shadowfacts.net/shadowfacts/Tusker), my iOS app for Mastodon and Pleroma. But I couldn't just write tests that interacted with an account on any real instance, as that would be far too unpredictable and mean my tests could have an impact on other people. The solution to this problem is, of course, mocking. The core idea is that instead of interacting with external things, your program interacts with mock versions of them, which appear to be their real counterparts, but don't actually perform any of the operations they claim to. This allows for very tight control over what data the application receives, making it much more amenable to testing.
|
||||||
|
|
Loading…
Reference in New Issue