The [pagesetup, system] event is going away

π is exactly three! And now that I have your attention, we're seriously considering removing [pagesetup, system] in 3.0.

It causes numerous problems due to firing at an very unpredictable time. We've already made changes to 2.0 to make it closer to 1.x timing, but pain persists. We're generally thinking pagesetup handler code should be moved to 1 of 3 different locations:

  • if happens every request, use [init, system] event handler.
  • if adds menu items, use [register, menu:<name>] hook.
  • if affects page display, use [shell, page] hook (or the other hooks with type "page").

Are there any case these don't cover?

  • @Ismayil e.g. a view_vars handler could return new Elgg\ViewBypass("string to return").

  • Alright, I'm mostly convinced, though nobody has really addressed my use case of affecting many pages globally based on page owner.  IK brought up the related problem of other view types, and I haven't had to deal with that so it's been off my radar.  Passing the entities explicitly is something I do in my own plugins, but with the blocking example it should be affecting all pages globally regardless of the plugin generating them.  I feel like there's a sense of lessening the importance of a global state like page owner, and when it's something specific I can hook or vars I can pass I definitely do prefer that, but I find it very useful to have that state to use for wide-reaching things.

    This may be getting off topic with regard to the pagesetup event specifically, so let's nix it already then.

  • We could fire a hook when someone sets the page owner (or when the system sets it from the URL).

    I wonder how often our automatic page owner algorithm is wrong.

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.