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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

catch’s picture

Subscribing.

Dries’s picture

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.

greg.harvey’s picture

Rules is the way forward for this Drupal developer. I barely use Actions and Triggers. I wouldn't miss it. +1

BarisW’s picture

I agree. Let's get it out ;)

BarisW’s picture

Title: Remove actions and trigger from Druapl 7 core. » Remove actions and trigger from Drupal 7 core

Typo in the title

swentel’s picture

Title: Remove actions and trigger from Drupal 7 core » Remove actions and trigger from Druapl 7 core.

Ok for me too!

swentel’s picture

Title: Remove actions and trigger from Druapl 7 core. » Remove actions and trigger from Drupal 7 core

aargh, didn't mean to change the title.

jschumann’s picture

Title: Remove actions and trigger from Drupal 7 core » Remove actions and trigger from Druapl 7 core.

Yeah, by the time 8 is ready, one of the other contrib solutions (rules?) might be the one to put back into core.

davyvdb’s picture

Wouldn't miss it either. Rules is indeed the way to go.

BassistJimmyJam’s picture

Title: Remove actions and trigger from Druapl 7 core. » Remove actions and trigger from Drupal 7 core

I'm all for this one. I always end up using Rules instead of Actions & Triggers. I would really like to see Rules make it in to core at some point, but it's too late for that in D7.

webchick’s picture

Title: Remove actions and trigger from Drupal 7 core » Remove actions and trigger from Druapl 7 core.

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.

greg.harvey’s picture

Title: Remove actions and trigger from Druapl 7 core. » Remove actions and trigger from Drupal 7 core.

Trying to set the title again. ;-)

webkenny’s picture

Title: Remove actions and trigger from Drupal 7 core. » Remove actions and trigger from Drupal 7 core

+1 Removing it makes a lot of sense to me.

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.

[EDIT: Didn't mean to remove the period on the title. Weird]

mcrittenden’s picture

Title: Remove actions and trigger from Drupal 7 core » Remove actions and trigger from Drupal 7 core.

I'd personally be in favor of this. Like Peter said, I generally go for Rules and the like instead of actions/triggers, and I think many others do the same.

catch’s picture

Title: Remove actions and trigger from Drupal 7 core. » Remove actions and trigger from Drupal 7 core

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.

fending’s picture

Title: Remove actions and trigger from Drupal 7 core » Remove actions and trigger from Druapl 7 core.

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.

alexjarvis’s picture

Title: Remove actions and trigger from Drupal 7 core. » Remove actions and trigger from Drupal 7 core

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.]

fgm’s picture

Title: Remove actions and trigger from Druapl 7 core. » Remove actions and trigger from Drupal 7 core

I certainly wouldn't miss them myself, but as webchick said in #11, this is extraordinarily late to remove a feature, albeit probably still a weak one. Even profile is still there...

eaton’s picture

Title: Remove actions and trigger from Drupal 7 core » Remove actions and trigger from Druapl 7 core.

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.

Dave Reid’s picture

I wouldn't miss it as well. But this is *way too late* to consider this.

chx’s picture

Title: Remove actions and trigger from Druapl 7 core. » Remove actions and trigger from Drupal 7 core.

It did not belong to Drupal 6 either, it was abandoned the minute it got in.

greg.harvey’s picture

@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.

Stalski’s picture

subscribe.
Drop it . I am also very very fond of the rules module.

sun’s picture

Title: Remove actions and trigger from Drupal 7 core » Remove actions and trigger from core or revamp/improve them
Version: 7.x-dev » 8.x-dev

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.

webchick’s picture

Title: Remove actions and trigger from core or revamp/improve them » Remove actions and trigger from Drupal 7 core.
Version: 8.x-dev » 7.x-dev

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.

Dries’s picture

Title: Remove actions and trigger from Drupal 7 core. » Remove actions and trigger from core or revamp/improve them
Version: 7.x-dev » 8.x-dev

@sun: quite the contrary, it helps get Drupal 7 out faster. Removing a module doesn't destabilize things. In fact, we would be able to move a few critical bugs from core to contrib. ;)

That said, I agree that this is late in the game. It just seems that actions and triggers are failing, and sometimes it is better to fail fast.

yoroy’s picture

Title: Remove actions and trigger from core or revamp/improve them » Remove actions and trigger from Drupal 7 core.
Version: 8.x-dev » 7.x-dev

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 :)

Bojhan’s picture

