🇺🇸United States @flashwebcenter

Thanks for reporting this! I was able to reproduce the swipe issue and have pushed a fix to the dev branch. The problem was caused by a change in how touch and pointer events were handled, which made right-to-left swipes inconsistent on some devices.

Please update to the latest dev release and test again. Swipe should now feel smooth and reliable across all devices. Let me know if you still see anything odd!

Best wishes,
Alaa

Hello,

Thank you for bringing this issue to my attention. The issue you encountered is related to the responsive table classes applied by the theme to the table wrapper.

Understanding Responsive Tables:
Drupal's "responsive" table option hides columns on small or medium devices, completely removing them from view. Solo theme takes a different approach - all tables have responsive behavior by default using a wrapper div that enables horizontal scrolling, so no columns are ever hidden. This ensures all data remains accessible on any screen size.

The Sticky Header Conflict:
The sticky table header feature wasn't working because the .solo-table-wrapper had overflow-x: auto applied to all tables. The CSS position: sticky property requires all parent elements to have overflow: visible - any other overflow value (auto, hidden, scroll) prevents sticky positioning from functioning. This creates a conflict between two useful features: sticky headers (which keep column headers visible when scrolling vertically) and horizontal scrolling (which allows wide tables to scroll sideways on narrow screens).

The Solution:
I've updated the CSS so horizontal scrolling (overflow-x: auto) is only applied to tables that don't have sticky headers enabled, allowing you to choose which feature is more important for each table.

The fix was pushed to dev version feel free to use it and it will be available in the next release.

Best wishes,
Alaa

Hello,

Thank you for suggesting this feature. I’ve added it to the dev release. Please feel free to test it out.

Best wishes,
Alaa

Glad to hear it’s working as expected! Thank you for the kind words. I really appreciate your feedback.

Hello,

Thank you for the kind words and for reminding me about the Deep Linking feature. It has been on my agenda to extend this functionality to all vvj* modules after I first implemented it in the Paragraphs Bundles Tabs example.

I’ve now completed the work to make Deep Linking fully configurable from the form UI, and I also introduced a global JavaScript API so developers can target or control any slideshow programmatically. This feature was included in the latest release (1.0.25) and added to vvja, vvjb, vvjc, and vvjt as well. These enhancements are enabled on the live demo site.

3D Carousel Example: http://unitedstarsofamerica.local/vanilla-views/views-vanilla-javascript...
Basic Carousel Example: http://unitedstarsofamerica.local/vanilla-views/views-vanilla-javascript...
Accordion Example: http://unitedstarsofamerica.local/vanilla-views/views-vanilla-javascript...
Slideshow Example: http://unitedstarsofamerica.local/vanilla-views/views-vanilla-javascript...
Tabs Example: http://unitedstarsofamerica.local/vanilla-views/views-vanilla-javascript...

For your current task, you have two options:
• Continue using VVJS and add a thumbnail element to navigate through the slideshow, or
• Use VVJT, which already has a similar thumbnail-to-panel interaction demonstrated on the live site.

You can find example implementations for both approaches directly in the README.md files.

Best regards,
Alaa

Hello,

Thanks for the detailed report! I've identified and fixed the issue – the slideUp() and slideDown() utility functions were announcing for all components instead of just menus. The fix adds an optional parameter to control announcements, resolving all three cases you reported while maintaining backward compatibility.

Please feel free to download the dev version and test it, and if you find any issues please feel free to report it back.

Best wishes,
Alaa

Hello,

The layout problem on that page is caused by the embedded iframe. It has a fixed width, so when the browser window becomes narrow the iframe pushes outside the container. This happens independently of the theme, and I confirmed the same behaviour in Olivero.

To help with this, I’ve added a new feature to the theme that provides a responsive wrapper for iframes along with optional aspect-ratio utility classes. This lets users make any iframe fully responsive without relying on fixed pixel widths.

Basic usage:

<div class="responsive-embed">
  <iframe>…</iframe>
</div>

The default aspect ratio is 4/3, but you can override it by adding one of the utility classes:

.aspect-ratio-1-1  { aspect-ratio: 1 / 1; }
.aspect-ratio-4-3  { aspect-ratio: 4 / 3; }
.aspect-ratio-3-2  { aspect-ratio: 3 / 2; }
.aspect-ratio-16-9 { aspect-ratio: 16 / 9; }
.aspect-ratio-21-9 { aspect-ratio: 21 / 9; }
.aspect-ratio-9-16 { aspect-ratio: 9 / 16; }

Example with a custom ratio:

<div class="responsive-embed aspect-ratio-16-9">
  <iframe>…</iframe>
</div>

I tested the iframe from your page using this wrapper, and it displays correctly and remains responsive:

    <div class="responsive-embed">
      <iframe
        src="//umap.openstreetmap.fr/it/map/monte-alto_1260853?scaleControl=false&miniMap=false&scrollWheelZoom=false&zoomControl=true&editMode=disabled&moreControl=true&searchControl=null&tilelayersControl=null&embedControl=null&datalayersControl=true&onLoadPanel=none&captionBar=false&captionMenus=true"
        loading="lazy"
        allowfullscreen
        allow="geolocation"
        frameborder="0"
      ></iframe>
    </div>

    <p class="text-align-center">
      <a class="link nota"
         href="//umap.openstreetmap.fr/it/map/monte-alto_1260853?scaleControl=false&miniMap=false&scrollWheelZoom=true&zoomControl=true&editMode=disabled&moreControl=true&searchControl=null&tilelayersControl=null&embedControl=null&datalayersControl=true&onLoadPanel=none&captionBar=false&captionMenus=true">
         Visualizza a schermo intero
      </a>
    </p>

