I've been using this patch to fix up SUM(fraction) successfully for years now, but it has just stopped working and I'm having problems narrowing it down to the exact failure. I haven't been able to narrow down the timeframe for when the failure happened either, except that it was either last week, or all the way back in January. It doesn't seem to line up with releases of this module.
Key to it is that $field->field_alias == 'unknown' for all of the Fraction fields in a view. That was causing the complete failure of what this patch was doing.
I've reworked the patch from #11 into 3.x-1515840-fix-sum to at least give me the correct answers in $view->results at hook_views_pre_render() time, but all of the fields are still considered empty and rendered as such. It seems very much like the field_alias being considered the default "unknown" by the field handler is the bugbear.
I had to change ordering of the 'entity field' vs 'field_name' in field definition since every field now has 'field_name', even if it is an entity field. This was resulting in no fields being found for fraction base fields.
The attempt to compensate for the field_alias being missing is not the correct way to go. Determining why that is missing is where I am currently focussed.
I have not created a MR as this still needs work. Some additional eyeballs would be greatly appreciated. Dumping to 3.x branch.
This has been fixed in the 3.0.0 release by correctly adding the MODULE_NAME.field_type_categories.yml file.
@see ✨ Drupal 11 compatibility fixes for fontawesome Active
No reviews. Making a RC for field testing.
Merged in ready for 3.0.0-rc2 release.
Merged in ready for 3.0.0-rc2 release.
elc → created an issue.
Migration completed. Additional eyeballs appreciated.
Converted hook_help as a first step.
No, sending plaintext passwords is not the job of this module. RPT is the place to go. Back to removing it.
No response from PRT module maintainers, so change of plans to cope with issue entirely here.
Offload the token into a sub-module and an update to keep the current status quo for existing sites, and the option to not install it on new ones.
- ➖ Move functionality and tests the new sub-module
- ➖ Add hook_update_N to install the new sub-module
- ➖ Move [user:password] handling to sub-module.
- ➖ Add hook_requirements detailing a conflict and steps to mediate
- ➖ Add option and coding to bypass the conflict with PRT since the sub-module will do exactly the same thing
- ➖
Tests good supporting both versions of Drupal core. Tests as they stand don't install Commerce 2.
Drupal 11 support is in 3.0.x branch.
Leaving at needs review so that another set of eyeballs can have a look.
Plan would then be to make a 3.0.0-rc1 release so it will be tested out in the wild.
Thank you! Soon to be released as 8.x-1.5.
VWO now shows the correct version when connecting a website.
Confirmation that the A/B testing is working as expected with this change would be appreciated before a release should be made.
Minor updates to OP.
Closing and waiting for the Drupal 12 bot.
Drupal 7 is no longer a supported release.
There is a Backdrop port: https://backdropcms.org/project/site_verify
Drupal 7 is no longer a supported release.
There is a Backdrop port: https://backdropcms.org/project/site_verify
Drupal 7 is no longer a supported release.
Created an issue: 📌 Add missing words to dictionary eg varchar Active
Task/Other issue on Drupal Core seems to be the place to discuss and do these things.
Fixed up the one test that was held up just by an admin ui change that needed to click differently named buttons.
Will leave fixing up the phpcs/cspell issues for 📌 Fix the issues reported by phpcs Needs work once this is merged.
I can see that you committed OPT_IN_TEST_MAX_PHP: 1 but it has disappeared without a corresponding commit or change.
Needs to be ported back to 2.1.x and 2.0.x as this is a long lived bug.
Located duplicate project:
https://www.drupal.org/project/nouislider →
Posted issue to reference as "Replaced by" as the newer one is up to date (older is 15.5.1, new is 15.8.1 and I assume has mechanism for staying up to date?) and includes the correct composer.json file, and has all of the library files instead of just the min ones.
📌
Set "Replaced by" to noUiSlider JS
Active
@todo Add a change notice/record regarding the removal.
Interop with Registration Password Token module ✨ Compatibility with Generate Password module Active .
This module sets the "password" property to the $account object itself during form submission, bypassing the need for core to continue to set the value.
https://git.drupalcode.org/project/rpt/-/blob/2.x/rpt.module?ref_type=he...
If memory serves, this was Automatic User Names module stepping in as it used the core password generator to provide a random string which did not validate as a username when Generate Password was installed.
It was fixed in Automatic User Names:
🐛
Make Automatic User Names compatible with Generate Password module.
Fixed
Add reference to core issue.
Thanks for the quick work! Yes, this is all it needed.
Only other question is whether this should cause a point release to differentiate it from the previously supported drupal cores.
Looks like a release came out, but it needs a new one already.
Module uses the password_generator service, introduced in Drupal Core 9.1.0. This makes this the minimum supported version.
@see https://www.drupal.org/node/3153113 →
@todo
Update the info.yml file to set minimum version of ^9.1 || ^10 and make a new release.
Despite the requirements stated in the info file, the minimum Drupal core version is 9.1.0. Please upgrade to this version or use the previous version of this module.
Triggering 3.0.0-beta2 release as this is a usability issue.
Project page updated for now. Will need an update in the new year, once Drupal 7 Core support is turned off in Jan 2025.
Still 15k users of this module on the 7.x-1.x branch. Lots of sites stuck on Drupal 7. Going to be interesting.
Released as 3.0.0-beta1 or 3.0.0-beta2
Follow up task 📌 Update project page Active
Drupal 11.1.0 and 10.4.0 have been released, fixing the Legacy/Hook false positive.
This will be merged into 3.0.x when I get the chance to update/write the release notes for dev/beta. Reviews always welcome, but not blocking.
I feel the review will effectively be on the release which will be a new branch and a beta, and will not remove support from any of the existing branches, so this makes it safe enough for it to be released as is.
Confirmed that importing did not work with validation being a requirement but it not being automatic. Made validation automatic and required.
@todo
- ➖ Add test to import SiteVerification entities through config.
- ➖ Update project home page
Still waiting on release of 11.1 and 10.4 to get rid of the phpstan error about Hook/LegacyHook not existing yet.
Still @todo
- Update README with current usage instructions (file/meta entry has changed to just name/content entry with parsing html meta line and file upload field processing no longer included)
- Finish adding help hooks (code completed, not pushed)
- Confirm if the forced validation currently coded breaks sync import of config, which was the entire point of this change
Tests need to be expanded to install redis and configure the tests to selectively use it in redis only tests. The code currently only tests the database storage of flood data.
The drupa/redis module has a modified .gitlab.yml file which would provide insight into getting redis installed and adding additional builds to test with a without it.
Marking as RTBC on behalf of @interlated
Let's fix the issue at hand, instead of adding nullable type hints to things that aren't ever going to be null. Having them nullable was a mistake, so just running an automated coding standards fix against them really isn't the way to handle it. It's important to understand the proposed fix and what is being applied to, and whether it is the correct result.
And fix up the only two nullable type hints that really are needed, plus match up their docblock hint.
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.