Font selection and subset removal very slow

Hi Gal,

Thanks for the feedback. And you read my mind! Yesterday and today I’ve been working on this. There’s just one last thing I need to sort out, and then it’s ready for release.

I’ll keep you posted ??

• This reply was modified 5 years ago by DaanvandenBergh.

Hi Gal,

Hope you like the UI improvements I made! ??

In v3.3.0 I introduced a queueing system. You basically select which subsets you want to search, which fonts you want to add to preload or which fonts you want to remove from the queue. After making a selection, you simply click the ‘Apply’ button that pops up and it’ll be processed all at once.

Hi Daan,

Much better, but…

• When checking/unchecking a font subset, the button appears with a blue background and no symbol inside it (the styling for .dashicons-search:before seems to be missing)
• When a search is executed, it updates the entire list, not just what changed, which means that I now have to delete every font style that’s available, but was deleted before. To prevent this, perhaps change the removal function into an “ignore” or “skip” checkbox, and don’t download styles with this box checked, but remember the selection on subsequent subset searches. Also, you can run the search only on subset checkboxes that have changed.
• When I make both “preload” and “remove” selections on font styles and click to apply under “preload”, the page reloads without applying my removals
• When clicking to apply under “remove”, preload changes are not saved either
• The WordPress plugin convention for admin sub-pages seems to be styled as tabs. The current styling doesn’t stand out enough, so the advanced settings may go unnoticed

Hi again, Gal,

Appreciate all your feedback!

• I don’t know what to make of this. Might be a caching issue on your side? It’s definitely in the CSS and works on all my sites.
• You’re right that a search updates the entire font list. That’s intentional. You’re saying you would want OMGF to filter out fonts you’ve already removed? This would mean you could only start over by emptying the entire directory. Hmmm… I’ll think about it. If anyone else would like to chime in on this, please do!
• There was a bug in the preload section, involving browser cache. Browsers try to remember form values upon page reload. Since OMGF is dynamically adjusting a form, the browser would continuously ‘remember’ the wrong checked boxes. This bug is fixed in v3.3.1.
• In v3.3.1 I changed the separate apply buttons to one apply button, which handles the entire queue for removal and preload. There’s a bug somewhere, causing it not to work when sticky. But just scroll to the bottom of the list and it’ll work.
• I can’t believe I missed this! v3.3.1 complies with the WordPress conventions and you’re right, it looks much cleaner.

Let me know what you think! ??

• This reply was modified 4 years, 12 months ago by DaanvandenBergh.

Hi Daan,

Looks like the .dashicons-search:before issue is due to a conflict with Advanced Admin Search. I have reported it there.

To reset font style removal selections without clearing the directory, you could just provide a button for this.

Going in another direction, despite showing the search button only when font subset selection changes, when running the search, unchanged subsets are also reloaded. If you only reload the subsets that were added or remove ones that were removed, there will be no reason to remember removals of font styles.

3.3.1 is a great improvement, and I appreciate you being so responsive!

Cheers,
Gal

Quick followup.

Going in another direction, despite showing the search button only when font subset selection changes, when running the search, unchanged subsets are also reloaded. If you only reload the subsets that were added or remove ones that were removed, there will be no reason to remember removals of font styles.

I’m still thinking about this, Gal. Would definitely be a great improvement, but it has to implemented in a way that it doesn’t impairs other UX scenario’s.

I’ll wait (imagine me drumming my fingers on the desk ?? )

Hi Gal,

Today I’ve been testing around with this scenario, but I came to the conclusion that it simply can’t be implemented.

There’s no (efficient) way of detecting which fonts have been added by search and which have been added by auto detect. And even if I implemented that, there would still be the scenario that you’d want to run a search to overwrite one of the fonts added by auto detect. I can’t detect that either.

So, I’m sorry, but this will not be added as a feature. I’ll keep it in mind, if I ever think of a good way to implement it, but don’t count on it.

Can you use transients, and separate auto-detect transients from manual-search ones?

Hmmm… Maybe? I’ll circle back to this soon. I’ll keep you posted.