thor_actual

This is great news! THank you.

THanks for your reply and happy new years @wfphil

I should have specified further, I want to disable it for all users, instead of hiding it from myself.

If the WF team is unlikely to update the timestamp function to actually reflect user’s authenticating / logging on, it would be crazy easy to simply make it a configuration option to remove the column entirely. Would you be kind pass it on to whomever is in charge?

If you’re curious about the context in which this makes sense for me and probably a significant amount of your customers. My case is this: I manage and care for a bunch of WP sites, using MainWP and of course WF for firewall. The issue arises when my clients log in and notice that my user account apparently haven’t logged in for a few years and obviously suspects their site is not being maintained and monitored.

I’ve had two slightly suspicious clients tell me this the past 3 months. It’s making me consider replacing WF with something less desirable simply because it makes better business sense.

• This reply was modified 2 years, 11 months ago by thor_actual.

Hello, thanks for the reply!

I’m referring to MainWP’s login method and I think also InfinityWP was the same, but I don’t use it anymore, so cannot check. I also sometimes use “single sign on” from GridPane (managed hosting), but here it actually updates.

MainWP does not specify exactly how this sign-on feature works.

Regardless of how you authenticate / logon, I feel it should be impossible to enter admin with full admin privileges without triggering an update on “last login”. Or at least be able to disable the “Last login” column if it serves no purpose.

> Sorry, it’s impossible to verify as Google’s algorithms determine what shows up in SERPS and how

Anyone concerned with SEO will skip your otherwise awesome plugin, if it doesn’t work. Luckily it is very verifiable and I suppose I’ll test it on my blog then ??

Although I didn’t ask for it, I appreciate the explanation as to why it’s not put directly into the element. I didn’t ask for it because judging from the care to detail in the plugin, I already knew there was a very good reason for the way you implemented it.

Do you mind sharing a few sites that use your plugin? I’d like to see how Google treats them in the SERP. I’ll report back here ofc.

• This reply was modified 4 years, 3 months ago by thor_actual.
• This reply was modified 4 years, 3 months ago by thor_actual.

Okay, so I managed to abolish the bug in a very unexpected way. I noticed there were a slight shadow on a div in the header. Somewhere in the CSS a bit of border had been added to the navigation wrap div somehow. I removed it and the bug went away, wat. It makes absolutely no sense besides it having to do with scrolling to and from the header.

I hate having lost this amount of time to a bug I’ll never understand and having bothered you with it, as well. Thanks for your patience.

There’s no server side or WP related caching enabled and I have now removed every shred of the back-to-top btn.

Any ideas at all?

Don’t mean to bust your balls. I’m grateful for your contribution to the space ??

Thanks for your reply!

Looks like it’s the scroll to top button that’s playing the biggest part to me.

This is what I thought so I removed it entirely with no effect.

I wonder if something is a bit wonky with the initial rendering. Does appear to start with display property, then scrolling adds block, and then returning to the top adds none.

Yeah, that sounds about right. However, the scrolled up (start document?) difference between broken and unbroken is none.

I assume it’s Oxygen Builder providing this, so they may have more insight about the button. CPTUI itself isn’t doing anything to the theme, other than just making sure the post types are registered to be queried for and displayed with the templates.

It’s home rolled, which is also why it was the first thing i tried to remove (not just disable). Oxygen is very bare-bones.

To be honest, I’m sure the issue is on the Oxygen side, but chances are little they can/will help :/

@nahuelmahe Oh, I just assumed the CSS he referred had been applied to the theme’s main CSS file. I just realized now there are some settings for that within the plugin.

Would you like help translating this into Danish? I’d love to contribute to your work.

Perhaps you need to apply vendor specific CSS rules for Chrome. This might account for the discrepancy between the browsers. I’d suggest using a tool like https://autoprefixer.github.io/ to auto-prefix you code ??

I am not the author or even collaborator. I just stumbled across this amazing plugin last night.