🇮🇹Italy @apaderno

avpaderno → created an issue.

I added it.

It appears after the other documentation pages. Should the order be changed?

Added documentation page to its documentation guide.

I unpublished it as requested. If it needs to be published again, the case study link is https://www.drupal.org/node/3496170 → .

I guess it must be Values & Principles → .

Thank you for the merge request!

Thank you for the report!

The service replaces the cache_tags.invalidator service, so it cannot be defined as service in the log_cache_tags.services.yml file. It must be implemented as described in Altering existing services, providing dynamic services → .

The reported error is caused by the fact the cache_tags.invalidator service does not have arguments, contrary to the replacement service.

avpaderno → created an issue.

The issue summary suggests that also src/Plugin/RulesAction/UserEmailVerificationVerifyUserEmail.php should be changed, but the merge request does not change that file.
The composer.json file is not necessary for compatibility with Drupal 11.

The issue summary needs to be updated: It just says which files should be changed, but it does not describe what needs to be fixed, and why.

avpaderno → created an issue.

avpaderno → created an issue.

avpaderno → created an issue.

I confirmed the account basing on the existing posts. No post/comment needed to be published.

Usually, after reviewing a project, we allow the developer to opt projects into security advisory coverage. This project is too small for us; it does not contain enough PHP code to really assess your skills as a developer.

Do you have any other project hosted on drupal.org that we could instead review? It needs to have most of the commits (but preferably all the commits) done by you, in at least a branch.

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 → .

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.

avpaderno → created an issue.

Since a merge request has been created for 🐛 The parent class of LogCacheTagsForm is wrong Active , it is better to first fix that issue.

Since the parent class is changed, there are other changes to be done:

• The constructor needs to be changed
• The configuration object is retrieved with $this->config()

avpaderno → created an issue.

avpaderno → created an issue.

There are other changes to do to that code, but let's keep them for other issues.

avpaderno → created an issue.

avpaderno → created an issue.

avpaderno → created an issue.

Thank you for the patches! I made a commit for the 1.0.x and the 2.0.x branches.

(Credits are assigned even when an issue is closed with a status that is different from Fixed.)

Thank you for providing a patch!

I made a commit based on the merge request posted on 📌 Automated Drupal 10 compatibility fixes Downport , which made a similar change done in the patch provided here.

avpaderno → created an issue.

I am closing this issue, since it is for a branch compatible with a Drupal release no longer supported. Feel free to re-open this issue, if it is still relevant for a branch compatible with a supported Drupal release.

francewhoa updated that documentation page many times. He also made some changes described as Added "HTTP" to "General Requirements" section. Added "PECL uploadprogress bar appears, but it is not showing progress?" to "F.A.Q." section.

With that, I think that documentation page is updated. It just needs to be migrated.
I would not delete it, since the uploadprogress can still be used, and it works. What changed is that Drupal core does no longer require it, nor does it show a warning about a missing extension.

I added dydave as maintainer. (Despite the title, dydave offered to be maintainer, not co-maintainer.)

The project owner last logged in when he merged two MRs for this very project. Previous comments are in other issues for the same project, posted on 2020/2021.

Avoided to highlight a sentence in the tip-note, since the full block is already rendered in a different background color.

I changed the tip notes in both the documentation guides.

In 90% of select query use cases you will have a static query. If in a critical performance path, you should use db_query() and friends instead of db_select() for performance reasons. Dynamic queries should be used if the query parts vary (to add WHERE conditions depending on the context, for example), if they should be alterable (to check node access permissions, for example), or if a query extender is used (to create a paged query, for example).

In 90% of the use cases you will have a static query. When performance is critical, query() should be used instead of select(). Dynamic queries should be used when the query parts vary, when they should be alterable, or when an extendable query class is used.

Moved the tip note to the top.

Added a reference to query extenders in the tip note.

Added a reference to extendable query classes in the tip note.

I am still checking the used project and the account used to create this application.