Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(events): the pagesetup event timing is more like 1.x #9440

Merged
merged 1 commit into from
Mar 5, 2016

Conversation

mrclay
Copy link
Member

@mrclay mrclay commented Mar 3, 2016

In 1.x, the event was triggered just before the first view was rendered and it was assumed that some global state, particularly context, had been set by this time in page-specific code.

In 2.0 this assumption is wrong because the page-specific code that sets state like context often runs within a resource view. Hence the event is triggered too early, before the page-specific state has been set up.

Here we delay the pagesetup event if the first view is a resource view.

This allows plugins to move all page-specific logic like context setting into a resource view with more confidence that that state will be available in their pagesetup event handlers. This likely fixes a class of undiscovered bugs like #9271 and #9322.

Refs #8374

  • Add note to see the commit description, merge

@mrclay mrclay mentioned this pull request Mar 3, 2016
1 task
@@ -329,6 +330,32 @@ protected function fileExists($path) {
}

/**
* Trigger the system "pagesetup" event just before the 1st view rendering, or the 2nd if the 1st
* view starts with "resources/".
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be best to add a short explanation why it is being done like this.

@juho-jaakkola
Copy link
Member

LGTM

In 1.x, the event was triggered just before the first view was rendered
and it was assumed that some global state, particularly context, had been
set by this time in page-specific code.

In 2.0 this assumption is wrong because the page-specific code that sets
state like context often runs *within* a resource view. Hence the event
is triggered too early, before the page-specific state has been set up.

Here we delay the `pagesetup` event if the first view is a resource view.

This allows plugins to move all page-specific logic like context setting
into a resource view with more confidence that that state will be available
in their `pagesetup` event handlers. This likely fixes a class of
undiscovered bugs like Elgg#9271 and Elgg#9322.

Refs Elgg#8374
mrclay added a commit that referenced this pull request Mar 5, 2016
fix(events): the pagesetup event timing is more like 1.x
@mrclay mrclay merged commit 9ae91d8 into Elgg:2.0 Mar 5, 2016
@mrclay mrclay deleted the delay_pagesetup branch March 5, 2016 23:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants