yang_yi_cn → created an issue.
ok I have same issue and google search landed me here.
I think there is a workaround, but reply #2 was not very clear.
Basically in the UI, if you already have "title" then it shows as required. But you can edit the YAML file and delete the "#title" completely, and the UI will still work - the title input will disappear and being replaced by a "key = [title]" thing instead. And on the rendered form, the title / label will disappear.
yang_yi_cn → created an issue.
I'm not that much an expert on these a11y things but can we combine this one with ✨ Accessiblity - Remove aria and alertdialog from module Active ?
yang_yi_cn → created an issue.
yang_yi_cn → created an issue.
We have the same issue. I think if it's "by design" then the design is wrong.
Bascially whatever "FROM" you set in the Newsletter settings, it doesn't work, It always fallback to site default e-mail.
I'm not sure about "Return To" part, but from my reading / testing, the $headers['Sender'] is actually needed to get a proper devliery. Just setting "FROM" address will get ignored by most mail servers such as Outlook, Gmail etc. Maybe we should test if it's empty befor settings it?
$headers['Sender'] = empty($headers['Sender']) ? $this->getFromAddress() : $headers['Sender'];
Ok I guess this is somewhat a documentation (or maybe adding to description so it could be a "Coding") issue.
Basically, this ticket is about "Invalid unsubscribe link for TEST", which is the NodeTabForm at a newsletter node > newsletter tab, where you can send test emails to preview, without actually sending the email to the whole list, very useful feature.
The NodeTabForm.php load the "current user email" as the DEFAULT e-mail (this is important),
then does some validation to ensure all emails are valid emails,
then eventually calls
$this->mailer->sendTest(...
where the Mailer.php does the test sends. However, during the test send, it checkes if the emails are actually subscribers or not. IF THE EMAIL IS NOT A SUBSCRIBER, IT PASSES EMPTY SUBSCRIBER TO THE EMAIL BUILDER.
It all makes sense but now
- if the current user doing the test is not a subscriber to the newsletter
- when email subscriber is empty, the [simplenews-subscriber:unsubscribe-url] token replacement is skipped, so the token is still there in the body text.
- MimeMail does a check on all links and found
- WSOD
I think for the bare minimal, we need to add this info after the test email description "A comma-separated list of email addresses.", so it becomes:
"A comma-separated list of email addresses. The e-mails MUST BE SUBSCRIBERS OF THE NEWSLETTER, or the unsubscribe URL might cause the sending to fail."
Or ideally we validate those emails are actually subsribers when submitting the NodeTabForm, and if they are not subscribers, show an validation error.
The "fix" seems to be breaking it again...
The website encountered an unexpected error. Please try again later.
InvalidArgumentException: The user-entered string '[simplenews-subscriber:unsubscribe-url]' must begin with a '/', '?', or '#'. in Drupal\Core\Url::fromUserInput() (line 216 of core/lib/Drupal/Core/Url.php).
Drupal\mimemail\Utility\MimeMailFormatHelper::mimeMailUrl('[simplenews-subscriber:unsubscribe-url]') (Line: 207)
Drupal\mimemail\Utility\MimeMailFormatHelper::Drupal\mimemail\Utility\{closure}(Array)
preg_replace_callback('/(<a>]+href=")([^"]*)/mi', Object, '
Mime Mail message template
Rebased again to bring up upstream changes, so the patch can apply.
The patch is available at https://git.drupalcode.org/project/feeds/-/merge_requests/28.patch, but I'm saving a static copy here as well.
yang_yi_cn → made their first commit to this issue’s fork.
yang_yi_cn → created an issue.
yang_yi_cn → created an issue.
FYI I just comment out the line
...
// 'type' => MENU_CALLBACK,
...
and the drush dmu:upgrade can continue to run. Even generated the routing, links, controller, form files. (not 100% correctly, but did most of the work).
If you looking at the source code (in HookMenu.php), it's trying run a
eval(...);
on the you module's D7 hook_menu(), i.e.
eval("my_module_menu() { ... }");
which provides the function in PHP runtime, then called later in a call_user_func()... to get the returned values ($items), then parse the items to generate D8 code.
In other words, as long as you can somehow return the array, the details in the array doesn't need to be 100%. Also I believe the D7 concept of MENU_LOCAL_TASK, MENU_CALLBACK are deprecated anyway.
MENU_CALLBACK is just a routing with no links.
MENU_TASK / MENU_LOCAL_TASK are routings + menu links, but there's no "LOCAL TASK" anymore.
So just comment out the type seems to be a reasonable solution.
I'm taking over this module and released a new version.
I haven't run coding standard checks on it though. If someone can re-roll a patch against new version I'd be happy to apply it.
fixed in 2.0.x branch.
new D9 version released
any updates on this? @apaderno
ok I'll wait 14 days in this issue then.
yang_yi_cn → created an issue.
yang_yi_cn → created an issue.
The screen shots of the patched version makes senses. I manage a lot of multilingual sites in Drupal 7 and I always creates a view similar to the patched version to replace the default node admin page.
It does make more sense to have "language" before the "title" search box because you want to ensure the language is right before your type the keyword to search.
On my views I have the "language" filter right after the "publish" filter, even before "type", but I guess after "type" is ok too. In my logic maybe when I try to find a content I always think language first, then the type, e.g. I will want to find something in English, in News or Blog types, with some keywords in title.
I also tested #149,
My view has a pager. After applying the patch the result for anonymous users changed from nothing to show the first page, but the pager disappeared. In the meaning time, Root user can see the pager with no problem though.