Votre stockage · WordPress + WooCommerce
WooCommerce AWS S3
L’extension Alter Product comprend un module de stockage AWS S3 prêt à l’emploi. Conservez les groupes de fichiers pris en charge dans votre propre bucket privé, connectez-le dans WordPress et migrez les fichiers existants avec les outils de l’extension.
Alter Product ne facture pas de supplément de capacité pour agrandir ce stockage connecté. AWS facture à votre compte le stockage, les requêtes et le transfert. Votre hébergement WordPress et les règles habituelles du forfait et des sessions embed restent applicables.
Ces instructions suivent le guide de configuration de l’extension. Les libellés de la console AWS restent en anglais.
Stockage, distribution et coûts
S3 conserve les objets fichiers de l’extension. WordPress reste responsable de leur distribution autorisée au navigateur.
Un stockage privé pour l’extension
Le navigateur ne télécharge pas directement depuis S3. WordPress récupère et vérifie les fichiers du bucket privé, puis les distribue par ses propres endpoints. Laissez S3 CORS vide et Block Public Access activé ; il ne s’agit ni d’un bucket public ni d’une connexion directe à un CDN.
Le module couvre les groupes de fichiers Alter Product pris en charge. Connecter un bucket ne déplace pas tous les fichiers de WordPress et ne modifie pas les limites des outils intégrés.
Payer AWS pour les ressources utilisées
Alter Product ne facture aucun supplément pour augmenter la capacité du bucket connecté. Les frais AWS dépendent de l’utilisation, de la région et de la classe de stockage ; consultez les tarifs S3 actuels plutôt que de supposer un prix fixe.
Comme WordPress distribue les fichiers, ce trafic peut aussi être comptabilisé dans la bande passante de votre hébergement. S3 ne garantit ni l’absence de transfert facturé par l’hébergeur ni un débit serveur illimité.
Créer un bucket avec les paramètres pris en charge
Les noms des champs ci-dessous correspondent à la console AWS en anglais et au guide de configuration intégré à l’extension.
Créer un bucket à usage général
Connectez-vous à AWS, ouvrez Amazon S3 et sélectionnez General purpose buckets → Create bucket. Choisissez une région et un nom composé de lettres minuscules, de chiffres et de traits d’union, sans points. Copiez le nom complet du bucket, y compris tout suffixe ajouté par AWS.
- Appliquez les paramètres du tableau et choisissez Create bucket.
- Conservez le nom complet du bucket, sa région et l’identifiant à 12 chiffres du compte AWS de son propriétaire.
- Laissez Cross-origin resource sharing (CORS) vide. Les requêtes vers S3 proviennent du serveur WordPress.
| Champ AWS | Paramètre |
|---|---|
| Bucket type | General purpose |
| Bucket namespace | Account Regional namespace (recommandé) |
| Object Ownership | ACLs disabled / Bucket owner enforced |
| Block Public Access | Block all public access (les quatre paramètres) |
| Bucket Versioning | Enable |
| Default encryption | Server-side encryption with Amazon S3 managed keys (SSE-S3 / AES256) |
| Bucket Key | Disable |
| Advanced settings → Object Lock | Disable |
Exiger HTTPS
Ajoutez une règle de transport sans rendre le bucket public ni accorder l’accès aux objets.
Ajouter la politique du bucket
Ouvrez Permissions → Bucket policy → Edit. Remplacez les deux valeurs EXAMPLE-BUCKET par le nom complet du bucket. Si une politique existe déjà, conservez ses instructions et ajoutez cette règle après avoir vérifié l’ensemble du document.
- Vérifiez les messages de l’éditeur et choisissez Save changes.
- Confirmez que la règle a été enregistrée. Laissez Block all public access activé.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyInsecureTransport",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::EXAMPLE-BUCKET",
"arn:aws:s3:::EXAMPLE-BUCKET/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false",
"aws:PrincipalIsAWSService": "false"
}
}
}
]
}Créer un accès IAM restreint
Utilisez une politique dédiée à ce bucket et à ce préfixe, plutôt que AdministratorAccess ou AmazonS3FullAccess.
Créer la politique de l’extension
Dans IAM → Policies → Create policy → JSON, collez le document suivant. Remplacez chaque EXAMPLE-BUCKET par le nom complet du bucket. Le préfixe alter-product doit correspondre à Folder prefix dans WordPress ; modifiez-le dans chaque Resource d’objet si vous choisissez un autre préfixe.
- Validez la politique, choisissez Next et donnez-lui un nom, par exemple AlterProductS3Storage.
- Choisissez Create policy et conservez son nom pour configurer l’utilisateur.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ReadRequiredBucketControls",
"Effect": "Allow",
"Action": [
"s3:GetBucketVersioning",
"s3:GetBucketOwnershipControls",
"s3:GetBucketPublicAccessBlock",
"s3:GetEncryptionConfiguration"
],
"Resource": "arn:aws:s3:::EXAMPLE-BUCKET"
},
{
"Sid": "WriteAndReadVersionedPluginObjects",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObjectVersion"
],
"Resource": [
"arn:aws:s3:::EXAMPLE-BUCKET/alter-product/objects/*",
"arn:aws:s3:::EXAMPLE-BUCKET/alter-product/.storage-tests/*"
]
},
{
"Sid": "RecoverJournalOwnedObjects",
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::EXAMPLE-BUCKET/alter-product/objects/*"
},
{
"Sid": "DeleteOnlyConnectionTestVersions",
"Effect": "Allow",
"Action": "s3:DeleteObjectVersion",
"Resource": "arn:aws:s3:::EXAMPLE-BUCKET/alter-product/.storage-tests/*"
}
]
}Créer un utilisateur dédié et une clé d’accès
Choisissez IAM → Users → Create user. Laissez Provide user access to the AWS Management Console décoché.
- Choisissez Next → Attach policies directly et associez uniquement la politique ci-dessus. Terminez avec Create user.
- Ouvrez Security credentials → Access keys → Create access key pour cet utilisateur. Pour cette configuration manuelle de l’extension, choisissez Other → Next, puis Create access key.
- Enregistrez Access key ID et Secret access key dans un gestionnaire de mots de passe. Le secret n’est affiché qu’une seule fois. Saisissez-les directement dans WordPress via HTTPS, jamais dans des messages ou des captures d’écran.
Enregistrer et tester la connexion WordPress
Ouvrez Alter Product → Settings → Storage dans le tableau de bord HTTPS de la boutique. Choisissez AWS S3 et + / Add connection.
Saisir les informations de connexion
Sélectionnez New connection. Ces mêmes instructions intégrées sont disponibles sous AWS S3 setup guide.
- Choisissez Save connection et attendez la confirmation.
- Choisissez Test connection. Enregistrez les modifications avant de relancer un test.
- Vérifiez le résultat dans la boîte de dialogue et la colonne Last connection test. Les champs de clés vides après enregistrement sont normaux.
| Champ | Valeur |
|---|---|
| Bucket name | Nom complet du bucket, et non un ARN, une URL s3:// ou une adresse HTTPS ; sans points. |
| Folder prefix | alter-product, conformément à la politique IAM. Utilisez des lettres, chiffres, traits d’union, tirets bas et dossiers séparés ; pas de barre oblique initiale ou finale. |
| Bucket owner AWS account ID | Identifiant à 12 chiffres du compte du propriétaire, sans espaces. |
| AWS region | Région réelle du bucket. Le formulaire utilise eu-central-1 par défaut. |
| AWS access key ID / AWS secret access key | Paire de clés enregistrée de l’utilisateur IAM dédié. |
| Use temporary AWS credentials | Laissez décoché pour la clé de longue durée de cet utilisateur IAM. Activez uniquement pour des identifiants temporaires et fournissez l’AWS session token. |
Si le test de connexion échoue
Vérifiez le nom du bucket, son propriétaire, sa région, les paramètres requis et le préfixe exact dans WordPress et IAM. Laissez CORS vide ; ne désactivez pas la protection contre l’accès public.
Le bucket, le préfixe, le propriétaire et la région enregistrés identifient la connexion. Pour une autre destination, sélectionnez New connection. Edit → Reconnect sert à remplacer les identifiants tout en conservant les références de fichiers enregistrées.
Transmettez au support le résultat du test, sans clés d’accès. Un test réussi est nécessaire avant de choisir ce stockage S3 par défaut.
Choisir la destination par défaut et migrer les fichiers existants
Le choix de la destination par défaut et la migration sont deux opérations distinctes.
Utiliser S3 pour les nouveaux groupes
Choisissez Make default sur la ligne de la connexion enregistrée. L’extension teste la connexion et ne change la destination par défaut qu’après réussite. Cela concerne les nouveaux groupes de fichiers ; les groupes existants et leurs révisions ultérieures conservent leur destination enregistrée jusqu’à leur migration.
Déplacer les groupes existants pris en charge
Sauvegardez ensemble la base de données, les salts WordPress et les fichiers avant la première migration. Commencez dans un environnement de test ou avec un petit groupe. Ouvrez Migrate sur la ligne S3 cible ; ouvrir le panneau ne copie aucun fichier.
Auto migration couvre les groupes pris en charge situés hors de la destination choisie. Cette fonction ne garantit pas la migration des fichiers WordPress sans rapport avec l’extension.
- Choisissez Start migration. L’extension teste S3, prépare chaque groupe, le copie, le vérifie et bascule ses références.
- Gardez la page ouverte. Pause s’arrête après le groupe en cours ; Resume migration reprend la progression enregistrée. Si vous fermez la page, rouvrez-la pour reprendre l’envoi des tâches.
- Si un groupe échoue, consultez le message et Advanced, corrigez la cause puis reprenez. Ne répétez pas aveuglément une opération dont le résultat d’envoi est inconnu.
- Après Migration completed, testez la lecture normale des ressources, leur modification, les aperçus et l’accès aux fichiers de commande. Les nouveaux groupes créés pendant l’analyse peuvent nécessiter un autre passage.
Retirer une ligne ne supprime pas les fichiers stockés
Changez d’abord la destination par défaut si nécessaire. Remove retire la connexion de la liste, tandis que les fichiers existants et leurs identifiants enregistrés restent disponibles. Ce n’est pas une commande de nettoyage des objets AWS.
Partager le stockage entre les nœuds WordPress
Une destination S3 partagée peut réduire la dépendance au disque d’un seul nœud. Un répartiteur de charge nécessite toujours une installation WordPress correctement partagée.
Conditions pour plusieurs nœuds
Pour une installation WordPress derrière un répartiteur de charge, réunissez toutes ces conditions :
- Un point d’écriture SQL cohérent et un état partagé de la base de données de l’extension.
- Un répertoire uploads partagé pour les fichiers encore stockés localement et les sources de migration conservées.
- Les mêmes salts WordPress d’origine sur chaque nœud afin de garder lisibles les identifiants enregistrés et les fichiers chiffrés.
- Un répertoire temporaire privé par nœud pour les transferts.
- Une configuration cohérente de l’extension et l’accès au même bucket S3 privé et aux mêmes versions d’objets.
- Utilisez wpdb standard avec mysqli natif et des tables InnoDB. Les drop-ins de routage de base de données tels que HyperDB ne sont pas pris en charge ; la répartition de charge se situe ici au niveau HTTP.
Maintenir la restauration et la rotation des clés
Conservez ensemble la base de données, les salts et les versions de fichiers référencées.
Sauvegarder, reconnecter et vérifier
Utilisez Edit → Reconnect pour remplacer les identifiants de la même connexion enregistrée. Testez la lecture des fichiers actuels et historiques avant de retirer l’ancienne clé, y compris via les autres connexions enregistrées qui peuvent encore l’utiliser.
Gardez le versionnement S3 activé et conservez les versions référencées par l’extension. N’appliquez pas de nettoyage de cycle de vie qui supprimerait des versions historiques nécessaires. Testez la restauration conjointe de la base de données, des salts et des fichiers stockés.
Les identifiants temporaires expirent et nécessitent un nouveau jeton valide et de nouvelles clés ; l’extension ne les renouvelle pas automatiquement. Surveillez l’utilisation AWS et le transfert de l’hébergement à mesure que la boutique grandit.