YOOtheme DevStack - Joomla Template

Guide to Setting Up and Using YOOtheme DevStack for Joomla

YOOtheme DevStack is not just a ready-made visual shell for a Joomla site. It is a starter kit for a product or technology website built around YOOtheme Pro. In this guide, we will walk through how to approach the template after installation: which layouts to use, where to configure styles, how to connect menus and modules, what to check on the live site, and which issues most often prevent the final result from looking like the demo.

This article does not repeat the short template description. The focus here is practical work: preparing the site, installing the template, running an initial check, configuring the header, pages, cards, images, responsive behavior, multilingual setup, and troubleshooting. We will also look at how to use DevStack for a SaaS site, an app, documentation, a support page, and a product blog.

This guide is written for a site owner, webmaster, or developer who already understands the basics of Joomla but does not want to get lost inside YOOtheme Pro. If you are migrating an older site, building a new product website, or putting together a quick prototype, read the sections in order. If the template is already installed, you can jump straight to layouts, menus, modules, and result validation.

What DevStack Actually Gives You and Where It Works Best

DevStack is designed for websites that need to explain a digital product: a service, an app, a platform, a technology team, documentation, pricing, support, and news. The official YOOtheme page shows that the package is built on YOOtheme Pro and includes ready-made pages, styles, and a curated image set. That matters because the value of the template is not limited to a single homepage design. You get a full page system that can be deployed as a demo website and then adapted to your own product.

In practice, DevStack is especially useful in three situations. The first is launching a new product when you need to quickly build a clear homepage, feature sections, pricing, a support page, and a content area. The second is redesigning a company website that already has Joomla content but looks outdated. The third is prototyping site structure before investing in a fully custom design, so the team can validate navigation, messaging, page types, and section order before moving into deeper customization.

The template has a distinct visual personality: a clean tech-oriented presentation, soft cards, glass-style effects, large typography, accent gradients, illustrated sections, and a page structure that feels familiar for SaaS products. It is not a universal template for every kind of business. For a restaurant, a real estate catalog, or a news portal, it will require more rework than a niche-specific template.

When the Template Is an Especially Good Fit

DevStack makes the most sense when you need not just a single landing page but a connected set of pages. For example, the homepage introduces the product, the Features page explains capabilities, Pricing presents plan logic, Support leads to help resources, and the blog is used for product updates and educational content. In that kind of setup, the template saves more than design time. It also saves time on information architecture.

• The site needs to present product functionality, not just serve as a corporate brochure.
• The team wants a demo structure they can launch quickly and then replace texts, illustrations, pricing, and sections.
• The project benefits from ready-made page layouts, styles, media, and visual consistency.
• Editors are willing to work inside YOOtheme Pro and understand the difference between a page layout, a post template, a module, and a menu item.

Where DevStack May Be More Than You Need

If your site consists of just a couple of static pages and does not need a visual builder, DevStack may be overkill. YOOtheme Pro is powerful, but that flexibility requires more attention from the site administrator. You need to understand where the layout is stored, which styles are applied, which modules are assigned to positions, what is managed through Joomla, and what is handled through the builder. For a small site without frequent updates, a minimal template with standard articles and modules may be easier to maintain.

The main check before choosing it: if you do not plan to use ready-made pages, style variations, the page builder, and module positions, DevStack turns into a beautiful shell that you will spend a long time simplifying.

DevStack Page Map: What to Keep, Replace, or Remove

The official DevStack page describes a set of ready-made layouts for a product website: homepage, feature pages, company sections, pricing pages, support, search, blog, post, author, and error pages. That gives you a strong starting architecture, but you should not move it over to a live site without filtering it first. The right approach is to decide which pages actually reflect your product and which ones are just demo filler.

In YOOtheme Pro, ready-made layouts can be loaded from the library, and your own layouts can be saved for reuse. For DevStack, that is especially useful. One feature section can become the base for several pages, and cards for integrations or capabilities can be adapted to different product directions. But if you keep every demo page without thinking, the site will look like a template showcase instead of your product.

Why Structure Matters More Than Colors at the Start

Many people start customizing a template with the logo, font, and button color. For DevStack, that is the wrong order. First, you need to understand which pages belong in the menu and which layouts are actually needed. If the structure is undefined, you will keep reworking the header, links, cards, and buttons. A better approach is to map out the site first: homepage, features, solutions, pricing or packages, support, resources, and contacts. Then choose the demo pages that best match that map, and only after that move into styling.

