While in process of customizing Deployer, I noticed that we have already customized PageDeploy and PageUndeploy modules, please see the below config sections taken from cd_deployer_conf.xml.
PageDeploy:
<Module Type="PageDeploy"
Class="com.tridion.extensions.deployer.ConditionalPageDeploy">
<Transformer Class="com.tridion.deployer.TCDLTransformer" />
</Module>
PageUndeploy:
<Module Type="PageUndeploy"
Class="com.tridion.extensions.deployer.ConditionalPageUndeploy"/>
I just have their .jar file no code as this was done by SDL Tridion when they implemented Tridion in our company, now I want to implement one new process when page is published or unpublished.
What changes do I need to do so that without touching existing customization, I can implment the new customization. Is it permitiable or supported in Tridion?
You might want to ask around in your department. Typically Tridion Professional Services will leave the code for any customization they make at the customer's site, specifically so that you can make changes to it afterwards.
Alternatively, you can create an additional Deploy/Undeploy module for your functionality. There can be multiple modules per type, so you can just add your own module to the list.
Related
The page on CSS in the docs http://docs.plone.org/adapt-and-extend/theming/templates_css/css.html#plone-css still suggests using cssregistry.xml, even though the resources are stored in the registry now. Is this the preferred method, as opposed to registry.xml? As far as I can tell it adds them to the plone legacy bundle. Given its name, it sounds like that is something I should be moving away from.
Assuming I don't want to keep using plone legacy bundle, is it bad to add my css/js to the plone bundle or should I create a new bundle for my namespaces?
Our institute has Plone 5.0 and 4.3 running and are migrating dozens of older plone sites into them.
We have created a Diazo theme and it is hosted to provide our theme out to all plone sites. There are specific plone pages like the Login that must be changed. There are two ways we see to do this:
Portal View Customizations. Problem is we can't host this template centrally and can't change it one place to change it everywhere. This will bring maintenance issues.
Diazo. We could put all the html in the index.html and then drop code we do not need through the rules.xml. However this feels super hacky and inelegant. The index file will grow and grow in size.
What is the best approach to something like this?
My idea: (Please tell me if this good or bad)
In Diazo, the rules.xml would load a subset rules file called login-rules.xml. In the login-rules.xml, I'd put a replace rule. The replace rule would have within it all the login HTML.
You've really got two kinds of problems here.
One is deciding where to intervene for your login pages. The other is how to manage deployment of custom code.
If the changes you need are strictly ones of presentation, Diazo is a reasonable place to handle it. Remember that you may use different theme documents, with your rule set making an early decision of which theme (html) file it uses under what circumstances.
If the changes you need are beyond simple presentation and require custom logic, or if the presentation changes start to require complex custom XSLT, make the changes via view customization. But do not do that with the Portal View Customization tool. Customizations that are needed on multiple sites should go into Python packages maintained in a source-control repository like git. That goes for Diazo rules and theme files as well as templates.
You may create the skeletons for these packages with ZopeSkel or mr.bob. Use the JBOT method within these packages to customize individual template files.
Managing deployment is much easier when you're using file-system packages from a repository. You may use mr.developer within your buildout to automatically check out the current version (or a particular tag or branch) of a package when you run buildout. Then, when you need to push changes to multiple servers, you run buildout on each one and restart the ZEO clients. That may be automated with tools like Ansible. See Plone's Ansible Playbook for examples.
I've used several bits of Plone-specific jargon in the above. All of these are well-documented at http://docs.plone.org.
I am following these steps: https://documentation.magnolia-cms.com/display/DOCS/Creating+a+page+template. I'm stopped at creating a page definition.
Magnolia does not see my helloWorld.jsp template. I'm using the Enterprise Edition (free trial) if it matters. I watched all tutorials, but I can not find the answer.
Yes, it probably matters.
When you are using EE, you can have defined multiple sites in single server and you don't necessarily want to have each template available in each site you define. So you need to tell Magnolia for which site you want to enable this template. To enable this template for all sites, go to STK group in AdminCentral and open SiteDefinitons app there. In Site Definitions, go to /default/templates/availability/templates and register your template there by creating Node named helloWorld with property id set to value templating:pages/helloWorld (ID is always in format module-name:path-to-template-from-templates-folder)
HTH,
Jan
To create buttons in the SDL Tridion ribbon toolbar, where can we find the extension related information (like the config file, js files) of already existing controls like Check-in, Check-out, Undo Check-out so we can use them as a reference?
Parts of the configuration are in the ..\Tridion\web\WebUI\Editors\CME\Configuration\CME.config, the rest is in the ..\Tridion\web\WebUI\WebRoot\Configuration\System.config I believe.
The ASPX, CSS and JS files are all located in ..\Tridion\web\WebUI\Editors\CME, interesting paths to follow there are the Views and the Views\Popups but also the Controls might contain useful items for you to investigate.
I don't have a running system to check with right now, but I believe you can find this information by "following the trail" from System.Config. Just like with our own extensions, the Tridion CME must register its commands in there, and will have links to js, css, config, etc.
I'd like to edit application-specific settings by using the IIS 7 Configuration Editor. The settings are stored in an applicationSettings section, the kind automatically added for you when using Visual Studio to add settings to a project. My section looks like this:
<applicationSettings>
<My.Custom.Properties.Settings>
<setting name="SomePath" serializeAs="String">
<value>D:\Folder\SubFolder</value>
</setting>
</My.Custom.Properties.Settings>
</applicationSettings>
So, by following directions from here, and after a lot of trial and error, I am able to load the section into the IIS editor. I can see (and edit) the attributes on the setting element. I can also see the value element, but the folder path inside it is not loaded and it can't be edited, which is what I need! The schema I have added to IIS looks like this:
<configSchema>
<sectionSchema name="applicationSettings/My.Custom.Properties.Settings">
<collection addElement="setting">
<attribute name="name" type="string"></attribute>
<attribute name="serializeAs" type="string"></attribute>
<element name="value"></element>
</collection>
</sectionSchema>
</configSchema>
Has anybody succeeded in doing what I'm trying to do, or, is there a way around this that doesn't involve going back to the old appSettings section?
Having found no other alternative, I opted for changing the schema of the applicationSettings section so that the value of a setting element is stored as an attribute of the element, not another element within it, which is what the IIS Editor likes. So, my settings now look like this:
<setting name="SomePath" serializeAs="String" value="D:\Folder\SubFolder">
</setting>
This, of course, meant implementing my own settings provider (see "Custom Settings Providers" here) so that I could read from the new attribute.
This is not too hard, and it's even less so if you inherit from the LocalFileSettingsProvider that comes with .NET. Moreover, if you don't plan on changing settings at runtime, then you only need to implement the GetPropertyValues method.
The downside with this approach is that it complicates design-time support from Visual Studio, since the Settings designer won't recognize the new schema, and I found no way of telling it to use the custom provider. The good news is that the designer will load after giving you an error about this, so you can still use it to define settings. However, it will overwrite your config file with the default schema when you save. My solution to this was to create a piece of JScript that runs on Visual Studio's prebuild event, and that will modify the settings changed by Visual Studio to conform to my schema. This page was very useful when coding the script.
Tips for implementing the custom provider:
I used the AppDomainSetup.ConfigurationFile property to get to my config file.
When loading settings, just set the SettingsPropertyValue.SerializedValue property and the framework will deserialize the actual value for you.
To make the application use the provider at runtime, click an individual setting on the designer and, on the Properties pane, enter the provider's class name on the Provider field. To specify the provider for all settings entered through the designer, click on the View Code button and add the SettingsProviderAttribute to the class.