Not sure if it's the best practice but I keep applying same minor modifications each time I create an email template.
I mean the one that extends when you click on Advanced arrow.
Is there a way to change it for good? Or perhaps adding an alternative one?
Related
I'm having a hard time coming up with a solution for this problem.
I'm building a WYSIWYG designer, for micro sites. The templates for these microsites will be supplied by an intermediate user, and the end-user will manipulate these templates. So, there are really two groups of users of the app: template-buiders, and end-users. Think MailChimp.
This means my Ember app will start off with a template from a template-builder, say
<h1>An awesome product</h1>
<h2 contenteditable="true">Subtitle away</h2>
<p>{{#if optionA}} One thing {{else}} Another thing {{/if}}<p>
and the end user, having chosen this template, will then be able to customize it. There are a few requirements:
There will be static, uneditable portions of the page (h1 above)
There will be static, editable portions of the page (h2 above)
There will be options that affect the layout, style, etc. (p above)
So far, my attempts have lead me to build a handlebars helper that takes a string and a context, and returns a rendered template. This is because the above template will actually be coming over from a database, as a string - remember, it's user-generated.
That means, in my application's template, it would look like
<div class="preview">
{{preview-userTemplate template context}}}
</div>
where
template: '<h1>An awesome product</h1><h2 contenteditable="true">Subtitle away</h2><p>{{#if optionA}} One thing {{else}} Another thing {{/if}}<p>',
context: {optionA: true}
Now, this actually works, in the sense that it will update if context is updated, so I can add controls along the sides for the end-user to manipulate those options. So I have those (more of less) under control.
It's the WYSIWYG content editing that is giving me trouble. In the above template (from my template-builder users), I want them to be able to add contenteditable="true" to places in their templates where the end-users can change the content.
Now, these changes need to be saved. Ideally, I would be able to retrieve the instance view's template back from the DOM, after the inline edits have been made. Is this possible? The original {{data}} placeholder would need to be preserved.
Alternatively, I could make a view/component, so the template-builder would do something like this:
<h1>An awesome product</h1>
{{#editable}}
<h2>Subtitle away</h2>
{{/editable}}
<p>{{#if optionA}} One thing {{else}} Another thing {{/if}}<p>
but this seems like it would require a good deal of finagling to get the edits to stick - I'm not even sure right now how I'd go about it.
What do you guys think? Is there an easier solution that I'm overlooking? Thanks for any pointers!
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!
Lets say I have installed a 3rd party app called 'articles', the app contains basic templates and views. And there is a view called 'home' to list articles.
I need to add a form within that view and of course the form variable is not in the default 'home' view. How should I go about adding the form variable to that view?
There are a couple of ways I can think of right now:
Create another app and create a custom view.
This seems crazy and I won't do it, but for the sake of possibility, add a context processor to add the form variable into the context.
Just wondering if anyone had this situation and what is the best approach for this?
well, you may want to try a Function Decorator to redefine the previous view function.
the context processor or the middlerware is not recommend because it's global and dirty.
another use way I can thing is use-defined tags. This may takes more affort and go against the origin design of the tags. But it seem to be a good way.
I've troubles using Django template language in a DRY way.
I defined base-section.html, which is a base for all sections of my website.
Each section must override some pieces of code in this basic template to provide proper title, icon, description, body of the section, etc - always in same way.
Now, I want to write some code in each section, but I don't like the idea of overriding about 10 blocks in each section, because it would be writing same things again and again.
Whereas keyword for specified section is X:
title of the section is X, too
title of the website in a browser is X, too
name of icon is X+"_icon.png"
and so on
I'll appreciate a solution where I can assign only 1 or 2 variables per section and have my templates working.
Is it possible?
A lot of this data could simply be passed along with the view. However, I often find that writing a custom template tag might be preferable.
You could take a look at custom tags in the Django documentation: https://docs.djangoproject.com/en/dev/howto/custom-template-tags/
Using either a simple tag or an inclusion tag, you can quite easily reuse template code.
I'm working on a blog application, and I want to have a sidebar that includes a list of all the months the blog has been in existence, to provide links to archives pages. Moreover, I'd like to make this automatically update when the month changes, rather than hardcoding it in the template. Of course, as far as I can tell, this means that I'll have to calculate the list of months in every view, and pass it into every template from every view.
I'd like to avoid this, if possible. Is there a way to calculate the list once and automatically apply it to every template, without having to explicitly pass it into the template from every view?
There are a few possible solutions to your problem.
If you really want to have this on every page on your site a context processor is probably your best choice. Context processors are basic way to inject data into all template contexts. Be aware however that the context processor will be called on every request.
An alternative solution would be to create a custom template tag and use it on a shared base template for all of the pages you wish to have your sidebar. Template tags are a bit more complex to create but they are more flexible.
With either solution you should also look at Django's cache framework. The cache framework makes it pretty easy to temporarily store your calculated values for a while to save some work on each request.
You want a template context processor
Django - having middleware communicate with views/templates
http://docs.djangoproject.com/en/dev/ref/templates/api/?from=olddocs#id1
Django's template inheritance should cover this. You could create a base template that handles your sidebar functionality. Your other views extend this template.
Template Inheritance:
http://www.djangobook.com/en/1.0/chapter04/#s-template-inheritance
A combination of custom template tags as mentioned previously and template fragment caching should do the trick.