Project page updated.
Created new task 📌 Update README and project page Active to deal with documentation updates.
Turns out, I am not the maintainer of that document. How do we find out who the maintainer is so that it can be migrated?
Looks like it just needs an update and then added to the new guide as a single page. It doesn't need multiple pages.
Installed and tested with these versions and unable to reproduce. Could you provide repeatable steps to produce the fault?
Had a think about this again - add a sub-module called "front" which requires "front_page" as a dependency. Fixes the original problem of trying to install the wrong module name, but without needing to make major changes to current module at all.
Optional - create an empty project using the namespace "front_page" which is marked as deprecated and to use "front" module instead.
Assuming this is handled.
Use the weight field to change the ordering.
cspell still upset about "rolename" but that is not relevant to this bug fix.
Instructions inside the module need updating to reflect the new feature.
I feel some kind of input validation is needed, and/or a way to uniquely identify a line as a regex instead of just assuming each line is a regex.
Having pulled every service injection, I've found there are at least 2 that are tripping up serialization. The DependencySerializationTrait method will stay unless someone can figure out which services can be bypassed to avoid it. It seems fairly harmless as it's only used when an altered form is used to trigger a batch.
Does this fix the issue?
I believe it's the specific cache being injected. I've used the DependencySerializationTrait in Hook/FormAlter for now, but CacheFactoryInerface could be injected instead to prevent the need.
Thanks for the terrific bug report!
I suspect it will be one of the new Hook namespace services is being included in one of the services used in the batch, all of which get serialized between batch steps.
With the code you've provided, we can make a test to reproduce the issue and hunt down which of them is causing the issue.
Re-target branch to 2.x, to be back ported.
Needs tests; plan to add to one of the existing tests.
Also added to tests to make sure view is valid before changing and then saving it.
Update module schema to include variable added here.
Failure on Drupal 11 testing caused by removal of "spaceless" in twig, resulting in extra whitespace characters being expected in the output.
📌
Remove use of deprecated "spaceless" filter in core templates
Active
Wrap expected text in version_compare to handle testing in both branches. May need to be fixed if Twig is updated for Drupal 10.5.x branch.
Tests skipped on merge but do pass:
https://git.drupalcode.org/project/views_advanced_cache/-/pipelines/486198
Could only think to add an array to the attributes. Is there anything else to alter into the attributes to press the limits?
Whoops, my bad. That certainly fixes the problem. Are you able to run with a patched version for now?
It very much sounds like we should add a test to trigger this same situation to prevent such a fault again.
No response from maintainer via contact form.
No response to issues:
- 📌 Automated Drupal 10 compatibility fixes RTBC
- 📌 Enable GitlabCI for Views Advanced Cache Active
- ✨ Apply custom cache tag for views row cache. Needs review
- 📌 Fix CS/SA/eslint/cspell issues Needs work
- 🐛 Add config schema for Views Advanced Cache Active
- 📌 Drupal 11 compatibility fixes Active
Missing sandbox credentials ApiIntegrationTest run.
Current will not finish build without forcing current Drupal Core to ^10.4. Here's it passed:
https://git.drupalcode.org/issue/commerce_afterpay-3397254/-/pipelines/4...
The Site Verification module allows for both file and tag based site verifications, managed by their own permissions. A user does not need to be given access to edit all meta tags on a site to be able to verify a site.
File based verifications, without needing access to the back-end hosting account, are also exclusively in this module.
Site Verification module allows for any tag or file based verification provider, by not limiting the user to the currently known domain verifying services. Providing both a meta tag parser and file upload, or manual entry to enter the verification data.
An admin can now name and describe each site verification to better keep track of which verification is for what, such as in the case of Google verifications where multiple users can each have their own tag which may need to be removed or disabled as needed.
For more details and how to use the module, check out the help inside the module or the project README.md: https://git.drupalcode.org/project/site_verify#site-verify
Won't change functionality of the module so have merged this one in. Looking forward to it being the default again so I don't end up getting another patch with one line of code changed lost amongst pages of use re-ordering diffs. Not on this project thankfully, but once is enough.
Updated MR to branch off 8.x-1.x once these are merged:
- 📌 Automated Drupal 10 compatibility fixes RTBC
- 📌 Enable GitlabCI for Views Advanced Cache Active
- 📌 Fix CS/SA/eslint/cspell issues Needs work
- 🐛 Add config schema for Views Advanced Cache Active
Added constraints to make schema FullyValidatable.
To be merged and rebased prior to merge:
- 📌 Fix CS/SA/eslint/cspell issues Needs work
- 📌 Enable GitlabCI for Views Advanced Cache Active
- 📌 Automated Drupal 10 compatibility fixes RTBC
Keeping the extra 2 MR committed to this MR until they themselves are merged.
Tests pass in pipeline:
https://git.drupalcode.org/issue/views_advanced_cache-3521203/-/pipeline...
Remove additional commits from 📌 Automated Drupal 10 compatibility fixes RTBC so tests will no longer run or pass.
Tests pass is this pipeline
https://git.drupalcode.org/issue/views_advanced_cache-3203460/-/pipeline...
Removing commits to be merged in separate issues, prior to this one:
- 📌 Automated Drupal 10 compatibility fixes RTBC
- GitlabCI
@todo Move the following into their own issues and do not merge them as part of this issue:
- GitlabCI setup
- phpstan/cs fixes
Prepared 📌 Drupal 11 compatibility fixes Active
MR made.
Many phpstan and phpcs issues still present in the module.
Maintainer malcolm_p contacted via d.o contact form.
The contrib module Fraction is also affected by this, with aggregation values disappearing.
In Core 10.4.5 the SUM output used Drupal\views\Plugin\views\field\NumericField, but in 10.4.6 it turned up in a Drupal\fraction\Plugin\views\field\FractionField using Drupal\fraction\Fraction\FractionItem::setValue(['numerator' => NN.NN]). setValue wasn't expecting such a value (normally it would be presented with FractionItem::setValue(['decimal' => NN.NN]) or ['numerator' => X, 'denominator' => Y]) resulting in the value always being empty as per the FractionItem::isEmpty().
Using both AUM & AVG in the same view ends up with one affecting the other, where in 10.4.5 that did not happen. I haven't figured out where that is happening.
There was a now reverted core change which has caused the change in behaviour. The change was introduced in 10.4.6 when 2735997 hit.
🐛
Decimal separator and decimals settings ignored when aggregating decimal fields
Needs work
🐛
[regression] COUNT aggregation no longer outputs count value for some fields
Active
🐛
Upgrading from 10.4.5 to 10.4.6 removes views format plural on Content ID field
Active
It removed the numeric field handler inside core/modules/views/src/Plugin/views/query/Sql.php
https://git.drupalcode.org/project/drupal/-/commit/59d79456a1a135b3d02bb...
End result is that after aggregation, instead of a numeric field being used for the result of the operation, it uses a Fraction field which is where the setValue(['numerator' => NN.NN]) happens.
Add a "me too" to the issue about fixing it up, and see where the core issue goes.
Installed Drupal 10.4.1 + Fraction 2.3.1 which resulted in a working SUM display.
Some items of note:
- $field->field_alias is still 'unknown'
- Resulting SUM field is the following during hook_views_pre_execute
- Class: Drupal\views\Plugin\views\field\NumericField
- type: numeric
In Drupal 10.4.6 + Fraction 3.0.1:
- Resulting SUM field is:
- Class Drupal\fraction\Plugin\views\field\FractionField
- type: fraction_field
Also getting validation error in both:
display.default.display_options.fields.field_fraction Default field views.field.* Yes <array>
'click_sort_column' is an unknown key because display.default.display_options.fields.field_fraction.plugin_id is fraction_field (see config schema type views.field.*).
'type' is an unknown key because display.default.display_options.fields.field_fraction.plugin_id is fraction_field (see config schema type views.field.*).
'settings' is an unknown key because [snip, etc]
Haven't had a chance to look deeper.
Works as expected, thank you.
Added 🐛 Match path to parent route for admin form Active .
Changing target branch because it will not create an issue fork. Tags and branches are really messed up for this module.
Patch for this in 🐛 Permission Missing to administer contextual range filters Active by @emerham
This is expected behaviour from Drupal Core. If you make a view dependent on a module, and then uninstall that module, it will remove any config that was dependent on the module which is the entire view.
The fix is to delete the block, delete the range filter from the view, double check the view config to ensure that every trace of it is gone, and then uninstall the module.
You can always keep a backup of your synchronised config too, and re-import the view if needed.
Fixed in 8.x-2.0 tagged release.
Really should have been tagged 2.0.0 on the 2.0.x branch (2.x).
No difference found when changing the category back to a translated string.
Have found why the value is showing as empty:
Drupal\fraction\Plugin\Field\FieldType\FractionItem::setValue() is being called with $values = [[numerator] => 114.6800];, which results in a parent::setValue($values, $notify) call with that array, resulting in a null denominator.
Made this change to cope with that input (pushed to issue branch):
- // If the decimal property is specified, use it.
- if (is_array($values) && isset($values['decimal'])) {
- $decimal = $values['decimal'];
+ if (is_array($values)) {
+ // If the decimal property is specified, use it.
+ if (isset($values['decimal'])) {
+ $decimal = $values['decimal'];
+ }
+ // If values array has been passed with only numerator and null
+ // denominator, treat it as if it was passed in as the decimal key.
+ elseif (isset($values['numerator']) && !isset($values['denominator'])) {
+ $decimal = $values['numerator'];
+ }
}
Still unknown:
- Why field_alias is 'unknown'
- Why value is being set as numerator array instead of decimal array, or num+den array.
- What happened to cause of all of this
Pondering installing an older versions of Drupal + Fraction and investigating old behaviour to narrow down which version has contributed to the change.
Site is running Drupal 10.4.6 and Fraction 3.0.1.
I've been searching Drupal Core for any related changes without any luck. I haven't figured out how field_alias is ending up either with no value set, or the value set being unknown. The field is present in the query while the alias is unknown, which is weird itself since there has already been an alias calculated as the array key, and set as a key in the array too.
I'll reverse that commit and see if it makes any difference. First look is that it's only the category name that has changed. Hard pressed to think that would make a difference.
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