| 开发者 | todotweb |
|---|---|
| 更新时间 | 2026年7月21日 20:40 |
| PHP版本: | 8.1 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
photolab folder to /wp-content/plugins/.wp-content/uploads/Photolab/photos/ directory is protected via an .htaccess file denying direct access. This works on Apache servers with mod_rewrite enabled.
If using Nginx, .htaccess files are not read. Add a rule to your server block to protect the directory:
location ~* /wp-content/uploads/Photolab/photos/ {
deny all;
return 403;
}
Consult your hosting provider documentation to apply this configuration.The plugin handles high volumes, up to 2000+ photos per album. Uploads use chunks of 5 files (filterable via photolab_chunk_size) for compatibility with shared hosting.
Yes. If Imagick is unavailable, Photolab automatically uses GD for watermarking. Performance on large volumes will be reduced compared to Imagick.
No. The watermark is applied to a copy (saved in wp-content/uploads/Photolab/watermarked/). Originals are stored separately and protected from public access.
Watermarking is inline: it runs during the same HTTP request as the upload chunk. Photos are watermarked immediately as they arrive, not via a background queue. The /upload/chunk endpoint returns after processing completes. Download is blocked until the photo reaches the watermarked state (HTTP 425).
The client sends a heartbeat every 30 seconds. If the server receives no heartbeat for 5 minutes (or 10 minutes if none was ever received), a recovery job transitions the album to aborted. From the admin panel you can reset the album (POST /albums/{id}/reset) to resume, or delete it. Already-uploaded photos remain as valid WooCommerce products.
Yes, up to 3 concurrent album uploads per user. Attempts beyond this limit return HTTP 429. Albums with the same name already in flight for the same user return HTTP 409.
The client can retry the same /upload/chunk with an Idempotency-Key header. The original response is replayed from a transient (TTL 24h) without reprocessing files. Without the header, behavior is unchanged.
If an expiration date is set for the album, the plugin automatically deletes the WooCommerce product, watermarked image, and database record via a daily job managed by Action Scheduler (bundled with WooCommerce).
An Action Scheduler job photolab_daily_cleanup runs every 24 hours (default 03:00 UTC) performing a failsafe sweep: detects stuck watermark jobs >1h, re-enqueues stalled photos, retries failed photos within a 5-retry budget per photo, purges expired idempotency transients, scans for disk/DB orphans (log only), and deletes Photolab logs older than 30 days (filter photolab_log_retention_days). Action Scheduler logs are auto-deleted after 7 days.
Yes. An optional distributed lock is available: if WordPress uses an external object cache (e.g. Redis), the lock uses wp_cache_add (atomic SET NX). Without external object cache, the fallback is a transient. Concurrent chunk attempts for the same album from different nodes return HTTP 423. CAS on the database is the final safeguard. Disable via filter photolab_use_distributed_lock.
Yes. The WordPress REST API requires a permalink structure other than "Plain". The plugin shows an admin notice if Pretty Permalinks are not active.
Yes. Photolab does not access wp_posts directly for WooCommerce products and is fully compatible with High-Performance Order Storage (HPOS).
In WooCommerce → Status → Logs, filter by source photolab*. Available sources: photolab, photolab-fsm, photolab-upload, photolab-heartbeat, photolab-recovery, photolab-watermark-job, photolab-rate-limit, photolab-ownership, photolab-download-guard, photolab-idempotency, photolab-cleanup, photolab-lock, photolab-logger. Each entry automatically includes user_id, album_id, and other contextual keys. Sensitive data (passwords, tokens, emails) is automatically redacted.