Jump to:

The actions API is wonky (look up your action via hash of function name?), actions/trigger has no maintainer in MAINTAINERS.txt and we have not seen the promised conversion of things like node operations into actions.

Also, the trigger UI is weak, and there's not a lot you can do with it.

In general, people use a contrib module like Rules - so let's just put this code back in contrib where it belongs and reduce some of the bloat in core.

Comments

I'd be comfortable removing actions and triggers from D7, and moving it to contrib. I was, originally, going to give it until D8 but I'm willing to remove them now if there is enough support. I wish actions and triggers had more momentum, but I honestly don't see that change.

Having actions in core is great, IMO. It allows for a lot of contrib modules -- Organic Groups, Flag, Views Bulk Operations, etc. -- to provide rich and customizable functionality. You move this to contrib and you'll invariably get 5-6 variations ("old" core triggers, Rules, Better Awesome Triggers, etc.) which means more work for contributed module developers to support the same functionality. IMO we'd be better served by making the Actions API better in D8 than ripping it out of core.

Trigger, don't really care. It is quite limited. But it'd be kind of sad, because Trigger got a lot of love this release, with tweaky edge-cases fixed and lots of unit test coverage.

I'm utterly mystified why this is being considered at this late date, however.

My only concerns would be what it would take for folks to upgrade it and releasing it into the community begets it needing a maintainer (which we don't have, right now) so it might turn into a dead end for folks needing an upgrade path.

I don't know about rules in core, but actions and triggers has been nothing but a huge maintenance burden this release. A few people (rfay and others) have fixed it up quite a lot, not sure if that'd make them more or less in favour of removing it having done that.

Improving the function that actions and triggers serve in core should be the conversation here, not removal. Drupal withers as an application framework when something so essential is thrown from core, IMO. You can't just lose that functionality (from core) without a good replacement.

That said, I've used both Rules and Actions/Triggers in solutions - Rules is accessible, writing your own Action really isn't for novices. Improving the latter accessibility will improve Drupal as an app framework; dropping the functionality from core won't move us forward.

I'd say we consider moving it to contrib. My one concern is that that move it is essentially signing a death warrant. Most people (including me) use Rules rather than A&T and I don't know how much maintenance love it would get.

[Edit: Also didn't intentionally remove the period from the end of the title, how odd.]

There are lots of contrib modules that rely on Actions, even if Triggers is ignored. The fact that we still have a number of legacy operations in core that don't use actions is hardly a reason to remove it. There is even less collective knowledge about how to build and maintain those.

@eaton, @webchick: Since Rules already *has* happened and seems to be more widely used than core Actions, surely Pandora's box is already flung wide open? I don't see how another year of people getting cosier with Rules in contrib, precisely because Actions in core needs some serious love and is hanging around largely for legacy reasons, will help.

I appreciate eaton's point, but there are also lots of contrib modules that rely on Rules and it *not* being core is not an issue, so Actions being moved from core didn't ought to be one either.

I don't disagree something like Actions would be great in core, but since fewer and fewer seem to be actually using Actions it seems futile to keep it there. Maybe it needs cutting lose for a few core releases, let the best contrib effort win (it might be Rules, it might be something else) and then roll it back in again later (like CCK -> FieldsAPI)? Let something prove itself indispensable, at which point it can be re-included in core. Why not? That's my feeling anyway.

(I also appreciate webchick's point about this being a little late in the day, btw, but I still agree with it.)

Still waiting for the people who actually do use Actions all the time to turn up and defend it, but so far all I see is folk talking about Rules.

This does not make sense. Instead of removing, we need to enhance them.

However.

It also does not make sense to tell us that everyone should focus on stabilizing D7, and finally get all of the critical issues fixed. Effectively, even remotely considering this issue for D7 makes me feel very angry. If we consider to do this for D7, then I can provide you a list of much more pressing clean-ups that should therefore be considered for D7, too.

Decisions like this should be taken during code thaw. Not when trying to get this sucker finally stable and out of the door.

Um. No. This is not "a little late". This is past API freeze, past code slush, past Super Extended Code Slush, and past 3 alpha releases, and heading into the first beta. Also, as far as I can tell, this has absolutely nothing to do with bringing our critical issue queue counter down to 0, though it's doing a great job of diverting energy away from that task. Seriously. Why are we even talking about this now? There must surely be a reason?

It's unfortunate that those who support Rules so strongly didn't spend energy on making core Actions better this release. I agree that Rules module is used more "in the field" than Trigger module, since Trigger lacks conditionals which is pretty important. But in terms of API support for Rules vs. Actions in contributed modules, I'm not so sure Rules is in the win there. The Action-enabled modules I use on almost every site - Views Bulk Operations, Flag, etc. use Actions, not Rules. Other than Content Access I'm not sure I'm aware of other modules that have Rules integration that are so critical to sites I build all the time. Ubercart has its own actions UI yet again.

I don't see how it's remotely fair to tell the people who have already ported their modules to D7, whose code relies on something that was in core in September, to go figure out Rules API instead. There's more than enough for them to do just in the gigantic list of pre-existing API changes we already have.

Subscribe. Not a user of action/triggers nor rules myself so I have no real say in this, but actions/trigger look like a very good candidate for a D8 dev cycle in contrib. There's a more popular toolkit out there it seems (rules) and the CCK scenario seems feasible here: mature in contrib and land in core as a RulesAPI. Also, cutting non-critical features is a good idea in general :)

@eaton, @webchick: Since Rules already *has* happened and seems to be more widely used than core Actions

Rules is effectively tied with Views Bulk Operations on the module usage page, and Views Bulk Operations is completely Action-centric. Other module like Flag and Workflow rely on Actions as well. Then there are modules like Organic Groups, Private, and so on that expose custom actions in order to facilitate cleaner customization.

While Rules is one module with many users, the Actions ecosystem, consisting of many modules that utilize the API, has a broader user base and a much larger list of modules that support it. There are a number of reasons we might decide to remove an API from core, but doing it months after code freeze, during bug-fix phase, due to the incorrect assumption that a contrib module is more popular than the core API, is a mistake.

While Rules is one module with many users, the Actions ecosystem, consisting of many modules that utilize the API, has a broader user base and a much larger list of modules that support it.

Good point. One decided downside to the removal of A&T is the number of other modules (many of which are themselves important/popular) that rely on this functionality being in core. Although they could certainly migrate to having an additional dependency, that's a hardship for their maintainers who are trying to add D7 support. Perhaps it would be better to say it's something we're considering for the next go round and leave A&T as is for D7.

Why are we even talking about this now? There must surely be a reason?

As far as I know, no particular reason other than those outlined in the issue by pwolanin.

I don't see how it's remotely fair to tell the people who have already ported their modules to D7, whose code relies on something that was in core in September, to go figure out Rules API instead.

Fair enough. If we don't remove the modules in Drupal 7 (which is fine by me), I'll remove them from Drupal 8 -- or at least Triggers. If Rules is the winning module, it would still be smart for people to adopt Rules instead of Actions/Triggers regardless of Actions/Triggers being in core a bit longer ... To me, it feels like we'll end up promoting a bad practice but who knows how Actions will evolve in the D8 development cycle.

I'm on the fence about this which is why it is worthy being discussed, and why it is a healthy discussion rather than a waste of resources. Our ability to fail fast and adjust has always been part of our DNA, and is what will keep us relevant. Processes are important, but can also be harmful if they become inflexible. I'll happily ignore any process when it makes sense to -- but as said, I'm on the fence about this one.

I just have to jump in, if only to keep the issue settings changing... :-)

I'm with webchick and sun on this one. Good idea or not, this is *not* the time to be doing it. Wait for D8. No one uses poll, either, but we've left that in core for what, 6 releases now? More? :-)

I have to say, though, this is a sign of a major flaw in our core workflow. I recall when actions went in, they were essentially gutted, castrated, and rendered impotent in order to be "simple enough" for core, because boo-hoo we didn't want to scare people with too many options. So guess what, lots of people didn't bother with the actions-jr that ended up in core and instead turned to a more featured contrib that replaced what had been actions in contrib. Why is anybody surprised by this?

It's too late to rip out an API like that for D7. For D8, let's try to actually, you know, make actions useful again rather than assuming that core == so simple an idiot can use it == so simple only idiots will bother with it. (OK, a little strong since I've used actions, but you get the idea.)

it would still be smart for people to adopt Rules instead of Actions/Triggers regardless of Actions/Triggers being in core a bit longer ... To me, it feels like we'll end up promoting a bad practice

If we took that approach we would have removed profile, tracker and a few other core modules this release, some of which had patches posted for them during code thaw, only a handful got in. Not that I'd be in favour of ripping them all out this week though.

On the other hand, that "base system" with 13 / 123 critical issues (~10%)... boy, that sucker is buggy! Who needs a "base system" anyway?! ;)

Also, I decided to do a pseudo-scientific study of contrib to answer this Actions vs. Rules API question definitively, by grepping an rsync checkout of contrib for _action_info( and seeing how many of those were _rules_action_info(. Looks like 153 out of 547 (~27%).

Also, I decided to do a pseudo-scientific study of contrib to answer this Actions vs. Rules API question definitively, by grepping an rsync checkout of contrib for _action_info( and seeing how many of those were _rules_action_info(. Looks like 153 out of 547 (~27%).

"I have to say, though, this is a sign of a major flaw in our core workflow. I recall when actions went in, they were essentially gutted, castrated, and rendered impotent in order to be "simple enough" for core, because boo-hoo we didn't want to scare people with too many options."

To refresh your memory, the "gutted and castrated" that you refer to was simply massaging of the default values of the 'hooks' index in the actions array, to allow Trigger module to only show sensible choices by default, and resulted in an API improvement by adding a hook_action_info_alter(). Trigger Unlock restores the ability to do things such as ban all users as soon as they view any post on your site, though I've never personally heard of anyone complaining of this limitation.

profile has some of the worst storage of any module I can remember since flexinode, and is the cause of all kinds of pain for people who switch it on then find themselves up shit creek without a paddle due to the lack of migration path to more modern contrib alternatives.

tracker can, and does, bring your site down once you get past a few thousand nodes/comments (until a couple of months ago).

Actions/Trigger has a crappy API/interface.

There's no need to be black and white about it, tracker and profile are qualitatively and quantitatively worse ;)

While Rules is one module with many users, the Actions ecosystem, consisting of many modules that utilize the API, has a broader user base and a much larger list of modules that support it.

I would definitely argue Rules is an ecosystem too, albeit an up and coming one (~27% according to webchick) - or we wouldn't even be having this discussion - which clearly *also* consists "of many modules that utilize the API". Let's see if they pass each other over the course of Drupal 7. I'll be curious to see what happens myself. I take your point about the perception of usage vs. actual usage, but we should definitely watch this space. Last time I looked, Ubercart planned to drop Conditional Actions in favour of Rules, for a start.

It's unfortunate that those who support Rules so strongly didn't spend energy on making core Actions better this release.

That's just not fair at all. Things get developed because people find them useful and build on them. "Those who support Rules", those over there in the corner, the unwashed, "We" use Rules because it works for us already and it's easy to work with. All we know is we use Drupal every day, Rules exists and it is broadly more accessible and usable than Actions, both as a UI and as an API. If you take issue with the very existence of Rules, or that fago spent time developing it instead of writing patches to core to make Actions and Trigger better, that's nothing to do with this. But please don't blame the users of the Rules module for the failings of the core module. We simply reviewed the options and chose a "product" you'd rather we didn't, but we all had our own, good reasons for doing so.

The suggestion was prompted by looking again at the code for actions - we did some desperate fix ups at the end of the D6 cycle and at that point I didn't think it should have been in core, and looking at it again reminded me of this.

I personally haven't really used trigger since it's had to make it do much useful, and I'm not sure which contrib modules use actions, so if Flag, VBO, etc are making use of it that would be a reason to keep at least actions if not trigger itself (which is kind of example code for using actions).

@eaton:
>While Rules is one module with many users, the Actions ecosystem, consisting of many modules that utilize the API, has a broader user base and a much larger list of modules that support it.

Thanks a lot for mentioning this. We surely need a good action API beside from a rules/trigger module, thus it doesn't make much sense to remove it for d7. I wouldn't care about the trigger module though.

>Also, I decided to do a pseudo-scientific study of contrib to answer this Actions vs. Rules API question definitively, by grepping an rsync checkout of contrib for _action_info( and seeing how many of those were _rules_action_info(. Looks like 153 out of 547 (~27%).

Well rules makes use of the core actions too. Anyway, having multiple action APIs (core,rules,ubercart,..) is definitely a bad thing as we end up with lots of duplicated code and put the burden on module developers to have to support each separately.

It's awesome to see drupal commerce coming back to Rules in d7 though.

@webchick: It's unfortunate that those who support Rules so strongly didn't spend energy on making core Actions better this release.

Well instead I worked on making Rules better.
To be honest action/triggers has some fundamental flaws I wouldn't bother putting much effort into. While the action API is fine for simple "bulk operation" use cases, it's in practice too limited for the rules/trigger use case. But still having a single, unified API is important and this is why APIs should be in core. However any core API really should be powerful enough to serve the major use-cases.

>mature in contrib and land in core as a RulesAPI
I'd love to see that happen and I considered working on that for d7 already. However rules 6.x-1.x has no good condition or action API either as I really focussed on the "triggering rules" use case when I initially wrote it (as workflow-ng for 5.x) and didn't cope well with advanced use cases (web services, loops, ..).

That's why I started from scratch for rules 7.x-2.x to build an extensible, reusable framework from the ground. It offers separately (re)usable conditions, actions, condition sets, rule sets (= rule plugins) and UI components while modules can extend it with new plugins.
Thus once Rules 2.x has proven in contrib I'd love to get the basic rules-API in core for d8, so we finally have an unique API modules can rely on and which is flexible and powerful enough to fit the simple as well as the advanced use-cases.

Keeping an eye on this, since I maintain Views Bulk Operations for D7 (which supports both options that are being discussed here).

While I couldn't care less if trigger was removed, I wouldn't feel comfortable removing actions. People ARE using actions.
I love using Rules with VBO, but there are still use cases where I would rather use actions (for example, providing a configuration form for an action is much easier with core. Getting a novice to do that properly with Rules? Forget it.).

Rules usage is exploding (and VBO for D7 has better support for it then ever), but I think we need another release cycle to actually learn something from all that usage and all those use cases, in order to get the Rules architecture right (and same as for Views, having plugins in core changes things) and make sure it's as easy / powerful to use as possible.

Views, Panels and Rules have a big issue that hasn't been dealt with much - since they are complex tools, they require good tutorials, manuals, etc (documentation) and solid examples for novice users to see.

while documentation may be or not accomplished already, with links on the project page and the usage of advanced_help (something not in core yet though)...

solid examples perhaps isn't.
Views does provide some examples.
Panels, none at all.
and Rules, only a very basic one. not enough.

but that's something that can be fixed easily, both for the module's, and in the future, if it happens, for core, before a major release.

I agree that this discussion really ought to be scoped to Trigger module only. I think actions are desirable, but could stand to be greatly cleaned up and expanded (allowing for conditional actions, for example).

maybe move out trigger and actions out of core, to contrib, like stated in the issue post.
there, no problem for older users or people unhappy for not having actions/triggers available for D8 and beyond. just install the module (when it's ready). whether Rules gets in to core or not.

Actions 5.x-2.x is a backport of Drupal 6 core actions and triggers and is recommended for use with Drupal 5, should you be unable for some reason to upgrade to Drupal 6 and use its core implementation.

@LPCA: looks like http://drupal.org/project/actions is the perfect place for the code, then: the D8 branch does not exist there so it can be created with the code removed from core with just the project page amended.

I agree that if at all, then moving trigger should be considered separately to moving actions. If we remove trigger from core, it will likely to be to let it die in contrib (since most people who would have used it will just install Rules if they need a UI for the same stuff).

Actions itself, we could likely try to actually use the API in core a bit (currently it's not), and improve it to handle some of the use cases that Rules does (so that rules could rely on it for that specific area of functionality).

I love using Rules with VBO, but there are still use cases where I would rather use actions (for example, providing a configuration form for an action is much easier with core. Getting a novice to do that properly with Rules? Forget it.).

The point is, usually you don't have to write a configuration form for Rules 2.x any more as you describe the parameters and your are done.
Having actions run by a defined array of parameters is key to be able to use them in many circumstances, including use-cases where action arguments need to be provided dynamically. (Using token replacements does not fly for that - that's the lesson we learned we learned with Rules 1.x.)

Rules usage is exploding (and VBO for D7 has better support for it then ever), but I think we need another release cycle to actually learn something from all that usage and all those use cases, in order to get the Rules architecture right (and same as for Views, having plugins in core changes things) and make sure it's as easy / powerful to use as possible.

Generally agreed, however we should aim on unifying the action API asap + an action API really belongs into core.

Actions itself, we could likely try to actually use the API in core a bit (currently it's not), and improve it to handle some of the use cases that Rules does (so that rules could rely on it for that specific area of functionality).

Yes, I agree this is very much the first step. It really doesn't matter much whether Rules is in core or not, as long as we come up with a unified and generally useful action API.

As outlined above Rules actions need the complete parameter description to be actually useful. While core-actions come with hand-crafted configuration form, this is not going to fly. So for making it compatible, we would have to go with the parameter-array for core-actions too.
Then we'd have to implement a simple action execution environment for single-actions, that works similar to that what Rules does. That could work, though I'm unsure whether it flies or we are going to re-invent Rules part-by-part.

Alternatively we could aim for getting the basic Rules-API for configuring and executing actions & conditions into core, while we keep more complex stuff like events, rules, components and in particular the UI for those - out. So modules like VBO should be able to solely build upon the core API, while people can install Rules in order to configure custom components, rules and stuff like that.

I tend to the last option, though I fear it would have to happen rather late in the cycle.
Of course, we'd need to rebuilt it based upon d8 plugins, but moreover my main priority for now is the entity API + the Entity property API, which really is the key for making a system like Rules properly work.

Ironically, setting up the Snowman Project test site for several of the site builders, I needed to turn on Trigger module so that I'd get notified when someone creates a new sandbox site there… The UX is indeed super nasty, though.

Without Trigger in core, we also have no UI for configuring the advanced actions like send email and such -- or at least no UI that makes sense, as they are never triggered by anything. That's something to consider before chopping it.

Honestly, I'm not comfortable removing anything from core until we decide what the heuristic for what is in core is. Once we have that, we can apply it logically. Until then, though, we're just flailing and smacking modules we don't like.

Crell: while it is good to have guidelines, it is not a strict requirement to have them. You make it sound like it is, but it isn't. Either way, I'll help decide on some guidelines in #1255674: [meta] Make core maintainable and wait to remove Trigger module for the time being.

It is not a strict requirement, but as far as I can see, the majority of us agrees that we need to come up with some sort of common understanding of what belongs into the "core" (that we apparently have to maintain), whether the question is actually about removing things or merely moving them, and also, to come up with a plan for how to deal with removed or moved things on a technical level (not limited to, but also including the upgrade path).

In light of that, it is correct to move this issue out of the RTBC queue, since there is nothing to commit at this point.

We need to discuss a lot of topics, and we're not even sure what exactly those topics are. Because of that, #1262752: Discussion items exists to figure out the actual questions and worries that all of us have.

Rules blows Trigger out of the water. When setting up complex workflows for clients, I always find that I try to use Trigger module for what I'm trying to accomplish, but just can't, so I always end up using Rules anyway. Rules is the next evolution of Trigger module, and is the direction we should head.

As long as Rules provides an upgrade path from Trigger module in Drupal 8, I'm all in on removing this.

Is it a "defining" quality of Drupal or an important differentiator from other web CMS projects? I'd say no. Wiring up event-response actions is useful, but not something that we really present as a defining characteristic of Drupal.

Is it a "building block" that can be used to implement many different user-facing features? Yes. It could use TONS of love, but it's definitely a building block feature

Would it be impractical or impossible to implement as an optional plugin or contrib module? No: alternative solutions have thrived in contrib.

If more robust solutions to the same problem exist in contrib, is it compatible with or "easily migratable to" the contrib solution? No. Any Triggers have to be recreated in Rules.

Does it have a positive or neutral impact on the number of "tightly coupled" connections and dependencies between different parts of Drupal? I'm torn on this one. The concept of using hooks and actions is a good move towards decoupling things, but the Trigger module in particular ends up being really tightly coupled to very specific core hooks. I'm going to say No, it doesn't have a positive/neutral impact on coupling and dependencies.

Does its presence significantly improve the experience of first-time evaluators, experienced builders, or developers building on top of Drupal -- without significantly diminishing the experience of the others? This is probably where the debate will rage most; because it's relatively difficult to configure and also very limited, I'd argue "No," but I'm open to disagreements.

Does it match common patterns and best practices for similar tools and web applications? No. It's pretty unique, and tools like Apple's Automator UI are probably better models to pursue for this kind of feature.

So, out of the eight criteria being evaluated it gets only one solid "Positive indicator." If we're being super generous we could bump it up to three. Again, that doesn't mean that it SHOULD be axed, just that the module as it exists doesn't seem to be very well aligned with the way we want to approach Drupal core.

i think in the end, it sums up to usefulness and usage in the community... it's worth as a contrib module, not as much as a module shipped with core. a more unified/flexible solution like Rules and Butler projects will be interesting to follow up in the future to fill in the gap.

With the above patch applied, there are still tons of references to the Trigger module in the codebase. The attached screenshot shows some of them (but there are plenty of others).

The screenshot also illustrates the point made by @eaton in #78, which is that it's very odd for core to provide a big old UI for configuring advanced actions without also providing a way to, uh, do anything with them. Doesn't seem like that issue has been resolved yet.

Core supplies that ui with trigger module disabled, that doesn't make any sense either but survived two releases. There's a separate issue to turn actions into a module which would at least mean that ui isn't pushed in everyone's faces. At least the references should be removed from the rest of core though.

Actions are very useful re-usable snippets of code and are used by many dozens/hundreds of contributed modules.

Which modules use Actions? We should update them to use Rules.

What we should probably discuss is bringing conditional actions into core.

But that's what Rules is.

But it is completely and totally separate from Trigger module. Separate issue.

Should we remove Trigger module, Actions UI, but leave the API? I'd be okay with that. The attached patch leaves the Actions API, but removes its UI.... Or should we just remove Trigger module here and leave Actions UI/API to another issue? What do you think, Angie?

Whoops, forgot the patch.... Again, this one removes Trigger and Actions UI, but leaves its API. I'm still kind of with Angie here about leaving Actions for a separate issue though. Definitely remove Trigger at the least though.

Yes, remove Trigger module here, discuss Actions UI/Actions API in another issue. That has been the consensus here for at least the past several dozen replies. :\

Some of the top modules that incorporate Actions support include Flag, Views Bulk Operations, OG, Quiz, Workflow, etc. Some of them have Rules support also, but not all. And I know what Rules is. But Rules is a contributed module. Many module maintainers do not feel comfortable relying on a contributed module for this key functionality, as contrib modules lag behind core (Rules just hit a stable release Oct 11, 10+ months after Drupal 7 came out).

Simple question about what would happen if Trigger module is removed...

Currently, some of my websites have standard core actions that are "triggered" by events such as the addition of a node, comment and/or user.

How would these actions be "fired" if the Trigger module were removed? Is the proposal that one must create a custom module to offer Rules support (itself a contrib module) to "trigger" standard actions that remain in core?

Simple question about what would happen if Trigger module is removed...

Currently, some of my websites have standard core actions that are "triggered" by events such as the addition of a node, comment and/or user.

How would these actions be "fired" if the Trigger module were removed? Is the proposal that one must create a custom module to offer Rules support (itself a contrib module) to "trigger" standard actions that remain in core?

Leave the Actions UI (knowing that you can't actually do anything with it)

Lars Toomre How would these actions be "fired" if the Trigger module were removed? Is the proposal that one must create a custom module to offer Rules support (itself a contrib module) to "trigger" standard actions that remain in core?

My question remains how in core will existing actions supplied by core modules be "fired" if the trigger module is removed?

We point people who need this use case over to Rules. The Snowman project is going down this road with their 80/20 ideology. Bring them 80% of the way, tell them how to get that last 20%. That last 20% is installing the Rules module with contrib.

fwiw I'm OK with committing a patch to remove trigger and leave actions there (assuming it's RTBC and someone doesn't come out of the blue with an amazing reason to leave trigger in), but it'd be good to have a follow-up issue to remove the actions UI as well.

We have some APIs in core that are rarely or very little used in core (even tokens is only used in a couple of places, lots of contrib modules provide tokens, but only system module uses token_replace() iirc), so actions being orphaned is not that much different (although it'd be nice if the test coverage was better than it is currently too).

The UI for configuring triggers and events happens contextually in all the various modules that support actions. VBO exposes Actions within Views. Workflow exposes a page that allows the triggering of actions when a node is moved from one workflow state to the next. And so on. These can also be triggered from custom modules with the actions_do() function.

What's being discussed here is ditching the limited and confusing UI that core provides.

And the Actions UI does do something. It's only through the Actions UI that you can configure advanced actions such as "Send an e-mail to X address." Those configured actions are then used by various contributed modules that also use actions like "Publish post."

And the Actions UI does do something. It's only through the Actions UI that you can configure advanced actions such as "Send an e-mail to X address." Those configured actions are then used by various contributed modules that also use actions like "Publish post."

Imo this is a broken pattern. Usually, I want to make that configuration in the context of the module usign the action, e.g. when executing a VBO. I think vbo has even implemented something like that in the meanwhile. Require users to jump back and forth between both UIs to configure a simple action is awkward.

Instead of the actions UI I think we need a place where people can click together re-usable complex actions, i.e. more than a simple context-specific configuration. But doesn't need to be in core, the API needs to be - including an API to embed the action configuration UI. Anyway, that should be handled in the actions issue....

Let's remover trigger and keep actions, then refactor/overhaul actions to fit common use-cases including Rules...

I'd like to startle everyone by announcing that I agree wholeheartedly with Fago. ;-)

While I'm not a fan of Rules, it's the best solution for complex triggered operations, short of writing custom PHP. It absolutely requires, however, adequate action coverage for core and contrib to do its job. So do other modules that don't depend on Rules. Keeping the underlying Actions API in core, and replacing odd bits like the 'custom node operations' API and 'custom user operations' APIs with their action-driven counterparts, is a better solution in the long term than entirely removing the system and punting it to contrib.

Remove triggers, keep Actions, and then figure out a good solution to the 'orphaned' Actions config screen.

There's an issue somewhere to move actions to a module (at the moment it's buried deep on system module). If that module is optional at least the current configuration screen wouldn't be there on every install. Will find nid later.

In #2, #26, #80 and #89 Dries suggested he'd be happy removing this module, however it probably makes sense to give him a last chance to chime in here.

I'm assigning this to Dries, but putting a 5 day time limit - if there's nothing after that and the patch is still RTBC, I'll go ahead and commit this myself. The patch has been waiting a very long time now and there are several months old issues in that assigned queue at the moment.

With the patch applied, there are still references to Trigger module in the codebase, including at least one in the UI. Maybe it's OK to refer to a contrib module in this situation, but at least needs discussion. Here are the places I found:

core/modules/system/system.admin.inc: '#description' => t('A unique label for this advanced action. This label will be displayed in the interface of modules that integrate with actions, such as Trigger module.'),core/modules/system/system.api.php: * triggered. Currently recognized behaviors by Trigger module:core/modules/system/system.api.php: * Modules that are processing actions (like Trigger module) should take

I'm concerned that we're losing some test coverage of the actions system here. The most obvious one is this:

Re: David's comment in #125 -- The references in system.api.php are in the the hook definition for hook_action_info() for the 'behaviors' key. The 'triggers' key also seems kinda tied in; do we retain it anyway as a generic key for modules to use?

I grepped for all references to "trigger" and the remaining instances outside of those in #125 seem to be:

I think that @skottler's offer to maintain it in contrib is awesome, and that helps prevent a host of upgrade path woes as well. This could mean either maintaining it as a full module, or simply providing a tested upgrade path to rules.

Every time I look for this issue I look under major tasks, and then remember it's at normal for some reason. I hate to push thresholds, but at the same time I really don't think removing an entire module is a "normal" task. Feel free to tell me I'm stupid if you disagree. :)

I've found the by far the most effective spam deterrent for a Drupal website is to close the comments after about a week. I currently do this by hand on webchick.net since I want to stick to just core modules to allow me to chase HEAD, either at beta or sooner if #1333898: Support unstable2unstable upgrades? [policy, no patch] is decided in my favour.

If we added the capability for conditional actions to core (which seems like a useful general feature to add), I could totally do this with Trigger module. Without it, I'll have to try and put a feature into core that adds a custom one-off to comment module, and one-offs get trickier now that everything's entities.

However, since I don't see anyone really frothing at the mouth to take on the requisite UX work to make Trigger module really rock and be generally useful to people, I'm still in favour of its removal. Sucks that our Actions test coverage will effectively drop to zero, though.

I offered to move Trigger itself into contrib and maintain it there. An upgrade with will bring longer term benefits to users, though, so that will likely be a bigger win.

I think it needs to be decided whether deprecation or elimination is the decided route for the module; my vote is elimination. An upgrade path is the right way to go if that is the consensus. Given conversations I've had with @xjm and others, that seems to be the right direction.