Tiki8 is coming up with a few minor changes. The permission definitions were moved out of the database, allowing for easier maintenance and adding of new properties. The category permission screen no longer lists the global-only permissions and the object permission lists now also display additional permissions that can be applied to the object outside of the direct type. When making the permissions global, the correct list is also extracted, fixing long time issues with scope checking of permissions.
The newest change is the introduction of a Signal/Slot type of mechanism to handle events within Tiki. It will allow to connect features through hooks rather than having to go directly in the code to check the feature and adding an extra call, leading to extremely long functions with sequential operations.
As a side benefit, it will also allow customizers to plug in new behaviors without affecting the core, making it easier to contribute and to maintain, for those cases where the feature is too specific to be contributed back.
So far, it has been partially deployed for wiki page update and creation. Much of the functionality in there still needs to be extracted, but the skeleton is in place. Events are organized in hierarchies, allowing for functionality that applies to all object types to be bound at a single location. For example,
$tikilib->update_page(...) will trigger tiki.wiki.update, which chains to tiki.wiki.save, which chains to tiki.save. Each event can have multiple functions or methods bound to it.
At this time, binding happens in a single location: lib/setup/events.php. This will change in the future to allow late event binding and speed up the setup process. However, since there is very little at this time, it's not much of an issue.
From Admin > Features > Programmer, you can see a graphical representation of the events in the system, updated live as they are deployed. The graph engine used by transitions was refactored to reduce code duplication and can now be used with very few lines of code.