🇺🇸United States @flashwebcenter

Hello,

You are not bothering me at all, thank you for your detailed testing.

Yes, the Fixed Search Block in Solo is specifically designed to display the search form. Removing the search form and adding other content will not break the region itself, but it may disrupt the layout, even though the content and close button will still appear.

Changing the order of the primary menu above the header or adding content to the header does not affect how the Fixed Search Block displays.

Please let me know anytime if you need further clarification or assistance.

Best wishes,
Alaa

Hello Eric,

Thank you for letting me know, and no worries at all.

These schema warnings are harmless. They happen because your custom content types add keys that Drupal’s schema system can’t map dynamically, but they will not break your site.

According to Drupal, mappings require all keys to be predefined, while sequences handle unknown keys. Since changing to a sequence would break other users’ configs, I’m keeping the safer mapping approach.

You can safely ignore these warnings. Thank you again for your detailed note, and please let me know if you need anything else.

Best wishes,
Alaa

Hello,

Thank you for letting me know. I’ve added the solo.schema.yml file to the dev version.

Please check on your end to see if you are still seeing the schema warning. If the warning persists, let me know the exact message so I can investigate and address it promptly.

Best regards,
Alaa

Hello,

The Fixed Search Block region in the Solo theme is specifically built to display the search form bar. I have tested it thoroughly on a fresh installation and on the demo site, and it is working as expected without any errors.

Best wishes,
Alaa

Hello,

I have tested this scenario on both a fresh install and the demo site and did not encounter any errors.

The issue appears to be that the solo-utils.js file is missing. Please ensure that this file is present in your installation. If you have a URL available, I would be happy to review it for you.

Best wishes,
Alaa

Thank you so much for your kind words! I truly appreciate it, and I’m glad you’re enjoying the theme. Let me know anytime if you need further assistance or have ideas for improvement.

Hello,

Yes, it is correct. The image is nested inside a clickable anchor that was previously using float: left. Disabling the float will fix it.

#page-wrapper .text-align-center img,
#page-wrapper .text-align-center video,
#page-wrapper .text-align-center object,
#page-wrapper .text-align-center embed {
  margin-left: auto;
  margin-right: auto;
  float: none;
}

Best wishes,
Alaa

Hello,

Thank you for bringing this to my attention.

I have updated the theme so that img, video, object, and embed elements now correctly inherit alignment from their wrapper, ensuring they center as expected when using .text-align-center.

Solution:
You can download the latest dev version, which includes this fix.
If you prefer to patch it manually, add the following CSS under Theme Settings > Global Site > CSS Injector:

#page-wrapper .text-align-center img,
#page-wrapper .text-align-center video,
#page-wrapper .text-align-center object,
#page-wrapper .text-align-center embed {
  margin-left: auto;
  margin-right: auto;
}

Best wishes,
Alaa

Hello,

To display Webform radio buttons and checkboxes inline in your Solo theme, you have two targeting options:

1. Target All Webforms Site-Wide:

#page-wrapper .webform-submission-form .form-wrapper.solo-clear::after,
#page-wrapper .webform-submission-form .form-wrapper.solo-clear::before,
#page-wrapper .webform-submission-form .form-wrapper .solo-clear::after,
#page-wrapper .webform-submission-form .form-wrapper .solo-clear::before {
  content: none;
  display: none;
  clear: none;
}

#page-wrapper .webform-submission-form .form-radios,
#page-wrapper .webform-submission-form .form-checkboxes {
  display: inline-flex;
  gap: 1rem;
  flex-wrap: wrap;
  align-items: center;
}

#page-wrapper .webform-submission-form .form-radios .form-type-radio,
#page-wrapper .webform-submission-form .form-checkboxes .form-type-checkbox {
  margin: 0;
  width: auto;
}

2. Target a Single Webform:
If you only want this inline style on a specific Webform, use its machine name:

#page-wrapper .webform-submission-your-form-name-form .form-wrapper.solo-clear::after,
#page-wrapper .webform-submission-your-form-name-form .form-wrapper.solo-clear::before,
#page-wrapper .webform-submission-your-form-name-form .form-wrapper .solo-clear::after,
#page-wrapper .webform-submission-your-form-name-form .form-wrapper .solo-clear::before {
  content: none;
  display: none;
  clear: none;
}

#page-wrapper .webform-submission-your-form-name-form .form-radios,
#page-wrapper .webform-submission-your-form-name-form .form-checkboxes {
  display: inline-flex;
  gap: 1rem;
  flex-wrap: wrap;
  align-items: center;
}

#page-wrapper .webform-submission-your-form-name-form .form-radios .form-type-radio,
#page-wrapper .webform-submission-your-form-name-form .form-checkboxes .form-type-checkbox {
  margin: 0;
  width: auto;
}

Replace (your-form-name) with the machine name of your Webform, found in the Webform’s URL or settings.

Note:
A new CSS class inline-radio-checkbox has been created for use across all forms site-wide. This class displays checkboxes and radio buttons inline rather than stacked. It was pushed to dev version.

