CUNY Academic Commons

Thanks for the report, Boone.

I'll take a look at it before the next maintenance release.

So this took me down the rabbit hole!

In #3780, we customized the login page so it would use the current theme's page template. That technique involved object-buffering the contents of the login header first, followed by the current theme's page template and later injecting some login markup into the page template.

The rationale for this, as far as I can remember, was to not include various unrelated assets (like plugin CSS and JS) on the login page.

I did remember a similar issue that was raised awhile ago -- #6644. #6644 found a quirk with how this technique is used and Boone found the symptoms, but I guess I totally forgot about that ticket!

So anyway, I believe the quirk is due to how WordPress internally queues up various scripts and assets. Their queue system is only meant for the current page. However, since the page template technique involves technically loading two pages, this confuses WordPress.

I've addressed this by reversing the order of how I am juggling the template buffering. I'm now loading the current theme's page template first, followed by the login header. This fixes the jQuery problem that Boone mentioned in the main ticket description. The second fix to allow late enqueueing involves bringing back WP's footer script rendering function into the login page.

Once I did those two things, I enqueued the password reset scripts that WP uses as well as added some inline CSS to make it all look good. See attached screenshot.

Here are the list of changes: https://github.com/cuny-academic-commons/cac/compare/115e542...5789789

Boone, one other thing to note is the admin bar assets were being included again due to the reverse buffering order, so I removed those assets manually. I don't believe we ever had a discussion on whether we wanted the admin bar to be rendered on the login page. If we want to do that, let's open a new ticket to discuss that.