The KLEKSI frontend is placed as a widget on your existing website. This preserves the general design and navigation of your own website, while the collection presentation from KLEKSI loads within the page. The widget is preferably placed between the header and the footer of your website. The header typically contains elements such as your logo and navigation menu. The footer usually contains additional navigation, contact details, and other general information. Add the following code at the location where you want to display the collection:

<link href="https://eu.cdn.kleksi.com/yourcode/app.js" rel="preload" as="script">
<kleksi-results></kleksi-results>
<script type="module"src="https://eu.cdn.kleksi.com/yourcode/app.js"></script>

Structure of the widget code
The code consists of three parts. The first line ensures that the necessary KLEKSI script is already executed by the browser.
loaded:

<link href="https://eu.cdn.kleksi.com/jouwcode/app.js"
rel="preload" as="script">

Next, the following element determines where on the page the KLEKSI frontend is displayed:

<kleksi-results></kleksi-results>

Finally, the JavaScript file is loaded with which the frontend is actually built and activated:

<script type="module"
src="https://eu.cdn.kleksi.com/yourcode/app.js"></script>

Placement within an existing page
A simplified HTML page might look like this, for example:

<header>
<!-- Header and navigation of your own website -->
</header>

<main>

<link href="https://eu.cdn.kleksi.com/yourcode/app.js"
rel="preload" as="script">
<kleksi-results></kleksi-results>
<script type="module"
src="https://eu.cdn.kleksi.com/yourcode/app.js"></script>

</main>

<footer>
<!-- Footer of your own website -->
</footer>

As a result, the visitor remains within your own website, and only the section between the header and footer is filled by the KLEKSI frontend.


Your personal widget code
In the example above, yourcode is used as an example. This value must be replaced by the unique code made available to your organization. For example, if your personal code is abcde, the references become:

https://eu.cdn.kleksi.com/ abcde /app.js

Always use the application ID of your KLEKSI application for this. You can also request this from your contact person or support staff.

Placement in a CMS
If your website uses a content management system, such as WordPress, Joomla, Drupal, or another CMS, the widget can usually be added via an HTML or code block. It is important that the block used allows the insertion of custom HTML and JavaScript. Some CMS systems or page builders automatically remove <script> elements. In that case, the widget must be included in the page template by the website administrator or web developer. After placing the code, you can open the page and check if the collection is displayed correctly between the existing header and footer of your website.

Use the full available page width
The KLEKSI widget was developed to utilize the full available width of the page. However, some websites use a central content column where fixed margins, whitespace, or a maximum content width are set on the left and right. As a result, the available space for the widget may become smaller than intended. This can lead to fewer objects being displayed side-by-side on certain screen resolutions and may also cause the responsive display to not respond optimally or correctly. We therefore recommend removing any fixed side margins, maximum content widths, or other restrictive layout settings from the page where the KLEKSI widget is placed, so that the widget can be displayed across the full available page width.

Link detail pages to your own domain name
When a visitor opens an object from the KLEKSI frontend, a separate detail page is displayed for that object. By default, KLEKSI makes these detail pages available via a KLEKSI domain. However, it is recommended to make the detail pages available under your organization's own domain name. This ensures that the visitor remains on your own website while viewing an object, and that the public collection pages are also linked by search engines to your organization's domain instead of the KLEKSI domain.

A detail page can then be opened, for example, via:

https://www.yourorganisation.com/collectie/detail/12345

instead of directly via a KLEKSI domain.

Operation of the coupling
To do this, a so-called reverse proxy rule is set up on the web server. When a visitor opens a URL under /collectie/detail/, the web server retrieves the corresponding detail page from KLEKSI in the background. The URL in the browser remains the URL of your own website. The visitor is therefore not visibly redirected to another domain. For a website using an Apache web server, the following line can be added to the .htaccess file for this purpose:

RewriteRule ^collectie/detail/(.*)
http://eu.detail.kleksi.com/yourode/$1 [P]

Enter your personal KLEKSI application code
In the line above, yourcode is an example value. This must be replaced by the unique KLEKSI code made available to your organization.

For example, if your KLEKSI code is abcde, the rule becomes:

RewriteRule ^collectie/detail/(.*)
http://eu.detail.kleksi.com/abcde/$1 [P]

Always use the code you received from KLEKSI.

Adding the rule to .htaccess
The .htaccess file is usually located in the root folder of the website. Open this file and first check if mod_rewrite is already enabled with:

RewriteEngine On

