From 708bfa7ad115fdc01d5b4a18c0c487e7b7217417 Mon Sep 17 00:00:00 2001 From: Kody Jackson Date: Tue, 29 Sep 2026 10:01:00 -0500 Subject: [PATCH] [docs] Fix broken links to '/guides/' paths (#50870) ## Problem There are several broken links within docs that reference `/guides/...`. These need to be updated to `/docs/guides/` to resolve correctly. ## Solution Updated links to resolve correctly ## Preview links If relevant, include links to changed pages for easy review access. TBD, waiting on build (unclear if this happens for external contributions). ## Review instructions 1. Navigate to the pages in the live/preview. 2. Click the links that were updated. ## Checklist Check all before review: - [x ] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) ## Summary by CodeRabbit * **Documentation** * Updated internal documentation links across API, Auth, Database, Functions, and troubleshooting guides to use the `/docs` paths. Co-authored-by: kodster28-happy-hour --- .../content/guides/api/handling-errors-in-supabase-js.mdx | 8 ++++---- .../content/guides/auth/choosing-a-server-package.mdx | 4 ++-- .../content/guides/database/extensions/pg_graphql.mdx | 2 +- apps/docs/content/guides/functions/auth-headers.mdx | 4 ++-- apps/docs/content/guides/functions/error-codes.mdx | 2 +- .../guides/functions/examples/mcp-server-mcp-lite.mdx | 4 ++-- .../restore-project-after-90-days-pause.mdx | 8 ++++---- 7 files changed, 16 insertions(+), 16 deletions(-) diff --git a/apps/docs/content/guides/api/handling-errors-in-supabase-js.mdx b/apps/docs/content/guides/api/handling-errors-in-supabase-js.mdx index eea070910be..f48afa826bb 100644 --- a/apps/docs/content/guides/api/handling-errors-in-supabase-js.mdx +++ b/apps/docs/content/guides/api/handling-errors-in-supabase-js.mdx @@ -61,7 +61,7 @@ Database calls (`select`, `insert`, `update`, `upsert`, `delete`, `rpc`) return | `details` | When `hint` and `message` aren't enough. Often contains the offending value, key, or row. | | `message` | As the human summary. Useful in UI strings, less useful for debugging. | -A full list of PostgREST error codes is in the [Error Codes reference](/guides/api/rest/postgrest-error-codes). +A full list of PostgREST error codes is in the [Error Codes reference](/docs/guides/api/rest/postgrest-error-codes). ## Branch on `error.code`, not `error.message` @@ -140,6 +140,6 @@ supabase.channel('room1').subscribe((status, err) => { ## Related -- [PostgREST Error Codes](/guides/api/rest/postgrest-error-codes) -- [Automatic retries with `supabase-js`](/guides/api/automatic-retries-in-supabase-js) -- [Securing your API](/guides/api/securing-your-api) +- [PostgREST Error Codes](/docs/guides/api/rest/postgrest-error-codes) +- [Automatic retries with `supabase-js`](/docs/guides/api/automatic-retries-in-supabase-js) +- [Securing your API](/docs/guides/api/securing-your-api) diff --git a/apps/docs/content/guides/auth/choosing-a-server-package.mdx b/apps/docs/content/guides/auth/choosing-a-server-package.mdx index 2bcaeac15e6..1c17750f8a3 100644 --- a/apps/docs/content/guides/auth/choosing-a-server-package.mdx +++ b/apps/docs/content/guides/auth/choosing-a-server-package.mdx @@ -58,7 +58,7 @@ const supabase = createServerClient( ) ``` -See the [server-side rendering guide](/guides/auth/server-side) for framework-specific setup. +See the [server-side rendering guide](/docs/guides/auth/server-side) for framework-specific setup. ## `@supabase/server` @@ -92,6 +92,6 @@ In a cookie-based framework you can compose the two — let `@supabase/ssr` own ## Next steps -- [Server-side rendering](/guides/auth/server-side) — set up `@supabase/ssr` for your framework. +- [Server-side rendering](/docs/guides/auth/server-side) — set up `@supabase/ssr` for your framework. - [`@supabase/server` reference](/docs/reference/server/introduction) — API for header-based server auth. - [`supabase-js` reference](/docs/reference/javascript/introduction) — the base JavaScript client. diff --git a/apps/docs/content/guides/database/extensions/pg_graphql.mdx b/apps/docs/content/guides/database/extensions/pg_graphql.mdx index ce5845773f0..e80c79de8de 100644 --- a/apps/docs/content/guides/database/extensions/pg_graphql.mdx +++ b/apps/docs/content/guides/database/extensions/pg_graphql.mdx @@ -106,7 +106,7 @@ Note that `pg_graphql` supports schema introspection, so you can connect any Gra comment on schema public is e'@graphql({"introspection": true})'; ``` -See the [upgrade notes](/guides/platform/upgrading#upgrading-to-pg_graphql-160) for details. +See the [upgrade notes](/docs/guides/platform/upgrading#upgrading-to-pg_graphql-160) for details. ## API diff --git a/apps/docs/content/guides/functions/auth-headers.mdx b/apps/docs/content/guides/functions/auth-headers.mdx index e0f982507ba..f358bbab67d 100644 --- a/apps/docs/content/guides/functions/auth-headers.mdx +++ b/apps/docs/content/guides/functions/auth-headers.mdx @@ -5,7 +5,7 @@ description: 'How the Authorization and apikey request headers and the verify_jw subtitle: 'How the Authorization and apikey headers and the verify_jwt platform check work' --- -Every request to an Edge Function passes through two layers of auth. First, a platform-level check (`verify_jwt`) runs before your code executes. Then, once the request reaches your handler, you decide what to do with the credentials the caller sent. This page is the reference for both layers. For the practical patterns built on top of them, see [Securing Edge Functions](/guides/functions/auth). +Every request to an Edge Function passes through two layers of auth. First, a platform-level check (`verify_jwt`) runs before your code executes. Then, once the request reaches your handler, you decide what to do with the credentials the caller sent. This page is the reference for both layers. For the practical patterns built on top of them, see [Securing Edge Functions](/docs/guides/functions/auth). ## Understanding authorization headers @@ -41,7 +41,7 @@ For migration compatibility, `verify_jwt` accepts publishable and secret keys on Use the `verify_jwt` flag to match how the function is called: - **Leave `verify_jwt` on** for functions that are only called with a user JWT, such as functions invoked from the client through `supabase.functions.invoke`. The platform rejects unauthenticated requests before they reach your code, and your handler can trust that a valid JWT is present. -- **Turn `verify_jwt` off** for functions that are called without an `Authorization` header, such as webhooks from external providers, or service-to-service calls that authenticate with an API key. These patterns are covered in [Securing Edge Functions](/guides/functions/auth). +- **Turn `verify_jwt` off** for functions that are called without an `Authorization` header, such as webhooks from external providers, or service-to-service calls that authenticate with an API key. These patterns are covered in [Securing Edge Functions](/docs/guides/functions/auth). Set the flag per function in `supabase/config.toml`: diff --git a/apps/docs/content/guides/functions/error-codes.mdx b/apps/docs/content/guides/functions/error-codes.mdx index e7e731d9e27..d7e48aeed33 100644 --- a/apps/docs/content/guides/functions/error-codes.mdx +++ b/apps/docs/content/guides/functions/error-codes.mdx @@ -174,7 +174,7 @@ export default { ## Authentication Errors These errors occur when the request contains a missing, malformed, or unsupported JWT token. Fixing them requires ensuring your requests include a valid authorization header, or disabling JWT verification for public endpoints. -For further information, see [Authorization headers](/docs/guides/functions/auth-headers) and [Securing Edge Functions](/guides/functions/auth). +For further information, see [Authorization headers](/docs/guides/functions/auth-headers) and [Securing Edge Functions](/docs/guides/functions/auth). ### UNAUTHORIZED_NO_AUTH_HEADER diff --git a/apps/docs/content/guides/functions/examples/mcp-server-mcp-lite.mdx b/apps/docs/content/guides/functions/examples/mcp-server-mcp-lite.mdx index 77cb3e8508b..74abb7decb6 100644 --- a/apps/docs/content/guides/functions/examples/mcp-server-mcp-lite.mdx +++ b/apps/docs/content/guides/functions/examples/mcp-server-mcp-lite.mdx @@ -278,7 +278,7 @@ When deploying MCP servers: - **Limit tool scope**: Only expose tools that are necessary for your use case - **Monitor usage**: Track tool calls and monitor for unusual activity -For more security guidance, see the [MCP security guide](/guides/getting-started/mcp#security-risks). +For more security guidance, see the [MCP security guide](/docs/guides/getting-started/mcp#security-risks). ## What's next @@ -295,6 +295,6 @@ With your MCP server running on Supabase Edge Functions, you can: - [mcp-lite on GitHub](https://github.com/fiberplane/mcp-lite) - [Model Context Protocol Spec](https://modelcontextprotocol.io/) -- [Supabase Edge Functions Docs](/guides/functions) +- [Supabase Edge Functions Docs](/docs/guides/functions) - [Deno Runtime Documentation](https://deno.land/) - [Fiberplane tutorial](https://blog.fiberplane.com/blog/mcp-lite-supabase-edge-functions/) diff --git a/apps/docs/content/troubleshooting/restore-project-after-90-days-pause.mdx b/apps/docs/content/troubleshooting/restore-project-after-90-days-pause.mdx index 31336ed26e9..9779f345c50 100644 --- a/apps/docs/content/troubleshooting/restore-project-after-90-days-pause.mdx +++ b/apps/docs/content/troubleshooting/restore-project-after-90-days-pause.mdx @@ -49,7 +49,7 @@ psql -d [CONNECTION_STRING] -f /path/to/backup_file.backup Some errors like `object already exists` are expected and can be safely ignored — they occur because the new project already has the default Supabase schemas applied. -See the [Restore Dashboard backup guide](/guides/platform/migrating-within-supabase/dashboard-restore) for detailed instructions and troubleshooting. +See the [Restore Dashboard backup guide](/docs/guides/platform/migrating-within-supabase/dashboard-restore) for detailed instructions and troubleshooting. ## Step 4: Restore Storage objects @@ -284,6 +284,6 @@ The script saves both source and target configs to a local `config_sync_