How to Change Default Font Site/Themewide in Upfront/ChildTheme

Hi

Is there a simple way to change the front used across the whole of my Upfront theme?

The default font of Quattrocento in Luke and Sara is very nice but not what I want to show as default everywhere. I've uploaded Open Sans with Theme Fonts Manager without problem but every time a new thing comes up that still contains the old font I'm having to go through each and every heading, button, hover/focus state, etc. (for all responsive views!!!), and adjust to my chosen font.

I've done it so many times now that it gets boring and I'm sure there are a still a few instances where the old font is still set as default but until it comes up I'll never know. For instance I came across the "Contact" Draggable Element yesterday that still had Quattrocento.

The other day I thought I was being clever by copying the Global Theme CSS (from within Upfront) in its entirety and doing a find/replace on the old font (and weight) and replacing with what I wanted and then pasting it back into Upfront editor. That didn't do it and there weren't that many references anyway.

I also did the same in one or two of the other css areas that can be found in the disparate areas of Upfront where CSS can be found/set, but likewise, not much help or difference.

I'm not sure if I should not have done what I did but everything still seems to work.

There's got to be an easier way of doing this in Upfront but I can't find it? Just point me to the CSS file(s) or the setting in Upfront so that I can blanket change the font and delete the old font from Theme Fonts Manager which I'm sure must also be adding to overall page load if anything.

