Network settings fail on test but website still uploads and downloads orders.

[zgap111]

Our 3 sites on v18.02 and network test = all fail
but everything seems to function - upload site/download orders/emails = all work...

[Bhujang]

i changed hosts and still get the same issues. Im going to try one last post to fix this then im leaving seller deck and going to word press.

[zgap111]

Wow... it's 4 months ago... and not resolved?

We're on host-it (with SD2018)... apart from the network test failing, it works for us.

Im going to try one last post to fix this

not sure what you're doing...

[bmcglobal]

Hi,
Was interested to read all the above. Our hosting is on zen.co.uk and we have exactly the same issue. We been trying everything what is written above on this subject, but nothing is solving the problem. And yes, the site is working, uploading correctly, and orders coming through etc, but very annoying to get this message everything when downloading and uploading. Can any help us further?
Frank

[NormanRouxel]

SellerDeck versions 16.0.3 and below use some Perl code that is illegal on current version (e.g. 5.28.1) of Perl. Perl is what runs the Network Test, Cart, Checkout, Search, the file Merge at the end of an Upload, etc.
I got burned by it this week when Ionos upgraded my server and many of my test sites stopped working.

Thus it's worth checking the following:

The version of SellerDeck are you using?

The version of Perl installed on the server?

Here are notes that I made so that older sites could be kept working:

SellerDeck Perl files that need editing for Perl 5.28.1

These are fixed in SD 16.0.4 onwards

ACTINIC.PM

Change:

	if ((defined %::g_InputHash) &&				# override the real referrer with the passed value
	
To:

	if (%::g_InputHash &&						# override the real referrer with the passed value
	
Change:	
	
	if ((defined %::g_InputHash) &&					# if we have input parameters
	
To:

	if (%::g_InputHash &&								# if we have input parameters



SEARCH.PM

Change:

			$phashOutput->{$sProductReference} = $phashOutput->{$sProductReference} + %$phash2->{$sProductReference}; 
			
To:

			$phashOutput->{$sProductReference} = $phashOutput->{$sProductReference} + $phash2->{$sProductReference};
			
			
TESTSETTINGS.PL

Change:

	if (!defined @Filelist ||							# an error occured
		 $#Filelist < 0)
		 
To:

	if (!@Filelist ||										# an error occured
		 $#Filelist < 0)


Change:

		if (!defined @Filelist ||						# an error occured
			 $#Filelist < 0)

To:

		if (!@Filelist ||									# an error occured
			 $#Filelist < 0)

[bmcglobal]

Thanks Norman.
Our SellerDeck is v 16.07
Perl 5.016003
Our hosting company said they saw something interesting when I was uploading the site. Despite the permission setting on the cPanel is conform Sellerdeck, the cPanel stopped the cgi script. At the moment they do not know why, they are searching for it.

[NormanRouxel]

That's an oldish Perl so it is probably ok with the now deprecated code. And if you're on 16.0.7 then the bad Perl code will be gone anyway.

I see that you're getting "not found" errors on your scripts. The Perl issue I'm reporting would result in "General Script Error" type messages displaying.

It looks like your hosts have narrowed the problem down a bit so let's hope they find out what's wrong.

[bmcglobal]

Hi Norman,
problem is still there.....the hosting company only found that the path to perl shell should be /usr/bin/perlml and not /usr/bin/perl -- as it was before. So some scripts can be read now Crypt::SSLeay and Achieve::Zip and Net::SSL so something is solved. But "SellerDeck received a request forbidden error from the web server. The server is not properly configured to allow SellerDeck to run CGI scripts from the cgi-bin. Run Web | Configure Web Site Details... to review your web site configuration"....
Hope someone from SellerDeck will find out....

[bmcglobal]

Hosting company just replied with this:

"
believe a server module is blocking requests on a rate limited basis.

You can read more about it here:

https://docs.cpanel.net/ea4/apache/a...odule-evasive/

Whilst I can't divulge the specifics of our implementation (the module is designed to stop DOS attacks so publicly disclosing the limits defeats the purpose of the module), suffice as to say, it does look like your site is being rate limited. We see a significant number of POST requests within the same second which seems to trigger a block (403)

I've had a chat with our Infrastructure team who suggest that you add a 1 second sleep in to your site script(s) to help alleviate this issue.
"

can anyone help where and how to add?