How to Keep Pages and Templates Connected

YOOtheme Pro distinguishes between individual page layouts and site-wide templates for posts, categories, search results, and other page types. That is useful, but it requires discipline. An individual page works well for the homepage or a product page. A post template is a better choice for the blog so new articles automatically inherit the same structure. If every post is built as a separate manual layout, the site becomes difficult to maintain.

Short version: first decide which pages reflect your funnel, then load the right layouts, then configure the menu, and only then style the cards, sections, and buttons. That order reduces rework.

Preparing a Joomla Site Before Installation

There are two ways to use DevStack: install YOOtheme Pro into an existing site and load the layouts you need, or deploy the demo package as a full Joomla installation with demo content. These are two different workflows. A full demo installation package cannot simply be installed over an active site like a regular template. If you already have a working project, use the standard template installation and import layouts through YOOtheme Pro tools.

Before installation, check the server environment and permissions. The YOOtheme Pro documentation specifically calls out PHP requirements and the GD extension, as well as possible issues with file upload limits and write permissions. For a template that includes demo media, that is not a formality. If the archive upload fails, images are not generated, or settings are not saved, the root cause is often hosting resources or file system permissions rather than the template itself.

Pre-Installation Checklist

• Create a backup of the files and database if you are working on an existing site.
• Make sure the server meets the requirements for both YOOtheme Pro and Joomla, including the necessary PHP extensions.
• Check upload_max_filesize, post_max_size, memory_limit, and max_execution_time if the archive fails to upload.
• Confirm that Joomla can write to the required directories, especially if styles, cached images, and media will be generated.
• Decide which users should be allowed to open YOOtheme Pro and modify the template.
• Prepare the logo, favicon, key images, homepage copy, and the initial menu structure.

Access Permissions for Editors

YOOtheme Pro is tightly connected to Joomla permissions. If access is given to too many users, an editor can accidentally change a global style, delete a section, or break a layout. If access is too restrictive, the team will not be able to update pages. On a production site, it makes sense to split responsibilities: the administrator manages the template and styles, the editor updates content in approved areas, and the developer handles the child theme, CSS, and overrides.

A solid rule for a working site: do not grant template editing rights to people who are only responsible for text updates and news posts. For content work, use articles, fields, modules, and prebuilt layouts.

Installation and Initial Validation Without Unnecessary Risk

If you are installing DevStack on an existing site, start with a standard YOOtheme Pro theme package installation through the Joomla extension manager. After installation, confirm that the template appears in the list of site templates, the correct template style is selected, and the YOOtheme Pro entry is visible in the admin area. If you are deploying a demo site from scratch, use the demo package as a separate Joomla installation, not as an extension archive.

The initial validation should be short but strict. Do not start editing every page right away. Open the homepage and check that styles load correctly, the menu is visible, media displays properly, the builder opens, the Save and Cancel buttons appear after changes, and live preview reacts to edits. If there are issues at this stage, do not move on to broad customization. Find the cause first.

First Launch Sequence

1. Install the template or deploy a separate demo package in a test environment.
2. Open the Joomla admin panel and access YOOtheme Pro through the menu item or template style.
3. Check the Settings panel, system recommendations, and whether saving is available.
4. Open the live site in a separate tab and compare it with the preview inside the customizer.
5. Make one small safe edit, such as changing sample text or a temporary color, save it, and confirm the result.
6. Undo the test edit or restore the previous value so you know the workflow is under control.

What to Do If the Demo Looks Different

The most common reason your site does not match the demo is missing demo content, unconnected images, a different menu structure, or modules that were never assigned. DevStack can look polished in the official demo because the pages, media, styles, copy, and internal connections are already in place. If you install only the template on an empty site, it is not supposed to generate content by itself. So do not compare it in vague terms like "nice" or "not nice." Compare specific items: the selected style variation, the active template style, the page layout, menu assignments, whether images exist, and whether modules are rendered.

Configuring Styles, the Header, and DevStack's Visual System

DevStack has a strong visual language: soft surfaces, a bright background, dimensional cards, glass-style navigation, vivid accent buttons, and tech-oriented illustrations. The official materials point to several ready-made style variations. Start by choosing the variation that is closest to your brand instead of manually changing dozens of variables. That makes it easier to preserve visual consistency.

