Michael Ott

Totally awesome! Take your time. We’ve all gone this long without the feature, waiting a bit longer won’t hurt.

Talk soon.

Thanks, that’s great news about the unverified view.

I am aware of the existing function to schedule the cron to delete unverified users, and agree it would be problematic if it tried to delete too many at once.

But there could easily be a situation where the website is acquiring more spam registrations at a rate greater than the number of unverified registrations that are deleted when the cron action runs, which means you can never actually clean up all unverified registrations.

With this in mind, may I cheekily also suggest an option to let us specify how many are deleted when the cron action fires, and put a hard limit on the field so it can’t be abused. I realise this isn’t something casually implemented, so no worries if not possible. The new unverified view will still offer an easy way to bulk delete unverified registrations.

Thanks – love your work.

Update: I also just noticed that when I manually trigger the action, it only ever deletes 20 unverified users at a time. I can constantly replicate this.

Do you mean front-end (og:title tag) or in the metabox of the post backend?

• This reply was modified 8 months, 2 weeks ago by Michael Ott.

Howdy,

All sorted. It only happened on multi-site deployments, my bad for not noticing in the previous update. Update to 1.4.1 and you’ll be good to go.

• This reply was modified 8 months, 2 weeks ago by Michael Ott.

Apologies for the late response. This is now sorted.

Howdy,

Facebook debugger can occasionally complain when things aren’t broken. I’ve seen this exact behaviour before and the problem just went away by itself. In your case, there’s nothing wrong with your website that will prevent Facebook (and other social platforms) from displaying the correct social data. All your social meta tags are working as expected.

That said, you do have an issue that may or may not be related to the debugger issue. If you view the source code of the page you sent me you will see there are two sets of Open Graph tags being output. One set is by the Open Graphite plugin, and the other is by Yoast. If you would rather have Open Graphite handle the social meta tags, you can disable the Yoast social functionality as explained here.

The Yoast output is also using an invalid twitter:card property (as highlighted here). According to the Twitter documentation (X) the only allowable value here is ‘summary_large_image’ not ‘summary’ as Yoast suggests.

That aside, there’s nothing to worry about.

No worries, done. New update pushed.

Hello again,

Kudos for doing a proper process of elimination. Have you tried a completely different theme? I’d be interested to know if the problem goes away if you momentarily switch to any of the stock 202x WordPress themes for example.

If that solves the problem, let me know what your actual production theme is. If it’s a free theme that I can get my hands on, then I might be able to replicate the issue. That will be a start towards finding a solution.

Talk soon.

Hello,

That’s the first time I’ve heard of this happening. I can’t replicate the issue, and nobody else has reported it (now or in the past) and honestly it’s impossible for me to know what might be causing the issue without having access to the site back-end and possibly error logs. It could be a theme or plugin conflict.

It’s unreasonable for me to ask for this, obviously, so my hands are kind of tied, unfortunately.

Have tried disabling the open graph capability in Yoast? Perhaps there’s some sort of conflict there, but even as I say that I know it actually won’t cause the site to break.

Thanks for reporting that. All sorted now. Update to 1.3.6 and you’ll be able to delete those pesky remaining events.

Assuming my code comments weren’t stale, they imply that the itsec_dashboard_events table was only present when the Pro version of iThemes Security was activated. This appears to no longer be the case as checking now I can see the same table is also present on the free version And I had a condition that only counted the events logs and let you delete them when Pro was activated.

Anyhoo, I stopped using the iThemes Security plugin a long time ago, so admittedly my plugin has been neglected. Sorry about that.

• This reply was modified 1 year, 5 months ago by Michael Ott.

Thanks @teszilla

It’s been a while since I looked at this plugin, and yes there were a couple of warnings. All sorted now.

Update: Looking at the JS it’s clear where the problem is, so I fixed it.

Basically it’s currently grabbing the href value (which is pretty much always going to be the path of the large version of the image) and using it as the thumbnail path.

How to fix:

On line 473 of \assets\tosrus\jquery.tosrus.js change this…

return c + t(this).data(s.anchor).attr("href") + h

…to this…

return c + t(this).data(s.anchor).attr("data-thumb") + h

…and compile the file to minified jquery.tosrus.min.js

Now in the actual gallery in the WordPress template, create an attribute on the anchor called “data-thumb” which contains a value of the path to the thumbnail version of the image, so your code is like this:

<a href="path-to-large-image" data-thumb="path-to-thumbnail" rel="lightbox">

    <img src="path-to-thumbnail" />

</a>

We’re running a forked version so have no problem making these kind of edits. But I believe the addition of a new attribute to solve this problem is a no-brainer.

• This reply was modified 1 year, 8 months ago by Michael Ott.

Thanks for that.

A premium plugin just to return a single piece of user data is irresponsible.

I figured it out anyway (with the get_user_meta function), and it was pretty straight forward when I realised how the plugin is storing the data.

For anyone who wants to know:

$phone = get_user_meta( $user_id, 'user_registration_input_box_phone' , true );
echo $phone;

Have a great day. Consider the matter closed.

@saardvark No worries!