Webserver On Alternate Port Number

I've just built a new internal development server, and have changed the default port number on it, so a new site url would be: http://www.newsite.com:1234for example.

However I've noticed that when I use the site, I can't log into the admin section, any index.php?dispatch= urls won't work, and also the some urls that get rendered correctly normall, are now returning dispatch urls instead.

Has anyone had any success changing the port number of the site?

Regards, Adam.

It should use what'd defined in your config.local.php. I.e.

http_host = yourdomain.com:1234

then the customer url should be

http://yourdomain.com:1234/index.php

Unless you have something that is hard coding the URL.

It should use what'd defined in your config.local.php. I.e.

http_host = yourdomain.com:1234

then the customer url should be

http://yourdomain.com:1234/index.php

Unless you have something that is hard coding the URL.

Sorry, forgot to mention, I did this, changed the http_host and the https_host in the config.local file to include the port number.

Also changed the storefront url in the database to include the port number

Would have to have a link to your site then to see what's going on.

Have you made any changes to .htaccess?

Not sure why your admin isn't working, works for me on 4.4.2 testing. But it looks like fn_dispatch and the SEO addon don't deal with alternate ports.

In fn_control line 275:

if (strtolower(Registry::get('config.current_host')) != strtolower(REAL_HOST)

config.current_host will have the port and REAL_HOST won't so this won't work properly

In app/addons/seo/func.php line 1059:

if (!empty($parsed_url['host']) && !in_array($parsed_url['host'], array(Registry::get('config.http_host'),  Registry::get('config.https_host')))) {

Same here, parsed_url('host') won't have the port and config.http_host will

There's probably more places that don't deal with ports. You could try submitting it as a bug but it will likely be considered an enhancement request.

Unfortunately, CS-Cart isn't working on alternative (apart from 80/tcp) port. Use another FQDN instead (eg. staging.example.org, test.example.org).

That is a very severe defect because some paid addons are bound to the domain name and to get them hooked up to a new subdomain requires to ask the seller to bind the license key to a new entry every time. Can't get development chain rolling. Please fix ASAP!

A properly developed addon will work based on the definitions in config.local.php and the resulting template variables for the frontend. Nothing in an addon should care what the port number being used is.

That is a very severe defect because some paid addons are bound to the domain name and to get them hooked up to a new subdomain requires to ask the seller to bind the license key to a new entry every time. Can't get development chain rolling. Please fix ASAP!

Well, you can also just use custom host lists for your browsers...

A properly developed addon will work based on the definitions in config.local.php and the resulting template variables for the frontend. Nothing in an addon should care what the port number being used is.

Hello! I am sorry but you have missed what the issue is. The problem is that CS-Cart itself cannot work properly on any port different from 80 because SEO-links get broken. The need to have it working on a different port in my case comes from the inability of some paid addons to share their license with subdomains of a domain name that the license is bound to, what is an understandable license management policy but obstructs development and testing purposes. The workaround is to run dev and test environments on different ports of a licensed domain name, what brings this bug of CS-Cart core functions.

Well, you can also just use custom host lists for your browsers...

Thank you for proposing the workaround! It might work but:
1) addons could validate their usage not only based on the HTTP Host header of every request
2) in the hosts file only bare IP addresses can be written, without any port number, so I would need to get those new IP addresses
3) it would be annoying to write all naming changes to configurations of all involved machines every time they happen
4) vendor could notice this as a suspicious activity and I do not want to mess any more with my licenses
5) this issue is clearly an old bug of a vital CS-Cart part and need to be fixed

By the way, the bug tracker here says "Cannot start a new Issue". Do I need to enter our company's CS-Cart license key here somewhere or to pass some other verification?

Hello! I am sorry but you have missed what the issue is. The problem is that CS-Cart itself cannot work properly on any port different from 80 because SEO-links get broken. The need to have it working on a different port in my case comes from the inability of some paid addons to share their license with subdomains of a domain name that the license is bound to, what is an understandable license management policy but obstructs development and testing purposes. The workaround is to run dev and test environments on different ports of a licensed domain name, what brings this bug of CS-Cart core functions.

I can't speak for other developers, but every time there is a reasonable request for development licenses for subdomains, we generally will enable our addon licenses for the requested subdomains. When requesting a dev license for a completely separate domain we require that domain to not be publicly accessible.

Since our licensing is domain based, any dev site in a sub-directory of the licensed domain is automatically available.