Abigailm

When you weed through the verbiage of Scott’s very long blog post, the crux of the issue comes down to this:

Scott installed an MU which targeted Plugin Organizer (PO). The wordpress plugin team asked him to remove that code. He removed the code from the MU file, but at the same time restored older code targeting PO to a different file. The WordPress team then asked him to remove that code as well, and Scott is unwling to do so.

From Scott’s own blog post:

October 27th, Otto wrote:

The Plugin Organizer author removed the code from his plugin to deactivate yours. We expect you to do the same.

After Scott removed the MU but restored code targeting PO which he calls a “compatibility bridge”:

November 9th, Otto wrote:

You will remove any and all code that interferes with Plugin Organizer in any way whatsoever. You will remove all mention of Plugin Organizer from the plugin.

Scott wrote:

WP-SpamShield has a warning notice (which they advised us to add), and a compatibility bridge (which they advised us to as well), but nothing “targeting” Plugin Organizer.

Not true: classcompatibility.php has a function called “deconflict_po” which specifically modifies the action of Plugin Organizer. Scott admits as much in his screed – “”WP-SpamShield changes the value of 5 settings in PO”

Scott posted a list of reasons as to “why we cannot remove the compatibility bridge” implying that it would break function of WPSS.

I went in to one of my sites, backed up the classcompatibility.php file, and then deleted the lines referencing PO — (lines 173-178, 306-324). Everyhing on that site works as expected, SpamShield javascript is called and used on all pages, no error messages thrown.

So for anyone who does not use Plugin Organizer, that code mades no difference.

I’m no coding expert, but I cannot see any possible way that removing the PO-specific function in the classcompatibility.php could possibly impact any other function of the WPSS plugin.

If PO is not installed – Scott’s code is superfluous.

If PO is installed, then Scott’s code modifies its settings.

If Scott doesn’t want to change his plugin, that’s his business.

But as much as he rants, that’s the only issue here. It’s not about free speech or democracy or a long-standing conspiracy or competition with Akismet — its simply an attempt to address a problem between two plugin authors.

I don’t think that the phrase “compatibility bridge” means what Scott thinks it does.

Thanks – I’ve seen his new post at https://www.redsandmarketing.com/blog/real-reason-wp-spamshield-kicked-off-wordpress-org/

I think it’s pretty clear that he’s got his own interpretation of events and isn’t going to change his mind. So I’m slowly migrating away from his plugin.

If you schedule one event as a 2-day event, and chpose the option for “All Day” event rather than setting a time, then the list view would show one event spanning the number of days, with date only displayed. (No time).

First Annual Spring Fling Studio Tour April 7th and 8th, 9a-4p
April 8, 2018- April 9, 2018

You could stil show time in the event title (as you already have, in this example I copied from your site) — or by putting the time in the first line of the event description (so it would display on the list page).

And only one entry for the 2-day event.

Is there a reason that won’t meet your needs?

(Almost all the events on my site are multiple-day events that are from 2-5 days long, and that is how I have always done it. Just check the “All Day” box when entering).

if Spamfield did not take this action toworth Plugin Organizer, that one disabled spamfield and caused it to not be able to block spam so…

Plugin Organizer is designed to allow site designers and admins to selectively disable plugins on some parts of their site. So it is designed specifically to allow a site owner to be able to turn off Spamshield on some pages, if they want to. There may be good reasons for site owners to want to do that — to test for conflicts, or to enable features on certain parts of web sites, or to cut down server load and speed up pages where it is not needed. One thing that comes to mind to me is the possible need to design an accessible area of the site or form. (Because Spamshield uses javascript it can make create accesibility issues for some users.)

I don’t use it — but I can see that given that the whole point of the plugin is to allow selective disabling of plugins — then setting up code to defeat that purpose is a problem.

I have a lot of web sites that don’t allow comments, so the only place on the site where spam protection is needed is on the contact forms. So no need to have a plugin like Spamshield loading on every page.