If this rule is already present, you do not need to add it again. A simple configuration might look like this, for example:

RewriteEngine On

RewriteRule ^collectie/detail/(.*)
http://eu.detail.kleksi.com/yourcode/$1 [P]

Many websites, and particularly those using a CMS such as WordPress, Drupal, or Joomla, already contain multiple rewrite rules. In that case, place the KLEKSI rule at the top, before general or so-called catch-all rules that redirect all other URLs to the CMS.

This is important because otherwise the CMS might already process the URL /collection/detail/... before the KLEKSI rule is executed.

Required server support
The addition of [P] to the RewriteRule indicates that the request should be processed as a proxy request. For this, the Apache web server must support mod_rewrite and the necessary proxy functionality, among other things. This is available in many hosting environments, but some hosting providers do not allow the use of proxy rules from .htaccess. If the rule causes a server error or the detail page is not displayed after placement, please contact your hosting provider or website administrator. Instruct them to allow an Apache reverse proxy via .htaccess for /collectie/detail/.

Linking your domain name in KLEKSI
After the above setting for the detail page on your website has been configured, we will establish a connection within KLEKSI with your organization's domain name. From that moment on, when an object is opened, the results page of the KLEKSI frontend will automatically redirect to the corresponding detail page on your own domain name. Consequently, a visitor opening an object from the search results remains entirely within your organization's website and is not redirected to a KLEKSI domain. It is therefore important that the technical configuration on your website is correctly implemented before we activate this domain connection in KLEKSI.

Check if the connection works
After completing all the steps above, open an object from your collection via the KLEKSI frontend. Next, check the URL in your browser's address bar. It must remain under your own domain name, for example:

https://www.yourorganisation.com/collectie/detail/12345

The detailed information is provided by KLEKSI, but for the visitor and search engines, the page forms part of your organization's website. This creates a single, consistent public collection environment: both searching and filtering via the KLEKSI widget and the individual object detail pages are offered under the organization's own domain.

Check after updates to your website or CMS
After an update to your CMS, theme, hosting configuration, or .htaccess file, the previously configured RewriteRule may be modified or overwritten. When a visitor subsequently opens an object detail page, this can result in a 404 error. If this error message is displayed within the design or error page of your own website, it usually means that the RewriteRule is missing or not being executed correctly, and the problem lies with the website or web server. In that case, check whether the RewriteRule is still present in the .htaccess file and is correctly placed (at the top).

If an error message appears originating from a KLEKSI domain, please contact us. In that case, the request is forwarded to KLEKSI, but something is likely going wrong on our end.

Use the widget on multiple pages
The KLEKSI widget can be placed multiple times within the same website. You can therefore use the widget on a general collection page, for example, but also on separate pages where you want to highlight a specific selection of the collection.

The widget does not need to be reconfigured each time. The selection of objects can be determined using the filters in the frontend.

Filter settings are included in the URL
When you set one or more filters in the frontend, these filter settings are automatically processed in the page URL. For example, if you set a filter on a specific collection, manufacturer, object type, or another available filter field, a URL is generated in which this selection is recorded. When this URL is opened again, the same filtered selection is automatically displayed.

This allows you to link directly to a specific group of objects within your own website. For example, you can include a link from a theme page, exhibition, or information page that takes the visitor directly to the relevant selection within the KLEKSI frontend.

Refer to specific selections
In this way, you can offer different entry points to the same collection from different parts of your website.

For example, you can:

• Link directly from a page about an artist to all objects by this maker
• refer directly to a collection from a page about a specific subcollection.
• Open a pre-filtered selection of relevant objects from a theme page
• refer to a specific group of objects within the collection from news articles or other pages.

The underlying KLEKSI widget remains the same. Only the URL determines which filter settings are applied when the page is opened.

Share a filtered selection
The same method can also be used to share a specific selection with someone else. For example, when someone requests information about a particular group of objects, you can set the desired filters in the frontend and then copy the URL from the address bar. You can share this URL via email, message, or other means. The recipient then immediately opens the same filtered selection without having to set all the filters again themselves. This makes the filter functionality suitable not only for navigation within your own website but also for easily sharing specific parts of the collection.

Be careful when changing filters
Shared or internally used filter links will continue to function correctly as long as the relevant filter fields and filter values remain available in KLEKSI. If a filter field is removed, renamed, or is no longer offered as a filter, a previously created link may no longer yield the same selection. It is therefore advisable to check links on important pages of your website as well when making changes to the filter configuration.