* feat: move storage settings
* feat: redirect
* feat: database settings in service area
* feat: move data api settings
* fix: revert data API placement
* feat: minor UX touches
* fix: simplify configuration group
* feat: references to database settings
* feat: references to storage settings
* fix: redirects and formatting
* fix: Import StorageMenu dynamically to avoid SSR issues with useLocalStorage
* fix: move Data API closer to semantic siblings
* fix: revert smart comma
* Shift bucket sort logic into storage explorer store
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
* Update all docs that make references to the database settings to find the connection strings.
Update all docs that references the database settings for the compute and disk page
* run prettier
* run pnpm format instead of prettier directly.
* first run through, fix grammar and reword awkward sentences
* Fix typos and remove unnecessary whitespace
* Apply suggestions from code review
Co-authored-by: Tyler <dshukertjr@gmail.com>
---------
Co-authored-by: Tyler <dshukertjr@gmail.com>
Partials are currently defined via MDX includes. This PR switches to pre-compile-time partials, which have a new syntax:
```
<$Partial path="path/to/file.mdx" />
```
## Rationale
This produces two improvements:
1. Partial substitution can occur in pipelines that don't use MDX compilation. For example, we can now do partial substitution before building the search index, so partial content will also be indexed.
2. After the App Router migration, the MDXProviders should've been deprecated, but were kept around for the sole reason of making partials work, and leading to us shipping unnecessary client-side code. We get a minor decrease in overall client bundle size (5.74 MB to 5.6 MB) by getting rid of the Providers.
## Breaking changes
Besides the change to partial syntax, the arguments are also less powerful than before because we are doing string substitution and don't have the full power of JS. Defining string variables is still possible (documented in the Contributing guide), and since that's all we actually do in practice, this shouldn't be too cumbersome. There is always the escape hatch of making a custom component for more complex content reuse cases.
* Add a note that schema needs to exist on Supabase before running
migrate. Otherwise one will receivie a following error
$ php artisan migrate
INFO Preparing database.
Creating migration table ........................................................................................................... 599.73ms FAIL
Illuminate\Database\QueryException
SQLSTATE[3F000]: Invalid schema name: 7 ERROR: no schema has been selected to create in at character 14 (Connection: pgsql, SQL: create table "migrations" ("id" serial not null
primary key, "migration" varchar(255) not null, "batch" integer not null))
at vendor/laravel/framework/src/Illuminate/Database/Connection.php:823
819▕ $this->getName(), $query, $this->prepareBindings($bindings), $e
820▕ );
821▕ }
822▕
➜ 823▕ throw new QueryException(
824▕ $this->getName(), $query, $this->prepareBindings($bindings), $e
825▕ );
826▕ }
827▕ }
+41 vendor frames
42 artisan:16
Illuminate\Foundation\Application::handleCommand()
* Apply suggestions from code review
---------
Co-authored-by: Vladimir Vuksan <vuksan-github@vuksan.com>
Co-authored-by: Charis <26616127+charislam@users.noreply.github.com>
Quick starts are missing the step to create an RLS policy, which can be
confusing if you choose to create the table from the Table Editor, and
subsequently can't select from it.
Update nextjs.mdx
The example env file created with `npx create-next-app -e with-supabase` is called .env.example, not .env.example.local. This updates the getting started doc to reflect that.
