Change History (62)

I'd like to tackle this task if no core devs intend to take over yet? It's been a while since I last contributed something to core.

A question though, this infinite scroll enhancement can only be applied to the theme search screen right? Other screens such as Featured, Newest or Recently Updated don't have pagination, so I doubt wordpress.org has API for those screens.

Infinite scroll on the themes screen has already been implemented on wordpress.com, so it may just be a matter of asking for their code and touching it up for core, rather than starting from scratch. Ask Koopersmith for details.

Infinite scroll on the themes screen has already been implemented on wordpress.com, so it may just be a matter of asking for their code and touching it up for core, rather than starting from scratch. Ask Koopersmith for details.

Have a tentative plan on how to implement if it does need to be from scratch, but will touch-base with Koopersmith to find out if that's an option, since it'd certainly speed things up.

Several UX things I usually encounter with infinite scrolling in other web sites / apps:

As the list infinitely expands, the user scrolls farther away from the top. There should be some way for the user to quickly scroll to top to navigate to other pages, or refine their search criteria.

Let's say the user navigates away from the page. If the user decides to go back by clicking the browser's "Back" button, they should be presented with the previous theme browsing state, rather than with page 1.

Some sort of indication of the range of items being displayed versus the total number of items should be presented to the user as the next page is preloaded and displayed (e.g. 120 - 145 of 20000 total).

Don't know if all of these should apply to this case, but could be some idea to consider.

Ported wp-includes/js/wplink.dev.js, which handles infinite scrolling for internal linking to wp-themes.dev.js for use in the Themes page.

Some things that are weird/known quirks:

There aren't any UI elements (i.e. spinners) to show that we're loading, but there are hooks in place to do this once the elements exist.

Labels are not modified based on "how many" we've loaded or how many are left. This means the paging always looks the same.

As soon as you've loaded all themes, it just doesn't load anymore. This is easy to hook into whatever we want to do when we're out of items.

For now at least, most of parseQuery was copied from tb_parseQuery (thickbox.js) into our JS for now, since making the change to thickbox.js would change how the thickbox handles query strings (whether more correct or not).

The parsing of the features[] query array is a bit hackish, in part due to how themes varies on how it includes it in the query string. Suggestions for better methods of parsing are welcome.

Yes, there is still some debug code, because it's a work in progress. This will be removed before final, of course, is marked FIXME, and should be obvious.

In another case of "let's do it because it looks cool", there doesn't seem to be any UX rationale for this change posted anywhere.

The original idea seems to come from wordpress.com, which implemented infinite scroll on the themes screen. Ironically, it has now dropped this approach, in favor of simply listing all the existing themes on a single page.

One can argue that with infinite scroll, you can see more themes quicker. However, this can be addressed by increasing the number of themes listed per page: #19469

[8:12pm] Jane__: scribu: it was discussed at core team meetup[[BR]]
[8:12pm] scribu: ok, that doesn't really help[[BR]]
[8:12pm] scribu: it should be in trac or on wpdevel[[BR]]
[8:12pm] Jane__: no, it doesn't[[BR]]
[8:12pm] Jane__: yes, it should[[BR]]
[8:12pm] Jane__: if i wasn't working 2.5 jobs for the salary of one, i would surely have finished collating and posting notes by now[[BR]]
[8:13pm] scribu: can't you get Matt to clone you or something? [[BR]]
[8:13pm] Jane__: but this is going to be one of those things where it's a "the majority of leads wanted it"[[BR]]
[8:13pm] Jane__: personally, i hate infinite scroll[[BR]]
[8:14pm] Jane__: URLS4EVA[[BR]]
[8:14pm] scribu: I thought you were the UX lead[[BR]]
[8:14pm] Jane__: yes, but we make decisions as a team[[BR]]
[8:14pm] Jane__: and my hatred is personal, not objective[[BR]]
[8:14pm] Jane__: which is why i agreed to it on the themes screen only[[BR]]
[8:15pm] Jane__: where we could see how it did on a screen where it seemed likely to improve the experience rather than potentially degrade it[[BR]]
[8:15pm] scribu: *sigh*[[BR]]
[8:15pm] helenyhou: Jane__: you are in my head. or i am in yours, whichever way.[[BR]]
[8:15pm] Jane__: we've been talking about it in dev chats for almost two months now[[BR]]
[8:15pm] Jane__: no one raised objections[[BR]]
[8:16pm] helenyhou: i think once all of the details are hidden by default and the grid is more even, it will look much better[[BR]]
[8:16pm] scribu: well, thanks anyway for responding, Jane__[[BR]]
[8:16pm] Jane__: sure

The last item in the original list is duplicated at the beginning of the first scroll fetch. This seems to happen only when using the feature filter and is true even when js is off. I suspect this has always been broken. Given that paging of search results is broken in 3.3, it is hard to tell. Regardless, not a blocker to landing .5.diff.

In 19815.8.diff​, the throttle still doesn't work properly. To test this, simply add console.log('maybeLoad!'); at the beginning of the maybeLoad function. You'll see that it's called every single time the scroll event is triggered. Function call is expensive.

Added 19815.10.2.diff​: Includes changes from 19815.10.diff​ plus fixed paging cases where paging starts at > 1, got rid of extra AJAX call for single page situations and end-of-content, renamed maybeLoad to ajax, and polling setInterval now clears when at end of content.

Output themes and theme-install infinite scrolling args in JS, rather than parsing query strings. props DH-Shredder, helenyhou. Make WP_Theme_Install_List_Table extend WP_Themes_List_Table. Doesn't help much yet, but we should be able to dry things up further. see #19815.

Allow WP_List_Table::_js_vars() to take an array of additional args to add. Allows us to have a single variable printing data when child classes need more data. Also, fix compact() call in [20094]. see #19815.