I'm looking for simple way to update custom translations in Liferay without redeploy of language hook. Restart is no option for me too :).
UPDATE:
The customer has quite big portal with about 50 different portlet-applications. Each application has rich user interface in four languages. Together the portal has about 800 keys that must be translated.
For this translation work the customer has specific department that works with appropriate tools. This tools can generate Liferay compliant property files.
Furthermore, by 800 key-words / translations, that is frequently necessary to change the translation.
Hence, I'm looking for method to update UI translations live - on the fly. Without redeploy of language-hook and without restart the Liferay.
If you're thinking of translating the content that you already enter to your portal, that's already changeable through the UI, no hook or anything necessary. However, as you mention hooks I believe that this is not what you're looking for.
Redeploy of a language hook is the simple option to update the application's language (i.e. Liferay's own UI). You can hot-deploy a language hook without restarting the server. All the other solutions I can think of are at least an order of magnitude more complex and would involve program code that overrides the mechanics how Liferay looks up translated UI elements.
IMHO you can choose either one, "simple" or "no redeploy of a hook". You can't eat your cake and have it, too.
Update (after your update): What I described above is Liferay's mechanism, which you're free to use or to ignore. If your plugins have specific needs that their translation must be updated without the plugins being updated at all, you're free to choose any different language lookup mechanism of your choice. The Liferay mechanism - in this case - might not be what you need to use. Or you'll need to talk to your business users and get their information on how often they believe that the translation will be required to update when the plugins stay unchanged. Or how often they are prepared to redeploy the plugins (and if they can wait for this amount of time)
Related
I am authoring an installer that creates a new website and application pool. This installer is for internal use within several development environments which all have subtle differences. One may use only HTTP, another only HTTPS and one might use both. One might use the default ApplicationPoolIdentity identity where as another may use an explicit User reference.
Given the association of a WebAppPool is by ID through a WebApplication which must be nested under a WebSite, each time an option is desired on the installer, the breakout and duplication of features gets ridiculous.
I imagine I am not the first to encounter this, how does one accomplish this much flexibility within an installer?
The route I went with was creating a basic template within WIX using expected IDs, then used an immediate custom action scheduled before InstallValidate which manipulated the template entries to what ever degree was required. The properties used by the CA to make the decisions are stored in the registry for modify/patch/removal invocations.
I am very new to liferay 7 ,actually we are migrating liferay 6.2 to liferay-7 ,in the 6.2 we are using ext to override the action class but in the liferay-7 I am getting some cofusion,could you please help me out.
The main theme of my ext is : whenever a new role getting created in an organization from the control panel, we need to store the role information and organization information in our custom table for that we have overriden EditRoleAction.java in LR6.2 so same thing we are trying to achieve in LR7.
Action class in Liferay 6.2 :
Portal path :
D:\Liferay6.2workspace\portal\portal-impl\src\com\liferay\portlet\rolesadmin\action\EditRoleAction.java
Ext Path:
CutomRoles-ext/docroot/WEB-INF/ext-impl/src/com/liferay/portlet/rolesadmin/action/EditRoleAction.java
Action class in Liferay 7.0GA4 :
D:\Liferay7GA4\portal\modules\apps\foundation\roles\roles-admin-web\src\main\java\com\liferay\roles\admin\web\internal\portlet*RolesAdminPortlet.java*
It really sounds like overriding the Action is not the right place to go. Look up ServiceWrappers - these will run on the business layer, and you can add additional code to (from memory) RoleLocalService.addRole(...) and other related methods.
Ext was never necessary for this purpose and shouldn't have been used in the first place. In fact, with the use of ext you deliberately make maintenance and upgrades a lot harder than when you go the regular plugin route. And with Liferay 7 and DXP the use of ext should be the extremely rare absolute exception to the rule. In fact, it's just now being reintroduced after being absent so far (because in a few rare exceptional cases it's still the only way). However, it's safe to assume that you don't need it.
Now that the description in the comments to this answer goes much further than the description in the question: You might need some portlet-level customizations as well. For this: Identify where the portlet is currently implemented (e.g. identify the module) and override its actions (there's a good chance that this article can help) and potentially also the UI.
And yet another alternative: You might be able to achieve the same by using Teams in the organization's site: They behave almost like roles but are only available to a single site (no organization though, but you state that your organizations have sites anyway)
My customer wants to provide 2 themes for a SharePoint application. Is there a strategy to accomplish this in MOSS 2007?
We want to apply user profile-based theme selection, and maybe even a drop-down to switch modes.
I don't know how extensive you want your re-theming to be. However if it could be CSS-only you could use this approach:
Store the CSS files for the different themes in the Style Library.
Create a list that stores the user and their chosen theme.
Write a feature and custom application page to allow the user to change their theme.
Write a control that does a lookup on the list against the current user and obtains the a reference to the corresponding CSS file in the Style Library. The control would then output the CssRegistration and CssLink controls to the page for this file.
Add this control to the master page so it executes on every page (caching should be added).
I can't see why this wouldn't be supportable by Microsoft as you're only changing CSS.
If you need to do more than that then another option is to write an HTTP module that changes the HTML output. Or of course JavaScript. With these two options you may have supportability issues (it depends on how extensive your changes are).
There is also SPThemes now available on Codeplex from Bjørn Furuknap. Users can choose their own themes and they can be applied at different scopes.
Here are the options that I’ve come up with from research and feedback. Both of which seem mostly infeasible.
Implement major UI layout changes in JavaScript. This would lead to client slowdowns, would be difficult to code, and would be completely unsupported by Microsoft due to the need to reference SharePoint objects that may change with subsequent SharePoint patches.
Provide two parallel themed sites based on the same data, and provide a way to switch between them. This would require that we deploy each site to multiple locations, and would require retooling of any site creation mechanisms in code (since they'd need to target two sites instead of one).
One another thing you can try is to use the Theme Changer and ThemeChangerStaple from codeplex , That is implemented as feature you can use the same code logic to archive what you want with bit of modification, give it as an option for the user using CustomAction.
So, maybe I'm a bit old-school, but when we created websites in the past, we'd develop the site on a development server, then publish or promote the pages and files to the production server. This has always seemed to be a good way to go so that users didn't see messed up pages or (God forbid) a downed server because one of us screwed up.
But it doesn't seem that Microsoft had this idea in mind when they created SharePoint...at least, I haven't been able to find a way to do this in the infrastructure as it's defined.
Does anyone know if there's a management strategy for SharePoint development? I've read online that we can make a backup of the development environment and restore to the production server. That might work the first time, but any updates to the production server can't do that without risking data loss on the production server. I've seen some tools out there for migrating list contents, pages and documents from one server to another--although, admittedly, I've not yet investigated them.
But, another concern of mine is custom content types. It seems that once a list is using a content type, you can't update it without deleting the items from the list, disassociating the content type, and reassociating the content type. Shouldn't there be some way to UPGRADE a content type?
Anyway, if you have any suggestions for any of these current dilemas, I would LOVE to hear from you.
Thanks in advance,
Dan
Thank you for your quick reply.
We already have several features created for our site and a solution package bundling features directed at the fundamentals (content types, columns, etc), and another solution for features having to do with branding (page layouts, master pages, etc.)
But it seems like this is a one-time-shot...basically, it gets our server set up, right? Once people have started using the production environment, we're going to have documents, pages, list items all existing in our content database, and it'll be impossible to update things like content types, columns.
Features you have to deactivate and uninstall before you can install and activate the new feature, right? I've seen a Version property on the feature definition, but as near as I can tell, this doesn't do anything. Solutions seem like they can be upgrade by incrementing the version number, but it doesn't seem to modify things like content types and columns--especially if they're in use. Plus, I'm not sure how extensive the upgrade with solutions is.
There's precious-little documentation out there for this sort of thing. It seems like everything I'm reading is how to get your SharePoint server set up initially...not managing it long term.
Do you have any advice or suggestions?
Thank you all for your suggestions.
But we've been working on this site for over a year now. I'm pretty confident that we're already setup according to what most of you are recommending. We already have several features that install things like content types, columns, master pages, page layouts, and workflows. Most of these features are contained within solution packages. We have all of our development environments set up as VPC servers.
So, I have the initial deployment pretty much set. What I'm REALLY hoping to find out is how I can upgrade things like content types and columns and stuff down the road. Is it possible to change content types once they're in use? Because it doesn't seem, based on my initial testing, that this is possible. I'm not to worried about the assemblies because it looks like they swap out just fine, but the only way I've gotten a content type updated is by deleting any items referencing them (i.e. all the pages in my pages library), removing the content type, then re-adding it.
Do any of you know if there's a way to update a content type AFTER the initial deployment? ...when users have already created items based on the content types we've already deployed?
(The other part of my question was actually moving existing pages from the development server to production, but I can live without that. My major worry is the content types.)
The best way to go is developing with features. Once the features are done, you ca deploy them with Solution package (called WSP).
The only thing left to do is to reactivate those features. That way, you can progressively roll-out new features without having to do everything in production.
WSPBuilder is an application that helps you build WSP.
For automating all of this... good luck. There is a lot of work involved.
UPDATE:
Deploying Content Types and Columns are tricky. Once the website has been created, you can't update them anymore through features. You need to go through the code and recursively go through all the sites and modify the specific content type that match the name.
We've tried and it's not possible to do that normally with features. This need to go through something I call "deploying with code".
You really really need to define your content types using a feature because that way each content type will have a set GUID and will be stored in the database using the same name. This becomes important when running CAML queries over the site and there are a few other little gotchas when content types are created "will nilly" if you will.
I prefer STSDev for rolling out solutions using custom content types.
There are two ways to edit pages on the server. You can define the page library to have major and minor versions. This allows editors to edit the page and a defined publisher to publish them. This is good on an internal site, but is not recommended for a public facing site.
For a public facing site you will need to use Content Deployment
I cannot stress enough that before going ahead with a production release you make sure you have features for the content types.
As mentioned here, Chris O'Brian has a post saying that you should not use features unless necessary. One of his reasons is that it slows developement.
I disagree with this. Developement is slower if you are unfamiliar with features, but once a level of knowledge is reached, it is not a major factor.
Do listen to him about the backup and restore method of moving the content.
If you do that, all mess in the content types and fields and webs you may have created during developement (for me that is always quite a bit) will be moved to your production site.
Instead of having a nice clean site where everything is consistent, you will end up with little bugs and some areas of the site behaving differently to others simply because of old development cruft.
I recommend taking a look at Chris O'Briens most recent post, and his great Content Deployment Wizard: it's not all about Features!
Maxim is right in that most items should be deployed via features that are wrapped in solutions (WSP files). Your strategy should be to make sure your solutions and assemblies are broken into related bits of functionality. This is also beneficial in that features can be isolated at certain levels like sites and webs. Feature activation code, deactivation code and feature stapling should be used when updating any content updates. Content deployment can also make sense.
Once thing to remember is that if the updates are only in code then the assemblies can be updated without requiring the feature to be reactivated or the solution retracted and redeployed. All that is required is the Application Pool to be reset.
Microsoft has a couple articles on Dev environments and you can Google many others who recommend environments. We do development on virtual machines and deploy most items to an virtual integration server. Once we smoke test it we then deploy our solutions to QA so on and so forth. The benefit i sthat features and solutions are easy to retract. Once it goes out to production it should be thouroughly tested.
Developing in SharePoint has it's issues, that goes without saying, but so far I have found that the benefits outweight the problems.
Team-Based Development in Microsoft Office SharePoint Server 2007
We developed a custom solution which would update content types and fields for a Site Collection. Underneath the covers, through code, SharePoint allows us to modify the Fields as well as values in the Fields and Site/List Content types.
For moving the actual content from QA to Prod we use Echo
What is the general feeling amongst developers regarding the changing of files in the 12 hive.
For example if you were asked to remove the sign is a different user menu item, you would need to modify the relevent user control on the filesystem. Now if you just go and modify it via notepad or copy over and then if you go and bring a new server into the farm you will need to remember to do the same on the new server.
Obvouisly you could deploy the changed file as a solution and have that done automatically, but I'm just wondering if people are hesitant to make changes to the default installed files?
I have done a bit of SharePoint development, and I must tell you that messing with the 12-hive is a ticket to a world of pain if you ever want to move the app.
I'd rather hack up some javascript to hide it, at least that can be bound to the master page, which is much more portable.
And remember, you never know when the next service pack comes around and nukes your changes :)
I agree with Lars. Sometimes you will not be able to avoid it, depending on your needs. But, in general the best policy is to avoid modification if at all possible.
I know that some of the other menu items in the current user menu (change login, my settings, etc) can be changed by removing permissions from the user. Under Users and Groups there is an option for permissions. I can't remember the exact setting (develop at work, not at home), but there are reasonable descriptions next to each of the 30+ permissions. Remove it and you start hiding menu options. No modifications to the 12-hive needed.
There is a very simple rule: if you want to keep official support from Microsoft, don't change any of the files in the 12 hive that are installed by SharePoint.
I've never encountered a situation where the only solution was to change such a file. For example if you want to change an out-of-the-box user control of SharePoint, you can do so by making use of the DelegateControl, and overriding it in a feature.
More info:
http://msdn.microsoft.com/en-us/library/ms463169.aspx
http://www.devx.com/enterprise/Article/36628
I know it's tempting to quickly change a file, and I have to admit sometimes I just do that on a DEV box, but don't go there on a production server!
Not sure if there is much use pitching in, as everyone else pretty much has it covered, but I would also say don't do it. As tempting as it is, its just impossible to know the full impact of that little change you have made.
From a support perspective you will make it difficult for Microsoft support (patches/hotfixes).
From a maintenance perspective you are also opening yourself up to long term costs.
Go the javascript route.
The way to go about it is to use a Sharepoint Solution (WSP) file.
To change the user control, create a new Sharepoint feature with the new functionality.
Include this feature in your solution.
Deploy the solution either using the stsadm command line, or through Central Site Admin.
This will then get automatically deployed to all the servers in your farm, and it avoids you overwriting anything default sharepoint files.
For more info, check out Sharepoint Nuts and Bolts blog on http://www.sharepointnutsandbolts.com/ which give an introduction to WSP and Sharepoint Features.
I've done this many times and I will speak from experience: Never ever touch the onet.xml files within the 12 hive under any circumstance. Any error that you make in there, and to make the CAML even more complex the file is largely whitespace sensitive, will have an impact on every part of SharePoint.
You should also consider that aside from the substantial risk to the installation, you may well be building in dependencies upon your changes that are then over-written in a future patch or service pack.
Most of the time, you can accomplish everything you want to using features and solution packages without modifying the files. However, there are a few (rather annoying) rare cases where your only option would be to modify a file on the system. I have used it for two particular cases so far. One was to add the PDF iFilter to the docicon.xml file, and the other was to add a theme to the themes.xml file. In both cases, it seemed to be the only way to achieve the goal. Still, we used a solution package to write those files out to all the servers in the farm.