Feel free to test this on your site, and let me know if anything behaves differently on other pages.

Best regards,
Alaa

Hello,
The feature was added to the 1.0.24 release.

Best wishes,
Alaa

Hello,

If the configuration was exported from the old site and imported into a fresh installation, some configuration items may not have been fully created or imported correctly. Occasionally, the installation process can be interrupted or incomplete, especially for complex entities like Paragraph types or media fields.

When this happens, I usually uninstall the affected module or feature, delete its related configuration (for example, the Paragraph type, media field, and image style), and then reinstall or re-import them one by one. This helps ensure all dependent configurations are generated properly.

It’s also possible that an environmental or memory-related issue on the site could have affected the installation process.

Glad to hear it’s working now!

Best regards,
Alaa

Hello,
The options were added to the new release 1.0.14 please feel free to use it.

Best regards,
Alaa

Hello,

Thank you for the details and screenshot. It looks like something may have changed in the Manage form display settings for the Image paragraph bundle.
Please visit:
your-new-site-dot-com/admin/structure/paragraphs_type/image_bundle/form-display
and compare it with:
your-old-site-dot-com/admin/structure/paragraphs_type/image_bundle/form-display

Make sure both pages have the same configuration. I’ve attached a screenshot showing how it should look.





Please let me know how it goes, or if you need any further help.

Best regards,
Alaa

You are welcome! Glad it is working now.

Hello,
Thank you for the video. However, it looks like you’re still using the old version. The dev version includes a different button style, as shown in the attached video → .

Please make sure to download the latest dev version and test again.

Best regards,
Alaa

Hello,

Thank you for reporting the issue. I attempted to replicate the error locally but was unable to reproduce it. However, based on the stack trace, the issue occurs when `solo_preprocess_container()` calls `Element::children($variables['element'])` without first verifying that `$variables['element']` exists.

Layout Builder's off-canvas dialogs may not include the `$variables['element']` array in their render structure, which causes the fatal error when trying to access it.

I've added defensive checks to ensure `$variables['element']` exists and is an array before processing. This fix has been committed to the dev branch.

Please download the latest dev release, clear your Drupal cache (`drush cr`), and test again. Let me know if you continue to encounter this issue.

Best regards,
Alaa

Hello,

Static CSS can’t override CSS variables, but inline mode can. I’ve updated the development version with the following changes:
Added a checkbox in the settings form. When checked, the generated CSS will use the !important rule to override any existing styles.
Added a new Head mode, similar to inline mode, but it prints the CSS inside the tag.

You can download and test the updated development version now.

Best regards,
Alaa

Hello,

I downloaded the module and tried to use it with a YouTube video on the Olivero theme, but the block didn’t work. The theme doesn’t override or create any media fields. The browser console shows this error: “Refused to apply style… because its MIME type ('text/html') is not a supported stylesheet MIME type.”

Best wishes,
Alaa

Thanks for the detailed steps! The PDF Reader module uses

Thanks, I’ll take a look, but note that I do have custom settings applied to some fields.

Thank you for reporting these accessibility issues. I've addressed all three problems in the 2.0 release:
1. Visual feedback for focus
Added CSS styling to provide clear visual indicators when elements receive keyboard focus, including outline and box-shadow effects.
2. Keyboard navigation with arrow keys
Arrow key navigation is now fully functional. Users can navigate through dropdown options using ArrowUp and ArrowDown keys.
3. Broken ARIA references

Made aria-describedby conditional, it's only added when a field description actually exists
Enhanced the JavaScript function to dynamically handle label associations
Created a Twig extension to properly sanitize option IDs, ensuring valid HTML identifiers for ARIA attributes

Please update to 2.0 release and test on your site. Let me know if you encounter any remaining issues.

Best wishes,
Alaa

Appreciate it! Glad to hear that!

Hello Steve,

Thank you for your feedback and for taking the time to explore the color system!

Yes, the behavior you noticed is intentional. The region color variables are designed to override the predefined color schemes. When I created the predefined schemes, the goal was to provide flexible starting points: many users like the general style of a scheme but want to adjust a few colors to better fit their own design preferences.

That’s why the system supports two approaches:

1. Fully custom design: You can disable all predefined color schemes and start entirely from scratch, building your own unique look.
2. Partial customization: You can keep a predefined scheme active and override specific colors in certain regions to fine-tune the appearance while retaining the base style.

This gives users the freedom to mix structure and creativity depending on their needs.

Thanks again for your thoughtful suggestion and for using the Solo theme!

Best regards,
Alaa

Hello @martinfer,

Thank you for bringing this to my attention, and for your kind words about the theme. I really appreciate it!

This task was related to the Better Exposed Filters module, which uses different markup and behavior than Drupal core. I’ve updated the code to handle both, the module’s classes and the default Drupal ones.
Previously, the form was responsive and would collapse on smaller screens. However, you made a great point about cases where the form is placed in a sidebar with limited width. To address this, I’ve added a minimum width of 170px to each field and max width for both 410px. This ensures the fields collapse vertically when needed, even on larger screens.