Even if I have to repeat my default font change every time Upfront is updated, it's got to be much easier than going through each element, each button, each heading and whatever else there is to change on each site.... it's also going to be a lot more reliable that occasionally getting the wrong font where I don't want it and then I can finally delete that Quattrocento from my Upfront site.

  • Adam Czajczyk

    Hello MrArtist,

    I hope you're well today and thank you for your question!

    Currently, editing css files won't help much here as Upfront stores layout data in database, meaning that the pre-configure layouts and layouts created by you won't change anyway. This is a bit more complex and there are two things that can be done here.

    1. First take care of typography settings by setting all fonts and their parameters in Upfront panel (on the left) in "Theme Settings -> Typography" tab.

    This should take effect but there's also such thing as "presets" and these are like "settings for parts of layouts" that has to be setup separately.

    2. For an element that you've added to a site, go to "Settings" (gray "gear" icon) and then
    - expand the drop-down box under the "Chose or Create Preset" label
    - type a unique and easy to identify name there and click on add
    - a new preset will be created so set your typography settings there and save

    If you completed step 2 for, let's say, "Text" type element, you'll be able to select that preset (re-use) it for all other "Text" type elements on your site. Therefore you will need to do this only once and will be able to re-use it in future.

    This is because "starter themes" (Upront child themes) are not "blank canvases" but actually a designed themes. Our developers are looking into releasing both "blank" theme and a "them builder" tool in future and this would help here much as it would simply allow you to create your own theme from scratch.

    Best regards,
    Adam

  • MrArtist

    Hi Adam
    Thanks for the quick reply.

    Your suggestions for 1 & 2 are pretty much how I've been doing it (but it seemed so crazy that I assumed there must be an easier more sensible way), but like I said, there are lots of variables and it takes a long time to go through each one and there are still things that I haven't come across yet and don't/won't get changed - e.g. like yesterday when I used the "Contact" element form for the first time.

    All the time I have to keep the old font in the site so that at least I can spot if it's still used (a default substituted font won't easily show up versus Open Sans if I delete the seriffed Quattrocento)

    You say it's because the Upfront starter themes are not blank canvases, then one has to ask why have all the options to change fonts at all? Well, it obvious of course, but so is being able to change a default font at a small few simple starter point rather then a million end points.

    It's such a shame this is not possible to do in Upfront even after all this development - There's so much other typographical ability within Upfront already (but not paragraph spacing is noticeably missing!).

    Changing the base typeface of anything is such a basic principle that even MS Word can do it, let alone just about all other CMS based design tools/processes.... It' like me doing some desktop publishing using a template but for each new text block or page I create I have to keep changing the font rather than set on overall global style.

    Looking forward to when it's added to Upfront, but from what you say it sounds more like it'll just be part of a blank/default theme builder rather than adjust existing themes easily. Oh well, back to the difficult way an I'd just better get used to it.

    Thanks.

  • Adam Czajczyk

    Hello MrArtist!

    I think I should add up to my previous post here. Actually, the "Theme Settings -> Typography" panel should affect most of the elements "overall" but this works best when you set that up on a "fresh" install where all the existing elements are using "default" presets. Granted, there still may be parts where adjusting preset's settings would be necessary but if an element is using a "default" present than it should follow general settings.

    The "blank" theme should actually help a lot here because if you setup typography options upfront, those will affect your entire design and you'll be building upon that. Then depending on what settings will you apply to a preset the particular element would pick up those "general" settings or use "hard-set" typography.

    We're aiming to make Upfront better and better and I think it's getting more handy and easier to use with each update. I agree that it requires changing some established "usage habits" but after spending some time with it turns out pretty handy and convenient in my opinion

    Having said that, I appreciate your feedback on this and also we're often discussing various aspects of our themes/plugins, including e.g. usability, with developers and we then pass insights from the members of our community to them

    Best regards,
    Adam

  • MrArtist

    Hi Adam
    I do understand that things are still evolving for Upfront, and as a more traditional DTP/Graphic designer I'm enjoying the more intuitive visual way of laying things out. I've been waiting for something like Upfront for a very long time.

    Interesting you saying that maybe I should set things up with the font at the beginning. This install was still fairly fresh when I decided what font I wanted, but still, even for each heading/styles and each responsive view's headings/styles I had to manually configure each one, they did not carry through to other areas.

    I finished my site last night after doing a mammoth 26 hours stint on it using Upfront and I'm pleased to say that (since finding a good hosting solution) that not once did I have a sluggish moment, failure or crash of Upfront, it all worked very well.

    A few times I got worried things might get lost or corrupted on a page as I moved things around. Once or twice changes failed to take or save as I left them and I had to do them again, but overall things worked well. However, with the reliance on the database to store most things (and the size it gets to, currently 270MB and counting), I do fear for that moment when it all goes wrong and nothing can be retrieved.

    On reviewing all the pages in each of the responsive modes I still noticed the odd wrong (old/original) font being used, so I had to go back in and change them mostly in missed narrow view locations.

    The one thing I really missed having was the ability to save a version of my page as like a backup or clone just in case I needed to revert at any point. I also found it tricky copying a page or parts of a page. I partially got the hang of using global areas for things like that but it is quite confusing to do and keep track of without any sort of visual preview, library or other some such method of keeping track of assets.

    When thinking about Upfront in terms of being a CMS solution capable of handling loads of pages quickly, I suppose with some well defined layouts it would be possible. But I find I'm doing the actual layouts on a page by page basis, customising each depending on content and purpose. For that, Upfront does work, but it is still quite intensive work, but once done it's really nice for quick edits and all those tiny pixel perfect positioning necessities.

    I'm still a bit concerned by some reported Pingdom page load times with what looks like prolonged ajax database calls on behalf of Upfront, but on the whole the actual page viewing times don't seem too bad and I haven't even tried the new Upfront optimisations yet, nor indeed any form of caching or CDN possibilities, so these may make things snappier.

    Does anyone have any idea why Upfront ajax calls to the server seem to take a few seconds for the server to respond? - Is it because it has to search that huge database that builds up with Upfront?

  • Predrag Dubajic

    Hi MrArtist,

    Thanks a lot for taking your time to share your thoughts and worries about Upfront, it really helps us getting the product better for both you and other users.
    We are aware of some things missing from current version, that would really benefit users, and we have to-do list for improvements and features yet to be included

    About the ajax and database issue, the ajax load time could be related due to large database however I'm not sure how it's even that huge on your site, on my test site with quite some changes the wp_options table is around 8MB, can you tell me which is the largest table in your DB?

    Best regards,
    Predrag

  • MrArtist

    Hi Predrag

    Regarding the large database sizes that Upfront causes, I detailed this issue in a ticket back in March:
    https://premium.wpmudev.org/forums/topic/new-install-of-upfront-posts-table-growing-to-60mb
    See my discovery and findings from about half way down.

    From what I discovered back then it is due to Upfront storing all of it's undo actions in coded form in the posts table. My current posts table details are as follows:

    table: posts
    Records: 356
    Data Size: 265.8 MB
    Index Size: 136.0 KB
    Type: MyISAM
    Overhead: 235.9 MB

    Please note, this is for a new site started only last week, on a new better server, using the latest version of Upfront from the start and with just a few pages created and not lots of weird plugins. I have of course made quite a few revisions and changes as I build each page, and this (it seems) is what makes the database grow to excessive sizes due to the undo buffer which doesn't clear when exiting a page from Upfront or indeed when quitting Upfront itself.

    Other main plugins installed: MarketPress, iThemes Security, BackupBuddy, WP-Media Folder and a few other basic things.

    Having a database this size causes big issues for backup, I currently have to ensure enough resources are allowed to process the file. Even though when zipped it only occupies a fraction of that size, for some reason the whole process fails if I don't allocate enough memory to initially grab the db.

    Back when I first reported the growing database issue, I discovered there is a Cron job to clear the undo buffer and is set to run every hour, but would only ever actually delete anything from that table after 24 hours. Strangely, on this newly installed site, (and also on new better hosting since back then) this is now not clearing after 24 hours and the db is remaining at a high size. - I wonder if it only clears if I haven't actually made any changes on the site at all for 24 hours?

    On checking the cron settings on this new site via Advanced Cron Manager I see the upfront_hourly_schedule is definitely set to run every hour as it should, but as I say, it doesn't seem to be doing its job at the moment.

    From my tests back in March, optimising the database or running the cron job manually doesn't make any difference.

    In case you want to investigate my site, I have just granted WPMUDEV access.

    It would be good to establish why this db table grows so large and what can be done to manually clear it when I no longer have any need for it's stored undo buffers (if that's what they really are).

    Many thanks.

  • Predrag Dubajic

    Hi MrArtist,

    Had a chat with UF devs about this and as explained in your previous thread what happens is UF stores revisions in DB and that increases its size, it should be cleared after around a day if no changes are made to post/page.

    Since you reported that this doesn't happen for you even though you made changes on different posts can you try making no changes at all for one day so we can see if on your installation changes are cleared only in that case?

    Best regards,
    Predrag

  • MrArtist

    Hi Predrag

    Unfortunately the database has not reduced after more than 48 hours on not working on any pages in Upfront. Total DB size is 272MB most of which is the Posts table.

    The Upfront cron job has been running hourly (and a manual one just tried), the site visited and a couple of non-Upfront things done in Admin/Dashboard after about 36 hours of not touching or being logged into the site. just the occasional front-end visit to see if that would spark the cron.

    I tried a short while ago making a tiny edit on one of the pages using Upfront to see if that might spark a clearance of the db but nothing so far. Also deleted a few test pages/posts I had in 'bin'. Nothing much in the way of other content in the site, just about four main pages with a few pictures and three or four linked Wistia videos.

    It's not looking good. Why is Upfront making the db's so large and failing to clear when nothing in its undo buffer is needed?

    Have just extended site access should you need.

    Hope someone can help cure the database size problem.

    Many thanks

  • MrArtist

    Any reports back yet on this from devs?

    Database still at approx 271MB, cron is not clearing the undo data.

    I'd like to know if this is fixable before I do any more work on the site - or if I will have to rebuild!

    As mentioned before, it should be a fairly simple site with a low db size. It only has a few pages and posts. MarketPress is also installed with two simple products. I can't carry on working with the site until this is resolved

    Have just reactivated site Support Access again should you need.

    Many thanks.

  • Adam Czajczyk

    Hello MrArtist,

    I hope you're well today!

    In your site's dashboard there's an "Upfront -> General" page that includes "Reset Upfront cache" tool. Have you tried that already? If no, could you please give it a try and compare the db size before and after?

    All my test sites produce extremely small database in comparison and I'm not able to spot the difference there that would be big enough to prove whether this helps or not. This shouldn't affect site's layout at all so could you please give it a try and let me know about the result?

    Best regards,
    Adam

  • MrArtist

    Hi Adam

    I just tried running that Reset Upfront Cache option and it made no difference. Tried it again, still no change, tried manually running the Upfront cron... no change.

    The comment for that reset option indicates it's helpful after core upgrades - however, this install of Upfront was not upgraded to need that, it was a clean install of WP with Upfront V1.2.2 from the beginning, no other frameworks or themes used. The only thing I've done is use Open Sans instead of the Luke & Sara default font. I spent a while editing two main pages at various times over a few days, MarketPress CSS tweaked and a few posts created. I have not run/installed anything strange or had any odd crashes. Could iThemes Security be blocking something or causing Upfront to bloat the Pages table?

    The increasingly large database issue happened to me on other sites on another hosting companies server, the only difference is that database would clear after 24+ hours. Could my current site/server have some sort of internal clock whose date is different from what Upfront cron is looking for when it's time to clear after 24 hours?

    Are you also implying that your databases never get large/larger when doing edits and saves on your Upfront installs? Even for the first 24 hours?

  • Adam Czajczyk

    Hello MrArtist!

    Thanks for letting me know about the result of clearing Upfront cache. I realize that it says that's mostly useful after core upgrades but it was worth checking anyway.

    Are you also implying that your databases never get large/larger when doing edits and saves on your Upfront installs? Even for the first 24 hours?

    It does grow but I make so many changes on my test sites on daily basis that it would be impossible to track whether that's caused by Upfront or not. I will however observe this on one of my sites for some time to check what's happening there.

    The increasingly large database issue happened to me on other sites on another hosting companies server, the only difference is that database would clear after 24+ hours. Could my current site/server have some sort of internal clock whose date is different from what Upfront cron is looking for when it's time to clear after 24 hours?

    This actually is a clue, I think. It suggests that maybe the Cron task is not fired properly or it is but, as you said, the task is fired but it's not clearing the database after all.

    That said, you mentioned that you checked the site against Cron tasks. I took another look at it and it also looks to me like those were being fired as expected. I'm wondering if it would be possible that you made full "1:1" copy of your current site (since this one is "live") on the same server (e.g. in sub-folder) including current database. It would make a perfect staging site that I could then study if you would provide me with full access credentials. Would that be possible? Let me know please and I'll provide you with a way to securely provide me with access data if so.

    Best regards,
    Adam

  • MrArtist

    I can set up a duplicate but I'm not sure of the best way to replicate due to potential issues I previously had trying to stage/migrate/deploy.

    In my earlier site developments a couple of months ago, I had (possible/unconfirmed) big problems with Upfront staging/migration/deployment by either DesktopServer and/or BackupBuddy where not all of Upfront's site URLs would get updated due to oddities in the way Upfront's database encoding was not being able to be read by the migration tools for conversions - see ticket: https://premium.wpmudev.org/forums/topic/upfront-are-page-links-encoded-and-cant-be-migrated-big-problem

    It's possible that problem was due to one or more issues with either using DesktopServer on a Windows local dev environment, or something BackupBuddy didn't like, or possibly Upfront actually encoding the URLs in an awkward way. I never found the real solution or cause and had to abandon that site install completely, which is what I'm trying to avoid with this current database issue.

    That said, what would be your preferred way to duplicate the site?

    Is there some way I can check if cron is doing it's job or being prevented? Might the new server hosting I'm using have a some limitation on cron jobs? (it is a shared server and otherwise seems fast and liberal on what's allowed).

  • MrArtist

    Hi

    Just reporting back here with how I just managed to reduce the database size from 271MB to 4 MB.

    At first I thought it was a cron problem on my new hosting, but after many hours of testing and research that wasn't it.

    What I did realise this morning was that in the WP-Optmize plugin (database optimizer) it was showing a load of unused space being occupied in the posts table left over from whatever Upfront had been using for its temporary store. Somehow, this space was not being released back to reduce the db size, hence it still growing rather than reducing after the 24 hours that Upfront keeps hold of its undo data.

    I'm not sure if that space was being used by the 53 unrequired WP revisions that were showing in WP-Optimize or the 142 transient options, nonetheless, after running WP-Optimize the db size reduced and after about half an hour the change finally showed in cPanel as well (surprising that cPanel didn't show the result immediately - so it seems cPanel can't be trusted to show results straight away!).

    On my previous hosting when I had a similar issue with the large Upfront DB, I had tried WP-Optimizer but it didn't do anything back then because I didn't realise Upfront took 24 hours to clear its brain, and in any case the cron to clear it DID work, so I forgot about the WP-Optimize possibility which one other user had success with in another ticket.

    This hunt for the solution to clear the excessive db size came from me asking why the Upfront admin-ajax call seems to take so long. My db size being put forward as a possible cause.

    Now that I have eliminated the large db problem I have just run a tools.pingdom.com test again and while the timings might be slightly faster, they still represent a significant chunk of the page load times as follows:

    2.43 seconds
    http://mysite.com/wp-admin/admin-ajax.php?action=upfront_load_grid&ver=1.1.1

    2.79 seconds
    http://mysite.com/wp-admin/admin-ajax.php?action=upfront_load_styles&layout%5Bitem%5D=archive-home&layout%5Btype%5D=archive&ver=1.1.1

    2.08 seconds
    http://mysite.com/upfront-dependencies/styles/2040ab64c1d0af6940910182a34ce415?ver=1.1.1

    2.56 seconds
    http://mysite.com/upfront-dependencies/scripts/a77a91a41a73d0d402c34862aa69bdb7?ver=1.1.1

    So my initial question in relation to the Upfront admin-ajax calls still stands: Does anyone have any idea why Upfront ajax calls to the server seem to take a few seconds for the server to respond? - This seems to be a common problem. I experienced it on my previous hosting which did prove to be an inefficient host. My new host is much better on fast SSDs but these admin-ajax calls do still take some waiting time before the result gets delivered, and I have read of others also noticing these long wait times.

    Any thoughts?

    Many thanks for your help and time.

  • Milan

    Hello MrArtist

    Hope you are well today

    So my initial question in relation to the Upfront admin-ajax calls still stands: Does anyone have any idea why Upfront ajax calls to the server seem to take a few seconds for the server to respond? - This seems to be a common problem. I experienced it on my previous hosting which did prove to be an inefficient host. My new host is much better on fast SSDs but these admin-ajax calls do still take some waiting time before the result gets delivered, and I have read of others also noticing these long wait times.

    To throw some lights on this, I've pinged our Upfront developer. Hopefully they will explain you better for this. Please wait for some time. One of developer from Upfront Dev team will respond you here soon.

    One quick note here is that, sometimes due to criticality of issues and bug, our dev team gets delayed so if that happens in this case and you don't get response soon, please wait bit more. I am sure its worthy.

    Cheers,
    Milan

  • Vladislav

    Hello,

    The reason those requests take some time to respond back is because the data that they're fetching is, by default, dynamic and created on the fly for your particular layouts. Now, this is the default behavior, which is handy for when the editor is being actively used to make changes to your site. However, this data is also cached, so once you're happy with your changes and don't intend to be changing the layouts anymore for a while, dropping all the debugging levels and turning on optimization should be starting to make use of the cached data instead, which should eventually speed up the request response times.

  • MrArtist

    Thanks for the response. I hadn't tried any of the optimisation features yet so on the news above that they might help I just tried them, a bit of time was saved on the admin-ajax calls but the major problem is that the slideshow header image of the home page goes wrong.

    For the first option of "On", the images enlarge and become pixelated. For the second option of "Aggressive", the images most often fail to show unless I resize the browser window. (Tries in Chrome and Opera).

    I tried both those options with and without the last gzip option and it didn't seem to make any visible difference.

    So, sadly, the optimisation features I'd been looking forward to trying don't seem to offer any benefit and just make things worse in terms of visibility.

    Any thought on why the slideshow fails to show properly?

  • Vladislav

    Heya!

    I'm sorry to hear that this didn't solve the situation. I'm not sure what the issue might have been with the images and the slider in combination with the optimization options - I have tried to recreate in on my setups, but haven't had much luck this far. I am assuming you have tried visiting the pages in incognito mode and/or after a hard reload and browser cache clear - if not, could you please give one of those options a quick try? Anyways, we will stay with it, as that's something we most definitely want to have fixed and working properly.

    A note, the optimization levels might fail on different setups (hence them not being all on by default), so this could have been one of such cases. On the other hand, cache freezing I was mentioning in my previous response shouldn't be problematic on its own - once the editing is done, of course. So, perhaps it would make sense to decouple the cache freezing from other optimization options in one of the future versions.

  • MrArtist

    Hi Vladislav

    Yes I tried in various incognito/cache disabled modes. Interestingly in Chrome on Windows I noticed if I disable cache I could eventually start to get the "Aggressive" setting to show the image properly but it would revert to not showing when cache was enabled. In "On" mode, I was still getting the zoomed-in pixellated look which I realised reverts to proper look when I resize the browser width.

    Some further testing on Win 7 and Mac revealed that this happens in Chrome, Opera and Vivaldi. In Firefox the view is okay.

    After a while of testing and re-saving the slider images and using "Reset Upfront Cache" I started to more regularly (but slowly) start to see the image in Aggressive mode (with or without GZip compression) however, as I say it's slow in the header image reveal. First I see number 01234 (depending on the number of images in the slider) appear on the left, then I see the image appear going off the left edge and then finally it reveals fully centred in the header. This happens on three different computers (and also not in Edge on Win 10 as well as Firefox).

    Also I noticed for a while a loss of font specification and it took a moment or so to use the right font on all the text in headers and the menus, reverting to what looked like Times for the menu and Aerial for the headers (from Open Sans).

    So, I'm not convinced this is actually helping the display of the page be any faster, it feels more sluggish but tools.pingdon.com did show faster times.

    All very strange.

    I'll open the site to access if you want to quickly review those settings and see the results for yourself. The site's not really in use yet so some quick testing is fine for you to do and I do have backups.

    Many thanks

  • Vladislav

    Hello,

    Thank you very much for access and such a detailed report! I was able to see exactly what you mean with the slider images, and I have a decent idea what went wrong there. The reason why this happened is because the optimization bounced all non-essential resource requests further down the queue. This affected the initial slider width and the element then, in turn, used what it considered to be the appropriately sized image at the time and stretched it, causing it to look pixelated. Once the page was fully loaded (i.e. once the resources bounced back by optimization were in), I was able to get the right image to appear by just triggering the window repaint (e.g. popping the devtools console in chrome, or resizing the window). This is definitely a bug and we will be fixing this in a future release.

  • MrArtist

    Hi Vladislav

    Thanks for the reply. It's reassuring to know it's not just me and something I'm not doing right or some corruption somewhere.

    Well done for spotting the cause. Any thoughts on the wrong font momentarily showing until screen is (fully) re-drawn? I see it on my fast Windows machine and also my slower Mac - look at the top menu and headers - it maybe looks like default fonts being used (or the original theme font?) pending download or calls for the correct font (Open Sans).

    Thanks

  • MrArtist

    Hi Predrag

    So that the site looked right, I switched off the performance options yesterday. Gzip compression is still on though as that doesn't seem to affect anything.

    I have just re-enabled "Aggressive" for you to recheck. Now, in Chrome on Windows, if I use an incognito (or non cached) window I see all text styles as default fonts until redraw on load completion - a basic thicker non-serif for everything except menus which look like a serif Times.

    This seems to happen in all browsers and platforms, correcting themselves only when the page has fully loaded and has found it's full layout. I suspect it's associated with the same issues that Vladislav found with the header image - something is not quite coming together until all the loading is finished.

    I will leave the setting on for a while for you to check but may turn it off again later. Please let me know when you are done. If you find it not showing, I may have turned it off again, feel free to use the opened site access to momentarily change the setting to "On" or "Advanced" to check.

    Thanks.

  • Vladislav

    Hello,

    You're spot on, this is tightly related with optimization, but the fonts should be appearing on window fully loaded on their own, without forcing the window repaint via resize. This was, in fact, my experience with your site as well - the page did boot with system fonts, but they got swapped with the actual fonts on the fly, as they got loaded. Anyway, the reason why this is happening is the same mechanism - non-essential requests being bounced back by the optimization routine. With optimization modes turned on, the fonts are being loaded via the web font loader: https://github.com/typekit/webfontloader (https://developers.google.com/fonts/docs/webfont_loader). So, this is what's causing the FOUT you're experiencing. To remedy this but still have the benefit of async fonts loading, you can make use of the .wf-loading class that's being added to your page's root HTML element.

  • MrArtist

    Nice answer, sounds great but not sure about what to actually do?

    I've now read all about FOUT (flash of unstyled text) and what ".wf-loading" does, but "Making use of the class that's being added to your page's root HTML element" I haven't a clue about!

    Mind you, for the moment with the other display issue I identified with the header image when any optimisation is on I shan't be needing this font fix for the moment.

    Maybe I'll just wait and hope it's all fixed in a UUU (Upcoming Upfront Update!)

    Many thanks.

  • Milan

    Hello MrArtist

    Hope you are doing well today.

    Issue with Slider optimization has been fixed, just code reviewing is left and hopefully it will be included in upcoming Upfront version soon. We have taking care of cache freezing stuff too. But we are planing to make it separate context to test well. But this will not worked out soon. It will surely take some time. And for FOUT stuff, our developer's above suggestions may help you.

    Cheers,
    Milan

  • Predrag Dubajic

    Hi MrArtist,

    Apologies for the delay here about FOUT solution.

    So basically there's .wf-loading which is only there while page is loading and is removed after the page has fully loaded.

    You can make use of that class in different ways to change the behaviour before the page loads completely.

    For example, you can use some of the default web fonts that are similar to the google font you're using so it shows that before the google font is loaded, for example some CSS like this could be used:

    .wf-loading .my-text-with-google-fonts {
        font-family: Arial;
    }

    Other thing you could do is hide the text until the page is loaded, it would work similar as above solution:

    .wf-loading .my-text-with-google-fonts {
        display: none;
    }

    You can further use this class to add jquery preloader or some other solution that would work best for you.

    Best regards,
    Predrag

  • MrArtist

    Hi Predrag

    I assume I'm supposed to add .wf-loading {display: none;} to the Upfront css, but what is the ".my-text-with-google-fonts" part? is it like .h1, .h2, .h3 .p, .li etc? I just want all font styles to not show/load until ready in the correct font - the page already uses a default font while loading (by theme default) as per your first example but that's distracting to the intended visual look.

    Given there are a lot of font styles in the theme/template, am I supposed to identify all of them and add each, or is there a wildcard solution to catch them all?

  • MrArtist

    Hi Milan

    Let me put it another way: As Upfront is all about being a simple drag-n-drop editor that shouldn't need lots of tweaking of css, what are the chances that the FOUT tweak can be added by default, or as an optimisation tweak?

    With any of the Upfront optimisation settings turned to On or Active, then the FOUT issue shows itself leading to ugly font representation while the page builds.

    Surely it would make sense to have the themes look good on page load, so .wf-loading display: none seems like a good idea as default for all the theme's default font styles?

    I'm sure everyone would rather not have the wrong fonts show momentarily, so rather than each Upfront user have to research and find all the font styles and then manually enter them ourselves, it would be far simpler if this was done just once by the theme creators.

    Many thanks.

  • MrArtist

    Well I finally figured out what to put in the Global Theme CSS.

    According to:
    https://helpx.adobe.com/typekit/using/font-events.html
    it was:

    .wf-loading p, .wf-loading span, .wf-loading h1, .wf-loading h2, .wf-loading h3, .wf-loading h4, .wf-loading h5, .wf-loading h6 {
        font-family: "Open Sans";
        visibility: hidden;
        }
    
    .wf-active p, .wf-active span, .wf-active h1, .wf-active h2, .wf-active h3, .wf-active h4, .wf-active h5, .wf-active h6 {
        visibility: visible;
        }

    (NB - not sure if the "span" declaration is needed but it was suggested in the list provided earlier?)

    However, after all that, it seems that the FOUT (Flash Of Unstyled Text) is not the full problem when using Upfront's optimisation settings. Instead I'm now getting a FOUT showing before the FOIT (Flash Of Invisible Text) as created by the added wf-loading/wf-active CSS - i.e. I can now see when the period of invisible text is (not) displaying, but the text still immediately shows on page load for a period of time before the FOIT.

    The FOUT (for the headings) is displayed in a default font of what looks like Arial. At one point I accidentally left all the "visible" "wp-active" statements as "wp-loading" which gave me the Times font in place of Arial, so in the end I was seeing three fonts show, so it makes me think something else is pre-styling the fonts before any chance of setting its visibility to hidden.

    This is all very odd. I see the same experience in Chrome or Firefox (caches cleared).

    Any thoughts?

    Access granted in case you want to see it in action on my site. Just enable the relevant first lines in the Global Theme CSS and turn on either of the first two optimisations.

  • MrArtist

    Hi Predrag
    FOUT/FOIT caused by Upfront optimisation is deactivated as I don't want it to show on the site.

    As mentioned above, and in the support notes section on my site, to see the problem you need to uncomment the relevant (indicated) first few lines in the Global Theme CSS and also turn on either of the first two Upfront optimisations.

    I have just extended the support time on the site.

    Many thanks.

  • Predrag Dubajic

    Hi MrArtist,

    I did uncomment the CSS but I forgot to enable optimization, sorry about that.

    I had another talk with the developers about this and provided them with all the info from this thread so they can look into optimization issues in future versions, for now issues like these are possible as the optimization options are still in experimental stage.

    Best regards,
    Predrag