Ben Butterfield

Hey @mkctu and @jamesc91,

I have faced a similar issue with a client that has around 6k products, which are frequently updated and also have a requirement to frequently add new products.

From what I can tell, the webhook fires when a product is edited and, possibly, when a new product is added. The webhoook triggers a full catalogue re-sync rather than a targeted sync, which takes a substantial amount of time and can fail on sites with low resources available.

Our temporary solution was to increase resources available on the WordPress server (Amazon AWS EC2 m5.large in this instance) to help prevent re-sync failures. It still takes some time though and does not show new products or edited products in real time – more like 15 minutes later.

You can check the latest sync log in BigCommerce -> Settings -> Diagnostics -> Get Diagnostics, and I think the latest version of the plugin also gives a sync log.

Hope that helps.

I’d take a guess that the login lockdown plugin may be preventing you from resetting your password. If you have FTP access, navigate to wp-content/plugins and rename the login-lockdown directory to BACKUP-login-lockdown. This should force the plugin to be disabled. Once you have reset your password and logged in again, you can rename the directory back to it’s original and enable the plugin again.

Here you go:

https://www.toltoys.com/wp-login.php?action=lostpassword

Boom!

This isn’t right:

require( dirname( __FILE__ ) . ‘afs/wp-blog-header.php’ );

This is:

require( dirname( __FILE__ ) . ‘/afs/wp-blog-header.php’ );

Notice the forward slash.

Are you using the theme editor? Try this, replacing 123456 with the hex value of your choice:

.art-postheader a:visited, .art-postheader a.visited { color: #123456; }

Ok – that could be the problem. Two things:

– You need to copy the index.php file from /public_html/afs/index.php not /public_html/afs/wp-content/themes/whatever/index.php. If it’s in a theme folder it’s a theme file not a core WordPress file. That looks like a theme file to me.

– You aren’t ADDING a line, you are CHANGING a line. If the line isn’t there, you got the wrong file.

Let us know!

For sure! Doesn’t really make any difference on a non public facing localhost though, which is why I suggested it as a possible fix for the problem so the OP can find the root of the problem.

I take your point though – should have provided instructions for resetting the permissions. Please forgive me – I’m not up on the etiquette of this forum.

Also, as was suggested in the thread you linked to, why not just serve afsjoints.com from public_html/afs if there isn’t anything else running on afsjoints.com?

On this page, there is a section titled “Using a pre-existing subdirectory install”. Follow that carefully, ensuring that your WordPress Address in Settings -> General is set to “https://www.afsjoints.com/afs” and Site Address is set to https://www.afsjoints.com. Also make sure that your web server has permission to write to public_html/.htaccess.

I don’t think file permissions are transferred over FTP (might be wrong). And this person is running a localhost, which isn’t likely to be public facing (notice my warning on that). So, see if you can get it working and then start locking down permissions. In my opinion, it’s easier to do things that way round.

If it’s your own domain name, try googling “blogger custom domain instructions”. I have no experience, but I guess it’s a case of setting your nameservers or A records in “advanced DNS” or whatever your host calls it. Hope that helps.

If it’s on localhost, try chmodding the whole WordPress directory to 0777. The cache folder may not be where you think it is. If it’s public facing, don’t do this.

As pioneer said, this probably isn’t the place. But, are you sure you went through their installation / configuration instructions fully?

You want to point your own domain to blogger or a something.wordpress.com domain to blogger? I doubt the latter is possible.