Indeed! documentation is bit unclear, an example command not work for windows, I did manage to install successfully, I have sent the message to fix the documentation, I will leave the comment in the documentation.
Try the following steps to fix the installation of DXA Model Extension:
Create the extensions folder in content service root.
Copy the ...
Indeed!, you missed to Installing the DXA Model Extension in content service.
Try the following steps to fix:
Create the extensions folder in content service root.
Copy the \dxa\cis\dxa-model-service-extension\udp-content-dxa-extension-assembly-11.0.0-1047-core.zip file to extensions folder
UnInstall the Tridion SessionContent Service
Re-install the ...
Your assumption is correct. The preview token is only set after Update Preview is clicked. It's always been this way.
Not this cookie no. It's set by the XPM client when it retrieves a result back from the Update Preview call
Not that I am aware of.
Note that Session Preview != XPM. It's a subset feature of XPM, so the IsSessionPreview property is behaving ...
The issue is that I was missing the ISH Cartridge (ish_ambient_cartridge.xml, now called
udp-cis-ish-cartridge.xml). I was missing the steps here. But, as I observed, in addition to those steps, the JAR files also needed to be copied directly into lib folder of my content microservice:
One workaround I've found is to temporarily move all of the aforementioned templates into temporary new folder locations, to allow the import operation to succeed. Then, once the cms-import.ps1 script is successfully run, the new templates will be in the correct location. Finally, to make this work, it's necessary to compare each of the new templates to the ...
The short answer is that you can add these parameters to either the start or the installService scripts, with the caveat that if you add it when calling installService you will need to first uninstall the service for it to take effect.
The DXA 2.1 release provides updates only to the .NET version of DXA. The Java version is planned for release soon after 2.1 in the subsequent 2.2 release. Until the 2.2 release is available, all references to the Java version should be assumed to be unchanged and as provided in the prior release 2.0.
Refer to the DXA 2.1 release notes
I hope ...
Older-style templates (i.e. CT with DXA metadata stating what the Region (View) Name is) can still be used, but may be confusing for the user, because the Region information on the CT is ignored; the Region (View) Name is determined by the “native” Region and its Region Schema. If you do a fresh install of the DXA Example Site (and Core Module), you will see ...
Based on your above comments, I still feel that you can use DXA to push out the JSON files. JSON files do not get refreshed until app pool recycles and is dependent on your cache settings and timeouts.Based on your frequency of publishing, you can build a custom controller to force retrieving the JSON from the database. In older versions of DXA, we had a ...
There's several approaches you can take to pass user conditions through to the content service.
The first approach (and the one that would most easily work for you I think) would be to add them directly to the ADF claimstore. Such as:
var claimStore = AmbientDataContext.CurrentClaimStore;
claimStore.Put(new Uri("taf:ish:userconditions:merged"), ...
Did you have a look at the DXA Search Module? This Module provides SI4T-based Search functionality to a DXA-based Web Application. It comes with support for Solr and AWS CloudSearch OOTB, but allows adding other Search Providers.
As a matter of fact, an ElasticSearch integration has also been created: https://velmuruganarjunan.wordpress.com/2018/09/10/tds-...
If you are using GraphQL for querying content, you do not need to worry about ADF claims for condition evaluation. These are only needed when using the CIL. Instead, you can simply pass your conditions as contextData to your GraphQL query, such as in the query below:
page(namespaceId: 2, publicationId: 1234, pageId: 5678,
Indeed!, It's the bug in DXA 2.1 found and raised SRQ to fix this, somehow Left Navigation of include page not used correct import package file, it was not localized to use the correct page template.
In order to fix this issue manually localize this Left Navigation page and then change to select the page template to Include Page (Left) and republish it will ...
The problem is that you installed the DXA Resolver UI Extension in %TRIDION_HOME%/web/WebUI. This is known to not work properly on Sites 9.
If you specify another location for extensionTargetFolder (or just use the default location), it should work ...
Indeed, The mapping is missing.
Create the Mappings and then publish and test, it should work:
Add-TtmMapping -ID Mapping1 -CmEnvironmentId Tridioncm_localhost -PublicationID tcm:0-5-1 -WebApplicationId Website1_RootWebApp -RelativeUrl /
CmEnvironmentId, PublicationId, and WebApplicationId should be your environment-specific values
Fixed this one. So the upgrade documentation was missing a step :). When I compared New ported files in DXA Core module in CMS i found issue. It ports 2 folders under Framework/Templates. DXA.Upgrade and DXA.R2.
And in all customer modules - page and component templates refers to TBBs in DXA.Upgrade "Render Page Content" or "Render Component Content". ...