Please feel free to test the update and let me know if you have any questions or further feedback.

Best regards,
Alaa

Hello,

The keyboard navigation support has been updated to work with any menu displayed in the Solo theme or any of its sub-themes.

The previous settings that applied only to the Primary Menu and Primary Side Menu have been removed.
A new Accessibility tab has been added under Global Settings. From this tab, you can view all menus created in the system and choose which ones you’d like to enable keyboard navigation for. After making your selections, click Save to apply the changes.

Please feel free to test the new functionality and let me know if you encounter any issues or have further feedback.

Best regards,
Alaa

Hello,

Thank you for the accessibility suggestion and for the kind words about Solo!

I have updated the system messages exactly as you've described and I pushed the changes to dev version → . The implementation follows WCAG 2.1 Level AA guidelines (Success Criterion 4.1.3 - Status Messages).

Current Implementation

Error and Warning Messages:

• `role="alert"` with `aria-live="assertive"`
• Interrupts screen readers immediately for critical notifications
• Ensures users don't miss important error messages

Status and Info Messages:

• `role="status"` with `aria-live="polite"`
• Waits for a natural pause before announcing
• Doesn't interrupt the user's current reading

Additional Accessibility Features:

• `aria-atomic="true"` ensures complete messages are announced
• `aria-labelledby` connects messages to their type headings
• `aria-relevant="additions text"` for content change tracking
• Close button announcements match message urgency
• Full keyboard accessibility and AJAX compatibility

This ensures:

• Critical messages (errors/warnings) interrupt immediately.
• Informational messages (status/info) wait for polite announcement

All screen readers properly announce messages with appropriate timing based on severity. If you test it with your preferred screen reader and notice any issues or have suggestions for improvement, please let me know.

Best regards,
Alaa

Thanks for the thoughtful request and for mentioning Mayo.

Solo already supports one click scheme switching and full custom scheme authoring with 15 color tokens per region across 16 regions plus the page wrapper, for a total of 255 fields, with live preview and config export and import.

I also have a detailed step-by-step video demonstrating how to create a custom scheme properly and a page for Regions' Color Fields.

I agree the demo site UX can be improved, so I’ve added a category based menu in the page title area to switch between related schemes instantly. I’m also planning to add a top carousel with thumbnails for even faster color scheme previews.

Best wishes,
Alaa

Hi Peter,

I’m glad you’re enjoying the theme and exploring its options, there’s always more to discover! 😊
Thank you for your kind words and for taking the time to share your feedback. I really appreciate it.

Best wishes,
Alaa

Hello Peter,

The menu system in Solo has been revamped and now includes additional options in the theme settings. There is a video tutorial covering all available menu types.

I’m also attaching a screenshot of the Primary Menu settings, where you can switch between “Click” and “Hover” behavior.

Best wishes,
Alaa

Hi Peter,

No worries at all. I’m glad to hear it’s working perfectly! Thanks for the kind words and for using the theme.

Best wishes,
Alaa

Hello,
Every region in the theme includes default padding.
To remove the padding specifically from the header, you can add the following CSS:

#header-inner {
  padding: 0!important;
}

Best wishes,
Alaa

Hello,
The install and Drush files have been updated. Please test again and let me know if you’re still encountering this error.

Best wishes,
Alaa

Hello,

W3.CSS includes many ready-made classes, making it great if you want quick styling out of the box and it already provides what you need. If you prefer to customize the design to match your own style and layout, UtiliKit is a better fit. There are also situations where you can use both W3.CSS for its base utilities and UtiliKit for custom enhancements.

It really depends on your site’s goals and personal preferences.

Best wishes,
Alaa

You are welcome!

Hi, thank you for your kind words and for trying UtiliKit!

Using UtiliKit with the Solo theme:
Yes, it’s fully compatible and even recommended. Solo and UtiliKit are designed to complement each other. UtiliKit provides the core utility class system (layout, spacing, display, color helpers, etc.), while Solo handles theme-level structure and presentation.

You can safely use UtiliKit classes directly within your Solo or Solo sub-theme templates. The framework is flexible, you can use it for simple styles or complex layouts, in a WYSIWYG editor, or inside a Twig template.

Future plans:
On my to-do list are some video tutorials to show different ways UtiliKit can be used in real projects, from simple utility styling to advanced responsive layouts.

About the “Directory does not exist” message:
You see this message because no CSS file has been generated yet.
If you enable Static Mode and have at least one defined CSS class group, UtiliKit will automatically create the CSS file.

I recently changed the message behavior:
It now shows as a warning if you haven’t saved or generated any CSS yet.
It becomes an error only if Drupal cannot create the directory or file due to permissions.
To fix it, simply save your UtiliKit settings or manually create that folder and make sure it’s writable. After that, clear the cache and the message will disappear.

Best wishes,
Alaa

Hi, thanks for the detailed report.
I just did a quick test on my local setup, and everything is working fine.
These behaviors come from your site’s Paragraph/Media configuration and image styles, not from VVJS itself.
VVJS is a Views-based slideshow and doesn’t require “Image Wide” or control captions/WebP output.
Please see the video tutorial for the correct setup.

