I have a mobile site at m.site.org and the main site at site.org I am using htaccess to redirect other pages but not sure if it's useful in this case.
If people are on a mobile phone and they go to the main site I want them to be redirected to the mobile version. Once on the mobile version we have an option to go back to the full site so I don't want them stuck in a redirect loop and can't go to the main desktop version.
I can not use server-side code and would like to know if there were an option without JavaScript (doubtful).
EDIT:
The link site.org I would like redirected but NOT site.org/index.html through htaccess. Possible? Does this help?
You should check this out. It provides regular expressions you use against the user-agent that can be done client side, and it is open source.
You can download an htaccess or get JS from it. Then edit at will. The htaccess gives you a rewrite cond. JS will give you a function.
Now this won't scale if a new phone comes to the market, but it's pretty decent and you can change it as new things come. Or you can run a process that fetches and deploys the new regular expressions periodically
Without touching the server, or adding JS, it's going to be difficult.
If you can check for the HTTP_USER_AGENT header on your server, you could display a HTML redirect:
<meta http-equiv="Refresh" content="0;URL=http://m.site.org" />
Related
I have a UWP (JavaScript PWA template / VS 2017) that is meant for testing and development of a hosted application. There is not much fancy about it besides letting a developer or tester choose which application build it should navigate to. However, one thing annoys me and I cannot seem to fix it. In a previous incarnation of this UWP, anytime I opened it on Windows 10 and navigated to an app build, it would show a back button at the top that I could use to go back to the index.html for the UWP.
I have scoured the old code to see if I was missing something. I was thinking perhaps I had left out some code to enable the back button and handle when it is clicked. Something that might have looked like this:
// This is javaScript
const navigationManager = window.Windows.UI.Core.SystemNavigationManager.getForCurrentView();
navigationManager.appViewBackButtonVisibility = window.Windows.UI.Core.AppViewBackButtonVisibility.visible;
navigationManager.addEventListener("backrequested", window.history.back, false);
However, there was no such code in the old version. I also checked the code for the hosted app and I didn't find anything like it either. Regardless, whenever I open the old solution for this UWP, I get a back button with all the expected functionality but without any code to handle it.
Is there some kind of declaration in the app manifest or .jsproj maybe? Something that tells the application at build time that we want a back button that works "out of the box"?
UPDATE
I recreated the UWP with a fresh template and did some tests on it. The template automatically sets the start page to https://example.com and on this site there is a link for https://www.iana.org, so I whitelisted that domain in the content URIs. Navigating to the link there works. I get a back button.
Next, I replaced the template code with my own code, pointed it to index.html as the start page, and set up the content URIs. When I try to navigate to anything, I do not get a back button. Even if I go to https://www.iana.org, I do not see a back button.
Last, I replaced the start page with https://example.com. When I click the link on that page for https://www.iana.org, I get a back button.
I also removed all JavaScript utilizing WinRT in order to check if something there might be messing with it, but it had no effect.
Additional Info
After having a look at the old version, a major difference I see is that the index.html for the app was actually hosted and in my version it is part of the app. Per recent comments on this question, it seems that the back button functionality only works for hosted content?
For security reasons, the PWA project requires the project to run in the https environment, or it can be run in localhost when debugging locally.
The PWA project in UWP is to package the existing PWA program. This requires that the PWA project is already in the https or localhost environment. You can view some requirements of the PWA project here
Thanks.
I have a website which has two versions, an all singing all dancing javascript powered application which is served when you request the root url
/
As you navigate around the lovely website the content updates, as does the url, thanks to html5 push state or good old correctly formatted #! urls. However if you don't have javascript enabled you can still use all functionality of the site as each piece of content also exists under it's own url. This is great for 3 reasons
non javascript users can still use the site
SEO - web crawlers can index the site easily
everything is shareable on social networks
The third reason is very important to me as every piece of content must be individually shareable on the site. And because each piece of content has it's own url it is easy to deep link to that url, and each piece of content can have it's own specific open graph data.
However the issue I hit is the following. You are a normal person and have javascript enabled and you are browsing and image gallery on the site and decide to share the picture of a lovely cat you have found. Using javascript the url has been updated to
/gallery/lovely-cat
You share this url and your friend clicks on it. When they click on the link the server sends you the non javascript / web crawler version of the site, and the experience is no where near as nice as the javascript version you would have been served if you directly went to the root of the site and navigated there.
Do anyone have a nice solution / alternative setup to solve this problems? I have several hacks which work, however I am not that happy with them. They include :
javascript redirect to the root of the site on every page and store a cookie / add a #! to the url so on page render the javascript router will show the correct content. ( does google punish automatic javascript redirects? )
render the no javascript page, and add some javascript which redirects the user to the root, similar to above, whenever the user clicks on a link
I don't particularly like either of these solutions, but can't think of a better solution. Rendering the entire javascript app for each page doesn't appear to be a solution to me, as you would end up with bad looking urls such as /gallery/lovely-cat/gallery/another-lovely-cat as you start navigating through the site.
My solution must support old browsers which do not implement push state
Make the "non javascript / web crawler version of the site" the same as the JavaScript version. Just build HTML on the server instead of DOM on the client.
Rendering the entire javascript app for each page doesn't appear to be a solution to me,
That is the robust approach
as you would end up with bad looking urls such as /gallery/lovely-cat/gallery/another-lovely-cat
Only if you linked (and pushStateed) to gallery/another-lovely-cat instead of /gallery/another-lovely-cat. (Note the / at the front).
Try out this plugin it might solve your 3rd reason, along with two reasons.
http://www.asual.com/jquery/address/
I've just created the required HTML5 Mobile web pages(including the CSS3 and javascript pages). I've got the apk file from build.phonegap.com as well.
But I want it to be dynamic i.e I should be able to add content from my laptop.
I've searched a lot but I'm unable to get the right info on doing this.
I just want to be adding simple text paragraphs from my local server(laptop) to the app on the go. What do I do ?
Sound like you need to set up some type of json / sql web service.
Use your machine's ip to do this.
Suppose your laptop ip is 192.168.1.1
Then from your application just use
http://192.168.1.1/your_appliction/webpage
replace http://localhost/ to http://10.0.2.2/
EDIT:
Treat your laptop as remote server and access the files in it as you normally do in website building.
From another post I think might help...
1- if you are building the whole site from scratch: You can create your site by any CMS like dotNetNuke or joomla which will allow you to login and edit what you want
2- if you are building just this page from scratch : You can build your page with online-editing in mind, in this case I recommend to build two pages one for for viewing content and the other for online-editing you can use any HTML-Editor control like FCKEditor
3- if you are dealing with already built page : it will be easier to build administration page which you can upload the new version of the content page to it, and the administration page take care of replacing the content page
Or maybe even the knockout js plugin could be something to look into http://jsfiddle.net/rniemeyer/LkqTU/
I need to be able to redirect from a silverlight application to a clickonce .application. The problem with this is that SL redirects via javascript, and it seems IE9 in its default security settings won't allow it.
Right now I'm stuck redirecting to a page with a "Click here to proceed" link, but it's not really the best. I tried redirecting to the link address automatically, but to no avail.
This would all work if I have my page added as a secure site, but I can't go telling people that they need to do that if they want to use this correctly... If any of you can tell me how to make my page prompt the user to add the site as secure without them having to do so manually, though, I would consider the issue resolved.
Thanks in advance.
So in the end we phased out SL and used a standard aspx (because of this and other issues). Thanks for your time, everyone.
I there anyway that I can install a SharePoint web application not on the root I need it on a virtual path? I have a situation that my customer is using somehow a url rewriting tool using ISA server like the following:
He have a main url let say http://publicsite/
we have sharepoint implemented internal on a site called http://internal/sites/sitecollection
when we open http://publicsite/sites/sitecollection it will open http://internal/sites/sitecollection
http://publicsite/ is on a different server than http://internal.
Right now I have an issue with the embedded resources in the rendered html markup for the sharepoint site like
<script src="/ScriptResource.axd?d=MZkmbKEwKTBSRdxFCFncmF72UDKBF9tO54OpDYX6Df4DBmB7HSDbA8CAqY5mCBAK2TAU34oVF24xOS5EJEafjb6Zcvwnmou5zv3RqxNzcSKM1XXzvQP1JpAzOAaH9PUPRTPUjZfdMBnoJPmBfgNZ-BFEntGwjcL7UiqfpH8R9TE1&t=ffffffffed1cce36" type="text/javascript"></script>
effectually it opens from the root and root based on the customer rewrite rule is another server so the resource response with status 404
And AFAIN since the sharepoint web application on the root so I can't change the way it renders the url.
Is there any way to solve this?
I started to think about some javascript function to change the url of all scripts with starts with /ScriptResource.axd and change it to /sites/sitecollection/ScriptResource.axd but It faild to reload the javascript I don't know why!!
The 2nd solution Is to create the web application on a virtual path and I don't know if this possible or not, so can anybody help me?
Thanks in advance.
Regards
My first suggestion would be to create a different public url for sharepoint. You are going to save yourself a lot of hurt if you do.
But if you really need to go forward, you could try to implementing a HttpModule that replaces the bad references. And you are going to have to test this a fare bit it you are doing anything more than just viewing some content. (collaboration, office sync etc)
https://sharepoint.stackexchange.com/questions/5956/rich-text-editor-error-messages/8364#8364
You will probably need to change the path on the page. Changing the configuration of the ISA server will still leave you with the problem that the root is on a different server to the SharePoint site.
If the JavaScript approach did not work you could try use the "adaptive control behavior" as suggested as the answer for this Question, Where you rewrite all the Script tags, you will also need to rewrite the Style and Image tags as some will refer to /_layouts
A heavy handed approach though but Control adapters work well with SharePoint.
I am thinking you could extend the web app on the internal server to the additional url http://publicsite/. Now you will rely on intelligent IP routing so that if the URL is http://publicsite/sites/sitecollection it goes to your intranet server, otherwise it goes to the public server. It sounds as though your ISA server already does this. I think that would make all the relative links correct.