Issue with website URL's

[arytekx3]

The last time I was on to update my website was yesterday and it was working great. All of a sudden today, I visit my website and click a link which should take me to http://arytek.com/services/laptops now takes me to http://arytek.com/home/arytekx3/public_html/services/laptops.

Why is the /home/arytekx3/public_html in my URL now?

This issue is causing login issues on my front end.

 

[gameconn]

looking at the url you have linked under "Services > Laptops" you pasted the wrong url, just edit your index page and fix it. c:
It seems you accidently messed with the other urls as well, you can just put "href="/services/laptops" at least that's how the linking on my site is.

If you need visual reference. c:

And how it should look

 

[essellar]

No, it's not a copy-and-paste issue; the underlying code is probably using PHP to determine the root location which is currently starting from the user root rather than the users' document root (where "/" would be public_html). This is due to configuration issues with the switch-over from Litespeed to Apache. Staff are working on a fix for the issue.

 

[caftpx10]

No, it's not a copy-and-paste issue; the underlying code is probably using PHP to determine the root location which is currently starting from the user root rather than the users' document root (where "/" would be public_html). This is due to configuration issues with the switch-over from Litespeed to Apache. Staff are working on a fix for the issue.

This occurs even with a simple forward slash (no document root globalsuper variable)?
EDIT: That would be strange, but there is doubt that would be the case as my site uses the original format (forward slash first).
I don't think the document root needs to be used in a link (looking at the code posted).

 

[essellar]

@caftpx10 - You're "thinking in HTML". In server-side scripts, it's common to include from includes that are included by other includes (and so on, and so forth). At the end of the day, you don't know exactly where the code that is creating links is running (and especially cannot be sure where you're running relative to the server root, as opposed to the application root); generating a server-relative link sort of depends on knowing where the asset you are linking to lives. Believe it or not, your average website owner doesn't know much about the applications they're running other than how to follow the setup and configuration instructions (maybe; there's often Softaculous and a support ticket or two involved in getting that far) and how to add stuff through the admin panel. Frankly, that's all they should have to know; you wouldn't force a novelist to be able to modify and build a word processor or a cashier to build out a POS system to get their work done either. So the app may be living in any install directory, and those assets are usually in subdirectories of the install directory. The app should be able to figure out from its pages'/scripts' own locations how to navigate to its own assets. If it can figure out __FILE__ and the current document root, it can point to anything it "knows" about, regardless of where the script is installed or how it's being accessed (as a potentially-deep subdirectory, an add-on domain, a subdomain, etc.).

 

[caftpx10]

@caftpx10 - You're "thinking in HTML". In server-side scripts, it's common to include from includes that are included by other includes (and so on, and so forth). At the end of the day, you don't know exactly where the code that is creating links is running (and especially cannot be sure where you're running relative to the server root, as opposed to the application root); generating a server-relative link sort of depends on knowing where the asset you are linking to lives. Believe it or not, your average website owner doesn't know much about the applications they're running other than how to follow the setup and configuration instructions (maybe; there's often Softaculous and a support ticket or two involved in getting that far) and how to add stuff through the admin panel. Frankly, that's all they should have to know; you wouldn't force a novelist to be able to modify and build a word processor or a cashier to build out a POS system to get their work done either. So the app may be living in any install directory, and those assets are usually in subdirectories of the install directory. The app should be able to figure out from its pages'/scripts' own locations how to navigate to its own assets. If it can figure out __FILE__ and the current document root, it can point to anything it "knows" about, regardless of where the script is installed or how it's being accessed (as a potentially-deep subdirectory, an add-on domain, a subdomain, etc.).

Yes, it's true that you don't know what is creating the links as the server renders the PHP that you cannot see unless you can access the actual file.
It's understandable to use document root for functions that include files, but when it comes to content which will take you to an other page on press, hover or any other touch event then it kind of seems that it is just using more than what it needs. If it is an include within the link to a single file with an attempt to use $_GET then that won't work just like that because include() or any similar function will read the string within the parameter as a full file name.

Anyway as you said, we can't see the server-side code so we don't know what is really going on in the code. I have just looked at the webpage and looked closely at what you're saying, it looks like something an average user may Iot be able to fix their self's (as the software can put anything in the way so it can be hard to fix or anything like that). It could be some page linking which is being used and set up during the installation.

 

[bdistler]

...it looks like something an average user may I[n]ot be able to fix their self's (as the software can put anything in the way so it can be hard to fix or anything like that). It could be some page linking which is being used and set up during the installation.

did you read what @essellar said above ? --> "This is due to configuration issues with the switch-over from Litespeed to Apache. Staff are working on a fix for the issue."

did you read what x10hosting said on their 'Status Page' ? --> "We are aware of the issues on xo1, xo2, and xo3 regarding the document_root and remote_address PHP Superglobals returning the wrong data."

did you know that the OP's account is on x10hosting's free-hosting server [ xo1 ] - which has this issue ?

what is the point of your post - it is of no added help for the OP?

 

[caftpx10]

did you read what @essellar said above ? --> "This is due to configuration issues with the switch-over from Litespeed to Apache. Staff are working on a fix for the issue."

did you read what x10hosting said on their 'Status Page' ? --> "We are aware of the issues on xo1, xo2, and xo3 regarding the document_root and remote_address PHP Superglobals returning the wrong data."

did you know that the OP's account is on x10hosting's free-hosting server [ xo1 ] - which has this issue ?

what is the point of your post - it is of no added help for the OP?

I'm very aware of what he and many others have said, obviously only the staff have the power to find and attempt to fix the issue with the access and tools available. The others? Nope. All the others can do is try to identify issues which don't require any special access or tools. They will have to either identify it by experience, what they've found (theirselfs or research) or "close enough" assumptions.

My post was just a question to confirm something and because I have got a reply saying things which I would like to reply to, I chose to reply to that. Nothing more, nothing less.

 

[arytekx3]

Thank you all for your responses. As I read above, it has to do with x10hosting's servers. As of now, it's still doing it and I have not changed anything in my website since a couple of days ago when it was working fine. Hoping this is fixed soon.