If you need further assistance, please change the status back to active.
bluegeek9 → changed the visibility of the branch 8.x-1.x to hidden.
bluegeek9 → made their first commit to this issue’s fork.
bluegeek9 → changed the visibility of the branch 8.x-1.x to hidden.
bluegeek9 → changed the visibility of the branch 3542118-submitting-a-blank to hidden.
bluegeek9 → made their first commit to this issue’s fork.
I avoid DeprecationHelper because it requires 10.3, and the minimum is 10.1 for Easy Email
DeprecationHelper helps modules support multiple versions of core →
I am unable to find evidence from the Drupal ecosystem of other projects using Mx. as an honorific. Introducing it without precedent risks imposing novelty and additional workload on contributors—especially volunteers, many from the very groups your advocacy seeks to support, including those defined by ethnicity, nationality, socioeconomic status, language, (dis)ability, age, religion, or political perspective. Well-intentioned advocacy must account for real-world implementation costs.
The claim that failing to include Mx. constitutes exclusion raises a critical question: if inaction is itself an act, where does it end? If the absence of a single honorific is morally exclusionary, then the omission of every possible honorific in every culture would also constitute exclusion. This reasoning collapses under its own universality, making everyone guilty of every omission. Defaults in software should serve the broadest range of users with minimal friction, not enforce ideological symbolism.
Diversity, equity, and inclusion are outcomes we all support, but achieving them in software is procedural: systems must allow flexibility, empower communities, and enable contribution without coercion. A more sustainable path is to document Mx. as an optional honorific in the README, allowing those who wish to adopt it while preserving usability and fairness for all. Inclusion is meaningful only when it respects both ideals and the practical limitations.
This project might be what we need. https://www.drupal.org/project/physical →
I think we accomplish this with the core workflow module, and a change to the data model.
✨ Workflow Integration Active
I have been researching names. There is an argument that we need more/better support for family names - tribe, clan, and other name parts.
This is a schema change, and would need to be done in a major release.
bluegeek9 → made their first commit to this issue’s fork.
bluegeek9 → made their first commit to this issue’s fork.
bluegeek9 → made their first commit to this issue’s fork.
I think the status field + Workflow integration is the API.
bluegeek9 → changed the visibility of the branch 8.x-1.x to hidden.
bluegeek9 → made their first commit to this issue’s fork.
Were you able to resolve the issue?
It does sound strange. No others users have reported the same issue. I am inclined to conclude the issue is either caused by using the dev version (8.x-1.x-dev), or by you local environment.
bluegeek9 → changed the visibility of the branch 8.x-1.x to hidden.
bluegeek9 → made their first commit to this issue’s fork.
bluegeek9 → made their first commit to this issue’s fork.
I have been looking at PhpMailer 7. We will probably support both 6 & 7.
drupal/phpmailer_smtp is a similar module to drupal/smtp. You probably do not want both installed.
If you composer remove drupal/phpmailer_smtp you might be able to uninstall smtp.
bluegeek9 → changed the visibility of the branch 8.x-1.x to hidden.
Thank you @hoporr,
I think the reason I was not able to reproduce the error is this was "fixed", but a hook_update_N was not created.
Have you been using Visitors long or recently?
I will take a look at this again.
bluegeek9 → changed the visibility of the branch 3195287-config-form-displays to hidden.
I ended up merging the similar issue. Your solution is also good. I am setting the status to fix so I can grant you credit.
Hi Ryan,
I am assuming you were able to resolve your issue. If I am wrong please change the status to Active.
bluegeek9 → changed the visibility of the branch 3315743-contact-module-messages to hidden.
bluegeek9 → changed the visibility of the branch 8.x-1.x to hidden.
bluegeek9 → made their first commit to this issue’s fork.
I reached out to the maintainer who last committed to RedHen and Party.
We should only reach out to the Drop Times after a beta release of CRM
It also updates config in
system.mail.
I think this is a problem. I think it should only update smtp.settings.
How do you think it should work?
I think SMTP should report if smtp setting is enabled but system.mail default interface is not the SMTPMailSystem. The report message should include a link to a form to set SMTPMailSystem as the default. I think any changes to system.mail should be transparent to the user.
Should this be a dev dependency?
If the site builder installs social_link_field we add field storage for crm_contact. Maybe add a field to person type.
Hi @jurgenhaas,
If the user is importing the configs, the system.mail:interface.default is set in the configs. It seems wrong to set this as part of the import.
There issue sets the value when the form is saved, 🐛 prev_mail_system is not saved after being set Needs review
There are some issues asking for a message when the default interface is not SMTPMailSystem.