Issues Migrating Liferay 6.1 theme to 7 - liferay

I've been following these instructions, in an attempt to migrate a theme from our 6.1 portal to Liferay 7. The initial issue I seem to be having is getting the imported and upgraded theme to use vm as the template extension. I've added a look-and-feel.xml file containing the correct template-extension element to the 6.1 theme before importing/upgrading, but I am still receiving a "portal_normal.ftl not found" error after applying the theme.
Additionally, after importing and upgrading the theme into the Liferay 7 toolkit, the theme seems to only contain the child-specific theme files, and not the "compiled" set that would include the parent files (as it would had it been generated by the old sdk).
Any help resolving these issues would be greatly appreciated!

Liferay DXP/7 support freemarker. So your template files should be .ftl not .vm.You have to migrate template files into freemarker manually.
Regarding CSS: once you migrated theme, you will find a folder named 'src', you should make changes in files, placed here. Once you will find another folder over here named 'build'here you will find theme like we had in webapps in older versions.
Hope it will help

Related

Unable to create Liferay project from plugins SDK with error "app.server.dir is invalid"

I have installed Liferay7.0 successfully and then was trying to import Liferay SDK plugins. I am using Liferay supported IDE(Downloaded from Liferay website) Neon.3
I have tried reinstalling Liferay, but it didn't work.
Sdk version is also 7.0.
Please help to sort out this problem.
Unless you have a good reason to use Plugin SDK in Liferay 7, you should use Liferay Workspace (or maven or gradle). Plugin SDK is basically only for upgrading legacy plugins, but new work is better documented and more flexible in the new OSGi modules.
As you state that your Plugin SDK is version 7, you're probably not upgrading. Instead of fixing your issue, simply ignore the SDK. If you want to fix it: Just like the previous versions' Plugin SDKs you'll need to configure the location of Liferay in build.yourusername.properties in the root folder of the SDK. (replace yourusername with the actual name that you're using to login to your development machine). The configuration you need is stated in the dialog.
focus on error message, please make a file name with your [USER-NAME] like this "build.[USER-NAME].properties" (ex: build.sam.properties) contain bellow properties and put in Liferay SDK path
(I put it in eclipse/plugins/com.liferay.portal.plugins.sdk-7.0/
contain:
liferay.dir = C:/
app.server.type = tomcat
app.server = tomcat-8.0.32
app.server.parent.dir = ${liferay.dir}/liferay-ce-portal-7.0-ga3
app.server.tomcat.dir = ${app.server.parent.dir}/${app.server}
app.server.portal.dir = ${app.server.tomcat.dir}/webapps/ROOT
if you are using wildfly server, use the following in your build.user.name.properties file. (Location ex: C:..\com.liferay.portal.plugins.sdk-7.0)
app.server.parent.dir =C:/../liferay-ce-portal-7.0-ga3
app.server.type=wildfly
app.server.wildfly.dir=${app.server.parent.dir}/wildfly-10.0.0
app.server.wildfly.deploy.dir=${app.server.wildfly.dir}/standalone/deployments
app.server.wildfly.lib.global.dir=${app.server.wildfly.dir}/modules/com/liferay/portal/main
app.server.wildfly.portal.dir=${app.server.wildfly.dir}/standalone/deployments/ROOT.war

Trying to modify Liferay's classic theme is behaving rare

I have a Liferay 6.1 instance with a custom classic theme, but trying to upgrade it to 7.0 is being so painful that I decided to take Liferay 7's classic theme (downloaded from here).
To bring it into Eclipse - Liferay IDE I created a new module (theme) project and imported files, but trying to deploy it was sending errors (for example, no init.ftl, stuff like that, unexpected given I am using the repo source).
When I arrived to this error, solved it and tried to deploy, it again said there's no init.ftl... Then I searched for it into the war and it actually wasn't there! No idea about what but... I noticed a portal_pop_up.ftl that doesn't exist in my source code!!! What is going on? I'm pretty confused.
Thanks!
Ok, the problem was with code downloaded from Github.
If you want to use classic-theme, just create an "empty" theme in the IDE and then overwrite it's files with the ones from auto"deployed" classic-theme in the L7 instance, in /opt/liferay/osgi/wabs.

where is war exploded in Liferay 7 tomcat after getting copied in osgi folder

I deployed a portlet in liferay 7 and it got deployed successfully and was available for use. I want to replace the jsp file, in earlier version I could see my application in tomcat/webapps folder and replace it quickly.
Now I am unable to locate the exploded war in liferay 7. I can only see the war in osgi/war folder.
Can someone help me with that.
Thanks in advance.
While I mostly agree with what Olaf wrote, I do understand the need to be able to make changes in JSP files and try them quickly during development. I'm afraid I don't have the solution for that yet.
However, let me answer the question you asked:
where is war exploded in Liferay 7 tomcat after getting copied in osgi folder
It is NOT (at least not the way it was done by application servers)! When you deploy a WAR file in Liferay 7, it will automatically (on the fly) convert it into OSGi bundle and install it in OSGi runtime. This way now Liferay is fully in charge of deploying plugins and does not need to rely on various application servers.
PLEASE NOTE: Every bundle has it's own state folder. In Liferay those are in <LIFERAY_HOME>/osgi/state. If you know the bundle ID you can easily find it. It may be (I haven't checked) that you'll find some JSP files there. The reason I'm writing this is to warn you (in case you figured it yourself) to NEVER modify bundle's state folder manually. Doing so may brake the whole environment. In worse case scenario you may have to redeploy everything in clean environment.
You should not rely on behavior like this. In previous versions it was the task of the application server to compile changed JSPs at runtime. However, this is bad practice in production systems and totally screws up your maintainability. If you need to update some UI code frequently, I'm suggesting you change your implementation to utilize ADT (Application Display Templates), e.g. through Freemarker or Velocity. Those are meant to be updated at runtime, where the JSP updates were a side effect of Tomcat's default (development friendly, production hostile) configuration

