jtcheng

Hmm.. Still getting intermittent behavior concerning both the header behavior (and which page/post it gets applied to).

Also noticed that there’s an overlap between the header menu and the sticky sidebar (for the site where the sticky sidebar is working).

This is shown in the following screenshot:

https://snipboard.io/m4gJUE.jpg

How would I go about fixing that in a way that would be responsive (so tablet users in landscape orientation wouldn’t see this kind of behavior)?

• This reply was modified 3 years ago by jtcheng.
• This reply was modified 3 years ago by jtcheng.

Hi Thomas,

I’ve tested the responsiveness both ways (via re-sizing the window on desktop and hard refreshing when the window is already small).

I have also looked at the behavior on the phone itself).

I can truly say that while refreshing may make the header cosmetically appear like it’s behaving correctly, the pull down menu does not.

The following screenshot from the phone illustrate this point:

https://snipboard.io/5I1RH6.jpg

That said, when I did a refresh on the left side, apparently the menu did self correct.

But shouldn’t responsive design be able to adapt to screen sizes on the fly?

That sounds off to me.

I guess, I can try to live with this signature, but it feels dirty.

You sure this is normal behavior for responsive design?

• This reply was modified 3 years ago by jtcheng.

I also tried the Legacy Widget for the LuckyWP Table of Contents and I’m getting the same errors that I got for the Easy Table of Contents Legacy Widget.

https://snipboard.io/m54kBQ.jpg

So I’ll just keep this site in question on the TOC+ since it’s a different plugin that also isn’t sticking. That way, maybe there’s another piece of data concerning the compatibility of any table of contents widgets with fixed widget plugin.

Thanks

Hi Thomas,

Thanks for looking into the Lucky WP TOC issue.

Based on your findings, I gave other TOC plugins a try.

Unfortunately, all of the ones I’ve tried below haven’t worked.

– Easy Table of Contents by Steven A. Zahn (throws errors in Appearance->Widget when activated)
– Table of Contents Plus by Michael Tran (currently in use, but sidebar not sticky just like with LuckyWP Table of Contents)
– Table of Contents Block by WPDeveloper (doesn’t even work; neither in content nor sidebar)

Thus, I still haven’t found a suitable table of contents plugin that works with the q2w3 fixed widget for the BloggingSideHustler site ever since the HomeownerHeadaches site exhibited working behavior last year (and that one still behaves as expected).

So I’m out of ideas as I’m not sure if this is a FixedWidget thing or if all the other TOC plugin authors have made mistakes that prevent the sidebar widget on FixedWidget from working.

Thanks

I also noticed that when the .site-header is sticky, the menu also doesn’t exhibit responsive behavior as shown here:

https://snipboard.io/w0sRoy.jpg

The baseline expected behavior (when Fixed Widget not involved with site header) should be like so:

https://snipboard.io/A980Zt.jpg

Thanks

Just to establish a reference, when I turned off .site-header in the Fixed Widget custom element field, the site header reverts back to being responsive again as shown in this screenshot.

https://snipboard.io/TmFdje.jpg

Hi Thomas,

Thanks for the suggestion.

I tried doing .site-header, which does make the header sticky for desktops.

However, then I get unresponsive behavior when I change the screen sizes, and I’m not sure what is the most graceful way of handling what would be. (sorry, I’m not the most comfortable with digging into the CSS weeds without messing something up)

I captured a screenshot here.

https://snipboard.io/QMX5iz.jpg

Any suggestions on solving this? (then that would close the book on this issue)

• This reply was modified 3 years ago by jtcheng.

Ok. I’ve tried using selectors but then some funny things happen that require getting deep into the CSS.

I was under the impression that the header can be made sticky through this plugin, but it sounds like the header region itself is not a widget area (or at least it doesn’t seem to recognize the default WP elements as shown in the following screenshots)…

Widgets area:
https://snipboard.io/XWunYj.jpg

Frontend:
https://snipboard.io/sCOwi5.jpg

So given that the only recourse at that point would be to get into the code and spend lots of time making sure the CSS is right based off of what custom classes I can come up with, then I guess this plugin is not really useful for this particular use case?

Just want to see if I’m not misusing the plugin for this case.

Thanks

Here’s a couple of screenshots to show what I am doing with the site where the TOC sidebar is not sticking.

Widgets screen:
https://snipboard.io/FzJI1N.jpg

Related plugins in question activated:
https://snipboard.io/cQge7y.jpg

These steps were taken with the older site though the behaviors are different.

Finally, here’s a screenshot showing the versions of the same plugins being used on the old site:
https://snipboard.io/Kko275.jpg

Unfortunately, I don’t have revision control to identify the actual version of the plugin that was installed back in August of last year I believe.

Thanks

Hi Odilo,

Unfortunately, it didn’t work. But thanks for the suggestions.

I will pursue talking to the ad setup guys about this as I suspect they changed something in the code and I’ll need to know what that is so I can version control it.

Hi,

I recently updated to Limit Login Attempts Reloaded version 2.15.1.

The console error I’m getting when I go to the “Settings” tab in the backend is now the following:

jquery-ui.css:1 GET https://www.world-of-waterfalls.com/wp-content/plugins/limit-login-attempts-reloaded/assets/css/images/ui-bg_glass_75_e6e6e6_1x400.png 404

jquery-ui.css:1 GET https://www.world-of-waterfalls.com/wp-content/plugins/limit-login-attempts-reloaded/assets/css/images/ui-bg_glass_75_dadada_1x400.png 404

They appear to be benign so I went ahead and pushed this update to production from version 2.12.3 (which didn’t have this problem). However, I was wondering if you will clean this up?

Thanks,
Johnny

Follow up.

While I was doing this exercise, I also noticed this other warning:
A cookie associated with a cross-site resource at https://yoast.com/ was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

I’ve seen similar warnings come and go with other plugins. Any effort to address this on Yoast’s end?

Thanks

Hi,

I have utilized a staging site and backed up the database.

Then, I proceeded to disable all plugins except Yoast SEO and switched to the 2019 theme.

The warning still persists on the dashboard in wp-admin so I’m quite sure this is something going on with the plugin at this point.

Hi,

I am using version 14.3 on the production site, but I have used 14.4.1 and this warning still persists.

When the plugin is deactivated, the warning goes away.

I am hesitant to update to version 14.4.1 given that it throws a new warning:
wp-seo-post-scraper-1441.js?ver=14.4.1:1 Marking links with nofollow/sponsored has been disabled for WordPress installs < 5.4. Please upgrade your WordPress version or install the Gutenberg plugin to get this Yoast SEO feature.

And since I’m using WordPress 5.4.2 and I don’t intend to use Gutenberg, it seems like the issues are compounding, which is why I’m hoping the issues are resolved before considering updating and seeing if I want to take on more features (and potentially problems).

Actually, I realized that you had already marked this as resolved. So I will submit a new topic.