kaimana

Thank you @axiopathos They are the same, as I mentioned, I’ve been doing this since 1995. I used to write sites in Windows Notepad in html, visualizing the page as I typed.

Thank you @bruceallen It’s installed in the usual public_html under the root of a shared hosting server. Also, I can’t even GET JETPACK SET UP, so how can I turn off and on the features I want and don’t want?

But it’s a moot point because I found a workaround; if you install either the WooCommerce Stripe Gateway or the WooCommerce PayPal Gateway first, that will give you the login to wordpress.com and allow you to hook your WooCommerce up.

Then you can install and active WooCommerce Payments, which otherwise screams about needing JetPack and refuses to setup. So now I’ve got Stripe, PayPal, and Woo Payments to choose from.

I wasted four hours trying to get JetPack to work.

I spent a half hour figuring out the Gateway dodge after I thought of it. It’s all good!

Thanks guys! Site didn’t HAVE an SSL, that’s why.

I tried to get Sectigo, the security certificate provider offered by iPage, my hosting company, to issue an SSL since July 27th, until they finally told me they had rejected my order on August 28th. Huh.

But I was apparently wrong, because even though they said they rejected my payment and said “contact my provider”, when I went to my control panel, there was the SSL!

I’ve finally had it with iPage and am moving the site to InMotion, along with my main site.

Let’s consider this thread closed, and thanks for the help!

With Warm Aloha, Tim

If you’re still getting brute force attacks, did you author the posts and pages on the site under your admin name, or have “Author’ in the Author Box in post set to Admin/your Admin username? Because if you left an Author credential visible on the site that’s your admin name, a hacker already has half of a successful login attempt. Make yourself an Editor username and use it to author posts and pages with, because then no one can hack you using it; an Editor doesn’t have Admin login privileges. FWIW, because you’re still going to have the same problem on the next site; taking this one down just takes the plate of cookies off the table for awhile until you bake some more.

• This reply was modified 1 year, 4 months ago by kaimana.

I have the same problem. This forum is marked “Resolved” but there is no fix posted. Did you give up on fixing this bug? Thanks for any info, Aloha, Tim

Aloha Nick

Thanks for the simple explanation; situation is now fixed.

This is totally my fault: I last installed WooCommerce in 2015, and the version at that time auto-installed the Cart and Checkout pages. Current version doesn’t do so.

Not knowing these two pages now had to be manually installed, or that I had to use the WC Setup Wizard to do so, they weren’t.

Again, Thanks! Aloha, Tim………

I should have said “duh, it looks like I just have to edit the functions.php file”, but don’t know what filters to add to wc_get_page_id, if any, or how to insert the sidebars_widget filter configured properly either.

Aloha, Tim……

Hi Nick