Title: Remove actions and trigger from Drupal 7 core. » Remove actions and trigger from Drupal 7 core

Subscribing

eaton’s picture

Title: Remove actions and trigger from Drupal 7 core » Remove actions and trigger from Drupal 7 core.

@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.

jrabeemer’s picture

Title: Remove actions and trigger from Drupal 7 core. » Remove actions and trigger from core or revamp/improve them
Version: 7.x-dev » 8.x-dev

Guys, we are crossposting like crazy. :-)

alexjarvis’s picture

Title: Remove actions and trigger from core or revamp/improve them » Remove actions and trigger from Drupal 7 core?
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.

Dries’s picture

Title: Remove actions and trigger from Drupal 7 core? » Remove actions and trigger from core or revamp/improve them

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.

Crell’s picture

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.)

catch’s picture

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.

webchick’s picture

Status: Active » Postponed

@sun: quite the contrary, it helps get Drupal 7 out faster. Removing a module doesn't destabilize things. In fact, we would be able to move a few critical bugs from core to contrib. ;)

Actually, if that's the reason, then that seems a bit silly. I only count 3 / 123 (~2.4%) critical issues assigned to trigger.module, and two of them are RTBC.

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%).

I think it's safe to mark this 8.x, "postponed" now. Move along, nothing here to see until Drupal 8. Let's go attack that critical queue! :D

eaton’s picture

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%).

Crafty, Webchick. Very crafty.

webchick’s picture

Oh, but in the interest of actual facts rather than wanton hyperbole:

"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.

alexjarvis’s picture

I wonder if we don't need to make a review of the modules to be included in core a priority for D8: #764684: Trimming core modules in D8?

Dries’s picture

@webchick: clearly, I wasn't advocating that we removed these module because of critical bugs. I was just correcting, sun.

@catch: profile and tracker are different -- you really can't make things that black and white.

@webchick: I agree that the statistics are compelling and that based on those statistics, we should postpone.

@all: glad to see all this passion -- that's a good sign. ;-)

catch’s picture

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 ;)

greg.harvey’s picture

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.

Actions/Trigger has a crappy API/interface.

Precisely!!

sun’s picture

