We are currently moving an EE6 / JSF application from a deployment path someserver.com/app to its own subdomain app.someserver.com.
Most things are working smoothly, but we have had unexpected troubles with how the web layer handles the now basically nonexistent context-root.
One thing we found and fixed early was that a cookie we set had its path shortened from "/app" to "", and thus was only readable per folder on the server, not for the entire application.
We have now found a similar problem with hyperlinks that we generate in JSF:
Go to home page
This was previously rendered as href="/app" and worked fine, but now with href="" the link is understandably no longer active. I want it to say href=""/".
Is there an elegant solution for that?
Keep in mind that we also have links of the form
Go to projects page
, so simply replacing the empty context path with "/" is not good enough.
Am I missing something obvious? I saw an explanation here (which matches what we experience), but no elaboration on possible solutions.
Turns out I wasn't thinking clearly. I was so focused on fixing the string that #{request.contextPath} produces, that I missed that I basically used it wrong the entire time.
The simplest solution is to just use
...
(with a trailing slash) to get to the root of the application, and never use href="#{request.contextPath}" without a slash at all.
This solves both cases. If the application is deployed to "some_folder", the link becomes "some_folder/". And if the application is deployed to the server root, then the link becomes "/".
Hope this helps someone who stumbled into the same trap.
Related
I'm working on a rather large legacy web app with the following stack: nginx, Django, React with React Router.
My problem is that any URL that I load gets a # appended to one before end if the last char is a /.
So https://dev.local/feed/ becomes https://dev.local/feed/#/,
and https://dev.local/create/?fid=user8:13/ becomes https://dev.local/create/?fid=user8:13#/.
I've investigated everything on the front end side. I'm using browserRouter, not hashRouter. I only have one router in my front end. I suspect this is coming from the back end, but not ruling out the front end. Edit: tried completely commenting out the router - the problem persists.
My question is how do I generally approach debug something like this? Browser debug tools - console, network, etc are not showing any redirects or URL rewrites. What would work here?
The issue disappeared after I ripped out a large node module with a lot of subdependancies (old version of spectacle). The list of subdependencies is quite extensive, and it's hard to pinpoint what solved the problem. Nothing obvious could be seen, like multiple version of react-router or history modules.
I searched for this one, but found nothing ...
My old site is: cs.abc.edu/~cs4096
My files were at: cs4096#cs.abc.edu/public_html
My personal site: myname.com
My Github Pages site: myname.github.io
When a user requests cs.abc.edu/~cs4096 they are served cs.abc.edu/~cs4096/index.html and so on.
Via the ISP hosting myname.com, I setup a CNAME pointing teaching.myname.com to myname.github.io .
I want references to the old site, including pages below the top index.html, to be sent to teaching.myname.com where through the magic of DNS CNAME the URL goes to the myname.github.io site. In other words, users still go to the cs.abc.edu/~cs4096 but they are served from github.io.
The teaching.myname.com -> myname.github.io bit is working fine. It’s the initial redirect/rewrite that is failing. The problem is that the ~cs4096 is included in the URL when it is passed to myname.com .
That is, this
http://cs.abc.edu/~cs4096
ends up as
http://teaching.myname.com/index.html~cs4096
instead of
http://teaching.myname.com/index.html
and this
http://cs.abc.edu/~cs4096/Schedule
ends up as
http://teaching.myname.com/index.html~cs4096/Schedule
instead of
http://teaching.myname.com/Schedule
And, if you wonder WHY I’m doing two “redirects” here, it is because want the automatic rebuild of github pages that I can’t get at abc.edu or myname.com .
Thank you all
Never mind ... I abandoned this idea and used an HTML Redirect. It will mess up “Back” in the Browser, but it works.
A weird one: I have a site using ModX and this morning when I went to preview a page after editing a got and error. It seems that ModX is no longer placing the / before the Resource Alias.
Thus my URL becomes mysite.comabout-us instead of mysite.com/about-us and doesnt work
Putting in the slash manually has no effect as ModX removes it on save.
Im running Revo 2.1.3
Would anyone know how to fix this? Thanks
EDIT:
Did some more testing and discovered this also occurs when I turn FURLs off
OK so took a stab in the dark and looked through the config.inc.php file and changed:
$modx_base_url= ''; to $modx_base_url= '/'; and all seems to be well again... Really odd
I have a perfectly working admin backend on my dev environment but it fails miserably on the prod environment. Specifically a bunch of problems arise :
It is unable to read the symfony/web/sf/ directory hence not loading the required images though it states that a project has been successfully created. This however is not the case with the frontend leading me to believe that the problem is more sinister than what meets the eye.
Though it loads the admin pages, the css is not loaded, even though admin.css is present in the web/css directory.
I did an inspect element and the problem seems to be this, instead of routing to
/web/css or /sfDoctrinePlugin or /web/js
it prefixes the name of the app [controlcenter in my case] to everything, essentially rendering the HTML as:
href = "/controlcenter/web/css" or href = "/controlcenter/js" or href = "/controlcenter/js" . And this does not happen at all on my dev environment and things render the way they do.
Fixits anyone?
This was completely ridiculous of me to post this. I was simply trying to go to controlcenter/module which basically translates to backend/module for most people.
The index file in this case is controlcenter.php, and upon accessing that, I get the website to render the way it ought to. Sorry for the confusion people. Hopefully someone drops in by and sees the answer for themselves.
I should set up defaults in my routing.yml so that it automatically redirects without me having to type controlcenter.php
Thanks
A website of mine is behaving weirdly. The layout sometimes is fine, and sometimes it is screwy. An example page that I see the problem on is this one: link
Disclaimer: I have yet to start my investigation into cause in earnest. I am turning to Stackoverflow because I am lazy and I hope someone will say "That happened to me once, it is probably this...". So please, no one get stuck into this working out this issue if it is something you have never seen before, as it wouldn't be fair as I have not done it myself.
Ok, some background:
The problem usually (maybe always) occurs when first viewing the page
The problem does not show up always, only sometimes
When the page shows up munged, if you refresh it usually reloads looking as it should
The site is a rails app
The css is passed through the neat Smurf Gem, which automatically minifies the CSS and Javascript on the page.
The layout problems happen in firefox (both linux and winXP)
The CSS is served up in the production environment using the ":cache => true" option which concatenates all the css files into one file
Anyway, I am hoping that this has happened to someone before and it will be really simple to fix. If not, I'll go and investigate and return with the solution (or a request for more help).
Thanks in advance!
James.
[edit]I added the first two bullet points, inspired by the comments and first answer[/edit]
We have had something similar when using HAML and SASS that resulted in the CSS being completely unavailable. It only happened on deploys. We determined it was a combination of the Rails stylesheet merging and the generation of the CSS from SASS. Sass was not done generating the CSS, which it did so on the first request to the application, when Rails attempted to merge it all together. The result, a corrupt useless CSS file. Then we stumbled upon this article which has a solution for preventing this issue.
Based on all this, my best guess is that the Smurf gem is attempting to generate your file on the first request, but Rails is serving it out before its done. The generation completes then each following request is fine. If this is the problem then the only solution i know of is to get the file generated before the first request. Of course, this does assume that it is related to deployments or application restarts in some way.
Peer
I had such a problem. The problem was only at the first time the page was loaded. Just reload it and it was fine.
The problem in my case was that the images where not there in the cache for the first time so the browser didnt know it's dimensions when preparing the page which caused the problem
If an image doesn't have a height/width assigned to it, a place is created on the page and it's put there. If the image doesn't quite fit, the browser may not know this until it's refreshed. Then it already knows the size and can properly fit it onto the page.