In YOOtheme Pro, the look and feel is configured in the Style panel, while the overall site structure is handled in Layout. The logo, header, navbar, mobile header, top, bottom, sidebar, and footer affect how the entire site feels. For DevStack, the header is especially important. The reference design shows a light top navigation, a calm background, a sign-up accent button, and a large centered hero. If you overload the header with modules, banners, and a second row of links, the template loses its character.

Where to Start in the Style Panel

Open Style and choose the closest ready-made variation. Then review global colors, fonts, buttons, cards, sections, and link states. Do not change everything at once. In DevStack, many elements are designed around subtle shadows and a light background. If you sharply increase contrast, enlarge corner radii, or switch to heavy dark backgrounds, the sections can start fighting each other.

Practical Configuration Order

1. Choose the style variation that is closest to your brand.
2. Check text readability on the homepage and support page.
3. Set the primary accent for buttons and links, but keep the secondary tones restrained.
4. Review the cards in feature and pricing sections. Shadows should help separate blocks, not turn the page into a stack of heavy tiles.
5. Save the result and open the site in a separate window outside admin mode.

Header and Navigation

In DevStack, navigation should quickly lead users to the core product sections: why the product matters, who it is for, pricing or implementation options, documentation, company info, login, or sign-up. If the site does not use registration, do not leave that button in place just because it exists in the demo. Replace it with contact, request a demo, or download documentation. In YOOtheme Pro, menus can be managed in the Menus panel, while menu publishing depends on menu positions or module positions.

For a multilingual site, do not rely on menu positions alone. YOOtheme Pro documentation warns that multilingual scenarios are better handled with menu modules in the appropriate positions, because different languages need separate menus, assignments, and connections. That matters even more in DevStack, where the header is visually lightweight and any extra or incorrect menu item stands out immediately.

Page Layouts and the Layout Library

YOOtheme Pro lets you load ready-made layouts from the library, save your own sections, and move layouts between projects. For DevStack, this is one of the main working tools. You do not have to build every page from scratch. You can start from an appropriate layout, replace the content, and then save the adapted section to your own library.

That said, the layout library needs to be used carefully. By default, loading a new layout can replace the existing one. The documentation describes several behaviors: replace the current layout, insert above, or insert below. On a live project, the safer approach is to duplicate the page or save the current layout version first, and then test the insertion. Otherwise, you may lose a structure you already configured.

How to Adapt the Homepage

The DevStack homepage should answer three questions: what the product is, who it is for, and why the visitor should keep exploring. The demo structure with a hero, video, benefits, trust logos, and feature cards gives you a strong starting point. But generic copy should be replaced with specifics: the customer's problem, the core promise, three to five key capabilities, proof, and the next step.

1. Keep the top hero section and replace the headline with your product message.
2. Rewrite the subheadline so it names the audience and the outcome.
3. Check the CTA buttons. One should lead to the primary action, and the second should lead to an explanation or demo.
4. Replace the “How does it work?” block with the real product flow: input, processing, result.
5. Use tool cards only for confirmed capabilities.

How to Work with Repeating Sections

Sections with feature cards, client logos, pricing, and articles should not be copied around randomly. Save a good version in My Layouts or use a shared section template. That way, design updates remain predictable and the site does not turn into a mix of similar but inconsistent blocks.

Check after loading a layout: open the page on a wide screen, tablet width, and narrow width. If the column order breaks the meaning, adjust the row layout, gap, and element visibility before publishing.

Menus, Modules, and Positions in a Joomla Template

With a Joomla template, it is important to understand the relationship between menus, modules, and positions. DevStack is built on YOOtheme Pro, where menu and module managers are integrated into the customizer. That is convenient because you can open the Menus or Modules panel and immediately see the result in preview. But the underlying logic is still Joomla logic: menu items point to articles, categories, and components; modules are published in positions; and module assignment can depend on the current page.

YOOtheme Pro provides positions for toolbar, logo, navbar, header, dialog, mobile header, sidebar, top, bottom, and builder positions. In DevStack, that system is especially useful for the header, support areas, footer, and repeatable product blocks. For example, a separate module with quick links can be published in bottom, while a documentation menu can appear in sidebar or inside the layout through a menu element.

