Search

Everybody already knows this story. It have been passed down from generation to generation. You may have heard it from your grandpa or you could have read it on the Scriptures.

Everytime you’re about to create events for your next project, your hands start trembling because you already know you will end up with blasphemous names like “aaa Save articles” and “wait before saving news” so they’re executed in the correct order.

But an hero have come to change this situation.

Riding his mighty moose our hero defeated the evil and a new order began. We will never know his name, he just came back to the unknown land where he daily fight the evil together with a few choosen people.

While this legend is really widespread, not everybody knows that recently our hero’s diary have been found. I was reading his deeds, the sky was grey and crimson, when suddenly, a burst of light hit the monit… ehm the big book and the wind revealed page 2a8fc6e6ddd46c29058e044729952275dee26749 (yeah, he was used to enumerate pages like that).

I was speechless. The hero wrote on his diary the formula to get events in the order we prefer! I report here the full spell so you can use it:

You can declare in your events a method called priority. All you need is something like that:

public function priority()
{
    return 10;
}

Basically, the higher the number (default is 2), the sooner the event is called. That’s it :)

Talking seriously, I was not aware of this very very very useful thing, so I hope you smiled while reading the story (not for grammar errors, please) and take advantage of what Alistair actually committed 10 months ago.

This is so great, alpacaaa! (Both, the story and the function.)

Fantastic write-up Alpacaaa, very entertaining! Exactly the style of writing I do myself, so reading it feels like mother-ship is calling me home.

I’ve realised that I live in a reality warp-field. Somehow I thought this function was public knowledge. Now that we have a crack team of bug-busting, feature-adding, working group heroes, I think these kind of information won’t get hidden away and passed by the community in the future.

And here was me just starting to worry about whether a page I’m building would save the data before firing off to an authorisation gateway…

Now I don’t have to ask the question ;o)

Thanks ^^

Could this be added as a field on the Events Editor as it’s a core ability? Seems silly to have to customise Events to use it. Could we try and get in the 2.2 release?

Edit: Removed a completely stupid question as it was already answered…

I’ve forked Symphony 2 and added this capability in the events branch. Would the core team take a look and see if it wants to be implemented?

I don’t know if I should just send a pull request, log it as an issue? That’s why I’m mentioning it here…

Anyway, have a look: http://github.com/designermonkey/symphony-2.git

Assumed that you fix the typo in the code (see my comment on GitHub) I see this as a clear improvement to the core functionality. I tested it and it worked fine. So why not send a pull request? The team can still say no if they don’t like the implementation (or they want to freeze the feature set for Symphony 2).

You might log this as suggestion on the issue tracker.

I’ll send a pull request then.

I’ve made some changes and reasoned why to ignore one that you’ve suggested, thanks for taking a look…

Could this be added as a field on the Events Editor as it’s a core ability? Seems silly to have to customise Events to use it. Could we try and get in the 2.2 release?

But wouldn’t it always be custom events that need it anyway?

What about combining custom events and native events? In this case it might help.

Another thought: The function might at least be part of the event template — that way it would be visible in the events, no secret knowledge anymore.

I don’t follow. My point is that this function has been added so that a developer can specify the ordering of events since they have custom events with dependencies. Native events do not require this, since native events have no dependencies on one another, so I don’t think this potentially confusing concept should be exposed to the user.

It should certainly be added to the event PHP template for custom developers, but I don’t thin it’s at all useful to show in the UI. Unless I’m missing something.

I have an event that uses the PayPal extension’s filter, this one goes off to PayPal before coming back to a specified url, I need to use some other events on the page too, so wouldn’t I need this to specify the order to make sure that the filter goes last?

While this thread is completely valid, I don’t believe this is what was intended by this change.

const kHIGH = 3;
const kNORMAL = 2;
const kLOW = 1;

The event priority system seems to be only based on a Low, Normal or High scale, not by using integers. Integers work, but this could really be considered a bug in the implementation because __findEventOrder doesn’t verify against these constants.

I worry that opening this field up to just ‘any range’ makes this process must more ‘free’ than it needs to be. I’d hate to see it become like the current AddScriptToHead functions where every developer just smacks a random number in their event to make it always run last.

There needs to be a standard set so we have an idea of what should really run on the Low, Normal and High priority’s. Everyone’s situation will be different, and in some cases you will need to chain events together using more than the 3 constants, but I believe that this shouldn’t be exposed to the frontend as a free field.

Another concern I have is that it becomes ‘a useless’ field on the page:

What's that? Oh just leave it at default

To date, Symphony has managed to avoid alot of these ‘useless’ fields, and it’s something I’d like to see continue.

By default, events are set to kNormal and for 90% of events, that’s fine, so perhaps we should just leave it as one of those ‘advanced options’?

In your situation @designermonkey, the PayPal extension’s event should be of kLow priority because you always want it to fire last.

So, as there’s no documentation for this stuff, how would I set that for a standard extension with a filter? Just customise it?

I have an event that uses the PayPal extension’s filter, this one goes off to PayPal before coming back to a specified url, I need to use some other events on the page too, so wouldn’t I need this to specify the order to make sure that the filter goes last?

I’m not familiar with how the Paypal filter works, but I’d say you only need priority if your events are dependent on one another. Why does the Paypal event need to fire after other events?

Why does the Paypal event need to fire after other events?

Because it goes to Paypal URL then comes back to a different page on the site.

I may be confused as to how events work…

Events:

  1. I need to post to my gallery to decrement a number.
  2. I need to post details into an orders section.
  3. I need to go to PayPal to authorize.
  4. Paypal comes back to a different URL that does some more posting to different sections.

Can all this be done from one page? How would I do it? I was under the impression I would need to prioritize events…

So, as there’s no documentation for this stuff, how would I set that for a standard extension with a filter? Just customise it?

You would customise the event and override the priority to be one of the constants, ie. Event::kNormal

Can all this be done from one page? How would I do it? I was under the impression I would need to prioritize events…

Events work off actions as described in load. If your form doesn’t have the particular action, that event’s trigger function won’t be called. In your situation, yes, it would be an example of using the custom priority as you basically want to chain the results of the events.

Now I understand this priority stuff. Thanks a lot, Brendo, for these explanations!

Thanks Brendo…

Event::kNormal

Erm, how? Where? ;) Also, can more than one action be applied to a form? I’m really new to events, I’ve only used Symphony for data-display before now…

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details