0

I'm using Sitecore 10.2 in my local as headless and nextjs for FrontEnd. I'm able to open the home page on the experience editor and can update content.

in Sitecore JSS with next js, we dont need to deploy next js deployable files into sitecore cm/cd instance instead of that we are providing next js app Url(http://localhost:3000) like below.

what I want is that when I run nextjs app it should display content from web db and when I open pages in experience editor it should fetch data from master db and update to master db only and we can publish to copy changes into web db.

but in below configuration I can make it either for master or web not solving both purpose.

even same issue will be there when I deploy to server like dev/staging.

mynextjsapp.config:

<!--
  JSS Sitecore Configuration Patch File

  This configuration file registers the JSS site with Sitecore, and configures the Layout Service
  to work with it. Config patches need to be deployed to the Sitecore server.

  Normally `jss deploy config` can do this for local development. To manually deploy, or to deploy via CI,
  this file can be placed in the `App_Config/Include` folder, or a subfolder of it, within the Sitecore site.
-->
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:set="http://www.sitecore.net/xmlconfig/set/" xmlns:role="http://www.sitecore.net/xmlconfig/role/">
  <sitecore>
    <!--
      Note that if any of these settings are enabled, they will apply to the entire Sitecore instance. If there are
      multiple sites defined in the instances, the settings will affect all of them.
    -->
    <settings>
      <!--
        ANALYTICS FORWARDED REQUEST HEADER
        When using Next.js SSR routes, Layout Service requests will send the original IP address of the client on the 'X-Forwarded-For' header.
        This setting tells Sitecore to read the forwarded header, thus making analytics track the correct original client IP address.

        <setting name="Analytics.ForwardedRequestHttpHeader" set:value="X-Forwarded-For" />
      -->
      <setting name="JavaScriptServices.ViewEngine.Http.JssEditingSecret" value="x889f4myl9iw8hdls9syqb0wuuv3tqs8uaro3vl15" />
      
      <!--
        ANALYTICS DISABLE ROBOT DETECTION
        During development, activity will flag us as a robot.
        These settings will enable tracking of robot activity for ease of testing (development ONLY).
        
        <setting name="Analytics.AutoDetectBots" set:value="false" />
        <setting name="Analytics.Robots.IgnoreRobots" set:value="false" />
      -->

      <!--
        JSS EDITING SECRET
        To secure the Experience Editor endpoint exposed by your Next.js app (see `serverSideRenderingEngineEndpointUrl` below),
        a secret token is used. This is taken from an env variable by default, but could be patched and set directly by uncommenting.
        This (server-side) value must match your client-side value, which is configured by the JSS_EDITING_SECRET env variable (see the Next.js .env file).
        We recommend an alphanumeric value of at least 16 characters.

        <setting name="JavaScriptServices.ViewEngine.Http.JssEditingSecret" value="" />
      -->

      <!--
        LANGUAGE FALLBACK
        These settings enable item-level language fallback for JSS apps that use Experience Edge.
        In addition to these settings, ensure that Language Fallback is configured on the Language
        item in Sitecore, and that items in the content tree have "Enable Item Fallback" field set
        to true. Other settings related to item-level language fallback that may exist in Sitecore
        configuration will not impact Edge functionality.

        <setting name="ExperienceEdge.EnableItemLanguageFallback" value="true"/>
        <setting name="ExperienceEdge.EnableFieldLanguageFallback" value="true"/>
      -->
    </settings>
    <sites>
      <!--
        JSS Site Registration
        This configures the site with Sitecore - i.e. host headers, item paths.
        If your JSS app lives within an existing Sitecore site, this may not be necessary.

        IMPORTANT: JSS sites ship in 'live mode', which makes development and testing easy,
        but disables workflow and publishing. Before going to production, change the `database`
        below to `web` instead of `master`.
      -->
      <!--<site patch:before="site[@name='website']"
            inherits="website"
            name="mynextjssite"
            hostName="sitecore10.2sc.dev.local"
            rootPath="/sitecore/content/mynextjsapp"
            startItem="/home"
            database="master" />-->
    </sites>
    <javaScriptServices>
      <apps>
        <!--
          JSS App Registration
          The JSS app needs to be registered in order to support layout service and import services.

          There are many available attributes, and they inherit the defaults if not explicitly specified here.
          Defaults are defined in `/App_Config/Sitecore/JavaScriptServices/Sitecore.JavaScriptServices.Apps.config`

          NOTE: graphQLEndpoint enables _Integrated GraphQL_. If not using integrated GraphQL, it can be removed.

          NOTE: layoutServiceConfiguration should be set to "default" when using GraphQL Edge schema.
          When using integrated GraphQL with Edge schema, a $language value is injected
          since language is required in all Edge queries. "jss" configuration does not do this (which is backwards
          compatible with JSS versions < 18.0.0).
        -->
        <app name="mynextjsapp"
            layoutServiceConfiguration="default"
            sitecorePath="/sitecore/content/mynextjsapp"
            useLanguageSpecificLayout="true"
            graphQLEndpoint="/sitecore/api/graph/edge"
            inherits="defaults"
            serverSideRenderingEngine="http"
            serverSideRenderingEngineEndpointUrl="http://localhost:3000/api/editing/render"
            serverSideRenderingEngineApplicationUrl="http://localhost:3000"
        />
      </apps>
      <!--
        IMAGE RESIZING WHITELIST
        Using Sitecore server-side media resizing (i.e. the `imageParams` or `srcSet` props on the `<Image/>` helper component)
        could expose your Sitecore server to a denial-of-service attack by rescaling an image with many arbitrary dimensions.
        In JSS resizing param sets that are unknown are rejected by a whitelist.

        Sets of image sizing parameters that are used in app components must be whitelisted here.
        If a param set is not whitelisted, the image will be returned _without resizing_.

        To determine the image parameters being used, look at the query string on the `src` of the rendered image, i.e. '/img.jpg?mw=100&h=72' -> mw=100,h=72
        Note: the parameter sets defined here are comma-delimited (,) instead of &-delimited like the query string. Multiple sets are endline-delimited.
       -->
      <allowedMediaParams>
        <!-- XML element name is arbitary, useful for organizing and patching -->
        <styleguide-image-sample>
          mw=100,mh=50
        </styleguide-image-sample>
        <styleguide-image-sample-adaptive>
          mw=300
          mw=100
        </styleguide-image-sample-adaptive>
      </allowedMediaParams>
    </javaScriptServices>
    <!--
      Media URLs resolving
      Tells Sitecore to not include the Sitecore server URL as part of the media requests, so that they are instead routed through Next.js rewrites (see next.config.js).
      This eliminates exposing the Sitecore server publicly.
      
      "default" configuration is used for Sitecore GraphQL Edge requests.
      "jss" configuration is used for Sitecore Layout Service REST requests.
    -->
    <layoutService>
      <configurations>
        <config name="default">
          <rendering>
            <renderingContentsResolver>
              <IncludeServerUrlInMediaUrls>false</IncludeServerUrlInMediaUrls>
            </renderingContentsResolver>
          </rendering>
        </config>
        <config name="jss">
          <rendering>
            <renderingContentsResolver>
              <IncludeServerUrlInMediaUrls>false</IncludeServerUrlInMediaUrls>
            </renderingContentsResolver>
          </rendering>
        </config>
      </configurations>
    </layoutService>
  </sitecore>
</configuration>

mynextjsapp.deploysecret.config:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <javaScriptServices>
      <apps>
        <app name="mynextjsapp"
             deploymentSecret="x889f4myl9iw8hdls9syqb0wuuv3tqs8uaro3vl15"
             debugSecurity="false"
        />
      </apps>
    </javaScriptServices>
  </sitecore>
</configuration>
1
  • 1
    you will need to configure 2 rendering hosts. One for editing that uses the master db and one for delivery that uses the web db.
    – Richard Seal
    Oct 13, 2022 at 16:11

1 Answer 1

2

Just follow the tips in the config file that you have:

IMPORTANT: JSS sites ship in 'live mode', which makes development and testing easy,
        but disables workflow and publishing. Before going to production, change the `database`
        below to `web` instead of `master`.

Changing database to web will be enough for your case.

Sitecore Experience Editor (and Horizon as well) works through http://localhost:3000/api/editing/render endpoint. And it will pass all the data from the master DB during editing. It doesn't take into account database property in the site configuration.

Next.js website itself works through requests to Layout Service. And you are able to configure the database that should be used in your site configuration.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.