In Sitecore, the publishing restrictions access via the dialog are stored under the inherited Publish base template - for example, the Item-level Publishable checkbox is stored under __Never publish.
I had expected to be able to restrict publishing by language, but the fields above are shared between languages so apply to all.
Obviously I could unshare the fields, but I'm not sure what other implications there may be. Has anyone tried this or implemented another solution?
You can restrict the publishing of an item by language, but it is also by version. These are stored in the Lifetime field section, rather than the Publishing section.
This will allow you to mark a specific version in a specific language as unpublishable, however it won't affect all versions in that language.
Other than that, an option would be to add a new field to a base template that is Unversioned, perhaps "Publishable In Language". You could then look into adding a new step into the publishItem pipeline that takes this into account when determining whether a version is to be published - this would possibly take place just after the DetermineAction step, where Sitecore uses its own logic to determine if an item is to be published. Unfortunately that class isn't easily overridable and uses private methods, so it's not a great candidate for extension itself.
Related
We had an issue where we enabled fallback language settings at the item level on a base template so that it would apply to all of our items. It worked for about 90% of our items but not for others even though the sitecore content editor indicated that it was working.
Placing this here for anyone else who has this issue. I didnt find a specific
solution for this issue on Google and was lucky enough to figure it out. Hopefully this can help someone else out too.
Our setup is Sitecore 8.1 with Habitat Asp.net MVC
Here are some steps to make language fallback work for all items by applying item level settings to a base template.
Step 1
First step to enable language fall-back is to set up the fall-back tree.
We can build a hierarchical structure (or simple linear) for languages to fall back to
Example:
In our case we would just do: EN-NZ --> EN
This is done /Sitecore/System/Languages by setting the fall-back language on each of the language nodes:
Step 2
Next we enable the language fall back feature for the site.
At the deployed website locate the config file Sitecore.LanguageFallback.config
And modify the config so that the following settings apply:
<setting name="LanguageFieldFallback.AllowVaryFallbackSettingsPerLanguage" value="true" />
…
<sites>
<site name="shell">
<patch:attribute name="enableItemLanguageFallback">true</patch:attribute>
<patch:attribute name="enableFieldLanguageFallback">true</patch:attribute>
</site>
<site name="website">
<patch:attribute name="enableItemLanguageFallback">true</patch:attribute>
<patch:attribute name="enableFieldLanguageFallback">true</patch:attribute>
<patch:attribute name="enforceVersionPresence">true</patch:attribute>
</site>
</sites>
Recycle the app pool
Step 3
Now the feature is enabled for the site we must enable the feature at the item level.
Navigate to an item in the sitecore content editor and view the Advanced section
If the Advanced section is not visible; select the View tab and check the Standard fields option
Check the Enable Item Fallback option. (Displays item from fallback language if no language version exists )
To restrict a page to a certain language, check the Enforce Version Presence option.
In cases where a version is not found for a specific language, Sitecore's default behavior is to return an empty item. This happens when rendering an item or when trying to access it via Sitecore API.
In cases where there’s no version available for the requested language, this option allows you to tell Sitecore NOT to return an item. This will end up redirecting the user to a 404 (not found) page, or returning NULL when trying to get the item via API.
We can apply these settings on the Standard Template and the setting will apply to all Items that inherit it
Navigate to the Standard Template
Create a Standard Values if does not exist
Set the Enable Item Fallback option
This will get 90% of our items and fields working, however there is a caveat; this only works for fields that do not inherit their values from Standard Values.
You can easily identify these fields by viewing the Item in the content editor
This is something to do with how the Enable Item Fallback option is also inherited from Standard values of Standard Template and Sitecore won’t apply the setting to the fields that also inherit from standard values.
To handle fields/items in this scenario you do one of two things:
Modify the field on the Item so that it does not inherit from standard values
OR:
Create a standard values on the Item template – It will inherit the Enable Item Fallback option from the Standard Values of the Standard Template
Uncheck the option and Save
Recheck the option and Save so that it no longer inherits the setting
Now that the Enable Item Fallback option is not inherited it will apply. The fields on the item that inherit from standard values will now fallback and render
Note:
I believe this is a bug because the content editor still displays the fields as inheriting their content from the fall back language when you change language however the content doesn’t render on the website until you do one of the methods mentioned above
Comments
There is also Field level settings to apply the same setting.
Also worth noting is that if you are having the issue above and apply the setting at the field level, it still won’t work until you do those steps above.
I Faced a similar problem, and here it is why.
In my case I have a datasource template DChild who inherits from another datasource template DMother.
Both DChild and DMother have standard values
When I created an item from DChild template, all fields whose values were been set by the standard values of DChild, were having their language fallback values coming from DMother standard values instead of the DChild standard value.
This was caused because the fallback was not enabled in the DChild Standard Values but was enabled in the DMother standard values.
Tricky huh ?
I intend to use Camunda for my product. While all camunda abilities match with my needs, i have a concern about camunda modeler controlled usage. Following are my needs in modeller
Is it possible to create custom domain specific tasks which i can simply drag-drop during modeling. It should be possible to define custom properties needed by this custom state
Can I somehow control/prevent use of custom java code/scripts by person modeling process. I want to restrict use of only my custom tasks, so that we don't end up with lot of scattered code across processes.
Can experts share views to achieve these targets?
Recently Camunda Modeler (I am using release 1.4.0, published on October 2016) has been extended to allow json template installation, which can meets all of your needs (if I understand them correctly), or at least the most of them.
You may find documentation for templates build here. The documentation is in progress, but what is already published I think it is quite clear. Briefly you have to
list all the elements you want to customise (user tasks, general tasks, service tasks, listeners, links and so on)
find out the json representation (explained in the short documentation) of each element
insert all the jsoned elements in a file (for example: myElements.json)
put the file in a specific modeler folder (see below)
close and restart the modeler
For example if you have installed the modeler in C:\Tools\camunda-modeler\, the folder to publish the file into will be C:\Tools\camunda-modeler\resources\element-templates (note that resources will be already present, but element-templates will not; it will have to be created).
If all will be right the modeler will start without any error and you will find a new dropdown list selector on the right panel (as stated in the documentation) for all the elements for which a template has been defined. Generally you have to classify each templates as either a user task, or a service task, or generic task and so on, so that when you want to use it you have to start from the generic element. For example, if you prepare in the json file 2 templates of kind of user task, say userTask1 and userTask2, if you want to insert in your new process userTask1 you have to
pick up an empty userTask
and choose from the element template selector on the right the voice userTask1, so that the empty user task becomes quickly the userTask1 (with all my custom properties with my default values)
that's it
To sum up, you may build templates with custom id and name (editable), with custom properties (editable or not, or even hidden), with eventual input/output parameters. So you may have default values properties and also tasks with simplified selections or without any selections at all.
You may find good starting examples to build your own templates at this GIT repository.
Hope that is enough to understand.
Is it possible to open up all possible states for a work item - essentially removing the state transitions?
I am hoping to use a tool outside of TFS for managing work items and would like to know if it's possible to simply allow all states at any time?
If you want to remove the transitions between work item, you need to customize the work flow.
You change the workflow to accomplish the following objectives:
Add or remove a state, reason, or transition.
Specify a value for field to be applied during a change in state,
reason, or transition..
Specify a custom ACTION to automate field assignments based on a
change in state, reason, or transition.
Detail steps to customize the workflow and more info about it, please refer this Modify or add a custom work item type (WIT) from MSDN.
Moreover, here is a 3rd party extension called TFS Work Item Manager which is an innovative team workload coordination platform that helps you manage your TFS work items in a much more efficient and intuitive way. You can also take a look at it.
I am building a brand new website in Sitecore and I am looking for advice on the following scenario:
My site has 2 version of its homepage. Both are quite different. The layout is the same, but most of the components and sublayouts on it will change depending on whether the user is logged in or not.
Does anybody has a suggestion of a good practice, or way to do that in Sitecore? My basic requirements are, have a single URL for both (the website root, it is a homepage) and do not harm the content author experience.
My thought so far was:
Use of personalization to control the components to be displayed (Concerns: performance and the content author experience he woudnt have to change component by component to see both versions)
Use of two item in the tree and intercept a pipeline to resolve the right item at the right time (Concerns: the content author would have two home items to maintain *not actually a big problem)
Does anybody has any other approach or considerations on those I listed?
Thanks
An alternative solution would be to make use of devices, and use a pipeline to switch devices if the user is logged in.
Set up your Device in Sitecore to use the default layout as a fallback so it does not affect other pages in your site (and they continue to work as expected). You are then able to set different sublayouts and components for that Item (directly or in Standard Values for the template) for each device. You can make use the VaryByDevice caching option to make better use of the Cache.
Your content editors can also switch between the devices easily in the Page Editor from the ribbon. Any further customization you need in other areas of the site, such has switching out a single component, can be run using a Personlization Rule taking advantage of "where the current device compares to value".
It does sound like you have the need for personalization based on authenticated status, so I would recommend staying with the built-in personalization interface to avoid confusion. Authors will have been trained during Sitecore training on how to use personalization, and introducing an alternative method for accomplishing the same thing could lead to a less-than-optimal experience for the author.
To address your concern of the author needing to view components by toggling each one, I would recommend installing the Experience Explorer module. You can create presets that meet your rules on your presentation and then the author can preview the site for different 'experiences'.
If you have a single URL for the home page, it is more straight-forward to go with a single item, so I would definitely advise against having two home page items that are being resolved by the same URL.
You mentioned a concern for performance, so I would recommend you making sure that you enable your sublayout caching settings. In your case, varying by Data may be the way to go, given you would personalize with two sets of datasources.
In the past I have used the following crude technique:
Make two components, one for "logged in" and the other for anonymous.
Each rendering has just one line, a single placeholder, either:
<sc:placeholder key="logged-in" runat="server" />
or
<sc:placeholder key="anonymous" runat="server" />
For "logged in" I make a personalisation rule which hides the component if anonymous, and for the anonymous component I make a personalisation rule which hides the component if the user is logged in.
I then nest all the components under the correct placeholder key.
So I am rather new to sitecore, and it's a topic that wasn't covered during my training. My questions is just to help point me to the correct term, or documentation on a method to do the following.
I have a definition item, with a ton of field groups, what I want to do is something like:
if Value of Field X is "yes" then collapse/hide Field X or Field Group X.
Does that make sense? Is it a validation rule? or some other kind of rules, is it a workflow I need to attach? Do you place it on just the field I want to hide, or the field that triggers the action?
I appreciate any guidance.
There is nothing out-of-the-box in Sitecore to achieve what you want but there is no reason you cannot create a composite custom field type to do this. The following articles will help you achieve this:
Creating a custom Sitecore Field
Getting to Know Sitecore: Custom Fields, Part 1
Create a new control, inheriting either from Droplist (if the comparison of the value is to be text based) or Droplink (for comparison of ID). You could add a parameter in the Source field of the control to specify what the values that trigger the hide should be.
The underlying control in the Content Editor is just a standard HTML select element. Add onchange events to the control and add your Javascript handler to hide the other controls. Since I could not find a way of adding additional custom css classes to the Sitecore controls, it would be best/easiest to hide all other controls in the same collapsible group after you control. This would mean you would need to group your controls better (or logically at least).
The Javascript will be something like this (the Content Editor uses the Prototype JS framework):
if ($(this).getValue() == 'no') {
// find the parent container of this control and then hide all the next siblings in the same group
$(this).up('.scEditorFieldMarker').nextSiblings('.scEditorFieldMarker').invoke('hide');
}
You can test this by running the above in the console, change out the keyword this with the id of your field, e.g. $('FIELD2292054').
What I am not sure about is how to trigger the hide on initial load, i.e. when someone returns to an existing item, it may be possible by adding to one of the pipelines, but would be better using a JS solution if possible. I'll have a think about this and get a proper code sample up over the next few days.
EDIT: You can add an event handler to sc:contenteditorupdated to handle the content editor being rel-oaded.
document.observe("sc:contenteditorupdated", myFunction);
I wrote up a blog post and put the code on GitHub if you are interested.
Not sure if you have come across Andy Uzick's this blog post.
He wisely talks about hiding fields in the Content Editor and has also created a Sitecore Module called Hide Field Template Extension which is hosted on the Sitecore Marketplace with the full source code to extend.
After reading through and trying the extension, I do feel that it will not completely resolve your issue (how you have described it in the question).
But it will give you:
A mid-term solution to hide a few unnecessary field that some content editors would not like to view.
Fields that are only required by administrators for admin purpose - to de-clutter these fields could be hidden.
Just one thing to bear in mind that it mentions in the requirements Sitecore 6.5 & 6.6. I have not tested it in Sitecore 7. If you are using Sitecore 7, which I think you are, one could modify the source code and make it work for Sitecore 7.
Have a look and share your findings.
Happy Sitecoring!