Live feed

Anybody → created an issue.

Just saw that MR!17 had already been merged, so let's close this Fixed and add a new issue if needed.

Please provide a test to show this works as expected now and in the future or proceed with 🐛 Still not working with certain letters Needs work if it fixes the same issue and mark this one as duplicate. Thank you!

We should also have a test for this. It should fail for now and work with the fix. Thank you!

I see that this module is used by thousands of websites, and yet I can´t find any documentation, or video on how to use it.

Can't use this module, don't no how.... :(

Converted to MR and fixed more occurrences.

This has been postponed on a Coder issue 🐛 Drupal.Commenting.VariableComment.VarOrder - @var before @code Needs review . After working on this today I commented over there 🐛 Drupal.Commenting.VariableComment.VarOrder - @var before @code Needs review that I think there is nothing to fix. That is, the sniff is fine as is. One of the points in that issue was that an @link/@endlink before an @var was an error. There happens to be no such usage in core, so although it could happen it isn't. It seems like an edge case and should not block enabling this sniff.

Therefore I am setting this to NR.

i just added a very small fix in the MR of Christian to cope with the case you provided. thank you :)

msn5158 → created an issue.

I worked on the core issue 📌 Fix 'Drupal.Commenting.VariableComment.VarOrder' coding standard Postponed today and reporting back here.

The Drupal coding standards page api-documentation-and-comment-standards#order does not mention @code in the order of sections. Should it be considered a section?

Can make an in issue in the Coding Standards project so that can be discussed.

Core does not have any '@copyright' or '@license' in doc blocks. So, that point seems to be outdated.

And '@link .. @endlink' is reported as an error. But I think this is correct for the Variable comment block where the explanation is after @var.

Also, there were no instances in Drupal core where an '@link .. @endlink' was moved as a result of enabling the sniff.

So, for me I would go with won't fix on this.

Hello sea2709, thank you for your feedback.
About your test, is your Call to Action Body a prop or a slot?
when you say, it doesn't work, did you mean that when you select the source "Data from a field", and then you select a specific field,
then, no source is showing?

if no source is showing, that could mean ui_patterns couldn't find a compatible source for the field you have selected and the prop (or slot) you are trying to set a value for.
There may be a bug indeed, there may be a small context requirement missing. If you were trying to extract a field property from the source "data from a field", the field property can only show in certain conditions (at least your field needs to be a single value field) and the current implementation seems to have a little bug (in your case, if i am not wrong "field_granularity:item" should have been in the context_requirements context)

Probably should be in the release notes.

Seems like this was merged by lio above.

Added test. Setting back to needs review.

quietone → opened merge request !8953

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

Marking this one RTBC as changes are quite straightforward and pipelines are executed without any warning.

https://git.drupalcode.org/project/drupal/-/tree/11.0.x/core/modules/use...

d7_user still exists

Hi,
I use custom formatters in relation to shurly. Latest Beta4 version Shurly.
Could that have something to do with my problem of these warnings?
This is my Custom Formatters code, for the field Link:

$shorturl = $items->getValue()[0]['uri'];
$shortitem = shurly_shorten($items->getValue()[0]['uri']);
if (isset($shortitem['shortUrl'])) {
  $shorturl = $shortitem['shortUrl'];
}
$output  = '<a  href="' . $shorturl . '" class="btn btn-primary"  rel="nofollow" target="_blank"> Shortlink text </a>';
return $output;

Greetings,

msn5158 → created an issue.

Applied with https://www.drupal.org/project/bat/releases/8.x-10.2 →

Ah, it's the new "require bad English" coding standard, starting to bite - among other things. You now have to finish every list of parameters with a comma :(

Preparing a commit that makes PHPCS happy and me sad :)

Thanks for your great work!

I uninstalled the module. Attached is the result.

Thanks and best regards

Hi Mariska.

Thanks for your query.

I've looked at the page you've referenced and tried the button. It isn't using the Printable module but is instead opening the normal browser print dialog for the page. To use Printable, you'll need to configure it under /admin/config/user-interface/printable.

Alternatively, you could make what you currently have work better by adding CSS to your theme that targets print media (more info at https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Printing).

Regards,

Nigel

Changing this to fixing the violations that are currently ignored by // phpcs:ignore Drupal.NamingConventions.ValidVariableName.LowerCamelName

Automatically closed - issue fixed for 2 weeks with no activity.

Automatically closed - issue fixed for 2 weeks with no activity.

What I see is that the failure happened somewhere when running system.post_update.php, which is part of the Drupal core "system" module. And in particular, it failed while running the function system_post_update_add_langcode_to_all_translatable_config() that is found in system.post_update.php

The classes like \Drupal\Core\TypedData\TypedDataManager that show up in the error messages are all part of the \Drupal\Core namespace, which means they are part of core Drupal. You can tell that by the \Drupal\Core part of the name.

