Ver. 8.0.1 cart.php redirecting to /store/productgroup/

[bayden10]

Previously in v7.x selecting Order New Product in Client area there was no redirection but after upgrading when selecting Order New Product within the client area it is now problematic when redirection is taking place to (i.e. https://whmcsstore.com/store/productgroup ) and this breaks our cart layout which has never done in the past.

Switching to Six template still produces the unwanted redirection.

Is there something that can be addressed in order to stop the redirection as to produce our current cart layout?

 

[Biswashost]

Hi icttech,  If you face this redirect only for 

• /store/website-builder
• /store/email-services

This is the new changes of version 8, whmcs new url for this 2 services like below:

• /store/email-spam-filtering
• /store/weebly-website-builder

So, if you before manually added your MC url then you can change them to new one or you can change MC new url to old url from "MC" product group setting page. 

[brian!]

33 minutes ago, icttech said:

Is there something that can be addressed in order to stop the redirection as to produce our current cart layout?

I doubt it - it has the smell of Friendly URLs and routepath about it, and specifically the new URL feature of Product Groups...

https://docs.whmcs.com/Product_Groups

now supposedly the URL is optional, but even if you delete the slug, there is still redirection to /store/{gid} - which I assume will still break your orderform template ??

my suspicion is that if this can't be changed in WHMCS (and it might be worth checking with Support via a ticket or posting in the v8 forums where you're more likely to come across someone from WHMCS), then fixing the cart template will be the simpler option...

I think that might something as simple as fixing the relative paths to the later css/js files (as they might be 404) - but you'll know your template better than me. 🙂

[bayden10]

Thanks @brian!

Yes that was my first thought was to check Friendly URLs and I did make a change from Full to Basic and the issue persisted.  Then checked the Advanced section, after seeing your post, for URLs and enabled "Mode Override" which resolved this issue.
Another thing I should have pointed out is that is a DEV WHMCS host with maintenance mode enabled which I think made this a bit more troublesome. Yes I did do a quick search within v8.0 discussions but nothing came up.

 

[brian!]

44 minutes ago, icttech said:

Then checked the Advanced section, after seeing your post, for URLs and enabled "Mode Override" which resolved this issue.

what did you change it too ? as I tried it yesterday and couldn't make that work... and I still can't today.

[bayden10]

On our DEV box and maintenance mode enabled I made sure to set to manual in advanced and then URI rewrite file WHMCS Rules: Synchronize. Then make sure manual override is shown, if not click the sync arrows.

You will see I have some error on rewrite but I can ignore that as this is DEV. Will be interesting once I've updated our templates and move over to Production.

 

[jimlongo]

I'm also having lots of problems with the rewrites since upgrading to V8.

Losing query string for one.  Go to http://mywhmcs.com/cart.php?string=something will take me to http://mywhmcs.com/store/slug/ and lose the query string in the process.

I've tried every setting available and can't get anything to work properly.   i don't see a path to making my module function with v8 at this point except probably insisting on customers use Basic URLs (which of course is a non-starter).

 

[bayden10]

Yes this is problematic for many custom modules as I see at the moment. I would also prefer to utilize Full-Rewrite.

Does anyone have a working .htaccess rewrite rule to bypass the /store rewrite and /store/slug so it rewrites Full properly?

Suggested

### BEGIN - WHMCS managed rules - DO NOT EDIT BETWEEN WHMCS MARKERS ###
<IfModule mod_rewrite.c>
RewriteEngine on

# RewriteBase is set to "/" so rules do not need updating if the
# installation directory is relocated.  It is imperative that
# there is also a RewriteCond rule later that can effectively get
# the actual value by comparison against the request URI.
# 
# If there are _any_ other RewriteBase directives in this file,
# the last entry will take precedence!
RewriteBase /

# Redirect directories to an address with slash
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.+[^/])$  $1/ [R]

# Send all remaining (routable paths) through index.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# Determine and use the actual base
RewriteCond $0#%{REQUEST_URI} ([^#]*)#(.*)\1$
RewriteRule ^.*$ %2index.php [QSA,L]
</IfModule>
### END - WHMCS managed rules - DO NOT EDIT BETWEEN WHMCS MARKERS ###

 

