Thanks!!
I will check it out
Setting to needs review
I was working on rebasing the 8.2.x branch, made some mistakes but fixed it at the end. The new branch 3461920-logger-misconfigured-8.2.x should work for the 8.2.2 version of the module.
I did not review the changes made by the original committer, I just rebased the 8.2.x Branch
Usage (while this gets approved):
Add the patch in your composer.json
- If you are using 8.1.x use the merge request #10
- If you are using the 8.2.x version, use merge request #13
chadhester → credited camoa → .
As far as I can see in the bootstrap5 theme page, v3 and v4 don't have major differences. So maybe all that is needed is the composer.json change.
camoa → created an issue.
Closing in favor of 🌱 IXP Phase 2 proposed process Active
Closing in favor of 🌱 IXP Phase 2 proposed process Active
Forgot to close
closing in favor of 🌱 IXP Phase 2 proposed process Active
Can we start doing this?
We need a volunteer maybe?
Closed in favor of 🌱 IXP Phase 2 proposed process Active
Closed in favor of 🌱 IXP Phase 2 proposed process Active
This is closed in favor of Phase 1 Proposal 🌱 IXP Phase 2 proposed process Active
Why not use the Issue fork?
I believe that is a better practice.
Your dependencies are not D11 compatible yet.
https://www.drupal.org/project/image_style_quality → is not.
Any advice? I am using D11 and wanted to use this module
Yes, Bob, I will do that. Or at least link the docs!
I just realized something, we haven't mentioned about guidelines to get the credit.
Should that be here or its own issue?
@hestenet? @ultimike?
That is a beginning! Great. From the doc that was shared, anything else that you see as something a IXP should be?
Thanks!!
I have corrected it!
Here we need a lot of help!
This is probably one of the most important parts.
It will provide guidance and also a way to demonstrate the end of the process.
So first step is to give an initial weight to this contribution, correct?
Same.here, Mike.
Let's put the table so people can have something to comment here.
I can try to do it tomorrow.
Mike and Javier,
I like this organization, lets.start by separating, what is IXP here.
This will be a great beginning!!
volkswagenchick → credited camoa → .
volkswagenchick → credited camoa → .
Adding one more point to link with the chance that companies can provide their case studies and guides on handling Inexperienced developers.
I have worked out the rebase of Drupal 11.x and compiled CSS via yarn run build:css.
Updated summary, and changed back to 10.1.x since drupalpod is not working with 11.x apparently.
Why are we using patches when there is a fork already? Just curious.
The issue fork has the changes you mentioned and I will add the extra ones as soon as my day starts.
Should we create instances that do not exist as variables but follow the pattern of the layout helpers? for consistency.
There are calc(13 * (var(--sp)); adn cal(4.5 * var(--sp)); that are not defined as variables.
Or is this too much?
I think the starterkit YAML file is a great addition, will it be worth to also provide a simple way to pass options? For dynamic changes the theme may need, for example, it could allow.Olivero to set the default color of the generated theme, or allow themes to provide basic options for customization and avoid manual changes.
It could be as simple as passing a --options to the generate theme command and pass this along to the starterkit postprocess.
Working on this with A customer,
the line:
$config[$id]['settings']['value_form'][0]['value'] = str_replace("\r", '', $options['value_form'][0]['value']);
gives an error:
[critical] Migration failed with source plugin exception: Cannot access offset of type string on string in /mnt/www/html/txhhsinternalmigrate6/docroot/modules/contrib/conditional_fields/conditional_fields.module