If those classes where the failure occurred were part of the typed_data module, they would be named beginning with \Drupal\typed_data.

The system_post_update_add_langcode_to_all_translatable_config() update function was added by 🐛 Require `langcode: …` only for simple config that contains translatable values Active . Because that issue is still open and seems to have caused some problems, I would start by commenting in that issue and posting your error. You can link to this issue too. The people who worked on that issue might have a better idea of what is happening here.

It would also be useful to add what version of core you were updating from and what version you were updating to. If composer is also updating other modules in the process, it would be useful to mention which modules were listed as being updated - your composer output would show this.

Also, did you check the watchdog to see if the errors are logged like it said?

Hi TR,

I'm admittedly grasping at straws.

I saw "TypedData" and Google sent me here.

I'm familiar with your work on Ubercart.

Please point me in a different direction and I'll go there.

- cheers

No longer postponed. I rebased onto 11.x

Why do you think it has anything to do with this module? None of your error messages refer to any code in this module, and the failure occurred when updating the system module which is part of Drupal core ...

Automatically closed - issue fixed for 2 weeks with no activity.

Automatically closed - issue fixed for 2 weeks with no activity.

@DamienMcKenna Removed phpcs:ignoreFile and fix with the relevant changes.

joshuautley → created an issue.

Automatically closed - issue fixed for 2 weeks with no activity.

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

Pretty sure this is fixed with 🐛 Logging is happening even with debugging off Fixed -- they were seeing the logging error the other way.

Good catch. Committed!

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

Merged the PU bot proposal. As there was no other substantive work done here, no other credit.

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

@Glottus thanks for your response - have you tried merge request !3 already, or do you mean with "those pieces above" the hints from #13?

When MR3 doesn't work either, feel free to directly set this back to "Needs work".

Rebased.

quietone → created an issue.

Double checked the performance pipeline on 11.x and it's down to 8m30 now with the combination of this and 📌 Consolidate Umami performance tests Fixed , was previously closer to 13 minutes.

https://git.drupalcode.org/project/drupal/-/pipelines/235402

#75 Thank you!

I've been holding off dealing with this issue for a while now and finally got the energy to tackle it again. Once I isolated the error and Googled it, found this thread, and implemented the following with success!

composer require 'drupal/rules:^4.0' 'drupal/typed_data ^2.1'

vendor/bin/drush cache:rebuild

Automatically closed - issue fixed for 2 weeks with no activity.

Automatically closed - issue fixed for 2 weeks with no activity.

bradjones1 → opened merge request !11

bradjones1 → created an issue.

Ready for review.

Mingsong → opened merge request !70

Links in core support attributes, one of which is class

Could we just put a class attribute in the menu links (where they live in various core modules) and use that, rather than a new property

This is how link attributes module works

If people want to modify they can use the discovered alter hook ?

So quiz.feedback.type.end and quiz.feedback.type.question can't be fully validated because part of it's schema comes from rules

and

quiz.type.quiz has a core schema gap around enforced dependencies

With D7 approaching EOL soon I've started the process of triaging the D7queue here. Since there hasn't been any movement on this going to close out.

With D7 approaching EOL soon I've started the process of triaging the D7queue here. Since there hasn't been any movement on this going to close out.

With D7 approaching EOL soon I've started the process of triaging the D7queue here. Since there hasn't been any movement on this going to close out.

With D7 EOL approaching this needed part of one of the few last release of D7 for quiz moduel?

With D7 approaching EOL soon I've started the process of triaging the D7queue here. Since there hasn't been any movement on this going to close out.

With D7 approaching EOL soon I've started the process of triaging the D7queue here. Since there hasn't been any movement on this going to close out.

Very strange. Updating from 10.2.7 to 10.3.1 seems to go ok with updb on my local development environment but errors out with the assertionerror on lightnight core versions in the cloud hosting environment. I've tried to apply this patch but it fails.

Set up an MR in a sandbox issue to change the cache target to point back to the MR's own jobs - this is because the actual change here restricts the artificat download to only core branches, which means the cache is always empty until we actually commit this.

phpstan: https://git.drupalcode.org/project/drupal/-/jobs/2245377
cspell: https://git.drupalcode.org/project/drupal/-/jobs/2245381

And the actual cache warming job itself. https://git.drupalcode.org/project/drupal/-/jobs/2245376

The cache warming job also fetches its own cache, because this will save CPU cycles on the commit runs - then it'll write a new cache based on the changes. We don't have to do this, but it'll mean the updated files are available much quicker.

We will probably want a follow-up to remove the verbose output from the jobs, but I think it's worth keeping that until we see it actually working after commit.

brunodbo → changed the visibility of the branch 3165072-split-purgers-by to active.