Download the PHP package augustash/wordpress-cache-protection without Composer
On this page you can find all versions of the php package augustash/wordpress-cache-protection. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download augustash/wordpress-cache-protection
More information about augustash/wordpress-cache-protection
Files in augustash/wordpress-cache-protection
Package wordpress-cache-protection
Short Description WordPress equivalent of drupal_cache_protection. Strips/redirects tracking params so Varnish caches canonical URLs, augments robots.txt with bot-throttling rules, and exposes filters for site-specific extension.
License GPL-2.0-or-later
Homepage https://github.com/augustash/wordpress-cache-protection
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package wordpress-cache-protection
WordPress Cache Protection
Protects WordPress page cache from fragmentation by tracking parameters and bot abuse.
Install
What it does
Hooks at plugin load and runs before WordPress queries posts.
Two modes for handling cache-busting query params:
- Redirect — 301 → clean URL. Varnish caches the 301, so subsequent dirty hits cost no PHP. Used for params that on-site JS doesn't read from
window.location(default:srsltid,fbclid). - Strip — internal rewrite of
$_GET/REQUEST_URI. Browser URL stays dirty so client-side analytics/ads scripts can still read attribution fromwindow.location; the application sees clean. Used for default:gclid,msclkid,_kx,gbraid,gad_source,gad_campaignid,utm_*,hsa_*,_hsmi,_hsenc,__hstc,__hssc,__hsfp.
Also strips Pantheon's *=PANTHEON_STRIPPED leftovers.
Augments robots.txt with bot-throttling rules for known abuse patterns.
Search protection
Per-IP rate-limit + page-cache kill on search responses. Every search query is unique, so the page cache can never help; meanwhile bots blast random queries to fragment cache and stress the DB.
- Two flood windows: burst (default 5/10s) + sustained (default 30/60s). Either limit triggers 429.
- Cache-Control:
private, no-storeon search responses so Varnish never caches them. - Empty
?s=(bare search form) doesn't trigger — stays cacheable. - Default search param:
s(WP core). Configurable.
Enabled by default; toggle off in Settings → Cache Protection.
Configuration
Settings → Cache Protection in the WP admin. Two textareas for redirect and strip lists, one param per line. Trailing * for prefix wildcards (e.g. utm_*). Search protection has its own section with the windows/thresholds.
