How do I stop property interceptors from running during a site import?

Question

How do I stop property interceptors from running during a site import?

Answer

There is no switch. Jahia has no setting, system property, session attribute or import option that turns property interceptors off.

But the premise is usually wrong, and that is the useful part of the answer.

"My imported rich text came back rewritten - was that an interceptor?"

Almost certainly not, but check the reference properties.

Ordinary content properties are not touched. On a measured import of the Digitall demo site, rich text reached the interceptor chain zero times - see the numbers below. So HtmlFilteringInterceptor and URLInterceptor did not rewrite the body of your rich text during the import.

But interceptors are not switched off for the whole import, and one of the exceptions is easy to mistake for this. After the content pass, Jahia resolves references through JCRNodeWrapper.setProperty, and that does run the chain - on reference properties such as picture, image, internalLink, galleryImg and j:reference. If what changed is a link or a reference rather than the surrounding text, reference resolution is the first place to look.

So: not the bulk of your content, but yes for references. The two halves of that sentence matter equally.

Ordinary imported properties already bypass interceptors

The document view import - the normal .zip / repository.xml site import - does not write through JCRNodeWrapper. It writes to the raw JCR node:

child.getRealNode().setProperty(attrName, attrValue, propDef.getRequiredType());

getRealNode() returns the underlying provider node, and the interceptor chain is only reachable from JCRNodeWrapperImpl.setProperty(...) and JCRPropertyWrapperImpl.setValue(...). So for the bulk of imported property values, no interceptor runs at all - not URLInterceptor, not HtmlFilteringInterceptor, not TagInterceptor.

If imported values are being rewritten, the import itself is usually not the cause. Check the three places below before assuming it is.

Where interceptors do still run during an import

What to do instead

Scope your own interceptor so it never matches

BaseInterceptor gives you four declarative filters, each ignored when left empty, combined with AND:

Core scopes its own TagInterceptor exactly this way - nodeTypes of jmix:tagged and propertyNames of j:tagList - so it is inert everywhere else. Narrowing your interceptor is almost always the right fix, and it helps outside import too.

For anything the filters cannot express, override canApplyOnProperty in Java and return false. Core does this in LastModifiedInterceptor.

Take over a specific attribute during import

If what you actually need is to control how one attribute is imported, Jahia has a supported extension point: implement AttributeProcessor and register it with ImportExportBaseService.setAttributeProcessors. Returning true from process(...) short-circuits all further handling of that attribute.

To skip importing a property outright, DocumentViewImportHandler has a propertiesToSkip set, configured through the Spring bean of the same name.

Do not do this

JCRStoreService.removeInterceptor(...) exists. It is not a per-import switch. It mutates process-wide state shared by every concurrent session and request, with no scoping and no restore if something throws. Removing an interceptor to get one import through will affect every other user of the platform for as long as it is gone.

JCRSessionWrapper does have a skipValidation flag, and it is easy to assume it covers this. It does not - it only skips constraint validation at save time and has no effect on interceptors.

Measured on a real import

This was reproduced on Jahia 8.2.3.2 by importing the Digitall demo site and recording every property that reached the interceptor chain.

The probe was a PropertyInterceptor registered at runtime that logs each canApplyOnProperty call together with the chain method that made it, and always returns false - so it observes without altering a single value. Recording the caller matters: the chain consults canApplyOnProperty on reads too, and reads outnumbered writes roughly eight to one, so a probe that cannot tell them apart reports nonsense.

Writes reaching the chain for nodes under /sites/digitall: 4290. All of them fall into the categories above:

And the number that answers the original question: the import created 13 jnt:bigText nodes, and their text property - rich text, precisely what URLInterceptor and HtmlFilteringInterceptor exist to rewrite - reached the interceptor chain zero times.

No ordinary content property was intercepted.

This article was drafted with AI assistance, then reviewed and curated by Jahia Customer Support engineers before publication.