You can apply this class under Page Settings > Page Wrapper section in the CSS Classes field to all forms site-wide.

Best wishes,
Alaa

You’re welcome! Happy to assist anytime.

Hello,

Thank you for bringing this to my attention. Solo includes its own menu system, which by default applies z-index: 1 to all nav ul elements. Since the breadcrumb is structured as nav ul but does not function as an interactive menu, it does not require these z-index layers. I have updated the CSS so that these styles now apply only to interactive menus, excluding breadcrumbs and other non-interactive nav ul structures.

You can download the latest release → to receive this update.

Best wishes,
Alaa

Thank you @ fkelly12054@gmail.com, and you are welcome @giordy.

Hi,

Thank you for sharing your findings, and I’m glad you resolved the issue.

I did test this as well: I removed the block from the Fixed Search Block region and also removed all blocks from all regions except the menu and content to test thoroughly. It is working fine on my end with these changes.

Best wishes,
Alaa

Hello,

Thank you for sharing these detailed findings.

I have tested Solo 1.0.21 locally and am not encountering these issues, which suggests the cause may be site-specific. Please try the following troubleshooting steps to help isolate the problem:

• Clear caches and rebuild CSS/JS aggregation (drush cr).
• Check logs under Admin > Reports > Recent log messages (/admin/reports/dblog) for any errors when saving theme settings.
• Temporarily disable contrib modules that may alter admin forms or configuration.
• Switch to the default theme (Olivero), then re-enable Solo and test again.
• Verify any custom CSS overrides in your sub-theme or custom module that could affect the primary menu’s alignment.
• Ensure there are no duplicate copies of older Solo versions present in your themes directory.
• I am also attaching a video demonstrating → my test with Solo 1.0.21 for your reference.

Please let me know what you find after these steps, and I will continue to assist you in resolving this.

Best regards,
Alaa

Hello,

*For point one, this is good.

*For point two, the screenshot shows a request for: https://www.gmpe.it/libraries/dom_purify/dist/purify.min.js
while the site itself is requesting: https://www.gmpe.it/libraries/dompurify/dist/purify.min.js
I’m not sure which page the screenshot was taken from, but please ensure this file is correctly loaded wherever it is needed.

*For point three, I’m also not certain which page this refers to, but it appears that: https://www.gmpe.it/themes/custom/gmpe/css/ckeditor.css does not exist. This missing file may be causing the missing icon and the related error.

Please check that this CSS file is present or remove the reference if it’s not needed, as it may resolve the CKEditor issue.

Best wishes,
Alaa

Hello,

It sounds like there’s been a mix-up between VVJS Slideshow (Views-based) and Paragraphs-based slideshow workflows, so let me clarify to keep your setup clean and scalable.

VVJS Slideshow vs. Paragraph Slideshow
VVJS Slideshow is designed to display slides using a Views display directly, not using Paragraphs. If you are creating a “gshow” content type and adding images there, you will typically create a View listing those images filtered by your content type or tags, then attach the VVJS Slideshow display to render those images as slides.

Paragraph-based slideshows, in contrast, require a Paragraph type with images embedded in each Paragraph item, which is a separate module and workflow entirely.

Both slideshows use a single JavaScript file, which is included with the module.

Best wishes
Alaa

Hello,

The issue you are encountering is due to using the module with a content type that has an image field allowing multiple images. This module is not designed to handle multiple images within a single content item. Instead, each piece of content should contain only one image.

If your content type’s image field is set to accept multiple images, this will cause errors and break the slideshow functionality. This is the same issue you encountered previously. https://www.drupal.org/project/vvjs/issues/3480190 🐛 Bugs with vvjs slideshow Active

To resolve this, please adjust your workflow so that each content item includes just one image, ensuring the module functions correctly.

Best wishes,
Alaa

Hello,

*Request for font ‘Source Sans Pro’ blocked at visibility level 2 (requires 3):
This occurs because the browser’s tracking protection or strict privacy settings are blocking the web font from loading when requested from a third-party domain. This is not a Drupal or CKEditor issue but a browser privacy behavior.
Solution: change it in the theme settings to load it locally.

*https://www.gmpe.it/libraries/dom_purify/dist/purify.min.js blocked due to MIME mismatch:
The file is missing or misconfigured on the server, causing it to return text/html instead of application/javascript, leading to the browser blocking it.
Solution: Ensure purify.min.js is correctly uploaded to: /libraries/dom_purify/dist/purify.min.js

*TypeError: can't access property "pencil", e.icons is undefined:
This is likely caused by an incompatible CKEditor 5 plugin attempting to access e.icons.pencil, which is undefined in the current CKEditor 5 version shipped with Drupal 11.2.
Solution: It is related to one of the ckeditor plugins. If you are using https://www.drupal.org/project/anchor_link → , ensure it is updated to the latest version for CKEditor 5 compatibility.

Best wishes,
Alaa

Hello,

