Actually, since there are 59 sites using the 2.0.0-alpha7 release, I would prefer the changes are backward compatible, which means the Key module cannot be a hard dependency, or those sites will not be able to update.
I know that alpha releases do not need to be backward compatible, but I would rather avoid disruptions on those sites.
My idea was to wait to create a pre-release, to avoid such changes, but the pre-release was created, and we cannot turn back.
No posts/comments were unpublished.
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!
I want to be maintainer/co-maintainer of a project, but I do not want to be considered unethical by security focused community members.
There is enough to write on the subject that four lines could not be enough for a summary.
I cannot even say that being considered unethical by security focused community members is one of the reasons for which people do not ask to being maintainer/co-maintainer of an existing project and they instead create their own project. Differently, the other points in that section are effectively reasons for which somebody did not want to be maintainer, or for which somebody was considering not to offer to be maintainer/co-maintainer.
The "Things you do not have to worry about" section does not address the ethical concerns of committing a social engineering and supply chain attack to inject oneself as a new owner.
It does not contain anything about that topic because that is not the purpose of that section.
The parts in that section can be rewritten as follows.
- I want to be maintainer/co-maintainer of a project, but I do not like how it is written, and I do not want to learn the old code.
- I want to be maintainer/co-maintainer of a project, but I do not want to support existing users.
- I want to be maintainer/co-maintainer of a project, but I do not want to be associated with a failed project.
If what added in that section, can be rephrased like that, it does not probably belong to that section.
Also, the ethical concerns of committing a social engineering and supply chain attack to inject oneself as a new owner is a topic relevant for everybody who is a project maintainer, independently from being added as project maintainer by following Offering to become a project owner, maintainer, or co-maintainer.
That seems more a topic for
Managing a drupal.org theme, module, or distribution project →
.
I wasn't aware of a minimum amount of code required to be included in security coverage.
The minimum amount of code is not required for the project to be covered by the security advisory policy. It is required for you to get the permission to opt projects into security advisory coverage.
We do not change projects status; we give to the person who applies a new drupal.org role. Since that is done by reviewing code, the project needs to have a minimum amount of code.
Would it be possible to recruit a maintainer who does have the experience so it can be covered?
Any maintainer who is able to opt projects into security advisory coverage can set a project to be covered by the security advisory policy. That will not give you the permission to opt the projects you create into security advisory coverage, though.
Furthermore, if you add as maintainer a person who can opt projects into security advisory coverage, that person will be contacted from the Drupal Security Team for any security issue found in the project. That is probably a responsibility somebody who is not interested in maintaining the project is willing to take.
Usually, after reviewing a project, we allow the developer to opt projects into security advisory coverage. This project is too small for us and it doesn't contain enough PHP code to really assess your skills as developer.
Have you created any other project on drupal.org (module, theme, distribution) we could instead review? The project needs to have most of the commits (preferable all the commits) done by you.
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, you should enable GitLab CI for the project and fix the PHP_CodeSniffer errors/warnings it reports.
- For the time this application is open, only your commits are allowed.
- 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 will not be changed by this application; once this application is closed, you will be able to change the project status from Not covered to Opt into security advisory coverage. This is possible only 14 days after the project is created.
Keep in mind that once the project is opted into security advisory coverage, only Security Team members may change coverage. - Only the person who created the application will get the permission to opt projects into security advisory coverage. No other person will get the same permission from the same application; that applies also to co-maintainers/maintainers of the project used for the application.
- 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 project moderator before posting the first comment on newly created applications. Project moderators 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.
- 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 following code does not throw any deprecation warning, on PHP 8.3.
<?php
declare(strict_types=1);
function add_title(object $node, string $title='') {
$node->title = $title;
$node->changed = time();
}
error_reporting(E_ALL | E_DEPRECATED);
$node = new stdClass();
$node->nid = 10;
add_title($node, "This is my new node");
The following code will throw deprecation warnings.
<?php
declare(strict_types=1);
class Node {}
function add_title(object $node, string $title='') {
$node->title = $title;
$node->changed = time();
}
error_reporting(E_ALL | E_DEPRECATED);
$node = new Node();
$node->nid = 10;
add_title($node, "This is my new node");
PHP Deprecated: Creation of dynamic property Node::$nid is deprecated in /home/avpaderno/.test/test_hinting.php on line 15
PHP Deprecated: Creation of dynamic property Node::$title is deprecated in /home/avpaderno/.test/test_hinting.php on line 8
PHP Deprecated: Creation of dynamic property Node::$changed is deprecated in /home/avpaderno/.test/test_hinting.php on line 9
Added a note about when and where to create issues to become maintainer/co-maintainer, project owner, or to take over a project namespace.
These offers need to first be created on the project issue queue, even when the person asking for more permissions is already co-maintainer or a maintainer. As per
Offering to become a project owner, maintainer, or co-maintainer →
, they can be moved in the
Drupal.org project ownership queue →
, 14 days after the offer was posted/moved in the project queue, if the offer has not been declined from other maintainers (including the project owner).
Remember to provide a link for the project page, in that case.
The tag can be added after reviewing three different project applications whose status is Needs review. That is not a manual review, so it does not count for the review bonus.
Those lines are not present in the kiosk_nav.info.yml file.
I added malcomio as co-maintainer, since 25 days now passed without any comment from asgorobets.
I do not see any reason to type-hint a variable to \stdClass; it seems rather too specific. Using object would allow to change the used class and be backward compatible.
This is the message I sent.
Hello guillaumev,
I am contacting you because Shawn ( https://www.drupal.org/u/fathershawn → ), who is already maintainer, offered to become the new project owner for Commerce Purchase Order ( https://www.drupal.org/project/commerce_purchase_order → ), a project you created for which you are project owner and maintainer.
May you post a comment on https://www.drupal.org/project/commerce_purchase_order/issues/3507014 💬 Request to become project owner 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 28 days, Shawn will be probably made the new project owner.Project moderators will not remove the existing maintainers/co-maintainers; they will leave the old project owner as project maintainer.
As last note: This is an offer to become the new project owner; it is not a request for being added as maintainer. A project owner is a project maintainer who cannot be removed from other maintainers, and who can remove all the existing maintainers/co-maintainers.
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 move this issue in the Drupal.org project ownership queue, 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 apologize: I missed out this yesterday. I will contact guillaumev now.
I am going to contact guillaumev between one hour and a half. That is two weeks before the usual, but I will ask for a reply to be given in the next four weeks.
Added a note about groups.drupal.org being on life support.
As a side note, on https://git.drupalcode.org/project/commerce_purchase_order/-/project_mem..., you are still listed as maintainer, which means that, effectively, you had all the permissions on the project, on the drupal.org side. (On git.drupalcode.org, none of the project maintainers is listed as owner, not even the project owner.) You can still do what a maintainer can do, on git.drupalcode.org side.
Apparently, not even the Recent log messages page shows when somebody has been appointed/removed as co-maintainer or maintainer.
The only person who could decide to re-add you as maintainer is the project owner. I would suggest contacting him for this (and point him to your request to be the new project owner).
Since you are offering to be the new project owner, I take you think he is no longer active on drupal.org or no longer interested in maintaining the project. In that case, you should wait to be made the new project owner.
I changed the issue title as per https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... → .
The only people with the Administer maintainers permissions are:
I would suggest contacting them and ask to post a comment on this issue.
These offers need to first be created on the project issue queue, even when the person asking for more permissions is already co-maintainer. As per
Offering to become a project owner, maintainer, or co-maintainer →
, they can be moved in the
Drupal.org project ownership queue →
, 14 days after the offer was posted/moved in the project queue, if the offer has not been declined from other maintainers (including the project owner).
Remember to provide a link for the project page, in that case.
There are no posts apart this one.
The account has been confirmed from tar_inet on February 5, 2025.
There are no posts/comments to publish.
Removed a duplicate link; improved formatting; made a sentence more generic, since every article which only mentions Drupal in passing does not fit Planet Drupal, even when the article is not about web development nor programming.
Removed the "Important issue for blogs hosted on Github" section, since this documentation page is a content guideline, not a documentation page on how to create a feed for Planet Drupal, and the linked issue is an old issue which suggests some possible workarounds for GitHub hosted feeds which could no longer apply or be necessary.
Using a view, it would also be possible to remove duplicates, I guess, or articles that do not match some criteria. It would resolve some issues that occasionally Planet Drupal have.
It would no longer be possible to re-categorize the articles added to Planet Drupal, which is what the Aggregator module allows, and which allows to move an article from Planet Drupal to Planeta Latinoamericano, for example.
The only reference to how a Planet Feed can be produced, in the Planet Drupal content guidelines, is Important issue for blogs hosted on Github → , which can be removed, since:
- It is about an issue happened time ago (more than ten years ago)
- The linked issue, #2164219: Meta: Feeds "looking" broken due to -1002 missing schema → , is described from the Planet Drupal guidelines itself as This most likely won't help
- The Planet Drupal guidelines does not put restrictions on how the content of a Planet Drupal feed is produced, but rather on its content
For the last point, I would rather not add suggestions on how a Planet Drupal feed can be produced. That can go in a different documentation guide, if it can provide enough details to be useful to somebody who wants to add their feed on Planet Drupal.
Where do I suggest that? This is my suggestion: "Your feed must have a maximum of ten posts."
Since no further limits are described, a maximum of ten articles on Planet Drupal, where articles older than three months and three weeks are automatically discarded, means that a feed should, in average, publish not more than an article every two weeks, or the articles from the same visible on Planet Drupal would become more than ten.
What reported on 📌 Clean up Drupal Planet for old posts Active was caused by an issue on Drupal core. There is no need to put a limit for those cases, since it is possible to removed articles from Planet Drupal. In That issue, @drumm also posted this comment, which I read it as There is nothing to worry about.
It's not really practical to do any manual cleanup since newer posts will usually push occurrences of this down by the time someone can look at this.
I don't suggest that drupal.org should make any changes
Actually, any restriction on articles/feeds described on
Planet Drupal →
are a condition for an action content moderators should take. If the guidelines say that a feed must have a maximum of ten posts, content moderators should do something when a feed does not respect that limit, similarly to what is done when a feed is not updated in more than two years.
So, yes, adding that "clause" does require drupal.org makes any change.
For what I recall, 10 articles from the same feed have never appeared on the first page.
If it happens because a site publishes 12 different articles in a week, I do not see that as a problem because we should incentivate good articles on Planet Drupal, or Planet Drupal will "die."
If it happens because an issue on how a feed is generated from a site, single articles can be removed, or the feed can be suspended until the issue is resolved. There is no need to put a limit that is then valid for every feed on Planet Drupal.
A limit basing on how many articles from the same feed appears on the first page of https://www.drupal.org/planet → , https://www.drupal.org/planeta → , or https://www.drupal.org/planet/chinese → makes less sense.
What should article's authors do before publishing an article? Check
https://www.drupal.org/planet →
and wait somebody else publish an article?
What should be done when there are more than 10 articles from the same feed on the first page of Planet Drupal or any regional variant?
If you are proposing to use a view to show the articles added to Planet Drupal (and the regional variants), this is something that need to be proposed for the Drupal.org customizations project. None of the Aggregator module's settings allows to set a view to show the added articles.
On /admin/config/services/aggregator/settings, there are no settings for ordering the posted articles.
Since /planet is a path alias for /aggregator/categories/2, the output of that page is produced from the Aggregator module. There is no way to alter how to order articles listed there.
I cannot say the output on that page is altered in some way. I suspect it is so from the Blog text that appears on the top of the page. (The Aggregator module does not seem to categorize its output in such way.)
Since there is already a custom module used for the block showing that information, I guess that module will be ported to Drupal 10. Only the maintainers of this project know what the plan is, though.
We should incentivate writing articles worth for Planet Drupal. Asking to post a new article every two weeks seems going in the opposite direction.
I would not ask to somebody who is willing to share an article that could be helpful to the community to first check how many articles already in the feed are still visible on Planet Drupal. I could also not imagine somebody reporting a feed with more than 10 articles visible on Planet Drupal.
If there are exceptional cases, those can be handled cases by case, similar to what done when a feed contains an article that does not suit Planet Drupal: It is sufficient to move the article to an aggregator category that is not publicly shown.
This requires a code change in one of the custom modules used on drupal.org. Given drupal.org is migrating to Drupal 10, it is probable this feature request will be postponed.
I added dieterholvoet as co-maintainer.
I added lussoluca as maintainer.
Your feed must have three posts already and at least one post created within the last three months means a feed could be asked to be added to Planet Drupal in June and have an article created on March and two articles older than three months and three weeks, which would also mean that, after three weeks, no article would be visible on Planet Drupal.
dbiscalchin has last logged in more than two years ago. I made tim-diels, who was already co-maintainer, a maintainer.
I published 🐛 AddConstraint() unexpected behaviour Active . The account has been confirmed by nico.b.
Feeds are required to have posts created in the past three months and three weeks because older articles are not even added to Planet Drupal and posts are automatically discarded after three months and three weeks.
Without those requirements, somebody could ask to add a feed with articles that will never appear on Planet Drupal, or somebody could ask to add a no longer active feed without adding new articles. In neither those cases the feeds should be added.
I am closing this issue since 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 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 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 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.
As a side note, the issue title needs to contain the full project name, which in this case is Responsive and off-canvas menu, not the project machine name, or part of the project name.
ajitdalal is no longer maintainer/co-maintainer of this project.
As long as the feed contains at least two articles published in the past three months and three weeks, the feed is fine.
Articles published in the last 30 days are preferable for the added feed because it shows the feed is constantly updated. It is a positive point which is considered when reviewing the feed.
I added svendecabooter as co-maintainer, since no comments for declining the offer have been posted.
There is no need to wait for 15 days more: A maintainer agreed to make you a maintainer, which means having all the permissions on the project. I added the missing permission.
Added a link that automatically creates an issue in the right issue queue.
Improved formatting; fixed a typo; added a description of what information the created issue needs to contain.
Effectively, the documentation needs to be corrected. It says If you followed the steps above, you have already created an issue requesting that your group be moderated. Here is how the process works. but the previous steps did not say an issue must be created, nor exactly what the issue needs to provide.
That said, the group gets a +1 from me. A second review from another moderator is necessary. Without that, after seven days the group will be approved (since I gave a +1).
I would add that, lately, the "trend" is no longer creating groups on groups.drupal.org, but community projects → on drupal.org, which are described as:
Community projects can be used for any purpose that supports or enhances the Drupal project and community. Examples could be non-code projects used to manage groups or initiatives within the Drupal community such as Drupal camps or working groups. They don’t contain modules or themes for use on other websites.
As described in Forming a new group → , the group must first be created, and then an issue which provides a link to the group is posted on this queue. The group is reviewed; if it passes review, it is removed from the moderation queue. That makes the group accessible to everybody.
Basing on 🐛 User repeatedly closing issues that should remain open Active , I would think this issue needs to be re-opened.
It could also be better to leave the task to close the issue to somebody else.
@niranjan_panem On which bases do you claim this issue is outdated? Did you verify it cannot be reproduced?
All the messages to the maintainers have been sent.
This is the first message I sent. I will send the other messages right after posting this comment.
Hello Pratik,
I am contacting you because nicxvan ( https://www.drupal.org/u/nicxvan → ) offered to become co-maintainer for Commerce Repeat Order ( https://www.drupal.org/project/commerce_repeat_order → ), 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/3500938 📌 Offering to comaintain Commerce Repeat Order 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, nicxvan 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/3500938 📌 Offering to comaintain Commerce Repeat Order Active .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.
This is the other message I sent.
Hello Prathamesh,
I am contacting you because Martin ( https://www.drupal.org/u/mandclu → ) offered to become co-maintainer for VWO ( https://www.drupal.org/project/vwo → ), a project for which you are maintainer.
May you post a comment on https://www.drupal.org/project/projectownership/issues/3493411 💬 Offering to co-maintain VWO 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, Martin 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/3493411 💬 Offering to co-maintain VWO Active .Best regards,
Alberto Paderno
-- Drupal.org project moderator
-- Drupal.org site moderator
This is the first message I sent.
Hello Anil,
I am contacting you because Martin ( https://www.drupal.org/u/mandclu → ) offered to become co-maintainer for VWO ( https://www.drupal.org/project/vwo → ), a project for which you are maintainer.
May you post a comment on https://www.drupal.org/project/projectownership/issues/3493411 💬 Offering to co-maintain VWO 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, Martin 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/3493411 💬 Offering to co-maintain VWO Active .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.
I am closing this issue since 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 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 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.