#Novice

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

I closed the MR so that anyone willing to tackle this issue may start the process from the very beginning.
To be honest though, I did try to find the comment described in the issue summary but couldn't find it at all in the code. Maybe something is off here or was it just me?

vensires → closed merge request !11619

Thanks for working to improve Drupal.

This is for the Drupal 7 Form API reference. Since Drupal 7 is past end-of-life this is now a "won't fix".

Work on documentation for form elements for supported versions of Drupal is at 📌 [meta] Move/Create Form Element Documentation Active and 🌱 [Meta] Improve documentation for Render and Form Elements Active .

Thanks for working to improve Drupal.

This is for the Drupal 7 Form API reference. Since Drupal 7 is past end-of-life this is now a "won't fix".

Work on documentation for form elements for supported versions of Drupal is at 📌 [meta] Move/Create Form Element Documentation Active and 🌱 [Meta] Improve documentation for Render and Form Elements Active .

Hello @everyone
I also tried to change the title using git (by changing the commit message ), but sadly, that is not working, and I don't have access to change it directly at MR

Hello @prudloff

I have updated the doc block with the provided suggestion
Please review and suggest if any other changes are required
Moving the issue to Need Review

adwivedi008 → changed the visibility of the branch 3515406-wrong-return-type to active.

adwivedi008 → changed the visibility of the branch 3515406-wrong-return-type to hidden.

Closing as there is nothing in core that would cause this bug after creating a new content type.

Feel free to reopen with clear steps to reproduce, or open a new feature request for the addition of the permissions message.

I performed Novice Triage on this issue. I am leaving the Novice tag on this issue because I think the requested changes from @quietone and confirmed by @joachim are clear. As well, we can confirm the uses again and update the issue summary to clarify how we found the changes.

I am removing the Novice tag from this issue because it was hard to me to determine the novice task on the issue.

I’m using this documentation as a source: https://www.drupal.org/community/contributor-guide/task/triage-novice-is... →

I performed Novice Triage on this issue. I am leaving the Novice tag on this issue because there is a clearly defined task for resolution. The issue summary could use an update as well.

There were some test failures in the merge request, but I think those are false positives.

I am removing the Novice tag from this issue because I think the resolution is ambiguous with the does not break anything comment.

I’m using this documentation as a source: https://www.drupal.org/community/contributor-guide/task/triage-novice-is... →

I am removing the Novice tag from this issue because I think it is a bit confusing for a first-time issue.

I’m using this documentation as a source: https://www.drupal.org/community/contributor-guide/task/triage-novice-is... →

This doesn't feel like a novice issue to me - I'm removing the tag.

-mike

I performed Novice Triage on this issue. I am leaving the Novice tag on this issue based on @smustgrave's triage. We should focus on the issue summary update based on recent work and resolving the code review.

Thanks @smustgrave! I'll definitely start looking into more advanced issues.

Seems pretty straight forward

@sandip poddar looking at your post history, could probably elevate past novice tagged issues. Thanks!

Seems pretty straight forward and checking locale_translation_batch_fetch_download $project only seems to be used like

$source = $sources[$project][$langcode];

Thanks! Merged

Hello, @prudloff
I've created an MR please check and review.

Thank you!

The page referred to is for Drupal 7, which is EOL. And for currently supported versions of Drupal, there is Configuration API → documentation.

Please review the changes.

I am working on it.

Fixed stylelint.

Hi @joachim,

I’ve updated the comment to reflect that setRebuild(TRUE) is what triggers the behavior, as you suggested, while preserving the original intention of explaining how to get this behavior from a DX perspective.

I also rebased the branch onto the latest 11.x since it was many commits behind, to ensure the pipeline runs accurately.

Let me know if anything else needs adjusting!

Ok I'll move this to "Fixed", if anyone finds any additional issues, please let me know and I'll re-open the ticket

Merged to the main branch (8.x-4.x), I'll move this to "Fixed" for now, if anyone is still having validation issues, please let me know and I'll reopen the task.