Best wishes,
Alaa

Hello @giordy,

Thank you for confirming the issue. It appears the problem wasn’t in the code itself but rather a CSS z-index conflict related to the menu position states. I’ve updated the development version.

@giordy and @dpierre, please feel free to download it, test it, and let me know if everything works correctly.

Best wishes,
Alaa

You're very welcome! I’m glad it worked out and that you’re enjoying the theme.

You’re welcome!
If you create any menu and place it inside the sidebar region, it will automatically use the same template as the main sidebar menu. However, if you insert the User Account menu, it will use its own dedicated custom template.

Twig template suggestions follow the standard hierarchy: menu name takes precedence over the region name in determining which template is used.

Best wishes,
Alaa

You are welcome!

Hello,

Thank you for your suggestion and for sharing the screenshots, they’re very helpful.

The Solo theme uses a flexible CSS Grid system, which allows you to create any column ratio with just a single line of CSS. You can easily replicate the 16-68-16 layout used in the Mayo theme by adding the following snippet:

@media (min-width: 62rem) {
  #main-container-inner {
    grid-template-columns: 16fr 68fr 16fr;
  }
}

You can add this under:
Theme Settings → Global Site → Custom Code → CSS Dynamic

If you’re using a sub-theme, you can also place it there for theme-specific customization.
This approach gives you the same flexibility as Mayo, you can define any proportion using fr, %, px, or rem values as needed.

Best wishes,
Alaa

Hello,

Thank you for your detailed feedback and screenshots, that’s very helpful.

The Solo theme uses a rem-based typography system, while the Mayo theme used percent scaling relative to the browser’s default font size. This means that in Solo, font sizes scale according to the site’s root html font size rather than a direct percentage of the browser default.

That difference explains why Solo’s 14 px option appears smaller than the 13 px setting in Mayo, the two systems aren’t equivalent.

You can easily fine-tune both the font size and line height by adding a small CSS override. For example:

#page-wrapper {
  font-size: 0.8125rem; /* roughly equals 13px if root is 16px */
  line-height: 1.8;
}

You can add this under:
Theme Settings → Global Site → Custom Code → CSS Dynamic

If you’re using a sub-theme, you can also include it there for theme-specific customization.
Adjust the values slightly until you achieve the same look you had with the Mayo theme.

Best wishes,
Alaa

Hello,

In the new release, all menus now share a unified z-index structure. Previously, dropdowns in the header menu could be hidden by the main menu.

If you're seeing this issue on the left side, check for any element with a z-index above 2000, it may be affecting visibility. Since your setup seems unique, I recommend slightly increasing the submenu z-index or adjusting it under CSS Dynamic in the theme settings.

You can add this CSS snippet under Theme Settings → Global Site → Custom Code → CSS Dynamic.
If you’re using a sub-theme, you can also add it there for theme-specific customization.

ul.navigation__menubar {
  z-index: 5000 !important;
}
ul.navigation__menubar > li > ul {
  z-index: 6000 !important;
}
ul.navigation__menubar > li > ul > li > ul {
  z-index: 7000 !important;
}
ul.navigation__menubar > li > ul > li > ul > li > ul {
  z-index: 8000 !important;
}

Best wishes,
Alaa

Hello,
Thank you for reporting this, the menu state announcements (opened/closed) now properly translate for screen readers in multilingual sites. Sites must clear cache and re-scan translatable strings after updating.

Best wishes,
Alaa

Hello Trung,
Thank you for reporting the TalkBack issue. I've fixed the skip links to work properly with mobile screen readers.
What was fixed:

• Skip links now correctly move TalkBack's focus to the target region.
• Added explicit screen reader announcements when navigating.
• The virtual cursor stays at the destination instead of returning to the top.
• The fix also works correctly with desktop screen readers (NVDA, JAWS).

Please download dev version, test and let me know if it works for you!

Best wishes,
Alaa

Hello,
I’m currently reviewing some Bootstrap timeline examples, like https://bootstrap-italia.arturu.it/it/admin/appearance/ui/patterns/point...

Just to confirm, do you mean displaying the Views rows directly in a timeline layout (like the one shown in that example).

Hello,

Thank you for the kind words. I’m glad you’re enjoying the Solo theme!

The sidebar icon is an SVG embedded directly within the Twig template. The easiest way to replace it is to hide the existing SVG and attach your own image.
For example, you can use any icon, such as one from Google’s Material Symbols library: https://fonts.google.com/icons?selected=Material+Symbols+Outlined:user_a...@0;wght@400;GRAD@0;opsz@24&icon.query=user&icon.size=24&icon.color=%23e3e3e3

#page-wrapper .sidebar-button-open button.sidebar-hamburger-icon span svg {
  display: none;
}

#page-wrapper .sidebar-button-open button.sidebar-hamburger-icon span {
  background: url("../images/user-menu.svg") center center no-repeat;
  background-size: contain;
  height: 40px;
  width: 100%;
  border: none;
}

As for the overlapping icons, it sounds like both the main navigation toggle and another menu toggle are visible at the same time on smaller screens. This is expected behavior when multiple menus are active. Each hamburger icon represents a separate toggle. However, these menus should be placed in different regions, so they shouldn’t appear too close to each other. I recommend reviewing your layout or region placement to ensure proper spacing between them.

