The Scrivito Example App often serves as a basis for implementing many and varied websites. But what if all the content it comes with is simply too much? In this guide, we would like to show you how to remove the default content and start from scratch with just a couple of pages. On this occasion, we’re also going to explain how to use the main navigation and how the included overview pages are structured.

For this tutorial, you don’t need to download or clone the Example App and execute it locally because we won’t touch any files in the codebase. Just open your Example App in the browser. Let’s start!

First, after opening your Example App in the browser, make sure to have “scrivito/” in the URL path as the first element after the hostname for having the editing interface available. Of course, you can also use the editing interface on edit.scrivito.com.

Then, create a working copy for applying all the changes we’re going to make in the course of this guide. Set the display mode to “Edit” using the switch at the top of the page.

Next, open your browser’s JavaScript console and change the context from top to scrivito_application.

We will delete all content from the working copy, i.e. each and every CMS object, and then recreate the absolutely necessary pages like the homepage to be ready to add our own content. Run the following script in the console and watch the standard content vanish. (This script along with many other usage examples can also be found in our SDK Cheat Sheet.)

After executing this script, your CMS is empty (in the selected working copy), and you will get a 404 error because the page that was displayed before is gone. Don’t publish this working copy if the Scrivito CMS you are working with includes valuable or publicly visible content. You will lose this content if you do, at least until it will have been restored using the publishing history!

In the Example App, the homepage object is equipped with several attributes from which the app code obtains various settings like page-specific styling options or site-specific access keys for third-party services like Google Analytics. So let’s create a homepage!

Note that we cannot use the “Create page” item from the page menu for this because the Homepage type has been excluded from the selection dialog to prevent editors from creating homepages in addition to the one provided. So we’ll use the browser console again and create an instance of the built-in Homepage object model class:

As you can see, we’ve given the homepage a path by setting its _path attribute to “/”. By default, the page with this path is the root page, the origin of the page hierarchy. The Example App uses it for storing the site settings, and it also represents the origin of the main navigation (we’ll expand on this in a moment).

After executing the above line of code in the console, the homepage should be displayed; however, it may take a couple of seconds until its initial content, a section widget containing a headline widget with its preset text, becomes visible. Try adding widgets, rearranging them, etc., like you probably already did prior to erasing the default content.

Did you notice the grey box at the bottom of the page? This is the footer. It is represented by a widgetlist so that it’s editable just like regular page content. Only the homepage has a footer widgetlist, however, this widgetlist will be rendered for all pages in the CMS. This is why the footer content can be edited on every page.

To see all the other options the homepage has in store for you, open its page settings via the menu at the top right and, for example, change the logo or the header image (or upload a new one) using the Content Browser. The various tabs of the properties dialog let you access the site settings, the social cards, etc.

Now, click the red magnifying glass at the top right corner of the page, then search for “lorem”. The 404 error you’ll get is the reason why we need to recreate the search results page.

Creating the search results page via the console is as easy as creating a page of any type. At this point, we recommend taking a look at the Example App’s page model classes and their React components, or getting to know the basic principles of Diversifying Website Content Using Object Classes later on. For now, just execute:

Like the homepage, the search results page is not available in the page type selection dialog, and thus you cannot create one using Scrivito’s editing interface – for the same reason: The default content includes such a page, and having more than one search results page doesn’t make any sense.

Repeating the search should now yield one result (unless you’ve changed the headline of the homepage). As with all new pages you might be creating, the search results page can be fine tuned via its properties view.

Next, let’s add a page to the navigation.

Did you notice the blue handle to the left of the magnifier? It represents an automatically generated navigation which is part of the layout and shows up on all pages except landing pages.

Technically, this navigation renders links for the pages that are (path-wise) located underneath the homepage. In our case, there are no subpages to the homepage yet, so nothing can be seen here until you select “Add page” from this menu and select a page type, e.g. Page. This will cause a navigation item, initially <UNTITLED>, to appear for the new page. The item will update as soon as the page title is set via the page properties – try it out!

Next, let’s create a landing page! Usually, landing pages don’t show up in any navigation (and also don’t have a navigation), meaning that they don’t need a path. This is exactly what you get when using “Create page” from the page menu to create a page: it won’t have a path.

Another common practice regarding landing pages is to exempt them from the site search because they should be accessible only by their individual URLs (used in Google Ads, Facebook posts, and the like).

But, how can we – as Scrivito users – find a specific landing page? There’s two easy methods: First, directly after creating a landing page, open its properties and assign a permalink to it – you don’t want its URL path to be something like “join-the-javascript-revolution-bbadaad6a47887cd” anyway.

Secondly, especially if you have many landing pages, open the Content Browser and use the search or the “Pages” filter list to find a specific page and, again, copy/paste its permalink (or object ID from the “System” tab) to the browser’s address line.

Overview pages are the means of choice for presenting content of any kind to website visitors in a compact form. The Scrivito Example App comes with several implementations of overviews:

• The SearchResults page type has its own logic for displaying the search results.
• A blog comes to life by several components working together: a Blog page, a BlogOverviewWidget on it, and any number of Blogpost pages not part of the page hierarchy.
• A JobOverviewWidget or EventOverviewWidget doesn’t require special page logic and can be placed on pages of any type.

What has been said above about the SearchResults page type, applies to the Blog type as well: Both have been excluded from the page type selection dialog to prevent the creation of further instances of them next to the one in the default content. – You don’t require two or three blogs, do you?

So if you want to use the Example App’s blog and also want it to have a permalink, you can add the blog as a subpage of the homepage by executing this in the console:

It’s the “/blog” path that makes this page a subpage of “/”, the homepage. After creating the blog, add a HeadlineWidget as well as a BlogOverviewWidget to the page and start providing blog posts using “Create page” from the page menu. To make use of the tag filter of the Blog page, assign suitable tags to the posts.

That was it! If you want to, go ahead and add further pages to the navigation, or stand-alone pages (without a path)...