Thank you for your contribution! The patch has been merged, and a new release (2.0.5) has been issued with your improvements.
I appreciate your help in making the module more robust for all users.

Best wishes,
Alaa

Hello,

Version 1.0.21 → has been released and is now available for use.

Best regards,
Alaa

Hello,

Does it calculate the slide gap? Yes, it does.
Does it perform this calculation on page load? Yes.
Does it also recalculate on browser resize? Yes, that’s included as well.

Please download the latest development version to apply this update.

Best wishes,
Alaa

Thank you @casanova347 for confirming

You are welcome!

Hello,

Thanks for the detailed example, that made the issue very clear.

I’ve added a new feature to the dev branch that directly addresses this. It makes the carousel layout more responsive between breakpoints by dynamically adjusting the number of visible items based on available space.

Here’s how it works, using your example:
If you configure 7 items for large screens, and each slide is around 300px wide (plus some spacing), the carousel will check the actual container width (e.g., 2000px) and reduce the number of visible slides if there isn’t enough room, even if the layout hasn't hit a new breakpoint yet.

Important: the configured values (itemsSmall/itemsBig) now act as maximums, not fixed counts. That means the carousel will never exceed that number, but it may show fewer if space is limited.

Just make sure your settings are realistic for the space you're working with. For example, if your wrapper has a max-width: 1000px, don’t set itemsBig = 4 if each slide is 400px wide, there's simply not enough room. The layout logic respects your max values but can’t override physical constraints.

This responsive behavior currently applies to horizontal carousels only. Let me know how it works for you!

Best wishes,
Alaa

Hello,

Using an image style is definitely better than loading the original image, it helps reduce file size and improves performance.

Responsive image styles take it a step further. They let you set different image styles per breakpoint, so the browser loads the right size depending on the screen.

If you're dealing with large images or care about performance (which most of us do), responsive images are the way to go.

So yes, if you're aiming for the best setup, I’d recommend going with responsive image styles.

Best wishes,
Alaa

Hello,

In the Solo theme, clickable images are set to stretch to 100% width by default. To disable this behavior, add the class image-auto to the Custom CSS Classes field under Page Wrapper in your sub-theme or Solo theme settings, as shown in the screenshot.

Best wishes,
Alaa

Thank you for the patch, it is applied to the new release 2.0.4.

Best wishes,
Alaa

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

Hello,

It appears that the issue you're experiencing may be specific to your local environment. I tested the module on fresh installations on my local of both Drupal 10 and Drupal 11, and it is functioning as expected. Additionally, I verified the module on SimplyTest.me for both versions, and everything worked correctly there as well.

https://master-efc9ezddlnrtmerw2xbuun22tq9sewuk.tugboatqa.com/node/1
https://master-70qx0i7z9e27iwdzcxyrw5e4atkuvpov.tugboatqa.com/node/1

If possible, please feel free to share a link to the issue with Twig debug enabled so I can take a closer look.

Best wishes,
Alaa

Hello,

Thank you for reporting this issue. I’ve updated the Font Awesome directory and tested it locally to confirm the fix.

Please feel free to test the latest changes using the dev version.

Best wishes,
Alaa

Hello,

I’ve tested the Accordion feature on Drupal core 10.4.7 with Paragraphs Bundles 1.0.11, and I’m not able to reproduce the issue, everything appears to be working as expected, including the toggle buttons and behavior.

My recommendation is to review any custom theme or other contributed modules that might be affecting visibility or layout. In some cases, CSS from unrelated modules or themes can unintentionally hide or reposition the buttons.

Please feel free to share additional details (e.g., theme in use, relevant HTML output, or browser console errors), and I’d be happy to help further troubleshoot.

Best regards,
Alaa

Hello,

Thank you for reporting this. I can confirm this behavior occurs on a fresh Drupal 11 installation.

The warning has been resolved, and the development version has been updated accordingly.

Best regards,
Alaa

Hello,

I added two new options (Show arrows on the sides (big screen only), Show arrows at the top of the slide (big screen only) ) to "Slide Navigation Arrows". It was added to 1.0.17 release.

Best wishes,
Alaa

Thanks for following up!

In the Solo theme, I’ve followed Drupal’s SMACSS-style CSS organization: https://www.drupal.org/docs/develop/standards/css/css-file-organization →

In solo.libraries.yml, I explicitly added a weight to each CSS file even though Drupal already handles some of that by default. This way, if something goes wrong, I still have a fallback order I can rely on.

Now, regarding sub-themes: to make sure the sub-theme CSS loads after the base theme, I simply gave the sub-theme’s styles a higher weight than those in Solo. That ensures the override order works as expected.

