Currently, our entire investor/client/customer db is wrapped in our custom "Gully" RESTful API.

Because of security issues, I've had to transfer the domain and took a moment to upgrade the webhook protocol to an https client.

Moved from "www.calf.stoneydsp.com" to "www.bull.stoneydsp.com" but the TLS is taking a while so switched back.

Need to hot-swap once the cert is issued.

Priority: live

What kind of change does this PR introduce?

From now on; y'all need to be authenticated and logged in to view this while this is still a work in progress. That is a totally fair deal.

The user db is completely secure; I'm only storing an email address by default, but users may add custom full names, public usernames and websites, and add a public avatar to the bucket, if they so wish.

I only have the ability to see the account ID, the email address linked to it, and those optional elements highlighted above.

This will all need some sort of bureaucratic 'red tape' page explaining as such in legalese.

It shouldn't be necessary but I also shouldn't be wasting more time on those acting in bad faith.

The site will go public once it's ready.

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Go to '…'
2. Click on '…'
3. Scroll down to '…'
4. See error

Expected behavior

A clear and concise description of what you expected to happen.

Screenshots

If applicable, add screenshots to help explain your problem.

System information

• OS: [e.g. macOS, Windows]
• Browser (if applies) [e.g. chrome, safari]
• Version of supabase-js: [e.g. 6.0.2]
• Version of Node.js: [e.g. 10.10.0]

Additional context

Add any other context about the problem here.

At the moment, we've secured a Google Business profile and provided enough linkage elsewhere that Google's algos are starting to lump everything together correctly (there is some other user in some other user-space with the same username...)

Adding social media tags to the footer, which propagates to every page on our site, should enhance this linkage quite a bit.

Fairly high priority, easy work so will probably do this right away.

Chore

Describe the chore

Gotta move all the old CSS styling framework over to fit around Tailwind and PostCSS, but provided we can do that ok then it should prove to be a very beneficial bedrock layer, should be choose to be a bit less 'granular' with the CSS handling than the current implementation.

Careful balancing of new vs. old... 😉

Additional context

Switched from vanilla Js/JHTML to NextJs

Need to convert the icon from .png to .ico using CMakeRC.

We can do all our system and web app icons while we're at it. The templates are the ones in /share.

Priority medium; though it's easy fun and stress free work so might happen sooner than the rest 🤣

https://github.com/vercel/examples/blob/main/edge-middleware/image-response/README.md

Chore

Describe the chore

Add Discord to OAuth providers.

facebook url debugger suggesting the link to the preview img is "wrong".

Attempting shuffling some /'s for the desired effect.

Chore

Describe the chore

So, we have 'internals/generate-sitemap.mjs' currently generating a sitemap.xml as a post-build step. It uses a package named 'globby' to do a regex match for rendered destination filepaths in the '/app/' directory, then calls '.map()' on the results to populate them for use into a string insertion. The final string is formatted using Prettier, then written into the xml file in the public folder.

There is also an example for a dynamically-generated sitemap as a page, based on dynamically-generated pages; i.e., a blog page, which has no fixed size and the router count is expected to continue to grow; it's possible to use a slightly different approach (but which still, essentially, maps the found pages to an output) to generate a sitemap-as-a-page on the app router.

What I'd like to do is both.

It should be possible to do the 'globby' regex matching in a .tsx file where we export the results for usage in other places. Then, we can share the resulting object with both 'generate-sitemap.mjs' and the rendered sitemap-as-a-page.

It might make sense to do this as a NextJs/React component placed at the root of the 'app' folder. The other files can import it from there.

Additional context

Some very pseudo-code...

The globby bit

import { globby } from 'globby'

export default async function GlobPages() {
	const prettierConfig = await prettier.resolveConfig('./.prettierrc.js')
	const pages = await globby([
		'app/page.tsx',
		'app/**/page.tsx',
		'!app/_examples/**/page.tsx',
		'!app/_*/**/page.tsx'
	])

    return pages
}

Then I guess we can try passing as an argument to other functions... like generating the xml:

import { writeFileSync } from 'fs'
import { GlobPages } from '@/app/globpages'
import prettier from 'prettier'

