Package installers
Permalink 2 users found helpful
Just getting up to speed on packages here.
If you have a functionality that depends upon an event, say page load or content publish, etc, then don't you need to ensure that the site.php config line of:
define('ENABLE_APPLICATION_EVENTS', true);
is present?
So should the installer be checking site.php for this and inserting the line as required or is there a tidier method of doing this?
Likewise, I guess, for the site_events.php file too, to hook the events. What if another functionality was installed which hooked the same event? Do multiple Event::extend calls for the same event add to the event stack in the order they're called or does the most recent replace all previous?
G
If you have a functionality that depends upon an event, say page load or content publish, etc, then don't you need to ensure that the site.php config line of:
define('ENABLE_APPLICATION_EVENTS', true);
is present?
So should the installer be checking site.php for this and inserting the line as required or is there a tidier method of doing this?
Likewise, I guess, for the site_events.php file too, to hook the events. What if another functionality was installed which hooked the same event? Do multiple Event::extend calls for the same event add to the event stack in the order they're called or does the most recent replace all previous?
G
Hopefully you mark this as an answer :)
All you need to do is have an installed package, so that guy has a controller.php just like every package out there.
in the package controller's on_start function define/enable application events.
This really isn't that different from placing it in config.php, but you can do it on a package basis.
[edit]
this works because if you check out the dispatcher.php every installed package's controller's on_start method is called.
Thanks to Remo for affirming what I thought regarding package application enabled events a few months ago.
All you need to do is have an installed package, so that guy has a controller.php just like every package out there.
in the package controller's on_start function define/enable application events.
This really isn't that different from placing it in config.php, but you can do it on a package basis.
[edit]
this works because if you check out the dispatcher.php every installed package's controller's on_start method is called.
Thanks to Remo for affirming what I thought regarding package application enabled events a few months ago.
Sweet, so the controller would look something like...To hook an event, does it still need to be in the site_events.php file, or can it be in the package somewhere?
class MyNewPackageController extends Controller { public function on_start() { define('ENABLE_APPLICATION_EVENTS', TRUE); } ... }
Found my answer here:http://www.concrete5.org/index.php?cID=76633...
It would appear that the Event::extend method goes in the on_start method as well.
So the package controller would look something like:
It would appear that the Event::extend method goes in the on_start method as well.
So the package controller would look something like:
I know this thread is quite old, but wouldn't you need to check that ENABLE_APPLICATION_EVENTS wasn't already defined (and what would happen if it was defined as FALSE in config/site.php)?
If it was already defined, you'd get a php warning/error.
But note that as of 5.4 (I think), you don't need to explicitly define this anymore (see the call to Events::enableEvents() in the Events::extend() function -- in concrete/libraries/events.php).
But note that as of 5.4 (I think), you don't need to explicitly define this anymore (see the call to Events::enableEvents() in the Events::extend() function -- in concrete/libraries/events.php).
Jordan is correct in 5.4+ you don't need it.
Mike
Mike
You can use Config::get() to check if a constant has been set or not.
No, the installer doesn't check that, it's your task as developer to ensure that you fallback or give warnings when you use advanced options like events.