Add-on Documentation from JCOGS Design

ConfigurationLast updated: 17 February 2026

This section covers field settings for JCOGS Image Pro Field.

  • Field settings control which editor tools are available (preset, crop, focal point, art direction, face detection).
  • Field settings can define defaults (default preset, default aspect ratio, default srcset widths).

See also:

  • Usage for what editors actually do on the Publish screen.

Field Settings

Field settings let you decide two things:

  1. Which tools an editor can use (preset, crop, focal point, art direction, face detection).
  2. What defaults/policy apply (for example default preset, allowed aspect ratios, default responsive srcset).

These settings affect both the Publish UI and what {field:img} renders by default.

Settings

See also:

Allowed upload destinations

Choose whether editors can select files from any upload destination, or restrict the field to a single upload destination.

Note: this approach to upload destination retrictions follows directly the EE file fields behaviour (it supports “all” or one directory).

Why you might want to restrict access:

  • You want all images for a field to come from a particular directory (for permissions, content governance, or predictable image dimensions).
  • You want to ensure editors cannot accidentally pick images from a “documents” or “downloads” directory.

Template impact:

  • None directly. This is a content/policy constraint, but it can make templates more predictable because the field’s images come from known sources.

Presets

Presets are a feature of and defined within JCOGS Image Pro and typically provide shortcut access a standard set of image processing rules.

Options:

  • Enable presets: allows this field to apply an Image Pro preset.
  • Allow editors to choose a preset: exposes a preset selector to editors.
    • When enabled, editors can select from the available presets (optionally restricted below).
    • When disabled, editors cannot change the preset in the publish UI. The Default preset (below) becomes a developer-controlled “forced preset”, unless the template tag specifies preset=....
  • Restrict presets: limit which presets appear in the selector (useful when you have many site-wide presets).
  • Allow “None”: lets editors explicitly select “no preset”. (This option is editor-facing, so it only matters when editor preset choice is enabled.)
  • Default preset: the preset used when there is no per-entry choice. This still applies when editor preset choice is disabled, so you can force a preset at field level.

Notes:</strong.

  • If editor preset choice is disabled, the field does not store per-entry preset intent; it always uses the field’s Default preset (unless overridden in the template).
  • You can force “no preset” by setting Default preset to “None”.

Use cases:

  • Standardise image output across a site (for example “Card thumbnail”, “Hero banner”, “Square teaser”).
  • Let editors pick from a small set of approved looks without having to understand cropping rules.

Template impact:

  • Stored presets are used only when the template does not explicitly set preset=.
  • If you want templates to be fully deterministic, always set the preset in the template.

Crop and aspect ratio

Cropping is a core “source image adjustment” feature. If enabled and a crop is defined it is stored as box located on the source image, and during image processing the processed image is limited only the part of the source image that is enclosed by the crop box.

Options:

  • Enable crop: allows editors to set/clear a crop.
  • Require crop: prevents saving an entry until a crop exists (useful for strict design systems).
  • Aspect ratio choices: define one or more aspect ratios for the editor to choose from.
  • Default aspect ratio: if you define 2+ aspect ratios, you can set a default.
  • Require an aspect ratio: forces an aspect ratio selection (only meaningful when crop is enabled).

Use cases:

  • Where excess detail / content in an image needs to be excluded ensure an image is relevant for an entry
  • Layout design situations where the aspect ratio of images must be consistent (for example 16:9 or 1:1).

Template impact:

  • {field:img} will reflect the stored crop/aspect intent by default.
  • Template parameters (for example width=, height=, aspect_ratio=) still take precedence; see precedence rules.

Responsive defaults

Responsive images are ones that include additional information about various scaled clones of a processed image, the additional information allows the browser to decide which of the scaled clone images is the most appropriate to download for a given device viewport width. This can lead to page rendering speed gains.

JCOGS Image Pro includes a powerful mechanism to automatically generate a collection of scaled clones of a processed image, and so generate HTML output that browsers can use to guide their image selection process.

The JCOGS Image Pro Field allows the default 'break-points' used by JCOGS Image Pro to specified as part of the field definition: this is possibly an easier way of specifying responsive behaviour than adding parameters to template tags.

Options:

  • Enable responsive defaults: controls whether {field:img} can generate a default srcset.
  • srcset widths: define one or more widths (in pixels) used to build the default srcset.
  • Default allow_scale_larger: only applies when srcset is in use. When enabled, Image Pro may generate variants larger than the source image. Use deliberately (it can increase processing and disk usage).

Use cases:

  • You want “good enough” responsive behaviour site-wide, while still allowing specific templates to override.
  • You want a baseline srcset for developers who are getting started, then refine later per template.

Template impact:

  • {field:img} can emit srcset/sizes even when the template does not provide them.
  • If your templates already provide srcset=/sizes= (or allow_scale_larger=), those explicit template parameters remain the source of truth.
  • Image Pro can generate a default sizes attribute, but setting sizes explicitly in templates is still best practice.

Art direction

Art direction allows editors to specify alternate images for particular viewport conditions. When alternates exist, {field:img} can render a <picture> element with <source> tags.

Options:

  • Enable art direction: shows the breakpoint grid and alternate image pickers.
  • Breakpoint rows (media queries): define up to 3 media conditions, including a required “Default” row.
  • Per-breakpoint preset: each breakpoint row can inherit the main preset, use a specific preset, or explicitly use no preset.

Note: when art direction is enabled, presets are treated as “per breakpoint”, so the main preset selector is hidden to avoid contradictory output.

Use cases:

  • Using a different crop/composition for mobile vs desktop.
  • Swapping a wide hero image for a tighter portrait crop on small screens.

Template impact:

  • {field:img} may output <picture> instead of <img> when alternates are present.
  • If your CSS/JS targets <img> specifically, ensure it also works with <picture>.

Focal point and face detection

Focal point helps guide “what matters” in an image, especially when cropping or resizing.

Options:

  • Enable focal point: lets editors pick a focal point.
  • Enable face detection: provides a helper tool that can suggest a focal area; it is crop-adjacent and is typically used to speed up editorial work.

Note: face detection is treated as crop-adjacent; if crop tools are disabled, face detection is also disabled.

Use cases:

  • Editorial teams working with photos where faces or key objects should remain in frame.
  • Avoiding awkward automated crops when images are reused at multiple sizes.

Template impact:

  • Focal point values are stored and exposed to templates as {field:focal_x}, {field:focal_y}, and {field:object_position} so you can apply them in CSS (for example object-position / background-position).
  • The field does not automatically alter Image Pro processing based on focal point; template tag parameters and presets remain the mechanisms that control output.

Debug mode

When enabled, additional debug information is shown to superadmins in the Publish UI.

Use cases:

  • Diagnosing why preview/actions are unavailable.
  • Checking which settings are active for a field while building templates.