Sorry, I spoke too soon. "To" does not but "Cc/Bcc" already does. Then only a very small suggestion to mention this in a description below the field. :-)
djg_tram → created an issue.
And the opposite is also missing, am I right? I mean, there's no way to go back to the submission from the usual Commerce order list, or when viewing/editing a particular order.
Yes, but there will be more changes, even with these lines — I hope without regression. :-)
Isn't this the same as https://www.drupal.org/project/commerce_shipping_pickup_api/issues/3406396 🐛 Dropdown or map not showing when default shipping method Active ?
As I also mentioned in another issue, I was working on some bigger changes because I'm involved with a dependent module that also required adaptation the the framework. That seems to have settled by now, so I'll upload the current state as a dev module, I'll not yet really ready to publish is before I get feedback. But this also contains the fix for the first appearance.
Good catch. The module itself is already compatible with D11 and C3 but I missed this.
There will be more changes in the near future, I'll upload the fix then.
Drupal 11 is already supported.
I can't seem to find a merge request that I could accept...
Besides, actually, I have quite a few modifications in my local copy because I needed to add a few things in a site I actively work on. But I'm not really sure each of those is general enough to be included. maybe if I only uploaded them to a dev version...?
@akolahi, @adpo If you're still interested, I added a module to the dev version.
As I moved on to Drupal 11 with the modules, I'm contemplating this. Do you think a complete address provided, just like with the normal delivery? Address, country, city, post code?
Drupal 11 supported.
Drupal 11 supported.
Drupal 11 supported.
Drupal 11 supported.
Drupal 11 supported
I experienced this in a brand new test setup. Looking into it.
@jsacksick Could you not just introduce a breaking change that kills any contrib module that depends on yours dead in its tracks? :-(
You could have been added a new dependency instead of changing it, for instance...
I hope I didn't screw up, I'm much less familiar with this Drupal Git than with GitHub. :-))
I was hoping for a git revert to function but it doesn't. :-) I'll start all over again.
Yes, I actually added that too because I created it in the meantime but feel free to pick.
My actual use case is to issue a redirect to a specific page when the user changes the country (practically to go to the starting page of that country rather than staying on the same page but with a different country setting. I use a correct middleware redirect approach so it doesn't get executed immediately but gets stored in the kernel and is executed when the current request actually finishes.
But, actually, I can achieve the same effect with using a different Country Switcher, a modified copy of yours that creates the URLs according to my specific needs. And this probably is a cleaner approach, anyway.
First, quick attempt but it seems to work for me now. Could you take a look before I create a MR?
djg_tram → created an issue.
Here we go again... Four years later (#10) and mysqli still required...
D9 actually requires PDO.
First, I would also add this file:
commerce_combine_carts.settings:
title: 'Combine Carts Settings'
description: 'Combining different order types.'
route_name: commerce_combine_carts.settings
parent: 'commerce_order.configuration'
weight: 999
as commerce_combine_carts.links.menu.yml. This makes the settings form appear as a link in the normal Commerce settings dashboard.
Second, although I found the carts tobe combined, I'm not sure the shipment methods are handled all right. If the two carts have different shipping methods and rates — and they probably have, that's the main reason for them in the first place — how is that supposed to be handled?
Could you look into it and decide what causes it? I left Admin Toolbar as soon as the new navigation bar appeared in core (even if it's still considered experimental). I like it much better...
I never looked into the code that generates these form elements, so I really don't know. This is just a shot in the dark, but maybe a class of form-indent-level-N would be beneficial.
I can't find anything in the classes that would help us tell apart this case, so it would be a task for the core to add something that we can rely on.
I would, frankly, expect Devel to style their form to indent the dependent fieldset in this particular case.
I'm not sure why this would be a problem: the primary purpose is to remove extra space.
You seem to mix two things here. This specific toolset is, in fact, a dependent fieldset that opens up when the upper checkbox is checked. But this is not a general attributes of fieldsets, this is something specific to this Devel form. If we changed all fieldsets the way you suggest, they would become larger anywhere in the UI, not just in this dependent position.
You're welcome. Although I wouldn't call that linked documentation very clear, it's still much easier than the USB quagmire I'm currently in in another project. Not related, anyway. ;-))
I seem to remember that D.o promised to make this contribution setting automatic some time ago, sad to see it's still not working...
Sure, with code modules where things can go wrong. But with a theme?
OK, I'll look into it, my main problem is that I use GitHub almost daily for Flutter development and know it quite well while with the Drupal system, including their only half-baked solution with GitLab and the old, tedious manual publishing of new versions, I always need to consult my notes to remember how it worked the last time around. :-)
Do you think this is important? The tag is 2.x and I got the upgrade in my website all right, so it seems just fine to me as is. Is it really important to keep the branch name in sync?
I'd give it almost zero chance of not being compatible with 11 as is but could someone with an actual 11 check it out, merely by adding ^11 to the info.yml?
The patch we suggested seven years ago (!), simply casting to array, was already capable of accomplishing this. :-)
I have long moved on since and no longer bitten by this problem but this one is really ridiculous, I have to say. A very straightforward modification that obviously doesn't even require testing, it cannot cause any problems or regresssion by definition, and nobody ever bothered to accept it (or even argue against it). Must be one of the record setters in Drupalland. :-)
When I looked around, I found it discussed in some places that this is deliberate. GitLab, where the source code is hosted, doesn't allow a tag to be removed if it is still referenced, and you have no rights to remove the D.o reference as a mere developer. The D.o team could do it upon request but the old pointers to where we could ask for it are no longer valid.
Sorry, it was an error and the system doesn't allow it to be revoked. I erroneously created a 2.0 tag after 1.9, without giving much thought, and only realized the error later. I deactivated it as much as the Drupal UI allows it but I can't completely remove it.
Yes, works as designed. The reason for it is the Roles.php filter that explicitly removes the authenticated user ID from the list.
The solution is to use a grouped filter.
Set Grouping 1 to Barefoot user and the operator to Only has the 'authenticated user' role. Set all the other groupings to your actual roles, that is, Grouping 2 will be named Role 1, operator is one of your Role 1. Grouping 3 will be named Role 2, operator is one of your Role 2, and so on.
This way you will have a combobox with all your roles plus a simple user at the front.
That's still a critical bug. You have everly right to turn on a module and not starting to use it immediately. A WSOD is hardly acceptable...
Could we urge acceptance of the MR? A WSOD is, after all, quite serious a problem...
I'm not sure how this would be any different than creating a simple, stock flat rate shipping method with a fee of zero...
I never needed to do such a syncing actually, so I wrote this specific part according to the many samples on the net. If you really think this causes no problems... :-)
This isn't the proper solution because first, you don't know whether the site has a default type at all, second, you don't know whether the admin wants to apply the possibility to set a price override to this type, anyway.
A solution would be to remove this field altogether and to instruct the user to create a field with the same machine name on any product type they want to apply the opportunity to.
djg_tram → created an issue.
No, there was a WSOD that blocked everything. I could only solve it by temporarily modifying the source code (as described above). As I do module development actively myself (both some contrib and many for in-house solutions), it was possible but not all admins are created equal. :-)
It depends on the particular site and situation. If I'm already inside a site with smaller traffic volume and requirements (not one that postulates fully separated test and production environments, just the smaller garden variety ones), logged in and just see that a couple of modules need to be upgraded, it's usually much simpler to let it happen there with the UI and then run the update as well. I also use the new Navigation module with my own additions that make both db update and cache clear readily available. In these cases, I only fire up the console access with Drush if necessary (core upgrade needed or WSOD).
With more complex schemes I might go the Composer and Drush route immediately. I don't particulary like the Composer approach for modules, so I tend to avoid it with my own modules but that's more like a question of preferences. At any rate, even if many modules do recommend Composer, I still think that as long as Drupal actually has the old way, that should also work.
Especially as, unfortunately, it's still not always easy to set up an environment that provides full Drush/Composer functionality, I just happened on a site where drush cr works but drush updb does not because proc_open is disabled and while they offer up a few items of php.ini to customize, this isn't among those. And equally unfortunately, just telling the client to move to a better provider is not always the most feasible solution. :-)
I had to:
1. manually remove the Renderer argument from the constructor.
2. Clear cache so that the site will return from WSOD.
3. Re-insert the argument.
4. Run UPDB manually.
5. Then it works.
Not fun. The upgrade process should be tested a bit more, I'm afraid. :-) This was on a production site that isn't used yet intensively. It would be a major PITA on a real production site.
No, a simple cache clear doesn't help.
Same error with updating to 2.0.4, simple cache clear doesn't help.
Yes, that's the possibility but then you probably would want a new setting for the field? Even if the geo module is present, the admin might not want to use it or not for all price fields.
This was a poorly thought out issue for me to have opened.
Not necessarily. :-) Now that I looked into the code, it's not really much. It looks for either of the two dependent geo-ip packages and if present, asks them for the country. Really nothing duplicated, just a single call in each case. And then commerceguys/intl seems to maintain a country > currency map that could be queried to get the currency. All that could be placed into a very simple submodule providing this optional resolver. I'm not sure I'll have time to play with this for a week or two, and I also have something else I promised in another issue to look into but if you feel like experimenting with it, sure. Or wait a little and I'll try to do it a bit later.
This module clearly states in the README that it doesn't do any resolving on its own but uses resolvers found in the system. Which is, in my opinion, the correct approach because it separates the actual multi-currency support from a selection of additional behaviors whose requirements might be different from site to site. I was well aware of that module before I started working on mine and, frankly, this was one of the reasons, I needed a cleaner solution that makes the multi-currency handling as automatic as possible — and I thought that others might benefit from it, too.
I added explicit support for Commerce Exchanger because it's a very common requirement (I use it, too). Other resolvers can be added in a similar way if it's not possible to rely on them automatically, without any extra support, just as part of the resolver chain.
I'll try to find some time to add the conditional handling in the coming days...
I don't see what benefit hook_install would provide in this case. It's really only about a single try-catch, nothing else.
No, that's not how it works. If you use Docker, for instance, it's your responsibility to add dependent packages each time the container is rebuilt. I usually do it by adding an .sh script in an init folder, then referencing from the docker-compose.override.yml as
volumes:
- codebase:/var/www/html
- ./init/30-composer.sh:/docker-entrypoint-init.d/30-composer.sh
The actual script can call the usual composer require calls but if you want to make sure you only call them unless it's already installed, you can use:
composer show | grep -q foo/bar || composer require foo/bar
Most definitively not solved and hardly as designed. It succeeded in making my site completely unusable after installation (fortunately not a production site but still). Error message as above. Cache refresh goes without issues. DB update say nothing to update. I can't remove it because drush pmu cannot find the 'secret' and 'confidential' fields in the 'consumers' table. You cannot add those manually because the schema will refresh them, of course. Complete checkmate. I'll find a way out somehow but you can be dead sure I'll never revisit the module. :-)
(Addendum, .install should warn about the required packages. You should never rely on everybody using composer to install. I looked into composer.json first because I was cautious but if a module breaks without its required packages then do you homework to make it clear before installation. And document it clearly.)
Requires "league/oauth2-server" and some other packages. See composer.json.
Those checkboxes, unless I'm mistaken, only work when accepting a PR, don't they?
I'm active in a couple of other dev communities where this is handled automatically, yes. It isn't advantageous at all that D.o made it that convoluted, also including how to make a new release. But in one point you're not mistaken, I'd consider it totally unnecessary to create PRs for my own changes and do the whole routine in an even more convoluted way.
I certainly doesn't want to conceal contributions, quite the opposite, I'm grateful for them. I could've accepted the PR in the first place but frankly, both changes were so minor that, given the extra complexities of the D.o process in general, this seemed much more efficient. I never intended to create animosity, so I apologize if someone feels so, but I'm not sure I can change those boxes now after the fact.
That's true and a good catch, I created it on a site where shipping was present and I never actually realized that this is an extra dependency. We have to look into how we can make it optional. Actually, none of processors mentioned there is essential. If you look into the code, they're purely there to put their calls inside a try-catch block. The stock Commerce merely throws a `CurrencyMismatchException`, resulting in a WSOD, if the cart has items in more than one currency, I only wanted to avoid that and show a regular, user friendly error message instead of the WSOD. So, in your particular case, you should be able to simply comment out `commerce_currencies.safe_early_order_processor` and `commerce_currencies.safe_late_order_processor` without any further issue.
I never decorated an existing class conditionally. Now that I googled for it, maybe https://www.drupal.org/docs/drupal-apis/services-and-dependency-injectio... → would be the solution?
Both the commit and the actual changelog of the new version refer to this issue. I'm not sure D.o allows us anything more than that but do tell me if I missed something.
Thanks, I had other a few other changes lined up, so I added it directly instead of the PR.
I'm not sure that would be enough. I added the JS, the arrows appear but the functionality is still missing. What's your experience, does it work for you?
Could it be related that I seem to get tons of "Theme hook se_twitter not found." warnings in the log recently? Looking into the code, it's "se_x" now, of course. Yes, an older site, before Twitter was renamed.
May we suggest a new released version? This is a rather major issue.
The problem is with the Commerce Cart module, it should be reported there. The viewsFormSubmit() function simply grabs the order item from the view and this apparently means that if an order processor (not just this module but any order processor) modifies the order in the meantime, the cart will grab the wrong one.
djg_tram → created an issue.
djg_tram → created an issue.
I never followed this discussion, so I'm not entirely certain it's related by I have a suspicion it is. After upgrading to 10.3, I accepted the proposition and disabled the module. I was immediately greeted with "Entity view display 'xxx': Component 'yyy' was disabled because its settings depend on removed dependencies." warnings. A terrible excuse of an error message because it doesn't even try to identify the issue but by adding a debug printout, the actual dependencies are from Layout Builder, hence my suspicion. These views don't use Layout Builder, actually. Every single page refresh generates such warnings, so the log is literally inundated with them.
So, I just followed Google's trail here. There's no `/admin/config/content/layout-builder`at all, is this something that got removed in the meantime?
djg_tram → created an issue.
I wonder why is it so hard to document it... :-))
The required dependencies are:
composer require html2text/html2text
composer require symfony/mailer
composer require tijsverkoyen/css-to-inline-stylesIt's there in the .install file but not every Drupal admin is a programmer and would to know where to look.
@pvbergen -- This module is obviously abandoned, I'd say the best solution is to quit using it and if you need the functionality, use your own module or start another one. I never did, as I described two years ago, I came here to chime in because my own code had the same problem.
Two years ago, one of the core members of the Drupal team clearly described that the solution this module had used previously was plainly wrong and provided the proper solution. After that, two days of testing should have been enough to change it for once and for all. This never happened, so, after all that time, there are inevitable conclusions to draw...
@vacho -- Put a dpm() or similar dump into the first line of that function and check $queue to see which worker actually causes the problem. Then investigate that worker. I had the same problem and it turned out to be an error in the worker's dependency injection (I'm developing it right now, so it was my error in my case). If it's your code, fix it, if it someone else's, contact them for a fix. As it looks, this isn't a Drupal core issue at all -- as soon as I fixed my own code, it went back to normal.
Basically, the first thing to check is whether line 206:
$worker = $this->queueManager->createInstance($queue_name);
can actually instantiate the worker at all. Note that various source sample floating around the web are erronous, if you happen to develop your own worker, be sure to take them with a huge grain of salt.
@vacho -- That's not a solution. This merely silences the error but the worker will never be executed then, given a lease time of nothing.
For those who happen to be in my shoes: create a route subscriber and alter the route `image.style_private` to your own controller. Copy `Drupal\image\Controller\ImageStyleDownloadController\deliver()` to it and modify it to either do something entirely different, or probably just handle your own case and call `parent:.deliver()` to get the original behavior.
Oh, dear me, a major showstopper and nothing has changed for years. :-( That hook would be desperately needed, up to the latest 10.1 and more... What could we do to make it happen ASAP?
While item 1 has its merits, I don't think item 2 would be of any importance. :-)
Actually, the code allows it, so I can't really see any reason not to allow from the UI as well.
From https://www.drupal.org/project/symfony_mailer/issues/3388098: →
AdamPS: However I have my doubts as
1) The description for the site mail field says this:
The From address in automated emails sent during registration and new password requests, and other notifications. (Use an address ending in your site's domain to help prevent this email being flagged as spam.)
2) AFAIK it isn't possible to configure sender in the GUI in other similar modules
djg_tram → created an issue.
Yes, I'd very definitely vote for the possibility. In my current case, the website owner prefers a gmail address for the site so that any system correspondence goes there. But when he tries to send e-mails from the site to his customers, the Sender and From have to use the same domain the site is running on or else the SPF will not match and services like Gmail itself will simply consider it spam and drop it silently.
As far as I can tell, From can be changed but Sender can't.
djg_tram → created an issue.
Published in a new version, thanks.
@sleitner @Siegrist -- OK, another week has passed. I started a new project at https://www.drupal.org/project/commerce_shipping_pickup_api → and started to move my own modules to depend on it. I'd be glad to see new submodules to appear. :-)
A better way that, I think, handless all cases:
switch ($options['type']) {
case 'table_fields':
if (!empty($configuration) && $options['entity_type'] == $definition['entity_type'] && $options['parent_entity_type'] == $definition['parent_entity_type'])
$plugins[$plugin_id] = $this->createInstance($plugin_id, $configuration);
break;
default:
if (!empty($configuration) && $options['entity_type'] == $definition['entity_type'] && $options['bundle'] == $definition['bundle'])
$plugins[$plugin_id] = $this->createInstance($plugin_id, $configuration);
break;
}