About the issue you linked ( https://www.drupal.org/project/drupal/issues/3070381 🐛 Base theme libraries may be output in reverse order Active ), I noticed no weights were set in the Theme A > B > C chain, which could definitely lead to inconsistent behavior.

In your case, manually setting the weight in the sub-theme should fix it since it forces the sub-theme styles to load last.

As for CSS aggregation: when you're actively updating styles, a few steps help avoid these kinds of issues:

1. Temporarily disable CSS/JS aggregation at /admin/config/development/performance
2. Turn on development mode at /admin/config/development/settings
3. And clear your browser cache. A lot of people don’t do this, and old CSS can linger. Personally, I keep a second tab open in private mode while working, that way I get a clean slate every time I reload.

Best wishes,
Alaa

Thank you for the report.

In Views header/footer, if you add a field using Global: Text area or Global: Unfiltered text, there is an option called "Use replacement tokens from the first row." The default tokens will not work in this case.

The reason the tokens appear empty is because the view header/footer does not have raw access to the first row’s field values when the output is rendered through a custom Twig template, as is the case with this module.

I’ve updated the plugin to explicitly expose these fields for token replacement. I’ve tested this functionality with common fields such as title, body, and image, and the new [vvja:field_name] token format now renders correctly.

I updated the readme and the homepage, also I added description under module settings:

Please feel free to test it on your end and let me know if it works as expected.

Best regards,
Alaa

Hello,
Yes, I fixed the typo and you should update maxilein.libraries.yml.

To control the order in which libraries are loaded, it's recommended to follow the SMACSS (Scalable and Modular Architecture for CSS) methodology. Drupal allows you to organize your CSS files into the following categories, each with its own load order weight:

• Base: Load Order Weight -200
• Layout: Load Order Weight -100
• Component: Load Order Weight 0
• State: Load Order Weight 100
• Theme: Load Order Weight 200

Example:

global-styling:
  css:
    base:
      css/reset.css: {}
    layout:
      css/layout.css: {}
    component:
      css/button.css: {}
    state:
      css/button-hover.css: {}
    theme:
      css/colors.css: {}

When Drupal processes these CSS files, it loads them based on their assigned weights. This ensures that foundational styles are loaded first, followed by layout structures, component-level styling, state changes, and finally visual theme adjustments. The result is a logical, layered approach to styling.

By default, a custom theme will override any assets provided by modules. The CSS files for the Paragraphs bundles are correctly included under the theme layer, and if you apply the weight as shown in the previous code, your sub-theme’s styles should load last. I tested this locally and confirmed that it works as expected.

If this behavior is not occurring on your site, there may be an environmental or configuration issue outside the scope of what I can assist with.

Best wishes,
Alaa

Thank you @mohammad faqeh for testing.

Hello,

Thank you for the detailed explanation.
To enforce the order and ensure the sub-theme styles are loaded last, you can define the CSS in the sub-theme’s maxilein.info.yml file accordingly.

maxilein-global:
  css:
    theme:
      css/maxilein-style.css: { weight: 400 }
  js:
    js/maxilein-script.js: {}

Best wishes,
Alaa

Hello,

Thank you for contributing the patch to the module! I’ve reviewed it and applied it to the codebase, and everything looks fine from my side. However, I’m unable to test it fully as I don’t currently have an account to verify the functionality.

If anyone in the community can test it and confirm that it’s working as expected, I’d be more than happy to approve the patch. Your feedback is greatly appreciated!

Best wishes,
Alaa

Hello,

If you want to show this field conditionally, only at certain times, you could add a dedicated field for administrative use, similar to how Views handles visibility.



Best wishes,
Alaa

Hello,

You can achieve this without using a checkbox. Simply navigate to:
your-site-dot-com/admin/structure/paragraphs_type/two_columns_bundle/display Then hide the title field as shown in the screenshot.

Best wishes,
Alaa

Great! I'm glad to hear everything is working well now.

Best regards,
Alaa

Hello,

To disable sticky behavior for the primary menu, you can add the following CSS either in your sub-theme stylesheet or within the Solo theme settings:

#primary-menu {
  position: static !important;
}

Best wishes,
Alaa

Thank you for your detailed report and for using the Solo theme.

After reviewing your description, I want to clarify that the “Save configuration” functionality is part of Drupal core and is handled by the form system itself. The Solo theme does not override or customize this form submission behavior in any way.

Based on what you’ve shared, the issue is not caused by the Solo theme. The settings form and save button are provided by Drupal, and the theme only provides additional fields or defaults (e.g., color settings, layout options) via the theme hook.

A few things you might try next:

1. Confirm that the Solo theme settings form has not been altered in a custom module or by the sub-theme.
2. Temporarily disable your sub-theme and try saving with Solo as the default theme to rule out custom overrides.
3. Check if the Solo config is being blocked from saving by a contributed module (like Config Ignore or similar).
4. Enable error reporting or check logs again after saving, to see if PHP or form validation errors are being hidden silently.

Again, thank you for bringing this up. At this time, there are no known issues in Solo version 1.0.19 related to saving theme settings. Please feel free to share any further findings.

Best wishes,
Alaa

Hello,

Thank you for bringing this to my attention. I’ve adjusted the Solo theme’s five main breakpoints (36, 48, 62, 75, and 87.5rem) to use precise min-width and max-width pairs, offset by 0.00125rem/0.02px. This ensures that only one media query applies at each breakpoint, eliminating overlap and preventing layout conflicts at exact widths.

