Jacob Dunn

Sure thing – this is actually in the contextual help in the top right of the settings page as well, for easier reference. Here you go:

RewriteRule ^slir(.*)$ /wp-content/plugins/pb-responsive-images/slir/index.php?r=$1 [L]

With this rule in place, your base url can then be set to {base-url}/slir/

If you don’t have mod-rewrite available, the rewrite URL should have set itself to a non-rewrite URL. If the rewrite above doesn’t work, and your images are breaking, paste the following into the SLIR rewrite field:

{plugin-url}/slir/?r=

That will put the fallback solution in place – the URLs won’t be as good looking, but it’s better to have it working, at least.

Enjoy!

It’s worth taking a look at this plugin, as well:

https://www.ads-software.com/extend/plugins/ctrl-s/

Looks like it fits the bill perfectly. Pretty simple, and straightforward.

There’s almost always a way to disable it, true – but the question is, is that per the repositories’ privacy policy? It says, “The plugin must not embed external links on the public site (like a “powered by” link) without explicitly asking the user’s permission.”

I interpret that as meaning they need to obtain permission first, as opposed to assuming that permission was granted when you chose to install the plugin, and allowing a method to later revoke it. I’d like to know if I’m incorrect on that, of course – before I end up wasting developer and moderator time. Let me know.

You’re right though – it’s a vast repository. I’m sure one could spend pretty much all of their time tracking down infractions and still never come close to keeping up. But there have been a couple of particularly egregious examples of link insertion that really have upset me lately. Meh.

Can’t complain too much though – it is all open source, after all, and you always get much more than you pay for.

Thanks Ipstenu, I’ll be sure to send them there. Makes sense on the ‘link to report’ front too. Although I’d still think it would be awesome to have – would just have to add a CAPTCHA, or require login. Not a huge issue, though, for sure.

Thanks again!

Quick correction : the url above has a missing /

Correct URL:
https://glasshouse.fr/dnload/contact-form-7-beforepipe.zip

Thanks for the plugin!

Awesome tip, logikal. Did the trick. Very surprised that such a massive error has been allowed to sit in the repository for so long. Especially given the fact that you’ve highlighted the error.

Would have immediately uninstalled the plugin if it hadn’t come with such high praise from an associate.

Disclaimer, untested:

For anyone installing from scratch, you should also be able to avoid having to edit the database if you edit core/update.php, and add the following at line 458:

instructions text DEFAULT NULL,

You’ll have to do so before ever activating the plugin, but it’s a bit less of a headache.

Ok – after way to much pain, I’ve tracked down the issue. Good news, it’s not this plugin. Turns out W3 Total Cache doesn’t play nice with Active Directory Integration. The object/database caching didn’t want to cooperate.

As for the Admin password reset issue, I’m still experiencing that, but it’s a minor quibble. I’ve just set up my AD user with the necessary permissions.

Thanks for the awesome plugin!

Thanks, newcom. That links checks out…I’m stumped. Unfortunately, I’m still not able to reproduce the issue – I’ve used Custom Post Type UI on a clean install with your post types, and the config page intentionally disabled. No dice. However, I’ve added some more sanity checks throughout that function – we’ll see if that fixes it. I’m pushing those updates live now.

I’d also attempt enabling those archives via the settings page and saving, now that you have access to that. That may eliminate those errors, as well.

Sorry I couldn’t help more!

I’ve found a possible fix for this issue – as detailed here. Let me know if there are any other issues.

Thanks!

Out of curiosity, can you paste the URL generated into one of those archive links? I wouldn’t think that it’s able to return anything if there’s no archive for that post-type…

I wasn’t able to replicate your errors, unfortunately. Used a clean install of WP, added a custom post type, and called wp_get_archives in the sidebar…am I missing a step?

Either way, I’ve found the error for your missing configuration page – I wonder if the two are connected? I’ll be pushing out an update with it later, but I’d like to see if I can track down this other issue first, if they’re not. The solution is here.

Thanks!

Wow. Just…Wow. When these server-specific issues come up, it always makes me shake my head. I know that it may be expected behavior, but it still doesn’t make sense, sometimes.

So, I forced verbose error reporting on XAMPP, and the following errors showed up:

Deprecated: Assigning the return value of new by reference is deprecated in C:\xampp\php\PEAR\Config.php on line 80

Deprecated: Assigning the return value of new by reference is deprecated in C:\xampp\php\PEAR\Config.php on line 166

Deprecated: Assigning the return value of new by reference is deprecated in C:\xampp\php\PEAR\Config\Container.php on line 111

Long and the short of it is – XAMPP is configured to look in your PEAR includes directory first when using require_once (for whatever reason), and grabbed a Config.php file from there, as opposed to the one in the same directory. I’m now forcing it to use an absolute path, problem solved ;-). Going to have to start doing that as general practice from here on out, if this kind of issue can crop up.

I’ll be pushing an update later, but if you want to patch it for the interim, here’s the code:

custom-post-archives.php, Line 120

// Configuration Page
require_once(dirname(__FILE__).'/config.php');
// Navigation Menu
require_once(dirname(__FILE__).'/nav-menu.php');

Enjoy!

Awesome – thanks for the info, mp. I’ve done testing on IIS, and LAMP, but never XAMPP. Tried to keep everything system agnostic, but from what your saying, it appears we’ve got a system-related bug. I’m downloading XAMPP now, I’ll let you know when I find a fix.

Wow. Odd. It shouldn’t even be getting that far, it was supposed to return on 764. I’m setting up some dev now, I’ll see if I can reproduce and kill it.

Ah never mind – you’re calling wp_get_archives, I see. Makes sense.