That would have to happen with some custom code in addition to this module
Opened a MR with another approach, also working for me.
I have a feeling that we are sort of working against an anti pattern for example in contrib here, so not totally sure this is needed. However, it's probably going to continue happening, so it's nice to guard against it at least.
OK, so here is a minimal reproducible recipe (also updating the IS):
- Install drupal using minimal profile
- Enable views module
- Create a new module called mymodule.
- Create an install file in this module containing this
/**
* Implements hook_install().
*/
function mymodule_install() {
\Drupal::configFactory()->getEditable('views.view.content')
// Make extra double sure this is actually going to update the title, with
// adding a time factor here.
->set('display.default.display_options.title', 'overridden title here' . time())
->save();
}
- Enable the mymodule module
- Export the config
- Reinstall the site using existing config (for example with drush si minimal --existing-config -y)
thorandre → credited eiriksm → .
Closing as probably only 2.x will get d11 support
Good question
Personally I think as long as there are no direct conflicts in dependencies we can continue to use it. But let's keep this open for sure.
What do you think?
This is also resolved in https://www.drupal.org/project/sparkpost/issues/3398176 🐛 The mime type guesser service is changed for d10 Needs review
That issue needs review. Maybe test that patch and mark as rtbc if it works for you?
Allowing the from to be set can lead to quite a few unsent emails, as sparkpost requires you to use a verified sender domain
The reply to seems like a good idea though. Would love to see some tests though, to ensure we don't introduce any regressions 🤓✌️ Are you able to code up some of that?
Well, no, not really. They are completely different modules. Trying to monitor issues as best as I can, but not really super well maintained no, is it? Anyway, the module is not abandoned or stuck in my own opinion, and adding that message would be misleading.
I really do appreciate the concern and attention, thank you for your contribution ♥️🤓
eiriksm → created an issue.
Just a friendly bumpety bump and nudgety nudge here.
Would be great with a new stable. And I am happy to help ✌️
I see. I never set that variable so I guess it was a comment regarding using the out of the box setup. As a consequence, I assume since run tests makes these appear maybe we could pass the same arg to the PHP unit command? The listener class, that is
thorandre → credited eiriksm → .
♥️
Just wanted to highlight my comment was not meant as snark or impatience. I see it comes across as a bit short and unfriendly. I was typing on my phone and simply wanted to make sure we did not forget that detail. I will try to find some time for at least doc suggestions this week hopefully
Echoing myself and #65.
The current setup still requires a maintainer to add phpunit.xml.dist to the repo (or I guess use the extra option mentioned)
I think it would be nice to either provide this by default or more clearly document this
Fixed in another issue actually
Coming back to this issue once again, after adding default_content_deploy on a project. This issue is marked critical and fixed, after which there has not been a new release. I promise I will stop with these nudges if we can get a new release out? :p
nudge nudge nudgy nudge :D
Awesome 👍♥️
I think we should keep but deprecate the service though, so putting back to needs work
I think I managed to change the default branch now as well ✌️
Awesome 👍♥️
Of course.
At this point mostly interested if this makes sense to other people than me, but if I should read something into your comment I would say it currently does not seems like the opposite at least
drupal gitlab is slow today, but I did create a MR and I expect it to show here at some point, so the status is now needs review
Actually it's this piece of code, so not actually variations:
// The default form ID is based on the variation ID, but in this case the
// product ID is more reliable (the default variation might change between
// requests due to an availability change, for example).
$form_object->setFormId($form_object->getBaseFormId() . '_commerce_product_' . $product_id);
In product ProductLazyBuilders
Those IDs are probably correct, yes. The actual changes I had locally were changed for the core issue, so I winged it ;p
Yes, such a setting was exactly what I had in mind actually. I will post a MR once the queuing of Drupals gitlab catches up, there are some slowness happening today apparently.
If someone lands here wanting a solution, one way is to decorate the module handler with your own one, extending core.
Then, either via hardcoding it like this, or by somehow dynamically (hook_hook_info for example) indicate which implementations should be simply "discarded":
protected function getImplementationInfo($hook) {
// Harcoded example.
$form_id_prefix = 'form_commerce_order_item_add_to_cart_form_commerce_product_';
if (strpos($hook, $form_id_prefix) !== FALSE) {
return [];
}
return parent::getImplementationInfo($hook);
}
eiriksm → created an issue.
I actually changed my mind, and added it to the form array instead, since I realized this would actually make it possible to alter base forms from custom code, that you would not want to alter the form_ids for, which can be convenient :)
Pushed a very naïve implementation of it with no tests. Since there is no "API" to sort of manipulate from a form class to communicate to the form builder, I went for using the build info. Which you can control inside of a buildForm method like so, for example:
$build_info = $form_state->getBuildInfo();
$build_info[FormBuilder::SKIP_ALTER_FORM_ID] = TRUE;
$form_state->setBuildInfo($build_info);
Would obviously need some tests, but setting to NR to get some feedback
eiriksm → changed the visibility of the branch 3441006-make-it-possible to hidden.