Hi @quietone

The previous MR (!8124) was quite outdated and significantly behind the 11.x branch. I initially attempted a rebase, but due to a large number of conflicts, it became difficult to manage cleanly.

To ensure a clean and conflict-free update, I’ve created a new branch and opened this fresh MR (!11606) with the necessary changes, fully rebased with the latest from 11.x.

All tests are now passing. Let me know if anything else is needed!

Thanks!

I'll merge this to the main branch, this MR has some deprecation fixes that could fix other issues reported with D11 compatibility

I fixed all the issues reported in the Jobs, I'll leave it to "Needs Review" just in case someone wants to test this and get extra credits.

Let’s do that then :)

29 is following the same logic as 📌 Clean up hook implementations in the Taxonomy module Active

The pipeline ran without issues, there are some ESLINT / PHPCS / .. issues to fix, but I'll do that in another issue: https://git.drupalcode.org/project/indexing_api/-/merge_requests/4

I'll merge this MR to the 1.0.x branch and mark it as "Fixed"

danrod → closed merge request !3

Just throwing my 2cents in but I really like how 📌 Clean up hook implementations in the Taxonomy module Active got organized. Maybe can do something similar.

Seems like finally the tests have passed: https://git.drupalcode.org/project/copyscape/-/merge_requests/6 !!!

I'll leave this for review for a while, just in case anyone wants to double-check this.

@smustgrave Thanks!!
Please do consider to fix the pipeline also: https://git.drupalcode.org/issue/drupal-3477616/-/jobs/4763371#L394

Fixed, now I can't review.

Leaving tests tag as the test-only pipeline is passing when I'd expect it to fail.

@mparker17, thanks for explaining the intent.

I think the intent of this is covered with the core README.md file, which includes how to contribute. Therefore, closing.

stylelint failed.

Fixed the issue where long component names were overflowing the badge. Now, the text stays within bounds and displays correctly. Ready for review.

Updated to reflect comment #55.

Thanks @somesh1999 , I also pushed some english fixes, but it looks great, I'll merge this to the main branch and move it to "Fixed".

Thanks!

danrod → changed the visibility of the branch 3514888-replace-readme.txt-with to hidden.

This needs another adjustment to meet coding standards.

What needs to be reviewed is to review the issue that made the code changes and confirm that the documentation changes are correct and are correct English. The originating issue is a security one, and is private. That leaves reading the commit, which is 706b0006. After reading that I am not sure the changes here are accurate. The changes here use 'file path' where the originating issue uses 'file URIs', which are different things. I am setting 'needs work' for those working here to discuss that.

As a reminder, screenshots should only be added to issues that are changing the user interface. See the last paragraph at https://www.drupal.org/about/core/policies/maintainers/how-is-credit-gra... →

I'll move it to "Fixed" now, if anyone has any suggestions, please let me know and I'll re-open the issue.

I'll merge it to the main branch now because I need this file for setting up the GilabCI process, but I'll move this to "Needs Review" just in case someone has suggestions on this.

I added a composer.json file with some basic but important information:

{
  "name": "drupal/copyscape",
  "type": "drupal-module",
  "keywords": ["Drupal", "Plagiarism"],
  "description": "This module integrates the Copyscape API and checks the originality of content published.",
  "homepage": "https://git.drupalcode.org/project/copyscape",
  "authors": [
    {
      "name": "Daniel Rodriguez",
      "homepage": "https://www.drupal.org/u/danrod",
      "role": "Maintainer"
    }
  ],
  "support": {
      "issues": "https://www.drupal.org/project/copyscape",
      "source": "https://git.drupalcode.org/project/copyscape"
  },
  "license": "GPL-2.0-or-later",
  "minimum-stability": "dev",
  "require": {
    "php": "^8.1"
  }
}

What needs to be reviewed here? I see that the execution permission was removed from the file and documentation was added in the interface file:

Execution permission was removed:

Can be moved to RTBC.

I think the feedback is to change as follow,

