iangeek

Sadly debugging revealed nothing… The script that returns the error is a really simple “file exists? Yes/No” check and part of the core:

if ( validate_file($plugin) )
  return new WP_Error('plugin_invalid', __('Invalid plugin path.'));

So there’s no debug info to be returned in this instance. I created my own debug info by mod-ing the code myself to return the absolute path it was searching for, but that still didn’t reveal anything.

I got onto my web host’s tech team (https://www.layershift.com/, who are pretty switched on support-wise) to see if they could spot anything obvious. Which they couldn’t, and were just as baffled…

…But…

All of a sudden, without either me or the host’s tech team having made any change to anything, it suddenly started working. Literally nothing had been altered, and the problem had persisted for ages. But then all sorted itself out without any hint of a problem. Really odd.

All we could put it down to was possibly some sort of crazy NGINX voodoo, but even then they didn’t seem that convinced.

Oh well, just marking it down as one of those annoying, time-wasting WordPress quirks. Thanks for the input though Marios!

If you head to Appearance > Widgets and look through your sidebar, you should be able to locate the Soundcloud widget, and just delete the word “widget” from the Title area.

Alternatively, if you’re able to add any custom CSS anywhere, just try this:

.widget .qw-widget-title {
    display: none;
}

Great, thanks for that Mohammad. In my use case its more that my archives are a Masonry grid, which is doing its imagesLoaded thing… That combined with lazy loading means it miscalculates the absolute positions and heights of some bricks causing all sorts of overlaps.

So if I do something like this, all should be good?

<?php

add_filter( 'lazyload_is_enabled', 'let_masonry_do_its_stuff' );

function let_masonry_do_its_stuff( $enabled ) {

	if ( is_archive() )
		$enabled = false;

	return $enabled;
}

Doh! Can’t believe I missed this.

Nice one team. Cheers!

Thanks Jeremy. I was a little behind on my updates, but looks like this was commited in GIT mid-April. And I can see your hover filter merge back in May. So I’m late to this.

It strikes me that this would be much better as an opt-in rather than the default behaviour. I get that they’re part of the same suite of code and so I’m sure it made total sense from a dev point of view (all respect to mjangda) to include it in this way, but it’s clear that end-users have a very different UI relationship with image “pin-it” buttons in practice.

Certainly most of my clients (predominantly fashion and wedding industry, image-led and heavy on photos) are perfectly happy with the offical sharing buttons, but see the image pin buttons as being elements of the overall design, since their proximity to images means they’re aesthetically linked with the post content in a way that an abstracted row of buttons at the bottom aren’t.

Given that there are so many standalone (and more customisable) image pin plugins out there that people are likely to want to use alongside Jetpack, I really do think making this an opt-in checkbox should be the default.

Anyway, cheers for helpful response as ever, and sorry if this is wrong forum for this. Just not sure how else to give feedback from the front-line ??

Thank goodness I hadn’t imagined it!

OK, great – will try that filter. Good to know everything’s extensible ??

Many thanks.

*smacks forehead* how did I never know that existed? Every day’s a schoolday with WP ??

Anyway, thanks for that! I’ve rummaged around and come up with this, which seems to do the trick:

<?php the_widget( 'null_instagram_widget', 'username=xyz&number=5' ); ?>

Karma + 1 to Scott

Great news! Many thanks ??

Great, ta.. Will check GitHub in future first before reporting ??

I went with click() instead, which so far works great.

… except for in the specific scenarios as outlined by myself here and vestaxpdx ??

click() outright doesn’t work for elements that have been dynamically added to the page after the initial DOM has been loaded. on() doesn’t care whether the element is part of the original DOM or not, so is the only solution for both mine and the OP’s use-case.

Had the same problem here, albeit from a different cause.

+1 on the jQuery rewrite.

Closing this myself, as just realised this is a duplicate of the previous post. My bad.

Original post here.

This happened to me the other day – it’ll most likely be your PHP version.

Check with your web host. New versions of AdRotate need at least PHP 5.3 if I recall, whereas a lot of larger web hosts are sat on 5.2 by default for legacy reasons, even if they offer up to 5.4 should you need it. There’s probably a setting to change the version on your web hosting cPanel / Plesk / etc.

Thanks for the confirmation – I thought it might be.

My host (Heart Internet in the UK) doesn’t allow me to run “proper” Cron jobs, so I’m going to give this a try:

https://www.richardwilkins.me.uk/2012/11/heart-internet-wp_cron-php.html (posting link to this for anyone else who has the same issue).

Marking it as resolved – cheers for help.

Just to close this off, the culprit seemed to be the “Post List Featured Image” plugin. For some reason the combination of the Annex theme and that plugin meant Custom Post featured images didn’t display. Fine with other themes.

Anyway, now resolved. As you were.