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.
Comment | File | Size | Author |
---|---|---|---|
#138 | kill-trigger-764558-137.patch | 81.62 KB | xjm |
#138 | interdiff.txt | 2.28 KB | xjm |
#129 | remove-trigger-764558-128.patch | 81.83 KB | xjm |
#129 | interdiff-121-128.txt | 9.25 KB | xjm |
#121 | 764558_remove_trigger.patch | 82.14 KB | catch |
Comments
Comment #1
catchSubscribing.
Comment #2
Dries CreditAttribution: Dries commentedI'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.
Comment #3
greg.harveyRules is the way forward for this Drupal developer. I barely use Actions and Triggers. I wouldn't miss it. +1
Comment #4
BarisW CreditAttribution: BarisW commentedI agree. Let's get it out ;)
Comment #5
BarisW CreditAttribution: BarisW commentedTypo in the title
Comment #6
swentel CreditAttribution: swentel commentedOk for me too!
Comment #7
swentel CreditAttribution: swentel commentedaargh, didn't mean to change the title.
Comment #8
jschumann CreditAttribution: jschumann commentedYeah, by the time 8 is ready, one of the other contrib solutions (rules?) might be the one to put back into core.
Comment #9
davyvdb CreditAttribution: davyvdb commentedWouldn't miss it either. Rules is indeed the way to go.
Comment #10
BassistJimmyJam CreditAttribution: BassistJimmyJam commentedI'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.
Comment #11
webchickHaving 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.
Comment #12
greg.harveyTrying to set the title again. ;-)
Comment #13
webkenny CreditAttribution: webkenny commented+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]
Comment #14
mcrittenden CreditAttribution: mcrittenden commentedI'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.
Comment #15
catchI 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.
Comment #16
fending CreditAttribution: fending commentedImproving 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.
Comment #17
alexjarvis CreditAttribution: alexjarvis commentedI'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.]
Comment #18
fgmI 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...
Comment #19
eaton CreditAttribution: eaton commentedThere 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.
Comment #20
Dave ReidI wouldn't miss it as well. But this is *way too late* to consider this.
Comment #21
chx CreditAttribution: chx commentedIt did not belong to Drupal 6 either, it was abandoned the minute it got in.
Comment #22
greg.harvey@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.
Comment #23
Stalski CreditAttribution: Stalski commentedsubscribe.
Drop it . I am also very very fond of the rules module.
Comment #24
sunThis 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.
Comment #25
webchickUm. 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.
Comment #26
Dries CreditAttribution: Dries commented@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.
Comment #27
yoroy CreditAttribution: yoroy commentedSubscribe. 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 :)
Comment #28
Bojhan CreditAttribution: Bojhan commentedSubscribing
Comment #29
eaton CreditAttribution: eaton commentedRules 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.
Comment #30
jrabeemer CreditAttribution: jrabeemer commentedGuys, we are crossposting like crazy. :-)
Comment #31
alexjarvis CreditAttribution: alexjarvis commentedGood 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.
Comment #32
Dries CreditAttribution: Dries commentedWhy 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.
Comment #33
Crell CreditAttribution: Crell commentedI 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.)
Comment #34
catchIf 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.
Comment #35
webchickActually, 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
Comment #36
eaton CreditAttribution: eaton commentedCrafty, Webchick. Very crafty.
Comment #37
webchickOh, 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.
Comment #38
alexjarvis CreditAttribution: alexjarvis commentedI 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?
Comment #39
Dries CreditAttribution: Dries commented@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. ;-)
Comment #40
catchprofile 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 ;)
Comment #41
greg.harveyI 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.
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.
Precisely!!
Comment #42
sunComment #43
pwolanin CreditAttribution: pwolanin commentedThe 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).
Comment #44
pwolanin CreditAttribution: pwolanin commentedComment #45
sunA much better target to work on: #218066: Prevent cross posting from reverting metadata fields
Comment #46
mcrittenden CreditAttribution: mcrittenden commentedThis 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.
Comment #47
fago@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.
Comment #48
andypostAnother reference #244093: Node and comment actions are (still) completely broken and have broken tests too
Comment #49
pwolanin CreditAttribution: pwolanin commentedJust looked at some of the code again in system module. Please, let's rip it out if no one is going to maintain it.
Comment #50
catchCrosslinking #1008166: Actions should be a module that at least puts it into quarantine.
Comment #51
colanSubscribing.
Comment #52
lpalgarvio CreditAttribution: lpalgarvio commentedDries is pushing the idea of a Context implementation getting into core, with Drupal 8, along with other neat things:
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
Comment #53
lpalgarvio CreditAttribution: lpalgarvio commentedwiki page:
http://groups.drupal.org/rules/rules-modules
Comment #54
lpalgarvio CreditAttribution: lpalgarvio commentedoh, forgot to mention that Rules for D7 is getting a re-haul on the UI to be more friendly at very least AFAIK.
Comment #55
chx CreditAttribution: chx commentedI do not think Rules is core ready.
Comment #56
lpalgarvio CreditAttribution: lpalgarvio commentedwell, if it isn't, it might/could be by D8 feature freeze, right? give a chance ;)
http://groups.drupal.org/node/81484
Comment #57
bojanz CreditAttribution: bojanz commentedKeeping 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.
Comment #58
lpalgarvio CreditAttribution: lpalgarvio commentedViews, 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.
Comment #59
Lars Toomre CreditAttribution: Lars Toomre commented@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!!
Comment #60
webchickI 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
Comment #61
sunYou don't really need a patch for that, do you?
Comment #63
sunkk, turns out that there's a whack interdependency in an actions test.
Comment #64
lpalgarvio CreditAttribution: lpalgarvio commentedmaybe 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.
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
Comment #66
fgm@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.
Comment #67
catchI 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).
Comment #68
fagoThe 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.)
Generally agreed, however we should aim on unifying the action API asap + an action API really belongs into core.
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.
Comment #69
sunMost 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.
Comment #70
sunComment #71
chx CreditAttribution: chx commentedRerolled.
Comment #73
sun@chx: Not sure what's wrong with #69? Applies cleanly for me and also passed tests. Re-attaching.
Comment #74
chx CreditAttribution: chx commentedPending bot update.
Comment #75
chx CreditAttribution: chx commentedWe need to wait for community feedback.
Comment #76
bojanz CreditAttribution: bojanz commentedHuh? 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.
Comment #77
sunTrigger 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.
Comment #78
eaton CreditAttribution: eaton commentedIronically, 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.
Comment #79
gmak CreditAttribution: gmak commentedI agree that Trigger should be removed from core. I find that using Rules is far more reliable and flexible.
Comment #80
Dries CreditAttribution: Dries commentedI'd be comfortable removing this module. Let's give it a bit more time for discussion though.
Comment #81
Crell CreditAttribution: Crell commentedHonestly, 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.
Comment #82
catch@Crell that's being discussed, fairly productively, over at #1255674: [meta] Make core maintainable.
Comment #83
andypostSuppose 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
Comment #84
Crell CreditAttribution: Crell commentedUntil 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.
Comment #85
Dries CreditAttribution: Dries commentedCrell: 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.
Comment #86
sunIt 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)
Comment #87
RobLoachRules 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.
Comment #88
sunSince the community is unable to reach consensus on fundamental issues, this is back on the table, still applies cleanly, and is still RTBC.
Comment #89
Dries CreditAttribution: Dries commentedI 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.
Comment #90
eaton CreditAttribution: eaton commentedAs 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.
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.
Comment #91
lpalgarvio CreditAttribution: lpalgarvio commentedi 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.
Comment #92
David_Rothstein CreditAttribution: David_Rothstein commentedWith 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.
Comment #93
catchCore 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.
Comment #94
RobLoachShould there be an upgrade path to check if Rules is available, and then enable it?
Comment #95
xjmNote 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.
Comment #96
RobLoachSince 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.
Comment #97
webchickNo. 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.
Comment #99
RobLoachWhich modules use Actions? We should update them to use Rules.
But that's what Rules is.
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?
Comment #100
RobLoachWhoops, 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.
Comment #101
RobLoach........... #RobCanBeDistracted
Comment #102
webchickYes, 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).
Comment #104
RobLoachQuick 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.
Comment #105
webchickGreat. 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? :)
Comment #106
Lars Toomre CreditAttribution: Lars Toomre commentedSimple 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?
Comment #107
Lars Toomre CreditAttribution: Lars Toomre commentedSimple 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?
Comment #108
RobLoachThe scope of this issue...
Rules does all the things Trigger/Actions does, and more.
Comment #109
Lars Toomre CreditAttribution: Lars Toomre commented@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?
Comment #110
RobLoachWe 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 :-) .
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.
Comment #111
catchfwiw 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).
Comment #112
webchickThe 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."
Comment #113
fagoImo 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...
Comment #114
eaton CreditAttribution: eaton commentedI'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.
Comment #115
catchThere'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.
Comment #116
RobLoach#1008166: Actions should be a module
Comment #117
RobLoachThe attached patch...
Comment #118
andypostThere'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
Comment #119
catch#117: 764558-removetrigger.patch queued for re-testing.
Comment #121
catchRe-rolled, the only failing hunk was the removal of trigger module itself, everything else still applies cleanly.
Comment #122
msonnabaum CreditAttribution: msonnabaum commentedLooks good to me.
Comment #123
catchIn #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.
Comment #124
webchickGiven Dries is about to take off to DDU, can we please make that 10 days instead?
Comment #125
David_Rothstein CreditAttribution: David_Rothstein commented... 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.
Comment #126
sunRight, 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.
Comment #127
xjmRe: David's comment in #125 -- The references in
system.api.php
are in the the hook definition forhook_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:
'triggers'
key as above in implementations ofhook_action_info()
Comment #128
xjmOops, at least one more:
I'll reroll with sun's version of the actions loop test from #73 and cleaning up the straggling references.
Comment #129
xjmComment #130
skottler CreditAttribution: skottler commented@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.
Comment #131
skottler CreditAttribution: skottler commented@xjm submitted her patch during the time I was writing my comment. Setting back to needs review.
Comment #132
skottler CreditAttribution: skottler commentedI tested the patch in #129, all seems to be working well. Marking RTBC.
Comment #133
xjmI 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.
Comment #134
catch@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.
Comment #135
sunThanks 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.
Comment #136
andypostAny reason to remove this? Suppose it should be changed
-16 days to next Drupal core point release.
Comment #137
xjmAh, good catch. We should rewrite that rather than removing it. I'll fix that.
Comment #138
xjmWith the actions description edited to remove references to trigger, rather than removed entirely.
Comment #139
xjmEvery 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. :)
Comment #140
webchickSorry, there's no reason the presence or absence of a module no one uses should block progress on the rest of D8.
Comment #141
webchickThat 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.
Comment #142
RobLoachApplies cleanly. After applying, no reference to Trigger module in the Actions UI. Looks good to me! Actions tests pass. Setting this back to RTBC!
Have no fear, you can still invoke Actions via Rules ;-) ... Conditional ones at that!
Comment #143
xjmOpened #1412964: Add additional test coverage for actions as a possible followup.
Comment #144
klonosWill it vanish or go in contrib? Just asking because I see no http://drupal.org/project/trigger
Comment #145
catch@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.
Comment #146
aspilicious CreditAttribution: aspilicious commentedI think skottler offered to maintain the upgrade path to rules in contrib...
Comment #147
skottler CreditAttribution: skottler commentedI 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.
Comment #148
xjmI 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?
Comment #149
skottler CreditAttribution: skottler commentedThe Trigger project now contains the Trigger module straight from 8.x-dev.
Can't wait to get this done :)
Comment #150
Dries CreditAttribution: Dries commentedAlright, this looks great. I still think it can be removed so committed the patch in #138.
Comment #151
aspilicious CreditAttribution: aspilicious commentedThis needs a change notification
Comment #152
webchickYay! Thanks, Dries!
Comment #153
Dries CreditAttribution: Dries commentedOh yeah. Committed to 8.x. See you on the other side, Trigger module. Thanks all.
Comment #154
Dries CreditAttribution: Dries commentedComment #155
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedCross-post I suppose.
Comment #156
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedChange notice.
Comment #159
geerlingguy CreditAttribution: geerlingguy commentedPosting updated change record link: https://drupal.org/node/2116417 (for those browsing this issue from the bottom-up :).
Comment #160
Chris Matthews CreditAttribution: Chris Matthews commentedEven 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.
Comment #161
colanHow about Business Rules?
Comment #162
dalra CreditAttribution: dalra commentedAnother alternative could be If Then Else.