cjhaas

Hi belvesvalley,

We haven’t tested Vendi Cache on multisite and as of right now we don’t recommend that you run it. The original Falcon code has MU support but when I last tested it a year or two I ago I only had one MU site and for some reason (that I unfortunately don’t remember) we ran into issues. The issue might have been with another plugin completely but in multisite, especially with caching, that’s a more common problem than normal.

Thanks,
Chris

Hi wordpresslover7,

In order for Vendi Cache to exist in an environment where Wordfence is also installed we had to rename anything that was Wordfence related for both technical and also legal reasons. We still have a little bit of code that has “Wordfence” in it (including a class with that name) but that will be going away soon.

The very short and literal answer is that we cannot use that function exactly as is however we will be able to give you a different function that does the same exact thing. Currently there isn’t a function exposed but we’ve added that as a feature request and we should be able to push that out pretty soon.

Until we push that change live, however, you can still use the built-in constants to tell us not to cache something. If at any point in your request pipeline you want to disable caching for a specific URL you can just set the global constant DONOTCACHEPAGE to true and we won’t cache anything:

if( ! defined( 'DONOTCACHEPAGE' ) )
{
    define( 'DONOTCACHEPAGE', true );
}

However, please note that setting this on something that was already previously cached will not un-cache it, you’ll need to manually do that and then we’ll begin to honor your command.

Thanks,
Chris

Hi logicalt,

We’re glad that you were able to use our fork of Wordfence’s code! For the first release of this plugin we’re focusing on stability and feature-parity between Vendi Cache and Wordfence’s caching engine. We also want to make sure that we can safely interoperate in an environment where both Wordfence and Vendi Cache are installed so that neither steps on each other toes accidentally. We’ve been running this on many different configurations so we’re pretty confident we’re okay but we also just want to “let the dust settle” a bit before and hear back from users before we make any changes.

As for your feature requests themselves, adding an “Empty Cache” button to the toolbar shouldn’t be too hard of a problem. We’d probably make users opt-in with a checkbox because I’m not a big fan of changing the entire admin experience, even if it is just slightly, for such a feature.

As for the preload, that one’s a little trickier and unfortunately probably won’t happen. Without going in great detail, we’d have to spawn a rather expensive (time/memory/CPU) task to spider your entire site to determine every possible URL so that we could cache them. Even if we added a “preload only these URLs” option it could still amount to a rather expensive tasks that ultimately we think is outside the scope of this plugin. For sites where we want to preload things, however, we just use a free spidering program such as Xenu which is awesome at discovering every single nook and cranny of your site.

Thanks,
Chris

Hi Max,

I apologize for missing you here but I’m glad you figured this out! We’ll update the documentation to be more explicit about how to disable Wordfence’s engine. There’s a very good chance that people enabled this (or someone on their behalf) years ago so it might not be obvious for everyone how to disable it.

Thanks again!

Chris

Hi foley2013, thanks for catching that! We tried to move all of the text into translatable sections and it looks like we missed a percent sign there. We’ll get that patched and pushed out in a future release. Thanks again!

I’m the author of Vendi Abandoned Plugin Check and I’ll be posting an update early next week once I complete my testing.

The plugin API tells you to query the URL https://api.www.ads-software.com/stats/plugin/1.0/{slug} however the {slug} part isn’t formally defined (at least that I’ve seen).

Inside of WordPress the slug is the path to the file that WordPress uses to “boot” up a plugin relative to the plugin directory (WP_PLUGIN_DIR). If you hover over the “Deactivate” on this plugin for instance you’ll see that the URL contains plugin=google-analytics-for-wordpress/googleanalytics.php and if you want to ask internal question to WP about this plugin this is the identifier that you’d use.

So our code was querying the WP API using https://api.www.ads-software.com/stats/plugin/1.0/google-analytics-for-wordpress/googleanalytics.php.

However, the meaning of “slug” for the API is just the folder that the author declared and not the boot file. Actually, it turns out that the entire path is completely ignore except for the last part. This URL will actually get the info, too:

https://api.www.ads-software.com/plugins/info/1.0/happy/memorial/day/google-analytics-for-wordpress.php

Since the API only looks at the last part it was querying for a plugin with the folder “googleanalytics” which is actually another plugin and retrieving the wrong data.

Our plugin worked most of the time before because many plugins name their boot file the same as the folder and we had fallback code to query that folder if the full slug didn’t work. (Also, not all plugins live in a folder, thanks Matt!)

We have a sample of a couple of thousand plugins and we want to run our test code against those but this should be addressed early next week.

Thanks,
Chris

Well, we ended up going down a much more complicated but safer path. The regex never worked on our iFrame and that was always ugly to begin with. So we built a dedicated parser that actually walks the HTML and converts it. It also exposes four WordPress filters for developers to override specific parts of the logic. Maybe overkill but it works. You can see the full class here:

https://www.vendiadvertising.com/cjhaas/pardot/view-pardot.php

To use it

1. Create a new file called pardot-http-to-https.php in the pardot includes directory and copy the contents of the above URL into it.
2. In pardot.php add require_once PARDOT_PLUGIN_DIR . '/includes/pardot-http-to-https.php'; before the other require statements.
3. Remove the contents of the if statement on line 631 (of version 1.4) and replace them with $form_html = http_to_https::convertHttpToHttps( $form_html );

I don’t have time to perform a pull request right now (someone else, please feel free!) but might be able to this weekend or next week.

I just wanted to add that I was experiencing this as well. In my case I inherited a site and BWP Minify is one of the plugins that I always install, not only for the minification and merging but also to find broken CSS.

It turns out someone wrote this wonderful bit of code below, I’m guessing to try and disable a background image:

background: url('') ;

The CSS _processUriCB function was choking on it on line 288 (I don’t blame it). I fixed my CSS but if for some reasons someone wanted to change this they could simply change line 286 from:

if ('/' !== $uri[0]

to

if ($uri && '/' !== $uri[0]

On line 448 of easy-columns.php change the third parameter from the number 8 to 'manage_options'

We ran into this because we were using bt_image_resize which was calling the deprecated wp_load_image() function. The fix for us was to recreate that function in our code from here: https://core.trac.www.ads-software.com/browser/tags/3.9.2/src/wp-includes/deprecated.php#L3204 and then change the first line in bt_image_resize to reference our new function

I just wanted to thank you for this! I was print_r‘ing all around trying to figure out why it appeared that my settings weren’t being saved!

Thanks Dominik, that’s actually why we posted here! ??

We’ve debugged as far as we could to no avail. We were hoping someone more familiar with TinyMCE could find some weird bracket rule equivalent like in 27601 (needle in a haystack, I know). This will be the first time that we’ll have to delay a WP update.

Thanks Mika, the developer says he’s looking into this so that’s good.

They have a blog post saying they just hit 20,000 sales so there is a pretty sizable install base. They are often packaged within themes, too. Unfortunately the average user will think “the WordPress update broke my stuff” when 3.9 lands.

We aren’t receiving any errors in the console or apache logs and we’ve tried enqueuing jquery-ui-dialog but that didn’t fix anything.

Our symptoms are the exact same as ticket #27601 which is why we thought we’d post here. We get white text on a white background and the markup is plain text with HTML tags (not rendered). We can provide access for debugging if anyone wants to try it.

I can reproduce it on several sites, too. The solution that works for me is to go to Settings, CMS Tree Page View and uncheck everything for “Field Groups”

Thanks @p?r, glad it worked!