Created a new branch and MR for 1.1.x
I encountered this issue on a project that uses custom content entities without bundles. In my case, the content appears to be correctly indexed into our VDB (Milvus, in this instance). However, we still receive the same notices on the /admin/config/search/search-api/index/<index>/fields page. These notices are linked to the "Preview content to be vectorized" feature, which doesn't function properly when no bundles are defined.
I've added an MR that resolved these issues for us.
This issue has resurfaced in version 4.5. It appears the commit was pushed to the 3.x branch, and then the 4.4 tag was created from that branch. Because the change was never committed to the 4.x branch, it disappeared once the 4.5 tag was created from the 4.x branch.
Applying the MR resolved this issue for me, this change pullls the code back in line with Drupal\Core\Action\ActionInterface
Applying the MR resolved this notice for me, the failing test seems to be unrelated.
Simple but effective, #5 resolved these notices for me.
mr.baileys → credited arkener → .
As Kristiaan noted, fixing incorrectly cased class names should be straightforward, given that class names are not case-sensitive. For other scenarios, such as the use of underscores, one of the backward compatibility approaches mentioned in #8 should be used. In the end, this change simply enforces an existing rule. If necessary, developers can always ignore the Drupal.NamingConventions.ValidClassName.NoUpperAcronyms result by employing the available PHPCS ignore implementations.
Tested the latest version of the MR on my instance of 11.1.0 and it also resolved the Unsupported operand types: array + null issue for me.
Thanks for your quick reaction Kristiaan! I've tested this patch on 11.1.0 and I'm now receiving an Unsupported operand types: array + null error:
Stacktrace:
at /var/www/html/drupal/modules/contrib/group/src/Plugin/Group/RelationHandlerDefault/OperationProvider.php:78
at Drupal\group\Plugin\Group\RelationHandlerDefault\OperationProvider->getOperations()
(/var/www/html/drupal/modules/contrib/group/src/Plugin/Group/RelationHandler/OperationProviderTrait.php:62)
at Drupal\group\Plugin\Group\RelationHandler\EmptyOperationProvider->getOperations()
(/var/www/html/drupal/modules/contrib/group/src/Entity/Controller/GroupTypeController.php:202)
...
Adding a simple fallback for no invokes ?? [] on OperationProvider.php:78 fixed this issue for me.
Agreed, we should remove the sniff and revisit once 📌 Coding standards for "use" statements RTBC is approved. I've merged the PR into 3.x, and I'll plan to create a new release this weekend, assuming no unexpected issues pop up. Thanks for the work on this!
Also running into this issue. Can we get a new tag so this issue resolves itself? The project page currently defines 4.0.3 as having D10 support, so releasing a new tag might fix some confusion.
quietone → credited Arkener → .
Agree with #35, the current description might indicate that the null coalescing assignment operator is included in this coding standard. Scoping this in the description to ?? would clarify this.
I would also clarify the title a bit, the current title has some ambiguity in regards to what we 're replacing.
Use Null-Coalescing Operator ?? to replace isset with ternary operator
with something like
Use Null-Coalescing Operator ?? instead of a ternary operator with an isset statement
MR: https://www.drupal.org/project/coder/issues/3407995 ✨ Add sniff for declare(strict_types=1); Needs review
3.8.0 has been released and the Composer package pointer has been changed to https://github.com/PHPCSStandards/PHP_CodeSniffer.
larowlan → credited Arkener → .
The Composer package will keep its current vendor and name. Packagist will change its reference to the new GitHub repository, resulting in no further actions needed here. Keeping this issue open until this switch has been made. See https://github.com/PHPCSStandards/PHP_CodeSniffer/pull/135
+1 makes sense to keep this consistent with other controle structures like `switch ()`
Our upstream dependencies have also created issues / commits in regards to this change:
- sirbrillig/phpcs-variable-analysis: https://github.com/sirbrillig/phpcs-variable-analysis/issues/314
- slevomat/coding-standard: https://github.com/slevomat/coding-standard/issues/1640
We should wait with creating a release until 3.8.0 has been tagged in the forked Codesniffer repository, as stated in the original issue. Created a draft MR https://github.com/pfrenssen/coder/pull/216 to follow this change.
Also ran into this issue. Extension::getExtensionFilename() can sometimes return NULL, mostly in the case of submodules, resulting in this issue. #2 fixed this issue for me.
Good catch, thanks for the patch. This has now been fixed in the 1.x branch.
Agreed that we shouldn't redefine this to a warning, as the coding standard dictates this as a "MUST".
The following phpcs.xml syntax can be used to redefine the severity for a specific rule when needed:
<rule ref="SlevomatCodingStandard.Namespaces.AlphabeticallySortedUses">
<type>warning</type>
</rule>
+1 to option A with required trailing commas.
Released a stable release for D8, D9 and D10.
This issue is most likely caused by the same issue as
🐛
Deprecation message on validation of empty file key
Fixed
. While KeyProviderInterface::getKeyValue() currently states that the return statement should always be a string, this seems to currently not be the case, for example when using the environment and file key types.
I've also created 🐛 KeyProviderInterface::getKeyValue() doesn't always return a string Needs review upstream, so we can some clarification on this issue.
Validated the latest release of 4.x using Drush 12 and there doesn't seem to be any issue running the command. Entities are updated as expected and no warnings are displayed. Though it's probably best to wait with actually adding support for Drush 12 until the RC or stable release is created.
This issue has been fixed in 🐛 Tables Removed After Ajax Completes Fixed . The FooTable will now only be drawn once. Thanks for the patch!
#5 has been applied, thanks for the patch! #7 has been fixed in 🐛 Notice: Undefined property: $last_render Fixed
Makes sense to also check on this line if the last_render is actually set. Thanks for the patch!
This issue seems to occur after the 9.5 jQuery changes. The FooTable integration seems to run multiple times, after which the FooTable table is completely removed. I've added a fix which will ensure that the FooTable initialization will only run once, which seems to fix this issue.
Merged!
This makes sense, thanks for the patch!
I've been using SlevomatCodingStandard.Namespaces.AlphabeticallySortedUses for some time and I haven't really ran into the issues as mentioned in #4, except for the fact the sniff will only mention the first incorrectly sorted statement. Are you able to provide some examples? PHPStorm's sorting currently corresponds with the sorting used in Slevomat. The sniff provided by @cburschka also corresponds with the sorting used by PHPStorm, except for the logic when it comes to uppercase and lowercase characters. For example, PHPStorm will sort to the following:
use Drupal\car\CarInterface;
use Drupal\Core\Controller\ControllerBase;
use Drupal\door\DoorInterface;
Which will be marked as correct by Slevomat and marked as invalid on the custom sniff.