The updates have been pushed to the development version → and are now live on the demo site.

Best wishes,
Alaa

You are welcome!

Hello,

The background issue has been addressed and merged. Previously, the background variable was applied to all ul and ol elements except when they were rendered within a field or a Views field. In the example under the "Operations" group (see: https://www.drupal.org/files/issues/2025-03-10/TransparentDropdown.png → ), I discovered that the element in question uses the .views-field class, which was excluding it from receiving the background variable.

To ensure consistency across the system, I’ve added the background variable directly to the dropbutton-wrapper.html.twig template. This way, any dropdown rendered by Drupal regardless of where it appears will consistently apply the background color variable.

.page-wrapper .dropbutton-widget {
  background-color: var(--r-bg);
}

The update has been pushed to the dev branch, feel free to use it. If you prefer not to use the dev version, you can apply the code snippet above in your theme settings as a temporary workaround until the next release.

Best wisehs,
Alaa

You are welcome!

Hello,

To achieve this without writing any code:

1. Navigate to Global Site > Theme settings, and set the layout width to 100%.
2. Download and install the Paragraphs Bundles → module.
3. You can add a paragraph field to any content type and begin using any of the available bundles.
4. Each bundle includes a configurable maximum width, ranging from 300px to 1000px.
5. Alternatively, if you prefer not to modify an existing content type, install the Paragraph Bundle Content bundle.
6. This provides a dedicated content type designed specifically for the Solo theme, with built-in width settings.

If you'd rather apply this using CSS:
1- Override the site's width variable by targeting the #page-wrapper element:

#page-wrapper {
  --solo-width: 100%;
}

2- Control the maximum width of full node content using the following rule:

#page-wrapper .node.node--view-mode-full .node__content {
  max-width: 1080px;
  margin: 0 auto;
}

This ensures the content is centered and constrained within a specified width, while the overall layout still respects the 100% setting.

Best wishes,
Alaa

Hello,

Thank you for providing the link /admin/structure/block/demo/solo.

Please note that the block demo page (/admin/structure/block/demo/solo) is not a normal page request. It does not render the theme’s page in the usual way. Instead, it uses a special internal controller that manually builds a fake page render array. It does not trigger real routes, such as the front page, content pages, or other standard site contexts.

As a result, contextual conditions like is_front and site_regions_top_disable are missing or undefined when Drupal renders the block demo page. For example:

  {% if site_regions_top_disable == 0 %}
  {% include '@solo/partials/_top-regions.html.twig' %}
  {% endif %}
  {% if site_regions_top_disable == 1 and is_front %}
  {% include '@solo/partials/_top-regions.html.twig' %}
  {% endif %}
  {% if site_regions_top_disable == 2 and not is_front %}
  {% include '@solo/partials/_top-regions.html.twig' %}
  {% endif %}

Because Drupal fakes the page to display only block regions (and not full site logic), theme settings, partial templates, and any dynamic Twig depending on context will not behave normally.

Best wishes,
Alaa

Hello,

Solo automatically adds the class img--is-clickable to certain clickable images to allow them to stretch properly.
All other images are not stretched to 100%, they remain at their original size by default.

If an image is placed inside an anchor (a tag), it may receive the img--is-clickable class.
To disable this behavior, go to the theme settings and apply the image-auto class to the page wrapper, as shown in the attached screenshot.

Best wishes,
Alaa

Hello,

The three grouped regions Top, Bottom, and Footer, all behave the same way.
When you place a block inside any of these regions, you will have three display options available under the theme settings for each grouped region:

Display the block on all pages
Display the block on the homepage only
Display the block on all pages except the homepage

Regarding your mention of "demo pages," I want to clarify that the theme does not include any demo pages.
If other modules or themes create pages with their own blocks, they may not use the Solo page templates.
To ensure Solo’s settings are applied correctly, you must use the templates provided and shipped with the Solo theme.

Best wishes,
Alaa

Thank you for the kind words, I really appreciate it!

I just want to clarify a couple of things about how Drupal works, especially the difference between modules and themes.

“isn't this the functionality of doing a database update? I did the update but didn’t see any functions implemented.”

Actually, database updates apply only to modules, not themes. Themes don't trigger hook updates or database updates the same way modules do.

“there were other settings that changed after the update, but they weren’t clearly visible.”

Yes, and that’s expected. Most of the changes happen in the code, not in the theme’s saved configuration. That’s why you might not see a visible difference right away.

In the most recent update, I added logic to preserve all user-defined theme settings. So, you didn’t need to reselect your settings, just visiting the theme settings page and clicking "Save" would apply the new logic while keeping your preferences.

  if (!isset($menu_alignment) || $menu_alignment === '') {
    if (theme_get_setting('primary_menu_align_center')) {
      $menu_alignment = 'center';
    }
    elseif (theme_get_setting('primary_menu_justify_content')) {
      $menu_alignment = 'justify';
    }
    else {
      // Default to left-aligned.
      $menu_alignment = 'none';
    }
  }

