Disclaimer: I inherited a Drupal 7.44 site with no experience in Drupal at all.
The business is trying to make a new webform and they want it to look exactly like an existing one. After looking around I found that the webform has a template tied to it. From the docs it seems I'm supposed to create more template files with the format webform-form-[nid].tpl.php where [nid] is the webform node id.
We have multiple environments that all changes must go through - dev, test, and finally prod. Wouldn't the node id be different in every environment for newly created webforms? Also, if I want to apply the same template to multiple webforms, do I really need to make multiple identical template files?
I also found some CSS styling for the existing webform and it looks like .webform-client-form-25 button.webform-submit and such. That 25 is the node id. I have little CSS experience, but this feels really bad. I don't want to copy blocks of CSS, changing node ids over and over. What's the proper way to assign generic, reusable CSS classes to webforms? I saw "Custom classes" under "Manage Display" when editing the form, but it didn't seem to change the actual HTML of the form. Was I on the right track though, should I just read some docs about it?
You are absolutely right, these detailed selectors do not make sense for reusable layouts.
Each webform HTML form gets a default class of .webform-client-form (that's generic) and an id including the webform's nid #webform-client-form-<nid>.
So, you could change #webform-client-form-25 to the class mentioned above. Please be aware, that this will affect all webforms then.
To set layout settings to several, but not all webforms, you need to give these webforms some class to distinguish them from the rest. Sadly, the Webform module itself doesn't provide an option to do that, but you can add a form alter hook in your theme's template.php:
function mytheme_form_alter(&$form, &$form_state, $form_id) {
$affected_forms = array('webform_client_form_25', 'webform_client_form_37', [...]);
if (in_array($form_id, $affected_forms)) {
$form['#attributes']['class'][] = 'my-custom-class';
}
}
With .my-custom-class you can then define CSS just for the group of webform forms listed in $affected_forms.
As for the template files, Webform itself states:
This file may be renamed "webform-form-[nid].tpl.php" to target a specific webform on your site. Or you can leave it "webform-form.tpl.php" to affect all webforms on your site.
So, again, it doesn't provide an option out-of-the-box, but you can create theme suggestions in your template.php by extending $vars['theme_hook_suggestions'] in a page preprocess function.
Related
I have have made a folderish content type called supplier_folder, which displays a list of suppliers that can be added under it, and their information. I can add it through the navigation bar, but I would like to add it programatically during setup.
I have been following the tutorial on custom installer code (http://docs.plone.org/develop/addons/components/genericsetup.html#custom-installer-code-setuphandlers-py) and have looked at creating objects programatically (http://docs.plone.org/develop/plone/content/creating.html).
Unfortunately, the second article says I need to have a folder created. How can I get around this and add the supplier_folder object at the Plone Site outside of a folder?
IIRC, only users with role Manager or Site Administrator can add content to the root of the site; you can overcome this limitation in two ways:
by using the _constructInstance method as it bypasses the permissions when creating an item
by switching roles inside your code with plone.api.env.adopt_roles
I personally prefer the second one.
you can see an example of a pretty complex setuphandlers.py in interlegis.portalmodelo.policy package.
When you create a new Plone site, it's also creating some default content types.
Look at how Plone do: https://github.com/plone/Products.CMFPlone/blob/1471828ee97a8dd84396bad4a3286be514819869/Products/CMFPlone/setuphandlers.py#L119
There are a couple of ways to achieve this. The buildin mechanism is to use GenericSetup in combination with "structure" folder as described here: http://koansys.com/tech/create-plone-initial-content-with-generic-setup
In short you need the following:
Create a folder "structure" in your Generic Setup profile (in general, under profiles/default)
Create a .objects file with the following content: "suppliers,supplier_folder"
in "structure" create a folder "suppliers" with a .properties file and content:
[DEFAULT]
title = Suppliers
description = Some usefull description text
As far as I remember this is ok for simple structures likes your. If you have complex structures with folders and sub-folders and want more specific control you probably need to write python code. I made some stuff here: https://github.com/collective/zettwerk.setup/blob/master/zettwerk/setup/structure.py
But zettwerk.setup is not yet released, but you should be able to integrate the structure.py right into your project. Than you can the handle_structure method into your setuphandlers.py and passing a structure dict like this:
handle_structure(portal, [{'id': 'suppliers', 'portal_type': 'supplier_folder'}])
The advantage of this method is, that you can also control metadata like workflow state, default page setting, portlets, local roles and some others.
I have some view which lists my module table entries.
What is the most elegant way to attach a form below the view to add record?
Waht I am trying to do know is:
I created dedicated form in my module:
function my_module_form_add_record($form_state) {
form fields.....
}
I added to the view theme file:
$add_form = drupal_get_form('my_module_form_add_record');
print $add_form;
But I do not like this solution for at least 2 reasons:
I does not work ...
2. Even if it worked - it is depended on the theme file! So if I change the theme - functionality is crashed.
I would like to find more elegant solution to attach form from custom module to the view.
I know of the existence of the "Views Attach" module but it has no option of adding custom forms.
I know also of the existence of the Views Embedded form (and I am usig it) but it is only useful if you want to add form to the every row.
Seems the must be some solution to add record from the view page!
Thanks you for help.
you could use hook_views_pre_render:
This hook is called right before the render process. The query has been executed, and the pre_render() phase has already happened for handlers, so all data should be available.
Adding output to the view can be accomplished by placing text on $view->attachment_before and $view->attachment_after. Altering the content can be achieved by editing the items of $view->result.
I don't have a real need to omit the default core.css reference from my HTML pages but I would like to know so I can feel comfortable that I have full control. Thanks
There are many ways to achieve this.
The problem is, once you remove the core.css file you are talking about 6 thousand lines of places that will not appear with a presentation anymore. What I do when we are limited to theme-only visual customization I create a theme that will address any new CSS needs and also replace the elements in the core.css file (themes are loaded AFTER this file, so if you have duplicated declarations in both files, the theme's one will prevail, without using the !important mini-hacks).
Keep in mind that SharePoint in editing mode just doesn't work without this file, you have to use different approaches when you are, for example, talking about an internet-facing site with 100% anonymous users vs an intranet-like portal with everyone creating and editing content on the go.
With all the warnings given, you can go to your masterpage and remove the core.css tag making it invisible:
<SharePoint:CssLink runat="server" Visible="false"/>
Depending on your type of sharepoint site (WSS vs MOSS + Publishing Features) the masterpages may work differently based on configuration, by default (WSS or MOSS without Publishing Features or any change on the matter) your masterpage will open on all the link that do not contain /_layouts/ in the url.
Examples:
/Default.aspx => Masterpage
/DocumentLibrary/Forms/Allitems.aspx => MasterPage
/_layouts/viewlsts.aspx (Show all site content) => no custom
masterpage
This is Microsoft's way to stop you from breaking even more (system pages) with the masterpages, but you can be extreme and use HttpModules or editing the 12/Template/Layouts/LCID folder (affecting the entire web front-end)
Usual scenarios:
Anonymous sites with no core.css when the user is anonymous and normal load when credentials are given (loading speed)
Themes used to let users create their mini-sites and use the branded templates or other sharepoint themes
Masterpages to customize what most of the users usually see, forcing your branding throught the child webs (new websites in non-MOSS Publishing wont inherit the masterpage)
Everything-under-the-masterpage with HttpModules or /12/ modifications (very rinky and complicated)
Note: It's not recommended to customize files from the Site Definition when you can avoid doing so.
When using Mickel's advice, make a copy of the Default.master, rename it to something like Custom.master and apply changes to that file. Then right click your custom master page and select "Set as default master page."
This is all done from within SharePoint Designer btw
Simply add your own custom CSS style sheet via Central Admin - this will be applied last, after Core.css so you can override anything you wish. You do not want to remove it! :-)
I know that I need to add the tracking code snippet at the bottom of all my pages, but is there a central location to do this?
Or do I need to add this tracking code to all of my templates?
I guess that I could wrap the snippet in a user control, or external .js file, and reference it on each page, but is there a global footer somewhere? The site I'm working on has about 30-40 layouts, and adding it to each one would be a pain!
Thanks in advance!
Actually, the role of a Sitecore layout is exactly this; to act as a global file that all individual page templates "derive" from.
Normally you'd stick the analytics code into the master layout, and use Sitecore sublayout/placeholder techniques to construct the various page templates you need. You would not normally need more than perhaps one or two layouts for any device you are serving content to. And I guess for most sites, the only device in use is regular web content delivery.
That being said, what you could do, is have all the layouts inherit their codebase from a common base class (inheriting from Page), and inject the google code centrally from here. Would still require you to go through all layout files however.
I have not tried the module, I think that is codebehind version. I have made this in XSLT, its pretty fast and easy to make. I have footer.xslt where I put the code that simply checks if page you are standing on uses template that I want to index and does not belong to page names that I want to exclude. Then I have an item with a custom template for Google Analytics with following memo fields.
IncludeTemplates -field contains list of templates that I want to include for analytics :
ExcludeItemsNames -field for excluding pages by item name
contains($includeTemplates, concat('|',./#template,'|')) and not(contains($excludeItemNames, concat('|',./#template,'|')))
Remember #key and #template is always in small letters
If you run many domains don't forget to add pageTracker._setDomainName("www.example.com"); in analytics script so you can separate sub-domains etc. if they use same footer.xslt
Normally we consider the actual Google code as content. Within Sitecore we normally have a settings folder, something like /sitecore/content/settings. This exists outside the root of the site. Beneath this have a settings item with a plain multi-line text field, I think the field type is memo or something similar.
Afterwards create an XSLT that renders out the content of this settings item. Something like (assuming the field is called value in the setting item):
<xsl:value-of select="sc:fld('Value','/sitecore/content/settings/footerJavaScript')" />
You may or may not need to set the disable-output-escaping attribute.
Then on the aspx page that your pages use as the template add a control that looks at the xslt rendering:
<sc:XslFile runat="server" Path="/xsl/footerJavaScript" />
The reason that we normally keep the javascript as content is this allows the client to change the analytics code without having to contact us.
We primarily use an ASP.NET environment at work. Right now I'm building an application which uses "Modules", which is just a UserControl, with its' Javascript right in the control, and a link element to the stylesheet for that control. I want to keep it modular, and would like the style of this control to be independent from the markup/javascript.
So I'm wondering what the preferred method of doing this is? Obviously if I didn't want the "theme" functionality I'm after, I could just use style tags at the top of the control. Right now I have a link element, as I said, and this isn't proper I don't think.
Does anyone have any preferred methods, and if so, what and why?
I considered ASP.NET themes briefly, but the idea of these controls are a little different, I think.
It's basically a shopping cart system. I don't want to get into it all, but we are using a really neat security system, and we don't want to use a premade shopping cart. I'm developing a set of controls that can be dropped on a page, for instance in SiteFinity (which is the CMS system we use) or for any other project we might have. Normally I would compile these into a DLL so we get ACTUAL controls we can drag & drop from the toolbox, then I could use internal "generic" styling and allow for any additive styling someone might want, as well as supplying a few fancier styles as well.
This is the first time I've ever done this, or really the first time anyone in our shop has done this either so I'm kind of figuring it out as I go. I might be pretty far off-base, but hopefully I'm not.
Right, the idea for this is to have a "theme", which is really just a CSS file and a jQuery template. I have them named the same, and have a Theme property on the usercontrol to set it.
When these controls are finalized, I might refactor the javascript to a RegisterScriptBlock on the code-behind, but for now they just in script tags on the control itself.
What prompted this question was DebugBar for IE, giving me warnings that link elements are not allowed inside a div. I don't much care, but after thinking about it, I had no idea how to link to the css file without doing that. I considered very briefly having an 'empty' link tag on the master and then setting THAT in the code behind on Page_Load of the UserControl, but that just seems like ass.
I could use #import I guess but I think link tags are preferred, correct?
It sounds like you're rolling your own theme engine... why not use ASP.NET Themes?
If you're determined to do it yourself, here's some code from the CssFriendly project that may be of interest to you. (I think it should be ok to post the code as long as I cite where it's from.) The .css files are flagged as Embedded Resource and the code below is used to include them as needed.
string filePath = page.ClientScript.GetWebResourceUrl(type, css);
// if filePath is not empty, embedded CSS exists -- register it
if (!String.IsNullOrEmpty(filePath))
{
if (!Helpers.HeadContainsLinkHref(page, filePath))
{
HtmlLink link = new HtmlLink();
link.Href = page.ResolveUrl(filePath);
link.Attributes["type"] = "text/css";
link.Attributes["rel"] = "stylesheet";
page.Header.Controls.Add(link);
}
}
I think what you're supposed to do is use Page.RegisterScriptBlock to register your script blocks. Best-case you shouldn't have them inline in your ascx inside script blocks. This isn't always possible, but theoretically it's the best way.
Ideally your styles should be separate from your markup as well. Your controls can have classes and IDs, but your style is based on your application and not your controls. Controls can theoretically be used in other applications where you might want a different style.
It depends on how big your app is, and whether or not it's dependent on Themes elsewhere, IMHO.
If you're using a .skin file, or if the majority of the app is also plugged into the theme, you might as well go with the theme.
But if it's just a few styles you need, you're better off to set the stylesheet manually, keep your css file external (inline styles are a PITA and defeat one of the core purposes of css).
In either case, don't forget to set the CssClass attribute on your controls.
To be proper I would have an import.css file - structure the naming of the classes to follow your controls, and import the styles within the header of the document.
If you have a module called "30DayPricingCalc" then you could name the classes/id's:
30DayPricingCalc.css
.30daypricingcalc_main_content
{
...
}
Also if you haven't I would setup a list of generic reusable styles to save you room. Since elements will allow multiple classes per object.
Also, link tags matter a lot less now than they used to. we're well past support for IE5 generation browsers and IE6 supports the #import tag.
Cheers!