I want to know how to apply the issue changes done in the Liferay Issues can be applied in our portal.
For example my issues are cleared in the following links,
https://issues.liferay.com/browse/LPS-14417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
https://issues.liferay.com/browse/LPS-14220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
I want to apply the issue changed in the above links in my portal.
Please some one help me to achieve this.
Thanks in Advance.
Regards,
Dinesh M K
You have to see the resolution and fix version stated.
the second issue says :
Fix Version/s: --Sprint 12/11, 6.1.0 CE RC1
and that means that the issue was solved in all Portals after version 6.1.0 CE.
the first issue , is no longer reproducible, and duplicate of https://issues.liferay.com/browse/LPS-14220 which is again solved in 6.1.0 CE RC1
In other words, If your portal is older than this version, you can't do anything. You'll have to upgrade to version 6.1.0 RC1 or later
It seems that the fixed-in version is a bit weirdly set in those issues - e.g. LPS-14220 is a subtask of a story in LPS-14414, which is stated as completed for 6.2.0. Careful: I did not fully read through all of the issue's descriptions, links and mix what I read with the answer (and comment to) #yannicuLar gave
Basically, this seems to be a new feature. The way to backport it to your installation is to identify the relevant commits (e.g. download the repository from https://github.com/liferay/liferay-portal or https://github.com/liferay/liferay-plugins, identify the relevant commits (they all contain the LPS number), "backport" them (e.g. see if they can just be applied to your codebase or if they need manual adaptation because the whole code changed.
Some features are easier to backport than others, I can't tell about the complexity for this one.
In order to separate your changes from Liferay's core changes, you should try to implement this in plugins (or patched plugins) rather than changing the original code and recompile. Most likely it's only the kaleo-web plugin that's effected, but if there are core changes, you'd be better of having them isolated in plugins.
The simplest (and most futureproof) possibility is to wait a bit for 6.2 (RCs are already out) and upgrade your portal to this version. If you want to stay on a version that gets updates, you should do this soon anyway.
Related
We build our installs\releases using Install Shield. I have come to a situation where we have a patch that cannot be upgraded by a release with a higher version number, that is missing components included in the patch.
After releasing a full minor release (i.e. 7.2.0) we released a patch on a previous full minor release (i.e. 7.1.12).
The Patch 7.1.12 had files and components added that do not exist in 7.2.0. The patch is not uninstallable.
It is now impossible to upgrade 7.1.12 to 7.2.0 because of the missing components. Some customers specifically want to upgrade to 7.2.0 and not a later version (7.3.0) where the components can be added to fix the issue.
Short of uninstalling 7.1.12 and then installing 7.2.0 I couldn’t find any solution to fix.
Is there any way around this? Can we build a 7.1.13 as a bridge to somehow fix the mistake. Or use an argument when installing 7.2.0 to get around this.
I looked around the registry and I am trying to figure out if it is possible to remove the components through the registry.
I tried deleting the component entries in the registry. that didn't do it.
If I delete the product entry in the registry that works - but it must be overkill.
I also tried deleting the patch msi from C:\Windows\Installer but that didn't do it.
There must still be a way to unlink the component from the feature in the registry without deleting the entire product.
It sounds like you're trying to do a series of Minor Upgrades, with at least 7.1.12 delivered as a patch. Using minor upgrades imposes various limitations; anything that requires you to Change the Product Code must be avoided. In your case, note that adding components is allowed, but not the reverse:
The update can add a new component to a new or an existing feature.
The product code must be changed if any of the following are true for the update:
A component is removed from an existing feature.
In short, any modifications to the feature-component tree, other than the addition of new ones, is going to require changing the product code, and thus a Major Upgrade. Major upgrades perform an uninstallation behind the scenes, and thus are less restrictive about the changes they are allowed to deliver.
You have two options:
Use a major upgrade, or some other means of uninstalling the old installation before installing the new version. If possible, this is what I would recommend. Using minor upgrades often adds more difficulty than benefit (though your needs may differ).
Maintain the new components in your newer versions. Note that you do not necessarily have to maintain the resources within them:
The update can add, remove, or modify the files, registry keys, or shortcuts of components that are not shared by two or more features.
But you will have to make additional changes to account for the changes to the resources. In your case, this probably will require additions to the RemoveFile table, and may be best served by "puncture component" pattern.
Spelunking through the registry for a workaround that modifies Windows Installer's bookkeeping is a bad idea. It may work, it may appear to work, or it may not work at all. In no case is it supported.
If both versions 7.1.12 and 7.2.0 are already publicly released, you're in a rough spot. I think your best bet there is to re-release 7.2.0 with a new product code and version, e.g. a 7.2.1 major upgrade. You can advise your end users that those already at 7.2.0 don't need to install it.
My current version of Liferay (6.2) has Alloy UI with few bugs.
Those bugs are repaired in newest version of Alloy Ui. Is it possible to use newest version of Alloy Ui instead of the old one?
Thank you.
I think it's possible, but there's a good chance, that you have to do extensive testing before doing it on your production environment and possibly some hand work also will be needed to make it work (if there is major version change, I think it won't work anyway because of the huge changes in the code base).
I'm going to upgrade my company's subversion server from version 1.6 to 1.7. The server runs on linux (Ubuntu AFAIK).
I've read all those:
Subversion 1.7 release notes
I've also read those posts:
subversion-client-version-confusion
how-to-upgrade-svn-server-from-1-6-to-1-7
Here and now, I know how to perform this. It's not a big deal. What concerns me the most is the current hooks infrastructure. There are several scripts in bash and perl.
As for now I've found no information referring hooks infrastructure changes, but maybe there are some known issues I missed? Is there anything against the upgrade I should know?
PS: Try and see what comes method is absolutely unavailable. I'd like the upgrade to be as fluent as possible. Repository users shouldn't even notice any changes. I can't allow myself any failure in that matter.
The Subversion compatibility guarantees promise that your hook scripts are called exactly the same in 1.6 as in 1.7. In 1.7 (and future versions) more arguments can be passed to scripts, but the old arguments still match the old behavior. So if you created your scripts like the templates, to ignore 'extra' arguments you shouldn't see a difference.
Subversion 1.7 didn't change the repository format since 1.6, so you can even (accidentally) use the svnlook from 1.6 to access the repository after upgrading.
Try and see what comes method is absolutely unavailable...
Yes, the try and see what comes method is available. You build a copy of your Subversion 1.6 environment, make the Subversion 1.7 changes, and test until everything is correct.
I don't see how you can accomplish your goal of a quiet upgrade unless you copy and test.
I guess it depends what you do with your hooks...
If your hooks are using svnlook, you should have no issues. If you're using an API (like the Python API), you probably are also okay as long as you're doing svnlook type of stuff.
Where you might start heading into problems is if you poked and prodded where you weren't suppose to poke and prod. For example, instead of doing svnlook, you do svn. There are a couple of places where the parameters have changed. Also, if you did an svn checkout (an absolute no-no in a hook) and then looked in the .svn directories, you'll get a surprise. Follow the rules, color in the lines, and your hooks won't have any issues.
I don't know of any issues from Revision 1.1 to revision 1.7 that should affect well behaved hooks hooks, and I suspect that you will not have any issues as long as we are still in Subversion 1.x. When Subversion 2.x comes out, all bets are off.
Yes, there have been some changes in how hooks work. The start-commit hook has an extra field that wasn't in versions 1.4 and earlier (The capabilities field), but nothing that would affect current hooks. And, in either Subversion 1.5 or 1.6, users now can set revision properties when doing a commit. These don't affect current hooks, but might be features that you want to incorporate in your current hooks.
The upgrade has been performed and succeeded. Subversion server was updated without issues. Hooks were designed without any hacks or slashes, respecting the rules and common sense. It was risky but promising and came out profitable (checkouts are light-speed now).
Just for sake of completeness: there was a consecutive centrally managed client upgrade. And there were issues, however not critical and predictable. After transition svn client 1.6 -> 1.7.7 working copy format changed. Every existing working copy had to be manually upgraded (or wiped out and checked out clean again).
Server upgrade is safe though.
I've recently upgraded my Orchard site to version 1.4. Since I had an source code enlistment I just updated to the latest Default branch, and built and deployed the new version. Since the deployment, my blog is totally missing. Thinking it had something to do with the new Autoroute feature, I enabled the Migrate14 module and migrated to 1.4, but still the blog is totally missing in both the Admin UI and at the site.
Do anyone have any ideas on what might have gone wrong?
Check if you have "Blog" feature enabled, this is the first thing.
Second - please check the logs in /App_Data/Logs for any exceptions being thrown and paste your findings here. This could give us a bit more detail.
Third - try upgrading your source to recent 1.x branch. I've been setting up a site using that one yesterday (also upgraded to 1.4) and everything went smoothly.
See this answer's comments for more information related to solution.
We have a liferay portal running on a hosting company, and We want to bring it to our own structure. So, I've downloaded the excellent bitnami stack and loaded it in our vmware server.
I've no experience on liferay whatsoever, all I know its that it uses mysql as database. Is there any docs on how to do it?
Tks!
Use the Liferay's Wiki:
5.0 to 5.1: http://www.liferay.com/community/wiki/-/wiki/Main/Upgrade+Instructions+from+5.0+to+5.1
5.1. to 5.2: http://www.liferay.com/community/wiki/-/wiki/Main/Upgrade+Instructions+from+5.1+to+5.2
I recommend to do a 2-step upgrade since direct upgrade from 5.0 to 5.2 is more troublesome.
There have been reports that it's some work to upgrade older versions to the latest and greatest, so you should be prepared for some efforts.
That said, the way you should go is to backup the previous installation (e.g. all directories, database entries etc) and deploy that on your own server. This installation then is updated to the latest version by installing the latest version and pointing it to the data from the previous installation. During the first startup, liferay will (given sufficient privileges on mysql) update the database structure and everything it needs. Keep your backup ready and test thoroughly if everything is upgraded the way you intended it to be.
Also you need to keep an eye on your customized stuff - if you have portlets or other components that use the liferay api, you might need to upgrade those manually to take changed APIs into account.
Theoretically that should be it. I've heard of people having had some problems with this - but it all depends on your level of customization and utilization of features in liferay.
The liferay folks intend to circumvent this in future with their EE environment, where you get better defined upgrade paths and long term support with minor upgrades to your environment, keeping APIs and database requirements stable. I'd hope that even upgrades between major versions will benefit from this, but have not yet tried it.