Fix comments on posts due to permalink format change

This commit is contained in:
Shadowfacts 2020-01-28 19:43:17 -05:00
parent 1175f0ce74
commit 9d0da15173
Signed by untrusted user: shadowfacts
GPG Key ID: 94A5AB95422746E5
6 changed files with 10 additions and 1 deletions

View File

@ -28,6 +28,10 @@ metadata.layout = "default.html.ejs"
</article> </article>
<script> <script>
const permalink = "<%= metadata.permalink %>"; <% if (metadata.useOldPermalinkForComments) { %>
const permalink = "<%= metadata.oldPermalink %>";
<% } else { %>
const permalink = "<%= metadata.permalink %>";
<% } %>
</script> </script>
<script src="/js/comments.js" async></script> <script src="/js/comments.js" async></script>

View File

@ -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>

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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.