Best wishes,
Alaa

Hello,

The configuration file was added earlier: https://www.drupal.org/project/solo/issues/3534652 💬 No schema for solo.settings. Active .
Please update to the latest release to include this file.

Best regards,
Alaa

Update language

Hello,

Thank you for providing the file. I’ve added it to the Solo theme, and it will be included in the next release.

You’re also welcome to submit the same file to https://localize.drupal.org/translate/languages/vi
so it can become part of Drupal’s official translation system.

Best regards,
Alaa

Hello Steve,

Thank you for the extra debug details. Since I can’t replicate the issue on my side, I updated some JS to pass context in Drupal in case there’s a conflict with BigPipe or other modules. Please feel free to test the dev version. I also fixed the hover issue and pushed that to dev.

Best wishes,
Alaa

Hello,

The dates have been updated and pushed to the dev environment. They’ll be included in the next release, but you’re welcome to use the dev version and test it in the meantime.

Best wishes,
Alaa

Hello,

Thank you for bringing this to my attention and for providing clear steps to reproduce the issue.

The theme is primarily tested and maintained against Drupal core functionalities, so I don’t always account for every contributed module such as Better Exposed Filters. That said, I understand the importance of making sure commonly used modules integrate well, and I’ll review this case to see what can be done.

The theme already includes some custom templates and baseline adjustments for most exposed form elements. I’ll investigate whether additional customization can be added specifically for Better Exposed Filters date pickers to ensure they display correctly.

I appreciate you reporting this, and I’ll keep it in mind for future updates.

Best wishes,
Alaa

This feature was released in 1.0.14.

This update was released in 1.0.14 release.

Hello,

A new feature was added under Overlay Settings > Overlay Position called "Full width". The feature is available now in 1.0.22 release.

Best wishes,
Alaa

Hello,
I’ve updated the Parallax bundle to include a JavaScript option. By default, it will continue to run in CSS legacy mode, but you can now switch it to JavaScript mode if preferred. Additionally, you have the option to disable parallax effects on smaller screens, with five different breakpoints available to choose from.

Please free to download dev version and test it.

Best wishes,
Alaa

Thank you for pointing this out. Unfortunately, background-attachment: fixed isn’t supported on iOS due to performance limitations. I’ll explore an alternative approach, similar to the solution I’ve implemented in https://www.drupal.org/project/vvjp → .

Best wishes,
Alaa

Hello Theo,

Yes, I can add some features like VVJS. I’ll put it on my agenda and to-do list.

Best wishes,
Alaa

Hello Steve,

I noticed some broken HTML in the report, so I’m updating the main click function as a precaution. I haven’t been able to reproduce the issue locally or on the live site, but I’ve adjusted the logic so that each button now gets its own function on click.

Please download the development version and open ../solo/js/menu/Solo-Menu-Remote-Diagnostic-Tool.js. Follow the instructions inside that file to proceed.

Best wishes,
Alaa

Thank you for reporting this issue!
This is a PHP version compatibility issue. The typed class constants syntax (e.g., `public const string DATA_ATTRIBUTE_PREFIX`) was introduced in PHP 8.3, but the module is currently using this syntax without properly declaring the PHP version requirement.

I'll push a fix shortly that removes the type declarations from the constants to maintain compatibility with PHP 8.1+, which is the minimum requirement for Drupal 10.3.

Best wishes,
Alaa

Hello,
VVJA isn’t compatible with Views grouping due to its design.
Flat Structure: VVJA relies on

to split fields, while Views grouping requires a recursive hierarchy.
Nested Accordion Issue: Grouping would create multiple accordion levels, needing a completely different JS system for state, events, and animations.

Because of this, VVJA will stay focused on delivering flat accordions really well.

Best wishes,
Alaa

Thanks for the detailed steps! Just to clarify: VVJA currently doesn’t support the Views “Group field” option. On the project page → I included a note on the home page that grouping isn’t available with VVJA.

That’s why when you try to group by your related Basic Page title, nothing happens, it’s a limitation of how VVJA handles the accordion structure.

Best wishes,
Alaa

Thanks for reporting this! From your description, it sounds like the dropdown works sometimes but not always when using the Solo theme, while it works fine in Tara.

On the Solo demo site, I haven’t run into this issue, for example, the “Bundle Demonstrations” menu with a parent works consistently. This makes me think the problem may be related to a conflict specific to your setup rather than the theme itself.

Here are a few things you can check to help narrow it down:

• Does the issue happen for both logged-in users (like admin) and anonymous visitors?
• Does it occur on all pages or only certain ones?
• Open your browser’s developer console and check for any JavaScript errors when the dropdown fails.
• If you’re using other modules that affect menus or JavaScript, try disabling them temporarily to see if there’s a conflict.

If you can share a live URL where the issue is happening, I’d be happy to take a look and help debug further.

Best wishes,
Alaa

Hello,

The best way to accomplish this is by adding a field to any of these bundles. The following paragraph templates were updated (image-wide, image, image-narrow, image-grid-section, hero, card-image-section, card-text-section, and simple) to use {{ content|without(...) }}. This ensures custom fields are displayed automatically, without requiring users to override or modify Twig templates in their theme, making the module easier to use, flexible, and more user-friendly.