Status: Postponed » Closed (won't fix)
  1. The effective result of this issue will be yet another debate about #bettercore. Please go to http://smallcore.org and use the non-existing discussion board over there, thanks.
  2. If not, then let's stop wasting time here. Or unsubscribe me from this issue, please. Oh, unsubscribe? In case you didn't notice, the solution for issue subscriptions will be based on actions.
  3. We need proper answers for the challenges we are facing. The most simple is not always the proper answer.
pwolanin’s picture

Title: Remove actions and trigger from core or revamp/improve them » Remove actions and trigger from Drupal 7 core.
Version: 8.x-dev » 7.x-dev
Status: Closed (won't fix) » Active

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).

pwolanin’s picture

Version: 7.x-dev » 8.x-dev
Status: Active » Postponed
sun’s picture

Title: Remove actions and trigger from Drupal 7 core. » Remove actions and trigger from core or revamp/improve them
Status: Postponed » Closed (won't fix)
mcrittenden’s picture

Status: Closed (won't fix) » Active

This issue obviously isn't "won't fix" ...why don't we all agree on setting active for D8 and crossing that bridge when we get to it.

fago’s picture

@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.

andypost’s picture

pwolanin’s picture

Just looked at some of the code again in system module. Please, let's rip it out if no one is going to maintain it.

catch’s picture

Crosslinking #1008166: Actions should be a module that at least puts it into quarantine.

colan’s picture

Subscribing.

lpalgarvio’s picture

Issue tags: +actions, +triggers, +rules

Dries is pushing the idea of a Context implementation getting into core, with Drupal 8, along with other neat things:

- Multi-device publishing (aka mobile); clean HTML/CSS, HTML5, contexts, web services APIs, etc
- Interopability and integration with cloud services: web service APIs, pluggable components, clean data models, etc
- Delightful experience: accessibility, usability, performance
- Configuration management: better separation between content and configuration, universally unique identifiers (UUIDs), exportables, more consistent CRUD APIs, etc
- Content staging

http://buytaert.net/starting-to-work-on-drupal-8
http://angrylittletree.com/11/01/drupal-8-road-ahead
http://www.garfieldtech.com/blog/web-services-initiative

the unified Context idea resulted in the project Butler:
http://drupal.org/project/butler

other posts about Drupal 8:
http://buytaert.net/8-steps-for-drupal-8
http://groups.drupal.org/node/116044
http://groups.drupal.org/drupal-initiatives
http://groups.drupal.org/wscci

given that a Context system is in Dries' plans to get into D8 core, why not also a full Rules system? ;)
Rules is the true replacement for workflow-ng, and the core's Actions and Triggers modules.

and it's ecosystem is getting big:
http://drupal.org/project/modules?filters=bs_project_sandbox%3A0&text=rules
has support for:
- Features,
- Token,
- Views,
- Context,
- Domain Access,
- Organic Groups,
- Webform,
- Flag,
- Voting API,
- Cache (Cache Actions can work with %args (like nid) in Views and Panels caches),
- Heartbeat,
- Signup,
- Ubercart 2.x,
- Ubercart 3.x,
- Commerce,
- Git,
- etc
through rules itself or through other modules integrated with rules, just to name a few.

i'd like to see Rules pushed into core to replace Actions and Triggers, or at very least, remove Actions and Triggers from core.
http://drupal.org/node/1211396

lpalgarvio’s picture

lpalgarvio’s picture

Title: Remove actions and trigger from core or revamp/improve them » Remove actions and trigger from core or revamp/improve them or replace with Rules module

oh, forgot to mention that Rules for D7 is getting a re-haul on the UI to be more friendly at very least AFAIK.

chx’s picture

Title: Remove actions and trigger from core or revamp/improve them or replace with Rules module » Remove actions and trigger from core or revamp/improve them

I do not think Rules is core ready.

lpalgarvio’s picture

well, if it isn't, it might/could be by D8 feature freeze, right? give a chance ;)
http://groups.drupal.org/node/81484

bojanz’s picture

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.

lpalgarvio’s picture

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.

Lars Toomre’s picture

@chx - Could you elaborate on why (ideally with some examples) you feel Rules module is not core ready? How would you like to see this very useful module further evolve? Thanks!!

webchick’s picture

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).

Trigger module though is a waste of space. :P

sun’s picture

Title: Remove actions and trigger from core or revamp/improve them » Remove Trigger module from core
Status: Active » Reviewed & tested by the community
Issue tags: -actions, -triggers, -rules
rm -r modules/trigger
git commit -am "- #764558 by webchick: Remove Trigger module from core."

You don't really need a patch for that, do you?

sun’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +DIE, +API clean-up
FileSize
73.63 KB

kk, turns out that there's a whack interdependency in an actions test.

lpalgarvio’s picture

Status: Needs work » Needs review

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.

http://drupal.org/project/actions is currently occupied by the backport (D5) of the actions module was developed for D6 core.

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.

http://drupal.org/project/trigger & http://drupal.org/project/triggers namespace empty, available.

about Rules and drupal core:
http://drupal.org/node/1211396

about Rules and drupal.org:
http://drupal.org/node/1217078

Status: Needs review » Needs work

The last submitted patch, drupal8.trigger-die.62.patch, failed testing.

fgm’s picture

Status: Needs review » Needs work

@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.

Better not create yet another related project, it seems.

catch’s picture

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).

fago’s picture

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.

sun’s picture

Status: Needs work » Needs review
FileSize
73.68 KB

Most of the recent discussion about improving actions in core should be moved to a new issue. Otherwise, the information is lost once this issue is fixed.

sun’s picture

Issue tags: +Framework Initiative
chx’s picture

FileSize
69.65 KB

Rerolled.

Status: Needs review » Needs work

The last submitted patch, 764558.patch, failed testing.

sun’s picture

Status: Needs work » Needs review
Issue tags: -Framework Initiative
FileSize
73.68 KB

@chx: Not sure what's wrong with #69? Applies cleanly for me and also passed tests. Re-attaching.

chx’s picture

Status: Needs review » Reviewed & tested by the community

Pending bot update.

chx’s picture

Status: Reviewed & tested by the community » Needs review

We need to wait for community feedback.

bojanz’s picture

Status: Needs review » Reviewed & tested by the community

Huh? I don't see a single person in the previous 70 comments opposing it. The main opposition was for removing actions, not trigger. Even webchick said she doesn't care about trigger.

sun’s picture

Issue tags: +Framework Initiative

Trigger module is the part that doesn't make sense, from whatever angle you look at it. DX is a mess, UX is a mess.

Actions is the concept we want to retain, because many contrib modules implement it, some rely on it, and we actually want to advance on that.

eaton’s picture

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.

gmak’s picture

I agree that Trigger should be removed from core. I find that using Rules is far more reliable and flexible.

Dries’s picture

I'd be comfortable removing this module. Let's give it a bit more time for discussion though.

Crell’s picture

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.

catch’s picture

@Crell that's being discussed, fairly productively, over at #1255674: [meta] Make core maintainable.

andypost’s picture

Suppose before removal we should create a contrib module! I'd like to co-maintain it in contrib

PS: namespaces are free see #764558-64: Remove Trigger module from core

Crell’s picture

Status: Reviewed & tested by the community » Postponed

Until we have a standard to determine what should and should not be in core, no more modules should be removed. See #1255674-111: [meta] Make core maintainable for a proposed standard and comment there.

Dries’s picture

Status: Postponed » Reviewed & tested by the community

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.

sun’s picture

Status: Reviewed & tested by the community » Postponed
Issue tags: -Framework Initiative +Platform Initiative

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.

(Also exchanging the issue tag, as clarified in #1255674: [meta] Make core maintainable)

RobLoach’s picture

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.

sun’s picture

Status: Postponed » Reviewed & tested by the community

Since the community is unable to reach consensus on fundamental issues, this is back on the table, still applies cleanly, and is still RTBC.

Dries’s picture

I still think it is a good idea to remove trigger module (independent of what direction we go in). I'll remove this module later today or tomorrow. We can always bring it back in.

eaton’s picture

As an exercise, I'll try to run Trigger module in particular (not the entire Actions system, just Trigger module) through the questions that we're ironing out in #1273344: Establish heuristics for core feature evaluation.

  1. Is it needed for Drupal web sites, automated tests, installation profiles, or drush commands to operate properly? Nope.
  2. 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.
  3. 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
  4. Would it be impractical or impossible to implement as an optional plugin or contrib module? No: alternative solutions have thrived in contrib.
  5. 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.
  6. 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.
  7. 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.
  8. 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.

lpalgarvio’s picture

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.

David_Rothstein’s picture

Status: Reviewed & tested by the community » Needs work
FileSize
64.58 KB

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.

catch’s picture

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.

RobLoach’s picture

Status: Needs work » Needs review
FileSize
96.18 KB

Should there be an upgrade path to check if Rules is available, and then enable it?

xjm’s picture

Status: Needs review » Needs work

Note that this patch will need to be rerolled, because the core directory structure for Drupal 8 has now changed. (For more information, see #22336: Move all core Drupal files under a /core folder to improve usability and upgrades). When the patch has been rerolled, please set the issue back to "Needs Review."

If you need help rerolling this patch, you can come to core office hours or ask in #drupal-gitsupport on IRC.

RobLoach’s picture

Status: Needs work » Needs review
FileSize
125.95 KB

Since we're removing the Actions UI as well, there really isn't any reason to have actions in there. Let's bring people over to Rules.

webchick’s picture

No. Out of scope. Actions are very useful re-usable snippets of code and are used by many dozens/hundreds of contributed modules. Rules doesn't yet have that kind of penetration.

What we should probably discuss is bringing conditional actions into core. Or we might discuss removing actions. But it is completely and totally separate from Trigger module. Separate issue.

Status: Needs review » Needs work

The last submitted patch, trigger.patch, failed testing.

RobLoach’s picture

Status: Needs work » Needs review

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?

RobLoach’s picture

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.

RobLoach’s picture

FileSize
94.36 KB

........... #RobCanBeDistracted

webchick’s picture

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).

Status: Needs review » Needs work

The last submitted patch, trigger.patch, failed testing.

RobLoach’s picture

Some of the top modules that incorporate Actions support include Flag, Views Bulk Operations, OG, Quiz, Workflow, etc.

Quick note! Only Quiz is the one without Rules support: #1213600: Deprecate actions module and replace it with Rules... Workflow isn't up to Drupal 7, probably because people have moved to Workbench/Maestro.

webchick’s picture

Great. It's a useful API then it should be moved into core. Back to "Let's improve actions, and not remove it." ;) In a separate issue.

Can we please get back on-topic to just dropping Trigger module now? :)

Lars Toomre’s picture

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?

Lars Toomre’s picture

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?

RobLoach’s picture

@webchick Remove Trigger module here, discuss Actions UI/Actions API in another issue.

The scope of this issue...

  1. Remove the Trigger module
  2. Remove notes/links about the Trigger module
  3. Leave the Actions API
  4. 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?

Rules does all the things Trigger/Actions does, and more.

Lars Toomre’s picture

@Rob Loach... but Rules is not part of core and as @webchick pointed out in #102, Rules just hit stable release last month (some ten months after D7 core was released).

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

Until Rules (or the Trigger replacement) is part of core, it appears removing the Trigger module will leave core actions orphaned -- or am I wrong?

RobLoach’s picture

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.

As an added bonus, here's a fancy video from eaton :-) .

Until Rules (or the Trigger replacement) is part of core, it appears removing the Trigger module will leave core actions orphaned

I'm with you here. It seems quite strange to leave an orphaned Actions, but like webchick mentioned, it is technically a separate follow-up issue.

catch’s picture

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).

