Progress bar not visible

Looks like the distance between the beginning and the end of your actual page content is not tall enough to warrant the progress bar to display. Do you have a longer post somewhere I can look at?

I also noticed a couple of javascript errors in the console which could be blocking the progress bar from displaying…

Hi Brian
Thanks for the response. I realised that none of the content was in the standard wordpress editor. It’s all in page builder elements.

I tried adding a load of text to the standard wordpress editor and still no progress bar.

I couldn’t see any errors in the console in chrome – if you have any other suggestions, please let me know.

Best
Richard.

May I see the link to the page where you added the content to the standard editor so I can check the source and console? Thanks.

Hiya

I just updated the plugin and tried adding content into the standard editor and it worked fine. When set to the top of the page, it was also being hidden by the #headerwrap.

Will try the plugin out on a site that doesn’t use a page builder.

Is there a way to chage the height/depth of the progress bar so it appears larger at the top of the screen?

Many thanks
Richard.

Thanks for pointing that out. I’ll take a look at ways of making it display above any fixed header elements in an update. It should already be doing so, but I will see if there’s anything further I can do.

As far as changing the width/height of the bar itself, that’s something I’d like to add as a feature in an update as well. Thanks for the suggestion.

Hi there,

I have installed your plugin: “Worth The Read” and I can not see i working on my website: “https://www.daviddelves.com“. What have a done wrong….. My main page is long and would like your plugin to work. ??

I have disabled all my plugins to find out if there is a conflict and still doesn’t work…. ??

I must inform you that my website is running on a “Genesis Framework by StudioPress“. ??

I look forward to your response,

David Delves

The plugin only displays on single posts, not archive pages or your home page. We are looking into adding it into custom post types in a future update, but as of now we are not planning on making it available for home pages or archive pages. Please let me know if you can’t get the plugin to work on single posts, thanks.

Hi Team,

Thank you for your reply…. It is still not working on my two websites below:

https://www.daviddelves.com
https://www.lasersfx.com

Like you say…. It will not work on pages and archives… My website consist of Posts ONLY and no pages. When open both websites and shows my main post. Your plugin still does not work and was informed it is compatible with all wordpress websites. Please can you help me to get this to work, as I really like it?

I look forward to your response,

David Delves UK

None of the blog posts I could find on the first site were long enough to trigger the progress bar to display. Here’s an example of a post I looked at: https://www.daviddelves.com/dreams-hallucinations-drawing-2/

The main inner blog post content has to be taller than the browser window to trigger the bar to display, otherwise it auto hides.

The second site I did find a longer blog post here: https://demo.studiopress.com/parallax/threaded-comments/ it should be displaying there but I checked the source code and it is not there. I just wanted to confirm that the WTR plugin is indeed still active on that second site? Please confirm.

Thanks Brian,

quick and easy setup, nice look and feel, excellent work!

There are two issues, though, both concerning visibility:

a) It would be great to have different width options for mobile vs desktop screens OR secure detection of a fixed header. At the moment, the progress bar is hidden under my fixed desktop menu header (Divi theme) until I set its width to > 70 px, which looks ridiculous on a smartphone. It would be great if I could set it to 5px and have it display equally on both devices, or if I could alternatively choose to set it to 5px for mobile and 75px for desktops to achieve the same desired result.

b) It would be great to be able to not just deactivate the opacity switch but also to have the non opaque color as a standard. If I flag the ‘mute’ toggle right now it leads to the progress bar being displayed with .5 opacity. I’ve changed as follows, but it would be nice to have that option on the settings page, too:

#wtr-progress {opacity: 1!important;}

Thanks for considering these, I appreciate it!

Christian / Germany

Hi @wegbereit I’m just now seeing your comments. I wish this support forum would alert me when people post new comments or topics! Right now I have to remember to check it, which I don’t always do. Anyway…

Great comments, thanks for your suggestions. I have a list going for the next update and I will add these to it. Can I get some clarification on a) above? Is the issue that the progress bar doesn’t have a high enough z-index to display on top of your theme’s header? Or would you rather be able to specify an offset of the progress bar so it displays below the header? Which option would be ideal? Thanks for your feedback!

Hi @brianmcculloh,

Oddly enough, I did get an alert with your answer. So this forum seems to send emails. Maybe they just end up in your spam folder (which is where I found mine)?

Anyway, thanks for taking care!

My main intention is to have the progress bar look the same on mobile and desktop versions. of Divi (Elegant themes).

The z-index variant would just place the the progress bar accross my menu, so that’s not what I’m looking for.

So the second option would be great – an offset that allows the progress bar to be displayed right below the desktop version’s fixed header, whatever its height may be.

Alternatively, I would simply set the height of the progress bar to a value that is just a bit larger than the menu’s height, but for the desktop version only.

You would probably need to include variables for breakpoints to achieve that consistently accross different theme, wouldn’t you?

Thanks very much and all the best
Christian

I did get an alert this time – maybe the last one did end up in spam. Thanks for the clarification. I think I like the first option better, but in either option I would need to include breakpoint options since on mobile you wouldn’t want the same offset as desktop.