3a91deb0a4
## Description Threads the field config to all "field subcomponents" through props, i.e. field label, description, error, etc. This way, the field config that controls any particular component is easily accessible and strongly typed, i.e. `props.field.maxLength`. This is true for both server and client components, whose server-side props are now also contextually typed. This behavior was temporarily removed in #7474 due to bloating HTML, but has since been resolved in #7620. This PR also makes significant improvements to component types by exporting explicit types for _every component of every field_, each with its own client/server variation. Now, a custom component can look something like this: ```tsx import type { TextFieldLabelServerComponent } from 'payload' import React from 'react' export const CustomLabel: TextFieldLabelServerComponent = (props) => { return ( <div>{`The max length of this field is: ${props?.field?.maxLength}`}</div> ) } ``` The following types are now available: ```ts import type { TextFieldClientComponent, TextFieldServerComponent, TextFieldLabelClientComponent, TextFieldLabelServerComponent, TextFieldDescriptionClientComponent, TextFieldDescriptionServerComponent, TextFieldErrorClientComponent, TextFieldErrorServerComponent, // ...and so one for each field } from 'payload' ``` BREAKING CHANGES: In order to strictly type these components, a few breaking changes have been made _solely to type definitions_. This only effects you if you are heavily using custom components. Old ```ts import type { ErrorComponent, LabelComponent, DescriptionComponent } from 'payload' ``` New: ```ts import type { FieldErrorClientComponent, FieldErrorServerComponent, FieldLabelClientComponent, FieldLabelServerComponent, FieldDescriptionClientComponent, FieldDescriptionServerComponent, // Note: these are the generic, underlying types of the more stricter types described above ^ // For example, you should use the type that is explicit for your particular field and environment // i.e. `TextFieldLabelClientComponent` and not simply `FieldLabelClientComponent` } from 'payload' ``` - [x] I have read and understand the [CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md) document in this repository. ## Type of change - [x] Bug fix (non-breaking change which fixes an issue) ## Checklist: - [x] I have added tests that prove my fix is effective or that my feature works - [x] Existing test suite passes locally with my changes
Payload Cloud Storage Plugin
This repository contains the officially supported Payload Cloud Storage plugin. It extends Payload to allow you to store all uploaded media in third-party permanent storage.
NOTE: If you are using Payload 3.0 and one of the following storage services, you should use one of following packages instead of this one:
| Service | Package |
|---|---|
| Vercel Blob | @payloadcms/storage-vercel-blob |
| AWS S3 | @payloadcms/storage-s3 |
| Azure | @payloadcms/storage-azure |
| Google Cloud Storage | @payloadcms/storage-gcs |
This package is now best used for implementing custom storage solutions or third-party storage services that do not have @payloadcms/storage-* packages.
Installation
pnpm add @payloadcms/plugin-cloud-storage
Usage
import { buildConfig } from 'payload'
import { cloudStoragePlugin } from '@payloadcms/plugin-cloud-storage'
export default buildConfig({
plugins: [
cloudStoragePlugin({
collections: {
'my-collection-slug': {
adapter: theAdapterToUse, // see docs for the adapter you want to use
},
},
}),
],
// The rest of your config goes here
})
Conditionally Enabling/Disabling
The proper way to conditionally enable/disable this plugin is to use the enabled property.
cloudStoragePlugin({
enabled: process.env.MY_CONDITION === 'true',
collections: {
'my-collection-slug': {
adapter: theAdapterToUse, // see docs for the adapter you want to use
},
},
}),
If the code is included in any way in your config but conditionally disabled in another fashion, you may run into issues such as Webpack Build Error: Can't Resolve 'fs' and 'stream' or similar because the plugin must be run at all times in order to properly extend the webpack config.
Features
Adapter-based Implementation
This plugin supports the following adapters:
However, you can create your own adapter for any third-party service you would like to use.
All adapters are implemented dev directory's Payload Config. See this file for examples.
Plugin options
This plugin is configurable to work across many different Payload collections. A * denotes that the property is required.
| Option | Type | Description |
|---|---|---|
collections * |
Record<string, CollectionOptions> | Object with keys set to the slug of collections you want to enable the plugin for, and values set to collection-specific options. |
enabled |
boolean to conditionally enable/disable plugin. Default: true. |
Collection-specific options:
| Option | Type | Description |
|---|---|---|
adapter * |
Adapter | Pass in the adapter that you'd like to use for this collection. You can also set this field to null for local development if you'd like to bypass cloud storage in certain scenarios and use local storage. |
disableLocalStorage |
boolean |
Choose to disable local storage on this collection. Defaults to true. |
disablePayloadAccessControl |
true |
Set to true to disable Payload's access control. More |
prefix |
string |
Set to media/images to upload files inside media/images folder in the bucket. |
generateFileURL |
GenerateFileURL | Override the generated file URL with one that you create. |
Payload Access Control
Payload ships with access control that runs even on statically served files. The same read access control property on your upload-enabled collections is used, and it allows you to restrict who can request your uploaded files.
To preserve this feature, by default, this plugin keeps all file URLs exactly the same. Your file URLs won't be updated to point directly to your cloud storage source, as in that case, Payload's access control will be completely bypassed and you would need public readability on your cloud-hosted files.
Instead, all uploads will still be reached from the default /:collectionSlug/file/:filename path. This plugin will "pass through" all files that are hosted on your third-party cloud service—with the added benefit of keeping your existing access control in place.
If this does not apply to you (your upload collection has read: () => true or similar) you can disable this functionality by setting disablePayloadAccessControl to true. When this setting is in place, this plugin will update your file URLs to point directly to your cloud host.
Credit
This plugin was created with significant help, and code, from Alex Bechmann and Richard VanBergen. Thank you!!