webchick’s picture

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."

fago’s picture

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...

eaton’s picture

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.

catch’s picture

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.

RobLoach’s picture

@catch There's an issue somewhere to move actions to a module

#1008166: Actions should be a module

RobLoach’s picture

Status: Needs work » Needs review
Issue tags: +Needs issue summary update
FileSize
82.13 KB

The attached patch...

  1. Removes Trigger module
  2. Removes the tests that hit Trigger
  3. Leaves the Actions API
  4. Leaves the Actions UI
andypost’s picture

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

There's a big probability that while trigger in core there would be a buzz about 'orphaned' actions and trigger. But if someone commit this patch we get actions 'orphaned' in core 'til d8 release

Right now there's no solution about UI for actions and trigger, rules UI not the best so it's really easy to remove something having nothing to replace

catch’s picture

Status: Needs review » Needs work
Issue tags: +Needs issue summary update, +DIE, +API clean-up, +Platform Initiative

The last submitted patch, 764558-removetrigger.patch, failed testing.

catch’s picture

Status: Needs work » Needs review
FileSize
82.14 KB

Re-rolled, the only failing hunk was the removal of trigger module itself, everything else still applies cleanly.

msonnabaum’s picture

Status: Needs review » Reviewed & tested by the community

Looks good to me.

catch’s picture