Please download the dev version. You can now add fields (such as First Name and Last Name) to any of these bundles. For example, the screenshot shows this applied to the Image Grid Section template.

Best wishes,
Alaa

Nesting a view block inside another view block

1. Install module: Download and enable Views Field View — https://www.drupal.org/project/views_field_view → .
2. Content & display: Use the Article content type and the Teaser view mode. In Manage display (Teaser), add a Field Group configured as Vertical tabs or Horizontal tabs, and place your fields inside those tabs.

Create the Views

A. Inner view

• Create a Block display that renders Article in Teaser mode (so the Field Group tabs are present).

B. Outer view (VVJT tabs)

• Create a view that uses the VVJT Tabs format.
• Use Title as the tab label.
• Add a second field using View: View (from Views Field View) and select the Inner view’s Block display.
• This embeds the Inner view under each VVJT tab.

Place & Test

• Place the Outer view block on a page and test.
• You should see VVJT tabs on the outside, and the Field Group tabs inside each tab’s content.

Notes / Demo

• In my demo, I’ve nested a view block inside another view block. The inner block shows the Article teaser with a Field Group set to Vertical tabs. Both VVJT tabs (outer) and Field Group tabs (inner) work correctly. Here is the demo bottom of this page https://unitedstarsofamerica.com/node/87

If your setup differs

• Please reproduce on a fresh Drupal install using the default Article content type.
• Export the created views and share the exports. That way I can import them into a clean site and run the exact test you’re using.

Best wishes,
Alaa

Thank you @anirudhsingh19
@vortexcentrum the new style is merged to dev and it will be in the next release.
Best wishes,
Alaa

flashwebcenter → made their first commit to this issue’s fork.

Thank you for bringing this up. However, this debug line was commented out in the dev version two days ago and will be included in the next release.

Best wishes,
Alaa

Hello,

@fkelly12054 thanks for the detailed testing. I’ve added two working examples on Simplytest that you can visit to see VVJS in action.
This setup can get complex; if it feels heavy, I recommend grabbing some one-on-one help (Drupal Slack/support channels) so you can get guided, hands-on troubleshooting while you experiment.

@opstao glad you tracked it down!

This demo may only be temporary, please check it soon.
https://master-4th1wcocxbnaaysibtmhqd2gjel9bh1u.tugboatqa.com/
username: admin
pass: admin

Best wishes,
Alaa

https://www.drupal.org/docs/extending-drupal/themes/contributed-themes/s... →
Done, thank you!

Add schema file

Hello,

I understand the idea, and it’s technically possible to make menu settings apply to any menu in any region. However, I don’t recommend adding this to a contrib theme because it greatly increases the risk of bugs.

When you allow a component to work in any arbitrary placement, you lose control over the surrounding markup, CSS, and JavaScript context. That means it’s impossible to guarantee that all features will work smoothly in every scenario. But in any private work, it’s fine to do because you’re dealing with one known environment, where you can fully control and test the outcome.

In a contrib theme, stability and predictability are critical, opening the placement too much can cause unpredictable behavior and break existing sites.

That’s why, in Solo, all custom features are tied to specific regions. This ensures they function exactly as intended, with the HTML, CSS, and JS environment they were built for.

Solo ships with four dedicated Twig menu templates that are designed for different regions:

• menu--primary-sidebar-menu-template-click.html.twig
• menu--primary-sidebar-menu-template-hover.html.twig
• menu--responsive-menu-template-click.html.twig
• menu--responsive-menu-template-hover.html.twig

If you need similar behavior for a menu in a different region, you can simply copy one of these templates to your sub-theme and rename it to match your target region or menu name. This approach keeps the theme stable while still allowing customization.

Best wishes,
Alaa

Hello,

Yes, it’s recommended, but if you don’t do it, your sub-theme will still work.

To update it:
Copy config/schema/solo_subtheme.schema.yml to your sub-theme’s config/schema/subtheme/ directory and rename the file to:

your_new_subtheme_machine_name.schema.yml
Inside the file, change:

solo_subtheme.settings:
  type: mapping
  label: 'Solo sub-theme settings'
  mapping:

to:

your_new_subtheme_machine_name.settings:
  type: mapping
  label: 'Solo sub-theme settings'
  mapping:

Best wishes,
Alaa

Hello,

Thank you for reviewing this and bringing it to my attention. I’ve updated the padding for all first-level menus to be applied globally across all menu types. Please use the dev version for this updated.

Best wishes,
Alaa

Hello,

Thank you for bringing this to my attention. I’ve updated the theme and released a new version. Please update to the latest version 1.0.25.

Best wishes,
Alaa

You are welcome!

Glad it’s working now! Cache delays can definitely be sneaky sometimes.

Hello,

The menu system in the theme has been updated. Please test it on the dev branch → .
I’ve also applied the keyboard navigation script to the demo site feel free to try it out.

Best wishes,
Alaa

Hello,

All menu templates have been updated to handle only span elements inside li.
Please feel free to use the dev branch and test the changes.

If you have used any of the Solo menu templates in a project, you can update your template with the new version.

Best wishes,
Alaa

Hello,

Unfortunately, I can’t determine much just from the image. If you can share a URL, I’ll be able to provide more specific help.

In general, for the slideshow to function correctly, make sure it's using the correct Twig template as shown in the screenshot I shared. Also, check the browser’s developer console for any JavaScript errors that might be preventing it from working properly.

