General code audit

[jessicaschilling]

This issue is for the need for an overall code audit, focusing in particular on:

• Modules etc that could be removed as a result of being ported over from PL blog but not needed here
• Potential barriers to deployment over IPFS

Please separate the results out into their own issues so they're easier to work - thanks!

[jessicaschilling]

@cwaring -- thank you for identifying any problems here as you find them! 🙏 I can separate into checklists or individual issues as need be.

[cwaring]

I'll report back with an evaluation within the next couple of weeks, and also my suggestions to #41.

[jessicaschilling]

@zebateira - per our conversation, are you able to work with @cwaring and @jdiogopeixoto to get this and #41 resolved? As we discussed, we might also want to look into establishing some sort of ongoing instrumentation for the blog to keep an eye on performance as the blog continues to expand over time. Thank you!

[jessicaschilling]

Note re instrumentation: @atopal recommends https://speedcurve.com/.

[jessicaschilling]

Do we feel we can close this issue in favor of #41?

[zebateira]

@jessicaschilling I would prefer to go forward with a separate code audit from the payload issue. Will leave an update here soon about this.

[cwaring]

Agree with @zebateira here. There is a lot more to be covered than captured in that issue, best keep this on the radar.

[zebateira]

Initial list:

• Blog post images need to be out of the public folder and required by webpack (follow up from discussion in feat: improve performance #91, WIP in fix: make blog post images work with IPFS #99)
• Remove unused code and packages (addressed by fix: update dependencies #100)

[cwaring]

I'll maintain a list of items here as I notice them:

• Remove image crop route from blog config
• Correctly exclude sitemap and feed items
• Ensure generated page metadata is correct
• Tailwind should be upgraded to 2.x (we can now use JIT mode to save build time)
• 404 should use a layout file (example: config 404.vue)
• Tags and authors should have rel="nofollow" to stop url indexing
• App metadata should be changed from "Protocol Labs"
• Countly should not load in dev mode, as not to pollute analytics
• bonus: card zoom hover is disorienting, try a subtle zoom on the image instead (eg https://protocol.ai/blog/)

[zebateira]

first two items from @cwaring list addressed in #98

[cwaring]

Added a few more items above :)

[zebateira]

@cwaring regarding the 404, is it possible to make it work on a subpath? It doesn't seem to be working: https://ipfs.fleek.co/ipfs/Qmb4soPiemEeQoYWciwsZXaCBP3AYeojjrCFdCGHjsSgwe/asdf

Currently the script redirect to /404.html is not working, but we can tweak it to make it work quickly.

[cwaring]

It's only possible by redirecting with the ipfsPathPrefix script. However in my mind the 404 is not really required when you're viewing a site from a CID gateway because that is a snapshot in time that will never change, so I'm ok with the compromise of using <base href="/"> to pin the 404 page to the root domain because a 404 is unlikely to be triggered unless that CID deploy happed to include internal dead links. Which should be a low probability.

The advantage of using a 404 layout means it's easy to capture the url for the 404 and report to analytics. If we redirect to a root /404 page perhaps this is also possible by checking the referer?

[cwaring]

The alternative that would work in both scenarios might be:

ipfs-404.html responsible for redirects -> {cid}/404 OR /404
/404 - responsible for displaying the 404 and reporting the referer path to analytics (so we can fix the 404)

Downside is this would only work if JS is enabled but who really browses with JS disabled these days?!

[cwaring]

I just checked, this would work but then you would also lose the original referer link because of the interim redirect.

eg:
[article elsewhere on the web] -> ipfs-blog/post -> ipfs-404 -> 404 (document.referer = 'ipfs-blog/post')
[article elsewhere on the web] -> ipfs-blog/post -> 404 (document.referer = 'article elsewhere on the web')

This can be helpful for figuring out the original source link and fixing them. So you would have to pass on the original referer to the 404 page to capture everything correctly or do the analytics tracking before the redirect, but then you would have to wait for that to complete before redirecting to ensure it was captured. Simply using one 404.vue is the easiest solution for now.

Also I know there aren't any 404 analytics yet on this site but that should be added asap :)

[zebateira]

WIP PR for 404 here: #106 (includes analytics as well :) )

[zebateira]

@cwaring does this feel like it's complete? Or do you want another iteration after launch?

[cwaring]

It looks like we've covered all the burning issues now but we should do another round to actually check over optimisations and configuration, I haven't had time to go much deeper in this sprint.

Calling this complete for now so we can move onto the pre-flight transition!