Is emailpage abandoned?
I haven't received a response from the maintainer and no maintainer commits have been made since March.
I haven't received a response from the maintainer and no maintainer commits have been made since March.
I posted an email to infrastructure about this offering to take the module. Then I noticed you did a recent commit so I followed up that email suggesting the module be given to you. Are you on the infra list?
I haven't received a response from the maintainer and no maintainer commits have been made since March.
I posted an email to infrastructure about this offering to take the module. Then I noticed you did a recent commit so I followed up that email suggesting the module be given to you. Are you on the infra list?
No. I'll subscribe now. Most of the features seem to be duplicated in the forward module. What do you think about switching the feature requests from emailpage to forward?
On 11/14/06, Darren Oh <darrenoh@sidepotsinternational.com> wrote:
No. I'll subscribe now. Most of the features seem to be duplicated in the forward module. What do you think about switching the feature requests from emailpage to forward?
And it seems they both duplicate functionaity available in the Send module: http://drupal.org/project/send To the extent that you are going to merge them it's probably worth comparing and merging them all. Send's last commit was at the end of June. Regards, Greg
No. I'll subscribe now. Most of the features seem to be duplicated in the forward module. What do you think about switching the feature requests from emailpage to forward?
Mike (Budda) mentioned that on one of the issues so it may be worth retiring the module. But if you do, you still need to think of the 1000s of users using it. They'll need/want a migration path. Currently, I have two modules in this state. Paypal_framework is superseded by lm_paypal module and Scheduler is superseded by Scheduled Actions (and soon Workflow which I believe is going to get scheduled transitions at some future point). So, I plan to retire these two. However, I have made them Drupal-5 compatible for those that use them. However, as can be seen by the announcement on the paypal_framework project page, the module is in "end of life" mode which for me at the moment means "it'll get maintained to Drupal-6 at least". I'll make a decision nearer that time. On a side note, seems a lot of duplicity is creeping despite the best efforts of the cvs admins. That's two modules I'll retire thanks to other modules. Not complaining, frees me up to do other things. But it's a shame a module can't build a "fan base" and have them improved upon. Seems to me the current fashion in module creatation is "that module nearly does what I want, so to fill in the missing feature I'll..... yes.... write a whole brand new one" ;) Anyway, more modules make it all look bigger ;) --AjK
No. I'll subscribe now. Most of the features seem to be duplicated in the forward module. What do you think about switching the feature requests from emailpage to forward?
Mike (Budda) mentioned that on one of the issues so it may be worth retiring the module. But if you do, you still need to think of the 1000s of users using it. They'll need/want a migration path.
Currently, I have two modules in this state. Paypal_framework is superseded by lm_paypal module and Scheduler is superseded by Scheduled Actions (and soon Workflow which I believe is going to get scheduled transitions at some future point). So, I plan to retire these two. However, I have made them Drupal-5 compatible for those that use them. However, as can be seen by the announcement on the paypal_framework project page, the module is in "end of life" mode which for me at the moment means "it'll get maintained to Drupal-6 at least". I'll make a decision nearer that time.
On a side note, seems a lot of duplicity is creeping despite the best efforts of the cvs admins. That's two modules I'll retire thanks to other modules. Not complaining, frees me up to do other things. But it's a shame a module can't build a "fan base" and have them improved upon. Seems to me the current fashion in module creatation is "that module nearly does what I want, so to fill in the missing feature I'll..... yes.... write a whole brand new one" ;)
Anyway, more modules make it all look bigger ;)
--AjK
As a user, I prefer fewer modules. I didn't know about the send and forward modules when I started looking at emailpage. emailpage is the most descriptive name, so it's the first thing I found. The more modules, the harder it is to find what I want.
As a user, I prefer fewer modules. I didn't know about the send and forward modules when I started looking at emailpage. emailpage is the most descriptive name, so it's the first thing I found. The more modules, the harder it is to find what I want.
Darren, Just spoke to Gerhard on IRC, the emailpage module is now yours. Given the duplicity I would say head it for retirement, just give it some TLC in it's dying months and a notice to users it's heading south (graveyard) ;) --Andy (AjK)
On 11/14/06, AjK <drupal@f2s.com> wrote:
As a user, I prefer fewer modules. I didn't know about the send and forward modules when I started looking at emailpage. emailpage is the most descriptive name, so it's the first thing I found. The more modules, the harder it is to find what I want.
Me too. Sometimes too much choice is not a good thing.
Darren,
Just spoke to Gerhard on IRC, the emailpage module is now yours.
Given the duplicity I would say head it for retirement, just give it some TLC in it's dying months and a notice to users it's heading south (graveyard) ;)
No point in TLC if it is destined to be put down. Just put a notice that it is deprecated in favor of ....
No point in TLC if it is destined to be put down. Just put a notice that it is deprecated in favor of ....
Then just whack in the rewrite patch I did that makes it work as advertised for 4.7 (the current offering tagged as DRUPAL-4-7) is totally broken. I think others (zoo33 + others) have patches in the queue that either do the same, or fix things. But if you want to deprive it of TLC then do the minimum to at least make it work (the code is there already) and mark it's project page with a nice message "Please use the Forward module for new sites. Existing users should look to migrate to the Forward module asap, RIP emailpage" ;)
On Wed, 2006-11-15 at 01:55 +0000, AjK wrote:
No point in TLC if it is destined to be put down. Just put a notice that it is deprecated in favor of ....
Then just whack in the rewrite patch I did that makes it work as advertised for 4.7 (the current offering tagged as DRUPAL-4-7) is totally broken. I think others (zoo33 + others) have patches in the queue that either do the same, or fix things. But if you want to deprive it of TLC then do the minimum to at least make it work (the code is there already) and mark it's project page with a nice message "Please use the Forward module for new sites. Existing users should look to migrate to the Forward module asap, RIP emailpage" ;)
maybe make a final emailpage_update_N that migrates to Forward.module and suggest users enable forward module and run the final update as an easy upgrade path.
The Forward project has been active for over a year. They have excellent support for upgrading from emailpage. So emailpage is ready to retire. I have cleared out the issue queue and applied patches for the 4.7 and 4.6 branches. The project description now advises users to upgrade to Forward.
At 4:57 PM -0500 11/16/06, Darren Oh wrote:
The Forward project has been active for over a year. They have excellent support for upgrading from emailpage. So emailpage is ready to retire. I have cleared out the issue queue and applied patches for the 4.7 and 4.6 branches. The project description now advises users to upgrade to Forward.
Since emailpage will be going away, might it be a wise idea to change the name of forward to emailpage or email_node? Emailpage just seems like so much more intuitive a name for this functionality. forward as a module name does not imply the ability to email a page from a site. Without reading the full description of the module, will people think of using it for that based on a quick read of the module list. just a thought. --Eric -- ------------------------------------------- Openflows Community Technology Lab, Inc. New York | Toronto | Montreal | Vienna http://openflows.com People are intelligent. Machines are tools.
On Nov 16, 2006, at 5:18 PM, Eric Goldhagen wrote:
At 4:57 PM -0500 11/16/06, Darren Oh wrote:
The Forward project has been active for over a year. They have excellent support for upgrading from emailpage. So emailpage is ready to retire. I have cleared out the issue queue and applied patches for the 4.7 and 4.6 branches. The project description now advises users to upgrade to Forward.
Since emailpage will be going away, might it be a wise idea to change the name of forward to emailpage or email_node? Emailpage just seems like so much more intuitive a name for this functionality. forward as a module name does not imply the ability to email a page from a site. Without reading the full description of the module, will people think of using it for that based on a quick read of the module list.
just a thought.
Email_node is more accurate. There is no module that sends actual pages. I'll contribute one if anyone is interested.
At 5:32 PM -0500 11/16/06, Darren Oh wrote:
On Nov 16, 2006, at 5:18 PM, Eric Goldhagen wrote:
At 4:57 PM -0500 11/16/06, Darren Oh wrote:
The Forward project has been active for over a year. They have excellent support for upgrading from emailpage. So emailpage is ready to retire. I have cleared out the issue queue and applied patches for the 4.7 and 4.6 branches. The project description now advises users to upgrade to Forward.
Since emailpage will be going away, might it be a wise idea to change the name of forward to emailpage or email_node? Emailpage just seems like so much more intuitive a name for this functionality. forward as a module name does not imply the ability to email a page from a site. Without reading the full description of the module, will people think of using it for that based on a quick read of the module list.
just a thought.
Email_node is more accurate. There is no module that sends actual pages. I'll contribute one if anyone is interested.
right, I should have said "email the contents of a node/page" not "email a page" but, i do think that email_node is a better name for the module being discussed. --Eric -- ------------------------------------------- Openflows Community Technology Lab, Inc. New York | Toronto | Montreal | Vienna http://openflows.com People are intelligent. Machines are tools.
but, i do think that email_node is a better name for the module being discussed.
except for the fact that we carefully avoid the use of the word 'node' in our UI because regular admins and users care not about our abstractions. given that, i think email_node is a poor name. 'email post' or 'email post to a friend' sound better.
Is it actually possible to rename a project once it's in CVS?
At 5:57 PM -0500 11/16/06, Darren Oh wrote:
Is it actually possible to rename a project once it's in CVS?
heh. I guess that would be an important thing to find out before we continue this thread ;) --eric -- ------------------------------------------- Openflows Community Technology Lab, Inc. New York | Toronto | Montreal | Vienna http://openflows.com People are intelligent. Machines are tools.
At 5:54 PM -0500 11/16/06, Moshe Weitzman wrote:
but, i do think that email_node is a better name for the module being discussed.
except for the fact that we carefully avoid the use of the word 'node' in our UI because regular admins and users care not about our abstractions. given that, i think email_node is a poor name. 'email post' or 'email post to a friend' sound better.
I won't get into the discussion of why I think that using less specific language because "users don't care" is foolish and leads to more confusion and prevents intelligent discussion between site admins and developers, as it is far too large a conversation for this thread... email_post seems as obscure as email_node and is also in my opinion not fully accurate, and "email post to a friend" is far too long a name. so how about "email_content.module"? --Eric -- ------------------------------------------- Openflows Community Technology Lab, Inc. New York | Toronto | Montreal | Vienna http://openflows.com People are intelligent. Machines are tools.
On 16 Nov 2006, at 23:54, Moshe Weitzman wrote:
but, i do think that email_node is a better name for the module being discussed.
except for the fact that we carefully avoid the use of the word 'node' in our UI because regular admins and users care not about our abstractions. given that, i think email_node is a poor name. 'email post' or 'email post to a friend' sound better.
I was about to say the exact same. Using 'node' in your module name (or in user-generated output) is a sign of bad taste. :) -- Dries Buytaert :: http://www.buytaert.net/
On Friday 17 November 2006 01:21, Dries Buytaert wrote:
On 16 Nov 2006, at 23:54, Moshe Weitzman wrote:
but, i do think that email_node is a better name for the module being discussed.
except for the fact that we carefully avoid the use of the word 'node' in our UI because regular admins and users care not about our abstractions. given that, i think email_node is a poor name. 'email post' or 'email post to a friend' sound better.
I was about to say the exact same. Using 'node' in your module name (or in user-generated output) is a sign of bad taste. :)
I don't know that I'd say bad taste (says the maintainer of a module that has "node" in its name... <g>), but it is limiting. email_node.module ceases to be accurate as soon as you add the ability to forward a page built with views or panels or taxonomy or any of the other useful non-node displays. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On 11/17/06, Larry Garfield <larry@garfieldtech.com> wrote:
On Friday 17 November 2006 01:21, Dries Buytaert wrote:
On 16 Nov 2006, at 23:54, Moshe Weitzman wrote:
but, i do think that email_node is a better name for the module being discussed.
except for the fact that we carefully avoid the use of the word 'node' in our UI because regular admins and users care not about our abstractions. given that, i think email_node is a poor name. 'email post' or 'email post to a friend' sound better.
I was about to say the exact same. Using 'node' in your module name (or in user-generated output) is a sign of bad taste. :)
I confess: node vote, favorite nodes ... Druplicon have mercy on me ...
At 1:26 AM -0600 11/17/06, Larry Garfield wrote:
On Friday 17 November 2006 01:21, Dries Buytaert wrote:
On 16 Nov 2006, at 23:54, Moshe Weitzman wrote:
but, i do think that email_node is a better name for the module being discussed.
except for the fact that we carefully avoid the use of the word 'node' in our UI because regular admins and users care not about our abstractions. given that, i think email_node is a poor name. 'email post' or 'email post to a friend' sound better.
I was about to say the exact same. Using 'node' in your module name (or in user-generated output) is a sign of bad taste. :)
I don't know that I'd say bad taste (says the maintainer of a module that has "node" in its name... <g>), but it is limiting. email_node.module ceases to be accurate as soon as you add the ability to forward a page built with views or panels or taxonomy or any of the other useful non-node displays. :-)
ok, that makes a lot sense to me, so much more than just saying "we don't use node because admins don't care". Thanks for clarifying that for me. --Eric -- ------------------------------------------- Openflows Community Technology Lab, Inc. New York | Toronto | Montreal | Vienna http://openflows.com People are intelligent. Machines are tools.
Dries Buytaert wrote:
except for the fact that we carefully avoid the use of the word 'node' in our UI because regular admins and users care not about our abstractions. given that, i think email_node is a poor name. 'email post' or 'email post to a friend' sound better.
I was about to say the exact same. Using 'node' in your module name (or in user-generated output) is a sign of bad taste. :)
Nodequeue -- but then, I wasn't even aware until Dries' talked to me about Views that 'node' wasn't used in the admin UI. The term was so very familiar, and widespread in Drupal, that it's weird to me that it's treated like an unwanted uncle locked in the tower.
On 11/14/06, Darren Oh <darrenoh@sidepotsinternational.com> wrote:
As a user, I prefer fewer modules. I didn't know about the send and forward modules when I started looking at emailpage. emailpage is the most descriptive name, so it's the first thing I found. The more modules, the harder it is to find what I want.
Emailpage: crufty, not as good as forward. Forward: no dependencies, works great out of the box. Could use Views integration. Send: depends on CiviCRM for a bunch of tracking features. Hmmm...might actually require some sort of "Mail" or something as well....I forget. So, Forward and Send (for CiviCRM users) still make sense. Emailpage is the bastard stepchild IMHO. My vote is to collapse forward and emailpage....as long as Forward's codebase is used, since it seems better. Send will likely not get changed and shouldn't be collapsed for those that heavily use CiviCRM. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
Emailpage: crufty, not as good as forward.
Lack of TLC. There exists in the patch queue an entire rewrite of the module that's not crufty and works perfectly as advertised.
Forward: no dependencies, works great out of the box. Could use Views integration.
probable duplicate module, born out of neglect for emailpage
Send: depends on CiviCRM for a bunch of tracking features. Hmmm...might actually require some sort of "Mail" or something as well....I forget.
Uses CiviCRM, not worth mentioning then unless you want that installed too, just to send a page? ;)
So, Forward and Send (for CiviCRM users) still make sense. Emailpage is the bastard stepchild IMHO.
Bastard stepfather you mean, it's way older. And if it's issue queue had been given some care I doubt Forward would have been born (so one would presume if Dad was away, Forward is in fact the bastard child ;)
My vote is to collapse forward and emailpage....as long as Forward's codebase is used, since it seems better. Send will likely not get changed and shouldn't be collapsed for those that heavily use CiviCRM.
I believe my advice to Darren was correct. Mark emailpage for retirement but continue to support your 1000s of users (if there are any left since it's slipped into a state of total dis-repair). But, as a responsible maintainer, you must assume there are still users till facts dictate otherwise. Then, Forward should begin to take it's place. By Drupal 6 (7 maybe) Forward will have 10,000s of happy users, emailpage? zero. Erect tombstone, it was good while it lasted ;) --AjK
On 11/14/06, AjK <drupal@f2s.com> wrote:
Send: depends on CiviCRM for a bunch of tracking features. Hmmm...might actually require some sort of "Mail" or something as well....I forget.
Uses CiviCRM, not worth mentioning then unless you want that installed too, just to send a page? ;)
Did you look at it before commenting on it? It uses CiviCRM IFF CiviCRM is installed. If not, it just does the regular job. Regards, Greg
On Nov 14, 2006, at 7:17 PM, AjK wrote:
Send: depends on CiviCRM for a bunch of tracking features. Hmmm...might actually require some sort of "Mail" or something as well....I forget.
Uses CiviCRM, not worth mentioning then unless you want that installed too, just to send a page? ;)
Woah there, Tex! There's a big difference between a module that supports CiviCRM and one that depends on it. When CiviCRM is installed, send will create a new user (if necessary) for both the sender and the recipient, and then log an action for each. When CiviCRM is not installed, it doesn't do that. Send depends on Mime Mail to convert the node's HTML into a valid multi-part email. Mime Mail's output is themeable, and when left to its own devices it uses your theme's style sheets. Rather than attempting to construct valid messages on a one-off basis, send leverages Mime Mail's code, which is reusable by other modules. It's more efficient this way, and you can maintain consistent branding while respecting users' plain-text/html email preferences. I wrote send because I wanted a consistent way to send nodes from the site for various reasons. For example, the News module extends send by form_altering the recipient into a selection of mailing lists. Petition or letter to the editor modules could do similar. Send keeps track of which nodes are sent, by whom, and by which module. You could use this data to determine your most active senders and most frequently-sent nodes across all participating modules. And, of course, it would all get tracked in CiviCRM, if you're into that sort of thing :) Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies
AjK wrote:
On a side note, seems a lot of duplicity is creeping despite the best efforts of the cvs admins. That's two modules I'll retire thanks to other modules. Not complaining, frees me up to do other things. But it's a shame a module can't build a "fan base" and have them improved upon. Seems to me the current fashion in module creatation is "that module nearly does what I want, so to fill in the missing feature I'll..... yes.... write a whole brand new one" ;)
Yeah, that's unfortunate. Unfortunately, there are so many modules already that I simply have lost track of what already exists and what is genuinely new. Maybe if more people would subscribe to the cvs-applications list, they could point out such double modules before the author gets cvs access.
Anyway, more modules make it all look bigger ;)
And more confusing, as noticed by Darren. Cheers, Gerhard
participants (13)
-
AjK -
Allie Micka -
Boris Mann -
Darrel O'Pry -
Darren Oh -
Dries Buytaert -
Earl Miles -
Eric Goldhagen -
Gerhard Killesreiter -
Greg Knaddison - GVS -
Khalid B -
Larry Garfield -
Moshe Weitzman