David

To be fair, my original review (which I changed) was accusing them of posting artificial reviews, not about stolen code. It was only later in the discussion that that came up. It’s pretty clear that I was not accurate in saying that they were tampering with the review system.

I’m so sorry… clearly I was very wrong, on multiple accounts. I guess it’s not the first time I’ve been wrong and it won’t be the last. Thanks Shan for being patient with me. And thanks Jan for taking the time to not only reply, but read so many reviews. At the very least, I’ll never make such accusations again because you’ve convinced me that these reviews are already in very good hands… that’s a boatload of reviews you all have to deal with — good job!

Jan, you have my permission to delete this entire thread, seeing as it’s unsubstantiated. Unfortunately I don’t see any way I can do so.

I hope you can see that I’m not one of those guys who tries to take a one-star jab at a dev just to say I did. I really hoped to save other devs time by listing my findings… instead, I wasted both of your time. I’m very sorry, again.

Shan, I don’t think you can blame me much for coming to the conclusions I did about the copying of work. I would say that your plugin name is your book’s “cover”, while your screenshots and UX are definitely part of your “book”. I was thinking along the lines of “Wow, if I can see nearly verbatim similarities from just screenshots, you know it’s bad.”

But you’re right, I (incorrectly) didn’t even feel the need to look at the code, and since your plugin is using the taxonomy model (like WC’s paid extension), your plugin would be massively different than WCV’s. But I honestly don’t really think WCV’s backend design is that good… so I’m surprised you would copy it if writing something new.

To be fair to you, I did grab your code and peruse it. And sure enough, most of it is very different, and IMHO, much better code design than WCV. But there is some significant code copying in the templates folder. If I might suggest, instead of “giving them credit” in the next version, which doesn’t really do much of anything for them, how about you give back by submitting some pull requests to WCV? I personally submitted a few PRs to them awhile ago, and I think it’s the least we can do when using free code.

You are right — you are doing an excellent job with support, and I commend you for that. ??

I’ve never left a review like this before. It was actually the similarity of writing styles that pushed me over the edge. It wasn’t just one thing or another, but a trifecta of factors that makes it extremely unlikely that you are not doing something to artificially boost reviews. Broken English in a global community is a given, but I’ve read a lot of plugin review streams, and there’s a lot more diversity everywhere else than what’s on here. A 500+ install plugin typically gets 2 or 3 organic reviews.

People don’t have to take my word for it. This review is just to alert anyone to investigate the plethora of 5 star reviews before assuming that this plugin is awesome. Maybe it is awesome.

I was actually going to try the plugin, but after finding sketchy stuff going on, I didn’t want to. But your response prodded me to look into it more. Now that I look at the screenshots, it’s very obvious that a lot of this plugin is a direct copy of WC Vendors — I didn’t even know that when I posted my initial “review”. I’m going to be really honest… that pretty much removes all incentive for me to try your plugin. I’d imagine you’ll continue forking their improvements from GitHub while you try to create premium addons. So it’s clear that you are taking a lot from that project — my question is, what are you giving back?

This also stopped working for me, and I found that it’s Google’s fault, not this plugin’s. For some reason they turned off the Google+ API, probably after an update. You need to go to https://console.developers.google.com, then in the sidebar click “APIs”, then “Google+ API”, then “Enable API”.

I was using the jetpack_sharing_counts filter, and yes, that small adjustment to sharing.js fixes the issue. Glad to see there’s a fix!

I also found that the filter broke the email button, even when I tried it on a clean install with no other plugins running. Hopefully a fix will come soon… I love the idea behind the filter. I even think there’s potential for it to be an option in the settings… if someone doesn’t want the counts, there’s not much reason to run that code.

Thanks so much, Yorman, for all your help on this. The last tidbit about resetting the sitecheck logs is a lifesaver!

I’ve spent hours trying to figure this out, and I’ve learned a lot. I changed my php.ini file, and I’ve also added @ini_set('session.cookie_httponly', 'On'); to wp-config.php. That correctly enables that setting in PHP, which I can confirm with ini_get('session.cookie_httponly');.

However, that does not eliminate the error. As it turns out, any plugin that tries calling session_start() will also cause this error to come up. This is happening in three of my plugins: WordPress Social Login, Paid Memberships Pro, and WC Vendors.

It is possible to eliminate the error by calling session_start() in the plugin with the init action, like so:

function wsl_start_session() {
    if ( ! session_id() ) {
        @session_start();
    }
}
add_action( 'init', 'wsl_start_session', 1 );

However, I have not confirmed that the cookies function properly under this setting. My question is: is this actually the plugin’s fault, or is it a problem with Sucuri’s check? It’s worth noting that a plugin consisting only of:

if ( ! session_id() ) {
    @session_start();
}

will throw the error, so it’s unrelated to the other contents of those plugins.

Your site may have been hacked: https://wordpress.stackexchange.com/a/191570/20963

Thanks for letting me know.
https://github.com/strangerstudios/paid-memberships-pro/issues/210

For that second bug, line 115 in /includes/init.php needs to be changed from
if(!empty($post->post_content) && strpos($post->post_content, "[pmpro_" . $pmpro_page_name . "]") !== false)
to
if(!empty($post->post_content) && strpos($post->post_content, "[pmpro_" . $pmpro_page_name) !== false)

Perhaps doing that would introduce a different bug… for instance if there is both a shortcode for “pmpro_member” and “pmpro_membership”.

As a side note, it would be nice if the account page was set from the Pages settings page, rather than by checking for a shortcode in the content. Right now, any page with [pmpro_account] in the content would be considered the account page, from a CSS point of view. And I myself would prefer defining the shortcode in my template file, rather than the content.

Another more serious bug is that if I use this on the account page:
[pmpro_account sections='membership,profile,invoices,links']
or
[pmpro_account sections='membership,invoices']
instead of
[pmpro_account]
then it will no longer recognize it as the account page and assign the “pmpro-account” class to the body tag.

I was wrong. As Sergey points out in the Trac ticket, there are a couple different ways to get the lightbox working without changes to core. Not necessarily elegant, but it can be done.

Actually, the post_gallery filter is intended for plugin authors who want to completely replace the gallery shortcode functionality. If you look at the code, you can see that the filter is at the beginning of the function, and that you’re actually filtering an empty string.

I definitely think there should be a filter at the end of the shortcode to amend a WP gallery, and I’m a bit surprised one doesn’t exist already. I went ahead and submitted this ticket to try to get it added to core.

Until that ticket takes effect (if it ever does), I don’t think there’s a way to add your awesome lightbox to a standard WP gallery if it’s added outside the main post content area (aside from copying the entirety of the gallery_shortcode function), unless you can get it to work without having to rely on inline attributes on those image elements.

If Theme My Login is enabled, PMPRO will redirect the registration page to the membership levels page. I personally have Buddypress installed and want to retain that registration system, while keeping PMPRO as a separate thing after a user registers. To do this, I utilize the pmpro_register_redirect filter and set it to false so that PMPRO doesn’t take over my registration process. Just to be clear, this will do nothing to integrate PMPRO with Buddypress. Here’s the code (added to functions.php in your theme) to disable the redirect:
add_filter( 'pmpro_register_redirect', function() { return false; } );

I too was wondering this. If there are no stats available, Akismet will hide them on the settings page. I was checking this on a local test site so the domain was different, and therefore there were no stats available.

If you have Jetpack installed, you can visit the stats page manually at [your_site_here]/wp-admin/admin.php?page=akismet-key-config&view=stats