Reroled patch #14 against 8.x-5.4
Ahh, there it is, I must have forgotten to add you to the credits list after commiting, sorry about that.
I've used the git command created here in the issue to give you credit, it also says "by ..:" in the commit message. According to: https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... →
However you're right it doesn't show on your Drupal profile page, it usually just works, don't know why you haven't gotten the credit.
I'll make sure to give you full credit on the next release notes, I know this wont show up on your Drupal profile page, sorry.
I've made an official v2 beta release, which includes this logo.
Thanks all!
Great thanks again, I'm planning on making a v2 release next week, I'll include this in it.
Thank you for the merge
I've created a new v2 branch, updated the core requirements and merged the request.
I'll try to find the time next week to make a v2 release so this gets out there. Thanks again for your code and patience.
Hi thank you for the merge.
I agree that type hinting is always an improvement, for phpstan and IDE integrations, but I feel this is something that should be handled in core instead, since adding this would change the developer experience when the ✨ Allow end date to be optional Needs review is implemented in core.
Sorry for letting this issue hang for so long.
Hi thanks for all the work. I've merged the request.
I'm new to merges and credit, so of course I did it wrong. I'm so sorry about that.
I'll make sure to include all the people who helped in the release notes.
I'm aware this doesn't show up on your Drupal profile, again sorry.
Hi, sorry for the late feedback.
Thank you for the logo.
I know it's minor, but there's a line of pixels peaking out at the top and left of the darker top overlay.
That should be it, then I'll include the logo in the next release.
You are right, I'll make a new release, sorry for missing this.
Merged, thanks all.
I don't intent to use GitLab CI, if you would remove it from the fork I'll merge it afterwards.
Yes you are absolutely right!
This will break on sites using a core version older than 10.3.x so I'll make a new 2.x version of optional_end_date with these changes.
It's primary administrative work on my part, but I still need to find the time to do this.
Hopefully I'll get around to it soon.
I'm unsure of how the merge request works against a new branch, with credits and all. I'll make an update in this issue if I need you to update the merge request to keep credits, maybe it's all done automatically never tried it don't know.
After I've been working more with the tmgmt module, I realized my previous assumption about the conditions in findReferenceEntity() was wrong (and introduced an error where the first paragraph was chosen for cloning each time).
Sorry if this has caused any confusion!
Anyway, I think the problem (in my use case) is the $entity passed to the doSaveTranslations() function, is not using the jobs source language.
I've supplied a patch that sets the entity language in the saveTranslation() function.
This is the correct patch.
The patch from
#33
✨
Integration with paragraphs asymmetric translation
RTBC
almost did it for me.
But if the target translation had less paragraphs than the source, the extra paragraphs wasn't added.
I've moved around on some parentheses, so the condition is (OR):
$referenced_entity->id() == $field_item[$property]['#id']Same entity($item_delta === $delta && !$is_target_type_translatable)Same delta, and not translatable$is_asymmetric_translation_modeIs asymmetric paragraph
I recently had some caching issues with the "Redirecting when not in context of a controller". And without knowing about the existing EnforcedResponseException solution, I implemented an almost identical workaround.
I'll make a shameless plug to an article where I summarize the implementation: https://blog.birk-jensen.dk/drupal-http-redirection-from-anywhere
I've just tested the #29 patch on version 2, it applied and worked as expected.
The (optional) part of the label is not optimal UI, but I don't think removing it will better the experience.
Do reopen this, if I'm wrong here.
I'll share a quick overview of our implementation in case it has value for anyone ending in this issue.
We ended up implementing a skipsend in the $params argument, and then having a PHASE_POST_RENDER hook (I think this could be any phase hook) set the the transport DSN to a
NullTransport</mail>.
The hook is as follows:
<?php
function hook_mailer_post_render($email) {
if ($legacy_message = $email->getParam('legacy_message')) {
if (!empty($legacy_message['params']['skipsend'])) {
$email->setTransportDsn('null://default');
}
}
}
?>
This assumes there's a <code>NullTransport transporter named null for it to work. And in our preview controller we're calling the mail with the extra parameter but with $send TRUE (so MailManagerReplacement::mail() and LegacyEmailBuilder::buil() wont end the process to early) :
// ...
$params['__skipsend__'] = TRUE;
$result = $mailManager->mail($module, $key, $to, $langcode, $params);
// ...
Thank you for your input on the issue, and all your work on the module!
I can't find any issue related to this, so I'll ask here.
What are the blockers for creating a new beta/rc?
I don't think the patch would have any performance impact for sending mails (it would though for not sending mails with $send FALSE).
I hadn't thought about using the NullTransporter, thank you for the idea, we should be able to implement a non intrusive module with that approach.
It might be an unusual requirement, but it's a feature we have provided clients, to give them peace of mind before sending out emails.
This issue is out of scope for this module, so I'm closing it.
Included a proof of concept patch that works in my particular situation.
It's a quick fix, and I've not looked into any side effects of the patch.
Maybe someone with more experience in the symfony_mailer module could point out any obvious flaws.
I've been looking into this a bit, and it seems relationships is almost supported (and I'm sorry if my observations below is all over the place, I'm just brainstorming out loud).
Like Graber stated the relationship needs to map to the correct keys, which is here: https://git.drupalcode.org/project/views_bulk_operations/-/blob/7a991c4c...
$base_field_values = [];
foreach ($batch_list as $item) {
$base_field_values[$item[0]] = $item[0];
}
The item[0] is the base ID, but the seems the ViewsBulkOperationsViewData::getEntity() already supports relationship and gets the correct entity, it's inserted in $item[3].
So by simply changing the $base_field_alias to the field alias of the relationship it should work.
I'm making the assumption that the table alias is [relationship base]_[relationship_id], I'm doing this because I can't find a reliable way of getting the table from a relationship. So if I rewrite the code in ViewsBulkOperationsActionProcessor::popuplateQueue() to this:
if (empty($this->bulkFormData['relationship_id'])) {
if (isset($this->view->query->fields[$base_field])) {
if (!empty($this->view->query->fields[$base_field]['table'])) {
$base_field_alias = $this->view->query->fields[$base_field]['table'] . '.' . $this->view->query->fields[$base_field]['alias'];
}
else {
$base_field_alias = $this->view->query->fields[$base_field]['alias'];
}
}
else {
$base_field_alias = $base_field;
}
}
else {
$viewsData = Views::viewsData();
$relationship = $this->view->getDisplay()->getOption('relationships')[$this->bulkFormData['relationship_id']];
$table_data = $viewsData->get($relationship['table']);
$relationship_table_alias = $table_data[$relationship['field']]['relationship']['base'] . '_' . $relationship['table'];
$base_field_alias = $relationship_table_alias . '.' . $table_data[$relationship['field']]['relationship']['base field'];
}
It seems to work in my particular case.
I know this is a hot mess, it's a hack that did it for my use case. Maybe a proper fix is not that far away, the current project I'm working on just don't allow me to spend the time I need to dig any deeper.
I have a view I can't "reverse" as well, has anyone had any luck getting VBO working with relationships?
(A hack would work for me as well)