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.
@hatuhay please re-open this issue. The fix provided actually was wrong and worked only for a few weeks, as popperjs has been deprecated in Drupal 9.5 📌 Deprecate popperjs Fixed and removed from Drupal 10 in September 2022 → .
Solution:
Include @popperjs/core directly in the theme and
SASS subtheme starter kit →
via package.json and replace the dependency on core/popperjs by the local asset.
I have more or less the same issue with an indexed view for Commerce products, with Drupal 10.1 and all contrib modules up-to-date.
But in contrast to the others my problem is not the language of the contents (as they are theoretically in English and German, but currently there are no English translations of them). My problem is the interface language of the view. The site default language is EN (for technical reasons) and the content default language is German. This means the main language of the view is English and it is fully translated to German. But when I show it in German (/de/products) everything on the site is German except of the static view texts (title, global text area in the header, ...) is English. How do I get the view to display in the negotiated language correctly?
If the #3 warning should cause problems (it would block CI if you include phpstan in the automatic tests) this could be a workaround:
class MyService {
protected static function getMessenger() {
return \Drupal::messenger();
}
}
I made the method protected to help with testing, this way it can be overridden to provide a mocked service instance easily.
59 Variable $messages might not be defined.
$messages is assigned inside a nested if statement inside the foreach loop, so the fix is very easy. Just add $messages = []; directly before the foreach loop.
Which warning exactly do you mean with #2? And #3 btw doesn't get triggered by static methods.
I didn't look on this issue for a while, but unfortunatley don't exactly know what it meant by
It is possible to programmatically emit a deprecation in older versions in the interest of consistency across multiple PHP versions.
PHPStan though is able to detect these issues, as I just got another one
Deprecated function: Creation of dynamic property Drupal\symfony_mailer\Processor\EmailBuilderManager::$proxy is deprecated in Drupal\symfony_mailer\Processor\EmailBuilderManager->getProxyMapping() (line 204 of modules/contrib/symfony_mailer/src/Processor/EmailBuilderManager.php).
which by PHPStan is reported as
------ ----------------------------------------------------------------------------------------------
Line src/Processor/EmailBuilderManager.php
------ ----------------------------------------------------------------------------------------------
204 Access to an undefined property Drupal\symfony_mailer\Processor\EmailBuilderManager::$proxy.
💡 Learn more: https://phpstan.org/blog/solving-phpstan-access-to-undefined-property
------ ---------------------------------------------------------------------------------------------- Find the full PHPStan report of the symfony_mailer 1.2.1 attached for reference (as it is too long to post it directly in the comment).
I have the exact same configuration (D10.0.9, DDEV 1.21.5) and for me this works out of the box. Can you check if the sendmail transport is set as default?
Failed PHP8.2/D10 tests are not related to the changes of MR !158.
mvonfrie → created an issue.
I installed commerce_stock as the dev version is D10 compatible now and looked a bit into the code to understand how things work and how to quirk a solution for my example into my site. As I have a deadline for the project I can't wait until this feature is implemented but have to find a custom solution in the meantime.
But I have an idea for a concept how to implement this properly. This can't be fully implemented in commerce_stock though as it would require changes in commerce/commerce_product which then are permanent and would make things even more complicated. So the concept will always require custom code by the site developer.
Currently all stock logic is connected to the PurchasableEntityInterface which basically (only) is the product variation entity (but can be extended by contrib modules to nodes for example). But of course we don't want (and don't need) to make the product entity purchasable in order to let it handle the stock of it's variations.
So we need two new interfaces plus traits providing their implementations for commerce products:
/**
* Defines the interface for stockable entities.
*
* The entity type implementing this interface should always be implementing \Drupal\commerce\PurchasableEntityInterface
* as well. An implementation for commerce product variations is provided by StockableProductVariationTrait.
*/
interface StockableEntityInterface extends \Drupal\Core\Entity\ContentEntityInterface {
/*
* Returns the entity handling the stock level for this entity.
*
* @return StockedEntityInterface|null
*/
public function getStockedEntity(): ?StockedEntityInterface;
}
/**
* The entity type handling the stock level for a purchasable entity, for example the commerce product for its product variations.
*
* An implementation for commerce products is provided by StockedProductTrait.
*/
interface StockedEntityInterface extends \Drupal\Core\Entity\ContentEntityInterface {
// Everything we need here for stock handling...
}
/**
* Implementation of StockableEntityInterface for commerce products.
*/
trait StockableProductVariationTrait {
/**
* {@inheritdoc}
*/
public function getStockedEntity(): ?StockedEntityInterface {
$stocked_entity = $this->getProduct();
return $stocked_entity instanceof StockedEntityInterface ? $stocked_entity : NULL;
}
}
/**
* Implementation of StockedEntityInterface for commerce products.
*/
trait StockedProductTrait {
// Everything we need here for stock handling...
}
Then stock checking and stock processing has to check: The given entity or purchased entity of the given order item
- implements
PurchasableEntityInterfacebut notStockableEntityInterface--> use it for stock handling - implements both interfaces --> use
StockableEntityInterface::getStockedEntity()- the return value implements
StockedEntityInterface--> use that entity for stock handling - the return value is NULL --> fall back to the parent entity implementing
PurchasableEntityInterface
- the return value implements
- implements
StockableEntityInterfacebut notPurchasableEntityInterface- the return value implements
StockedEntityInterface--> use that entity for stock handling - the return value is
NULL--> don't handle stock for it.
- the return value implements
Of course this requires changes to all sub-modules of commerce_stock and is quite complex. But the same time it is very flexible as it allows to decide whether the product variation or product should handle the stock (or maybe a totally different entity implementing StockedEntityInterface and being return by StockableEntityInterface::getStockedEntity()) on a per-bundle basis.
The site developer would just need to create custom product and product variation classes implementing the interfaces and registering them properly. This can be done using hooks or more easier with the Bundle Class Annotations → module.
/**
* Custom product variation implementation using delegating its stock handling.
*
* @Bundle(
* entity_type = "commerce_product_variation",
* bundle = "my_product_variation_bundle",
* label = @Translation("Stock delegating product variation"),
* )
class StockableProductVariation extends \Drupal\commerce_product\Entity\ProductVariation implements \Drupal\commerce_stock\Entity\StockableEntityInterface {
use \Drupal\commerce_stock\Entity\StockableProductVariationTrait;
}
/**
* Custom product implementation handling stock for its variations.
*
* @Bundle(
* entity_type = "commerce_product",
* bundle = "my_product_bundle",
* label = @Translation("Stock handling product"),
* )
class StockableProductVariation extends \Drupal\commerce_product\Entity\Product implements \Drupal\commerce_stock\Entity\StockedEntityInterface {
use \Drupal\commerce_stock\Entity\StockedProductTrait;
}
It would even be possible to mix this for a product type, for example a book product type with three different variation types book, ebook (like ePub, PDF, ...) and amazon_kindle_book. book and ebook variations could handle their stock on product level by implementing StockableEntityInterface (i. e. using local stock) while amazon_kindle_book handles its stock on the variation by using a custom amazon kindle stock implementation.
This also effects Webprofiler #64 where the webprofiler toolbar reports data to the backend via POST /admin/reports/profiler/frontend/{profile}/navigation. The route only allows HTTP POST but as the admin path check of the "admin language from user preferences" language negotiator can't pass the HTTP method to the AccessAwareRouter it fails with the MethodNotAllowedException, which happens at least once per main request.
Patch #74 seems to fix this. I can't 100% confirm yet as I have another issue with webprofiler to solve first.
Please make this more generic and pass through all query parameters. While destination needs special handling, other query parameters could just be passed through. Or if that is too open maybe trigger an event to retrieve the query parameters to pass for a specific request.
In my use case I need a query parameter "owner" in order to set the owner of the new entity to a defined user passed via query parameter (and hiding the author selection UI) instead of the current user creating the new entity. The entity is a commerce product which should be owned by the "seller" user (which has an "add product" action on its profile, accessible to the seller user and all shop managers + admins) and not the "shop manager" or admin user creating the product. Without this issue being generic my only option would be to add separate local actions per product bundle.
mvonfrie → created an issue.
mvonfrie → created an issue.
I guess I wanted implement the required update hook but then realized that I don't understand the module enough to do it and had (and still have) no time to dive deeper into the code.
Ok, I just found out that the error why I created ( 🐛 Dynamic property error on PHP 8.2 Fixed ) has been fixed in 1.2.0. But I suggest to keep this to run static code analysis for other deprecations.
mvonfrie → created an issue.
Fixed. Tests are failing due to 🐛 Schema registration_form_mode in commerce checkout pane is missing Closed: duplicate .
mvonfrie → created an issue.
I'm interested as well.
I have a voucher product with the value chosen by the user. To make it easier for both the users and companies providing the vouchers, there will be a product X with variations like 10€, 20€ and 50€. There is no separate stock for the different variations but only a total value per product.
Example: Stock for product X is 180€, then this can be:
- 18 x 10€
- 9 x 20€
- 3 x 50€ + 3 x 10€
- 3 x 50€ + 10€ + 20€
- ... any other possible combinations
mvonfrie → created an issue.
@drugan, shouldn't we better link directly to the 2.0.x branch (https://git.drupalcode.org/project/xnumber/-/blob/2.0.x/README.md) then?
The Call to an undefined method Drupal\Tests\xnumber\Functional\XnumberFieldTest::drupalPostAjaxForm() occurrences require a major rewrite of the tests, see
-
Instructions for converting a Simpletest web test →
drupalPostAjaxForm()doesn't exist on BrowserTestBase and can usually be replaced withdrupalPostForm()this does mean a loss of pseudo-JavaScript coverage, so ideally a follow up should be created to add proper JavaScript coverage using WebdriverTestBase - drupalPostForm() is deprecated and will be removed in Drupal 10 →
In addition I found used but uninitialized variables in the tests, which also needs to be fixed.
Pending tasks:
PHPstan --level 0 fixes
Note: Using configuration file /var/www/html/phpstan.neon.
9/9 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%
------ ------------------------------------------------------------------------------------------
Line src/Tests/XnumberFieldTest.php
------ ------------------------------------------------------------------------------------------
150 Access to an undefined property Drupal\xnumber\Tests\XnumberFieldTest::$url.
489 Call to an undefined method Drupal\xnumber\Tests\XnumberFieldTest::drupalPostAjaxForm().
496 Call to an undefined method Drupal\xnumber\Tests\XnumberFieldTest::drupalPostAjaxForm().
515 Call to an undefined method Drupal\xnumber\Tests\XnumberFieldTest::drupalPostAjaxForm().
520 Call to an undefined method Drupal\xnumber\Tests\XnumberFieldTest::drupalPostAjaxForm().
756 Access to an undefined property Drupal\xnumber\Tests\XnumberFieldTest::$url.
------ ------------------------------------------------------------------------------------------
Resolve depending issues
Update core version requirement
Increase minimum core version requirement to ^9.3 || ^10 as 9.3 is the first version supporting PHP 8.1, the minimum for Drupal 10.
The dependency on readmehelp (which is not yet Drupal 10 ready) will be removed by 📌 Remove dependencies on readmehelp and help module Fixed .
mvonfrie → created an issue.
An option to make this module optional for xnumber etc. is by suggesting it in composer.json. You just have to add:
"suggest": {
"drupal/readmehelp": "Allows automatically to display module's README file on the admin/help/your_module page."
}
This way it will be easier to upgrade the modules to Drupal 10 as well, because the readmehelp module can be upgraded seperately.
Meanwhile as #2946807 is still in development, the hard dependency in xnumber and other modules could be changed into a soft dependency by applying the patch from @tim-diels and suggesting it in composer.json by adding:
"suggest": {
"drupal/readmehelp": "Allows automatically to display module's README file on the admin/help/your_module page."
}
This way it will be easier to upgrade the modules to Drupal 10 as well, because the readmehelp module can be upgraded seperately.
mvonfrie → created an issue.
I just got the exact same error in 7.43 as well.