zigpress

There are too many separate pieces of code to share on here.

However, I will be forking this plugin as soon as I get time. My fork will be called ZP Taxonomy Filters and will contain all the extra bits discussed above, and it will be available at zigpress.com/plugins when ready.

You’ll need to give me a few weeks though as I’m very busy.

Thanks very much for the reply, I appreciate it.

I’ve actually managed to get it working, using pretty much exactly the technique you describe.

Would you be able to implement the filter I detailed in my follow-up question? That would be the icing on the cake.

Follow-up:

I managed to do various things in my theme to implement this using actions and filters that exist in the plugin, and the only modification I had to make to the plugin was in the “is_btf_filtered” function in api.php:

At the start of the function I added:

if (apply_filters(‘beautiful_filters_is_btf_filtered’, false) === true) return true;

This lets me force the plugin to consider that the filter is active, so that the clear link is shown.

It would be fantastic if you could add this filter to the plugin.

The plugin is no longer installed.

No, and I don’t have time to debug someone else’s plugin for them…

I think we have to assume this is a dead plugin. There has been no response from the author.

At some point I’ll write my own.

I’m not providing any SEO plugin. I was simply hoping to debug the problem with ACF custom fields not updating the SEO score when loading the page editor.

Get your facts right.

So:

1. Why obfuscate at all?

2. Why not place a link to the Github repo in the source code of the plugin (e.g. the readme file)?

I quote from the guidelines:

“We require developers to provide public, maintained access to their source code and any build tools in one of the following ways:

– Include the source code in the deployed plugin
– A link in the readme to the development location”

You haven’t done the first, and the second isn’t exactly easy to spot, otherwise I would have spotted it.

Interesting. What about HTTP_REFERER – no info about the search term in there?

Keep an eye on our plugins page – just because we’re no longer developing plugins for the WordPress repo doesn’t mean we’re no longer developing plugins.

Thank you for your kind words. If you go to zigpress.com and click Plugins in the menu you can keep track of my plugins.
In the next couple of weeks look out for a new plugin on that page called ZP Widget Classes which, though not developed specifically for WordPress, will work with WordPress for now and hopefully for quite some time.

Yes, it certainly seems that websites aren’t at risk. Thanks Tobias.

Well that’s OK, if you don’t feel this is a risk then that’s good, I can continue using 1.9.2. But now that the vulnerability has been published by WP Security Bloggers, it might be a good idea for you to contact them to establish why they feel this is a vulnerability, especially if 1.10 doesn’t change this aspect of the plugin. I’m not a security specialist, just a humble plugin developer!

Thanks for the reply and as a fellow plugin developer I completely understand your position.

I want to ask one thing: a csv injection vulnerability has been discovered in TablePress 1.9.2 (link below). Would you be prepared to release a 1.9.3 just to fix that one thing, and preserve WP 4.9.x compatibility with just that particular release?

https://medium.com/@Pablo0xSantiago/cve-2019-20180-tablepress-version-1-9-2-csv-injection-65309fcc8be8

OK, I see I’m now back to 10, thanks very much.

The plugin uses PLUGINDIR and WP_PLUGIN_DIR to locate its JS file so it could be that whatever method you used to rename wp-content didn’t properly change those constants.

However it also uses “wp-content” as a literal string when setting the backup file location which means that it is not currently compatible with non-standard WordPress installations where the wp-content path has been changed.