String freeze: Provide 'better' example for Content context of trigger module

This is by design - if you set it to do that, that's what it does.

Again, this is a gotcha, not a bug. It's doing exactly what you're telling it to do. Demoting from critical. Someone else can set it back to by design.

This is indeed by design and is not critical.

It may not make sense in the real world, but it's doing exactly what it's being told to do.

Whyever would you set it up like that anyhow?

Consider:

1.) Automatically unpublish nodes whenever they're edited.
2.) Edit a node, publishing it.
3.) Save it.
4.) The action "On saving, unpublish" will revert it back to unpublished.

I see a logic error here, but it's not in the software.

We can wait for a core developer to look at this, but I bet they will say exactly the same as everyone here has told you.

Takafumi,

I discussed this issue with the author of the actions module before my first reply to this issue (this is my last, by the way) and responded on that basis. Unless Dries or Gabor steps in, that's as good as you're going to get.

Takafumi: what you describe is expected behavior. If you set up an action to unpublish stuff when edited, it will not be possible to publish, that's what you requested the system to do. The core actions system is ready to handle contrib triggers like "when a user in a certain role edits a post" to trigger the unpublish action, so users in higher roles can publish it. This is not a built in feature in Drupal 6. With whatever action sets, it is possible to set up conflicts like you mentioned, it is the site admins job to think about what she sets up.

So in essence, this isn't a technical error, but a documentation problem. It's a lousily chosen use case too - I don't know where you would want to irreversibly demote a node on editing, and that is obviously what happens unless you are using a role-based trigger that isn't in core.

So fix the documentation, I guess. There are plenty of other use cases that do useful things which work, there's no need to use a bad example.

Takafumi: "remove the posts from the front page" == "mark it not promoted" != "mark it unpublished"... That said, it would be the same problem with the sticky flag, not the published flag then. Let's get a better example there. Drupal 6 in itself does not have a user role restriction possibility on triggers built-in, so that existing example is not good.

Sorry that the module cannot be used for your requirements without an addon. But I still don't see how the behavior you described is not completely logical. ;)

This may well be a documentation problem, but I admit to being a bit confused as well, after looking at this for a bit this afternoon.

The example given for /admin/build/trigger/node is "...you could remove a post from the front page when the post is updated." That sounds like a very handy thing to do -- automatically unpromote an existing post when its content changes.

It seems like -- if I were to follow the example -- I'd select the action "Remove post from front page" under the heading "Trigger: After saving an updated post" so that it would only occur on updates . I definitely wouldn't want to add it under the trigger "Trigger: When either saving a new post or updating an existing post" as that would interfere with new posts in the way the OP described -- no new posts could be promoted.

My question for those trigger-happy among us is though: on a default install (or at least, on my default install), I only have a select box with available actions available for "Trigger: When either saving a new post or updating an existing post". That's exactly the trigger I don't want. All the other triggers on that page, including "After saving an updated post" say "No available actions for this trigger." If I create an advanced action, like e-mailing someone, then the advanced action (and only the advanced action) shows up as an available action for the other triggers.

So, really, I must be missing something here, too. Why are the default content-related triggers only available for "When either saving a new post or updating an existing post", and not the others? Are the others just there as placeholders for actions added through contrib?

And, won't adding any of the default actions to the only content trigger available actually be counterproductive, since all of them change something about the post's workflow and will then override the content type's workflow settings on all new and updated posts?

Heh. Of course, if you could add an action to "Remove post from front page" to the trigger "After saving an updated post", then:

- you add a new post, say a "Story", which is automatically promoted.
- the post is updated, say new content in the body.
- the trigger calls the action, which demotes the post.
(chorus)
- an administrator reviews the post, decides it should be promoted again. Edits to promote and saves, updating the post.
- the trigger calls the action, which demotes the post.
(repeat)

Maybe we do need to remove that example use case. And, possibly add another action that won't cause this problem, like e-mailing the author a confirmation message with the title of her successfully added post.

So:

1) why are non-advanced content actions only available on the trigger "When either saving a new post or updating an existing post"?
2) given that all of the available, default actions modify the workflow (and will essentially either un/publish, de/promote or de/sticky-ify all future created or updated posts, what is a better example to suggest in the embedded text?

1) There were some efforts to try to safeguard people from using incompatible actions, so actions define the operations they run on. See node_action_info() in node.module for example. Most node actions can only be associated with nodeapi presave.
2) Sending off an email or displaying a custom message could be good examples.

The attached patch changes the example use case on /admin/build/trigger/node to:

For example, you could send an e-mail to an administrator when a post is created or updated.

instead of:

For example, you could remove a post from the front page when the post is updated.

Note that there really isn't a "good" way to actually do the existing example. Plus, trigger module already uses a similar example in the Users and Taxonomy contexts.

I considered replacing the example in the Comments context as well, for consistency, but as far as I know the current example ("you could promote a post to the front page when a comment is added") won't lead to the same problem it does on Content.

This patch violates the string-freeze, but, IMO, is necessary.

Agreed, committed, thanks. The comment example is indeed not conflicting, since it would re-promote the node for each comment. As long as you do positive things, the actions work well there. For negative things, you need user role limited actions or some other way to tell when not to apply the negative effect. Such triggers will be provided by contrib modules.