Email notifications for site admins/moderators (new content added for example).

[klonos]

Excerpt from the conversation in #345 (comment) between @klonos & @jenlampton :

I have addressed all issues...

What were they exactly? Was it the spammy-looking entry in the support section?

Yes. Support, showcase, and events. All items have been removed, and all naughty users blocked. I also adjusted the content types so everything starts unpublished and needs approval to prevent this from happening again.

I believe we should have an email notification that goes out to site admins each time a new node of these types is created (or modified) so that we can act faster rather than having these sit there as unpublished until somebody notices.

I do make it a practice to check all unpublished nodes every Thursday. We don't have any email notify modules on the site yet but we could add this feature once we add one (or port one). @klonos can you please make a separate issue for that?

Here's the issue then 😉

[klonos]

...comment from @Dinornis

Since D6 I have been using Actions and Trigger (now Rules) for this exact purpose.

[laryn]

Rules does have a work-in-progress version:
https://github.com/backdrop-contrib/rules

[jenlampton]

And again, for the record, I would prefer not to have Rules on any of Backdrop's own websites. There are always better options :)

[jackaponte]

And again, for the record, I would prefer not to have Rules on any of Backdrop's own websites. There are always better options :)

Curious, Jen--why do you avoid Rules, and what are the better options for this sort of functionality? (Hopefully that's not too much of a sidetrack to this conversation!)

[jenlampton]

I'm ambivalent about rules.

On one hand, I object to it on philosophical reasons (and have for years).

It's a user interface for writing If statements. It's a large cumbersome piece of code with a confusing UI, and in the end there are thousands of lines of code required to do an operation that would take roughly 3 lines if you were to do it yourself. Having a UI for if statements (and a bad one at that) creates an increased risk of harm, security implications, and all that extra code surely affects performance. Add to that, the kinds of people who would choose to use an interface instead of writing an if statement are usually beginners or non-coders, and sometimes people who may not know when and why such an if statement should be used in the first place, and problems can escalate quickly.

What happens during the "then" part of that equation is usually an operation that's provided by another contrib module, or by core. These should be responsible for providing safe clean UIs for accomplishing these tasks. It seems to me that providing a hook that pushes the burden of that knowledge onto others (especially those less capable) is a bit of a cop-out.

On the other hand, I'm really drawn to tools that empower anyone to do anything.

Especially for Backdrop, we want beginners and non-coders to be able to do as much as they can. Having a tool like Rules for them is going to be very important. I might wish it had a better UI, and was safer in general, but it's a good start.

Doing things "the best way", vs...

So on the one hand, backdropcms.org, api, forum, localize, etc, are likely to end up being the biggest and hardest Backdrop sites to build and maintain. I am tempted to do things "the best way", or the way that is going to cause us the least headaches both now and in the future. We are also fortunate that the people building and maintaining those sites are not beginners, so we have the option of writing our own if statements if we need to.

...doing what's best for the community.

But on the other, isn't the best way to make sure tools like Rules get improved, to use them, and perhaps contribute to their improvement? Instead of writing our own 3 line if statement, we could be contributing that time to something that would benefit every site, not just our own.

Where I stand now.

I do believe that improving Rules is important, but I also see a risk to the community if we aren't able to do other, more important things - like having a forum, a translation server, a better primary website, etc. All these things take time, and that's one commodity we're short on. An if statement is a quick thing to write, and a problem in an if statement is an easy thing to diagnose and fix, whereas even trying to diagnose something that went wrong somewhere with Rules takes hours. It's a very complex tool for a very simple problem, and for our sites, we don't really need it.

Hopefully that's not too much of a sidetrack to this conversation!

It is, but it's good to remind myself that I still see both sides of the situation :) so thank you!

[Dinornis]

So what options do Backdrop users have right now?

The suggestion of having all new content staring as unpublished pending approval may work for BackdropCMS.org, however, that is not an option for many community websites.

[jenlampton]

Fortunately, this queue is only for backdropcms.org :) Everyone else is in about the same boat as they are for Drupal 7, they'll need to evaluate the options out there and make their own decision. Port something? Improve something? Settle for what's already available? Create an editorial workflow that fits the tools and budget they have? shrug

[Graham-72]

I am delighted to see @jenlampton 's comments. I ported Rules because I wanted a way of generating a tweet to Twitter when a particular type of content was added to a site, and I had previously used Rules to do this in a D7 site. But Rules is big and complicated to port as well as use. It would be good if something much simpler could be produced as a contrib module. Is there anything else out there or do we need a fresh start?

[Dinornis]

Are Actions part of Backdrop core? I don't think they are.

[jenlampton]

For this particular job, how about https://www.drupal.org/project/notify?

Are Actions part of Backdrop core? I don't think they are.

We do have actions, our bulk operations system uses them.

[Dinornis]

So why not use actions and trigger?

[jackaponte]

Thanks for the response re: your take on Rules, Jen! I skimmed it and will read it more thoroughly soon, as a frequent Rules user.

For this particular job, how about https://www.drupal.org/project/notify?

Sounds like it fits the bill to me, and would be a valuable addition to Backdrop contrib.

[jenlampton]

So why not use actions and triggers?

Because we don't have triggers ;)

[klonos]

Although the port of Rules needs to happen at some point if we want more people to consider moving to Backdrop (lots of sites using it for more than just notifications), I agree that currently and for the specific task at hand, porting Notify seems more reasonable. So 👍 to that from me.

[Dinornis]

Fortunately, this queue is only for backdropcms.org :) Everyone else is in about the same boat as they are for Drupal 7, they'll need to evaluate the options out there and make their own decision. Port something? Improve something? Settle for what's already available? Create an editorial workflow that fits the tools and budget they have? shrug

Actually both Drupal 6 and Drupal 7 have this functionality in core so all Drupal users have to do is enable the Trigger module, create a new Send E-mail... action and assign it to the Save New Content Trigger.

Because we don't have triggers ;)

What were the reasons to remove the Trigger module? Would it be easier to port it to Backdrop at least until a better option is sorted? Will porting Notify be easier?

[jenlampton]

Actually both Drupal 6 and Drupal 7 have this functionality in core so all Drupal users have to do is enable the Trigger module, create a new Send E-mail... action and assign it to the Save New Content Trigger.

Really? How did I not know this was possible....

[olafgrabienski]

I'm also curious why Trigger module was removed. Didn't find relevant issues in the Backdrop queue, apart from backdrop/backdrop-issues#142 (comment) where @quicksketch states that Trigger "isn't around any more".

[laryn]

I'm guessing Trigger was taken out in early Drupal 8 development (before Backdrop forked). See:

https://www.drupal.org/node/764558
and
https://www.drupal.org/node/2116417

[Graham-72]

I am having a go at porting the Notify module.

It is now available for testing at https://github.com/backdrop-contrib/notify/releases/tag/1.x-1.3.0