We just upgraded our Movable Type 4 Installation to Movable Type 5. One plug-in we were using is called Promote This. It hasn't been upgraded to MT5. Although it seems to work, the dashboard gives us a warning:
This plugin has not been upgraded to support Movable Type 5. As such, it may not be completely functional.
uses: MT::Template::Context::add_tag, should use: Registry (path: tags, function)
I really haven't programmed Perl for years. Is this a hard thing to fix?
We created a version of PromoteThis that is compatible with Movable Type 5 in order to facilitate upgrades of older Movable Type-based sites, and
in order to avoid continued use of Movable Type 4. Movable Type 4.38
is going End-Of-Life at the end of 2013.
We have successfully deployed this updated version on a site that we upgraded from MT 4.31 to 5.2.3, and I am not aware of any problems.
Feel free to try it and submit any bug reports to the repository if you find any issues that need to be addressed.
I will submit a pull request to Byrne Reese, so that his repository has a more current version.
The author is Byrne Reese and I'm pretty sure he'll gladly update his plugin (it looks like a trivial change IMHO). Have you asked him?
Related
Wanted to play around with Bloc (basic minimum: create a BlElement), followed the basic instructions to fetch the packages here:
Metacello new
baseline: 'Bloc';
repository: 'github://pharo-graphics/Bloc/src';
load
I see the Fetching... being performed and succeed, and then see the Loading baseline... and Loading Bloc progress bars, but then I get thrown into an error:
This package depends on the following classes:
Key
You must resolve these dependencies before you will be able to load these definitions:
Key>>#a
Key>>#arrowDown
Key>>#arrowLeft
Key>>#arrowRight
Key>>#arrowUp
Key>>#b
Key>>#backspace
Key>>#c
Key>>#character:
Any clues?
Update #1:
As it turns out, I should have really read the README, which states pretty clearly that the repo is discontinued.
As Leandro pointed out below, the repo relies on classes (such as Key) that were deprecated after 7.0 (and I can verify that the above worked for me in 7.0)
OTOH, the following, recommended at "the new repo" in 8.0, fails for me with the same problem.
Metacello new
baseline: 'Bloc';
repository: 'github://feenkcom/Bloc/src';
load
Update #2:
After loading a fresh version of Pharo 8.0, the Metacello ... load works for me (my previous image was clearly ... put into a bad state by trying to load the older, invalid version, and now I have to figure out how to undo that damage, but that is a problem for another day).
So, all good now, but I hope the Bloc "booklet" is modified to represent these new version constraints.
Not sure whether this helps but the problem is that the class Key belongs to a deprecated package, namely DeprecatedFileStream.
I was able to load Bloc on Pharo 7.0, where the deprecated classes were still available. Note that in 8.0+ those classes are no longer available.
I'm not a Pharo user, so I cannot provide you with a solution.
That is not the only thing you need. You'll need a different vm and the skia library. It is easier to start with gtoolkit.com to see what you need and how it is built. The vm has some modifications that are not atm in the Pharo vm, for headless usage and no morphic event loop. Skia is used for rendering. In the different github repositories of feenkcom you can find the details. The rendering of bloc to morphic is deprecated.
On the website of Debian, it's written about point releases:
They usually incorporate the security fixes released until the time of
the update and fixes for grave bugs in the current release.
If I correctly understand, that means only minor updates can occur in the packages of the current stable version, right?
In other words, I want to know if a binary who depends of a library in a specific version (libmicrohttpd.so.12 for instance) will stay compatible in the next point releases of Debian.
Yes, but it is very seldom.
In general you are right, the point releases should not change existing API and ABI.
But there could be problems on doing that: security changes would require a lot of work, and upstream will do only for the new version. In such cases the version will be dump. But this is very seldom: it would need a security bug which effect the fundamental design of a library (not just some coding error).
In any case the old version will remain on archives, and you can keep it (so that it would not be automatically removed), so that you can still use, hopefully with relevant safe guard.
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 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.
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.