Changes to init_custom.vm not showing up

I'm building a new Liferay theme and being crushed by this problem.
When I make changes to the init_custom.vm, the only possible way for me to see the changes is to restart Tomcat. When I make other changes to my theme, such as editing my CSS or adding images, I can see the changes after deploying the theme via the Ant Deploy target. No such luck with the templates.
I checked the $CATALINA_HOME/webapps/my-theme/init_custom.vm after deploying, and that file does reflect my changes.
I cannot continue to develop if this is going to be the cycle. I must be able to make changes to the velocity template without requiring a restart. Any suggestions?
I'm using the Eclipse Liferay IDE and the Ant build to deploy my theme when I make changes. I'm using the Liferay 6.0.6 Tomcat bundle. I've also already added include-and-override=portal-developer.properties to my portal-ide.properties file.
Thanks!!!
(also asked this in the Liferay Forums, and I'll make sure to copy back any answers I get: http://www.liferay.com/community/forums/-/message_boards/message/11292911)
Liferay also caches everything Velocity related which sometimes can present itself in the way you describe: changes to templates don't seem to show unless you restart Liferay. You can turn off this behavior if you set the following property in your portal-ext.properties file:
velocity.engine.resource.manager.cache.enabled=false
I switched to the 6.1 Beta and do not have the problem on that release, so it was just with 6.0.6.
Also: I've seen How to edit a velocimacro without restarting velocity? and Testing JSON API in Rails 3.2 using rspec using exact PUT/POST bodies as Backbone would send and they did not work for me. Upgrading to 6.1 beta did, for some reason, work.

Liferay 4.2 to 5.2 upgrade question: How to predeploy portlets in Liferay 5.2

We are upgrading from Liferay 4.2 to Liferay 5.2.2. We are using the EXT environment. Previously, in 4.2 there was a directory called /ext/portlets. According for 4.2 doc,
"Portlets placed in this directory will be automatically deployed to the application server when running the ant deploy target from the /ext directory"
Is there an equivalent for 5.2?
At first I though that /ext/modules would do the trick, but it looks like the build file inside of /modules just unwars my portlet war file. This is not sufficient to deploy the portlets, since Liferay needs to augment the web.xml in my portlets' WEB-INF to insert servlet mapping tags.
Just for comparison, 4.2's build file in /ext/portlets directory, would call com.liferay.portal.tools.PortletDeployer and pass my war file as an argument.
I looked around, the PortletDeployer still exists in the 5. 2 code base. It is now located in com.liferay.portal.tools.deploy, but it is not called anywhere from the build files. . I wonder if this means that there is no longer a way to predeploy portlets in 5.2 Liferay. Does Liferay have to be up and running to deploy in 5.2?
If your portlets are bundled as war, and are not required to run in the same webapp as Liferay, just put your wars in the liferay deploy dir. This directory is defined in your portal-ext.properties file, and overrides the bundled portal.properties file definition of
auto.deploy.deploy.dir=${liferay.home}/deploy
At startup, Liferay scans this directory and installs any found "plugin" (portlet, theme, layout, hook...).
You may be interested in the plugins SDK for the portlet and theme creation as it could help you separate portlet developpement and core portal extension.
You should also be careful regarding your theme, it may require migration to comply to the 4.3 onward themes.

Resources