mvonfrie → created an issue.
Another option would be putting a clear statement in the 2.2.0 release notes that the old update hooks will be removed and one must update to 2.1.4. first. Ofc the change is listed there but in my opinion that is not prominent enough amongst the list of all changes.
I agree with @martinstadelmann, this is totally unexpected and can cause some trouble i.e. if it works locally (because you updated somewhen to 2.1.4) during active development (of customer change request etc.) and then before preparing the deployment to test/production you install al available updates, including 2.2.0. Then on the test/production system during install (possibly with a scheduled maintenance window) you do the update from like 2.1.3 to 2.2.0 in one step instead of two and it fails.
Also, @mglaman stumbled over this and wrote a blog post about it: https://mglaman.dev/blog/restrict-composer-dependency-updates-only-patch....
Patch provided in MR !551.
mvonfrie → created an issue.
@cilefen, this definitely is a CKeditor behavior. To get some context, why that happens in CKeditor5, please read https://github.com/ckeditor/ckeditor5/issues/16203.
Some support from the Drupal Core team there might be helpful.
To get some context, why that happens in CKeditor5, please read https://github.com/ckeditor/ckeditor5/issues/16203.
mvonfrie → created an issue.
MR !32 works, but this is only half of the truth. In my case the image was not corrupted but the thumbnail of a document media entity embedded in a body field via CKeditor.
Steps to reproduce
- Create an image style with at least one aspect switcher effect.
- Enable Drupal Media with the Document media type including thumbnails.
- Configure a text format using CKeditor5 to allow adding Drupal media documents.
- Configure media documents default view mode to include the thumbnail image using the image style created before.
- Upload a document via Drupal media and ensure it has a valid, non-corrupted thumbnail image.
- Edit the body of any content using the configured text format, add the uploaded document via the Drupal Media button.
- Observe an error message in the CKeditor preview.
- Save and attempt to view the content with the included document.
I have a similar use case where I get the same error:
I have a Drupal 10.3 site with Media and Media Library enabled and the media types image and document set up and configured according to the needs of the customer. Because the didn't need the other media types like remote video they have been completely removed. Now he needs to embed Youtube videos via CKeditor.
So I thought, ok I will apply the remote_video_media_type recipe, adjust it and that's it. But applying that recipe failed because media library already is installed and configured, aka some of it's configuration has changed compared to the module's version. But adding another media type (or entity type in general) is a legit use case for recipes and should be possible.
I think sth. like skippable configuration imports is needed. So if configuration exists we just take it as is, without trying to import it. In case of a media type it doesn't matter how the core.entity_view_mode.media.media_library or views.view.media_library actually look, right?
- For
core.entity_view_mode.media.media_librarythe only important thing is that the view mode exists with this machine name. If the label has been changed doesn't matter. (In my case the site has no English language but German only, so I guess that's the difference the recipe importer is complaining about). - The
views.view.media_libraryconfig is even more likely to change as it might get customized to site owner needs. But again the important thing here is that the view exists not how it is configured, except maybe a constraint that the defined view displays must exist.
And I got a warning regarding missing properties in Drupal\media_bulk_upload\Entity\MediaBulkConfig regarding edit_after_upload and edit_finish_path.
See PHP 8.2: Dynamic Properties are deprecated for details and how to fix it.
The patch from #77 doesn't work because MR !14 is not mergeable into 3.0.2. This is because it contains changes in Commit 9e79aa9b which should not be included in a feature MR:
- Adding the LICENSE.txt file
- Adding auto-generated "Information added by Drupal.org packaging script on 2023-04-12" for version 3.0.2 in multiple *.info.yml files.
- src/Form/MediaBulkUploadForm.php.rej containing rejected merge hunks
In addition I would like to suggest for the "Redirect to this path after finishing editing" the option to use Drupal's standard destination parameter to return to the page from where the media bulk upload has been triggered. This is especially useful when the media library opens as modal overlay. There it doesn't make sense to redirect to the default front page.
I'm looking ahead to using this change.
Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to our policies.
Of course, but in my opinion it still makes sense to report the version I observed it and then you change it as needed. Maybe due to other changes the problem doesn't exist anymore in 11.x.
@cilefen, for simpler steps just skip installing the group modile and modify the views.view.media view in a similar manner.
Why is this a bug and not a feature request?
Because when I change one view (or a config entity in general) I don't expect another virw config entity to be modified with the same change. And there are even cases where having different labels (or other values) for the same field on different displays are needed, i. e. a table display with abbreviations for column labels vs. full name for a grid display.
And why is a translation context needed?
Because otherwise all translations with the same value will get changed. The group module's group members view doesn't show insider scoped roles as user inherits from a global Drupal role he has but just manually assigned group roles (there's an issue for that, no need to discuss it here). To circumvent this until a fix is available I've added a column with the (global) Drupal roles and changed the label translation (German) of the other column to "Gruppen-Rollen". Then I noticed that the page title of admin/people/roles changed to "Gruppen-Rollen" as well.
mvonfrie → created an issue.
For documentation purposes, to help others with the same problem finding the solution: today I asked for help on Slack and @kristiaanvandeneynde pointed me to this issue while he was working on the hotfix release.
@mvonfrie
As site administrator and group administrator, on the group contents view, I see the action "Add existing content" but not the action "Add new content". The user has all available permissions on the group. I found that the add existing content route requires_group_relationship_create_any_accesswhile the add new content route requires_group_relationship_create_any_entity_access. And the corresponding access checks return different results:Drupal\group\Access\GroupRelationshipCreateAnyAccessCheckreturns allow whileDrupal\group\Access\GroupRelationshipCreateAnyEntityAccessCheckreturns neutral.
What am I missing? Drupal is 10.3.8 and group is 3.3.0.@kristiaanvandeneynde
Do you have group_support_revisions enabled?@mvonfrie
Yes.
BTW, I have a similar problem with the "Add member" action on the group members view. The access result is neutral as well.
+1 for @richarddavies
This is similar to ✨ Display implicit roles of group memberships Active , you must not assign insider/outsider roles, but it should be visible that the user implicitely "has" these roles.
See my comment 📌 Disallow the programmatic assignment of insider/outsider roles to members Active for the reason of this issue.
mvonfrie → created an issue.
Thanks, that seems to work. At least when debugging the SynchronizedGroupPermissionCalculator the calculated permissions look correct.
But still, the information about the implicit (outsider, insider, inherited) roles is missing. I will create a follow-up issue as feature request.
I stumbled upon this issue when executing a migration from a Drupal 7 site with organic groups which I implemented several months ago and the new site is almost ready for production now. I changed my plugin to filter out all non-individual roles from the mapping and that works. But I observe a strange behavior related to this and would like to ask if that is intended or not.
The Drupal 7 site has an og level "Author" role, which now is a global "Author" role with outsider and insider mappings for the group type. Users, organic groups and almost all contents get migrated from Drupal 7, except migrating the og-level roles to corresponding global roles. The admins have to do this manually. After running the migration I have the following in Drupal 10:
- User A created
- Group B created, Insider "Author" role bound to the global "Author" role is defined.
- Membership of user A in group B created
Now when I assign the global "Author" role to user A, I nowhere see that it also got the "Author (insider)" role in group B implicitely assigned. Neither in the group members view, nor as read-only information in the group membership edit form. How can I check whether the outsider/insider scoped group roles actually are assigned?
mvonfrie → created an issue.
I'm getting the exact same error on the admin page admin/reports/updates/settings.
I just got this error on Drupal 10.3.1 with PHP 8.2.2.
Instead of fully disabling/uninstalling Big Pipe it also works to disable it just for the affected blocks (if that is deterministic). in my case I just disabled it for all views blocks:
/**
* Implements hook_block_build_BASE_BLOCK_ID_alter().
*/
function mymodule_block_build_views_block_alter(array &$build, \Drupal\Core\Block\BlockPluginInterface $block) {
// Disable placeholdering of this block.
// @todo Remove this when "big_pipe sometimes fails to load blocks" is solved. See: https://www.drupal.org/project/drupal/issues/3390178#comment-15742673
$build['#create_placeholder'] = FALSE;
}Hello, I am facing same issue as well. On 10.3.1 with Group 3.2.2 I have a view which shows group contents of a given group (via contextual filter). The view page works fine, the view block (limited to 10 nodes) rendered on the group page doesn't show, there is just the BigPipe placeholder. When disabling Big Pipe the block is rendered correctly. This is for admin user. I cannot provide information for anonymous user as I haven't configured group permissions for that yet.
Using Core 10.3.1, Group 3.2.2 and Flexible Permissions 1.10, I repeatedly but not really reproducable get the following (unhandled) errors:
Symfony\Component\DependencyInjection\Exception\ServiceCircularReferenceException: Circular reference detected for service "group.anonymous_user_response_subscriber", path: "group.anonymous_user_response_subscriber -> group_permission.calculator -> flexible_permissions.chain_calculator". in Drupal\Component\DependencyInjection\Container->get() (Zeile 149 in /var/www/html/web/core/lib/Drupal/Component/DependencyInjection/Container.php)
TypeError: Drupal\flexible_permissions\ChainPermissionCalculator::__construct(): Argument #1 ($cache) must be of type Drupal\variationcache\Cache\VariationCacheInterface, Drupal\Core\Cache\VariationCache given, called in /var/www/html/web/core/lib/Drupal/Component/DependencyInjection/Container.php on line 261 in Drupal\flexible_permissions\ChainPermissionCalculator->__construct() (Zeile 63 in /var/www/html/web/modules/contrib/flexible_permissions/src/ChainPermissionCalculator.php).
They always appear together in the logs.
Maybe they will be resolved when upgrading to Flexible Permissions V2? If not please let me know to open a separate issue.
Addition: I had this problem already with 1.1.3 but just updated to 1.2.1 to check if it is still there.
mvonfrie → created an issue.
I understand that Gin should care only about core as there are tons of contrib modules which might need to adapt themselves to Gin as well, which would bloat the module to handle all or even many of them. On the other hand, should all those contrib modules be aware of Gin and maybe other themes which need adjustments of he modules to work with them? That's the same problem just from the other side.
What about a more generic approach, like the Gin everywhere → module does? It even enables Gin for some core forms which are not covered by Gin itself (Block Content, Media, Menu). Why not integrating Gin everywhere completely into Gin?
And additionally, please document it better how to enable Gin for your own custom entity type. At least put a section in the project documentation which points to the proper hooks in the gin.api.php. Thanks.
Why is your first example <a href="#"> </a> (obviously) wrong? Syntactically it is totally correct, but of course semantically this doesn't make sense because the user will never be able to click this link. If this for some reason is used as a trap link (kind of honeypot) with a special url, you would know that the link has been "clicked"/followed by a robot and not a human, then it makes sense again.
Would be interesting what CKeditor5 does with this? <a name="top"> </a> This is an invisible anchor which can be used as jump target (a "Top" button at the end of the page or floating at the bottom to jump back to the start of the page (after header, banner image etc.).
In my opinion, CKeditor5 should correct syntactically wrong markup but not interpret syntactically correct markup which maybe makes no sense, as it cannot know a developer's intentions.
MR !13 has a conflict with ✨ Allow enabling vite for all components and libraries in theme/module RTBC which is already RTBC.
@wotnak, at first not but then I created a file with simple test code. No change.
But I've skipped this approach due to other problems with Vite itself. Read https://www.drupal.org/project/vite/issues/3349311#comment-15657697 📌 Example configurations/starting points Active to see how I configured it for now.
I found a solution using Yarn workspaces. In addition I'm using Typescript.
In each module/theme you need the following files:
package.json
Eventually it makes sense to remove a common prefix from [module_or_theme_name] in the package.json. If i.e. all modules start with myproject_ like myproject_ui I would name the package @myproject/ui. The package names just need to be unique though.
{
"name": "@myproject/[module_or_theme_name]",
"type": "module",
"engines": {
"node": "^20.14",
"yarn": "^4.3"
},
"private": true,
"scripts": {
"dev": "vite",
"build": "tsc && vite build"
},
"devDependencies": {
"@rollup/plugin-node-resolve": "^15.2.3",
"@types/node": "^20.14.8",
"fast-glob": "^3.3.2",
"typescript": "^5.2.2",
"vite": "^5.3.1"
}
}
vite.config.ts
in the vite config the server part is important, so we skip the rest of the file here for simplicity:
export default defineConfig({
server: {
host: true, // "Set this to 0.0.0.0 or true to listen on all addresses, including LAN and public addresses." --> Needed for DDEV.
port: xyz, // Every module/theme needs its own port, and all of them must be exposed from DDEV or Docker in general. We start with the default port 5173.
strictPort: true // Ensure that every module/theme uses it's own port. "Set to true to exit if port is already in use, instead of automatically trying the next available port." --> If something doesn't work/some ports are already in use lets fail here as our dev servers would not be reachable.
}
})
tsconfig.json
The tsconfig file for the module/theme (Vite application). To not duplicate all the settings, compiler options etc. we extend it from a base tsconfig in the project root.
Here the important part is the includes.
{
"extends": "../../../../tsconfig.base",
"include": [
"components/**/*",
"src/**/*"
],
"references": [
{
"path": "tsconfig.node.json"
}
]
}
tsconfig.node.json
The tsconfig file for the Vite config compilation step (this is only using for compiling the vite.config.ts).
{
"compilerOptions": {
"composite": true,
"module": "ESNext",
"moduleResolution": "Node",
"allowSyntheticDefaultImports": true
},
"include": ["vite.config.ts"]
}
Root package.json
The Yarn workspace definition.
{
"name": "@myproject/workspace",
"type": "module",
"packageManager": "yarn@4.3.0",
"engines": {
"node": "^20.14",
"yarn": "^4.3"
},
"private": true,
"scripts": {
"dev": "yarn workspaces foreach -Rpi --topological-dev --from '@myproject/*' run dev",
"build": "yarn workspaces foreach -Rp --topological-dev --from '@myproject/*' run build"
},
"workspaces": [
"web/modules/custom/*",
"web/themes/custom/*"
]
}
In the global dev and build scripts we run the corresponding scripts of all workspaces recursively (-R) in parallel (-p). We restrict them to a scope (--from '@myproject/*', the root package will be automatically excluded as Yarn detects that it would lead to an endless recursion). With --topological-dev Yarn will only run the command after all workspaces that it depends on through the dependencies and devDependencies field have successfully finished executing. This way the themes for example can depend on any of the modules.
In the dev script we additionally print the lines from the output as it receives them with the -i option. Without it (as in the build script) Yarn buffer the output from each process and print the resulting buffers only after their source processes have exited which makes more sense for scripts executed by a CI pipeline for example.
@ChrisScrumping I have a working webpack configuration in other projects. What I don't like with webpack is, that it builds dev and prod outputs into the same folder & files, which often leads to stupid git diffs (especially during development, even if you don't commit the changes). When you commit only prod builds, during development almost all generated files appear as changed because for prod they get minified and for dev not.
Of course there should be a configuration to create dist/style.css as non-minified during dev and prod build and an additional dist/style.min.css during prod build. But then still you do not have solved the issue which file Drupal should take (style.css or style.min.css) right now because the library definition is static. This is where the Vite module comes in very handy.
And integrating webpack with storybook might be another topic...
I spent over 8 hours to get Vite working in the project root. It is not possible, at least not yet. Maybe it will be in the future with the new Vite 6 Environment API.
<root> means the Vite project root, not the Drupal one. By default Vite generates the output in a dist folder, which would be in <root>/dist/. Even if I change it to <root>/web/dist/ to have the generated files in Drupal's web-root I have no chance to get the files where they need to be (<root>/web/[modules|themes]/custom/[module_name|theme_name]/dist/) as output.entryFileNames, output.assetFileNames etc. must not contain ../ to get out of the dist folder.
error during build:
Invalid pattern "../themes/custom/theme_name/components/title/style" for "output.entryFileNames", patterns can be neither absolute nor relative paths. If you want your files to be stored in a subdirectory, write its name without a leading slash like this: subdirectory/pattern.
The documentation regarding the Vite configuration example needs to be updated as well.
* in `<theme>/vite.config.ts`:
```diff
import { defineConfig } from "vite"
import multiInput from "rollup-plugin-multi-input"
export default defineConfig({
plugins: [multiInput.default()],
build: {
manifest: true,
rollupOptions: {
input: [
[...]
+ "components/**/*.pcss.css",
+ "components/**/*.ts",
],
},
},
[...]
})
```
The import multiInput from "rollup-plugin-multi-input" and then loading the plugin with multiInput.default() no longer works for me> I'm getting the following error:
You must supply options.input to rollup
If I change this to multiInput() as in the examples from the rollup-plugin-multi-input repo itself, I get another error:
failed to load config from /var/www/html/vite.config.js
error during build:
TypeError: multiInput is not a function
I don't have a solution for this yet.
Version info:
Node 18.20 or 20.14.8
Yarn: 4.3.0
Vite: 5.3.1
Typescript: 5.2.2
rollup-plugin-multi-input: 1.4.1
@ChrisScrumping even if your module is not up to date, it still looks helpful. What I'm trying to achieve at the moment is a Drupal site with two themes and one module all using Vite together. That would mean having vite.config.js in the repo root instead of the theme's or module's folder, especially as it would be much easier to run only a single Vite dev server and not multiple ones in DDEV.
mvonfrie → created an issue.
mvonfrie → created an issue.
+1 for me as well.
I have similar use cases as @joachim.
My first use case is developing a migration from D7 Scald (using the migrate_source_scald_atom source which is completely undocumented and drush migrate:fields-source not really a help) to D10 Media.
My second use case is migrating user memberships from D7 organic groups to D10 groups, but I can't migrate the organic groups to groups as well. So I have to write a custom source plugin which reads the membership relations from the D7 database together with the D10 group UUIDs which will be added in the D7 instance. It is a bit too complicated to explain why we can't migrate organic groups to groups, lets simply say there are too big structural changes and the customer decided to use the migration to implement organizational changes already existing in real-life as well.
For both use cases it is really helpful to have a destination which doesn't create any data in the site until the plugins and migrations are ready and the real destination plugins can be used.
@Jaypan, that sounds legit. More helpful would be a proper documentation with examples how to do things (adding, removing, ...) subgroups correctly via API.
Typo in issue title corrected.
I found a lot of code depending on the system.mail configuration which is not used by Symfony Mailer, especially in the WebformEmailProvider class. This needs to be adapted by a check whether Symfony Mailer is active (and then an alternative implementation utilizing Symfony Mailer) or if it should use the old system.
There might be changes in the Symfony Mailer module needed as well, I've linked the one which I found.
mvonfrie → created an issue.
mvonfrie → created an issue.
$parent_entity = $this->entityTypeManager->getHandler('group', 'subgroup')->getParent($child_entity);
doesn't work for me. It throws MalformedLeafExceptions, at least for subgroups added programmatically.
Addition: Removing the recipients to prevent sending updates was the only way when Drupal used swiftmailer, as the update manager only has two options for the email notification threshold: all updates or only security updates, but no option to not send a notification.
After applying the MR on my site and looking into the policy I found the "skip sending" adjuster which is the correct way of not sending notifications on the test environment. But still there might be other use cases where the recipients are evaluated dynamically (or defined by users) and can be none, so the code still should handle that properly.
mvonfrie → created an issue.
That is related to the HTML normalization "feature" of CKeditor 5. See https://github.com/ckeditor/ckeditor5/issues/16203 for more examples.
mvonfrie → created an issue.
Using 2.0.1 on Drupal 10.2.5 and Drush 12.5.1.0, MR !11 breaks the functionality as described in #11 and #16.
I don't re-open because this already gets fixed by 🐛 There are no commands defined in the "ckeditor_media_embed" namespace. Needs review
Using 2.0.1, MR !14 works for me on Drupal 10.2.5 and Drush 12.5.1.0.
This partially reverts and therefore fixes ✨ Add Drush 12 compatibility for custom CKEditor Media Embed Plugin commands RTBC .
mvonfrie → created an issue.
I just got the following warning after upgrading a site from 9.5 to 10.2:
Warning: file_get_contents(themes/custom/my_theme/../../../../../modules/contrib/colorbox/styles/default/colorbox_style.css): Failed to open stream: No such file or directory in Drupal\Core\Asset\CssCollectionOptimizerLazy->generateHash() (line 43 of core/lib/Drupal/Core/Asset/AssetGroupSetHashTrait.php).
Warning: file_get_contents(themes/custom/my_theme/../../../../../modules/contrib/colorbox/styles/default/colorbox_style.css): Failed to open stream: No such file or directory in Drupal\system\Controller\CssAssetController->generateHash() (line 43 of core/lib/Drupal/Core/Asset/AssetGroupSetHashTrait.php).
I can fix that by patching the colorbox.libraries.yml file like this:
plain:
version: VERSION
js:
styles/plain/colorbox_style.js: {}
css:
theme:
- styles/plain/colorbox_style.css: {}
+ styles/plain/colorbox_style.css: { preprocess: file }
dependencies:
- colorbox/init
But that doesn't really solve the issue here. The Drupal site is located at /var/www/html/ (web root is at /var/www/html/web/) which means that the ../../../../../
resolves to /var/www/modules/contrib/colorbox/styles/default/colorbox_style.css
instead of /var/www/html/web/modules/contrib/colorbox/styles/default/colorbox_style.css
and of course that file doesn't exist. I'm not sure whether this (the ../../ too much) is a bug in core or in the colorbox module. Therefore I didn't create an issue for that yet.
I get this error:
Fatal error: Declaration of Drupal\pluginformalter\DataCollector\FormAltersDataCollector::collect(Symfony\Component\HttpFoundation\Request $request, Symfony\Component\HttpFoundation\Response $response, ?Exception $exception = null) must be compatible with Drupal\webprofiler\DataCollector\FormsDataCollector::collect(Symfony\Component\HttpFoundation\Request $request, Symfony\Component\HttpFoundation\Response $response, ?Throwable $exception = null): void in /var/www/html/web/modules/contrib/pluginformalter/src/DataCollector/FormAltersDataCollector.php on line 55
This one is easy to fix, just the method signature changes from \Exception to \Throwable and the return type must be void.
I start a merge request for the changes, if there are more fixes needed they can be added there as well.
mvonfrie → created an issue.
mvonfrie → created an issue.
Publishing/unpublishing content has many effects including possible desctructive ones: assume someone has the unpublish * role but not the publish * role and clicks on the unpublish tab/local action by accident (or vice-versa). The user would not be able to revert this action on his own.
See MR !2 for the update hook.
Just adding the dependency to composer.json and the info.yml is not enough because that will not install it. And depending on the site manager to install it manually is no good practice, as if they don't know and forget it, that will break the site. The safe option is to install it via an update hook.
Hello. I have a different use case but came across this issue when looking into the webform submissions delete form whether it would be possible to extend/path it for my use case. On a customers site the webform spam protection was not configured strong enough and now we have almost 40,000 submissions in a webform, of which 98 - 99 % are spam. With data analysis (# submissions per ip adress, email address etc.) and what is available I managed to marked most of the spam submissions as locked, with less than 500 remaining which the customer has to check manually.
So far so good. The next step is to clean the data tables from the spam submissions. My idea is to add an option to the clear (and purge) forms to only delete submissions which
- * are locked (in my case the spam is locked)
- * are not locked (in a case where it is easier to identify and lock the submissions to keep)
- *ignore the locked state (current behavior)
As that could become a per webform or global purge setting as well and thus affect/extend the implementation of this issue, I first want to hear your opinion about it.
I'm looking for the same (merge a group → specific menu into the main menu). But I would prefer a solution in Drupal Core which is independent from actually displaying the menu (aka it should work for decoupled menus as well).
Where is the change record regarding the removal of the $filters parameter of Group::getContentEntities($plugin_id, $filters) (or Group::getRelatedEntities($plugin_id, $filters) in 2.x/3.x)?
How can I rewrite my code which uses the filters? In my case the filter depends on the bundle type of the related entities, for type A I have to filter on the group owner UID, for type B on the current user UID. And there are two more filters to apply, which are more difficult to explain.
mvonfrie → created an issue.
@mrweiner I get the following output from Drupal Upgrade Status. Except the core_version_requirement,/em> all reported issues are in tests only. I don't know why rector didn't fix them when you changed this issue back to active. But it would be really nice if you could apply them (eventually manually) and create a D10 compatible release soon. Maybe you can even publish a D10 compatible release without fixing the tests now (as their outcome should not be affected) and fix the tests later if you don't have so much time now? Thanks.
Cache Register 1.0.2 Scanned on Wed, 11/15/2023 - 17:35. 31 errors found. 1 warning found. Avoid some manual work by using drupal-rector for fixing issues automatically or Upgrade Rector to generate patches. web/modules/contrib/cache_register/tests/src/Kernel/CacheRegisterKernelTestBase. php: ┌──────────┬──────┬─────────────────────────────────────────────────────┐ │ STATUS │ LINE │ MESSAGE │ ├──────────┼──────┼─────────────────────────────────────────────────────┤ │ Fix with │ 194 │ Call to deprecated method assertNotEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertNotEquals() instead. │ │ │ │ │ │ Fix with │ 203 │ Call to deprecated method assertNotEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertNotEquals() instead. │ │ │ │ │ └──────────┴──────┴─────────────────────────────────────────────────────┘ web/modules/contrib/cache_register/tests/src/Kernel/DrawerTest.php: ┌──────────┬──────┬─────────────────────────────────────────────────────┐ │ STATUS │ LINE │ MESSAGE │ ├──────────┼──────┼─────────────────────────────────────────────────────┤ │ Fix with │ 18 │ Call to deprecated method assert() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertTrue() instead. │ │ │ │ │ │ Fix with │ 26 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ │ Fix with │ 29 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ │ Fix with │ 45 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ │ Fix with │ 81 │ Call to deprecated method assertNotEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertNotEquals() instead. │ │ │ │ │ │ Fix with │ 82 │ Call to deprecated method assertNotEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertNotEquals() instead. │ │ │ │ │ │ Fix with │ 83 │ Call to deprecated method assertNotEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertNotEquals() instead. │ │ │ │ │ │ Fix with │ 87 │ Call to deprecated method assertNotEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertNotEquals() instead. │ │ │ │ │ │ Fix with │ 90 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ │ Fix with │ 92 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ │ Fix with │ 93 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ └──────────┴──────┴─────────────────────────────────────────────────────┘ web/modules/contrib/cache_register/tests/src/Kernel/ManagerTest.php: ┌──────────┬──────┬─────────────────────────────────────────────────────┐ │ STATUS │ LINE │ MESSAGE │ ├──────────┼──────┼─────────────────────────────────────────────────────┤ │ Fix with │ 25 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ │ Fix with │ 41 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ └──────────┴──────┴─────────────────────────────────────────────────────┘ web/modules/contrib/cache_register/tests/src/Kernel/RegisterTest.php: ┌──────────┬──────┬─────────────────────────────────────────────────────┐ │ STATUS │ LINE │ MESSAGE │ ├──────────┼──────┼─────────────────────────────────────────────────────┤ │ Fix with │ 25 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ │ Fix with │ 34 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ └──────────┴──────┴─────────────────────────────────────────────────────┘ web/modules/contrib/cache_register/tests/src/Kernel/SlotBaseTest.php: ┌──────────┬──────┬─────────────────────────────────────────────────────┐ │ STATUS │ LINE │ MESSAGE │ ├──────────┼──────┼─────────────────────────────────────────────────────┤ │ Fix with │ 32 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ │ Fix with │ 53 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ │ Fix with │ 119 │ Call to deprecated method assertNotEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertNotEquals() instead. │ │ │ │ │ │ Fix with │ 125 │ Call to deprecated method assertNotEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertNotEquals() instead. │ │ │ │ │ │ Fix with │ 145 │ Call to deprecated method assertNotEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertNotEquals() instead. │ │ │ │ │ │ Fix with │ 160 │ Call to deprecated method assertNotEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertNotEquals() instead. │ │ │ │ │ └──────────┴──────┴─────────────────────────────────────────────────────┘ web/modules/contrib/cache_register/tests/src/Kernel/SlotTest.php: ┌──────────┬──────┬─────────────────────────────────────────────────────┐ │ STATUS │ LINE │ MESSAGE │ ├──────────┼──────┼─────────────────────────────────────────────────────┤ │ Fix with │ 27 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ │ Fix with │ 60 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ │ Fix with │ 64 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ │ Fix with │ 76 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ │ Fix with │ 78 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ │ Fix with │ 93 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ │ Fix with │ 95 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ │ Fix with │ 96 │ Call to deprecated method assertEqual() of class │ │ rector │ │ Drupal\KernelTests\KernelTestBase. Deprecated in │ │ │ │ drupal:8.0.0 and is removed from drupal:10.0.0. Use │ │ │ │ $this->assertEquals() instead. │ │ │ │ │ └──────────┴──────┴─────────────────────────────────────────────────────┘ web/modules/contrib/cache_register/cache_register.info.yml: ┌──────────┬──────┬────────────────────────────────────────────────────────────┐ │ STATUS │ LINE │ MESSAGE │ ├──────────┼──────┼────────────────────────────────────────────────────────────┤ │ Check │ 0 │ Value of core_version_requirement: ^8 || ^9 is not │ │ manually │ │ compatible with the next major version of Drupal core. See │ │ │ │ https://drupal.org/node/3070687. │ │ │ │ │ └──────────┴──────┴────────────────────────────────────────────────────────────┘
I really like to see this as well, no matter where it will be implemented. I currently have an issue with updating json_field from 1.0-RC4 to 1.0 or even 1.2, which is caused by the fix for #3252426 🐛 Support sqlite; set sqlite_type to native JSON field Fixed . This module cannot update the fields automatically because they have contents. In this case that should not matter because the change is about the SqlLite data type and I'm not using SqlLite.
About #39 the error message in commerce order there is already an issue ( Commerce #3336653 💬 Support setting theme for entity print patch Needs review ), added it as child issue.
Self-linking doesn't make sense, here is the correct link.
Linking the issue mentioned in the description for better tracking. The patch doesn't work with MR 16 from that issue.
mvonfrie → made their first commit to this issue’s fork.
I just created a separate branch and MR 60which so far works, but we need to add the changes described in #38 there as well.
I have the same error message as in the description on my local instance and the following one on our test server (which configured exactly the same as the future production server except the hostname):
Warning: file_get_contents(): open_basedir retsriction in effect. File(/sites/default/files/css/css_OTs7jT_btKWU2MLco9kpWeRL-rV2o_TgZa4ICtteRCk.css?delta=0&language=de&theme=drowl_child&include=eJxLKcovz4lPzsjMSdFPzU3MzNEprsxNy8-rjAdxUov0S1KLSwAYzA7M) is not within the allowed path(s): (/var/www/vhosts/***Hostname removed***/:/tmp/:/var/lib/php/sessions) in Drupal\symfony_mailer\Plugin\EmailAdjuster\InlineCssEmailAdjuster->postRender() (line 78 of modules/contrib/symfony_mailer/src/Plugin/EmailAdjuster/InlineCssEmailAdjuster.php).
That error message ("open_basedir restriction in effect") might give a better understanding of what's causing the error than "Failed to open stream: No such file or directory": The path to the CSS file starts with a / so it is kind of rooted. If we check other usages of the standard Drupal function getCssAssets() we i.e. can find Drupal\Core\Render\HtmlResponseAttachmentsProcessor::processAssetLibraries() which passes the result of getCssAssets() directly to Drupal\Core\Asset\CssCollectionRenderer::render() to create HTML <link> render arrays for all assets. This means, in that (and all other cases I found) the path is web-rooted to be output as
<link rel="/sites/default/files/css/css_OTs7jT_btKWU2MLco9kpWeRL-rV2o_TgZa4ICtteRCk.css?delta=0&language=de&theme=drowl_child&include=eJxLKcovz4lPzsjMSdFPzU3MzNEprsxNy8-rjAdxUov0S1KLSwAYzA7M" />
but in our case the path is rooted against the linux file system. Therefore, I don't understand the very long discussion and complex ideas to solve this. In my opinion it is very easy to solve:
Proposed resolution
- Prepend
$file['data']with Drupal'sapp.rootpath value. Considering the differences between >= 10.1 and < 10.1 we can do this conditionally only ifstripos($filePath, '/') === 0 // Make sure to use type-safe comparison as we want to check against position 0 and not FALSE indicating that $haystack does not contain $needle! - Furthermore, we need to load the CSS file from the file system and not via HTTP(S) for inlining, so we need to get rid of the url params.
Starting example:
public function postRender(EmailInterface $email) {
// Inline CSS. Request optimization so that the CssOptimizer performs
// essential processing such as @import.
$assets = (new AttachedAssets())->setLibraries($email->getLibraries());
$css = '';
$rootPath = \Drupal::getContainer()->getParameter('app.root');
$logger = \Drupal::logger('symfony_mailer');
foreach ($this->assetResolver->getCssAssets($assets, TRUE) as $file) {
$filePath = $file['data'];
// Only if we have a rooted path (which means it is web-rooted).
if (stripos($filePath, '/') === 0) {
// Correct the path to be linux-rooted.
$filePath = $rootPath . $filePath;
// Remove the query string which we don't need to load the file.
if (($pos = stripos($filePath, '?')) !== FALSE) {
$filePath = substr($filePath, 0, $pos);
}
}
try {
$logger->info('Loading CSS from file: %file.', ['$file' => $filePath, 'file' => $file]);
$css .= file_get_contents($filePath);
}
catch (\Exception $e) {
$logger->error('Failed to load CSS from file: %file. Error: %error', ['$file' => $filePath, 'file' => $file, '%error' => $e->getMessage(), 'error' => $e]);
}
}
if ($css) {
$email->setHtmlBody($this->cssInliner->convert($email->getHtmlBody(), $css));
}
}
Or write an post update hook which loops over all invoices and if they have a PDF generated, moves the file and updates the file entity accordingly.
Possibly the code running in the background to generate the invoice and send the email is using the wrong theme. Checkout Entiyty Print #2860122 Add option to set theme used for entity_print rendering ✨ Add option to set theme used for entity_print rendering Needs work
MR 16 conflicts with #2971822 🐛 Allow users to choose whether to optimize css. RTBC .
I have a very similar problem (please tell me if I should create a separate issue), using Drupal 10.1.2, Commerce 2.36.0, Commerce Invoice 2.0.0-RC3 and Entity Print 2.13.0.
My custom template in the site theme works perfectly fine when using the Entity Print route /print/pdf/commerce_invoice/1. But when I click on the module provided download link using its own route /invoice/1/download the PDF gets generated using the default template from the module instead of my custom template. Here it doesn't matter if I click the link from the admin view (admin theme) or the user view (custom theme).
mvonfrie → created an issue.
I have the exact same problem, but with the paypal payment gateway as well and not only with the manual payment gateway. MR 6 fixes both cases for me and works well.
I just came across this issue when getting the error message "The @see reference should not contain any additional text" from PHPCS for an internal project.
I agree with #11 and understand all the pros and cons, though my failing use case of @see has not been discussed here and is somewhere in between. Like
@Perignon →
I use @see for links when it is necessary for the understanding of some code. But unfortunately those specific links are very long and difficult to read, especially in rendered documentation like from PhpStorm.
Instead of
@see https://difficult-to-read-and-remember.hostname.com/1236456/some-very-long-and-crazy-url-which-nobody-will-understand-the-meaning-of-by-reading-this
I want to use
@see {@link https://difficult-to-read-and-remember.hostname.com/1236456/some-very-long-and-crazy-url-which-nobody-will-understand-the-meaning-of-by-reading-this Descriptive name of the linked page}
which then would be rendered as Descriptive name of the linked page (this link obviously doesn't work) linked to the given url.
mvonfrie → created an issue.
@joachim, yes the 'bundle' bit should be removed too. But the field (plugin) id should be changed from 'computed' to 'field' as no computed plugin exists.
On Friday I tried MR !1864 but I was not able to apply that one as patch. For me it looks like that is an older MR which will be discarded in favor of !4224?
MR !4224 on 10.1.2 with Commerce 2.36.0 works for me for a computed bundle field on the commerce order item entity.
Nevertheless I found an error in the example in `views.api.php` in both MRs, as following the example in !4224 I got the error
The "computed" plugin does not exist. Valid plugin IDs for Drupal\views\Plugin\ViewsHandlerManager are: [list of found plugin ids]
See my review comment in !4224 for details.
Basically I agree with you that only stable versions should be used, but that's not always possible.
We had some problems which have been solved by 3367674 → and as far as I remember from my colleagues other strange things as well, that's why we decided to switch to @dev until 2.10 gets released instead of applying the patch from that issue.
Then yesterday we suddenly started getting the described errors which are fixed by #bfdf0d3 and even if that commit is included in the beta1 I decided to directly go to the RC1 as RC should be more stable than beta.
mvonfrie → created an issue.
Just removed the leading dot of the issue title.
Totally agree. I'm currently stuck in (3) always returning the $payment_method_type->createLabel() if there is only one option for a payment method type (in my case of paypal_checkout => "PayPal") and the customer requiring to customize the label (as his customers otherwise won't understand that they have to select that option to pay by credit card or EPS (Austrian online banking) which they can select on the next checkout step.
At the moment I don't have time to implement the event but will start with a small fix of changing the option label for (3) to use the payment gateway's display label. This way it gets customizable via configuration and if users don't have more than one gateway configured per payment method type this is an improvement already. Furthermore it will be in line with how the label is generated for (4).
Ok, just wanted to fix this and have seen that it already has been fixed in 4035fef ("Fixed for phpstan issues, etc.") by @gausarts which has no related issue.
But I will keep this open for now in case there are more PHP 8.2 compatibility issues.
mvonfrie → created an issue.
mvonfrie → created an issue.