Data

Data Structure

Most of your site content will be configured and managed through the Matrix. The Matrix is a core FusionCMS module that enables developers to build and configure unique content structures and page routes. There are two types of Matrix; a Page and a Collection. You'll create and assign Fieldsets to your Matrix to input and store content unique to your Pages & Collections.

• Pages - Single, unique, one-off page routes that do not bare repeating. An example would be your homepage, there is only ever one homepage.
• Collections - Give you the ability to create multiple pages from the same content structure & route pattern. An example of this would be posts in a blog.
• Fieldsets - Assigned to each Page or Collection Matrix you create. Fields within these Fieldsets are what store the content of your pages.

You may also assign relationships between Pages and Collections. This would allow you to create a main overview page with the intent of listing out associated collection pages.

For example, if you're making a blog with the matrix then Page will have its own Fieldset and view template assigned to its route /blog. Included on this page we'd like a listing of blog posts. The blog posts would be set up as their own separate Collection with an assigned view template and route of /blog/{slug}. You can assign the blog Page to be the parent of the blog post Collection. This relationship will be reflected in the sidebar of the CMS, where management of blog posts will be nested under a "Blog" navigation item.

Auto-loaded Data

A Matrix Page or Collection will have specific data variables auto-loaded and available on the view file assigned to it.

Content Data

A Matrix Page or Collection entry will automatically return a $page variable available on the view file assigned to the page route. This variable can be used to access all content field data. You can use and display content data from specific fields by calling the field handle off the variable.

{{ $page->title }} // Will print the title field of the post

Be aware of the Field Type you're working with to anticipate what data will return and how it might display. The above example would work for something like an input or textarea since these fields return a string. Other fields may return differently, like as an object, array or boolean. Please take a look at our docs on individual Field Types listed in the sidebar for information and template usage examples.

Matrix Data

One other variable auto-loaded to your view template will return information about the Matrix structure itself via a $matrix variable. This information isn't usually necessary or relevant to basic frontend development but can be useful in very special cases. An example of such a case is if you wanted to replicate your backend field structure on the frontend of the website. While this is much more complicated than simply displaying the field data, it's a necessary component in making this situation possible.

Query Data

While your view templates will be auto loaded with relevant page data there may be other data you'd like to include on the page. We can query this data easily in our views by using Laravel's Database Query Builder with a couple of Matrix helpers. The query builder behind the scenes translates to a standard MySQL query, so common things like where, orderby and sortby will intuitively follow these conventions in querying data. Please refer to official Laravel docs for the time being for a list of different clauses and methods that can be used with query builder.

For the following examples, we'll be using the @php directive to query additional data directly on the view template.

matrix_page

You may have a situation where you'd like to query data from one Matrix Page on to another. We can do this with the use of matrix_page while specifying the handle of the Matrix Page you'd like to fetch data from.

@php
    $homepage = matrix_page('homepage')->get();
@endphp

Note: We'll need to signal the end of the query with get().

The data of this page will return as an object, meaning we can directly call field values from the variable:

{{ $homepage->title }}

matrix_entries

Continuing with blog as an example, while content relevant to the blog page itself will be auto-loaded, entries from the blog posts Matrix Collection it's associated with would not. To query a Matrix Collection of items, use matrix_entries, specifying the handle of the Matrix Collection you'd like to query data from.

@php
  $posts = matrix_entries('blog_posts')->where('status', true)->orderby('title','asc')->get();
@endphp

In this example, there are other parameters to add to our query, like to only fetch enabled posts, and specifying the order.

The data will be returned as a Laravel collection (essentially a more intuitive array), so we'll need to use directives to work with and display content values from this data in our view template.

@foreach ($posts as $post)
  <div class="article">
    <h1>{{ $post->title }}</h1>
    {!! $post->excerpt !!}}
  </div>
@endforeach

Paginate Data

You may want to paginate your data. This can be accomplished through the query builder by replacing get with paginate at the end of your query. Indicate the number of items per page through the paginate method.

@php
  // Return data paginated with 10 items per page
  $posts = matrix_entries('blog_posts')->where('status', true)->orderby('title','asc')->paginate(10);
@endphp

If you chose to paginate your data, only the "per page" number of items will show up at one time. Call the links method off of your data variable to display pagination links in a set HTML structure. Each of these links will already contain the proper page query string variable.

{{ $posts->links() }}

If you'd like to specify your own HTML structure for pagination links, simply pass a partial view file through the links method.

{{ $posts->links('partials.pagination') }}

There is a $paginator and $element variables available to you on this partial to get pagination data.

<div>
    <span>Page {{ $paginator->currentPage()}} of {{ $paginator->lastPage() }}</span> |
    <span>{{ $paginator->total() }} {{ ($paginator->total() > 1) ? 'total posts' : 'post'}}</span>
</div>

<ul class="pagination">
  @foreach ($elements as $element)
      {{-- "Three Dots" Separator --}}
      @if (is_string($element))
        <li class="page-item disabled"><span class="page-link">{{ $element }}</span></li>
      @endif

      {{-- Array Of Links --}}
      @if (is_array($element))
        @foreach ($element as $page => $url)
            @if ($page == $paginator->currentPage())
                <li class="page-item active"><span class="page-link">{{ $page }}</span></li>
            @else
                <li class="page-item"><a class="page-link" href="{{ request()->fullUrlWithQuery(['page'=>$page]) }}">{{ $page }}</a></li>
            @endif
        @endforeach
      @endif
  @endforeach
</ul>

You can learn more about displaying and working with Pagination through Laravel's Query Builder Pagination docs.

FAQs

If we're auto-loading page data on view templates, why not also auto-load all collection page data to a parent page?

The way associated collection page data would need to be returned varies greatly depending on the way a developer would like to set up their page. For a blog, you might want posts auto-loaded in descending order by date and paginated for 12 per page. For a portfolio, you may want all collection page data returned in ascending order by name. And in some circumstances, you might not need this data at all. For these reasons, we're leaving it up to the developer to explicitly call for this data through their view files and decide how that data should be returned.