Configuration 

What the sets contain 

This extension ships three content elements, so it ships three component sets and one aggregate set that depends on all of them.

All three are driven by one Extbase plugin, so they share one TypoScript block, plugin.tx_academicjobs . That block is shipped once, in Configuration/TypoScript/, and every component includes it. Which component sets a site names therefore decides which content elements the backend offers, not how much TypoScript is loaded.

Every component set depends on fgtclb/academic-base-ctype-group, the set of EXT:academic_base that labels the content element group all academic extensions sort their elements into.

The site settings of this extension are declared with the aggregate set: the storage, detail, list and redirect pages, the notification e-mail, the job avatar upload, the content element header switch and the page links of the list pagination. A site that depends on a single component set still gets the shipped defaults, but can only override them in Site Settings when it depends on fgtclb/academic-jobs.

The content elements are hidden by default 

EXT:academic_jobs hides all three of its content elements for the whole installation and brings them back per component. Whichever of the two mechanisms below you use, it is what makes an element selectable in the backend again — without one of them the content element is not offered, and existing records keep rendering.

Include the site set 

Add the set to the config.yaml of the site that should offer the content elements:

 base: 'https://example.com/'
 rootPageId: 1
+dependencies:
+  - fgtclb/academic-jobs

See also TYPO3 Explained, Using a site set as dependency in a site.

Include static templates 

For an installation that still configures its frontend through sys_template records, the same files are registered as static templates and as selectable page TSconfig files.

Pagination of the job list 

The Job List content element can split its jobs into pages. Whether it does, and how many jobs a page holds, is set on each content element, tab Pagination:

How many page numbers the navigation links at once is one value for the whole site:

The site setting is declared by the aggregate set fgtclb/academic-jobs, like every other setting of this extension. A site configured through static templates sets the constant instead.

Load the script or bring your own 

The Jobs New content element loads two scripts on the page that carries it: CKEditor 4 from its content delivery network, and the module @fgtclb/academic-jobs/frontend/rich-text.js , which turns the description fields of the form into rich text editors. No other content element of this extension loads a script.

Both are switched off together, per site, for an installation that brings its own editor or wants none:

With the site set, it is a site setting of fgtclb/academic-jobs, like every other setting of this extension:

plugin.tx_academicjobs.assets.js: false

With the static template, it is the TypoScript constant of the same name:

plugin.tx_academicjobs.assets.js = 0

The form keeps working without the scripts. The description fields are plain text areas, marked with the class ace-ckeditor , and a visitor submits the text as it is. A script of your own finds the fields by that class.

A project that overrides Templates/Job/New.html keeps whatever its copy loads, until it wraps its own <f:asset.script> and <f:asset.module> in <f:if condition="{settings.assets.js}"> .

Do not combine both 

A site that uses the site set and the static template reads the shipped files twice. The site set is applied before the sys_template record, so the second read happens after the site settings and after config/sites/<site>/constants.typoscript — and it resets every constant the extension ships a default for back to that default. For this extension that is the whole plugin.tx_academicjobs constants block: the Fluid root paths, the storage and target page ids, the notification e-mail, the job avatar upload settings, the content element header switch and the script switch, among others.

Nothing else is damaged: the Constants and Setup fields of the sys_template record, the page TSconfig of a page and the page TSconfig files selected on a page are all applied afterwards and still win. Use one mechanism per site and the question does not arise.