Here’s what happens when I’ve got Genesis Connect for Woo ACTIVATED: my site pages (https://newageofsail.com/) show the full-width responsive header, the breadcrumbs, the sidebar, and the Super Social icon set in the widget at the top of the sidebar. The Super Social icon set at the bottom of the content is NOT visible. Also, the WP editor works and appears normal. There’s no white screen of death anywhere (seen dat before!); it’s just that the content DISAPPEARS off the page when GCFW is activated.

Here’s what I’ve got when I’ve got Genesis Connect for Woo DEACTIVATED: site pages appear totally normal, all content is visible, and both the Super Social icon set in the widget at the top of the sidebar AND at the bottom of the content appear.

I’ve got the following in my wp-config.php file:

define(‘WP_DEBUG’, true);
define(‘WP_DEBUG_LOG’, true);

/* That’s all, stop editing! Happy blogging. */

@ini_set( ‘log_errors’, ‘On’ );
@ini_set( ‘display_errors’, ‘Off’ );
@ini_set( ‘error_log’, ‘/public_html/error_php.log’ );

And when I activate GCFW and do a forced reload of a page, NOTHING is showing up in my error_php.log file, and there are no new entries in the WP error.log file. But this shows up at the top of the sidebar on my pages:

Notice: woocommerce_get_page_id is deprecated since version 3.0! Use wc_get_page_id instead. in /hermes/bosnaweb17a/b639/ipg.newageofsailcom/public_html/wp-includes/functions.php on line 3831 Notice: ss_do_one_sidebar is deprecated since version 2.1.0! Use dynamic_sidebar() with sidebars_widget filter instead. in /hermes/bosnaweb17a/b639/ipg.newageofsailcom/public_html/wp-includes/functions.php on line 3831

When I deactivate GCFW and do a forced reload, the deprecation notice at the top of the sidebar disappears.

Hope this helps!

With Warm Aloha, Tim……..

Should have known it was a plugin conflict.

Rather than peel back all the plugins, I started by peeling back all the Woo “helper” plugins and leaving WooCommerce on. Worked fine. Added PayPal For WooCommerce, Infused Woo (integrates Woocommerce with Infusionsoft), WooCommerce Product Add-Ons, and everything still worked fine.

I activated USPS WooCommerce Shipping, by WooForce (now https://www.xadapter.com/), and the Woo Settings page and Cart pages disappeared again. So I’m contacting them now to see if they’ve got anything. Their plugin solves a problem for us, but not if it breaks the site’s cart.

Thanks for the quick response!

Aloha wpsolutions

I just got off the phone with my iPage tech support guy and he said the following: get the “Allow from all” off the front of the list and put it at the end. This is what I had in .htaccess, that was created by AIOWPS:

#AIOWPS_IP_BLACKLIST_START
Order allow,deny
Allow from all
Deny from 130.185.155.*
etc, etc

What tech said is that the “Allow from all” just before the list of “denied” IP’s sets ALL IP’s to “allow” and ignores the list; he said the denys have to come first, then they are in memory. When the “allow” command comes in next, all IP’s except the denied ones are allowed.
So this is what I’ve got now:

#AIOWPS_IP_BLACKLIST_START
Order allow,deny
Deny from 130.185.155.*
etc, etc……
Allow from all
#AIOWPS_IP_BLACKLIST_END

I just cleared my cache and am reloading it; then clearing and reloading my CDN cache. I’ll let you know in a day or so if this worked.

Aloha, Tim………

OK, just confirmed that NO IP blocking directive works on my server; I blocked a specific IP: 91.200.12.132, and it got through. So the only puzzle is why can I block my own specific IP but not any others? I’ll get with the tech support people at iPage then get back with any info.

IP range blocking did NOT work; I logged right in with my IP range blocked.

What now? Get another hosting service?

Aloha, Tim…….

Aloha Wpsolutions

91.200.12.* has gotten through three times since I changed the notation from CIDR to wildcard in htaccess on the 18th. I didn’t wipe my system cache or CDN, but they’re set to auto-update every 24 hours, so that shouldn’t have affected it.

Any ideas?

Aloha, Tim…………

(yeah, I realized I hadn’t put those addresses into the blacklist yet; they just came in).

I know someone tried a hack when I get this message from my WP admin notification email address:

“A lockdown event has occurred due to too many failed login attempts or invalid username:
Username: friendly_techie
IP Address: 46.118.153.231

IP Range: 46.118.153.*

Log into your site’s WordPress administration panel to see the duration of the lockout or to unlock the user.”

Sometimes I’ll get 20 a day, mostly from 91.200.12.*.

I’ll change the notation from CIDR to wildcard, let it run a few days and see if they’re still getting through.

Thanks! Aloha, Tim………..

Aloha Friends at AIOWPS

The specific IPs that keep getting through are 91.200.12.*, 46.118.153.231, 91.210.147.8, and 46.118.117.16 . I get ten to twenty attempts per day from the IP range 91.200.12.* .

Here’s the entire AIOWPS section from my htaccess file:

[ Moderator note: code fixed. Please wrap code in the backtick character or use the code button. ]

# BEGIN All In One WP Security
#AIOWPS_BLOCK_WP_FILE_ACCESS_START
<Files license.txt>
order allow,deny
deny from all
</files>
<Files wp-config-sample.php>
order allow,deny
deny from all
</Files>
<Files readme.html>
order allow,deny
deny from all
</Files>
#AIOWPS_BLOCK_WP_FILE_ACCESS_END
#AIOWPS_BASIC_HTACCESS_RULES_START
<Files .htaccess>
order allow,deny
deny from all
</Files>
ServerSignature Off
LimitRequestBody 10240000
<Files wp-config.php>
order allow,deny
deny from all
</Files>
#AIOWPS_BASIC_HTACCESS_RULES_END
#AIOWPS_PINGBACK_HTACCESS_RULES_START
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>
#AIOWPS_PINGBACK_HTACCESS_RULES_END
#AIOWPS_IP_BLACKLIST_START
Order allow,deny
Allow from all
Deny from 130.185.155.0/24
Deny from 159.224.139.0/24
Deny from 176.8.88.0/24
Deny from 178.137.18.0/24
Deny from 178.137.89.0/24
Deny from 180.140.127.0/24
Deny from 185.81.158.0/24
Deny from 195.74.38.0/24
Deny from 213.184.244.0/24
Deny from 46.118.118.0/24
Deny from 46.118.153.0/24
Deny from 46.119.117.0/24
Deny from 47.89.29.0/24
Deny from 69.174.244.0/24
Deny from 82.98.146.0/24
Deny from 83.175.120.0/24
Deny from 85.128.142.0/24
Deny from 87.242.64.0/24
Deny from 91.200.12.0/24
#AIOWPS_IP_BLACKLIST_END
#AIOWPS_BLOCK_SPAMBOTS_START
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} ^(.*)?wp-comments-post\.php(.*)$
RewriteCond %{HTTP_REFERER} !^http(s)?://(.*)?\.friendlyaquaponics\.com [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule .* https://127.0.0.1 [L]
</IfModule>
#AIOWPS_BLOCK_SPAMBOTS_END
# END All In One WP Security

That’s it. Thanks! Aloha, Tim………

Aloha Friends at AIOWPS

Finally got time to look at this again:

I upgraded; got current versions of everything. I successfully locked my own IP out using the blacklist manager; then looked at the htaccess file and saw my IP, so the blacklist feature works (on me).

The following IPs are still getting through the blacklist manager, even though they’re showing up in it, and in the htaccess file:

91.200.12.*, 46.118.153.*, both Russian origin. Their ISP’s complaints department doesn’t return calls.

Any ideas?

I’m not worried; they’d have to suss out both my admin login name and my password, and they haven’t even gotten the admin name once.

Thanks for any thoughts you may have on this matter! Aloha, Tim……