avpaderno → created an issue.
For what I recall, the default database credentials used by DDEV are always the same, independently from the project. After ddev start, ddev describe will report the database credentials, which is helpful in the case the project uses different credentials.
I am closing this issue, which was created for a project version compatible with a Drupal release no longer supported. Feel free to re-open the issue, if it is still relevant for a project version compatible with a supported Drupal release.
I am closing this issue because there has not been any follow-up action as described in How to become project owner, maintainer, or co-maintainer → from the person who opened this offer.
I am closing this issue because there has not been any follow-up action as described in How to become project owner, maintainer, or co-maintainer → from the person who opened this offer.
I am closing this issue because there has not been any follow-up action as described in How to become project owner, maintainer, or co-maintainer → from the person who opened this offer.
I am closing this issue because there has not been any follow-up action as described in How to become project owner, maintainer, or co-maintainer → from the person who opened this offer.
I am closing this issue because there has not been any follow-up action as described in How to become project owner, maintainer, or co-maintainer → from the person who opened this offer.
I am closing this issue because there has not been any follow-up action as described in How to become project owner, maintainer, or co-maintainer → from the person who opened this offer.
I am closing this issue because there has not been any follow-up action as described in How to become project owner, maintainer, or co-maintainer → from the person who opened this offer.
I am closing this issue because there has not been any follow-up action as described in How to become project owner, maintainer, or co-maintainer → from the person who opened this offer.
I am closing this issue, since it has been created about three years ago, and no maintainer has been successfully added using this issue.
I am closing this issue, since it has been created about three years ago, and no maintainer has been successfully added using this issue.
I am closing this issue, since it has been created about three years ago, and no maintainer has been successfully added using this issue.
I am closing this issue, since it has been created about three years ago, and no maintainer has been successfully added using this issue.
I am closing this issue, which was created for a project version compatible with a Drupal release no longer supported. Feel free to re-open the issue, if it is still relevant for a project version compatible with a supported Drupal release.
I am closing this issue, since it has been created about three years ago, and no maintainer has been successfully added using this issue.
I am closing this issue because there has not been any follow-up action as described in How to become project owner, maintainer, or co-maintainer → from the person who opened this offer.
I am closing this issue because there has not been any follow-up action as described in How to become project owner, maintainer, or co-maintainer → from the person who opened this offer.
@ndf Are you still interested to be added as maintainer of this project?
(For project moderators who can access this page: https://www.drupal.org/admin/people/advanced?name_op=%3D&name=Ignigena&m... → .)
(For project moderators who can access these pages: https://www.drupal.org/admin/people/advanced?name_op=%3D&name=bmeme&mail... → , https://www.drupal.org/admin/people/advanced?name_op=%3D&name=g0blin79&m... → .)
I’m fine with releasing a version of the module that doesn’t cover security updates.
Even if you would create a pre-release, or not create a release, project moderators will not add you as co-maintainer for a project that is covered by the security advisory policy.
Basing on the code used by Formatter::getObjectGitUrl() and Branch::getSlug(), this is probably an issue caused by the slug value stored for each Drupal core branch.
This does not seem to happen for Drupal 11 documentation pages, for example AccessAwareRouter: In that page, the View on git.drupalcode.org link is https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Routing%21AccessAwareRouter.php/class/AccessAwareRouter/11.x.
It still not the correct link, which should instead be https://git.drupalcode.org/project/drupal/-/blob/11.0.x/core/lib/Drupal/Core/Routing/AccessAwareRouter.php?ref_type=heads, for example, because the 11.x branch is the main branch, not a branch for the Drupal 11 release.
As a side note, I noticed that the View on git.drupalcode.org link is preceded by an icon, on Drupal 11 pages but not on Drupal 10 or Drupal 9 pages.
avpaderno → created an issue.
The page linked in the issue summary now shows methods and properties.
Without content to review, this request can only be closed. Feel free to re-open it after posting content on drupal.org, committing code in a project, or creating a merge request for a project, for example.
Without content to review, this request can only be closed. Feel free to re-open it after posting content on drupal.org, committing code in a project, or creating a merge request for a project, for example.
Without content to review, this request can only be closed. Feel free to re-open it after posting content on drupal.org, committing code in a project, or creating a merge request for a project, for example.
I confirmed the account on July 17, 2025, but I forgot to close this issue.
Without content to review, this request can only be closed. Feel free to re-open it after posting content on drupal.org, committing code in a project, or creating a merge request for a project, for example.
Without content to review, this request can only be closed. Feel free to re-open it after posting content on drupal.org, committing code in a project, or creating a merge request for a project, for example.
Without content to review, this request can only be closed. Feel free to re-open it after posting content on drupal.org, committing code in a project, or creating a merge request for a project, for example.
The typical path to confirming users usually involves reviewing the content created on this site. In this case, you have not created any content except this post, so there is no content to review.
I am postponing this issue, for now. After you have posted some content on this site, you may want to add a comment to this issue to request a new review.
Please see Become a confirmed user for information on the role and how it is granted.
Thank you and welcome!
Drupal 9 is no longer supported. Can the issue be reproduced with Drupal 11?
Welcome to drupal.org!
This site is not about Java coding. It is about Drupal, which is written in PHP.
mably has been added as maintainer.
The only person with the Administer maintainers permission cannot be considered still active on drupal.org. I am going to add mably as maintainer.
Hello Pushpinder,
I am contacting you because Steven ( https://www.drupal.org/u/bluegeek9 → ) offered to become co-maintainer for Password Separate Form ( https://www.drupal.org/project/change_pwd_page → ), a project for which you are maintainer.
May you post a comment on https://www.drupal.org/project/projectownership/issues/3537250 📌 Offerer to co-maintain Password Separate form Active about accepting or declining the offer? Please do not reply via email; we need a reply on the offer issue.
Without a comment posted on that issue in the next 14 days, Steven will be probably made co-maintainer.Project moderators will not remove the existing maintainers/co-maintainers; the project owner will not be replaced either. Maintainers cannot change the project owner; co-maintainers/maintainers can only be removed/added by people who have the permission to administer co-maintainers/maintainers.
I am contacting all the people who can administer co-maintainers/maintainers for the project.
As last note: This offer is about being co-maintainer, which is different from being a maintainer. A co-maintainer is a person who does not have all the drupal.org permissions on a project. Even though being co-maintainers could mean having just a single permission, we expect a co-maintainer to have the following permissions on the project: Write to VCS, Edit project, Maintain issues, Administer releases.
If there is any reason for not giving all those permissions, please explain that on https://www.drupal.org/project/projectownership/issues/3537250 📌 Offerer to co-maintain Password Separate form Active . We need this to know it was intentional and not a misunderstanding on what the offer required.Best regards,
Alberto Paderno
-- Drupal.org project moderator
-- Drupal.org site moderator
The status is Postponed because we are waiting for a reply.
Please post a comment after 14 days, if your offer has not been declined. It will show you are still interested in maintaining this project and it will serve as reminder an action is required for this offer.
Only one of the people with the Administer maintainers permissions logged in at least once in the past six months. I am going to contact him.
Hello Scott,
I am contacting you because Andy ( https://www.drupal.org/u/andyf → ) offered to become maintainer for polly ( https://www.drupal.org/project/polly → ), a project you created for which you are project owner and maintainer.
May you post a comment on https://www.drupal.org/project/projectownership/issues/3538556 💬 Offering to maintain this project Active about accepting or declining the offer? Please do not reply via email; we need a reply on the offer issue.
Without a comment posted on that issue in the next 14 days, Andy will be probably made maintainer.Project moderators will not remove the existing maintainers/co-maintainers; the project owner will not be replaced either. Maintainers cannot change the project owner; co-maintainers/maintainers can only be removed/added by people who have the permission to administer co-maintainers/maintainers.
As last note: This offer is about being maintainer, which is different from being co-maintainer. A maintainer is a person who has all the drupal.org permissions on a project: Write to VCS, Edit project, Administer maintainers, Maintain issues, Administer releases. A person who does not have all those permissions is a co-maintainer.
If there is any reason for not giving all those permissions, please explain that on https://www.drupal.org/project/projectownership/issues/3538556 💬 Offering to maintain this project Active . We need this to know it was intentional and not a misunderstanding on what the offer required.Best regards,
Alberto Paderno
-- Drupal.org project moderator
-- Drupal.org site moderator
The status is Postponed because we are waiting for a reply.
Please post a comment after 14 days, if your offer has not been declined. It will show you are still interested in maintaining this project and it will serve as reminder an action is required for this offer.
Only scottalan can be considered still active on drupal.org. I am going to contact him.
Hello Bryan,
I am contacting you because Vadym ( https://www.drupal.org/u/abramm → ) offered to become maintainer for Tombstones ( https://www.drupal.org/project/tombstones → ), a project you created for which you are project owner and sole maintainer.
May you post a comment on https://www.drupal.org/project/projectownership/issues/3536568 💬 Offering to maintain Tombstones Active about accepting or declining the offer? Please do not reply via email; we need a reply on the offer issue.
Without a comment posted on that issue in the next 14 days, Vadym will be probably made maintainer.Project moderators will not remove the existing maintainers/co-maintainers; the project owner will not be replaced either. Maintainers cannot change the project owner; co-maintainers/maintainers can only be removed/added by people who have the permission to administer co-maintainers/maintainers.
As last note: This offer is about being maintainer, which is different from being co-maintainer. A maintainer is a person who has all the drupal.org permissions on a project: Write to VCS, Edit project, Administer maintainers, Maintain issues, Administer releases. A person who does not have all those permissions is a co-maintainer.
If there is any reason for not giving all those permissions, please explain that on https://www.drupal.org/project/projectownership/issues/3536568 💬 Offering to maintain Tombstones Active . We need this to know it was intentional and not a misunderstanding on what the offer required.Best regards,
Alberto Paderno
-- Drupal.org project moderator
-- Drupal.org site moderator
The status is Postponed because we are waiting for a reply.
Please post a comment after 14 days, if your offer has not been declined. It will show you are still interested in maintaining this project and it will serve as reminder an action is required for this offer.
avpaderno → made their first commit to this issue’s fork.
This is quite a broad question. There is documentation on how to upgrade from Drupal 8 to a supported Drupal release. We cannot repeat what that documentation already says.
If you have a more specific question, that would be probably be answered.
As a side note, there is no need to add your name to every post's title, nor describe who you are in every post. That could be taken as tentative of spamming.
Thank you for applying!
Please read Review process for security advisory coverage: What to expect → for more details and Security advisory coverage application checklist → to understand what reviewers look for. Tips for ensuring a smooth review → gives some hints for a smoother review.
The important notes are the following.
- If you have not done it yet, enable GitLab CI for the project, and fix what reported from the phpcs job. This help to fix most of what reviewers would report.
- For the time this application is open, only your commits are allowed. No other people, including other maintainers/co-maintainers can make commits.
- The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status won't be changed by this application.
- Nobody else will get the permission to opt projects into security advisory policy. If there are other maintainers/co-maintainers who will to get that permission, they need to apply with a different module.
- We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.
To the reviewers
Please read How to review security advisory coverage applications → , Application workflow → , What to cover in an application review → , and Tools to use for reviews → .
The important notes are the following.
- It is preferable to wait for a Code Review Administrator before commenting on newly created applications. Code Review Administrators will do some preliminary checks that are necessary before any change on the project files is suggested.
- Reviewers should show the output of a CLI tool → only once per application. The configuration used for these tools needs to be the same configuration used by GitLab CI, stored in the GitLab Templates repository.
- It may be best to have the applicant fix things before further review.
For new reviewers, I would also suggest to first read In which way the issue queue for coverage applications is different from other project queues → .
Thank you for applying!
Please read Review process for security advisory coverage: What to expect → for more details and Security advisory coverage application checklist → to understand what reviewers look for. Tips for ensuring a smooth review → gives some hints for a smoother review.
The important notes are the following.
- If you have not done it yet, enable GitLab CI for the project, and fix what reported from the phpcs job. This help to fix most of what reviewers would report.
- For the time this application is open, only your commits are allowed. No other people, including other maintainers/co-maintainers can make commits.
- The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status won't be changed by this application.
- Nobody else will get the permission to opt projects into security advisory policy. If there are other maintainers/co-maintainers who will to get that permission, they need to apply with a different module.
- We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.
To the reviewers
Please read How to review security advisory coverage applications → , Application workflow → , What to cover in an application review → , and Tools to use for reviews → .
The important notes are the following.
- It is preferable to wait for a Code Review Administrator before commenting on newly created applications. Code Review Administrators will do some preliminary checks that are necessary before any change on the project files is suggested.
- Reviewers should show the output of a CLI tool → only once per application. The configuration used for these tools needs to be the same configuration used by GitLab CI, stored in the GitLab Templates repository.
- It may be best to have the applicant fix things before further review.
For new reviewers, I would also suggest to first read In which way the issue queue for coverage applications is different from other project queues → .
The person who confirmed the account has not been logged. It means the account has been confirmed more than five years ago, probably at the time the existing, but not recent, accounts were automatically confirmed.
Creating a project on drupal.org does not require a confirmed account. Being able to make commits on drupal.org repositories just requires to visit a page to confirm the Git username and accept the terms of use.
None of the people who has the Administer maintainers permissions logged in at least once in the past 365 days. I am going to add abramm as maintainer.
I apologize for the delay in handling this. I am verifying the maintainers are still active on drupal.org.
bryjbrown logged in at least once in the past 14 days.
I apologize for the delay in handling this. I will contact the maintainers tomorrow.
Hello Ivan,
I am contacting you because Darren ( https://www.drupal.org/u/dfisher → ) offered to become co-maintainer for Domain Country Path ( https://www.drupal.org/project/country_path → ), a project you created for which you are maintainer.
May you post a comment on https://www.drupal.org/project/projectownership/issues/3537331 📌 Offering to co-maintain Domain Country Path Active about accepting or declining the offer? Please do not reply via email; we need a reply on the offer issue.
Without a comment posted on that issue in the next 14 days, Darren will be probably made co-maintainer.Project moderators will not remove the existing maintainers/co-maintainers; the project owner will not be replaced either. Maintainers cannot change the project owner; co-maintainers/maintainers can only be removed/added by people who have the permission to administer co-maintainers/maintainers.
As last note: This offer is about being co-maintainer, which is different from being a maintainer. A co-maintainer is a person who does not have all the drupal.org permissions on a project. Even though being co-maintainers could mean having just a single permission, we expect a co-maintainer to have the following permissions on the project: Write to VCS, Edit project, Maintain issues, Administer releases.
If there is any reason for not giving all those permissions, please explain that on https://www.drupal.org/project/projectownership/issues/3537331 📌 Offering to co-maintain Domain Country Path Active . We need this to know it was intentional and not a misunderstanding on what the offer required.Best regards,
Alberto Paderno
-- Drupal.org project moderator
-- Drupal.org site moderator
The status is Postponed because we are waiting for a reply.
Please post a comment after 14 days, if your offer has not been declined. It will show you are still interested in maintaining this project and it will serve as reminder an action is required for this offer.
I am going to contact the only maintainer who logged in at least once in the past year. The project owner can be considered no longer active on drupal.org, since he has last logged in more than a year and a half ago.
The project link is https://www.drupal.org/project/country_path → .
Hello Mu'tasim,
I am contacting you because Brian ( https://www.drupal.org/u/realityloop → ) offered to become maintainer for Reserved Paths ( https://www.drupal.org/project/reserved_paths → ), a project you created for which you are project owner and sole maintainer.
May you post a comment on https://www.drupal.org/project/projectownership/issues/3537273 💬 Maintainer/co-maintainer request Active about accepting or declining the offer? Please do not reply via email; we need a reply on the offer issue.
Without a comment posted on that issue in the next 14 days, Brian will be probably made maintainer.Project moderators will not remove the existing maintainers/co-maintainers; the project owner will not be replaced either. Maintainers cannot change the project owner; co-maintainers/maintainers can only be removed/added by people who have the permission to administer co-maintainers/maintainers.
As last note: This offer is about being maintainer, which is different from being co-maintainer. A maintainer is a person who has all the drupal.org permissions on a project: Write to VCS, Edit project, Administer maintainers, Maintain issues, Administer releases. A person who does not have all those permissions is a co-maintainer.
If there is any reason for not giving all those permissions, please explain that on https://www.drupal.org/project/projectownership/issues/3537273 💬 Maintainer/co-maintainer request Active . We need this to know it was intentional and not a misunderstanding on what the offer required.Best regards,
Alberto Paderno
-- Drupal.org project moderator
-- Drupal.org site moderator
The status is Postponed because we are waiting for a reply.
Please post a comment after 14 days, if your offer has not been declined. It will show you are still interested in maintaining this project and it will serve as reminder an action is required for this offer.
mutasim al-shoura logged in at least once, this week.
The project link is https://www.drupal.org/project/reserved_paths → .
I will handle this in about a hour.
I will handle this in about a hour.
I changed ownership as requested.
I changed ownership as requested.
Nothing is wrong with the scope of this issue and I would rather not change it after 14 comments.
Since there have not been replies here nor via email, I made amateescu the new project owner.