Skip to main content

Quick Setup (CMS presets)

CMS presets — surfaced as Quick Setup in the panel — are pre-built bundles of cache rules and general CDN settings tuned for a known platform. Applying one creates individual, editable cache rules on your property and applies a set of recommended general settings, so you get a sensible baseline in a single click and can fine-tune each rule afterward.

Where to find Quick Setup​

Open a property in the Paradarum panel, go to the General settings tab, and expand the Quick Setup card at the top of the page:

Quick Setup — Apply a recommended configuration, then fine-tune each section for your use case.

note

The Quick Setup card is hidden for managed properties — for example, the backing property of a live stream. Presets are only available on standard, self-managed properties.

Available presets​

Presets are grouped into four categories, shown in the dropdown in this fixed order: CMS, E-commerce, Framework, LMS.

CategoryPresets
CMSWordPress, Drupal, Joomla, Ghost
E-commerceWooCommerce, PrestaShop, Magento 2, Shopify (Headless)
FrameworkNext.js, Laravel, Static Site/SPA, API/Backend
LMSMoodle

Each preset bundles an ordered set of cache rules (with per-path TTLs), general settings (HSTS, clickjacking and MIME-sniffing protection, always-online, query-string handling, browser caching), a list of cache-bypass cookies, and a recommended WAF profile.

How applying a preset works​

  1. Expand the Quick Setup card and pick a platform from the Select CMS/Platform dropdown.
  2. Review the detail panel: display name, description, a category chip, and an "N rules" count badge.
  3. Click Apply Preset and confirm in the dialog ("Apply WordPress Preset? This will create N individual cache/header rules…").
  4. The panel creates each rule one by one on the property, then merges the preset's general settings onto the property.
  5. A snackbar reports success, e.g. "WordPress: N rules + settings applied!". Each created rule carries the description "Applied from WordPress preset" and is fully editable.

Under the hood the panel fetches presets from a single read-only endpoint and then calls the standard rule and general-settings endpoints to apply them.

# Fetch all active presets (what the General page does on load)
curl -H 'Authorization: Bearer YOUR_JWT' \
  https://api.paradarum.com/api/CmsPreset
# => { "status":200, "message":"Success", "data":[
#      { "id":1, "name":"wordpress", "displayName":"WordPress", "category":"CMS",
#        "config": { "rules":[...], "general_settings":{...}, "cache_bypass_cookies":[...] } }, ... ] }

What gets applied — and what does not​

The apply flow writes cache rules and general settings only. Two parts of the preset are intentionally not applied automatically:

:::warning WAF is configured separately Applying a preset does not turn on the preset's recommended WAF profile. The card's own info note makes this explicit: "Advanced security (simplified WAF with ModSecurity) is configured from the WAF section." The WAF block is recommendation metadata — configure it yourself in the WAF section. :::

:::info Cache-bypass cookies are informational The preset's cache_bypass_cookies list is returned by the API but is not pushed by the apply action. If you want logged-in users to bypass the cache, add those cookies to the relevant cache rule's Location Features (see how rules work). :::

Part of presetApplied by Quick Setup?
Cache rules (per-path TTLs)Yes — created as individual editable rules
General settings (HSTS, protections, always-online, query string, browser caching)Yes — merged onto the property
WAF profileNo — configure in the WAF section
Cache-bypass cookiesNo — add manually if needed

Important gotchas​

:::danger Applying twice creates duplicates Applying a preset always creates new rules — it never replaces existing ones. Applying the same preset twice gives you a duplicate set of rules. There is no "remove preset" action: to undo a preset, delete the individual rules it created (they all carry an "Applied from …" description, which makes them easy to spot). :::

:::tip Fine-tune after applying Every rule a preset creates is a normal, editable cache rule. After applying, open the Cache Rules section and adjust TTLs, patterns, or Location Features to match your site — for example, raise the page TTL or add bypass cookies for your session cookie. :::

Example: the WordPress preset​

Applying the WordPress preset creates these cache rules (nginx-style patterns; ^~ = prefix match, ~* = case-insensitive regex, / = catch-all):

OrderPatternTTLPurpose
1~* \.(jpg|jpeg|png|gif|ico|svg|css|js|woff|woff2|ttf|eot)$2592000 (30d)Static assets
2^~ /wp-admin/0Bypass admin
3^~ /wp-login.php0Bypass login
4^~ /wp-json/10REST API
10/1800 (30min)Pages (catch-all)

It also merges these general settings onto the property:

{
  "hsts": { "enabled": true, "max_age": 31536000, "include_subdomains": true, "preload": true },
  "clickjacking_protection": true,
  "mime_sniffing_protection": true,
  "query_string": { "mode": "only", "values": ["utm_source","utm_medium","utm_campaign","fbclid","gclid","_ga","_gid"] },
  "always_online": { "enabled": true, "codes": ["error","500","502","503","504"] },
  "browser_caching": { "mode": "override", "ttl": 3600 }
}

The preset's recommended bypass cookies (wordpress_logged_in_, wp-settings-, comment_author_, wp-postpass_) are not applied automatically — add them to the page rule's Location Features if you want logged-in users to skip the cache.

Each preset rule is created via the standard cache-rule endpoint, exactly as if you had created it by hand:

curl -X POST 'https://api.paradarum.com/api/Property/123/rules/cache' \
  -H 'Authorization: Bearer YOUR_JWT' \
  -H 'Content-Type: application/json' \
  -d '{
        "name": "WP: Cache Pages (30min)",
        "pattern": "/",
        "ttlSeconds": 1800,
        "description": "Applied from WordPress preset",
        "order": 10,
        "isEnabled": true
      }'

See also​