Designing Content Structures

Content structures are information blueprints that define consistent fields for each content type. Determining structures upfront is critical for an effective content management strategy. It ensures consistency, streamlines management, and enables efficient content reuse. Liferay’s Classic CMS provides the Web Content application to create these blueprints, though Liferay Objects offers a powerful alternative for some use cases.

In this lesson, you’ll learn how to translate your content requirements into reusable web content structures in Liferay. You’ll also explore best practices for choosing between structured and inline content.

Understanding Web Content

Web Content is Liferay's core Classic CMS tool for creating structured, reusable content intended primarily for web pages (e.g., articles, banners, FAQs). Its power comes from separating content from its presentation using three key components:

  • Structures: Define the data fields for specific content types (e.g., fields for a "News Article" might include Headline, Author, Publish Date, Body, and Banner Image).

  • Articles: Individual content items created from a structure, containing the actual text, images, and data.

  • Templates: Control the visual display of content when rendered on pages using FreeMarker templates.Web Content is Liferay's core tool for creating structured, reusable content intended primarily for web pages.

This structured approach promotes consistency, simplifies updates, and enables content reuse across different pages or sites.

Using Web Content Structures

Web content structures define set of fields that authors fill out when creating a content item (e.g., text, images). This approach separates raw content from presentation, which is a fundamental principle of a modern Content Management System (CMS). Liferay offers various field types to build your structures, including text, rich text, image, date, and selection fields. You can also mark fields or groups of fields as repeatable to capture multiple values, like social media links.

Before creating structures in Liferay, carefully plan out each type of content you’ll need to reduce rework and improve management. When planning, collaborate with design, content, and business teams to answer key questions:

  • What fields are required? For example, a Leadership Profile needs a name, title, and photo, with an optional bio or contact info.

  • What categories are required? A value like "Department" works better as reusable categories.

  • What data types are needed? Choose appropriate field types (text, image, date) for each data piece.

  • Do any fields repeat? Identify fields or groups of fields (e.g., social media accounts) that need to be repeatable.

Answering these questions upfront ensures your structures are well-planned and meet your business needs.

Creating Advanced Data Models

While web content is generally preferred, Liferay Objects offers a viable alternative for some use cases. Objects is a tool for creating custom data models for forms and applications without coding, but it can also model data-driven website content. This is especially useful for content that requires complex relationships between records or dedicated APIs.This is particularly true for structured or data-driven content that requires complex relationships between records or where dedicated APIs for each content type is beneficial.

Choosing between Objects and web content depends on your data’s purpose:

  • Objects: Best for data that powers an application, handles transactions, or manages system configurations.

  • Web Content: Best for data designed primarily for presentation or information.

To learn more, consider taking the Mastering Data Modeling with Liferay Objects course.

Best Practices for Structures

To ensure your content structures are effective and maintainable, consider these best practices:

  • Keep Structures Focused and Reusable: Avoid creating one giant structure with dozens of fields. Instead, design smaller, focused structures for each distinct content type and reuse them wherever applicable.

  • Use Appropriate Field Types: Use field types that match the data you want to store. Avoid using plain text fields for everything, as specific types enable better validation and functionality.

  • Consider Field Granularity: You should use different fields for logically distinct types of data, especially when they have unique display requirements. That said, you should balance granularity with the ease of authoring; don't create too many tiny fields if it makes editing cumbersome.

  • Use Clear and Consistent Naming: Name your structures and their fields logically and predictably (e.g., "Author Name," not "text_field_1"). This makes the system easier for everyone to use and maintain. Also, by using descriptive field labels, you can help guide content creators, ensuring they understand what information they should enter.

  • Design for Evolution: Design your structures to be flexible. It's often better to start with a simple structure and add a new field later than to create an overly complex one with many unused fields.

  • Limit Structure Depth: Avoid creating overly nested or heavily repeatable fields, as they can quickly make the authoring interface unusable. If your data structure becomes deeply complex, consider using Liferay Objects instead.

  • Evaluate Translation Needs: Only mark fields as translatable if their stored value changes between languages. For example, information like dates or numbers typically require frontend localization or timezone adjustments, not translation.

  • Optimize Searchability: Disable search indexing for fields that users will not explicitly query. This keeps search results relevant and significantly reduces indexing footprint.

These principles create a robust, user-friendly architecture. Additionally, you must decide whether to capture data via fields or categories, and whether to use structured or inline content.

Deciding Between Fields and Categories

When defining your structures, you must decide how to capture information. While fields are the primary method, categories can also append data. This is useful for repeating lists across different content types.

When choosing between fields and categories, consider these guidelines:

  • Use fields for data that is unique to one content type.

  • Use categories for metadata that applies to multiple content types, simplifying maintenance and reuse.

For example, to track sunglasses manufacturers, you could use a field. However, if manufacturer names are applied to blog posts, marketing documents, and other items, defining them as categories is more effective and scalable.

Deciding Between Structured and Inline Content

To use structures effectively, you must assess whether specific content from your site plan or mock-ups is best authored as structured web content or as simple inline content.

  • Structured Content: Use structured content when multiple items follow the same information pattern (e.g., leadership profiles, product listings) or when you need to reuse the item across multiple pages (e.g., promotional banner that needs to appear on multiple pages).

  • Inline Content (Fragments): Use inline content for unique, one-time items. For example, special welcome messages on a landing page are often best handled as inline content authored directly on the page.Use inline content for unique, one-time items. For example, special welcome messages on a landing page are often best handled as inline content authored directly on the page.

By leveraging both structured and inline content strategically, you can reduce unnecessary complexity and keep your site easier to manage.

Clarity’s Structured Content Strategy

Clarity plans to use web content for their structured, reusable content items. Because their site features a diverse range of content, well-designed structures help them maintain consistency, organize content predictably for authors, and reduce the maintenance burden as their site grows. For example, Clarity needs these structures:

  • “Announcement” for public messages (e.g., new product announcements)
  • “Carousel” for promoted content (e.g., featured products)
  • “FAQ” for frequently asked questions (e.g., on payment methods).

For each structure, they can define the specific fields needed to capture necessary information. For unique, one-off messages, such as the main headline on their homepage, they plan to use inline editing within a fragment. By strategically using both structured and inline content, Clarity can deliver engaging and consistent digital experiences that are easy to manage and scale.

Conclusion

Designing effective content structures is the foundation for scalable and contributor-friendly content authoring. Making the right architectural decisions about fields, categories, and authoring strategies is the key to building maintainable and future-proof content solutions.

Next, you'll create web content structures for Clarity's solution.

loading-knowledge-label