From ca5924646db18fa4e6968b333131ab1c0e79e045 Mon Sep 17 00:00:00 2001 From: lukinovec Date: Fri, 6 Jan 2023 15:34:04 +0100 Subject: [PATCH] Add and fix heading IDs (#232) --- source/docs/v3/cached-lookup.blade.md | 2 +- source/docs/v3/event-system.blade.md | 2 +- source/docs/v3/features/user-impersonation.blade.md | 2 +- source/docs/v3/integrations/nova.blade.md | 2 +- source/docs/v3/integrations/sanctum.blade.md | 4 ++-- source/docs/v3/session-scoping.blade.md | 4 ++-- source/docs/v3/single-database-tenancy.blade.md | 2 +- source/docs/v3/tenancy-bootstrappers.blade.md | 6 +++--- source/docs/v3/tenant-aware-commands.blade.md | 2 +- source/docs/v3/tenants.blade.md | 2 +- source/docs/v3/testing.blade.md | 6 +++--- 11 files changed, 17 insertions(+), 17 deletions(-) diff --git a/source/docs/v3/cached-lookup.blade.md b/source/docs/v3/cached-lookup.blade.md index 24dc28b..e8675c1 100644 --- a/source/docs/v3/cached-lookup.blade.md +++ b/source/docs/v3/cached-lookup.blade.md @@ -32,7 +32,7 @@ DomainTenantResolver::$cacheTTL = 3600; DomainTenantResolver::$cacheStore = 'redis'; ``` -## Cache invalidation +## Cache invalidation {#cache-invalidation} Updating and saving a Tenant model's attributes will cause the cached entry for this model to be invalidated when `DomainTenantResolver::$shouldCache` is set to `true`. diff --git a/source/docs/v3/event-system.blade.md b/source/docs/v3/event-system.blade.md index a479b9f..c7c4eea 100644 --- a/source/docs/v3/event-system.blade.md +++ b/source/docs/v3/event-system.blade.md @@ -52,7 +52,7 @@ The `JobPipeline` is a simple, yet **extremely powerful** class that lets you ** You may use a job pipeline like any other listener, so you can register it in the `TenancyServiceProvider`, `EventServiceProvider` using the `$listen` array, or in any other place using `Event::listen()` — up to you. -## Creating job pipelines {creating-job-pipelines} +## Creating job pipelines {#creating-job-pipelines} To create a job pipeline, start by specifying the jobs you want to use: diff --git a/source/docs/v3/features/user-impersonation.blade.md b/source/docs/v3/features/user-impersonation.blade.md index ee7a7cc..2d73a5b 100644 --- a/source/docs/v3/features/user-impersonation.blade.md +++ b/source/docs/v3/features/user-impersonation.blade.md @@ -30,7 +30,7 @@ If the impersonation succeeds, the token is deleted from the database. All tokens expire after 60 seconds by default, and this TTL can be customized — see the section at the very bottom. -## Enabling the feature +## Enabling the feature {#enabling-the-feature} To enable this feature, go to your `config/tenancy.php` file and make sure the following class is in your `features` part of the config: diff --git a/source/docs/v3/integrations/nova.blade.md b/source/docs/v3/integrations/nova.blade.md index 7a41d1e..865674a 100644 --- a/source/docs/v3/integrations/nova.blade.md +++ b/source/docs/v3/integrations/nova.blade.md @@ -6,7 +6,7 @@ section: content # Laravel Nova {#laravel-nova} -## In the central app +## In the central app {#in-the-central-app} If you wish to use Laravel Nova in the central application (to manage tenants), you need to make a small change to the Nova migrations, they expect your model primary keys to always be unsigned big integers, but your tenants might be using `string` ids. diff --git a/source/docs/v3/integrations/sanctum.blade.md b/source/docs/v3/integrations/sanctum.blade.md index ddfc808..7153b11 100644 --- a/source/docs/v3/integrations/sanctum.blade.md +++ b/source/docs/v3/integrations/sanctum.blade.md @@ -10,7 +10,7 @@ section: content Laravel Sanctum works with Tenancy out of the box, with the exception of the `sanctum.csrf-cookie` route. You can make some small changes to make the route work. -### Making the csrf-cookie route work in the tenant app +### Making the csrf-cookie route work in the tenant app {#csrf-cookie-route-in-tenant-app} To make the `sanctum.csrf-cookie` route work in the tenant app, do the following: @@ -29,7 +29,7 @@ Route::group(['prefix' => config('sanctum.prefix', 'sanctum')], static function }); ``` -### Making the csrf-cookie route work both in the central and the tenant app +### Making the csrf-cookie route work both in the central and the tenant app {#csrf-cookie-route-in-both-apps} To use the `sanctum.csrf-cookie` route in both the central and the tenant apps: diff --git a/source/docs/v3/session-scoping.blade.md b/source/docs/v3/session-scoping.blade.md index 7fc5b67..6f36976 100644 --- a/source/docs/v3/session-scoping.blade.md +++ b/source/docs/v3/session-scoping.blade.md @@ -16,7 +16,7 @@ Here's how you can prevent this. Since the databases are automatically separated, simply using the database as the session driver will make this problem disappear altogether. -## Storing sessions in Redis {storing-sessions-in-redis} +## Storing sessions in Redis {#storing-sessions-in-redis} This is the same solution as using the DB session driver. If you use the [`RedisTenancyBootstrapper`]({{ $page->link('tenancy-bootstrappers') }}), your Redis databases will be automatically separated for your tenants, and as such, any sessions stored in those Redis databases will be scoped correctly. @@ -24,4 +24,4 @@ This is the same solution as using the DB session driver. If you use the [`Redis Alternatively, you may use the `Stancl\Tenancy\Middleware\ScopeSessions` middleware on your tenant routes to make sure that any attempts to manipulate the session will result in a 403 unauthorized response. -This will work with all storage drivers, **but only assuming you use a domain per tenant.** If you use path identification, you **need** to store sessions in the database (if using multi-DB tenancy), or you need to use single-DB tenancy (which is probably more common with path identification). \ No newline at end of file +This will work with all storage drivers, **but only assuming you use a domain per tenant.** If you use path identification, you **need** to store sessions in the database (if using multi-DB tenancy), or you need to use single-DB tenancy (which is probably more common with path identification). diff --git a/source/docs/v3/single-database-tenancy.blade.md b/source/docs/v3/single-database-tenancy.blade.md index acf39c7..d2cae60 100644 --- a/source/docs/v3/single-database-tenancy.blade.md +++ b/source/docs/v3/single-database-tenancy.blade.md @@ -88,7 +88,7 @@ And this will automatically scope the `Comment::all()` call to the current tenan # Database considerations {#database-considerations} -### Unique indexes {unique-indexes} +### Unique indexes {#unique-indexes} If you'd have a unique index such as: diff --git a/source/docs/v3/tenancy-bootstrappers.blade.md b/source/docs/v3/tenancy-bootstrappers.blade.md index 3975142..389e798 100644 --- a/source/docs/v3/tenancy-bootstrappers.blade.md +++ b/source/docs/v3/tenancy-bootstrappers.blade.md @@ -33,7 +33,7 @@ The filesystem bootstrapper makes your app's `Storage` facade and the `storage_p > Note: If you want to bootstrap filesystem tenancy differently (e.g. provision an S3 bucket for each tenant), you can absolutely do that. Take a look at the package's bootstrappers to get an idea of how to write one yourself, and feel free to implement it any way you want. -### Storage path helper +### Storage path helper {#storage-path-helper} The bootstrapper suffixes the path returned by `storage_path()` to make the helper tenant-aware. @@ -46,7 +46,7 @@ Since `storage_path()` will be suffixed, your folder structure will look like th Logs will be saved in `storage/logs` regardless of any changes to `storage_path()` and regardless of the tenant. -### Storage facade +### Storage facade {#storage-facade} The bootstrapper also makes the `Storage` facade tenant-aware by suffixing the roots of disks listed in `config('tenancy.filesystem.disks')` and by overriding the disk roots in `config('tenancy.filesystem.root_override')` (disk root = the disk path used by the `Storage` facade). @@ -65,7 +65,7 @@ The root of each disk listed in `config('tenancy.filesystem.disks')` will be suf To make the tenant-aware `Storage` facade work with a custom disk, add the disk's name to `config('tenancy.filesystem.disks')` and if the disk is local, override its root in `config('tenancy.filesystem.root_override')` as shown above. With S3, overriding the disk roots is not necessary – `Storage::disk('s3')->path('foo.txt')` will return `/tenant42/foo.txt`. -### Assets +### Assets {#assets} The filesystem bootstrapper makes the `asset()` helper link to the files *of the current tenant*. By default, the bootstrapper makes the helper output a URL pointing to the TenantAssetsController (`/tenancy/assets/...`), which returns a file response: diff --git a/source/docs/v3/tenant-aware-commands.blade.md b/source/docs/v3/tenant-aware-commands.blade.md index 6e1b3f7..fa92a71 100644 --- a/source/docs/v3/tenant-aware-commands.blade.md +++ b/source/docs/v3/tenant-aware-commands.blade.md @@ -51,7 +51,7 @@ class BarCommand extends Command } ``` -### Custom implementation +### Custom implementation {#custom-implementation} If you want more control, you may implement this functionality yourself by simply accepting a `tenant_id` argument and then inside `handle()` doing something like this: ```php diff --git a/source/docs/v3/tenants.blade.md b/source/docs/v3/tenants.blade.md index c85acdd..66b9af0 100644 --- a/source/docs/v3/tenants.blade.md +++ b/source/docs/v3/tenants.blade.md @@ -16,7 +16,7 @@ The base model has the following features on top of the ones that are necessary - Data column trait — lets you store arbitrary keys. Attributes that don't exist as columns on your `tenants` table go to the `data` column as serialized JSON. - Id generation trait — when you don't supply an ID, a random uuid will be generated. An alternative to this would be using AUTOINCREMENT columns. If you wish to use numerical ids, change the `create_tenants_table` migration to use `bigIncrements()` or some such column type, and set `tenancy.id_generator` config to null. That will disable the ID generation altogether, falling back to the database's autoincrement mechanism. -## Tenant Model +## Tenant Model {#tenant-model} **Most** applications using this package will want domain/subdomain identification and tenant databases. To do this, create a new model, e.g. `App\Tenant`, that looks like this: ```php diff --git a/source/docs/v3/testing.blade.md b/source/docs/v3/testing.blade.md index 16b40b6..45f617e 100644 --- a/source/docs/v3/testing.blade.md +++ b/source/docs/v3/testing.blade.md @@ -10,7 +10,7 @@ section: content TODO: Review -## Events +## Events {#events} Keep in mind that the package makes heavy use of events, so if you use `Event::fake()` anywhere in your tests, tenancy initialization and related processes might break. @@ -30,7 +30,7 @@ Event::fake(); To test your central app, just write normal Laravel tests. -## Tenant app {#central-app} +## Tenant app {#tenant-app} Note: If you're using multi-database tenancy & the automatic mode, it's not possible to use `:memory:` SQLite databases or the `RefreshDatabase` trait due to the switching of default database. @@ -55,7 +55,7 @@ class TestCase // extends ... public function initializeTenancy() { $tenant = Tenant::create(); - + tenancy()->initialize($tenant); }