* main.before_files – before initializing core files stage
* main.before_db – before initializing database stage
* main.after_db – after initializing database stage
* main.before_tpl – before templating engine init stage
* main.after_tpl – after initializing templating engine init stage, but content is still not thrown
* main.before_content – before throw out content to user
* main.after_content – after throwing out main content to user
* main.before_cache – before init cache stage
* main.after_cache – after init cache stage
* main.before_session – before init session stage
* main.after_session – after init session stage
* main.settings – fired when setting stage is called
* main.before_auth – fired just before user authentification is initialized
* main.execute – on every call of {execute(module,method)}
* main.load_data_handlers – when load data handlers stage
* main.http_headers – when throwing out main http headers to user
* main.user_info – fired when we init current user information (guest or member and its details)
* main.on_post – when detected that current page was called using POST method
* main.on_ajax – when core detected that page is called with AJAX
* main.on_console – fired when we are inside cli/console/terminal
* main.on_redirect – this event called when pages redirect is in progress
* main.shutdown – framework destructor firing this event. This is done after all content thrown out, so we can do long running tasks here, without blocking user interface experience.
* core.exception – fired when exception from userspace was catched, usually from component or by calling new Exception(“message”)
* core.error – fired when we catch userland error, usually thrown using trigger_error()
* show_css.prepend – core firing this event on stage, when CSS parts were gathered, but still not processed together
* show_css.append – allows to append some custom CSS into right place, ensuring it will beused correctly with other parts
* css.before_pack – fired when CSS packing is just about to begin
* css.after_pack – after packing CSS together into one file
* show_js.prepend – core firing this event on stage, when JS parts were gathered, but still not processed together
* show_js.append – allows to append some custom JS into right place, ensuring it will beused correctly with other parts
* js.before_pack – fired when JS packing is just about to begin
* js.after_pack – after packing JS together into one file
* debug.render – fired just before debug rendering is about to start, allowing to change something or add new debug parts
* block.prepend[$block_name] – this event allows to execute custom code when template specific block $block_name was called, and prepend content right before block generated content. Note that “center_area” is special block name for main content
* block.append[$blockname] – this event allows to execute custom code when template specific block $block_name was called, and append content right before block generated content. Note that “center_area” is special block name for main content
* core.before_menu – fired before menu processed stage
* core.after_menu – fired after menu processed stage
* db.before_create_table – self-describing from its name
* db.after_create_table – self-describing from its name
* db.before_alter_table – self-describing from its name
* db.after_alter_table – self-describing from its name
* form.before_render – fired just before rendering begins
* f0rm.after_render – this event fired after form rendering was done, but we still can change/replace soemthing inside generated content
* form.before_validate – fired before form validate processing stage
* form.validate_ok – when form validation was done and result is success
* form.validate_error – when something not passing form validation
* form.after_validate – with this event we can execute code right after built-in validation ended, usualyl adding more custom validation or data processing
* form.before_update – fired after successful form validation, before updating database with form data
* form.after_update – fired when validation passed, database updated, usually to do some final processing after data is verified and ready inside database
* table.before_render – self-describing from its name, called for each table separately
* table.after_render – self-describing from its name, called for each table separately
