Appears tests are running against Commerce 3 and that is not currently passing tests.
This patch is working in a production site to reproduce the behaviour from the patches before the final result was merged in.
Fixed as part of ✨ Provide exportable configuration Active .
The SiteVerification content entity allows the admin to set the label, id, and description which are displayed in the entity list.
Fixed as part of ✨ Provide exportable configuration Active .
The SiteVerification content entity has validation constraints on duplicating the filename, but does still store both types in the same ConfigEntityType for simplicity of storage and handling.
Duplicate meta tag is not restricted as it is normal operation for their to be multiple of the same meta tag name.
Fixed as part of ✨ Provide exportable configuration Active .
The SiteVerification content entity allows the admin to set the label, id, and description which are displayed in the entity list.
The "phpstan (next minor)" error is unavoidable until 📌 Backport Hook and LegacyHook Attribute Active lands. At that point both of the errors in the phpstan.neon file can be removed.
Very much open on feedback and patches on this! Will be making a 3.0.0-beta1 release in about a week if I don't get feedback, and that'll be out in the world for testing from then on.
One item of note is the simplification of the admin form for creating and editing the entities - it now only includes the name and the content fields, and does not have a full metatag entry, or a file upload field. There was already confusion about the file uploading part, fixed in 2.1.0-rc1, but it was added complexity that I didn't feel was needed in what was already a full re-write of the module.
Updating version to 3.0.x as this has become a full re-write of the module.
The module will still continue to function, however it will continue to swap between an integer value interpreted as a boolean value, and a true boolean value for this config item.
It's a boolean in the form, should be a boolean because it's a checkbox and true/false, and currently preventing the full validation of the module configuration against the schema.
The point of having the config and schema matched up is to eventually turn on config schema enforcement and validation so that config (simple and entity) and entities can be validated at the entity level instead of a form, allowing for API updates to entities without bypassing all of the validation.
Fixed upstream. Minor changes here.
This is actually a problem with variable precedence, filed on this issue 🐛 Unable to run "composer (previous major)"; no image Active
This will be fixed when upstream fixes the testing infrastructure, but it's probably also good to fix the indent.
I was going to open this up again next week as I'm still having the issue - it does seem to be via the UI and also via MR. This issue has my workings on it 🐛 Test GitLab CI issue Active .
I pushed an override to the image to get this working for the 2.0.x branch. I tried just overriding for "composer (previous major)" but it would not accept it either, so everything now uses apache instead.
Strangely, 2.1.x branch works normal now, but 2.0.x does not. The 2.1.x was "fixed" by the indent, but it also does different core opt-ins. 2.0.x only tests phpunit on the previous major. 2.1.x does previous, current and next point phpunit.
Does DDev give me a local version of the gitlab runner setup?
Getting the 2.0.x branch going meant overriding _TARGET_PHP_IMAGE_VARIANT: 'apache' for all builds. Specific composer job override didn't work, or I didn't have the right syntax.
Regardless, it kept choosing the wrong image for previous major.
For similar issues: 🐛 Test GitLab CI issue Active
Does not entirely seem to be solved by indenting. In the above, the 2.1.x branch was fixed by the indenting, but the 2.0.x branch needed to manually set _TARGET_PHP_IMAGE_VARIANT: 'apache' for all tests.
Change of title to reflect the actual change as a result of this isssue; to avoid going down the rabbit hole of suspecting something wrong with the module, make sure that Drupal works before genpass is installed.
Confirm that 3.14.2 fixes the issue for us here.
Does there need to be a change in Drupal (core-recommends)? I've just run composer update for twig everywhere and we're good to go.
The core-recommends is twig/twig": "~v3.14.0" so most everyone will now bypass 3.14.1 to .2 and never know this happened. Would it be safer to change that to twig/twig": "~v3.14.2"? Or specifically add a conflict for a known bad version?
twig 3.14.2 has been released:
D11 support was fixed in this issue. It is now a duplicate.
@see 📌 Automated Drupal 11 compatibility fixes for site_verify Needs review .
Fixing target branch.
2.0.x branch will not support Drupal 11.
Forced downgrading to 3.14.0 has fixed this in D10.3.6 production sites.
Is also causing testing failures in contrib with useful error indication.
Forcing twig to 3.14.0 fixes it here, and all the live sites I just dutifully updated just today.
Fix will be done in 💬 Updating phpstan and twig via Composer generates a blank page when editing a node Active .
Need fixing in 2.0.x too.
The 💬 Updating phpstan and twig via Composer generates a blank page when editing a node Active issue is what was taking down a pile of my lives sites that I've also been pulling my hair out about, so turns out this is all interrelated. They're 10.3.6 sites, so it's extended further than dev!! Updated to twig 3.14.1 earlier today so just force backing that out to get things back up and running.
Looks like it was the indenting in the gitlab-ci file!! No idea what it just decided today to go bonkers. Probably an update of something that no longer accepts poorly indented yaml files. Didn't even know it was poorly indented as that came from the original gitlab_template file I grabbed that had the huge droplet at the bottom.
The main composer job is still going ubuntu! At least it's working. Here's the job you ran:
https://git.drupalcode.org/issue/genpass-3486092/-/jobs/3279675
Anyway, yes. Both my issues are fixed and all credit is to you, thank you.
Working (yours):
Running with gitlab-runner 17.5.2 (c6eae8d7)
on gitlab-runner-6dd988d654-qvnk8 s8ex1X2yJ, system ID: r_EFUc8A4vR1Ul
Resolving secrets
Preparing the "kubernetes" executor
00:00
"CPURequest" overwritten with "2"
Using Kubernetes namespace: gitlab-runner
Using Kubernetes executor with image drupalci/php-8.1-apache:production ...
Failing (mine):
Running with gitlab-runner 17.5.2 (c6eae8d7)
on gitlab-runner-6dd988d654-qvnk8 s8ex1X2yJ, system ID: r_EFUc8A4vR1Ul
Resolving secrets
Preparing the "kubernetes" executor
00:00
"CPURequest" overwritten with "2"
Using Kubernetes namespace: gitlab-runner
Using Kubernetes executor with image drupalci/php-8.1-ubuntu-apache:production ...
I didn't even know I could change that. And here's the normal composer (so Drupal 11.0.5 current), which fails at phpunit which I'm guessing is because it's running the wrong software. I can't even access vanilla Drupal core functionality:
Running with gitlab-runner 17.5.2 (c6eae8d7)
on gitlab-runner-6dd988d654-qvnk8 s8ex1X2yJ, system ID: r_EFUc8A4vR1Ul
Resolving secrets
Preparing the "kubernetes" executor
00:00
"CPURequest" overwritten with "2"
Using Kubernetes namespace: gitlab-runner
Using Kubernetes executor with image drupalci/php-8.3-ubuntu-apache:production ...
You use php-8.1-apache:production, and I'm on php-8.3-ubuntu-apache. How did I do that? How can I fix it? afk 3 hours.
I was setting _PHPUNIT_CONCURRENT: 0 in the UI to remove that as an issue, and make everything linear. But I've only done that since things started breaking. Not setting anything else other than what is in the file.
This is the file in use for main branch: https://git.drupalcode.org/project/genpass/-/blob/2.1.x/.gitlab-ci.yml?r...
Not sure if it's tangentially related, but I'm getting server 500 errors when simply accessing drupal core at admin/config/people/accounts without the contrib module even installed!. Locally, it works fine. I'm going nuts here. All of that worked a few days ago - it's in a release.
🐛
All phpunit testing failing
Active
is my testing of that issue.
Here's the 2.0.x branch failing to do previous major too:
https://git.drupalcode.org/project/genpass/-/pipelines/331567
Here the Site Verify module doing the same.
https://git.drupalcode.org/project/site_verify/-/jobs/3278516
It was working 4 days ago:
https://git.drupalcode.org/project/site_verify/-/pipelines/327677
Both of these use a .gitlab-ci.yml file I've written, so maybe I have some silly syntax error that just hasn't shown a fault until the last day?
Added to the test; genpass is not installed at the start, and drupal core is still giving 500 error on admin/config/people/accounts, NOT on admin.
The act of logging into drupal as an administrator with ['administer account settings', 'administer users'] and accessing $this->drupalGet('admin/config/people/accounts'); is causing a 500 error. This should be without genpass installed unless I am mistaken about the $this->modules array, from which I have removed genpass. Should check on that.
All tests work perfectly locally so this is only on the testing infrastructure that things are broken.
Without Generate Password event installed, testing is unable to access admin/config/people/accounts in current or next minor.
From the new NotInstalledTest.php =>
/**
* Check to see that Drupal core is working, then install genpass.
*/
public function testDrupalWorkingWithoutAndWith(): void {
// Check that Drupal is working before installing Generate Password.
// THIS IS WHAT FAILS! UNABLE TO ACCESS THIS PAGE?
$this->drupalGet('admin/config/people/accounts');
$this->assertSession()->statusCodeEquals(200);
// Install Generate Password.
$this->assertTrue(
\Drupal::service('module_installer')
->install(['genpass']),
'Failed to install Generate Password module.'
);
// Check that the same page is still accessible.
$this->drupalGet('admin/config/people/accounts');
$this->assertSession()->statusCodeEquals(200);
// Check all of the form changes.
$this->assertSession()->pageTextContains('Account settings');
$this->assertSession()->pageTextContains('Generate Password - User Account Registration');
$this->assertSession()->pageTextContains('User password entry');
$this->assertSession()->pageTextContains('Admin password entry');
$this->assertSession()->pageTextContains('Generated password length');
$this->assertSession()->pageTextContains('Generated password display');
}
Released as hopefully last D7 version.
Final Bug fix release for Drupal 7
Bugs
- #2890278 → : Process uploaded file into filename/contents fields.
- #1694022 → by dmitriy.trt → : Support empty verification file.
- #2954441 → by imyaro → , jenlampton → , chris matthews → : Incorrect page contents for the verification page without the file content.
- #3119844 → by jenlampton → , elc → : Test front-page metatag using xpath.
- #3119841 → by jenlampton → : Use correct permission in tests.
Tasks
- #1412198 → by mgifford → , deekayen → , chris matthews → , elc → : Remove Yahoo engine.
- #2394355 → by gabesullice → , chris matthews → : Use static cache for site_verify_load().
- #3485022 → : Add Drupal 7 .gitlab-ci.yml file.
phpcs issue will be fixed as part of the next issue merged.
Needs porting to 2.1.x. README already says it's deprecated.
The concept of engines are intended to be removed from 3.0.x branch.
This feature doesn't belong in the module - the correct location to see if a file verification has been accessed is the the web server logs.
Reliably recording every access to the files would require any and all caching to be disabled the served verification files. I would like to enable as much caching as possible even for serving these files as this would be a very easy thing to cache.
It is then also impossible to determine when a verification service is checking the metatag; it's attempting to read bot minds, and again caching affected.
Setting as close, won't fix.
This issue is still present in the 2.1.x branch.
Notable behaviour change for the module.
7.x-1.x branch is ready for 7.x-1.3 release.
This feature won't be making into the release, or most likely any release before EOL of D7.
#1230956: Support for Exportables (Features) →
The first set of patches in there completely replaces the admin ui with ctools, which would add a dependency to an otherwise lightweight module just before D7 EOL. If it was looked at 12 years ago, it would be part of it but there's no point making such a huge change now.
The second set of patches implement the features ctools export part, seem incomplete, but would be a way to get this done, however the requirement and functionality of the export should be offloaded to a sub-module "site_verify_ctools" which when enabled would abuse the hook naming possibilities to provide the parent module's hooks. The aim of the trickery would be allow site_verify to continue on without a hard ctools dependency. 2 months out from D7 EOL.
Postponing unless someone is really keen to work through making this feature.
For Drupal 10/11 see ✨ Provide exportable configuration Active .
About to be updated to remove this html rendered page output with 🐛 Impossible to create empty verification file Needs work .
Needed to add update to cope with any sites still sporting a Yahoo engine based verification. Without the engine being present, php array index notices start appear in the watchdog.
The caching is only relevant to an admin loading the edit verification page, when there are 4x calls caused by the automatic menu item loading. All other calls to the function are single.
Using a non drupal_static method as the drupal_static call is expensive in comparison to a local static, especially when there is no possibility of a static cache reset being effective.
Fixed as part of 📌 Fix phpcs/phpstan/cspell issues Active , thank you!
Fixed in 7.x-1.x with thanks to @jenlampton
📌
Tests do not use the 'administer site verify' permission
Needs review
📌
Test front-page metatag using xpath
Needs review
Thank you @jenlampton
Thank you @jenlampton
All green.
Release will need to address:
- File contents not saved from admin form (to be confirmed)
- 🐛 Impossible to create empty verification file Needs work
Target correct dev branch for D11. Revert to Active just in case UpdateBot finds some needed changes.
✨ Provide exportable configuration Active is only remaining task. It is to be target of 3.0.x branch due to large changes involved.
GitlabCI should be enabled on 7.x-1.x branch before all the changes are merged in.
Update title to more easily identify what this issue is for. Nothing to be done here.
Add 💬 Compatibility with TFA module Active .
TFA module replaces the core login process entirely, just like CAS Server does which means they are currently not compatible at all. Supporting 2FA would be nice, but would most likely need either a sub-module, or for TFA change how it operates to provide an API for tying it into any login form.
Fixed 2.1.0-rc1 has been released. This is a bridge version as 3.0.x will aim to use OOP Hooks and start at Drupal 11.1.
Release notes for 2.1.0-rc1
Bugs
- None.
Tasks
- #3483955 → : Coding standards updated + Test target changes
- Use ticket expire timestamp for cookie expiry.
- #3453816 → : Make Services primary and link with Settings page by tasks.
- #3448425 → : Use FullyValidatable and #config_target.
- #3448424 → : JSON formatted responses
- #3440085 → : Remove deprecated & outdated code; Autowire; Constructor Prop Promo
-
- Drop D9 support. Add D11 support.
Changes since 2.0.1
The current maintainer of this module hasn't been seen or had activity on this site in a long time. This module would most likely be considered abandoned. A shame, since I use it; I've had to fork it locally to be able to use it so it would be ideal if you could get the releases going again.
Review the issue queue to demonstrate your knowledge of the module as there's an issue ready for review, perhaps prepare it for Drupal 11 in a new issue, and then follow the abandoned projects procedure.
https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... →
https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... →
https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... →
Small adjustment to plan - make 2.0.x release with the same core version requirement.
2.1.x branch would be the ^10.2 || ^11 compatible version, or more likely ^10.3 to make full use of Autowire.
3.0.x branch for OOP Hook and ConfigEntity changes.
D11 has been released but not all of the changes have been made to the 3.0.x branch yet. 2.1.x has been kept in sync with it. Given there are many changes that haven't been merged into 2.0.x, there is significant code changes that need some eyeballs and testing against.
To that end, the 2.1.x branch will be released as 2.1.0 being the only planned release unless a patch release is required. Initial release will be alpha as there are a lot of moved files.
Development will then continue on the 3.0.x branch for the remaining issues, especially to replace the ticket factory with something more generic. Core target for 3.0.x would be Drupal ^11.1 as that includes OOP Hooks.
This is where Drupal Core uses Attributes primarily with a fallback to Annotation:
https://git.drupalcode.org/project/drupal/-/blob/d7b47da6deda8a417760c26...
This is part of the commit linked the summary.
This is the constructor of the DefaultPluginManager which is given the Attribute and Annotation classes for discovery:
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Plugin%21...
This patch has not been merged into 2.0.x.
Update target branch. Tests pass.
I've made too many changes to put it to RTBC so leaving on NR.
Fixed in 2.0.1 release.
Contacted Dave Reid via d.o contact form as UBC doesn't have contact info on here.
Whoops, managed to miss the "fixed" status that I was aiming to do.
That has been merged, and is fixed.
Turned into MR against 2.0.x branch.
Fixed up tests to use new permission. Cleanup on tests to avoid doing extra work which isn't tested or needed.
Tests are green all round.
Linked the updated plans for releases:
Cleaning up the issue queue and making a final D7 release & new D10/11 release would be great. I've cleaned the queue a fair bit and prepared some of the issues for merging. Here's what looks like it should go into D7 release:
Updating target version. Tests pass for all target cores. Setting to NR as this MR amends the D11 fixes.
PHP always surprises me; it really does just ignore an Attribute class not existing. I guess that's why the syntax is #[Blah] so that older versions ignore it as a comment.
Added note to release to indicate 2.1.1 release has a minimum schema version requirement.
Update to an intermediate version first before stepping all the way from the 2.0.x branch. Given the commit log, the site was running 2.0.1 (20 October 2023) prior to this update.
Update to 2.0.4 or 2.1.0 before upgrading to 2.1.1; the removed schema update is still in these versions.
This change was included in 2.1.1 release and won't be reversed at this stage.
📌
Remove old schema updates
Fixed
The missing schema update if you would prefer to patch that in:
https://git.drupalcode.org/project/genpass/-/commit/a541ccfd4335d4bc52ce...
Adding it to 10.3 and 11.0 would allow the work on converting contrib modules to get underway using BC method - this is going to be quite the code churn leading up to Drupal 12.
Adding it to 11.0 is a no brainer - if it's added to 10.4, then it has to also exist in 11.0. Even if sites are expected to upgrade from 10.4 to 11.1, it's a real disconnect for a class not to appear in an intermediate version. It's harmless to add the classes. Any contrib module would need an exception to say "works with 10.4 through 11.1, but don't try it with 11.0 or it will WSOD your site". There will be D11.0 sites trying to use that code.
It would be nice to add it to 10.3 (so I can start coding BC OO hooks) but there's no compelling reason it needs to be added. No contrib marked <=10.3 is going to have any of these BC OO hook wraps that it needs the classes to exist. Any contrib release that adds them would already need to state ^10.4.
Thank you for the link to the backport issue.
Switching to OO Hooks looks like it's going to churn a lot of code over the next year.
I would think adding it to 10.4 (or 10.3) and then not adding it to 11.0 would break modules, sites and people's expectations. When something is added to a previous version it then needs to continue on to all future versions until it going through the deprecation cycle. If it disappears for a version in the middle it's just going to confuse things.
Change has been committed to 11-dev and the next major job is working on the testing pipeline.
https://git.drupalcode.org/issue/genpass-3482165/-/jobs/3122350
alexpott → credited elc → .
Thank you, I understood this wouldn't be merged. I've updated the summary to make it a bit more obvious hopefully. Will mark this as draft to obstruct merging further. It would expect that once 🐛 Symlinking a module breaks HookCollectorPass Active hits, the attempt to patch will cause a composer failure.
Pretty happy that this got attention and fixed so quickly as it was quite a confusing error. Still looking into how chi managed to get a stack trace from the error as the lack of information made it very difficult to track down the true failure.
Still wondering how I could create BC code after 📌 OOP hooks using attributes and event dispatcher Needs review . No Drupal versions prior to 11.1 (current 11-dev) include Hook/LegacyHook Attributes which are needed for them to work going forward. The issue states that BC code should be possible back to 10.1.
I'd have thought that 10.4 would be a better starting version so that it's a future change rather than something that magically appears in the past.
Anyway, will be marking this as fixed when core fix lands.
Core fix required - this is in an unreleased core:
🐛
Symlinking a module breaks HookCollectorPass
Active
Local issue demonstrating tests working with a patched core:
🐛
Run tests against a patched core 3482283
Active
I wasn't going to figure this one out in a hurry, thank you.
How on earth did you find this module's issue?
Postponed pending 3482283, at which time this will be closed (outdated).
Core modules are being converted.
📌
Test issue please ignore: Rector on user
Active
Attempted adding GenpassHooks to see if it would get rid of the error, which did not work.
Not sure if this is really hook related, but the new OOP hook methodology need to be adopted.
Possibly related to the addition of Hook Attributes:
📌
OOP hooks using attributes and event dispatcher
Needs review
And
Change notice:
Support for object oriented hook implementations using autowired services →
Backwards-compatible Hook implementation for Drupal versions from 10.1 to 11.0
Contrib modules which want to adopt this new approach to hooks and continue to support Drupal 10.1 and 11.0 are recommended to implement a new hook class, manually register that class as a service, and add a shim procedural implementation
Documentation and examples are not immediately available.
Still failing with concurrent turned off. Test does show as passed, but it has the same error messages. No more useful an error message.
Drupal: 11.0-dev
PHP 8.3.12 (cli) (built: Oct 8 2024 18:47:22) (NTS)
Copyright (c) The PHP Group
[snip]
PHPUnit 10.5.37 by Sebastian Bergmann and contributors.
Notice: file_get_contents(): Read of 8352 bytes failed with errno=21 Is a directory in /builds/issue/genpass-3482165/web/core/lib/Drupal/Component/Annotation/Doctrine/StaticReflectionParser.php on line 184
Failure of "phpunit (next minor)" does not appear to be temporary so, 🐛 phpunit (next minor) failing Active