Assigned: Unassigned » Dries

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.

webchick’s picture

Given Dries is about to take off to DDU, can we please make that 10 days instead?

David_Rothstein’s picture

Status: Reviewed & tested by the community » Needs work
  1. 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
    
  2. I'm concerned that we're losing some test coverage of the actions system here. The most obvious one is this:
    --- a/core/modules/simpletest/tests/actions.test
    +++ b/core/modules/simpletest/tests/actions.test
    -/**
    - * Test actions executing in a potential loop, and make sure they abort properly.
    - */
    -class ActionLoopTestCase extends DrupalWebTestCase {
    

    ... since it's not even part of the Trigger module. But there may also be others.

    For ActionLoopTestCase I don't see why we would need to remove the test; it seems like it shouldn't be hard to change it to not depend on the Trigger module instead.

sun’s picture

For ActionLoopTestCase I don't see why we would need to remove the test; it seems like it shouldn't be hard to change it to not depend on the Trigger module instead.

Right, this test should not be removed. My patch in #73 rewrote the test to work without Trigger module - no idea why that was dismissed in later re-rolls.

xjm’s picture

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:

  • forms stuff
  • JS stuff
  • the 'triggers' key as above in implementations of hook_action_info()
  • nonspecific use of the word ("trigger an error," etc.)
xjm’s picture

Oops, at least one more:

modules/system/system.api.php: * @see trigger_example_action_info_alter()

I'll reroll with sun's version of the actions loop test from #73 and cleaning up the straggling references.

xjm’s picture

Status: Needs work » Needs review
FileSize
9.25 KB
81.83 KB
skottler’s picture

Status: Needs review » Needs work

@David_Rothstein,

We should dereference Trigger in the system module, which should be relatively simple given the fact that the lines returned from your grep above use it as an example for implementation.

I am willing to maintain Trigger in contrib.

skottler’s picture

Status: Needs work » Needs review

@xjm submitted her patch during the time I was writing my comment. Setting back to needs review.

skottler’s picture

Status: Needs review » Reviewed & tested by the community

I tested the patch in #129, all seems to be working well. Marking RTBC.

xjm’s picture

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.

catch’s picture

@webchick, every day this waits for a decision, is another day people spend wasting time in issues like #1280792: Trigger upgrade path: Node triggers removed when upgrading to 7-dev from 6.25 not knowing which version to work against.

I make ten days January 21st so let's sort this out by then.

sun’s picture

Thanks for re-incorporating the test changes from #73. Patch looks ready to fly for me.

I'm actually not sure what kind of approval or feedback we're waiting for? @Dries clearly stated in #89 already that he's perfectly fine with removing Trigger and thinks it is a good idea.

After all, it was "us" (me) who reverted the earlier RTBC status - not @Dries.

andypost’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/core/modules/system/system.module
@@ -89,8 +89,6 @@ function system_help($path, $arg) {
-      $output .= '<dt>' . t('Configuring actions') . '</dt>';

Any reason to remove this? Suppose it should be changed

-16 days to next Drupal core point release.

xjm’s picture

Ah, good catch. We should rewrite that rather than removing it. I'll fix that.

xjm’s picture

Status: Needs work » Needs review
FileSize
2.28 KB
81.62 KB

With the actions description edited to remove references to trigger, rather than removed entirely.

xjm’s picture

Priority: Normal » Major

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. :)

webchick’s picture

Priority: Major » Normal

Sorry, there's no reason the presence or absence of a module no one uses should block progress on the rest of D8.

webchick’s picture

That said, I will miss it. :)

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.