Practical Menu Logic

For a typical product website built on DevStack, the menu might look like this: Home, Features, Solutions or Use Cases, Pricing, Support, Blog, Company, Contact. If the site has many pages, do not push everything into the top navigation. Use a mega menu only where it actually helps, for example to group features by role, link to documentation, or surface resource categories. If a mega menu is used only for visual effect, it makes the site harder to maintain.

Modules and Page-Level Assignment

Modules work well for repeatable blocks: the footer, a list of support links, a demo banner, a language switcher, secondary menus, or a contact block. During troubleshooting, always check not only the position but also the menu assignment. If a module is published in the correct position but not assigned to the current menu item, users will not see it. If a module is assigned to all pages, it may appear in places where a different context is needed.

Quick Module Check

• The module is published and contains actual content.
• The position matches the real output location in YOOtheme Pro.
• The menu assignment includes the required page.
• The access level does not hide the module from regular visitors.
• Joomla cache and YOOtheme cache have been cleared after the change.

Dynamic Content, Fields, and Post Templates

DevStack may look like a collection of attractive pages, but for a long-term site the more important question is how to avoid turning every post and card into manual page composition. YOOtheme Pro supports dynamic content, meaning it can pull Joomla data directly into layout elements. That is useful for a product blog, knowledge base, feature list, team pages, author pages, and resource cards.

The official DevStack documentation points to custom fields for posts and users. That is a good model to follow. Instead of manually copying the author name, description, image, and links into every page, you can store the data in Joomla and render it through a template. Then changes to the article or profile are automatically reflected wherever they are used.

When to Use Site-Wide Templates

A site-wide template makes sense anywhere you have a large number of similar pages. In DevStack, that includes the blog, posts, authors, categories, search, and help pages. If you have twenty knowledge base articles, do not build twenty separate layouts. Create a post template and connect the title, image, intro text, author, tags, and related content to Joomla fields. That keeps the site manageable.

How to Avoid Empty Blocks

YOOtheme Pro can collapse elements, columns, rows, and sections when the dynamic source is empty. That is useful for cards where not every entry has an image, tag, or extra link. But you should not rely on automatic collapsing alone. It is better to define required fields in the content model from the start. For example, a knowledge base article should require a title, short description, and category, while the image and author block can remain optional.

A practical guideline: if a block is important to the meaning of the page, the field should be required in the editorial workflow. If the block is decorative, it can stay dynamic and the layout can safely collapse when the value is empty.

Practical Example: Building a Homepage for a SaaS Product

Below is a concrete scenario that shows how DevStack can be used on a real site. Imagine you need to build a homepage for a cloud service that explains the product, showcases the features, and leads people to pricing, support, and a demo. The goal is to create a page that keeps DevStack's polished tech style while speaking about your product rather than the template.

Goal

You need a homepage where the visitor understands the offer in the first screen, sees the product workflow and advantages in the next sections, and then gets a clear path to pricing, documentation, or a contact request. To do that, use DevStack's ready-made structure, but replace the demo content and remove blocks you do not need.

Preparation

Before making changes, prepare a short hero message, a list of core features, three or four client or integration logos, one visual asset for the presentation video, and links to pricing and support. If you do not have those yet, draft the text in a separate document first. Editing meaning directly inside the builder is inefficient because it is easy to start bending the text to fit the card instead of clearly explaining the product.

Steps

1. Open the homepage in the Pages panel and make sure you are editing the correct item.
2. In the hero section, replace the headline, subheadline, and CTA buttons. One CTA should lead to the main action, the second to a more detailed explanation.
3. In the video section, keep only useful content. If there is no video yet, temporarily replace the block with a product screenshot or illustration.
4. In the logo section, use real brands, integrations, or partners. If you cannot verify them, remove the section so you do not create a false impression.
5. Rewrite the “How does it work?” section as a sequence: “input -> processing -> result”.
6. Connect the tool cards to real functions: deployment, automation, integrations, support, analytics, or other verified capabilities of your product.
7. At the end, add a path to pricing, a contact form, or the support page.

Result Check

Open the live site without administrator rights. Confirm that the first screen explains the offer without requiring scrolling, the buttons lead to real pages, the cards do not contain demo copy, the images are sharp, and the mobile version preserves the order of the key content blocks. Then review the page in preview mode across multiple device sizes.

