I am in the process of fitting Sitecore Web Forms for Marketers to a solution. For that to work I need 3 things:
The ability to inject JavaScript from a rul
Rewriting all generated code to use Foundation (instead of Bootstrap)
Be able to read the submittet data of a "changed" form. Ie. a form where there is injected extra field through JavaScript.
My initial questions for this is to the second point: How do I write these views?
I have followed this article: http://www.hhogdev.com/blog/2015/september/customizing%20wffm%20in%20sitecore%208.aspx but unfortunately He does not elaborate on how to generate proper names/ids for fields and the form.
Can anybody point me in the right direction for that?
The blog post you linked to was written based on Sitecore 8.0, and although the module is the same the implementation of WFFM has since changed (unfortunately for the worse IMO).
We are currently using WFFM with Foundation, so it is possible to have them both working together but there are a few things you have to do.
I config disable Bootstrap CSS, this will mean Bootstrap markup but without the CSS files being included. I suggest you style around the given settings as much as possible to save future upgrade issues:
<settings>
<setting name="WFM.EnableBootstrapCssRendering">
<patch:attribute name="value">false</patch:attribute>
</setting>
</settings>
If you need to edit the markup then the default views for the form field markup files can be found under: Website\Views\Form and the EditorTemplates folder under that. Here's the kicker. In versions earlier than 8.0 update-5 the markup did not use the Bootstrap helper and therefore the markup was all present. The latest implementation hides this all away and therefore harder to edit in my opinion.
If you struggle with the Bootstrap markup then take a look at the view files from WFFM 8.0 update-5 or earlier. The markup is much more obvious and you should be able to (essentially) port these over to Sitecore 8.1 and then amend the markup as required (although we have found added the correct surrounding foundation DIV's were enough)
I have no idea what you mean by point 1, but for point 3, you can't. WFFM only works on the fields that you create on the back end, any new fields you create with JS will get lost. If you need to do something clever then use a hidden field (this requires adding a custom field type unfortunately) and then populate this hidden field with the data that you need passed back to the server.
Related
I'm running Sitecore 7.2 with Web Forms For Marketers 2.4.
I have a placeholder settings main. That placeholder has the WFFM form control listed under "allowed controls". The "restricting placeholders" app also lists the main placeholder as the only selected placeholder.
I have a layout standard that points at a .cshtml file Standard.cshtml.
I have a template standard page. On the __Standard values of that template I've defined a presentation under the "default" device: layout is standard, and the main placeholder is listed under "placeholder settings".
My understanding is that I should be able to "insert form" onto either the __Standard values or on to content item instances of the standard page template. But every time I try either of those I get "there are no allowed placeholders in order to insert a new form". What do I need to do to get WFFM to let me add a form to my items?
WFFM doesn't work with Sitecore MVC. Sad panda.
https://kb.sitecore.net/articles/522918
There are a couple of workarounds floating around (e.g. http://www.chrisvandesteeg.nl/2014/02/11/usercontrol-renderings-in-a-sitecore-mvc-website-wffm-for-mvc/), but I don't think they're supported.
It sounds like you have everything setup correctly in order to insert a form into the main placeholder (possible security issues, notwithstanding). I believe the issue is the fact that the WFFM module is strictly Web Forms only at the moment and does not work with MVC layouts and renderings. Because your layout is a .cshtml file, Sitecore will trigger the MVC pipeline.
Apparently there is an update in the works that will support MVC and possibly support for a wizard / multi-stepped feature.
In the meantime, I have had to work around the issue by creating separate ASPX layouts / templates for form landing pages like the one below. The downside here is that you have to manage separate code paths for both MVC and Web Forms.
https://www.montereybayaquarium.org/support-us/membership/become-a-member-now
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!
I am a bit confused on the best way to handle this problem:
My web site needs read-only static web pages (typically the About part of a web site) with 2 simple constraints:
they need to be translated
they need to have flexible layout: to incorporate base headers/footers, floating images and/or tables, and non-interactive elements (like a bootstrap carousel).
Several solutions that I have thought about:
I can of course directly write HTML files but the translation part will be awkward (a lot of <h1>, <ul>, <li> and <p> which are of no interest to the translator).
I can use Django flatpages with some markup languages but I lose a lot of flexibility (for instance template tags are not recognized)
Use generators like Hyde, but it seems quite overkill for my needs and internationalization seems a bit difficult
Does someone have other propositions that I can look into ?
Thanks !
Use django-cms, it has a Page model that can be translated and has a very smart plugin system to add many content-types into every page.
I use it a lot and it's very easy and yet powerful
For completeness and fairness, here's a full list of available CMS packages for Django.
for a much simpler solution, I would create a model called "Page" with lets say title and text fields.
The title and the text fields I would register to django-modeltranslation which will handle the translation issue.
For the text field i would use TinyMCE which let you insert basically any HTML you want so you can do whatever you need.
I am designing a very small website using basic HTML. I usually use a CMS but it has been a while since I did just HTML files, I was wondering if there was some sort templating where you can have like areas like a "Master template" and when a section is changed or added to the rest of the HTML pages that have those sections change with it. Like a common header and footer so I don't have to make the changes in each page if I need to make a change to an element.
I am using AptanaStudio 3 and was wondering if there was a feature like that as there is in Dreamweaver. I don't have Dreamweaver installed on my new computer, so taht is not an option.
Thanks in advance
You can try server-side includes (SSI): http://www.htmlgoodies.com/beyond/webmaster/article.php/3473341/SSI-The-Include-Command.htm
What is the most efficient way (in terms of programming/maintenance effort, elegance) to render a Django forms.ChoiceField as a Twitter Bootstrap dropdown using one of the django-bootstrap, django-bootstrap-form, django-bootstrap-toolkit, django-crispy-forms, etc apps? Is there explicit support for this use case in any of these apps?
Disclaimer I'm the lead developer of <a href="https://github.com/maraujop/django-crispy-forms/"django-crispy-forms (one of the apps mentioned).
I will try to explain how you do this with django-crispy-forms. You simply do in your template:
{% load crispy_forms_tags %}
{{ form|crispy }}
You can see this and more in django-crispy-forms docs. Your ChoiceField will be rendered as Bootstrap dropdown as you want.
Compared to django-bootstrap
First, a little bit of history. django-bootstrap was born after django-uni-form (the parent project from which django-crispy-forms evolved). At that time, django-uni-form was already doing Boostrap forms, but probably not in the best possible way (Bootstrap was supported by using an aditional contrib application). Thus, the author of django-bootstrap probably decided to go on its own.
Now, regarding Bootstrap support. django-bootstrap can also render forms but, instead of using a Django filter, it changes the base class of your form. So django-crispy-forms affects your templates while django-bootstrap affects your Python code.
Also, both django-crispy-forms and django-bootstrap let you do layouts. In django-bootstrap, layouts are in a Meta class within the form while in django-crispy-forms the layouts live in a subclass of FormHelper, which gives you decoupling.
django-bootstrap uses a tuple for defining a layout, while crispy-forms uses a subclass of Layout. This adds the possibility to reuse layouts, compose layouts easily, etc. Note that although crispy's encapsulation still has a list of fields inside, it adds a helpful and human-friendly API to programmatically manipulate the layout and I think enforces a good decoupling pattern.
From what I can see, layouts in crispy-forms are more powerful. It has a larger layout object collection, for example, prepended text, appended text, daterange and others are already supported while in django-boostrap these are in the TODO list.
crispy-forms has also an API for modifying layouts on the go and doing some hardcore programmatic layout building which is very nice.
crispy-forms also supports formsets of all kinds. It supports different CSS template packs, which means that if in the future the new kicking CSS pack is named 'chocolate', it will be very easy to create a new template pack for it and all your forms will be able to be rendered with 'chocolate' without code changes, just a simple setting variable.
crispy-forms also has attributes you can set in FormHelper that define nice extra functionaly you can easily turn on and off. You can also create your own custom attributes if you want.
Finally, django-crispy-forms (together with django-uni-form) has more than 67.000 downloads, which is quite good for a Django application. The project has almost 500 followers in Github, several big users, good testing coverage and several years of history and it's still actively maintained.
Compared to django-bootstrap-form
From what I can see django-bootstrap-form is only a filter for rendering a form with Bootstrap. That is something django-crispy-form covers while offering much, much more. The project was released on 21st August 2012 and looks to me like it's reinventing the wheel because several other apps cover already this use case.
Compared to django-bootstrap-toolkit
It's inspired by django-boostrap-form. From what I see in the docs, it also gives you a filter for rendering a form with Bootstrap. It apparently covers more Bootstrap stuff than forms, but I can't find more info in its docs. Last commit was 2 months ago.
I will insist that I'm obviously not the right person for a comparison that is not biased. That's why I've never written about this before. I could have published a blog post about this several times but I always dismissed the idea. However, as the fragmentation of form apps (and bootstrap-support apps) is growing, I thought this might be a good time to write down what I think.