Also, credit has not yet been assigned to users for this issue itself and should be added.
FYI: The release notes are missing issue credit for this issue.
Your issue is that #25 is not the most recent patch. You have to use the merge request patch/diff
No, the patch is not already included. You might have a conflict with another patch you are using. I was able to successfully use the patch with 1.0.0-beta3 without any issues.
Look at the changes in the MR. It was broken in 1.0.0-beta3 for me, so the MR needs to be merged.
PHPCS needs to pass.
I discovered the change in 🐛 Typo in the calendar-month-col twig template Active broke my TS. Once I fixed that, I can test the changes here.
The changes work great, as far as I can test. My test does not cover the entirety of the functionality changes, but I'm happy with what I use and see.
I'm going to see if the changes work with my site. I have to adjust some custom TypeScript to work with the changes, I think, for me to test it.
Shorten title more
solideogloria → changed the visibility of the branch 8.x-1.x to hidden.
solideogloria → changed the visibility of the branch 3255924-multiday-rendering-fix to hidden.
The function is already fixed in 1.x, it seems.
@cmlara Very interesting article. I had no idea WordPress did that. I definitely agree that Drupal should only collect what it needs. I think that if users are given more granular control over which data is sent, they are more likely to allow it.
The changes need to be applied to the merge request.
It seems like it was a misunderstanding of what needs to change. While EntityInterface $source_entity = NULL is deprecated due to not having the nullable type, there is nothing wrong with ?EntityInterface $source_entity without a default value, so it should be left as-is.
PHPUnit failed in the pipeline. Is this the cause?
The function doc comments need to be updated to match the changes.
Looks good to me. It's a simple change/fix.
Ah, right you are. Thanks
Looks good to me.
Looks good to me.
The branches in the MR look incorrect. See the documentation for how to do this properly.
https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →
They must be already fixed in the dev branch, then.
I looked at the diff: https://git.drupalcode.org/project/search_api/-/merge_requests/208/diffs
It doesn't have a single changed method signature to add the nullable to the type.
solideogloria → created an issue.
solideogloria → created an issue.
solideogloria → created an issue.
This is required for PHP 8.4 compatibility to avoid deprecation errors.
solideogloria → created an issue.
solideogloria → created an issue.
Some fixes were missed:
https://www.drupal.org/project/drupal/issues/3427999#comment-15932569 📌 [PHP 8.4] Fix implicitly nullable type declarations Active
Could a maintainer please reopen the issue? Or should I open a new one?
Some were missed. I tried using Drupal 10.4.1 and PHP 8, and I get these errors:
Deprecated: Drupal\layout_builder\Form\BlockVisibilityForm::buildForm(): Implicitly marking parameter $section_storage as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/core/modules/layout_builder/src/Form/BlockVisibilityForm.php on line 115
Deprecated: Drupal\layout_builder\Form\ConfigureVisibilityForm::buildForm(): Implicitly marking parameter $section_storage as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/core/modules/layout_builder/src/Form/ConfigureVisibilityForm.php on line 172
Deprecated: Drupal\layout_builder\Form\DeleteVisibilityForm::buildForm(): Implicitly marking parameter $section_storage as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/core/modules/layout_builder/src/Form/DeleteVisibilityForm.php on line 90
solideogloria → created an issue.
solideogloria → created an issue.
solideogloria → created an issue.
Here's all the Search API errors I get when rebuilding the cache in PHP 8.4:
Deprecated: Drupal\search_api\Datasource\DatasourceInterface::checkItemAccess(): Implicitly marking parameter $account as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Datasource/DatasourceInterface.php on line 147
Deprecated: Drupal\search_api\Datasource\DatasourceInterface::getAffectedItemsForEntityChange(): Implicitly marking parameter $original_entity as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Datasource/DatasourceInterface.php on line 302
Deprecated: Drupal\search_api\Datasource\DatasourceInterface::getItemAccessResult(): Implicitly marking parameter $account as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Datasource/DatasourceInterface.php on line 161
Deprecated: Drupal\search_api\Datasource\DatasourcePluginBase::checkItemAccess(): Implicitly marking parameter $account as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Datasource/DatasourcePluginBase.php on line 101
Deprecated: Drupal\search_api\Datasource\DatasourcePluginBase::getAffectedItemsForEntityChange(): Implicitly marking parameter $original_entity as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Datasource/DatasourcePluginBase.php on line 171
Deprecated: Drupal\search_api\Datasource\DatasourcePluginBase::getItemAccessResult(): Implicitly marking parameter $account as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Datasource/DatasourcePluginBase.php on line 109
Deprecated: Drupal\search_api\Plugin\search_api\datasource\ContentEntity::getAffectedItemsForEntityChange(): Implicitly marking parameter $original_entity as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Plugin/search_api/datasource/ContentEntity.php on line 1136
Deprecated: Drupal\search_api\Plugin\search_api\datasource\ContentEntity::getPartialItemIds(): Implicitly marking parameter $bundles as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Plugin/search_api/datasource/ContentEntity.php on line 812
Deprecated: Drupal\search_api\Plugin\search_api\datasource\ContentEntity::getPartialItemIds(): Implicitly marking parameter $languages as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Plugin/search_api/datasource/ContentEntity.php on line 812
Deprecated: Drupal\search_api\Plugin\search_api\processor\AddURL::getPropertyDefinitions(): Implicitly marking parameter $datasource as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Plugin/search_api/processor/AddURL.php on line 29
Deprecated: Drupal\search_api\Plugin\search_api\processor\AggregatedFields::getPropertyDefinitions(): Implicitly marking parameter $datasource as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Plugin/search_api/processor/AggregatedFields.php on line 32
Deprecated: Drupal\search_api\Plugin\search_api\processor\ContentAccess::getPropertyDefinitions(): Implicitly marking parameter $datasource as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Plugin/search_api/processor/ContentAccess.php on line 129
Deprecated: Drupal\search_api\Plugin\search_api\processor\CustomValue::getPropertyDefinitions(): Implicitly marking parameter $datasource as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Plugin/search_api/processor/CustomValue.php on line 71
Deprecated: Drupal\search_api\Plugin\search_api\processor\EntityType::getPropertyDefinitions(): Implicitly marking parameter $datasource as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Plugin/search_api/processor/EntityType.php on line 31
Deprecated: Drupal\search_api\Plugin\search_api\processor\Highlight::getFulltextFields(): Implicitly marking parameter $fulltext_fields as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Plugin/search_api/processor/Highlight.php on line 376
Deprecated: Drupal\search_api\Plugin\search_api\processor\LanguageWithFallback::getPropertyDefinitions(): Implicitly marking parameter $datasource as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Plugin/search_api/processor/LanguageWithFallback.php on line 107
Deprecated: Drupal\search_api\Plugin\search_api\processor\RenderedItem::getPropertyDefinitions(): Implicitly marking parameter $datasource as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Plugin/search_api/processor/RenderedItem.php on line 152
Deprecated: Drupal\search_api\Plugin\search_api\processor\ReverseEntityReferences::getPropertyDefinitions(): Implicitly marking parameter $datasource as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Plugin/search_api/processor/ReverseEntityReferences.php on line 228
Deprecated: Drupal\search_api\Plugin\search_api\processor\RoleAccess::getPropertyDefinitions(): Implicitly marking parameter $datasource as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Plugin/search_api/processor/RoleAccess.php on line 131
Deprecated: Drupal\search_api\Processor\ProcessorInterface::getPropertyDefinitions(): Implicitly marking parameter $datasource as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Processor/ProcessorInterface.php on line 151
Deprecated: Drupal\search_api\Processor\ProcessorInterface::requiresReindexing(): Implicitly marking parameter $new_settings as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Processor/ProcessorInterface.php on line 229
Deprecated: Drupal\search_api\Processor\ProcessorInterface::requiresReindexing(): Implicitly marking parameter $old_settings as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Processor/ProcessorInterface.php on line 229
Deprecated: Drupal\search_api\Processor\ProcessorPluginBase::getPropertyDefinitions(): Implicitly marking parameter $datasource as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Processor/ProcessorPluginBase.php on line 148
Deprecated: Drupal\search_api\Processor\ProcessorPluginBase::requiresReindexing(): Implicitly marking parameter $new_settings as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Processor/ProcessorPluginBase.php on line 185
Deprecated: Drupal\search_api\Processor\ProcessorPluginBase::requiresReindexing(): Implicitly marking parameter $old_settings as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/search_api/src/Processor/ProcessorPluginBase.php on line 185
There's a lot of errors like this:
Deprecated: Drupal\webform\Plugin\Field\FieldType\WebformEntityReferenceItem::getSettableOptions(): Implicitly marking parameter $account as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/webform/src/Plugin/Field/FieldType/WebformEntityReferenceItem.php on line 114
Looks good to me.
This of course also affects 3.x.
solideogloria → created an issue.
$bucket_index is undefined.
Someone else will have to work on this. I literally only use this module for one small thing, so I'm probably just going to give up if nobody else is going to help fix this.
There were some large blocks of code that had merge conflicts, and I'm not certain of the correct outcome.
I did my best to reroll, but I need some people to test the changes.
solideogloria → changed the visibility of the branch 3255924-multiday-rendering-fix to active.
solideogloria → changed the visibility of the branch 3255924-multiday-rendering-fix to hidden.
solideogloria → changed the visibility of the branch 3255924-multiple-multiday-events to hidden.
It would be ideal to know the number of Drupal sites among those
For BuiltWith, I think that might require a Pro account. I couldn't figure out how to do it.
You're right. Files get deleted, but folders don't. I have a large number of empty folders inside private://views_data_export.
Is there a way empty folders can be deleted?
Yeah, probably not.
Does anyone have data about the level of popularity?
Here's Nginx compared with Apache and Drupal.
https://trends.builtwith.com/Web-Server/nginx
https://trends.builtwith.com/Web-Server/Apache
Nginx:
Top 1m 40.15% 401,507
Top 100k 50.09% 50,094
Top 10k 53.77% 5,377
Apache:
Top 1m 25.55% 255,529
Top 100k 31.54% 31,538
Top 10k 31.81% 3,181
That is exactly why I like the diataxis model.
The link appears to be a 404
The patch no longer applies after the latest release.
Never mind. It appears there wasn't an argument for the logger before, so I must've just been passing a previously-unused argument.
https://git.drupalcode.org/project/ultimate_cron/-/commit/c003090f0c7352...
Switching to normal, since it's a less-common use case.
solideogloria → created an issue.
So it's probably true that the core of the API will work as it always has.
Even with the version supporting PHP 5.3, they say this:
If you are using PHP 5.3, you should upgrade your environment as this version has been past end of life since August 2014. Otherwise, you can download v5.9.2 (zip, tar.gz) from our releases page. This version will continue to work with new versions of the Stripe API for all common uses.
https://github.com/stripe/stripe-php?tab=readme-ov-file#legacy-version-s...
Ah. I think a 3.x branch makes sense.
The older versions don't receive security updates. https://github.com/stripe/stripe-php?tab=readme-ov-file#support
I think the amended text reads well.
Applying the changes in MR 12 fixes the issue.
Marking as a bug report because of this.
I added a second MR where I upgrade the solution to work with the non-jquery version in 2.0.x branch for everyone using this and doing an upgrade.
This change is actually necessary for the accordion to work at all in the 2.0.x version if the behaviors are attached more than once. I think maybe the once function isn't working properly?
Notice that once is not added as a parameter where it should be:
dependencies:
- core/drupal
- core/drupalSettings
- core/once
/**
* @file
* CKEditor Accordion functionality.
*/
(function (Drupal, drupalSettings) {
'use strict';
...
})(Drupal, drupalSettings);
I'm very minded therefore to actually introduce some kind of configuration option of how the link should be rendered, and for new views use a plain link with a 'button' class, but keep the 1.x version around as an option and allow the local actions stuff in this ticket as another option.
I think this would be a good solution.
It makes the buttons follow the site's theme and adjusts them to be themeable, so you can style them however you want. On my site, it makes the buttons look like literally every other button on the site.
The added library is still pointing to https://github.com/fengyuanchen/cropper, which isn't maintained anymore.
Is this the issue you're referring to?
✨ Create composer.libraries.json Active
I agree with #16. Now that Core is working to remove its dependencies on jQuery, that same sentiment should extend to contrib.
Using status messages doesn't work if the site doesn't use that block to show messages. I think that including the JS on every page is fine because the JS is small and doesn't really affect the load time that I can tell.
I think #22 (aka #24) should be used.
Agreed. Project Browser is still in alpha and not used by many sites yet. I think 5.1.0 should be released.
The truck is backing up in the image, so that conveys that part. But I agree that it's not easy to understand at a glance.
Okay. In that case, several contrib modules don't follow the standard and there's no coder rule to detect that, to my knowledge.
I think it would also be helpful to include guidelines and examples/suggestions regarding acronyms in class names. Sometimes you see stuff like SMTPManager, which is harder to read and looks bad, versus SmtpManager, which is preferable.