If you've already debugged that and it's still not working, try disabling any custom or contrib modules that could be interfering. It can also help to test the slideshow while logged out (as an anonymous user) to rule out permissions or caching issues.

The module includes an example View (vvjs_example) that works with the default Article content type. If you don't have that content type, you can edit the View and switch it to a different one. If the example doesn’t work after adjusting it, then something else on the site is likely causing the problem.

Let me know if you can provide a URL, that will help me assist you more effectively.

Best wishes,
Alaa

Hello,

To confirm if the issue is theme-related, try switching to the Olivero theme (included with Drupal). If the slideshow works there, it means the current theme is interfering with the VVJS templates.

You do not need to copy the entire theme. If you're using a custom theme in the themes/custom folder, you can place the two template files directly there and rename them according to your view.

If your theme is in themes/contrib, then it's best to create a sub-theme and place the renamed templates inside it.

Theming Views: https://drupalize.me/tutorial/overview-theming-views
How to Create Sub-Theme: https://www.drupal.org/docs/extending-drupal/themes/contributed-themes/s... →

Best,
Alaa

Thank you so much! Your words mean a lot to me and I will have https://www.drupal.org/project/vvja/issues/3538771 ✨ Timeline Active on my to do list.

Best wishes,
Alaa

Thank you for the suggestion!
I appreciate you taking the time to share this idea. A timeline-style view integration does sound like a valuable addition to the VVJ* module family especially considering the limited options currently available in Drupal for accessible and flexible timeline visualizations.

I'll take a closer look at potential implementation options that could complement the existing accordion structure or it will have its own module.

Thanks again, and feel free to share any specific or examples.

Best wishes,
Alaa

Hello,

You can enable the twig debug through the Drupal UI

Go to: https://your-site.com/admin/config/development/settings
Under Twig Development Mode, check the following boxes:
☑️ Twig debug mode
☑️ Disable Twig cache
☑️ Do not cache markup
Click Save configuration and clear caches.
Then open your site in a browser → Right-click → "View Page Source" → Search for

.
You'll see detailed comments showing:

Important Note for DXPR and Layout Builder Themes
The vvjs module provides its own templates to ensure correct rendering of the slideshow.

However, some themes like DXPR may override or suppress default Views template suggestions, particularly when using their own layout builder or dynamic block region system.

If your theme still overrides the rendering or you want to customize the slideshow:
Copy these two files from the module:

modules/contrib/vvjs/templates/vvjs-internal.html.twig
modules/contrib/vvjs/templates/vvjs-fields-internal.html.twig

Rename them to match your view name using standard Views suggestions:

views-view--yourviewname.html.twig
views-view-fields--yourviewname.html.twig

Place them in your theme at: themes/custom/YOUR_THEME/templates/views/
then clear caches.

BTW, the link provided as demo site is not working, and generates a Page Not Found. m not sure why it's not working for you. I just clicked the link and it's working on my end.
You can also access the demo by visiting https://unitedstarsofamerica.com and navigating to the Views Vanilla section; the demo link is available there.

Best wishes,
Alaa

Hello,

Thank you for bringing this to my attention. I’m currently investigating the issue you described regarding keyboard navigation for the second-level menu. I’ll make sure to resolve it and follow up with an update. I really appreciate your kind words and support for the theme it means a lot!

Best wishes,
Alaa

Hello,

Thanks for the suggestion! I’ll take a look and if the crossfade transition can be added without breaking existing functionality for current users, I’ll definitely consider implementing it in a future update.

This kind of enhancement could be a nice addition to the module’s flexibility.

Best wishes,
Alaa

Hello,

The module supports two display modes:
Hero Slide Mode – This requires a specific field type, and the image field must be limited to one image only.
View Mode Integration – This allows you to use any defined view mode.

Please note: the module includes its own Twig template. If any other module or theme overrides this default template, the slideshow will not function correctly.

To verify which template is being used, follow these steps:

Enable Twig debugging.
Inspect the page source and look for the template suggestions in the HTML comments.
Ensure no other template is overriding the one provided by this module.

<!-- BEGIN OUTPUT from 'modules/contrib/vvjs/templates/views-view-vvjs.html.twig' -->
<!-- BEGIN OUTPUT from 'modules/contrib/vvjs/templates/views-view-vvjs-fields.html.twig' -->

You can see examples of both display types on the demo site:
https://unitedstarsofamerica.com/vanilla-views/views-vanilla-javascript-...

By default, you should see a working version similar to the examples shown there.

Best regards,
Alaa

Good morning,

Thank you for your kind words, I truly appreciate your support and I'm glad to hear the theme has been a reliable foundation for your projects.

Regarding your new requirement for government websites: yes, you can absolutely implement the top "leaderboard-style" layout using the existing highlighted region, without creating a new region, and still meet WCAG 2.1 accessibility requirements.

Suggested Approach Using the highlighted Region

1. Create two separate menus in Drupal.
2. Place each menu block into the Highlighted region.
3. Apply the following CSS to split them visually:

#highlighted {
  --r-bg: #ccc;
}

#highlighted-inner {
  display: flex;
  justify-content: space-between;
  gap: 1rem;
}

#highlighted-inner nav {
  display: flex;
  width: auto;
}