async function generate(pages) {
	const sitemap = `
		<?xml version="1.0" encoding="UTF-8"?>
		<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
			${pages
			.map((page) => {
				const path = page
					.replace('app', '')
					.replace('.tsx', '')
					.replace('page', '');
				const route = path === '/page' ? '' : path;

				return `
					<url>
						<loc>${`https://www.stoneydsp.com${route}`}</loc>
					</url>`
						})
						.join('')}
				</urlset>

	const formatted = await prettier.format(sitemap, {
		...prettierConfig,
		parser: 'html',
	})

    writeFileSync('public/www_sitemap.xml', formatted)
}

const pages = GlobPages()

generate(pages)

And... generating the dynamic sitemap-as-a-page

import { GlobPages } from '@/app/globpages'

export default async function sitemap() {

  const { data: pages } = await GlobPages()

  return (
    pages?.map(({ id }) => ({
      url: `https://example.com/${id}`,
      lastModified: new Date(),
    })) ?? []
  )
}

Login page

Currently, any un-authenticated users attempting to access the site are redirected to the sign up/sign in page. Aside from the login form, this page doesn't really contain much meaningful info about the site - what are we signing up for/logging in to? etc.

While this isn't really a major issue - since I don't particularly expect nor want any traffic right now, during construction - I realize there will be some genuinely curious visitors here and there, who probably deserve to have a little more light shed on what they are seeing.

There is no major point in encouraging visitors to sign up to take a peek inside, nor any reason to deter them. It's open-source development, on a public-facing domain, and thus I expect all different kinds of footfall at any time. The catch is that I get to see what you're looking at and where you're calling from. This, too, should be clear, for the benefit of the more genuine audients and passers-by.

I will enable login with GitHub and some other carefully selected auth providers in due course, but at the very least, it might be nice to add to the login page a site description string, and perhaps a toast notification explaining the purpose of the site and it's current state.

Perhaps a link back to this repo and some resources, like the brand icon, would also add some confidence to visitors of the site when assessing it's veracity.

Again, I don't particularly expect these changes to bring in signees. It's courtesy on my part to provide some confidence to the visitors about what this page is...

Additional context

Added some middleware to deploy the HTTP headers to the Edge recently. Included some hooks to a private logger for testing purposes.

Ohh boy that thing is going crazy, hundreds of cache hits per minute...!

I'm ready to slide the OAuth over the whole thing, that's really gonna piss 'em off, lol. 😛

Bug report

The LinkedIn icon in the footer links with the wrong social media platform...

So far, I'm just running doxygen at the root of each 'to-be-featured' repo, harvesting the HTML output, and serving it as-is.

No build steps, no nuxt/vue/nodaemon or whatever. I much prefer this way, just working with old fashioned HTML files and DNS configs.

I do have a neat method for getting doxygen to spit out a mostly-formed vue/nuxt js project, but this IMO would be pure technical debt; Going from HTML, to some sub-language, just to output raw HTML again.

HTML is easy and it's secure. I'd like to stick with it for anything that has no right not being static HTML.

However, generating each project one by one is just too labour-intensive for maintenance when it comes to doxygen's more generous outputs, like projects with lots of different C++ classes, namespaces, files, and other stuff to document. We end up needing to make the usual, occasional minor change to a single line of HTML, for hundreds of HTML pages. Moreso, when these pages are not sitting side by side at the time/point of creation, it becomes tedious catching syntactical mis-matches between projects.

Once again, I am quite drawn to how team JUCE have configured their doxygen comments and documentation generation; it is, to quite a large extent, tied to their design as a library. Achieving the same architecture as this has always been an eventual goal of mine - it would be excellent having, for example, the CxxWin graphical application source files and the Biquad audio DSP files side by side in a portable library/namespace.

This is quite different to my current approach, where each project is currently still quite monolithic, though there are some efforts to at least lay the paths for the design I have in mind (modular structure and namespacing already somewhat at play).

I will need to make a decision between what is useful for my portfolio webpage, and what is useful for documenting my work for other coders, which of these is the bigger priority for at this moment in time, and then delegate the appropriate refactoring time as appropriate.

