Bug #11997
closedDomain mapping not working for CETLS site
0%
Description
Domain mapping no longer appears to be working for the CETLS site and I’m not sure if the problem is on our end or with the Commons. I cannot access the CETLS site unless I am logged in to the Commons. When I try accessing the CETLS site (http://cetls.bmcc.cuny.edu) when not logged in to the Commons, I get this error message: https://screencast.com/t/FOPnNJSv3K9. When I am logged into the Commons and attempt to access it, I get redirected back to https://bmcccetls.commons.gc.cuny.edu/. Until now, http://cetls.bmcc.cuny.edu would remain in the address bar.
Any light you can shed on this would be greatly appreciated!
Note: I also emailed Boone directly about this issue.
Files
Updated by Boone Gorges about 5 years ago
- Assignee set to Raymond Hoh
Ray, I've begun looking at this but I have a limited understanding of how mapping is intended to work. I can see that the redirect_canonical() function is incorrectly flagging that cetls.bmcc.cuny.edu be redirected to bmcccetls.commons, but I haven't figured out how or why yet. I'll continue to look, but if you can, I'd like you to jump in to see if you can identify what's happening.
Updated by Boone Gorges about 5 years ago
On a lark, I flushed the object cache, and the redirect behavior corrected itself.
This, along with backtrack info I collected, suggests strongly to me that:
- A call to `home_url()` in `redirect_canonical()` was incorrectly returning bmcccetls.commons instead of the mapped domain, which was triggering the redirect
- `home_url()` was returning the wrong value because the `domain_mapping_siteurl()` filter callback was not working properly
- This was probably caused by domain_mapping_get_data_by_id() incorrectly returning a null result for the blog ID
- Since this was fixed by a cache flush (and everything looks OK in the database tables) it means that a null result for the blog ID must have been incorrectly stored in the cache.
If this reasoning is correct, the questions are (a) why did a bad value get cached, and (b) are there techniques we can put into place to mitigate this sort of problem in the future? Even if it means not caching null values (ie forcing a database hit for non-mapped domains)? Ray, any thoughts you have would be welcome.
Updated by Gina Cherry about 5 years ago
Thanks so much for the very quick response! Thankfully, I can now send out the weekly CETLS newsletter with links to our blog and events.
Updated by Raymond Hoh about 5 years ago
Boone, can you pass me the backtrace log if you still have it?
If not, no problem. I'll take a closer look.
Updated by Boone Gorges about 5 years ago
- File 11997-backtrace.txt 11997-backtrace.txt added
Sure thing, Ray. See attached for a relevant backtrace of the redirect_canonical call.
Updated by Raymond Hoh about 5 years ago
- Category name set to Domain Mapping
- Status changed from New to Staged for Production Release
- Target version set to 1.15.13
If this reasoning is correct, the questions are (a) why did a bad value get cached, and (b) are there techniques we can put into place to mitigate this sort of problem in the future? Even if it means not caching null values (ie forcing a database hit for non-mapped domains)? Ray, any thoughts you have would be welcome.
Boone, your reasoning is correct. I've attempted to fix this in the following changeset:
https://github.com/cuny-academic-commons/cac/commit/62372e10b9d3d5704f00037724f2064a0415ef65
For (a), this was an oversight on my end. Previously, I cached invalid DB results from domain_mapping_get_data_by_id() as null to prevent checking the DB again for the same data:
https://github.com/cuny-academic-commons/cac/blob/0c1c5eb4a0d957cbb9af5c4dc4c6e2a10ab51705/wp-content/plugins/wordpress-mu-domain-mapping/domain_mapping.php#L604
However, if there is a null result, that means there was a problem connecting to the DB in the first place. Based on your stacktrace, you're correct that the home_url() would return the subdomain instead of the mapped domain URL.
For (b), I've made it so that we only cache valid results in the in the domain_mapping_get_data_by_id() function. Next, if there is a null value returned by the function, we try to return what is expected by comparing the current server's "HTTP_HOST" value. I tested this out locally and this appears to alleviate the infinite redirect loop. It's not entirely accurate, but this should help until the DB is able to return a proper result.
Let me know what you think.
Updated by Boone Gorges about 5 years ago
Thanks for the careful thinking about this, Ray. Knowing that a null result corresponds to a DB connection error is helpful. I'm happy to go ahead with your fix. Do you think this warrants a hotfix? It's a severe problem but it appears to be extremely rare.
Updated by Raymond Hoh about 5 years ago
It's a good thing I didn't push the update as a hotfix because I found a bug that caused a redirect loop in the admin area as a result of the previous change:
https://github.com/cuny-academic-commons/cac/commit/eaaa6af50fa399026fa8c9cc12c7a2a96ec937e6
I think that because the redirect loop is a rare occurrence, we can hold off until the next maintenance release.
Updated by Gina Cherry about 5 years ago
That's funny - I was going to report that, but when I went in today to make sure I had the details correct, it was no longer happening. I guess that's because you fixed it!
Updated by Boone Gorges almost 5 years ago
- Status changed from Staged for Production Release to Resolved