Abigailm

OK, thanks. It’s a little tricky to download and rollback from svn because there doesn’t seem to be a way to download a full zip file — but I see that the zip file for the version I am looking for available from https://downloads.wordpress.org/plugin/wp-spamshield.1.9.19.zip — so I think I can do what I want for now.

I’d love to offer coding help if I could, but I don’t have the skills — but I certainly understand your limitations.

@ginmi – Again I am just a user like you and have no actual knowledge of what happened. But I do know that in general the WordPress plugin team does not disclose reasons for removal of a plugin, so I think that we have already been given as much information as we can reasonably expect.

I do know some facts about what happened publicly in the past couple of weeks. Apparently there is/was a functional conflict between the WP-SpamShield plugin and another plugin. That’s common and unavoidable– some plugins are incompatible with some others.

But what was not common is that the two plugin authors got into an argument, each accusing the other of having “malware” in their code; and each created code within their plugin to specifically block or disable the operation of the other. In the case of SpamShield, with version 1.9.20, released 10/27/17 – there was an “anti-malware” module added specifically targeting the other plugin.

Subsequently, each plugin author followed up with another update that undid that particular change — for SpamShield, that was version 1.9.21, also released 10/27/17.

In the case of SpamShield, the “anti-malware module” was in the form of an MU plugin, titled “WP-SpamShield Anti-Malware & Functional Integrity Scanner” (See https://wordpress.org/support/topic/two-wp-spamshield-plugins/). An MU plugin is a little different from a regular plugin, as it runs prior to other plugins and also cannot be disabled by users in the same wasy as other plugins. While version 1.9.21 removed the reference to the other plugin, it left the anti-malware module in place, set up to scan for another known malware program that has a similar name to Spamshield.

Within the file directory (via FTP), in the mu-plugins directory this shows up as “am-integrity-scanner.php”.

Again, I am speculating, but it is possible that the WP team has requested (or suggested) a specific change, which may or may not involve the use of the MU scanning plugin, and that the plugin developer does not want to make that change.

I really don’t have an opinion about this one way or another, but any plugin developer who wants to be hosted on WordPress needs to play by the WordPress rules. And it is never a good idea (for security reasons) to download plugins from sources other than WordPress, unless it is a premium (paid) plugin from a highly trusted source. (A paid plugin creates a contractual relationship between the developer and the buyer; whereas a free plugin is distributed without obligation).

So yes, I hope that this can be resolved within the next few days … but if not, then I see no choice for myself but to look for an alternative solution for anti-spam functions.

Here are the wordpress.org rules for plugin developers — https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

Note paragraph #18.

I use Shortcodes Ultimate on some sites with WP Fastest Cache, without problems, but the issue could be related the way CSS associated with the plugin is loaded.

@emrevona you might want to check this thread to understand the issue – https://wordpress.org/support/topic/feature-request-load-stylesheets-in-header-not-body/

OK, the easiest way to transfer a wordpress site is with good clone and duplicator plugin. I have used this one in the past, and never had any problems, but apparently it does fail in about 10% of cases.
https://wordpress.org/plugins/wp-clone-by-wp-academy/

But this one seems to be more popular these days: https://wordpress.org/plugins/duplicator/ (more than 1 million downloads & updated within the past 2 weeks)

Here is how I go about migrating a site:

1. I set up a secondary subdomain on the old server, in addition to the existing one. So there will be two domains, http://www.site.name and old.site.name, both pointing to the same installation. DNS for both old.site.name and http://www.site.name points to old server.

2. Same deal with new server, two subdomains pointing to the same folder/installation — http://www.site.name and new.site.name — DNS for new.site.name points to new server.

3. Backup database on old server.

4. Do a clean install of wordpress to new server,with new.site.name subdomain. Set primary admin user and password for wordpress to the same as on old server.

5. Follow the migration routine which generally involves a full backup of old site database and tarring of old site files, and then unpacking files on new site along with restoring database. Directory structure will be identical that way.

6. Test to make sure that new site at new.site.com is functioning, but don’t worry about internal links or attachments yet.

7. On old site,in wordpress dashboard, change site name to from http://www.site.com to old.site.com

8. On new site, in wordpress dashboard, change site name from new.site.com to http://www.site.com. Don’t do anything else yet.

9. Change DNS to point http://www.site.com to new host.

10. I usually make a teeny change to one of the sites on the home page, such as in the footer, so that later I will be able to tell which site I am on after the next step. For example, maybe I add “!!” to the page footer on the new site. It can be anything, just as long as I can easily and quickly tell the difference between site #1 and site #2.

11. Have coffee. Take a shower. Whatever….. expect it to take at least 45 minutes for DNS to propagate. But it could take a whole lot longer Do not expect new site to work until that has happened.

11. Once DNS has propagated, http://www.site.name should go to the new site. Sometimes everything works right away, sometimes I still need to use a plugin like Velvet Blues or another search & replace utility to update internal links.

Once everything is tested and working then the old site can be taken down, but having DNS point to old.site.name for a few names makes it easier to compare and recover stuff from the old site that sometimes doesn’t make it to the new site.

Anyway, that’s how I do it. I’d suggest deleting all the stuff from the new host and starting from scratch.. but up to you.

Just in the future: moving a wordpress site from an old to new host is an intermediate, not beginner level skill. So next time get help before you start. Some hosting companies offer to do it for you, often without extra charge.

Try looking at the page when you are NOT logged in.

Hi, this was a problem caused by the WordPress 4.8.2 update.

Wordpress made some security related changes that prevented code in the Event Calendar from executing. Later the same day, the Events Calendar team issued a hot fix update — you can read more about that here:
https://theeventscalendar.com/hotfix-the-events-calendar-4-5-12-3/

So right now, no version of The Events Calendar before version 4.5.12.3 is fully compatible with the current version of WordPress.

So you would either need to upgrade The Events Calendar to the current version, or roll back your WordPress installation to the previous version.