Honestly I need to be applying for actual gainful employment right now because I have like 0 money, no jokes. What else isn't a joke? The phrase "the cost of living".

poor skeleton ☠️

I'll get this thing rolling ASAP.

Chore

Needs to be reflected in the client handler also.

Some unnecessary files making it to prod. Use '.vercelignore' to remove.

Meanwhile, 404.html head tag needs a quick refresh...

Chore

Describe the chore

Analytics scripts, etc...

Chore

Describe the chore

Add Google to OAuth providers.

Chore

Describe the chore

Bring back the Supabase edge functions

At the moment, it seems doxygen's outputted HTML is - incredibly well-done, IMO - but also the lack of decent formatting on initial output is one tiny thing that causes me an over-reaction. I strongly dislike being unable to visually parse a file on a standard laptop screen. No worries, run eslint on it - fixed!

Oh except... the linting breaks the doxygen-generated "click here to view the source file"-type pages. My particular favourite part of the whole thing!

It looks like the doxygen way of creating those files uses HTML tags that care about EOL's and whitespace, for example by rendering them as such.

Need to figure an eslint rule for exclusion of just those lines of each of those pages. Possibly some manual work involved in the first few runs to be on the safe side.

Low priority, even though it's one of my favourite parts of what doxygen does and I broke it on the current deployment at some point.

Will happen but not today.

Chore

Describe the chore

Need to start adding some pages to the router, and clear up the dark/light mode global CSS so that all new pages are "just done".

Additional context

Some pages to add:

• projects/ and projects/<project_name> which we can create using .mdx from the existing project repos and instantiate as a Next.js blog (no more doxygen HTML on this side).
• /account already exists but should probably go on the navbar (for users who are authenticated and logged in, only)
• /docsand /wikiwhich can link with the GitHub pages content, which I suppose will continue to use the pre-existing doxygen creation we were doing (curse you, talwind/postcss on the nextjs starter! Too handy to walk away from, but now we need to somehow port a consistent brand theme between that and the native CSS used on the GitHub pages/wiki!)

Some pages and scripts still to go in...

Chore

Describe the chore

Need to create a generic Terms of Service and Privacy Policy due to login authentication function and cookie store.

Shopify has free generators for both.

Priority High

I messed around with the table styles in the CSS while laying out the initial idea for the home page (still in place and needs further development - tickets incoming).

Unfortunately I quite strongly dislike the way those doxygen pages look compared with having them more "on-brand" like every other developer does. This means... perhaps making a "non-docs" version of the table class without the extra padding.

I plan to re-generate the CSS from a fresh copy of the latest doxygen defaults, and simply move all of the customary over-writing into our "styles.css". It will be important to keep that doxygen default CSS file out of any future headers we generate from doxygen, because it breaks the CSS5 layering that it was created this way to do. Instead, the doxy CSS is to be kept imported as a layer, at pretty much the highest level (over-writing anything that comes before it), into our usual "styles.css" where the further customization happen at user-agent level.

Currently I might have to dig up the changes I made in the existing doxy CSS in the project and try to move them over to "styles.css" without breaking the current specificity.

The idea then would be that "doxygen.css" can simply be swapped out with every new doxygen release, to make full use of whatever new functionalities were bought in by the good dev.

Not really a major priority but probably a medium at least, for me...

Chore

Describe the chore

Finish porting the dark mode toggle Js, as currently found the 'app' project - probably needs to be Typescript, and pass the linting config.

Add the cookie for dark/light mode preference to the user db???

Trying to resolve workflow from production branch downwards:

- production
|- preview
  |- development
    |- feature/bug/issue/pr...

Might be better to pull from https links?

It's pretty much entirely just for show.

I am not foolish enough to attempt to start a business on my own right now. I'm a musician who has learned how to code; things like consumer rights, privacy policy, community engagement etc are way out of my wheelhouse. I don't have any interest with engaging with these subjects, either.

I am not foolish enough to attempt to manage some kind of e-commerce store with absolutely no previous experience.

I don't have the ego nor the enthusiasm to believe that I can generate enough interest to support a living wage with the resources I have a available to me.