A Common Issue That Gets in the Way

If the page still feels like a demo after editing, the problem is usually that the words were changed but the logic of the sections was not. For example, a trust-logo block may not make sense for a new product that has no real clients yet, a pricing table may not fit a service sold through custom contracts, and a support page may not be useful without an actual knowledge base. Remove or rename blocks confidently if they do not support the real funnel.

Practical Ways to Use DevStack

DevStack can be used for much more than a single homepage. Its real strength is the combination of product-focused design, ready-made pages, the builder, dynamic content, and post templates. Below are several scenarios based on real YOOtheme Pro capabilities and the standard DevStack structure.

SaaS or App Website

Use the homepage, features, pricing, and support as your foundation. The hero explains the product, feature pages expand on capabilities, the pricing page helps compare options, and the support page gathers documentation. The result is easy to validate: within two or three clicks, a user should understand what the product does, where to learn more, and where to go for the next step.

Knowledge Base Around a Product

If the product has a large number of instructions, DevStack can be turned into a help center. The support page becomes the entry point to documentation, search helps users find materials, and the post template gives every article a consistent structure. In this setup, dynamic fields and site-wide templates are especially valuable because dozens of articles need to look consistent without manually building each layout.

Corporate Website for a Technology Team

Use the About, Careers, Support, and Blog pages as the company foundation. The key is not to overload the homepage with technical details. The “why us” section can be tied to case studies, careers can connect to benefits for candidates, and the blog can be used for product news. This kind of site becomes convincing when the demo images are replaced with real team assets or clean visuals that match the subject.

Prototype Before Custom Development

DevStack works well for validating ideas. You can assemble the site structure, show the client real scenarios, test the menu, and check block order before deciding what should later be rebuilt as part of a custom design. In that case, do not spend too much time on small visual refinements. The value of the prototype is in validating the logic, not in perfect pixel polish.

Images, Speed, and Visual Stability

DevStack includes many visual blocks, so image quality and media settings directly affect how the site feels. YOOtheme Pro supports the media manager, focal point, responsive images, lazy loading, and modern formats. That does not mean you can upload any oversized files without thinking. The more hero images, background illustrations, and cards you use, the more carefully you need to manage file sizes and caching.

For the hero section, use a large image that still serves a clear purpose. If the hero includes video, check the consent manager and placeholder behavior. For feature cards, use a consistent visual style and proportions. If one card uses a photograph, another an SVG illustration, and a third an abstract icon, the visual system falls apart even with a good template underneath it.

What to Check in Files & Images

• Images have correct dimensions so the layout does not jump during loading.
• The focal point is set where automatic cropping might otherwise cut off an important part of the image.
• Lazy loading does not break the first screen. Important images in the initial viewport should appear without noticeable delay.
• Cached images are cleared after changing quality or format settings.
• Next-gen formats are enabled only if the server supports the required conditions.

SEO and Accessibility Without Inflated Expectations

YOOtheme Pro is built on UIkit and supports semantic features, aria labels, and logical structure, but the final level of accessibility and SEO still depends on the author. You cannot expect the template to automatically fix weak headings, empty alt text, meaningless buttons, or poor contrast. For DevStack, hierarchy matters especially: one clear page heading, logical H2 and H3 headings in the content, descriptive links, alt text for important images, and sufficient contrast on accent gradients.

Result check: if images are turned off, the user should still understand the page through the headings, button text, and block structure.

Multilingual Setup, Menus, and the Footer Without Conflicts

DevStack is often chosen for products that need to support multiple languages. Joomla includes multilingual support out of the box, and YOOtheme Pro adds a convenient language switcher. But a multilingual site cannot be built by simply copying the homepage. You need duplicate content items, menus, modules, and a clear check of how each language is connected to its menu items and templates.

YOOtheme Pro documentation notes an important nuance: for multilingual sites, menu positions and the footer builder have limitations. Instead, language-specific menus are better handled through menu modules, and the footer is better handled through builder modules in the bottom position. That directly affects DevStack because the header and footer in a product-oriented theme usually contain the key navigation paths.

Order of Work for a Multilingual DevStack Site

