PressForward is a free plugin that provides an editorial workflow for content aggregation and curation within the WordPress dashboard. It is designed for bloggers and editorial teams who wish to collect, discuss, and share content from a variety of sources on the open web.
GNU Affero General Public License v3.0
120
stars
22
forks
source link
Error when loading Reader on hash corresponding to off-screen item #1153
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+.
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.
boonebgorges
commented
3 months ago
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.