I do have a Patreon account that I have never actually engaged with personally. I don't see myself in that 'content creator' world; I'm not offering a service to 'subscribe' to over here. I'm pretty much intending to close that down if I can prove the security of my website deployment in it's place.

All I am looking to do is to show that, as a developer, I am capable of creating these things, for you, my future employer.

I intend to offer the option to throw some coin into a tip jar; the user chooses their own amount, and there is an option to either pay it one-off, or pay on some sort of recurring plan (monthly, yearly, whatever you want - the word "subscription" is a total misnomer, IMO). There is a suggested amount of 2 EUR, but again, the user can specify whatever they want.

The login function was pretty much a forced decision to keep the wannabe-hackerz out. As soon as I started messing with payment processors, y'all thought I was Steven Slate cruising on a 10m dollar yacht with some sort of yearly subscription plan, didn't you?

No - rather, it's my responsibility to keep the info of my users safe. If somebody does want to tip me enough to buy a coffee (the suggested amount), then I'm not having them get ripped off for it by man-in-the-middle attacks.

I'm not selling product licenses, I'm not going into business, I'm not trying to compete with you, oh glorious company who keeps trying to hack my Stripe account - rather, I'm just trying to entice you into hiring me as a competent developer.

That is simply all there is to it.

Thanks for reading!

Improve documentation

Literally levelled up by a few frameworks at a time, but haven't had the chance to stop and even write a single sentence about any of it on the actual page, where it belongs!

Nice easy way to get deeper into NextJs and get that landing page back on track at once.

Describe the bug

Dead.

Screenshots

Additional context

Time to step off.

Chore

Describe the chore

Need to get the old theme back asap so we can start opening up some content to anonymous traffic.

Additional context

Need to transfer the essential parts of my custom CSS, and the stuff from doxygen's theme that we want to keep, and bring them in. The Tailwind config is actually pretty well aligned with my own preferences (few hard-coded pixel values, instead prefer em units with pow2 numbers) and I think it will be possible to over-ride some stuff at the config level and be more or less back to the previous theme. Then it is a case of styling components, mostly.

Also the create-next-app tailwind config file is not compatible with the npx tailwindcss init --full config file??? Aghh annoying. We'll see about that, because the tailwindcss "full" version opens up most everything that I think we will need, but breaks the border-foreground/20 of the base layer in the globals.css...

Bug report

It's been almost a week of successful radio silence on the domain activity. However, minutes after posting about some of the issues I've had on this project, I just received the following friendly watchful reminder, this time from Vienna - but probably just another VPN:

logs_result_2023_10_18_1609.csv

logs_result_2023_10_18_1609.json

Meh. All 404's. Just an attempt to creep me out, possibly having read my post on the vercel issues page...

Currently the site is built in a very split-up approach where there are lots of sub-domains that should probably just be sub-pages instead; currently there would be some work involved to have a generic cookie securely shared across each sub-domain to remember things like light/dark mode toggle user prefs. Other large elements like images and fonts are also being distributed too widely for a one-source static HTML website as a result of this design.

I will prune a few elements but keep some things as they are also, because the sub-domain level of control is something I intend to utilize quite a bit as things progress.

would be nice, could be serverless...

Bug report

Sorry mighty Megatron, that last issue was a bit insulting wasn't it?

This wannabe-hacka dude is more like Cy-Kill, being a Go Bot and all.

Cy-Kill is scary... not really

Just like all of my repos since as long as I can recall, this repo has got a massive number of page views and clones (I haven't cloned my own repo once) but, just like all the others, only two views; me, and you.

You better hope you weren't dumb enough to be logged in when you were over here.

Look. it's Friday, you clearly are mentally ill if you're trying this relentlessly to hack me, an unemployed recovering addict who can't afford a week's worth of groceries right now.

Get some sunshine, life is fucking brief you know?

Bug report

Just need to port the old content over and fix some broken links. Will be a relief to finish the docs pages.

Chore

Describe the chore

Excellent Nextjs script...

...and a TS implementation.

Chore

Describe the chore

Need to bring the API edge functions which we still plan to implement over from vanilla Js to Nextjs. Same for webhooks etc.

Additional context

Switch from vanilla Js to Next Js