1. First configure the primary language version and finalize the page structure.
2. Save repeatable sections into the layout library.
3. Create content items and menu items for the second language.
4. Transfer the layouts through the library and translate the content.
5. Create separate menu modules for each language and publish them in the correct positions.
6. Check that the language switcher does not lead to empty or incorrect pages.

When to Translate Pages

It is better to translate pages after the structure and design of the main version are already stable. Otherwise, every section change will need to be repeated in each language copy. That becomes especially noticeable in DevStack, where layouts can be content-heavy: hero areas, cards, images, pricing, forms, FAQs, and the footer quickly become a large set of synchronization points.

Safe Enhancements: CSS, Child Theme, and Language Overrides

Small improvements make sense in DevStack as long as they do not break updates or require editing the Joomla or YOOtheme Pro core. YOOtheme Pro documentation offers two safe paths: add CSS/Less through the Settings panel or create a child theme with css/custom.css and js/custom.js. For interface string translations, use Joomla language overrides.

Below is an example of a small CSS adjustment for cards where you manually added the devstack-feature-card class in the element settings. It does not modify the core and is easy to roll back: remove the class from the element or delete the CSS.

.devstack-feature-card {
  border-radius: 18px;
  box-shadow: 0 18px 45px rgba(39, 43, 88, 0.10);
  transition: transform 180ms ease, box-shadow 180ms ease;
}

.devstack-feature-card:hover {
  transform: translateY(-3px);
  box-shadow: 0 24px 60px rgba(39, 43, 88, 0.14);
}

@media (prefers-reduced-motion: reduce) {
  .devstack-feature-card {
    transition: none;
  }

  .devstack-feature-card:hover {
    transform: none;
  }
}

The change is built on safe logic: YOOtheme Pro allows custom CSS, DevStack uses a card-based visual system, and the class applies only to selected elements. After adding it, check the page with cards, test the mobile width, and review reduced motion mode. If the hover effect makes the interface feel too animated, keep only the shadow or remove the rule completely.

When You Need a Child Theme

If the change is just a few lines of CSS, the Settings panel is enough. A child theme becomes useful when you start adding your own files, fonts, template overrides, custom elements, or repeatable enhancements across multiple projects. Important point: a child theme does not need to modify template settings. Its purpose is to keep code-level changes separate from YOOtheme Pro so updates do not overwrite your work.

Language Overrides for Clean Translation Work

If you need to change the text of a cookie banner, a system message, or another interface string, do not search for it in the template files. Use Joomla's built-in language override system. That way, the change survives updates and does not require editing source files.

Checking the Result Before Publishing

DevStack should be reviewed across several layers: structure, visual result, Joomla logic, performance, accessibility, and permissions. Simply opening the homepage is not enough. A template can look good on the first screen while still containing empty demo pages, incorrect menu items, hidden modules, oversized images, or broken translations.

Start with the site map. Every menu item should lead to the right page, and every page should have a clear purpose instead of remaining as demo leftovers. Then check the style variation, header, footer, cards, pricing, support, and blog. After that, open the site as a regular user, because administrators may see elements that are hidden from visitors.

Checklist

• The first screen explains the product without requiring the whole page to be read.
• All CTA buttons lead to real pages or forms.
• Demo copy, empty logos, and temporary cards have been removed.
• The menu does not contain pages that are still unfinished.
• Modules are published in the correct positions and assigned to the right menu items.
• Mobile navigation works independently from desktop navigation.
• Images do not cause layout shifts and do not appear blurry.
• Styles save correctly, cache clears properly, and the system check shows no critical problems.
• Editors have only the permissions they actually need.

How to Know the Site Is Ready for User Testing

The site is ready for external testing when a new visitor can complete the intended flow without instructions: understand the offer, move to the features, find pricing or terms, open support, read the content, and return to the main action. If users ask, "Where is the documentation?", "Why does this button go somewhere else?", or "Is this your product or just the demo?", the setup still needs more work.

Troubleshooting Common DevStack Issues

Most problems with DevStack are not caused by the template "breaking." They usually come from a mismatch between Joomla, YOOtheme Pro, permissions, cache, module positions, and demo content. Below is a practical symptom map. Use it from top to bottom: first rule out simple causes, then move on to server settings and the child theme.

The Template Installed, but the Site Does Not Look Like the Demo

