email

Merhaba

Türkçe konuşan Drupal kullanıcıları için bir e-posta listesi (Google Group) var mı? Eğer varsa katılmak isterim.

Eğer böyle bir oluşum yoksa ben aşağıdaki adreste bir tane oluşturdum. Katılımınızı beklerim.

http://groups.google.com/group/drupal-turkce

A huge feature of any music or band website is simple contact management. You want to keep track of fans, venues, promoters, media people. The reason of course because this creates a nice way to look people up later after you meet them.

For fans, SimpleNews module works great. But it doesn't let you do targeted email campaigns, say for only fans in New York. And it can't distinguish a fan from media contact.

CiviCRM is a full blown contact management solution but is somewhat overkill and hard to use.

Updated: June 20, 2007: RTL HTML Email now possible with my patch to the new htmlmail module.

Requirements for Drupal 6 core RTL email support - Request for comments

It has been 8 months since I've implemented a Drupal 4.7 user.module patch to support RTL emails (attached).

My next target is to ask for the RTL/i18n community help to update the code and migrate those proven changes into the Drupal 6 core. This will save tons of later headache.

Here are the basic requirements - I will need your feedback on the concept (implementation is quite straightforward).

An admin in my group gets access denied. Ideally, group admins should be able to send email?

(Please see the attached 4 sketches)

The basic idea of cck_emailer is to create a cck field type that lets you define an email address to which to mail any new node created that implements the specific cck_emailer field type.

How could CCK replace webform, and would you want to even do this? The purpose of this post is to vet an idea. There is no working code yet. This is also not an attack of any kind on the webform module, I'm just using it for comparison of what this would recreate and in order to tell if this would be any better than what the webform module already does.

Alright, I believe I know how to do some formatting (although I haven't done much yet, but I know it's working), and my custom cc processing module seems to be working. Ouch! My brain is melting. What a way to get my feet wet in the Drupal waters!

Anyway, two (hopefully!) final questions:

Every day I get two or three spam mails through the contact form on one of my homepages.
This is why I think, that the contact.module and Drupal is evil ;)

Do you have the same problems?
What are your solutions against this?

Regards Tobi

Hey there,
Tried to get my systems administrator to install og2list today.
He replied:
" Are you sure you want us to make all those mail router configuration changes to your exim config. I do not see cpanel supporting this software and so mails on other domains may get messed up by this. "

So I ask you: "Will og2list work with a dedicated host running cpanel/whm?"
When I tried to add the settings to my exim.conf file on my own all other mail stopped.. When I removed the changes I made the email resumed being sent... all email that didn't go through in the interim was then allowed to be delivered.. so nothing was lost.... but then I had no idea what order to put things in or if some settings should combine with or supercede others...

the #1 unmet requirement for converting my entire day job's content management needs to drupal is the fact that we currently handle a lot of our content via email. i need a way to plug these existing email addresses into my new drupal site and have the content flow in both directions.

in particular, we use email-based issue-tracking systems, and our entire userbase is used to sending support questions and bug reports to an email address, not going to a web site and filling out a form. similarly, there's a big global email list where people can ask support questions and other users try to answer. this serves much the same function as the forums on drupal.org: clueful users who aren't quite clueful enough to be developers can handle the 1st-tier support questions, and leave the developers more time to write code instead of answering silly questions.

In a meeting today discussing the next generation of the Events systems we recognized that mail issues were a pretty big deal. We'll be working and posting specific use cases shortly. In the meantime there was a stong feeling from those present that we should coordinate all mail issues with this group.

There are two broad issues - the UI and the back-end services.

UI

• The ability to compose and deliver HTML and text emails
• A well designed UI for non-technical end-users
• Ability to drop in merge codes for personalization and common text

API

• abstracted mail delivery services
• ability to create unique tokens
• auto-generation of reply addresses

I'm sure this is an incomplete (if not mis-informed) list - but you get the idea :). Our initial question is what level of coordination do we need to have? Our assumption is that send.module does much of what we need already. What else should we be thinking about?