Existing

ErrorDocument 404 /404.php

### BEGIN - WHMCS managed rules - DO NOT EDIT BETWEEN WHMCS MARKERS ###
<IfModule mod_rewrite.c>
RewriteEngine on

# RewriteBase is set to "/" so rules do not need updating if the
# installation directory is relocated.  It is imperative that
# there is also a RewriteCond rule later that can effectively get
# the actual value by comparison against the request URI.
# 
# If there are _any_ other RewriteBase directives in this file,
# the last entry will take precedence!
RewriteBase /

# Redirect directories to an address with slash
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.+[^/])$  $1/ [R]

# Send all remaining (routable paths) through index.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# Determine and use the actual base
RewriteCond $0#%{REQUEST_URI} ([^#]*)#(.*)\1$
RewriteRule ^.*$ %2index.php [QSA,L]
</IfModule>
### END - WHMCS managed rules - DO NOT EDIT BETWEEN WHMCS MARKERS ###

# RewriteRule ^(.*)$ "https\:\/\/domain\.ca\/$1" [R=301,L]

Options -Indexes

RewriteCond %{HTTP_HOST} ^domain\.ca$ [OR]
RewriteCond %{HTTP_HOST} ^www\.domain\.ca$
RewriteRule ^e911\/?(.*)$ "https\:\/\/www\.domain\.ca\/announcements\/3\/Our\-911ore911\-Emergency\-Service\.html$1" [R=301,L]

 

[jimlongo]

I got a ticket response that the behavior I'm seeing is expected.

Quote

In 8.0, we did overhaul the cart to support Friendly URLs and a redirect would occur on loading cart.php without any expected parameters and before the ClientAreaPageCart hook point is ran

They suggested storing any parameters in the $_SESSION immediately.

Edited October 20, 2020 by jimlongo

[yggdrasil]

As Brian said, this seems to smell like the URL friendly routing.  You can look up my past posts on this. They started doing this with version 7 but only for a few basic URL's. In my case, it broke .htaccess rules permanently to the point of no return that I had to add hooks and code to detect URL's and redirect them to the URL I wanted. Basically faking the browser directions.

I suspect in v8 they even changed more URL's to the new format. This will cause havoc among many modules and third party addons in the future. The real problem is that the old URL's, even while ugly had functionality on them with quite easy POST and GET parameters on the URL. The new ones does not, it relies on sessions. You cannot simple access variables on the URL.

But this is not the biggest offender here. The old style was hardcoded into the smarty templates. That means you could URL's and paths as desired for anything, login, user registration, whatever. But now with the new Laravel format they don't give you access to links anymore. The URL rerouting is behind Ion Cube code, you cannot alter or change this, and I don't think you will ever be able to change its deep in the framework.

What I'm trying to say, is that you are out of luck. You will never be able to change or reroute URL's as you want, even if you find a hack today, they will break even more things in the future, it means it will only work temporarily. This is the new WHMCS style format URL's and they are not going back. They took away the feature on which you can access and modify links and URL's on your WHMCS site. You cannot decide anymore to what URL's a form will point, or a link, or a product. Or anything. All WHMCS installations are being standardized and every site will look the same in terms of URL structure.

This a big nasty change in a bad way (less customization) and while I started complaining about this almost 2 years back,  I suspect only slowly people will realize how limited they are and how negative the change is. I guess all in the new of SEO which is going to be worthless anyway as all sites have the same structure and links making it even less search friendly as you lost uniqueness now.

[yggdrasil]

On 10/19/2020 at 5:12 PM, icttech said:

Yes this is problematic for many custom modules as I see at the moment. I would also prefer to utilize Full-Rewrite.

Does anyone have a working .htaccess rewrite rule to bypass the /store rewrite and /store/slug so it rewrites Full properly?

Suggested

### BEGIN - WHMCS managed rules - DO NOT EDIT BETWEEN WHMCS MARKERS ###
<IfModule mod_rewrite.c>
RewriteEngine on