#highlighted-inner nav:first-child ul {
  justify-content: start;
}

#highlighted-inner nav:nth-child(2) ul {
  justify-content: end;
}

#highlighted-inner ul li a {
  font-size: 14px;
  padding: 2px 12px;
}

Best wishes,
Alaa

Hello,

The Solo theme includes custom Twig templates for sidebar regions. However, the menu_block module overrides Drupal's default theme suggestions, which is why your region-specific template (e.g., menu--sidebar-second.html.twig) wasn't being used as expected.

To address this, I’ve updated the theme suggestion alter hook to work around the module’s behavior. I’ve tested it locally and confirmed that the custom sidebar template is now correctly applied.

Please feel free to download the latest dev version → , test it on your setup, and let me know if everything works as expected.

Best wishes,
Alaa

Hello,
Under the Page Settings section, you'll find a field for CSS classes. You can apply custom classes there, just like I’ve done in the screenshot.

Best wishes,
Alaa

Hello,

The 1.0.x-dev version on the project page is dated July 21, but Composer only installs the July 16 commit. This is usually due to Composer metadata caching on Drupal.org. Try running:

composer clear-cache
composer update drupal/solo --with-dependencies

If you still get the older version, it’s likely a caching delay on the Drupal.org Composer endpoint and should resolve soon.

Best wishes,
Alaa

Hello,

No, the Cloudflare Purge module does not automatically purge content when nodes are updated or files are deleted.

Best wishes,
Alaa

You are welcome!

In the Solo theme, the default node add/edit form is rendered using: solo/templates/admin/node-edit-form.html.twig

This template is applied for all content types when creating or editing nodes. If you'd like to customize the layout of the form globally (for all content types), you can:

1. Copy the template to your sub-theme: themes/custom/your_subtheme/templates/admin/node-edit-form.html.twig
2. Modify the HTML structure or classes as needed.

Creating a Per-Content-Type Node Edit Template

If you need a custom layout or field arrangement for specific content types, such as Article, follow these steps:

Step 1: Download the Latest Dev Version of Solo

Ensure you're working with the most recent version of Solo, which includes support for: node_edit_form theme overrides.

Step 2: Copy the Default Template

Copy: solo/templates/admin/node-edit-form.html.twig to your sub-theme and rename it using the correct naming convention: node-edit-form--article.html.twig This template will be used only when editing or creating Article nodes.

Step 3: Print Fields Individually

Inside your node-edit-form--article.html.twig, you can print specific fields manually.

Here’s a basic example:

{{ form.title }}
{{ form.body }}

{# Exclude the manually rendered fields from the remaining form output #}
{{ form|without('title', 'body', 'advanced', 'footer', 'actions') }}

{{ form.advanced }}
{{ form.footer }}
{{ form.actions }}

Important: Any field you render explicitly (like form.title or form.body) must be excluded from the form|without() list. This avoids rendering them twice.

Step 4: Discover Available Fields

To see all available fields in your form, use a development dump:<pre>{{ dump(form) }}</pre>

This will output the form structure in the HTML source and help you determine field names to render.

Example Template Structure

{{ attach_library('solo/solo-node-edit-form') }}

<div class="layout-node-form solo-clear">
  <div class="layout-region layout-region-node-main solo-padding">
    {{ form.title }}
    {{ form.body }}
    {{ form|without('title', 'body', 'advanced', 'footer', 'actions') }}
  </div>
  <div class="layout-region layout-region-node-secondary solo-padding">
    {{ form.advanced }}
  </div>
  <div class="layout-region layout-region-node-footer solo-padding">
    {{ form.footer }}
    {{ form.actions }}
  </div>
</div>

This gives you full control over the layout, grouping, and appearance of the node edit form per content type in your Solo-based sub-theme.

Best wishes,
Alaa

Hello,

Thank you for testing and confirming the functionality on Drupal 10.5.1. I'm glad to hear everything is working as expected.

Please feel free to share any feedback or suggestions as you continue testing. I appreciate your support!

Best regards,
Alaa

Hello,

The new feature has been added to all grouped regions: Top, Main, Bottom, and Footer. Please download the latest development version → and test the functionality.

Feature Overview:

1. Within the settings for any grouped region (e.g., Main), you can now define the global column layout using the two-column or three-column dropdowns.
2. A new checkbox has been added below these dropdowns to enable per-content-type layout settings.
3. When this option is activated, a collapsible section will appear for each content type in the system.
4. You may expand any section and define custom layout settings for that content type.
5. You are not required to configure every content type, those left unchanged will inherit the global settings for the selected region.

Important Behavior:
If you later disable the feature and click "Save," all content types will automatically revert to using the global settings defined for that region.

Please let me know if you encounter any issues or have feedback.

Best regards,
Alaa

Hello,

If you're using the Solo theme as your admin theme, you can adjust the layout to stack the form sections vertically—this moves the right-hand column below the main content area.

To achieve this, apply the following CSS:

.path-node .layout-node-form {
    flex-direction: column;
  }

  .path-node .layout-node-form > div {
    width: 100%;
  }

Note: Personally, I use the Gin theme → , which replaces Claro. Gin includes a built-in option to expand the "stage" area to full width, providing a better editing experience without custom CSS.

Best wishes,
Alaa