If you're ever unsure what changed, you can export the site configuration and check the solo.settings.yml file. That makes it really easy to see any updates between versions.

Best wishes,
Alaa

Hello,
The menu options were previously split into separate fields, which resulted in a cluttered layout. I’ve restructured them into a single select list for better usability.

To apply the new configuration:

Go to the Solo theme or your sub-theme.
Re-select your previous menu setting from the updated list.
Click Save to confirm the changes.

Best wishes,
Alaa

Hello,

The fourth-level menu has been thoroughly tested and confirmed to support the following:

1. Accessibility best practices, including ARIA roles and full keyboard navigation
2. Responsive behavior across mobile and desktop devices
3. Automatic submenu positioning using smart flip logic
4. Full RTL (Right-to-Left) language support
5. Integration with all core menu features available in the theme settings

Based on the screenshot you shared, it appears that you're still viewing an older version of the theme. Please clear both Drupal caches and your browser cache to ensure you're seeing the latest updates.

For your reference, I’ve attached a screenshot of the fourth-level submenu in action. This feature is now live on the demo site under:

Solo's Feature → Typography and Fonts → Google Fonts → Heading Fonts

https://unitedstarsofamerica.com/

Best wishes,
Alaa

Hello,

i have uncheck 2 options optimisation "Aggregate" in option Drupal, seem resolve problem of the first bad chargement

If this resolves the issue, it likely means the problem was caused by cached data. You'll need to clear both your Drupal caches and your browser cache to ensure all updates are properly reflected.

Best wishes,
Alaa

Hello,

Thank you for providing detailed information about your setup. Based on your description, it appears that the issue lies in the CSS selector used within the CSS Injector.

#page-wrapper {
  table tr:deactivated td {
    background-color: red;
  }
}

The selector tr:deactivated is not a valid CSS pseudo-class, which is why the background color isn't being applied.

To apply a red background to table rows with the class deactivated, you should adjust your CSS as follows:

#page-wrapper table tr.deactivated {
    background-color: red;
}

Best wishes,
Alaa

Hello,

If your goal is to change the node title from h3 to h2, and you've already edited the node.html.twig template, then yes this is typically the recommended and cleanest approach in Drupal.

Keep in mind that node.html.twig affects all content types. If you only want to apply this change to a specific content type, you should override the template using the format: node--[content-type].html.twig.

All modifications should be done within your sub-theme to ensure maintainability and upgrade safety.
https://www.drupal.org/docs/develop/theming-drupal/creating-sub-themes →
https://www.drupal.org/docs/develop/theming-drupal/twig-in-drupal/twig-t... →

Best wishes,
Alaa

Hello,

Based on valuable feedback from the Drupal community, Solo officially will supports fourth-level navigation menus in the next release.

Why This Matters
Many users requested the ability to create deeper, more complex menu structures — especially for large sites with multi-level content hierarchies, product catalogs, or mega menu requirements.

Previously, Solo focused on a clean, accessible 3-level menu structure, optimized for performance and simplicity. However, after carefully evaluating real-world use cases and listening to user feedback, fourth-level menu support has been added — with full consideration for:

• Accessibility best practices (ARIA roles, keyboard navigation)
• Responsive behavior on mobile and desktop
• Automatic submenu positioning (smart flip logic)
• Clean, maintainable CSS and JS handling
• RTL (Right-to-Left) language support

Best wishes,
Alaa

Hello,

Based on valuable feedback from the Drupal community, Solo officially will supports fourth-level navigation menus in the next release.

Why This Matters
Many users requested the ability to create deeper, more complex menu structures — especially for large sites with multi-level content hierarchies, product catalogs, or mega menu requirements.

Previously, Solo focused on a clean, accessible 3-level menu structure, optimized for performance and simplicity. However, after carefully evaluating real-world use cases and listening to user feedback, fourth-level menu support has been added — with full consideration for:

• Accessibility best practices (ARIA roles, keyboard navigation)
• Responsive behavior on mobile and desktop
• Automatic submenu positioning (smart flip logic)
• Clean, maintainable CSS and JS handling
• RTL (Right-to-Left) language support

Best wishes,
Alaa

Hello,

Based on valuable feedback from the Drupal community, Solo officially will supports fourth-level navigation menus in the next release.

Why This Matters
Many users requested the ability to create deeper, more complex menu structures — especially for large sites with multi-level content hierarchies, product catalogs, or mega menu requirements.

Previously, Solo focused on a clean, accessible 3-level menu structure, optimized for performance and simplicity. However, after carefully evaluating real-world use cases and listening to user feedback, fourth-level menu support has been added — with full consideration for:

• Accessibility best practices (ARIA roles, keyboard navigation)
• Responsive behavior on mobile and desktop
• Automatic submenu positioning (smart flip logic)
• Clean, maintainable CSS and JS handling
• RTL (Right-to-Left) language support

