I'm not sure if it is a bug, or support request.
Here is my requirement, maybe I'm doing it the wrong way...
I'd like the system to check if there is the word 'node' in the actual URL, and write a message. This should be done also for Anonymous users so instead of "content is going to viewed by logged in user" I've used "User is going to view a page".
The problem with the below example is that I get the message even if 'node' is not in the URL.
array (
'cfg_8' =>
array (
'#type' => 'configuration',
'#altered' => false,
'#event' => 'init',
'#label' => 'Node in URL?',
'#active' => 1,
'#module' => 'workflow-ng',
0 =>
array (
'#type' => 'condition',
'#name' => 'workflow_ng_condition_token_compare',
'#settings' =>
array (
'regex' => 1,
'used arguments1' =>
array (
),
'text1' => '[node:url]',
'used arguments2' =>
array (
),
'text2' => 'node(/.*)?',
),
),
1 =>
array (
'#type' => 'action',
'#name' => 'workflow_ng_action_drupal_message',
'#settings' =>
array (
'message' => 'NODE is in the URL!',
'used arguments' =>
array (
),
'error' => 0,
),
),
'#name' => 'cfg_8',
),
)
Comments
Comment #1
fagoI've just changed the behavior of this event to the same pattern - it's only working for authenticated users.
I do so because of drupal's page cache - if it's turned on and the page is served from the cache the event won't be fired. So I thought I do so to avoid confusion.
To reflect his, I renamed it to "An authenticated user is going to view a page" as well the others to "Content view by an authenticated user" and "User page has been viewed by an authenticated user" -> committed.
Such an event for anonymous users is currently not supported - sry.
Comment #2
amitaibuFago,
Thanks for the answer. I think this issue is very important, as we need to be able to handle anonymous users. Actually probably more anonymous then authenticated users and common sites.
I'm thinking about two things:
* A half solution is to keep also the Anonymous view event, but to write something like User is going to view a page (For Anonymous to work disable cache) - ugly solution, but maybe better then nothing.
* How about caching the cache? (I'm a non-developer, so if I'm talking nonsense, sorry)
Comment #3
fagoProbably you are right - perhaps is disabling too much as it would work for most people. So I've removed all this checks from the code - so anonymous is now supported.
So instead I've added a help text for those events which might be affected by the page cache. It's shown on the configuration page. For this I introduced a new event_info property #description.
Comment #4
amitaibuFago,
Man your quick ;)
I have another idea. What about creating a special event for anonymous only, that will be available also when cache is enabled?
Comment #5
fagoI thought about that already, but it isn't possible in a way all actions would work correctly. So I won't.
Comment #6
amitaibuFago,
I don't wish to be a nagger, just trying to find a solution and make this module rock (even more)... ;)
If I understand correctly, if the page cache is enabled then some of the actions can not be preformed. Maybe in case a user chooses an anonymous event, then only the allowed actions will appear? (similar to the improvement I've suggested Liam
IMO The option to turn off the cache, in order to catch anonymous events is problematic.
That's it, I will not bug you anymore with this issue ;)
Comment #7
fagoI appreciate your proposals - having some other opinions is very important and eases decisions for me. So thanks for that!
So this issue is not caused by workflow-ng, it is caused by the way caching works. If you are serving cached pages, you are just bypassing the usual php code evaluation and this is nothing workflow-ng can change.
Although there is way modules can something for cached pages (hook_init) - but that isn't suitable for firing actions as not all modules are loaded (bootstrap phase) So such a feature would be quite complicated - as action authors would have to state if their action would work - but they would hardly know it theirself. So it isn't worth the effort.
Comment #8
amitaibuThe reported issue is still not solved (beta4):
(this happens for all roles, not only anonymous). IMO, The condition isn't correct.
Comment #9
(not verified) commentedComment #10
amitaibuIssue is still not solved [node:url] is still not looking in the real URL passed in the browser. (i.e. the message appears always regardless that the word NODE is not in the URL)
Comment #11
fagohm, for me it was working. Could you please use a drupal message instead of the condition, so you can display this token and see what is going wrong.
Comment #12
amitaibuOk, problem was the the name of the condition is now [user:path], and no longer [node:url].
Maybe as an MI, some warning for the admin should be given, if the condition is not a valid token?
Fixed WF:
Comment #13
fagoso, let's close this issue.. ;)
@notification: I agree that it would be fine, but not that important or easy to do. So I won't for now.
Comment #14
(not verified) commented