🇭🇺Hungary @djg_tram

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-styles

It'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;
}

A quick solution would be to change the condition near the end of InlineEntityFormAlterManager::getInstance() to:

      if (
        (($options['type'] == 'table_fields') && !empty($configuration) && $options['entity_type'] == $definition['entity_type'] && $options['parent_entity_type'] == $definition['parent_entity_type'])
      ) {

Actually, I can't decide what the optional part comparing the counts of the two array was intended to do in the first place...

djg_tram → created an issue.

@sleitner I didn't mean to do it in the first place but maybe a fork under a different name? I really didn't want to make it look like hijacking :-) bt I've already tried to contact Siegrist before without success...

Yes, that should be the best way forward but we need @Siegrist for this...

No need to upload it, it's already up in a fork -- I completely forgot and without the link in the issue at https://www.drupal.org/project/commerce_shipping_pickup/issues/3246790 → I'd probably never find it again. :-)

Anyway, it has its branch to browse at https://git.drupalcode.org/issue/commerce_shipping_pickup-3246790/-/tree...

And the documentation referred to above: basically, we have two different approaches: list and online selector. Providers normally use either or both:

• they can provide a list of available pickup points, indexed by some identifier. In this case, the user is shown a list to chose from.
• they can provide an online selector, usually a map, to be embedded mostly as an IFRAME, that the user can use to select a pickup point.

The module handles both cases and has the documentation to describe them. In addition, existing submodules like the ones I mentioned can be used to follow how this works in real life.

From the modified README:

# Commerce Shipping Pickup

Provides the framework for shipping methods for pickup services and parcel machines.

**This module only provides the framework. In order to use actual pickup service operators,
install at least one dependent pickup service module (usually named _Commerce Shipping Pickup
Some-Service-Name)_.**

## Developing dependent pickup service modules

The user-friendly way is to create one module per operator,
and a module can provide more than one actual service. For easy discoverability,
the suggested name is in the format _Commerce Shipping Pickup Your-Service-Name_
(with the short, module name `commerce_shipping_pickup_yourservice`). If you have a module
with multiple services of your country's national postal company, you probably want to name
the module by country and company. If you have a separate operator with a single specific
service name, you may want to use that. At any rate, use a name that you know
the site builders will easily find.

### Shipping methods

You need to inform `Drupal Commerce` about your services by creating a shipping method for each.

Extend `PickupShipping` with your shipping method. This class provides the same functionality
as the usual flat rate shipping methods: a rate label, a description and an amount).
If you need your own configuration or rate calculation logic, override the appropriate functions.

`PickupShipping` implements `PickupShippingInterface` and has two abstract functions
that you **must** override (or you get an exception). `buildFormElement()` provides
the pickup point selection interface to the user and `populateProfile()` gets back
the necessary information from this interface about the user's selection and stores it
into the shipping profile in the order. Follow the documentation in the interface
to understand the connection between the inline form and the storage of the pickup point.

See the `commerce_shipping_pickup_demo` sub-module for a minimal sample.

@sleitner Last year, Siegrist and I worked together on a modified version of the module that changes its functioning in some ways. I have four submodules ( https://www.drupal.org/project/commerce_shipping_pickup_foxpost → and others) that build upon this module as a programmer's API, implementing the actual pickup providers. We agreed that, considering the low number of actual users, making breaking changes is probably acceptable at this stage. Basically, this module would no longer be a standalone module (although it does contain a sample) but provides the foundation for submodules to build upon. At least, I hope my recollection is correct, anyway, I still use this modified variant of commerce_shipping_pickup in my projects (I'll copy fragments of the modified README in the next post).

My submodules are D10-compliant and the main module can be made, too, with very small amount of work, I'll test it in the coming days. Starting from that, I'd suggest to @Siegrist and y'all to use this transition to D10 as a point to make this change. I'm willing to take whatever part is necessary in it, maybe if Siegrist picks it up again from where we left back then, or maybe allowing me the status to upload the new version.

If Siegrist doesn't happen to react in the near future, I could also upload it somewhere, GitHub or elsewhere, if any of you is interested and willing to experiment with this approach. I also need the functionality going on, so I'm willing to take part in any shape or form to move it forward. :-)

@ckrina, actually, it was a few months ago already, and I've been simply using it without thinking much about it. I don't know how I could describe what was changed without simply resorting to a "look it up in the CSS". :-)) I think I touched most containers and almost all changes are padding and margins where I mostly simply moved to a smaller variable: for instance, you might have used var(--space-m) somewhere, I modified it to var(--space-s) and similar. There are two or three font size changes, too.

@ressa, anything that you would care to mention as an issue so that I can look into?

1. There is no "project", "datestamp" or "version" in the yml file. As the log shows, you were trying to check the downloaded version on your own disk -- this, obviously, doesn't check the code in the repository.

2. It's not the first time this comes up: I couldn't care less about the 80 character limit. Please, stop mentioning it in the issue queue, I will not change it.

It's still broken in Drupal 10.

It's still broken in Drupal 10.

I can see your point but in this particular case, this is cleary something I don't intend to do. This is not a new theme that needs visual description. This is a modification of the default admin theme, bundled with Drupal, available to each and every admin, that only intends to modify spacing and doesn't even touch the positioning and layout of the regions.

I'm not sure I know what you mean by that. :-) Yes, those are the regions. They're the same as with Claro, only a little bit more compact.

Added.

Some of it probably already changed in 1.0.1.

@longwave That doesn't really help because D10 is also full of deprecated message (including this one).

Being warnings, things are not critical per se, but this makes the log practically unusable. So, some co-ordinated effort to root out these deprecated things would be very welcome. :-) Yes, I know, everybody is free to contribute but not all of us are actively participating in core. So, the question is whether you, who do, can at least inform us whether this is something that is currently undertaken or not.

No, not really, I've been using it myself from day one on several sites, without the slightest problem -- or else I would fix it :-))

Could you be a bit more specific? Can you assign the blocks in the Compact theme? Maybe you lost the previous assignments (although this isn't supposed to happen, either) but you can re-assign them again?

Is your base-ckeditor5.css included in the first place? I had problems with it in a similar situation.

Thanks. I probably won't chime in there because, frankly, I can't be bothered, I just ignore it. And, as far as I can see, nobody argues for it, anyway... :-))

The indentation typos are clear but, to tell you frankly, I probably can't be forced to change the 80-line. I consider it one of the stupidest assumptions in 2023 and fight it tooth and nail in other languages and IDEs as well. People don't use 80-line VGA terminals any more, neither do I, there's absolutely no sense in this requirement, quite the opposite, it makes contemporary programming a pain.

I'm a very strong proponent of legible, well organized code but this just flies in the face of all that.

Converted. Also uploaded a new version with some changes I forgot in the initial release.

Already published around that time. :-)

@ressa, your wish is my command. :-) Actually, I had the same problem, in order to switch to Claro, I had to modifiy it to be usable. So, I created Claro Compact → .

No problem so far, thanks.

Thank you, it works just fine now.