Best wishes,
Alaa

Hello,

Based on valuable feedback from the Drupal community, Solo officially will supports fourth-level navigation menus in the next release.

Why This Matters
Many users requested the ability to create deeper, more complex menu structures — especially for large sites with multi-level content hierarchies, product catalogs, or mega menu requirements.

Previously, Solo focused on a clean, accessible 3-level menu structure, optimized for performance and simplicity. However, after carefully evaluating real-world use cases and listening to user feedback, fourth-level menu support has been added — with full consideration for:

• Accessibility best practices (ARIA roles, keyboard navigation)
• Responsive behavior on mobile and desktop
• Automatic submenu positioning (smart flip logic)
• Clean, maintainable CSS and JS handling
• RTL (Right-to-Left) language support

Best wishes,
Alaa

Hello,

I added some css to include any menu in the four primary grouped regions (Top, Main, Bottom, and Footer) and pushed the changes to the dev branch.

Best wishes,
Alaa

Hello,

Thank you for bringing this to my attention.

The fix is now available in the latest development version of the module.
Feel free to use the dev release, or you may wait for the next full stable release.

Best wishes,
Alaa

Hello,

Before creating a new issue, please review the existing issues and read the available documentation about the theme.

Please note that the menu system in the Solo theme does not support a fourth-level menu.

Thank you!

Hello,
I'm not entirely sure what caused the issue, but the recent update to the w3css theme involved removing the word "Version" from all libraries. This change was necessary because it was causing cached files in the browser dependent on the Core version. You can read more about it here: https://www.drupal.org/project/entity_browser/issues/3325948 🐛 Remove VERSION from libraries.yml Fixed

To control the order in which libraries are loaded, it's recommended to follow the SMACSS (Scalable and Modular Architecture for CSS) methodology. Drupal allows you to organize your CSS files into the following categories, each with its own load order weight:

• Base: Load Order Weight -200
• Layout: Load Order Weight -100
• Component: Load Order Weight 0
• State: Load Order Weight 100
• Theme: Load Order Weight 200

Example:

global-styling:
  css:
    base:
      css/reset.css: {}
    layout:
      css/layout.css: {}
    component:
      css/button.css: {}
    state:
      css/button-hover.css: {}
    theme:
      css/colors.css: {}

When Drupal processes these CSS files, it loads them based on their assigned weights. This ensures that foundational styles are loaded first, followed by layout structures, component-level styling, state changes, and finally visual theme adjustments. The result is a logical, layered approach to styling.

Side note: I’m also curious whether the intended behavior is for the site-specific theme’s CSS to override a library included in a custom paragraph template or not.

In general, yes a custom theme will override any module-provided assets by default. However, this behavior can be adjusted depending on how you define and attach libraries in your sub-theme.

Best wishes,
Alaa

Hello,

I’ve added the new feature to the four primary grouped regions (Top, Main, Bottom, and Footer) and pushed the changes to the dev branch. This feature is for large screen only. Feel free to test it at your convenience.

Best wishes,
Alaa

Hello,

Thank you very much for the clear pdf. I tested the right alignment with and without the logo, as well as with the menu flipped — everything is working as expected.

Best wishes
Alaa

You're very welcome — I'm glad to hear it's working beautifully!

Thank you as well for your kind words. I truly appreciate the feedback, and it means a lot to know the theme's organization and clarity stand out. If you need anything else or have further questions, I'm always happy to help!

Hello,

Thank you for the screenshots and the detailed description.

The menu is designed to target the immediate children of a LI that contains a button or link. However, when a menu item uses nolink and has no child items, Drupal renders it as a span instead of a link or button.

I’ve updated the menu logic to account for this scenario. It is pushed to dev feel free to use it.

Best wishes,
Alaa

Yes, I don't understand you. Please make a video and describe the issue.

Hello,

The logo option has no relationship with the menu. The description is updated so people don't confuse aligning the entire block with aligning individual child elements.

Best wishes,
Alaa

Hello,

The alignment moves the entire main menu block (not the items inside it) within its parent container. That means the full menu block itself shifts left, center, right, or stretches (justify) horizontally depending on the setting. The description was updated in the theme.

Best wishes,
Alaa

Hello,

A new dropdown has been added under the Theme Settings in the Primary Menu Settings section. This dropdown allows you to choose the main menu alignment with four available options: Left, Right, Center, and Justify.

This feature has been pushed to the development branch. You are welcome to start using it now or wait for the full release.

Best wishes,
Alaa

Hello,

I usually download the fonts from https://gwfh.mranftl.com/fonts and link them to my theme. I created a sub-theme → with an example.

Best wishes,
Alaa

Hello,

In the demo I have the main menu and the logo in the same region. You can flip the main menu and the header as the demo then use this code to align the main menu to right.

https://www.youtube.com/watch?v=w9qRuAtfLTI

Place this code in the theme settings under Global settings in CSS Injector.

#page-wrapper .navigation__primary {
  margin-left: auto;
}

