Ok - I think we found the problem @Hyperbytes
Just put your project settings to Document relative
and then save the page
@Tom, bad news can be good news, this was another issue i raised with my service provider, some people are getting SSL errors
Any chance you could tell me your current ip so i can get them to check the logs and fault find,
Brian I can see your menu on your page just fine, it renders.
And no issues with your SSL this side either…
So the final result is - just use project settings, Links Relative to “Document” for now if you have php includes.
We will improve it in the next update so PHP includes never get rewritten to site root relative links
1 Like
All links changed to relative to document rather than root and that has resolved the issue.
Perhaps the customer will stop shouting down the phone now - lol
1 Like
Yes @Dave, the error only occurred in the “users” section of the site (which is a secured area)
Not sure if it is linked but it is the only area where the menu is not in the same directory as the files
I’ve sent you the details in a PM.
Possibly? We have secured pages with SSI menus working fine right now (the included .php files are within the parent/root directory with the secured pages).
Still got an issue if anyone has suggestions
The menu is called from both the site root and from a directory “users”
With links relative to site, that was not an issue as they were all in the form “/mylink.php”
Now they are relative to document them menu breaks as the path is dependent on the page from which the menu is called
Other than duplicate the menu at both levels, any ideas how to deal with this.
I would normally just manually set the links but rewrite just changes them
I’d do exactly the same for now until:
Then go back and revert to the original link structure. I know how easy it is to spend hours on such an issue only to end up doing the most obvious thing I’d thought about in the first place. The actual art is to remember all these ‘temporary’ fixes and go back and amend them once there is a fix… Sometimes I discover old ‘fixes’ only to stump myself once again thinking wtf did I do there!?! 
I have duplicated the menu on both levels and this has the menu working
@George Another thing to consider.
In my case the SSI was called from “root” and “user” directory
In that SSI there was also an image link (brand link)
With “relative to document”, the link was also rewritten so the link was valid from “root” but broken from “/users”
So it is not just SSI links that need to be excluded but ideally a way if excluding links ‘within’ SSI’s also
No problem - in the next update we will leave all server side includes alone as well routes links.
So, I restored my files yesterday and got my sites working again until I have an answer.
I have all of my links site relative because I keep the includes in a seperate folder and all of my other files are in various layers. To be honest I can’t figure out how document relative links work, besides why are there 2 couces if one is always wrong?
What has changed in 1.98 that caused this and how will I deal with it going forward. i still ahev 1.97 at home so that is where I will do my site work for now
@George I am loosing Route Link hyperlinking on saving the document.
Is that related to the issue here?
HREF is set to ./login when using picker. But on saving the file, the link becomes login, breaking the URL & redirection.
I am using ASP.NET & Server-Side Routing (SPA).
Yes Nishkarsh, same issue I believe, SSI and routes are being rewritten when they shouldn’t and no way to stop it. Fix will come in next update
2 Likes
The issues with broken links should be fixed now in Wappler 1.9.9
This topic was automatically closed after 4 days. New replies are no longer allowed.