How to remove hashtag(#) from vue-router URL? - vue.js

I want remove hashtag(#) from urls, but also i need to save no-reload mode. Can i do that?
I have: page.com/#/home
I want: page.com/home
I tried mode: 'history', but page reloads with it.
UPD: Is it possible to create SPA app without page reloading and with normal URLs?

When activating the history mode, you need to first configure your server according to the documentation. The reason for that is, that the history mode just changes the URL of the current page. When the user actually reloads the page, he'll get a 404 error, because the requested URL is not actually there. Reconfiguring the server to serve always the main index.html of your SPA resolves this issue.
When using a # in the URL (no history mode), the browser tries to navigate to the element with the ID, which was given after the # (within the same document). This was the original behavior of the fragment identifier. Therefore, if you add a link to your HTML with such a fragment identifier, the browser won't reload the page but actually look for the ID inside the document. The vue-router watches this change and routes you to the correct route. This is the reason it works with hashes. If you just add a regular URL to the HTML, the browser's native behavior is to actually navigate to this page (hard-link). This leads to your experienced reload effect.
The way to handle this, is, to never use regular links to route within a Vue Single-Page-Application. Use the tag <router-link> for routing between one page and another (but only within the SPA). This is the way to go, no matter if the browser allows the navigation with # without reloading or not. Here is the documentation for the recommended routing tag: link
You can also route from one route to another programmatically. Use $router.push() for that. Here is the documentation for that: link

Related

Single Page Application Routing

Modern single page applications use routing mechanisms which don't have to rely on fragments or additional url parameters, but simply leverage the url path. How does the browser know when to ask the server for a resource and when to ask the single page application for a spa-page controlled by a router? Is there a browser API which makes it possible to take over the control of url handing which is then taken over by e.g. the vue-router or another routing spa library?
In Vue Router (and I assume other libraries/frameworks are the same) this is achieved through the HTML5 history API (pushState(), replaceState(), and popstate) which allows you to manipulate the browser's history but won't cause the browser to reload the page or look for a resource, keeping the UI in sync with the URL.
For example, observe what happens to the address bar when you enter this command in your browser's console
history.pushState({urlPath:'/some/page/on/stackoverflow'},"",'/some/page/on/stackoverflow')
The new URL is even added to your browser's history so if you navigate away from the page and come back to it you'll be directed to the new URL.
Of course all these URLs are non-existent on the server. So to avoid the problem of 404 errors when a user tries to directly access a non-existent resource you'd have to add a fallback route that redirects to your index.html page where your app lives.
Vue Router's HTML5 History Mode
React Router's <BrowserRouter>
How does the browser know when to ask the server for a resource and
when to ask the single page application for a spa-page controlled by a
router?
SPA Frameworks use routing libraries.
Suppose your javascript app is already loaded in the browser. When you navigate to a route that is defined in your routes array, the library prevents an http call to the server and handles it internally in your javascript code. Otherwise the call is forwarded to the server as a GET Http request.
here is an answer that discribes this behaviour with a clear scenario

Custom nuxt 500 error page with preloaded state

Environment: Nuxt.js (Vue/Vuex/Node framework with SSR).
If user encounters an Internal Server Error, I want to use a custom Vue template, similar to the one I'm already using for 404 errors.
By looking at Nuxt source, it looks like the only way is to add a custom 500 page is to override the default .nuxt/views/error.html with my own custom error page.
I don't want just a static HTML page that the user must click out of to re-enter the app, though. I want it to still load the Nuxt app with some preloaded '500 error' state.
In Nuxt docs I don't see how to accomplish this. Any advice?
Things I have tried already:
Redirecting from error.html (doesn't work because of double redirect)
Iframe (works, but don't want to do it this way)

Url rewrite for an existing website

I hope this is not a very stupid question. I have to rewrite the url's of an existing website. I have never done that before, so I'm a little bit confused. I have allready written some rules that make a page like faq.php be accessible also by entering only faq without the .php extension, but the page fap.php it's still accessible and in the footer when I move the mouse over the faq icon the link shown in the browser is faq.php. To make the browser display faq and not faq.php do I have to change the href link in the page manually or there is another way?
For example: in this website(stackoverflow) when you move the mouse over questions, tags, users or other links, the browser displays only /questions (or the others) without .php(or whatever they used to built the website). How can I achieve that?
What you see in the status bar is what your server sends to the browser.
To remove .php from faq.php you must either
send only faq (PHP) or
replace the contents of href attributes on the client side (JavaScript).

Unable to show page in iframe in Ektron CMS

I am working on Ektron 8.6.0.060 CMS, on admin dashboard I add an custom widget in which I call an iframe for content page, on picking URL from iframe, 404 page not found error occurs. All URL and signs are using correctly still error occurs.
Be sure that you are entering a fully qualified domain name in your IFrame. Unless you are very careful about your paths, relative locations will likely be incorrect. Rather than "/page/item.aspx" or "www.site.com/page/item.aspx" make sure you include your protocol, e.g. "http://www.site.com/page/item.aspx" . This is particularly easy to forget if you are generating this url dynamically.
Also, if you are pointing to ektron content, make sure the content is published and public.

How to regain Login Portlet in liferay

I am new to liferay 5.1 technology.
I by mistake removed the login portlet and now I am not able to login into the application.
I mean login portlet is no more visible any help would be of great help.
Can you please try hitting the following url?
localhost:8080/c/portal/login
Replace host and port with your host and port number.
If it doesnt work out try doing the following.(Make sure the package is correct as i am not aware of package path in 5.1)
http://www.liferay.com/community/forums/-/message_boards/message/5005621
Actually, with enough persistence, it would be also possible to lock yourself out of access to /c/portal/login (as of Liferay 6.0.6). This can be done by setting community home page to a hidden "redirect" page (as opposed to default "portlet" page), causing /c/portal/login to redirect wherever the home page redirects.
Liferay tries to prevent from doing so by issuing alerts whenever you try to make home page hidden. But you can make some page hidden and then drag&drop it to the first position in site map root level.
The reason behind doing so is to achieve a certain appearance of portal navigation (which would otherwise require some mangling in theme), i.e. make home page redirect to one of it's children.
Going back to the topic, when /c/portal/login fails, there is one another, more reliable (yet more ugly) method of getting to what one would call a login page - append this: ?p_p_id=58&p_p_state=maximized to any non-redirecting Liferay page (and probably drop any other GET parameters if existent). This is also basically what /c/portal/login does - but it appends it to home page, so if home page is a redirect page it fails display login portlet in it's maximized state.