Symptom: the site looks empty, key sections are missing, images are absent, and the menu differs from the reference. A likely cause is that only the template package was installed without the demo content, or the required layouts were never loaded from the library. Check which installation path you used: a standard template for an existing site or the full demo package for a new installation.

Fix: load the required layouts through the Layout Library, replace the content, assign the correct menu items, and confirm the selected style variation. Do not try to "repair" an empty page with CSS if the real problem is that the needed layout is missing.

The Customizer Does Not Save Changes

Symptom: edits appear in preview, but disappear after saving, or a write error appears. Likely causes include file permissions, conflicting file ownership on the server, or issues writing CSS or settings. Check the permission guidance: directories often use 755 and files 644, but the exact values should match your hosting policy.

Fix: check file ownership, permissions on the template and cache directories, and the YOOtheme Pro system panel. If you do not manage the server yourself, send the host a concrete symptom description, such as theme settings not saving or the CSS file not being generated.

The Archive Does Not Upload or the Installation Stops

Symptom: Joomla refuses the archive, the installation is interrupted, you get a white screen, or the process times out. A likely cause is PHP limits: upload_max_filesize, post_max_size, memory_limit, and max_execution_time. This is especially common on shared hosting and with large demo packages.

Fix: increase the limits through your hosting panel or ask the server administrator to do it. If this is the full demo package, do not install it as a standard extension. Unpack it and install it as a separate Joomla site.

A Module Is Published but Not Visible

Symptom: the module exists in the admin panel but does not appear on the target page. Possible causes include the wrong position, empty output, menu assignment, access level, device-based visibility, or a position that is not used on a page built with the page builder. Check the position in YOOtheme Pro first, then review the menu assignment and publishing status.

Fix: assign the module to the correct menu item, choose an appropriate position, check device visibility, and clear the cache. If the content needs to be inserted directly into the page layout, use the relevant builder element or a builder module instead of expecting the position to appear automatically.

The Menu Shows the Wrong Items in Different Languages

Symptom: the language switcher works, but the menu remains from another language or leads to the wrong pages. The cause is often that menu positions were used instead of separate menu modules for a multilingual site. Check whether separate menus and modules were created for each language and whether they were assigned to the correct positions and pages.

Fix: create a separate menu module for each language and publish it in the proper position. For different-language footers, it is often better to use builder modules in bottom if the shared footer builder does not cover the scenario.

Part of the Page Looks Broken After a Style Change

Symptom: buttons, cards, or sections lose contrast, shadows become too heavy, or the customizer shows a Less error. The cause is usually an overly aggressive change in the style customizer or an invalid Less value. YOOtheme Pro documentation notes that incorrect values can stop style compilation.

Fix: go back to the component you changed and reset that specific setting using the gray dot, or use the component reset option. If you added custom CSS or Less, temporarily remove the snippet and save the style again. It is better to roll back precisely than to reset the entire site unnecessarily.

Helpful DevStack Video

YOOtheme has a focused presentation of DevStack as a theme package for YOOtheme Pro. The video is most useful after you already understand the structure of the template. It shows the logic of the ready-made pages, visual techniques, style variations, cards, background elements, and theme-specific details. It is not a substitute for configuring the template in Joomla, but it is a strong visual reference for deciding which parts of DevStack are worth keeping and which should be adapted to your product.

Watch the video with a practical goal in mind: note which layouts fit your site, which visual effects are worth keeping, where you need original copy, and where a demo block should be removed entirely. It is especially useful to compare the demo feature, pricing, and support pages against your future site map.

When YOOtheme DevStack Is the Right Choice

YOOtheme DevStack is a strong choice if you need a tech-oriented Joomla template for a product, service, app, support center, or company website, and you are comfortable working inside YOOtheme Pro. Its real strength is not a single attractive screen but a complete system of layouts, styles, media, and templates that can be turned into a full product website.

Before publishing, check the page structure, menu assignments, module output, styles, images, user permissions, and how the site behaves outside administrator mode. If DevStack still fits your needs after that, move on to testing it on a site copy and only then push the changes to production. When you are ready to continue, you can download YOOtheme DevStack and follow the safe installation path described in this guide.

If what you actually need is a minimal template without a builder, a strict custom development path, or a different visual language, it is better to choose an alternative before moving all of your content into DevStack. That will save time and help you avoid ending up with a polished demo package that works against the real needs of the site.