Dein Speicher · WordPress + WooCommerce
WooCommerce AWS S3
Das Alter Product-Plugin enthält ein fertiges AWS-S3-Speichermodul. Speichere unterstützte Dateigruppen des Plugins in deinem eigenen privaten Bucket, verbinde ihn in WordPress und migriere vorhandene Dateien mit den Werkzeugen des Plugins.
Alter Product erhebt keine zusätzliche Speichergebühr für die Erweiterung dieses verbundenen Speichers. AWS berechnet deinem Konto Speicher, Anfragen und Datenübertragung. Dein WordPress-Hosting sowie die üblichen Regeln für den Tarif und Einbettungssitzungen gelten weiterhin.
Die Anweisungen folgen der Einrichtungsanleitung im Plugin. Die Bezeichnungen der AWS-Konsole bleiben auf Englisch.
Speicherung, Auslieferung und Kosten
S3 speichert die Dateiobjekte des Plugins. WordPress bleibt für die autorisierte Auslieferung an den Browser zuständig.
Ein privates Backend für das Plugin
Der Browser lädt nicht direkt von S3 herunter. WordPress ruft Dateien aus dem privaten Bucket ab, überprüft sie und liefert sie anschließend über eigene Endpunkte aus. Lass S3 CORS leer und Block Public Access aktiviert; dies ist weder ein öffentlicher Bucket noch eine direkte CDN-Verbindung.
Das Modul umfasst unterstützte Alter Product-Dateigruppen. Das Verbinden eines Buckets verschiebt nicht jede Datei in WordPress und ändert keine Limits für eingebettete Werkzeuge.
AWS für die genutzten Ressourcen bezahlen
Für die Erweiterung der Speicherkapazität deines verbundenen Buckets erhebt Alter Product keine zusätzliche Gebühr. Die AWS-Kosten hängen von Nutzung, Region und Speicherklasse ab; prüfe die aktuelle S3-Preisliste, statt von einem festen Preis auszugehen.
Da WordPress die Dateien ausliefert, kann der Datenverkehr auch auf die Bandbreite deines Hostings angerechnet werden. S3 verspricht weder ein Hosting ohne Datenübertragung noch unbegrenzten Serverdurchsatz.
Einen Bucket mit den unterstützten Einstellungen erstellen
Die folgenden Feldnamen entsprechen der englischen AWS-Konsole und der im Plugin integrierten Einrichtungsanleitung.
Einen Bucket für allgemeine Zwecke erstellen
Melde dich bei AWS an, öffne Amazon S3 und wähle General purpose buckets → Create bucket. Wähle eine Region und einen Namen aus Kleinbuchstaben, Zahlen und Bindestrichen, ohne Punkte. Kopiere den vollständigen Bucket-Namen einschließlich eines gegebenenfalls von AWS hinzugefügten Suffixes.
- Übernimm die Einstellungen aus der Tabelle und wähle Create bucket.
- Bewahre den vollständigen Bucket-Namen, die Region und die 12-stellige AWS-Konto-ID des Bucket-Eigentümers auf.
- Lass Cross-origin resource sharing (CORS) leer. Anfragen an S3 kommen vom WordPress-Server.
| AWS-Feld | Einstellung |
|---|---|
| Bucket type | General purpose |
| Bucket namespace | Account Regional namespace (empfohlen) |
| Object Ownership | ACLs disabled / Bucket owner enforced |
| Block Public Access | Block all public access (alle vier Einstellungen) |
| Bucket Versioning | Enable |
| Default encryption | Server-side encryption with Amazon S3 managed keys (SSE-S3 / AES256) |
| Bucket Key | Disable |
| Advanced settings → Object Lock | Disable |
HTTPS vorschreiben
Füge eine Transportregel hinzu, ohne den Bucket öffentlich zu machen oder Objektzugriff zu gewähren.
Die Bucket-Richtlinie hinzufügen
Öffne Permissions → Bucket policy → Edit. Ersetze beide EXAMPLE-BUCKET-Werte durch deinen vollständigen Bucket-Namen. Falls bereits eine Richtlinie existiert, behalte ihre Anweisungen bei und füge diese Regel nach Prüfung des gesamten Dokuments hinzu.
- Prüfe die Meldungen des Editors und wähle Save changes.
- Bestätige, dass die Regel gespeichert wurde. Lass Block all public access aktiviert.
{
"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"
}
}
}
]
}Eingeschränkten IAM-Zugriff erstellen
Verwende eine eigene Richtlinie für diesen Bucket und dieses Präfix statt AdministratorAccess oder AmazonS3FullAccess.
Die Richtlinie für das Plugin erstellen
Füge unter IAM → Policies → Create policy → JSON das folgende Dokument ein. Ersetze jedes EXAMPLE-BUCKET durch den vollständigen Bucket-Namen. Das Präfix alter-product muss Folder prefix in WordPress entsprechen; passe es in jedem Objekt-Resource an, wenn du ein anderes Präfix wählst.
- Validiere die Richtlinie, wähle Next und vergib einen Namen wie AlterProductS3Storage.
- Wähle Create policy und bewahre den Namen für die Benutzereinrichtung auf.
{
"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/*"
}
]
}Einen eigenen Benutzer und Zugriffsschlüssel erstellen
Wähle IAM → Users → Create user. Lass Provide user access to the AWS Management Console deaktiviert.
- Wähle Next → Attach policies directly und füge ausschließlich die obige Richtlinie hinzu. Schließe Create user ab.
- Öffne beim Benutzer Security credentials → Access keys → Create access key. Wähle für diese manuelle Plugin-Einrichtung Other → Next und anschließend Create access key.
- Speichere Access key ID und Secret access key in einem Passwortmanager. Der geheime Schlüssel wird nur einmal angezeigt. Gib beide direkt über HTTPS in WordPress ein, nicht in Nachrichten oder Screenshots.
Die WordPress-Verbindung speichern und testen
Öffne im HTTPS-Dashboard des Shops Alter Product → Settings → Storage. Wähle AWS S3 und + / Add connection.
Die Verbindungsdaten eingeben
Wähle New connection. Dieselbe integrierte Anleitung findest du unter AWS S3 setup guide.
- Wähle Save connection und warte auf die Bestätigung.
- Wähle Test connection. Speichere Änderungen, bevor du erneut testest.
- Prüfe das Ergebnis im Dialog und in der Spalte Last connection test. Leere Schlüsselfelder nach dem Speichern sind beabsichtigt.
| Feld | Wert |
|---|---|
| Bucket name | Vollständiger Bucket-Name, kein ARN, keine s3://-URL und keine HTTPS-Adresse; ohne Punkte. |
| Folder prefix | alter-product, passend zur IAM-Richtlinie. Verwende Buchstaben, Zahlen, Bindestriche, Unterstriche und getrennte Ordner; kein Schrägstrich am Anfang oder Ende. |
| Bucket owner AWS account ID | Die 12-stellige Konto-ID des Eigentümers ohne Leerzeichen. |
| AWS region | Die tatsächliche Region des Buckets. Im Formular ist eu-central-1 voreingestellt. |
| AWS access key ID / AWS secret access key | Das gespeicherte Schlüsselpaar des eigens angelegten IAM-Benutzers. |
| Use temporary AWS credentials | Für den langfristigen Schlüssel dieses IAM-Benutzers deaktiviert lassen. Nur für temporäre Anmeldedaten aktivieren und dann den AWS session token angeben. |
Wenn der Verbindungstest fehlschlägt
Prüfe Bucket-Name, Eigentümer, Region, erforderliche Bucket-Einstellungen und das genaue Präfix in WordPress und IAM. Lass CORS leer; deaktiviere nicht den Schutz vor öffentlichem Zugriff.
Der gespeicherte Bucket, das Präfix, der Eigentümer und die Region bestimmen die Verbindung. Wähle für ein anderes Ziel New connection. Edit → Reconnect ersetzt Anmeldedaten und behält dieselben gespeicherten Dateiverweise bei.
Gib dem Support das Testergebnis ohne Zugriffsschlüssel weiter. Ein erfolgreicher Verbindungstest ist erforderlich, bevor du dieses S3 als Standard auswählst.
Den Standard wählen und vorhandene Dateien migrieren
Das Standardziel festlegen und Dateien migrieren sind getrennte Aktionen.
S3 für neue Gruppen verwenden
Wähle in der Zeile der gespeicherten Verbindung Make default. Das Plugin testet die Verbindung und ändert den Standard nur bei Erfolg. Dies gilt für neue Dateigruppen; vorhandene Gruppen und spätere Revisionen behalten bis zur Migration ihr gespeichertes Ziel.
Unterstützte vorhandene Gruppen verschieben
Sichere vor der ersten Migration Datenbank, WordPress-Salts und Dateien gemeinsam. Beginne mit einer Testumgebung oder einer kleinen Gruppe. Öffne Migrate in der Zeile des Ziel-S3; das bloße Öffnen des Panels kopiert noch keine Dateien.
Die automatische Migration umfasst unterstützte Gruppen außerhalb des gewählten Ziels. Sie verspricht nicht, sonstige WordPress-Dateien zu migrieren.
- Wähle Start migration. Das Plugin testet S3, bereitet jede Gruppe vor, kopiert und überprüft sie und stellt ihre Verweise um.
- Lass die Seite geöffnet. Pause hält nach der aktuellen Gruppe an; Resume migration setzt den gespeicherten Fortschritt fort. Öffne die Seite nach dem Schließen erneut, damit weitere Arbeitsschritte gestartet werden.
- Prüfe bei einem Gruppenfehler die Meldung und Advanced, behebe die Ursache und setze die Migration fort. Wiederhole keine Operation blind, deren Upload-Ergebnis unbekannt ist.
- Prüfe nach Migration completed das normale Lesen von Ressourcen, Bearbeiten, Vorschauen und den Zugriff auf Bestelldateien. Während des Scans neu angelegte Gruppen benötigen möglicherweise einen weiteren Durchlauf.
Das Entfernen einer Zeile löscht keine gespeicherten Dateien
Wechsle gegebenenfalls zuerst den Standard. Remove nimmt die Verbindung aus der Liste; bestehende Dateien und ihre gespeicherten Anmeldedaten bleiben verfügbar. Dies ist kein Befehl zum Bereinigen von AWS-Objekten.
Speicher zwischen WordPress-Knoten teilen
Ein gemeinsames S3-Ziel kann die Abhängigkeit von der Dateifestplatte eines einzelnen Knotens verringern. Ein Load Balancer benötigt weiterhin eine korrekt gemeinsam genutzte WordPress-Installation.
Anforderungen für mehrere Knoten
Stelle für eine WordPress-Installation hinter einem Load Balancer all diese Voraussetzungen gemeinsam sicher:
- Eine konsistente SQL-Schreibinstanz und ein gemeinsamer Datenbankzustand des Plugins.
- Ein gemeinsames uploads-Verzeichnis für noch lokal gespeicherte Dateien und aufbewahrte Migrationsquellen.
- Dieselben ursprünglichen WordPress-Salts auf jedem Knoten, damit gespeicherte Anmeldedaten und verschlüsselte Dateien lesbar bleiben.
- Ein privates temporäres Verzeichnis pro Knoten für Übertragungsaufgaben.
- Eine einheitliche Plugin-Konfiguration und Zugriff auf denselben privaten S3-Bucket und dieselben Objektversionen.
- Verwende Standard-wpdb mit nativem mysqli und InnoDB-Tabellen. Datenbank-Routing-Drop-ins wie HyperDB werden nicht unterstützt; die Lastverteilung erfolgt hier auf HTTP-Ebene.
Wiederherstellung und Schlüsselwechsel funktionsfähig halten
Bewahre Datenbank, Salts und referenzierte Dateiversionen gemeinsam auf.
Sichern, neu verbinden und überprüfen
Verwende Edit → Reconnect, um Anmeldedaten derselben gespeicherten Verbindung zu ersetzen. Teste vor dem Stilllegen des alten Schlüssels das Lesen aktueller und historischer Dateien, auch über andere gespeicherte Verbindungen, die ihn möglicherweise noch nutzen.
Lass die S3-Versionierung aktiviert und bewahre vom Plugin referenzierte Versionen auf. Verwende keine Lebenszyklusbereinigung, die benötigte historische Versionen löscht. Teste die gemeinsame Wiederherstellung von Datenbank, Salts und gespeicherten Dateien.
Temporäre Anmeldedaten laufen ab und benötigen einen neuen gültigen Token sowie Schlüssel; das Plugin erneuert sie nicht automatisch. Überwache bei wachsendem Shop die AWS-Nutzung und den Hosting-Datentransfer.