# RewriteBase is set to "/" so rules do not need updating if the
# installation directory is relocated.  It is imperative that
# there is also a RewriteCond rule later that can effectively get
# the actual value by comparison against the request URI.
# 
# If there are _any_ other RewriteBase directives in this file,
# the last entry will take precedence!
RewriteBase /

# Redirect directories to an address with slash
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.+[^/])$  $1/ [R]

# Send all remaining (routable paths) through index.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# Determine and use the actual base
RewriteCond $0#%{REQUEST_URI} ([^#]*)#(.*)\1$
RewriteRule ^.*$ %2index.php [QSA,L]
</IfModule>
### END - WHMCS managed rules - DO NOT EDIT BETWEEN WHMCS MARKERS ###

 

Existing

ErrorDocument 404 /404.php

### BEGIN - WHMCS managed rules - DO NOT EDIT BETWEEN WHMCS MARKERS ###
<IfModule mod_rewrite.c>
RewriteEngine on

# RewriteBase is set to "/" so rules do not need updating if the
# installation directory is relocated.  It is imperative that
# there is also a RewriteCond rule later that can effectively get
# the actual value by comparison against the request URI.
# 
# If there are _any_ other RewriteBase directives in this file,
# the last entry will take precedence!
RewriteBase /

# Redirect directories to an address with slash
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.+[^/])$  $1/ [R]

# Send all remaining (routable paths) through index.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# Determine and use the actual base
RewriteCond $0#%{REQUEST_URI} ([^#]*)#(.*)\1$
RewriteRule ^.*$ %2index.php [QSA,L]
</IfModule>
### END - WHMCS managed rules - DO NOT EDIT BETWEEN WHMCS MARKERS ###

# RewriteRule ^(.*)$ "https\:\/\/domain\.ca\/$1" [R=301,L]

Options -Indexes

RewriteCond %{HTTP_HOST} ^domain\.ca$ [OR]
RewriteCond %{HTTP_HOST} ^www\.domain\.ca$
RewriteRule ^e911\/?(.*)$ "https\:\/\/www\.domain\.ca\/announcements\/3\/Our\-911ore911\-Emergency\-Service\.html$1" [R=301,L]

 

 

 

 

 

 

 

 

.htaccess rules will not have any effect in some future as they are now routing things internally on the PHP framework. I suspect they will completely drop .htaccess in version 9. I would not bother much with rules because as they change to the new format you will not be able to identify unique products, or users, or anything else that was usually posted with the URL as a parameter. Unless of course WHMCS uses slugs on the URL's. They are not doing this as far as I know with the new format. The new format is not using slugs for ID's and identification like the old format did everywhere. They store values in the PHP session which means .htaccess becomes useless and pointless. Even if you modify a request on the fly with .htaccess, it will still be useless on any URL on which a user does an action (which is almost everywhere) because you cannot control to where the routing (redirection) is going after the action.

[BigWil]

On 10/21/2020 at 2:29 AM, yggdrasil said:

.htaccess rules will not have any effect in some future as they are now routing things internally on the PHP framework. I suspect they will completely drop .htaccess in version 9.

Well hopefully they work in 9.  I know the only thing working now is Basic.  The whmcs buttons themselves don't even do the job. Click a product, enter a domain, hit continue and there you are back at the product group.  Whmcs maybe slow down a bit, you're breaking things that have worked for years. 

[Paul S.]

I brought this issue up to WHMCS support and they just sent me to the redirect loop knowledgebase article. Since that didn't resolve the issue and support seemed unwilling or unable to assist, I have been searching for an answer to this issue since then. 

I just found this thread, but it seems that a proper resolution has not been found for this issue yet. Has anyone located a way to properly resolve this issue?

[megox58823]

Honestly, I wouldn't want a valid production WHMCS installation anywhere near a nulled version.

Depending on how many clients are being migrated, manual migration might just be the best option.

[wali3]

I received a ticket answer stating that the behaviour I'm experiencing is anticipated.