- @trigger_error('typedConfigManager() is deprecated in drupal:11.2.0 and is removed from drupal:12.0.0. This method is no longer in use instead $this->typedConfigManager to be used. See https://www.drupal.org/project/drupal/issues/3477616', E_USER_DEPRECATED);
+ @trigger_error('typedConfigManager() is deprecated in drupal:11.2.0 and is removed from drupal:12.0.0. The replacement is to use the $this->typedConfigManager as is done in ::validateForm(). See https://www.drupal.org/project/drupal/issues/3477616', E_USER_DEPRECATED);

charlliequadros → changed the visibility of the branch 2873447-views-rest-export to hidden.

Hi @smustgrave

Sorry, but I still don’t fully understand what I need to do. Could you clarify the next step?

Either way, if it’s not possible to explain right now, I’ll keep an eye on this ticket to see how the issue gets resolved.

Working on this

The file StreamWrapperManagerInterface.php had execution permission, as shown in the image.

I have removed this permission. Could someone review it?

This is already implemented in the file. The datetime field’s date and the file_uri field’s url are handled the same way as daterange in tests/src/Kernel/EcosystemSupport/FieldTypeSupportTest.php.

'datetime' => [  
  // 🐛 Core bug: this is the computed equivalent of `value`, should be marked internal.  
  // @todo Give this similar treatment as `daterange` in https://www.drupal.org/project/experience_builder/issues/3512853  
  'date' => FALSE,  
],  
'file_uri' => [  
  // 🐛 Core bug: this is the computed equivalent of `value`, should be marked internal.  
  // @todo Give this similar treatment as `daterange` in https://www.drupal.org/project/experience_builder/issues/3512853  
  'url' => FALSE,  
],  

Let me know if anything else is needed. Thanks!

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

I think this looks okay now. Not a native English speaker so might have some grammar issues.

Marked 'date' (DateTimeItem) and 'url' (FileUriItem) properties as internal
Created DateTimeItemOverride.php to override DateTimeItem and marked the date property as internal.
Updated FileUriItemOverride.php (already present) to mark the url property as internal.
Please review

The change is simple and LGTM. Seems the error is unrelated through im not able to rerun the job?

This is referring to Drupal 7 book style documentation, which is outdated.

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

The page is now outdated and is in an archive waiting removal.

See 📌 Migrate documentation into the new system Active

@sidharrell, thanks for updating the documentation.

I think this can be closed as fixed.

Can put back into review for more eyes but before RTBC summary will have to match

No worries. So might help to look at the reference issue this was created from.

Not a layout builder expert to say what’s needed or not but the summary needs to match the MR. Helps committers quickly understand a ticket

If it’s determined nothing is needed then the summary could include your findings and just a simple solution of remove the todo

Hi @smustgrave,

Apologies if I might be misunderstanding something here, but I just want to clarify the intent behind this change to ensure I'm following the best approach. I'm still getting started with contributing to Drupal, and I really appreciate your guidance.

The issue summary suggests that handleEntityDelete() should be updated to use isLayoutCompatibleEntity(), but after reviewing the implementation, I noticed that removeByLayoutEntity($entity) does not fail if the entity is not layout-compatible. Instead, it simply attempts to clean up inline_block_usage, setting layout_entity_id and layout_entity_type to NULL if applicable. If no matching records exist, nothing happens, which makes me wonder if the extra check is truly necessary.

I just want to make sure I'm not missing something here:

• Was there a specific issue that required adding isLayoutCompatibleEntity()?
• Is there any scenario where calling removeByLayoutEntity() directly could cause unintended side effects?

If the check is needed for a reason I’m not seeing, I’ll be happy to update it accordingly. Otherwise, removing it might help simplify the logic while still ensuring the cleanup happens.

Again, thanks for your patience and feedback—I really appreciate learning from this process!

So reading the issue summary and title

update InlineBlockEntityOperations::handleEntityDelete() to use isLayoutCompatibleEntity()

Still seems to be needed.