I am using Liferay 6.1.1GA2, which includes YUI 3.4.0. As of this posting, the YUI library is currently up to version 3.8.0.
Is there a way to upgrade this library within Liferay so that I won't have to include the newer version inside each portlet I deploy? I can see including the current version on top of the Liferay version leading to problems very quickly.
Related
I started to read about wicket integration with liferay. I found very old information that wicket portlet is no longer supported, but wicket version 1.5.6 works fine with liferay 6.0. What about Liferay 6.2?
Just yesterday a user from the community created a Pull Request to fix the support for Liferay: https://github.com/wicketstuff/core/pull/476.
The Pull Request is for WicketStuff 7.x though. You are very welcome to port the fixes to wicket-6.x branch and we will add them for WicketStuff 6.23.0.
WicketStuff 1.5.x is not maintained anymore.
Apache Wicket version 6.x, 7.x and 8.x supports JSR286 portlets.
Please see the following wiki of how to use the apache wicket portlet bridge.
https://github.com/wicketstuff/core/wiki/Portlet
I am currently working on a project in Orchard. We are looking to wrap up an existing .NET MVC Web application within an Orchard Module. Currently, we are having issues with AutoFac.
The original site was built using AutoFac 3.5, however the latest stable version of Orchard is still running on 3.0. The application requires features introduced in 3.3. If I install 3.0 into the module, the features do not work, if I have 3.5 in the module, it produces a conflict.
Can anybody suggest a way of handling this conflict? Or, is it safe to upgrade AutoFac 3.0 in Orchard and if so how should I perform this without breaking it?
Thanks,
If I may suggest, Orchard 1.9 should be released soon™ and it already has dependency on latest stable Autofac 3.5.2. If you don't want to wait you can grab latest repository from GitHub
https://github.com/OrchardCMS/Orchard/tree/1.9-int
It's perfectly stable in my opinion and I find released 1.8.1 to be much more buggy :D.
Copy the web.config file runtime Node from Existing Module (Lucene or Markdown or like) and add the runtime node on conflicts Module Web.Config file. After Compile then clear the Conflict
I have a portlet that worked fine on Liferay 6.1 portal but when I deploy it on Liferay 5.2.3
my configuration page did not even open.
How should I make it work ?
Here is a nice authoritative answer to a very similar question.
The portlets of newer versions are not designed to work on older installation of Liferay. Since they are compiled using the latest plugins-sdk and the also the different jars which have changed since the last version.
So if you want the newer version portlet to work with any older version then you have to compile the portlet with an older version of Liferay with that plugins-SDK. And I am sure there would be a lot of classes and jsp-tags in the Liferay 6.1 portlet which would not work in Liferay 5.2.3.
I am upgrading Liferay from 5.2 to 6.1. I want to know similar to core liferay, for theme also we have to follow two steps up-gradation (i.e from 5.2 to 6.0 then 6.0 to 6.1) or we can directly go for 5.2 to 6.1 theme upgrade.
The theme doesn't require any sort of upgrade process so you'll only need to rewrite it once.
Basically you'll just need to make sure that the theme is using 6.1 API and AUI.
The most complicated of the two being migrating from jQuery to AUI (YUI).
Here is a "rosetta stone" to get you started: http://www.jsrosettastone.com/
The upgrade is not like the core liferay.
Steps (more of a check-list) to look for when upgrading themes:
1) You have to change the liferay-look-and-feel.xml's <version>6.1+</version>.
2) You would need to manually include jQuery, as now it is not part of Liferay (Alloy UI is now a part). You can include them through the template files (*.vm).
3) There are a lot of customizations in the template files (portal_normal.vm, portlet.vm, navigation.vm etc) from 5.2 to 6.1, so if you have done customizations to these then you would have to again customize them.
4) Also a lot of CSS changes have happened since 5.2, infact 6.1 UI is almost completely different from 5.2. So you will have to again style liferay html elements as it now uses alloy UI JSP tags to render them.
Hope this helps.
For a project we want to use dojo 1.7.2. I downloaded the version and unzipped everything to a directory.
I added the ibm directory from the js\dojo.1.5.1 directory of my 8.5.3 domino server.
And package all the files as a executable jar file.
In Domino 8.5.3 dojo 1.6.1 is loaded as OSGi bundle and is located in the \osgi\shared\eclipse\plugins
Is there a way to use the newest version of Dojo as OSGi bundle, the same way as dojo 1.6.1 is deployed??
Does your plugin define a Dojo version. I'm looking at the explanation for how the Domino 8.5.3 plugin defines the Dojo version on Page 40 of XPages Portable Command Guide, the section entitled "Installing Multiple Dojo Versions and Determining the Version Used".
It uses an inner text file in the plugin "/resource/dojo.properties" and a property line:
DojoVersion.versionStr=1.6.1
If you define a higher version number in your plugin, I believe that should get used by default. Alternatively, you should be able to define a different version number and use the xsp.client.dojo.script.version property in xsp.properties.
Have you tried xsp.client.script.dojo.version?