Best wishes,
Alaa

Hello,

The menu system in Solo has been thoroughly tested and fully respects any custom classes applied to menu links.

If you're experiencing issues with the menu, it's likely due to a conflict specific to your site’s configuration or custom code. Unfortunately, I'm unable to assist with site-specific conflicts outside the scope of the theme.

Thank you for your understanding.

Best wishes,
Alaa

Hello,
Hello,

The primary menu uses a custom template and is specifically built for its designated region. If you'd like to add a menu to the header area, please follow these steps:

1. Create a sub-theme to override the necessary templates without affecting the base theme.
2. Create a new menu via the Drupal admin interface (Structure > Menus).
3. Use the horizontal menu template as a reference to create a custom template for the new menu. https://www.youtube.com/watch?v=UJpNOawzl9E&list=PLZVSLeSmRrd1nqYAFOyalL...

This approach ensures the header menu is styled and structured according to your design needs while maintaining best practices.

Best wishes,
Alaa

Hello,

Thank you for bringing this feature to my attention. I've added a "None" option to the date format dropdown, allowing users to opt out of custom formatting and fall back to Drupal's default behavior.

This enhancement is now available in the development version of the theme. You're welcome to try it out or wait for its inclusion in the next full release.

Best regards,
Alaa

Hello,

For 2 Show Collapse or Expand (Single): please download the new release.
For 3 When I open a tab, the previous one should close, as in the page: I added a new feature in the new release called (Exclusive panel). Allow only one panel to be open at a time.

Best wishes,
Alaa

Hello,

The height of each slide is calculated dynamically to ensure smooth transitions. However, when margin is added to the slide’s child elements (such as the paragraph), that margin isn't included in the calculated height.

To address this, I’ve added a small CSS adjustment to ensure the height is calculated correctly.
Please download the latest version and use that going forward.

Best wishes,
Alaa

Hello,

Here is an example of how to use this module:

1. Create five content items using any content type available in your system.
2. Create a View and select the Tabs display format.
3. Add the Title field as the first field in the view—this will be used as the tab label.
4. Add the Body field after the title—this content will be displayed when a user clicks on each tab.
5. This behaves exactly like the accordion module you've used before.

Best wishes,
Alaa

You too!

Hello,

The only difference between versions 1.0.13 and 1.0.18 is that the bottom borders were moved from the

Hello,

The poem you're using appears on a single page. This module is designed to work with multiple pieces of content, which can then be displayed using a View.

You could use the Paragraphs module to create tabs and show one section at a time.

As for borders, I apply custom classes to target specific tables. I don’t use inline styles, so unfortunately I can't offer help with that part.

Best wishes,
Alaa

Hello,
1- I updated the gaps in 1.0.8 version feel free to use it. Now the gap is controlled in the parent wrapper if want to update the gap use this code:

.vvja .vvja-inner {
  --grid-gap: 12px or 16px;
}

2- You should use the inspector and inspect the element to see what is the reason or send the link.

3- This accordion does not work this way. when I have time I will add this feature.

Best wishes,
Alaa

Hello,
You should use the browser inspector to examine the element and understand the cause of the issue—it might be a conflict. You can also try using !important to force the style override if needed.

If a CSS variable is already assigned to the HTML element, try using the variable instead of hardcoding the color or background value.

#page-wrapper .solo-inner ul.navigation__menubar li>a.is-active,
#page-wrapper .solo-inner ul.navigation__menubar li.is-active>a,
#page-wrapper .solo-inner ul.navigation__menubar li.is-active>button {
  --r-bg: #5881AE;
  --r-tx:  #FF0000;
}


#page-wrapper .solo-inner ul.navigation__menubar li>a.is-active:hover,
#page-wrapper .solo-inner ul.navigation__menubar li.is-active>a:hover,
#page-wrapper .solo-inner ul.navigation__menubar li.is-active>button:hover {
  --r-bg: #FF0000;
  --r-tx:  #FFFFFF;
}

In your code, I noticed that in the second group, the hover effect is only applied to #page-wrapper .solo-inner ul.navigation__menubar li.is-active > button:hover. Was this intentional?

Best wishes,
Alaa

Hello,

I tested the paragraph slideshow locally using Drupal 11, and it's working as expected. It's unclear how you've added the slideshow, but based on your screenshot, it looks like the slideshow sections aren't displaying correctly.

Please check the paragraph bundle and confirm that all required fields are present. You can review the form display configuration by visiting:

your-site.com/admin/structure/paragraphs_type/slideshow_bundle/form-display

When you first add a slideshow, you should see a default structure like this.

Similarly, when editing content to modify the slideshow, the form should display relevant fields as well.

If you're still having trouble identifying the issue, I recommend starting from scratch. Try uninstalling the relevant modules, ensuring all related configuration is removed, then reinstall everything again. Be sure to check the settings under "Manage display" and "Manage form display" for each paragraph bundle.

Let me know how it goes!

Best wishes,
Alaa