There has to be more consideration for how a plugin can get manipulated by a small hand of players

.

The manipulation came from the plugin authors themselves. The WPSS author added code to defeat the operation of PO; the PO author retaliated by adding code to disable WPSS; and then the WPSS author retaliated by setting up a MU “Must-use” plugin designed to load ahead of others and disable PO before it even loaded. PO author complained to WordPress plugin team.

Then WP plugin team told both authors to remove code that targeted the other plugin. The PO author seems to have complied. But WPSS author did not – he removed the MU, but restored the function that he had placed before and which had been the cause for the PO author’s attempt to retaliate.

It’s pretty simple, and if there wasn’t a written rule before of “thou shalt not write code that is intended to interfere with operation of other other wordpress repository plugns” — there should be. We all realize that there is always a potential for conflicts among plugins, but it shouldn’t be purposeful.

The appropriate thing would have been for the WPSS plugin to throw off a warning that it is incompatible with PO, or even disable itself – with a prominent notice- on sites where PO is installed. That’s what my caching plugin does – it can’t be activated if other caching programs are enabled because of conflicts, but it certainly doesn’t try to disable the other caching program.

@ljoyceg — I completely understand your frustration – but changing themes can be a lot of work, especially on an already-developed site when you’ve already done a lot of customizations.

I’m only using Evolve on one site and unfortunately have learned from experience to delay upgrades for a few days and monitor these forums first.

Romik has a history of being responsive to support requests and complaints, but isn’t available 24/7 but it’s clear to me now that he is alert to this issue as he seems to have opted to roll back entirely to 3.7.6 with his 3.8.1 upload to subversion — and that was done only 3 hours after the rollout of 3.8.0 — see https://themes.trac.wordpress.org/log/evolve/

It would have been nice if he had posted a notice here and commented the changelog in 3.8.1 to make it clear that it was a rollback … but I’d say that for any complex theme it’s a good idea to read changelogs before upgrading, and unless something is noted as a security patch or a compatibility patch with a newer version of WordPress… give it a few days.

Thank you again for posting. I don’t know if its any consolation, but your post probably saved others from a lot of grief. At least those of us who have figured out to check the support threads before upgrading. 🙂

I’ve upgraded to WP 4.9 on two sites using Pods with no apparent issues. No error messages, no changes in function among existing pods.

Obviously there are a lot of different things that can be done with pods, which means different things that could go wrong — but I haven’t seen any issues at all with the 4.9 upgrade on any of my sites. So of course, make a backup before you upgrade… but no problems so far.

@ipstenu — I just want to thank you for your dedication and professionalism. I can see now what happened and what the issue is. Your recommendation posted at https://wordpress.org/support/topic/conflict-with-wp-spamshield-plugin/page/2/#post-9627154 makes sense, and it is the approach I would prefer as a user (for plugins to display warnings about incompatibility rather than attempt to interfere or disable conflicting plugins).

@redsand — I also want to thank you for all the work you have put in on developing your plugin. It is and was an excellent plugin and I am sorry to see you depart as it will be difficult to replace functionality.

That being said, I don’t want a plugin that intentionally disables or interferes with the functionality of others. I’d prefer to see warnings in the WP dashboard area. So in terms of this particular issue, the code that you don’t want to remove is also code that I don’t want to have. (Or at least code that I would want to be something that could be enabled/disabled within options settings.)

I don’t use the particular plugin that you have targeted, so not a problem there. But I do use a lot of plugins on a lot of sites and don’t want to have to worry about similar issues with a different plugin. If there is a warning that two plugins are incompatible, I can work with that. But when plugins conflict, whether intentionally or deliberately, it can take me hours to debug and figure out what the problem is.

So if there isn’t already a WP repository rule that says that WP plugins cannot have code specifically interfering with the operation of other plugins, I think there ought to be.

That being said, you are free to make your own choices and if you want to retain code that the WP Repository won’t permit, that is your option.