danchadwick → created an issue.
Forgive my inexperience with GitLab, but I think this needs rebasing on the current 6.0.x head. I'm scared that if I click "Merge", it will revert the changes where the issue fork is behind radix.
danchadwick → created an issue.
@anybody. Thanks. The part I was missing was just to create the link just like you would for any other core Ajax dialog. I created README_DIALOG.mdx in the starterkit to document exactly how to get core Ajax dialogs working. It not hard, but thinking too hard had me reading Bootstrap documentation, which is a step in the wrong direction.
danchadwick → created an issue.
danchadwick → created an issue.
danchadwick → created an issue.
All CI code-standard test pass now. Some of the eslint ones were made to pass by disabling the tests to avoid coding changes.
Notable changes:
The (presumably intended to be private) global function radixCleanIdentifier was changed to snake-case radix_clean_identifier. It is not expected that subthemes would call this function. However, if they do, they would need to update the function call accordingly.
The drush command radix:create had it annotation corrected to remove the machine_name option, which is not implemented.
Furthermore, the drush documentation indicates that PHP 8+ only commands should be written with PHP attributes. This would be a separate issue. The annotation would be something like:
use Drush\Attributes as CLI;
[snip]
/**
* Create a radix sub-theme.
*/
#[CLI\Command(name: 'radix:create', aliases: ['radix'])]
#[CLI\Argument(name: 'name', description: 'The machine-readable name of your sub-theme.')]
#[CLI\Usage(name: 'drush radix:create my-theme', description: 'Creates a Radix sub-theme called my_theme, using the radix_starterkit.')]
danchadwick → created an issue.
danchadwick → created an issue.
danchadwick → created an issue.
Great catch, @thomas.frobieter.
danchadwick → made their first commit to this issue’s fork.
So these are CSS selectors of equal specificity. Without digging, I'm not sure Drupal guarantees the relative order of the stylesheet references for the theme's library (which references the main stylesheet build by webpack.mix.js) and those included by the components via core's Single Directory Components. I would not recommend relying on the order of equal-specificity selectors.
What I would recommend is that, instead of trying to override conflicting CSS properties of, say .btn, instead look at the bootstrap definition of .btn and instead override the variables that are used to define it. See /src/scss/base/_variables.scss.
Hope that helps.
I'm confused about the issue you are facing. sub-theme/node-module/bootstrap contains the actual version 5.3 bootstrap source files. It has nothing to do with radix, except of course that radix uses these file.
The style definition for a class like .btn is from bootstrap 5.3 itself. Radix does not override bootstrap SASS files, although you are certainly free to do so in your subtheme.
If you can ask a more specific question, I'd be glad to try to help.
@joachim namyslo. I have found WampServer to be exactly to my liking, and have made tools (with few exceptions) work under git bash for windows. WRT the recent windows segment faults after upgrading to PHP 8.3, I found that switching the configuration from the apache module to FCGI worked flawlessly. My segment faults are gone without other changes to .htaccess, disabling xdebug, adjusting the apache configuration (such as thread size), etc.
I have no idea of course what the actual source of the segment fault is. I only know the change that fixed it.
Closing for lack of additional information or activity. Happy to update documentation with better instructions if someone provides them. I tried running this on windows under the git bash shell and was not successful. I can't help with linux.
Thx. Merged.
This seems to be a webform thing, which wouldn't apply to Radix in general.
https://www.drupal.org/node/2972533 →
I'm going to leave this closed, but if anyone can supply instructions to use bootstrap modal with radix natively (i.e. not with webform), please do re-open.
@jamesoakley - Open a MR with your suggested change? I don't use browsersync so I can't really test that part.
Agree on 2 weeks, although I'm hoping for a stable within that time. I was thinking a week of RC7 with no significant issues before stable.
NOTE: The "vertically_centerred" property for the modal component had it's spelling corrected from "verticaly_centerred". Since modals are not generally created by the component's template, this is not expected to affect any current pre-release 6.0.x users.
cspell now passes in the ci pipeline.
danchadwick → created an issue.
Note: the above merge request is actually for the dropdown schema. It got linked to the wrong issue. The table schema issue is still open.
I too am new to the drupalcode merge request workflow. First, I had to get the pipeline to build (which I did in another issue). This I found your change and merged it, but it wasn't linked to this issue. So your changes have been committed and merged in 6.0.x. Thanks for your help.
danchadwick → created an issue.
I think the ship has sailed on reversing the change. It was pushed on November 21, 2024. There are about 500 reported users of 6.0.x. Certainly some of them (like me) will have started with this change and changing back would break my site.
I just now updated the release notes to specifically call out the change to the image template.
This issue highlights that it is somewhat brittle to have the templates (and associated x.theme files with preprocess functions) copied from the base theme to the sub-theme, and them have them use the base theme's components.
Some opttions:
- Do nothing and rely on the release notes. If you update without reading release notes, particularly for a pre-stable version, you are taking a risk, IMO.
- Change the version to 6.1.0-rc1.
- Change the version to 7.0.0-rc1
- Change the image.twig file to contain:
{% set image_attributes = image_attributes ?? attributes ?? create_attribute() %}
and them immediately release 6.0.0-rc8. (I need to confirm the that associativity of the ?? operator correct :) )
I don't love the last option because a) it may trigger an issue with the schema and we don't want to change the schema to include it, lest we encourage people to use it and b) it adds cruft to the first stable release of this branch. This is a decision for @doxigo.
Presumptuously you have to watch the sources (or you won't start the build) and watch the destinations (so you can re-trigger the browser refresh). What I'm wondering is if you do that, do you get two builds -- source change -> build -> destination change -> build -> destination "changed" to the same file contents.
I'm surprised this doesn't make an infinite loop.
Ideally you'd like to decouple the build (based on source) and the refresh (based on destination). Possibly?
@anybody - Re breaking changes: I'm not the primary maintainer. That's a question for @doxigo. Certainly, such changes to a stable version should be mentioned in the release notes. Due to the nature of how the sub-theme has copies of templates (and theme functions and CSS and JS), it's becomes very hard to make improvements to the base theme without some manual work needed upon upgrade. Personally, I'd like to see minor-level version change for such things (e.g. 6.8.3 -> 6.9.0). That way the major version tracks the "bootstrap 5, SDC-aware" version.
And I do agree that a patch-level version should be backward-compatible.
@amysiano4x3 - Close, but not quite. The MR was opened on the issue for the table schema, not this one.
@amysiano4x3 Thanks for the MR. However this issue is for the table schema. I don't think you can move a MR, so could you please open this MR on the issue for the dropdown-menu? And then I need someone else to test it with schema validation enabled.
This for the report. I'm 92.6% sure this is related to the changes in the template and component template made in in #3482516. Please adjust your theme's templates to correspond to the new radix template (or replace both your your subtheme's templates).
I did note in the rc7 release notes that there are template changes. The dropdown and dropdown-menu both changes, for example.
If this isn't this issue, please do re-open with more information.
The only other change I see is the removal of the trailing closing slash in the image tag, and a major change in the template for the user_picture in the comment template, either of which seem relevant here.
Changing priority to minor since this only affects those who have required "core-dev" and enabled assertions.
Closing with the discussion to comment out the dialog js overrides.
The discussion of moving some things from the starter kit to the base theme is valid. This might include templates and js/css overrides. If there's appetite for this, please open a new issue. Pro: easier to update everyone. Con: easier to break everyone.
Real status should be "don't work as designed". ;)
I can confirm that the starter kit templates are discoverable. Therefore the solution would be to retain the subtheme's template, or change the suggestions to remove the template that is being found in the starterkit. This is a theme system issue, rather than a radix issue.
Closing as "works as designed" because the radix parts works and there's no option for "not my problem".
Stable release will be made if rc7 does not have significant issues reported.
After discussion with @doxigo, I think we should leave this commented out. It causes problems with (at least) layout builder. Until it's solid, I think it's better to opt-in.
Still interested in instructions for using it. If found, I'll add it to the documentation somewhere (like maybe in the dialog component's .mdx file).
Does it build twice, once when the sources is changed and again when it detects the build file changed?
Also wondering if there is a time threshold that mix supports, like don't trigger the browser reload until the job is done.
danchadwick → created an issue.
danchadwick → created an issue.
Super. I could sure use the help. There's no way that I can go through all the components and make sure that the variables and slots actually used correspond to the schema and the block comments in both the component twig and calling template twig files.
Here's some sample schema. I haven't found a good definitive guide other than this though:
https://www.drupal.org/docs/develop/theming-drupal/using-single-director... →
This is a Single Directory Component (SDC) validation error. This validation only happens for core developers with assertions on. @see "Component Data Validation" here: https://www.drupal.org/docs/develop/theming-drupal/using-single-director... →
So if you're trying to make progress, either disable assertions or remove the drupal/core-dev package from your project's composer.json.
I suspect there are a lot of schema validation errors in Radix. I'd welcome patches or MR to improve them.
For this particular one, it looks like:
- alignment is '' for left. This string value needs to be added to the schema. Might be wise to allow null too.
- style is set as a class on the nav ul item and should not be passed to the dropdowm-menu component at all. It isn't used there. So style should be removed from the schema.
- fill is the same as style. Should be removed from the schema.
If you're game, update to the latest radix dev (as there have been a number of changes since rc6), make the above schema changes in components/dropdown-menu/dropdown-menu.component.yml, and post a MR or patch. I'd be happy to commit it.
danchadwick → created an issue.
@anybody - Could I impose on you to educate me on how to use the dialog overrides. What I tried was:
- Disable bootstrap4_modal, which I was previously using.
- Comment back in the library overrides for dialog.js and dialog.ajax.js in my info file.
- Change my triggering link to be have the attributes data-bs-toggle='modal' data-bs-target:='#drupal-modal'. I tried it both with and without a class of 'use-ajax', which didn't seem to matter.
When the link is triggered, I see a dialog start to be displayed. I see the ajax network traffic returning the form from the route. But the contents of the form don't make it to the pop-up dialog ( the div with class modal-content is empty).
Can you point me at some better instructions for using these dialogs? Maybe we can get usage documented and have them enabled in the starter kit. TIA
Not my area of expertise. Can anyone else chime in, ideally with an exact patch?
Closing for lack of priority and resources. Please feel free to reopen with additional info or a MR.
I adjusted the component to not wrap the table with the bootstrap table-responsive div if sticky is enabled. I think this is the best we can do. If someone want's to have the nav bar work as I do, they'll have to patch core or similar.
Calling this fixed unless someone has a better idea.
Given the complexity and lack of appetite for making this work, I'm closing this. Please feel free to reopen with a solution, MR, or more information.
Agree with @doxigo. This is something for a subtheme to address. Closing for lack of activity.
@jcandan: I've been tidying up the issue queue, hopefully in preparation for a stable release. I would welcome any help on the release notes, particularly including changes for rcX upgraders.
This think the concern is/was that a translated path alias would be quite brittle. However, given that this has been in radix since v5, let's leave it alone to avoid a breaking change.
@thomas.frobieter: Thanks for your suggestion. If we didn't have existing users, I'd would have removed the suggestion for path alias.
The dialog overrides are currently commented out in the starter kit. Absent more info, it seems like this a) isn't currently being supported in v6 and maybe even works properly. Please re-open if there's additional information or issues.
Closing for lack of feedback / improvement suggestions to the documentation.
I agree. It seems like you could do this in a subtheme needed.
@doxigo: your thoughts?
Also, I cleaned up some leftover cruft (getting the node revision, but then not using the result).
@diegopino: thank you for the thorough report and suggested solution. I followed your ideas. Please re-open if you need further improvements (after adjusting your template to correspond to the one in the starter kit).
This commit fixes a number of things:
- The first link becomes the button. It retains any existing attributes.
- The dropdown_button_attributes passed to the dropdown component are now actually used.
- The preprocess function does not add classes. That's left to the template where it's easy to customize.
- The first link, which becomes the button, is left as the first element in the links variable in case your subtheme needs it.
- The link is now generated natively. This means that to add classes, the same care must be taken to avoid the core bug as happens with local tasks. A (ugh) global function was created to help with this.
- The split variable is now calculated in the preprocess and passed to the dropdown component.
- The menu block no longer needs to be passed to the dropdown component.
NOTE TO EXISTING 6.0 RELEASE CANDIDATE USERS: You will need to copy a new links--dropdown.html.twig file from the starter kit to your subtheme and customize it to your liking.
Seems like the instructions need updating, maybe?
Duplicate report. Closing in favor of more detailed description in related issue.
Thx for the patch. I searched the codebase and found a couple others. There is also one in a regex expression in progress.js, but since that is looking for HTML generated elsewhere, I left it as is.
Anyone want to work on a MR for this issue?
There were a couple of issues related to menu links and classes. Could you please try the latest dev and re-open this issue if the problem persists. I cannot reproduce any issue on the latest dev.
I resolved this by preprocessing the menu local tasks, rather than relying on the bug in core being fixed. This circumvents the core bug.
Since the identical progress.js appears in both the components/progressbar and the src/js/overrides directories, I simply deleted the one in the components directory. For reasons I have not researched, the presence of this version in the SDC prevented the core misc/progress.js from being loaded, leading to the javascript error and failure of batch operations.
With the overrides loaded in the info.yml file via libraries-extend, both the core and the radix version of this file are loaded. The core version supplies the Drupal.ProgressBar function.
This issue's resolution should make radix compatible with Drupal 10.4 and 11.1 when using progress bars. Please re-open if there are compatibility issues with earlier versions.
I'm not sure why your template suggestion is not being used. Make sure you've cleared the cache. Your suggestions (may) need to be directly in the /templates directory, not nested in a folder within. I found I had to declare the template in MY_SUBTHEME_theme() using the 'path' array element in order to have one of my templates discovered when placed in a subdirectory within /templates.
In any case, I don't think this is really a radix issue, but rather relates to the core theme system. Best of luck.
Re #3, the spaceless filter has now been removed. We welcome any patches or MR that address any of these issues. There is a lot of work to perfect the components.
@deepali sardana: I appreciate the MR, but that's not the right fix. The row-N and col-N classes need to be removed.
The above commit:
- Removes the row-N and col-N classes,
- Adds a trailing comma, missing from the classes
- Fixes the vertical alignment by adding a wrapping row class
- Adds the missing template to the starter kit.
@tstermitz: Yes, the core requirement in your subtheme matters. The version doesn't matter to drupal, so you can set it to whatever you want to track its version (which should not directly track radix, since your changes are different from radix's changes).
However, you might NOT want to update your starterkit version. You can use this to compare the templates (and maybe other files) between, say, rc5 and 6.0.0 stable to see what things were fixed in the starterkit templates that you might want to backport to your subtheme.
Without researching this, I'm guessing the core requirement was updated to include D11 between rc5 and rc6.
I'm closing this issue. If someone discovers an actual incompatibility with Drupal 11, please do open a new issue.
Looking at rc6, both the radix.info.yml and the starterkit info.yml indicate that radix v6 is compatible with D11.
I think upgrade status just considers the info.yml files. Is there some other issue, or can this be closed?
Committed to 6.x. This resolves the issue of semantic and display errors when two HTML tags abut with intended whitespace between them. A good example is an inline field with span tags around the label and the field contents.
If you would like to remove some of the extraneious whitespace from the HTML output, I would welcome a new issue and MR/patch for using fine-grained Twig whitespace control using the dash and tilde modifiers to opening/closing tag syntax.
danchadwick → created an issue.
Here's a re-roll to be applied after the issue remove the spaceless filter tags is committed.
Here's a patch to harmonize dropdown-menu with nav with regard to link().
danchadwick → created an issue.
Here's a patch intended to be applied to commit #15244b15 which simply removes all the spaceless tags and adjoining whitespace. Because it touches 56 files, it will would be ideal to commit this before other patches.
It was created by making the following regex deletions using my IDE:
\{% apply spaceless %\}\n\s*
That matches {% apply spaceless %}, followed by a new line and additional whitespace.
^\n*\s*\{% endapply %\}\n*
That matches the start of a line, optional whitespace, followed by {% endapply %} and optional additional newlines.
I have looked at the file changes in all 56 files and confirmed that the regex replacements worked as intended.
The spaceless filter causes my site a number of display and semantic errors.
Here's a patch to just delete progress.js from the components in order to get sites working again with D10.4
danchadwick → created an issue.
Personally, I'd prefer to see spaceless retained and the affected templates modified (or fixed). The intention is to feel free to format templates liberally as if they are source code (which they are), and yet in production not generate a ton of wasted whitespace.
danchadwick → created an issue.
@ghost of drupal past: Unpersuaded. The very next line truncates the name to 25 bytes, surely a much larger source of concern for collisions. The caller will need to take care to pass names that fit within that limit without collision just as I propose they must with the colon. Beyond that, I'm unaware of any use of a colon in cache names other the SDC. Rather than patch a numerous places in SDC, why not protect the name from known illegal characters which result from an unfortunate design decision when SDC was committed?
Either way, SDC is broken for all windows developers right now.
danchadwick → created an issue.