Change of context between themes is not working as expected
How To articles are not official guidelines or officially supported documentation. They are community-contributed content and may not always reflect the latest updates to Liferay DXP. We welcome your feedback to improve How To articles!
While we make every effort to ensure this Knowledge Base is accurate, it may not always reflect the most recent updates or official guidelines.We appreciate your understanding and encourage you to reach out with any feedback or concerns.
Legacy Article
You are viewing an article from our legacy "FastTrack"
publication program, made available for informational purposes. Articles
in this program were published without a requirement for independent
editing or verification and are provided"as is" without
guarantee.
Before using any information from this article, independently verify its
suitability for your situation and project.
Issue
- Changing pages using the navigation from Liferay won’t actually trigger a reload in the page. Instead, the content that is being displayed will change, and some of the resources and imports won’t actually be loaded again, what gives Liferay a big boost in terms of load.
- This is the case even if the themes were different. That means if you are in frontend and use the “test-frontend-theme” in your public pages, and you go to the backend with the administrator, the styling and javascript of “test-frontend-theme” will be applied. Even if the theme should have changed to “test-backend-theme”.
- The same behavior is visible if you change from “test-frontend-theme” to “test2-frontend-theme” page.
- If we use in our “test-frontend-theme” a js library called “featherlight”, this is working perfectly fine but changing the theme to the “default-backend-theme”, breaks the layout completely by clicking links or tabs.
Environment
- Liferay DXP 7.1
- Javascript
- Metal JS
- Featherlight
Resolution
-
You can use Dynamic Include to include the featherlight.min.js trough CDN.
With this, the use case is still reproducible.
- If you make tests with other JS libraries, like React.js the use case won't be reproducible anymore.
-
Unfortunately, the issue is with featherlight.js, and that is a third-party technology.
-
We'd like to highlight, that for the recommended way to include a js file in the theme's head, can be found based on this documentation: Top JS Dynamic Include.
- Unfortunately, it isn't a solution for your problem with featherlight.js, however, it's better than including it in the portal_normal.ftl
- Every time we load a page, we are evaluating some javascript code
- When we navigate with SPA, we carry out some actions: destroy portlet, destroy components, clear SPA cache, etc. to clear information we don't want in the destination page.
- We know we need to do all this because all the parts (portlets, components, etc.) are introduced by our own code.
-
What happens if we introduce some custom code?
- We don't know whether we need it on the destination page or not.
- Once the code is evaluated in the initial page it's going to remain in the browser till we reload the page (no-SPA scenario) unless we do something specifically to remove it (like we do when destroying portlets).
- That's the reason why all the code added by featherlight.min.js keeps evaluated when we moved to User&Org page. And that's the reason why it is not there when the SPA is disabled.
- So, if checking this use case with featherlight.min.js, the only option would be to double-check what errors you are getting (i.e. Users&Org page) and then add some extra javascript code listening some of the events fired when we navigate with SPA and use it to remove/fix that code.
- As an example, if featherlight.min.js is adding something to window object that is causing issues, maybe you need to add some code which is going to be executed 'onEndNavigate' and it's going to clear that information from window object.
Did this article resolve your issue ?