RobLoach’s picture

Status: Needs review » Reviewed & tested by the community

Applies cleanly. After applying, no reference to Trigger module in the Actions UI. Looks good to me! Actions tests pass. Setting this back to RTBC!

That said, I will miss it. :)

Have no fear, you can still invoke Actions via Rules ;-) ... Conditional ones at that!

xjm’s picture

klonos’s picture

Will it vanish or go in contrib? Just asking because I see no http://drupal.org/project/trigger

catch’s picture

@skottler in #130 agreed to maintain trigger in contrib.

We will either need that, or tell people to use rules instead.

If there is trigger available as a contrib module, that completely covers an upgrade path.

If instead people are pointed to rules, then we'll either need to write an automated upgrade path (in a follow-up in the rules queue), or tell people to recreate their triggers as rules manually.

aspilicious’s picture

I think skottler offered to maintain the upgrade path to rules in contrib...

skottler’s picture

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.

xjm’s picture

I opened #1413214: Provide upgrade path from Trigger to Rules. If some folks take this up, we could even provide the upgrade path in rules now, in D7, to ease the transition.

Edit: The above issue should not block this one; however, do we want to track it somehow (maybe #1393358: [META-12] Review 'revisit before release candidate' tag) to keep an eye on its status?

skottler’s picture

The Trigger project now contains the Trigger module straight from 8.x-dev.

Can't wait to get this done :)

Dries’s picture

Alright, this looks great. I still think it can be removed so committed the patch in #138.

aspilicious’s picture

Title: Remove Trigger module from core » Change notification: Remove Trigger module from core
Priority: Normal » Critical
Status: Reviewed & tested by the community » Active

This needs a change notification

webchick’s picture

Assigned: Dries » Unassigned

Yay! Thanks, Dries!

Dries’s picture

Title: Change notification: Remove Trigger module from core » Remove Trigger module from core
Assigned: Unassigned » Dries
Priority: Critical » Normal
Status: Active » Fixed

Oh yeah. Committed to 8.x. See you on the other side, Trigger module. Thanks all.

Dries’s picture

Assigned: Dries » Unassigned
Tor Arne Thune’s picture

Title: Remove Trigger module from core » Change notification: Remove Trigger module from core
Priority: Normal » Critical
Status: Fixed » Active
Issue tags: +Needs change record

Cross-post I suppose.

Tor Arne Thune’s picture

Title: Change notification: Remove Trigger module from core » Remove Trigger module from core
Priority: Critical » Normal
Status: Active » Fixed
Issue tags: -Needs change record

Status: Fixed » Closed (fixed)
Issue tags: -Needs issue summary update, -DIE, -API clean-up, -Platform Initiative

Automatically closed -- issue fixed for 2 weeks with no activity.

geerlingguy’s picture

Issue summary: View changes

Posting updated change record link: https://drupal.org/node/2116417 (for those browsing this issue from the bottom-up :).

Chris Matthews’s picture

Even though this thread is old...I found it today because I needed a send email action to happen on a particular trigger, but then realized Actions was removed from core. I went over to #1413214: Provide upgrade path from Trigger to Rules, but it hasn't seen much "action" (no pun intended) and the Rules module is still in -alpha. Just curious what the best course of action is (no pun intended) for this particular simple use case.

colan’s picture

How about Business Rules?

dalra’s picture

Another alternative could be If Then Else.