For these applications, we need a project where, in at least a branch, most of the commits (but preferably all the commits) have been done from the person who created the application.
The purpose of these applications is reviewing a project to understand what the person who applies understands about writing secure code which follows the Drupal coding standards and correctly uses the Drupal API, not what all the project maintainers collectively understand about those points.
Do you have a project for which most of the commits have been done by you in at least a branch? It also needs to contain enough PHP code.
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 → .
Check also https://git.drupalcode.org/issue/bakery-2931396/-/jobs/5644279: It reports an Unexpected identifier "LanguageManagerInterface", expecting ")" error, which should be fixed.
That error is what causes the errors shown by PHPStan in https://git.drupalcode.org/issue/bakery-2931396/-/jobs/5644281.
Thank you for your help! In the live preview, it works well.
Only dhiraj bhagat has the Administer maintainers permission, and he logged in at least once in the past six months. I will contact him when I get back to my computer.
Thank you for the changes!
Now the arrow appears smaller in some cases.
I guess it depends on the space left for the arrow.
In which way is this question related to Drupal? Are you using Drupal for your app? How?
Without more details, this is a rather broad question.
This is a rather broad question. Is there anything that you do not understand about modules?
As a side note, there is no need to put your name in the title.
(I apologize for bumping this issue. I deleted spam comments.)
Thank you! The changes have been committed.
I am going to restore the issue summary, which was removed from a previous edit.
harder, but still a case to be made, because string references will still exist on the issues
When an issue tag is deleted, the view listing all the issues using it will show no issues. The issues will still see a comment showing the issue tag has been added, but that comment will not link back to the issue tag. That should not be worse than keeping the issue tag and have a view showing all the issues using it.
(The view shows only issue tags whose description is more than five characters.)
I know the tags are not hard-coded, but if you want to avoid showing some tags from that view, without editing them, that is only possible by changing the view.
If editing the issue tags to remove the description is fine, then editing the view is not necessary.
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.
This is the issue queue for a PHP extension which runs on Drupal 7.
This is the issue queue for a PHP extension thought for Drupal 7. It is not the Drupal core issue queue.
I reverted the edit, since documentation pages are not for advertising what somebody is doing.
I will keep an eye on that account's activities.
The view is defined in the features/drupalorg_documentation/drupalorg_documentation.views_default.inc file.
Deleting issue tags seems simpler than filtering them out from that view's output. If there are semi-rude terms, should not those be edited or deleted directly?
Views are imported as features.
I added the feed to Planet Drupal ( https://www.drupal.org/aggregator/sources/2093 → ).
I added danrod as co-maintainer.
(I apologize: I read the issue as removing the issue tags, not removing them from the documentation guide.)
I added tobiasb as co-maintainer.
@danrod Are you still interested in co-maintaining this project?
I take this can be considered fixed.
@vladimiraus Are you still interested in maintaining this project?
There are now two articles posted on 2025.
@tobiasb Are you still interested in co-maintaining this project?
avpaderno → changed the visibility of the branch 3531148-the-settings-for to hidden.
@jan I changed the default branch.
This is the message I sent.
Hello Robin,
I am contacting you because Matthijs ( https://www.drupal.org/u/matthijs → ) offered to become maintainer for Lightgallery ( https://www.drupal.org/project/lightgallery → ), 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/3519648 💬 Offering to become project owner/maintainer 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, Matthijs 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/3519648 💬 Offering to become project owner/maintainer 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 has been changed 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.
robin.ingelbrecht logged in at least once in the past two months. I am going to contact him once I go back to my computer. (The project link is https://www.drupal.org/project/lightgallery → .)
I confirmed the account because of 🐛 Sort Icon in Drupal Content view is in wrong direction Active , which has been created a year ago.
Why is the 5xx error returned only in one out of three cases? Since the request is for the same documentation page, should not the error be returned in all the cases, or in none of the cases?
There are merge conflicts that need to be fixed.
avpaderno → changed the visibility of the branch 3529479-check-only-project-files to hidden.
avpaderno → created an issue.
This type of issues needs to be opened in the project issue queue. They can be moved on the Drupal.org project ownership queue after 14 days, if none of the maintainers replied.
Remember to change status, when the project is ready for review, as in this queue Active means Don't review yet the project I am using for this application.
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 → .
avpaderno → created an issue.
The status is also for the issue summary that needs to be updated.
I readded the feed ( https://www.drupal.org/aggregator/sources/2092 → ), but it does not show any article.
These applications are for giving people the Drupal role that allows to opt projects into security advisory coverage. This is the only reason we review projects.
You can already opt projects you maintain into security advisory coverage.
This issue does not seem for the Seven theme if, like #2113931: File Field design update: Upload field. → , would require changing also files that are part of Drupal core.
If I understand correctly, the issue is the missing space between the fieldset title and the next form element. I could not reproduce this.
Probably, this was no longer an issue by the time comment #19 🐛 Plural variants translation fieldset display could be improved for mobile Active was posted.
It seems the <span> element is no longer necessary.
I tested https://onecompiler.com/html/43mxzgq9y on Google Chrome, Microsoft Edge, and Firefox: The underline is shown in all the browsers. The only difference I could see is that on Firefox the underline is shown for the arrow too.
With child issues in three different projects, this is not a Seven issue.