Naming of views and their variant displays.

[Graham-72]

Each view has a name and within a view there is one or more displays identified with a suffix like ':page' and ':page1'. The use of this colon would seem to be a problem because the view name is passed to the mail system and used to identify the template for the HTML body of the email.

For example, the template file names for use by the mimemail example module might be mimemail-message--test.tpl.php and mimemail-message--test2.tpl.php, where test and test2 identify specific templates to be used for the type of email.

So we need to modify the names used by views_send, in particular replacing the colon with perhaps a pair of hyphens.

At the same time, it would seem to be worthwhile to revise the use of view and display names within the config file views_send.settings.json, and also perhaps its structure.

[hansfn]

Hi, Graham

The use of this colon would seem to be a problem because the view name is passed to the mail system and used to identify the template for the HTML body of the email.

Could you please point to the code where the view name is passed to the mail system? I just don't see that Views Send is doing that. In addition, from mimemail-message.tpl.php

 * Copy this file in your default theme folder to create a custom themed mail.
 * Rename it to mimemail-message--[module]--[key].tpl.php to override it for a
 * specific mail.

That means that there is one template for all messages sent by a module (through Mimemail) - unless you can change the key. (Views Send doesn't allow that.)

PS! All statements are for Drupal 7. I haven't checked for Backdrop.

[Graham-72]

Hi @hansfn In this Backdrop version I am modifying Views Send that that the view name will be passed as the key in order that different templates may be used if needed. My work is not complete yet.

[Graham-72]

@hansfn - a bit more explanation of what I am attempting to do with this Backdrop version ...

I am working towards it being able to use the custom themed mail option referred to in your quote from Mimemail. My aim is to have Views Send pass the name of the view to the mailsystem as the value of $key when assigned in the Drupal views_send.module at lines 1067 and 1124 where currently you have $key = 'direct';

There have to be some modifications within views_send.module in order to get the view name to this point in the code, but I believe I have found a way to do this, and I have prototype code working.

I am also finding it necessary to make small modifications to the Mimemail module in order to fit with my understanding of how to use Backdrop's config file system.mail.json

Reviewing the use of this config file has given me major doubts about what the Mailsystem module is doing, and I am working on a much simplified version that I have called Simple_mailsystem.

As I see it, the main things I need to do with this port of views_send are now:

1. when assigning the name of the view to $key as referred to above, I need to replace the colon with a hyphen in order that it can be used as a template name such as mimemail-message--views_send--[key].tpl.php
2. for better understanding, I must improve the naming of config variables in Backdrop's file views_send.settings.json which has entries as shown below in my initial port of the module. "views_send_from_name_test_views_send:page": "Graham Oliver", "views_send_from_mail_test_views_send:page": "graham@oliverweb.net", "views_send_tokens_test_views_send:page": { "node_title_pos_1": "title", "node_uid_pos_2": "uid", "field_email_pos_3": "field_email", "field_name_pos_4": "field_name" }, "views_send_to_name_test_views_send:page": "field_name_pos_4", "views_send_to_mail_test_views_send:page": "field_email_pos_3", "views_send_subject_test_views_send:page": "Test email", "views_send_message_test_views_send:page": { "value": "Testing", "format": "plain_text" }, "views_send_attachments_test_views_send:page": "", "views_send_priority_test_views_send:page": "0", "views_send_receipt_test_views_send:page": 0, "views_send_headers_test_views_send:page": "", "views_send_direct_test_views_send:page": 1, "views_send_carbon_copy_test_views_send:page": 0, "views_send_remember_test_views_send:page": 1 }

Although this works, I am hoping to make it easier to read and understand.

I will be glad to read any comments you may wish to make. I am hoping that very soon I can be ready to commit some changes.

[hansfn]

Thx for the info. Interesting usage of the mail key. I'll post comments if I have anything useful to add ;-)

And now slightly off-topic:

The fork of Drupal 7 into Backdrop was OK, but I now realize that all modules are (indirectly) forked too. That isn't good resource wise. Since Backdrop is so close to Drupal 7 it should be possible to maintain the Backdrop fork of a Drupal 7 module as a simple patch file. All improvements/bug fixes should happen one place.

I guess this is a dream that would never happen because of improvements in Backdrop - in particular configuration management. Do you know if this is even discussed in the Backdrop community? Our work on Views Send is a good example ...

[klonos]

Do you know if this is even discussed in the Backdrop community?

AFAIK this was among the many things discussed. When the fork was announced, there was a lot of "turmoil" and some people had really "strong" feelings about the fork (actually about any forking of Drupal). The fact remained though that Backdrop had to happen and d.org was not the place for it.

There is a way to work simultaneously code-wise with both Drupal and Backdrop because d.org allows you to keep the code in GitHub (it's not d.org that allows this actually - it's because at some point they switched to git, so things can be "synchronized"), but currently there is no way to keep a single issue queue. Mind you, this is not coming from a person that has actually done that, I have only read some articles about it.

Anyways, you might find these of interest:

• Several reasons why I prefer Github over Drupal for Hosting my Drupal Projects.
• Picks of interesting Drupal projects on Github: Drupal on Github (@github_drupal) | Twitter
• Move Git repositories to Github | Drupal Groups

I understand your concern about duplication of work if someone decides to maintain both Drupal versions as well as the Backdrop versions of their modules, but I guess this is how things are.

As a last piece of info, just know that the security teams of both projects work together in fixing issues and they synchronize the fix releases and announcements so that there is no security announcement about a flaw fixed in one project that could compromise the other.

[Graham-72]

The config settings for one particular mailing will, if saved, now be structured like this, in this case for a view named test_views_send_page_2 ` "views_send_test_views_send_page_2": {

    "from_name": "Graham Oliver",
    "from_mail": "graham@mywebsite.net",
    "tokens": {
        "node_title_pos_1": "title",
        "node_uid_pos_2": "uid",
        "field_email_pos_3": "field_email",
        "field_name_pos_4": "field_name"
    },
    "to_name": "field_name_pos_4",
    "to_mail": "field_email_pos_3",
    "subject": "Test views send",
    "message": {
        "value": "Testing",
        "format": "plain_text"
    },
    "attachments": "",
    "priority": "0",
    "receipt": 0,
    "headers": "",
    "direct": 0,
    "carbon_copy": 0,
    "remember": 1
}

`