When loading the Reader using a hash corresponding to an item that doesn't appear in the displayed list of items, the JS application can't fully initialize. More specifically:
- Load /wp-admin/admin.php?page=pf-menu&pc=1#modal-4393b94dda497e63a0b0d62f2b488d24, where
4393b94dda497e63a0b0d62f2b488d24 is the hash of an item that appears on page 2+.
- You'll see the following stack trace in the browser console: https://gist.github.com/boonebgorges/2b14518de700ad5f48a81c8b605ea4d4
When bisecting back to before the Bootstrap 5 update, the behavior changes somewhat: you don't see an error, but the modal doesn't load. So this is a problem that's likely existed since the introduction of the Reader.
I assume the issue is that the item's markup doesn't appear in the DOM, which means that the modal can't be initialized. A "proper" fix might involve building the modals in such a way that we don't need to have the markup in the DOM on the pageload. But this is not only a big technical change, but we then have to ask how the user will be dropped into pagination/infiniteScroll in that situation. (Should they be dropped onto page 15/100 if that's where the item appears? If infiniteScroll, should they see the first 15*20 items?)
In the short term, I think we could redirect away from the hash when the corresponding element isn't found on the page, which will at least prevent the JS application from seizing up.
When loading the Reader using a hash corresponding to an item that doesn't appear in the displayed list of items, the JS application can't fully initialize. More specifically:
4393b94dda497e63a0b0d62f2b488d24is the hash of an item that appears on page 2+.When bisecting back to before the Bootstrap 5 update, the behavior changes somewhat: you don't see an error, but the modal doesn't load. So this is a problem that's likely existed since the introduction of the Reader.
I assume the issue is that the item's markup doesn't appear in the DOM, which means that the modal can't be initialized. A "proper" fix might involve building the modals in such a way that we don't need to have the markup in the DOM on the pageload. But this is not only a big technical change, but we then have to ask how the user will be dropped into pagination/infiniteScroll in that situation. (Should they be dropped onto page 15/100 if that's where the item appears? If infiniteScroll, should they see the first 15*20 items?)
In the short term, I think we could redirect away from the hash when the corresponding element isn't found on the page, which will at least prevent the JS application from seizing up.