About the depth - let's imagine a "page" node which has a reference field "related_articles" with several articles, and each article has a field "related_pages" linked to some pages - by exporting this, we can get a pretty long nested structure, and even loops.
To make it work well, we also need to allow configuring the depth of the dependencies, and the list of reference fields to skip from exporting, because without this can produce a huge amount of unnecessary entities and even circular redirects. As an example of how to resolve this issue, we can look at this implementation: ✨ Allow to partially export content Active
As an alternative, until this feature is in core, we can use this module: https://www.drupal.org/project/single_content_sync → - it can export Layout Builder too, and also integrate reference entities like menu and path_alias into the single yaml file together with node.
murz → created an issue.
Implemented
This still happens if the Filters block contains custom filters selection, reopening to fix.
Fixed.
Fixed.
Fixed.
Implemented a fix
murz → created an issue.
Implemented.
The actual source of this specific issue is the Drupal Core issue 🐛 [warning] No configuration objects have been updated. Needs work that got reverted for some reason.
But the general issue with this - is that the stdout output can be mixed with any output, which causes the JSON parsing issues in many Drush commands.
Actually, this happens not only with JSON-formatted logs, but for any log style that outputs to stdout (for example, by this module: https://www.drupal.org/project/log_stdout → ).
But for non-json output this issue in most cases doesn't produce the fatal error, because Drush tries to remove non-json output using this trick:
$result = $process->getOutputAsJson();
that uses under the hood the function Consolidation\SiteProcess\ProcessBase::getOutputAsJson()
which uses a trick to remove non-json prefixes and suffixes in the function ProcessBase::removeNonJsonJunk().
This is why it doesn't cause errors on non-json-formatted logs in most cases, until the log record doesn't have the { symbol.
Seems this patch got reverted for some reason?
Cuz now I see this message again with the "warning" severity in Drupal 11.1.8 (and in 10.2.x too): https://git.drupalcode.org/project/drupal/-/blob/11.1.8/core/modules/loc...
function locale_config_batch_finished($success, array $results) {
if ($success) {
$configuration = $results['stats']['config'] ?? 0;
if ($configuration) {
\Drupal::messenger()->addStatus(t('The configuration was successfully updated. There are %number configuration objects updated.', ['%number' => $configuration]));
\Drupal::logger('locale')->notice('The configuration was successfully updated. %number configuration objects updated.', ['%number' => $configuration]);
}
else {
\Drupal::messenger()->addStatus(t('No configuration objects have been updated.'));
\Drupal::logger('locale')->warning('No configuration objects have been updated.');
}
}
}
Also, try a fix from the issue 📌 Minimize service dependencies to optimize performance Active - maybe the request_stack dependency causes this error, and reworking it to lazy load could help resolve the circular reference issue.
If not, to fix this issue I need clear steps to reproduce the issue on my side.
Implemented a new checkbox "service.name" in the settings, that adds the service info to the log.
I installed the Domain module and the Extended Logger, but still can't reproduce this issue.
Maybe I need to set up some specific settings to get this error? Could you please share reproduction steps starting with bare Drupal? Thanks!
murz → created an issue.
murz → created an issue.
Already updated to Drupal 11.
murz → created an issue.
Fixed.
Implemented.
Seems Formdazzle! fixed the issue #3086985: Themes with form_alter conflict with formdazzle_form_alter → that makes it "great again"? Just can't actually choose what to use - Twig Template Suggester or Formdazzle! :)
Tested the fix in the MR and it works well.
Reviewed the changes and the solution is very simple, removes a lot of the legacy code, and makes the function clear.
About the hard-coded offset of 10px - the right solution is to use the CSS rule "scroll-margin-top: 10px" instead of hardcoding, so it's good that we're removing this.
As I see no issues with the new implementation, moving to the Reviewed and tested status.
Implemented.
@abhishek@kumar, so do you want to contribute a fix for this bug? If not, @eugene_bsk is ready to work on this.
Found a pretty ugly workaround to override the CSS and JS files of a SDC component in the theme - in the my_theme.info.yml we can add these:
libraries-override:
core/components.my_module--my_comonent:
css:
component:
'../modules/custom/my_module/components/my_component/my_component.css': css/my-component-design.css
And then, you can create a CSS file in the theme my_theme/css/my-component-design.css to override styles.
Take note that this overrides the whole file, not adds an additional CSS. So, if you want to only extend the component CSS, provided by the module, not replace it - this doesn't suit.
@abhishek@kumar, I think the first option is more straightforward, because actually, when we have in several product types an attribute with the same name, we can't just filter by the attribute for only one product type.
For example, we have Hats with attribute "color" and Pants with the same attribute "color", and both attributes will be represented as a single facet in GraphQL, so we can't filter just by "Hats" color.
So, let's choose the option to group the filters by the name in the block settings form then, what do you think?
murz → created an issue.
Implemented.
Implemented.
Implemented.
Simplified generating the root of the form and added skipping langcode for forms. Attaching a static patch file with those changes, to make it possible to use in composer until 🐛 GitLab Merge Requests Unable to Generate Incremental Patch Files Active is resolved.
Updated the fix to force getting the original data. Attaching a static patch file with those changes, to make it possible to use in composer until 🐛 GitLab Merge Requests Unable to Generate Incremental Patch Files Active is resolved.
I implemented the fix, please review. Attaching a static patch file with those changes, to make it possible to use in composer until 🐛 GitLab Merge Requests Unable to Generate Incremental Patch Files Active is resolved.
murz → created an issue.
Seems now "Extension configuration" is already outdated (last commit - 8 years ago) ;-)
@chi Do you plan to update your module, or maybe you've renamed it and continued the development with another name?
Added deduplication of enforced lists. Attaching a static patch file with those changes, to make it possible to use in composer until 🐛 GitLab Merge Requests Unable to Generate Incremental Patch Files Active is resolved.
Simplified implementation and add sort to prevent the array order. Attaching a static patch file with those changes, to make it possible to use in composer until 🐛 GitLab Merge Requests Unable to Generate Incremental Patch Files Active is resolved.
Improved the implementation. Attach a static patch file with the last changes, to make it possible to use in composer until 🐛 GitLab Merge Requests Unable to Generate Incremental Patch Files Active is resolved.
Decided to use data from Drupal Configuration instead of separate YAML files, because of the simplifying, better performance, and caching out of the box. See ✨ Implement overriding the schema form fields using configuration Active for the implementation.
For me sometimes yes, sometimes not, seems depends on the error type. I'll try to find a short case to reproduce it.
Attaching a related Core issue with missing API: ✨ Form api does not have any Reset button Active
Until this is fixed, as a workaround you can use two approaches for now:
1. Use the form redirect like this:
public function buildForm(array $form, FormStateInterface $form_state) {
...
$form['input_data']['options']['clear'] = [
'#type' => 'input',
'#value' => $this->t('Reset'),
'#limit_validation_errors' => [],
'#submit' => [[$this, 'resetForm']],
];
return $form;
}
public function resetForm(array &$form, FormStateInterface $form_state): void {
// A workaround for the issue
// https://www.drupal.org/project/drupal/issues/2799269
$form_state->setRedirect('<current>');
}
2. Use the browser API to reset the form:
$form['reset'] = [
'#type' => 'input',
'#value' => $this->t('Reset'),
'#limit_validation_errors' => [],
'#attributes' => [
'onclick' => 'this.form.reset(); return false;',
];
);
But the proper API from Drupal Core would be much better, so keeping the issue as active.
Reviewed and merged.
Implemented the first implementation in the MR. Attach a static patch file with those changes, to make it possible to use in composer until 🐛 GitLab Merge Requests Unable to Generate Incremental Patch Files Active is resolved.
Moving to "Needs review" to get an answer for the MR's comment https://git.drupalcode.org/project/drupal/-/merge_requests/160#note_146560
Attach a static patch file with those changes, to make it possible to use in composer until 🐛 GitLab Merge Requests Unable to Generate Incremental Patch Files Active is resolved.
I updated the issue title, please check if the name suits the rules now.
Fixed.
For this implementation, it will be loaded from cdn for performance reasons, but for subtheme you can override the library and put the files locally, and made needed changes in it.
Implemented.