I need to make an upgrade of Liferay, as mentioned above(5.2->6.0) So far, as my research (1,2,3) shows I need to:
Make backups of the Database and file system of plugins (especially portal*.properties).
Overwrite dependency jars
Deploy new .war
Set permission algorithm to 5 in the properties (as L-5.2 uses it, however L-6.0 uses 6)
Start application,
see if the DB updates correctly
see if the portal is working correctly
Clean up user-specific permissions
Convert legacy permission algorithm to 6 in the control Panel
Migrate a custom theme.
Upgrade EXT to EXT Plugin(p. 398)
It's fairly understandable, but I stumbled upon this thread(Missing FileEntryForm class). Are there any more changes of this kind?
Also, is there something else I'm missing?
Thanks :)
Related
I have a uCommerce package installed for my sitecore. The problem exists when you start editing template items under sitecore/templates/User Defined/uCommerce definitions/. When you restart IIS or recycle application pool (apparently this happens after solution rebuild) the template items reset their values to the fixed one. What could be causing the problem? Is there any cache mechanism which could be causing this?
update: have checked the sitecore database, the field values are being saved and stored in database properly after iis reset/pool recycly, so there is pretty much confidence that it has to do something with caching
The UCommerce DataProvider (UCommerce.Sitecore.SitecoreDataProvider.DataProviderMasterDatabase) automatically adds the templates under sitecore/templates/User Defined/uCommerce definitions at start up so they will always be reset after each recycle.
First off, make sure that you are making your changes in the Master database and not the Web database. If that is not the issue, then try the following while logged into Sitecore as an administrator:
Go to http://yourdomain.com/sitecore/admin/cache.aspx
Clear the Sitecore cache
Go to the Master database's content editor and look at your templates
Make any changes necessary, save and publish
Do your IIS restart / application pool recycle (the latter occurs on every build)
Go back to http://yourdomain.com/sitecore/admin/cache.aspx
Clear the cache again (just a base-case)
Go back to the Master database's content editor and look at your templates again
If the issue occurs after trying those steps, then you should open a Sitecore support ticket and see what they say. You may also want to try making a clean install of Sitecore and trying to reproduce the issue there (Sitecore Support is likely to do this as well).
The problem was that the standard values template presentation layout I have been updating was the english version. However, there was another language version set and the layout for that version was different. When uCommerce is resetting the template on application pool recycle it doesn't take into the account the multilanguage support, so the last retrieved language version of that fieldvalue is used as reset template and that different language version with different layout was used. A partial workaround is to use the same layout for all the language versions.
Very general question here:
I have Liferay 6.1.1 ga2 set up on my Oracle WebLogic 12c.
It works fine on my local, but when I deploy it onto our development server, I lose all write permissions.
E.g., changing the theme/color scheme, creating web content, pages, and saving changes to most things
I try to import LARs however it is saying it is not permitted
I'm not seeing any errors in the logs, and the control panel messages are even telling me my content was created or change successfully (besides the LARs0, but everything stays the same.
Any reason(s) why my changes aren't showing up? I'll surely give a bounty if I can get pointed in the right direction here
Given your description, I'd recommend checking OS issues, like write access to various folders, like temporary folders etc.. I guess that Liferay has proper permissions to the whole database (it's rare to have incomplete access) and can write to all tables. And you're operating on a portal-wide admin account, right?
Unrelated to LAR import, changes will not show up if you have workflow enabled - then you'd find the changes in the list of tasks that need approval.
As staging has quite an obvious UI in 6.1, I assume you don't have staging activated, otherwise you just need to publish. In order to see new portlets, make sure that the "Edit Controls" checkbox in your dockbar is checked. This has bitten me more than once.
if you're running a cluster, make sure that you have set it up correctly, e.g. that you don't see cached content on your node.
Can you confirm that you can see the options to change on the UI, just that your changes aren't persisted?
Also, please note that Weblogic 12c is not on the "supported Appservers" list for Liferay 6.1, it's there for Liferay 6.2 only (probably due to release date). This doesn't mean that it shouldn't run, just that it's not tested for your version. Further, there's a GA3 release for 6.3 already, so you might want to check if it's a problem that's fixed in GA3.
I'm working with multiple Liferay Projects (different Portal, plugins, user and usergroups etc ) in the same time, and often have to switch between them. This switch requires lots of steps like
Editing the portal-ext.properties (to change the Liferay Database, and edit some custom project-specific properties), and edit 'portal-setup-wizard.properties'
Add/remove portlets themes and hooks from the Eclipse Server instance, sometimes clean the Tomcat's 'data' 'Webapps' and 'work' folder
Go to Liferay's Control-Panel/Server/Plugins Installation and re-index portlets like 'Users and Organizations' or 'Documents and Media'
So, I thought that creating a new Server Instance for each project, with a new tomcat and JRE, would be a nice idea. When I had to switch project, I could just stop the old server and start another. At first, I thought (was adviced actually) that using the same Liferay Plugins SDK (6.1.0), should be ok, as long as the Server instances are the same version.
Practically this doesn't work 100% perfectly. While most of the work is getting done, there are some problems here and there, like a theme not getting deployed propertly, hooks not beeing applied etc. As I understand, there is some [Liferay SDK] - [Liferay Server] binding, and that means that only 1 Server (the first one I created) will fully work.
For example, By investigating the [Liferay SDK folder]/bild.[user name].properties, I can see some properties that are referring to a specific Server/JRE location :
app.server.portal.dir
app.server.lib.global.dir
app.server.deploy.dir
app.server.type
app.server.dir
So, my question is, what should I do to work with multiple Liferay Projects ?
Is the multi-Server practice, a good approach to work with multiple-projects ?
If yes, should I create a different SDK for each Server? Maybe a different Eclipse workspace too ? Or is there some way to use the same SDK
What about working with Servers of different Liferay Version ?
Personally, I set up every project with its own source, tomcat, database, etc. even if it means duplication. These days storage is cheap and makes this possible. Of course your milage may very but I thought I'd share my setup with you.
I have a project directory with all my projects which looks like so:
/projects
/foo-project
/bar-project
/my-project
Inside a project I have
/my-project
/tomcat
/bin
/conf
...
/src
/portal
... my portal source ...
/plugins
... my plugin source ...
/portal-ext.properties
I then setup tomcat to use different ports (8080, 8081, 8082, etc...) so that I can just leave them all running if I have to or want to.
I setup Liferay to use different database for each Liferay instance.
I place the portal-ext.properties as a sibling to the tomcat directory and Liferay will read this file (assuming the default behavior). This offers quick and easy edits as well as figuring out how you've set each project up.
The advantages should be clear. You can just "walk away" from a project and into another without tearing down and setting up. And when you return everything will still be as you left it. Context switching is also quicker and helpful if you want to answer a question about a project you're not yet working on.
Depending on the complexity of each of your projects, multi-instance might not work for you. Hooks and EXTs may conflict with each other and it appears as if this is already the case with your projects.
If you can afford the space (which is not much) this has been the fastest way I have found as a Liferay developer.
If we start working on a new Liferay project in our company, we setup:
a new database schema,
a new, clean Liferay server connected with that schema and
a fresh Eclipse workspace, with
a clean SDK project
Only this way you're sure to have cleanly separate projects. To switch to another project, just shutdown the current Liferay server, startup the new one and switch to the right workspace in Eclipse. This all takes no more than 2 minutes, a lot less than to do all the cleanup actions you have to do if you share workspace and server.
In my opinion, this is the approach of most development teams.
Why mess with all these complications in a single computer? I use Oracle VirtualBox and set up a separate VM for each project. Even though I work on a laptop, it has 8 cores, and I've bumped my memory up to 16GB and set each machine up with 4GB of RAM.
I can have multiple VMs running at once and have set all active projects as home pages in Chrome. Using bridged networking each VM has its own IP address, and they all listen on 8080.
Another benefit is that, although my primary project is being developed using Eclipse Indigo and LR 6.1 CE GA1, I have another using Eclipse Juno, its specific IDE plugin and LR 6.1.1 CE GA2. So it also works as a new version tester.
VirtualBox is free. Memory is cheap. And remember that you can put a VM to sleep without shutting it down. That takes about 10-20 seconds and waking it up again takes 30-60 seconds.
The simplest solution would be :
Create 3 different users, the Liferay SDK's bundle.properties file is separate for each user. So, lets say, if you want to run 3 servers with the same sdk. Create 3 files like
bundle.user1.properties
bundle.user2.properties
bundle.user3.properties
Now, when you want to deploy something for server 1, log in the server using user1 and try to deploy the portlet, this will read bundle.user1.properties and it will deploy the portlet/hook to the specified location.
Hope this will resolve your deployment issue.
Also, when you have 3 users, you can run 3 different servers together in a different user accounts, in this way, they would be secure and apart from admin, nobody can shutdown the same.
Hope this helps!
The following issue just crept up on me. The steps mentioned below had worked just fine until about 2 days ago.
When I deploy a update to a solution (of web parts) to a SharePoint 2010 server I don't see the update. The solution does get installed, but from what I can tell the installed web parts are over a month old (nothing new is installed).
I do the following steps through PowerShell:
retract the solution from the web app
remove the solution
add the solution
install the solution to the web app
I have tried restarting the Web App, restarting IIS and also restarting the server. Nothing seems to work.
I notice that after I remove the solution it does get removed from the GAC. After I add/install it the solution does reappears in the GAC.
Am I missing something? Am I overlooking a step that I should be doing? Something to try?
I never deactivated/reactivated the Feature.
After following the same steps I mentioned in my question I just deactivated, then reactivated, the Feature and everything started to working fine.
This is an easy thing to I can start to implement with my solution updates. However, why did I never have to do this step before?
In general, you should check your ULS log to see which version of your solution is running. If you see the old one, then you can be sure that your activated site feature is still bound to the old version. In this case you have to Inactivate the site feature indeed to loose that tie and then Activate to bind to the new one (it appears Activate always ties the site feature to the newest version of the solution).
Maybe you had not to do this earlier, because you did not change the version number of your solution, appearing as the same version in GAC on the server. In this case you had your site feature already pointing to the correct version of your solution, therefore didn't have to reset the feature.
You have probably checked, but just in case. Make sure that the powershell script is not adding a month old package.
Is the problem in the web part code or the configuration? The configuration usually unghosts itself sooner or later and refuses to update from the solution - you can update the file in the gallery manually if anything has changed there. For most updates there won't be any changes because existing web parts won't get updates applied anyway - they will use new code but old configuration.
If the problem is the code itself, does the assembly appear to the system to be unchanged? All the hardcoded full name references in SharePoint config files mean that usually you are deploying a new assembly but with the same version numbers. This can mean that the system doesn't bother making the update. I have found it very useful to update AssemblyFileVersion (which does not affect binding) on every build and have a page in _layouts that displays the file versions of all the loaded assemblies so I know exactly what is running.
Im new with liferay have a problem with portlet deployment using the plugins sdk,
Platform:
liferay-portal-tomcat-5.5-5.1.2,
liferay-plugins-sdk-5.2.2,
windows vista.
Problem:
I have successfully created a sample portlet with ant and deployed it into the hot-deploy folder. It is automatically picked up by the server but the console messages say that the portlet has been copied successfully and never registers it.. and i cant find it in the add application drop-down menu.. pls your help will be very appreciated.
I don't know if anything important changed in these versions, but you say you're using Liferay 5.1.2 with the plugin environment 5.2.2 - try with matching versions - at least on the second digit.
also, make sure that all required files are available - among them are WEB-INF/web.xml, WEB-INF/portlet.xml.
Create a new sample portlet with "create.bat" in the plugin SDK's portlet folder and deploy this - it should succeed. Then make sure that all config files from the new one are present in your current one.
How did you create your current portlet? What did you do/change?