Hello @VladimirAus,
I came across this topic while working on an issue involving the _progress.scss file in this theme. It seems that this file is overriding the display property from Bootstrap 5 (BS5).
In the Bootstrap 5 source code, it's indicated that the .progress element should have a display: flex; styling (ref: https://github.com/twbs/bootstrap/blob/main/scss/_progress.scss#L24). However, in the BS5 Drupal theme, this value is set to display: block; (ref: https://git.drupalcode.org/project/bootstrap5/-/blob/3.0.x/scss/drupal/_...).
I'm curious about the reasoning behind this change. In my understanding, it would be beneficial to maintain code that's similar to the original BS5 code to minimize the need for patches and potential compatibility issues.
I'm looking forward to hearing your thoughts on this matter.
Best regards,
Mykola Balabash
Dear @amal.bukhari,
We greatly appreciate your correspondence. We wish to inform you that the problem concerning the support of standard custom Drupal menus has been successfully resolved. This solution has been incorporated into the most recent version, namely 5.1.2.
Kindly inform us whether you are utilizing multi-level menus or the Megamenu module. Presently, we regret to inform you that our support extends exclusively to the Main navigation menu. Implementing these menus beyond this scope necessitates tailor-made adjustments to your website.
Your understanding is valued.
Sincerely,
Mykola Balabash
Dear @ravi kant,
I extend my appreciation for your diligence in bringing this matter to our attention. With great care, we have conducted a comprehensive assessment of the issue and undertaken rigorous testing on our end, utilizing the latest iteration of Drupal, version 10.1.
Outlined below are the precise procedural steps that were meticulously followed during our testing phase:
1. Installation of the latest Drupal version was initiated using the command: composer create-project drupal/recommended-project my_site_name_dir
2. Executed website installation either via Drush or the user interface.
3. Verified the activation of error logging within the website environment.
4. Integrated the DXPR Theme through Composer as follows: composer require 'drupal/dxpr_theme:^5.1'
5. Enabled the Color and DXPR Theme Helper modules.
6. Set DXPR Theme as the default theme and activated it.
7. Utilized the terminal to access and interact with the DXPR Theme.
8. Generated a sub-theme using the dxpr_theme_STARTERKIT script: ./scripts/create_subtheme.sh
9. Enabled and designated the newly created sub-theme as default.
10. Scrutinized configuration and content pages for error messages and database logging verification.
In view of these efforts, I kindly request that you consider the outlined steps and undertake a similar course of action on your end. If this course does not yield the desired results, I would greatly appreciate your provision of information regarding your sub-theme creation process, as well as the default theme that has been designated within your context.
Thank you for your collaboration, which plays a crucial role in our endeavour to ensure operational excellence.
Sincerely,
Mykola Balabash
Hello @asb, thank you for reporting this to us. We are looking into this issue.
Could you please share the next information with us?
- Installed PHP version on the server
- Installed Drupal version
- Do you have dxpr_theme folder in your public files folder, e.g. /sites/default/files/dxpr_theme/fonts?
Thank you for an update @Akram-Pk!
Dear @jabeler,
Thank you for bringing this matter to my attention. I have successfully replicated the issue and am currently working on a solution to resolve it.
Added check for field value and return empty string for unpublished nodes. Solution from 7.x branch.
twilderan → created an issue.
Greetings @shas3n,
We kindly request that to confirm whether you have enabled all necessary regions in order to implement your custom design, as demonstrated in the provided screenshot.
Thank you for your assistance.
Hello @vpowner,
Thank you for bringing this to our attention. After conducting an investigation, we have determined that the behavior you have reported is actually the default behavior of Drupal.
To address the issue, we kindly recommend that you first uninstall DXPR Theme Helper and then proceed with removing the package from your composer files in order to remove the corresponding configuration files.
We kindly request to inform us, if this solution resolves the issue for you.
Thank you for your cooperation.
Hi @Akram-Pk,
Thank you for your request, I've investigated your issue and found a possible issue.
I guess you accidentally enabled Starterkit theme instead of ready to use one.
Please check this screenshot:
Indeed there in an error with submitting Site Branding block with enabled Starterkit theme, but this machine name supposed to be changed on setup:
And here is how it looks like with enabled DXPR Theme 5.0.1:
Please switch to DXPR Theme 5.0.1 in order to fix this issue.