Trying to modify the RSS feeds created by Views module in Drupal.
Since there are no 'theme_' hooks for the RSS feeds (rightfully as XML is theme-less), I need an alternate way to modify the fields that are output into the RSS, preferably using template.php if possible.
http://api.drupal.org/api/function/format_rss_item/6 looks promising as that is where each row is created, but it doesn't
node_feed() is what collects the nodes, creates the additional fields, and then calls format_rss_item().
Specifically, we need to remove the dc:creator element from the $extra array created in node_feed()
If you go into a specific content type, you can set the RSS display fields as per this post:
http://redfinsolutions.com/redfin-blog/show-hide-fields-views-generated-drupal-rss-feed
I am adding another answer, as I have recently had to do this and managed to do it without modifying data in the theme layer.
You can add a preprocess function to your view. It is a bit of work though.
There are some guidelines here, but they are a bit confusing. Here is my summary of how to do this.
First make sure your modules weight is > views
Secondly copy the template you would like to add a preprocessor to to your modules directory. Rename it to be something in the list of templates in theming information.
Then edit hook theme like this (but change to use the existing view that you need to override.
function mymodule_theme($existing, $type, $theme, $path) {
// Copy the exsisting views theme from the existing array.
$override = $existing['views_view_row_rss'];
// Add my preprocessor to the list of preprocess functions
$override['preprocess functions'][] = 'mymodule_myfunction';
// Point to a template so that this view will be used.
$override['template'] = 'my_more_specific_template_name';
$override['path'] = drupal_get_path('module', 'path');
unset($override['file']);
// Return your theme handler.
return array('my_more_specific_template_name' => $override);
}
You should then be able to write your preprocess code in the function mymodule_myfunction.
In the view, if you click on "style information" this will show you the template files used to create the feed. You can copy the template so that it is overridden for your view and remove dc:creator from the $item_elements array.
This is not particularly nice as you are modifying data in the theme layer, but it will do what you want.
I'd suggest using the Views Node Feed module to do this. It will let you completely write the XML that is output by Views for feeds.
Related
How can I assign an existing template file (template file of an another view) to Drupal view.
I already have a template views-view--search-issue.tpl.php for search_issue view. Is there any way to use the same template for another view archive_issue? Or is it necessary that I have to create a new template for that one?
Then you might want to implement some preprocess hook that lets you add some suggestions. Something like this (it's not tested and maybe you'll need a different hook but to get an idea):
function phptemplate_preprocess_views_view (&$vars) {
$view = $vars['view'];
if ($view->name == 'archive_issue') {
$vars['template_files'] = 'views-view--search-issue';
}
}
But like Aniruddhsinh said, the easiest way is to just copy paste the code you need in the appropriate template. Maybe you're feeling that you're violating the DRY manta (Don't Repeat Yourself), but in this case it's better than to break the pattern for views templates. Just go with Aniruddhsinh solution.
Source: Suggested template files for views
Go to your archive_issue view and select the template file name. Create a template file with the same name from archive_issue and copy the content from views-view--search-issue.tpl.php which is for your search_issue.Paste it into this archive's template file. Clear the cache because of template changes and you will get the same template as it is in search_issue.
I have several custom content types and in one specific one I need to offer two fields, one for the href for a link, and one for the text of a link this way I can build and style it with minimal user involvement of the HTML/CSS. I also have a custom node.tpl for this content type. My problem is that drupal throws divs around each field I create that aren't in my template file for this content type (node-custom.tpl) and I can't put the href for a link with divs around it inside google.co.uk</div>"> See my problem. Maybe I'm doing this all wrong so any other ideas are welcome.
Please note I'm trying to create this site with minimum involvement of HTML/CSS access for the user. I'm aware I could hand code the link in the field.
The easiest way to do this would be to use a preprocess function in your template.php file and build the link up manually:
function mytheme_preprocess_node(&$vars) {
$node = $vars['node'];
if ($node->type = 'my_type') {
$uri = $node->field_name_of_link_field[LANGUAGE_NONE][0]['value'];
$text = $node->field_name_of_display_text_field[LANGUAGE_NONE][0]['value'];
$vars['my_link'] = l($text, $uri); // Using Drupal's l() function to render a link
}
}
Then in your node template file you'll have access to the variable $my_link which you can output anywhere, and will contain the correct HTML for the link. Finally, go to the "Manage Display" page for your content type and set the display of the two fields you no longer need to output to 'Hidden'.
There are other ways so if that's no good let me know
EDIT
Just to add, I think the easiest way to do this would actually be to install the Link module and use the provided field type instead of the two other fields you're currently using.
I've just discovered that if you want to alter a specific page (or group of pages) all you need is to add templates file to the core templates. For instance, I need to theme my /helloword page using a page--helloworld.tpl.php and node--helloworld.tpl.php template files.
Now all I get is a blank screen so I tried to write a preprocess function that adds support for custom theme files like:
<?php
/**
* Adding or modifying variables before page render.
*/
function phptemplate_preprocess_page(&$vars) {
// Page change based on node->type
// Add a new page-TYPE template to the list of templates used
if (isset($vars['node'])) {
// Add template naming suggestion. It should alway use doublehyphens in Drupal7.
$vars['template_files'][] = 'page--'. str_replace('_', '-', $vars['node']->type);
}
}
?>
I see no syntax error but I still get a blank screen. Still no luck
Is someone able to figure out what's wrong in the code/routine?
Drupal7 + Omega Sub-Theme
Kind Regards
I think there's a tiny bit of confusion here: a template file named node--type.tpl.php will automatically be called for any node which has the type type...you don't need to add the template suggestions in yourself.
There is one caveat to this, you have to copy the original node.tpl.php to your theme folder and clear your caches otherwise Drupal won't pick it up.
Also you don't want to use the phptemplate_ prefix...rather you want your function to be called MYTHEMENAME_preprocess_page.
Your code to add the page template based on the node type looks spot on, see if you still have the problem after you change your function name and clear the caches.
Hope that helps :)
Is it possible to include a theme in a Drupal Feature? if so how?
Not at the moment, unfortunately. Features basically consist of things that can be cleanly exported out of and imported into Drupal via various event hooks. Themes are an entirely different animal.
Theoretically, if you want to override some markup in your Feature (custom tpl.php files for your own content type for example), you could include the custom tpl.php file and use theme-related hooks in the Feature's module file to let Drupal know that the templates are in your module's directory.
In addition to Eaton's answer. If you need to override an existing template (a .tpl.php file) provided by another module you can use hook_theme_registry_alter in YOUR_FEATURE.module:
function YOUR_FEATURE_registry_alter($theme_registry) {
$originalpath = array_shift($theme_registry['TEMPLATE']['theme paths']);
$featurepath = drupal_get_path('module', 'YOUR_FEATURE') .'/themes');
array_unshift($theme_registry['TEMPLATE']['theme paths'], $originalpath, $featurepath);
}
In order for this to work, your feature should have a weight greater than the one of the module providing the overrided template. So in YOUR_FEATURE.install you will have something like
function YOUR_FEATURE_install() {
db_query("UPDATE {system} SET weight = 10 WHERE name = 'YOUR_FEATURE'");
}
Hello im a newbie at using Drupal, and have come across a block in my progress. I have been using CCK to add new content types to my forms. I was wondering if there was any way to add to the form that is generated so that i may contain the elements and also insert visual html code like head rules etc. I have dabbled with the hook_form_alter() and it does not seem to help me in my efforts. Ive been through adjusting tpl.php files and such and have made no progress. Please if there is any one there in the inter-webs who is knowledgeable on this matter your advice would be greatly appreciated.
Here is just an example of what I would want to do within the form:
1. Contain field elements within DIV's
2. Add HTML Content into the form
If you want to customize the markup for a for you can create a theme function for it and make the form use it with hook_form_alter. This has nothing to do with CCK which is used to customize a content type so you can add additional content to a content type.
hook_form_alter does not help you in altering an edit form containing cck fields because cck fields are added after hook_form_alter call.
You need to theme your form like this:
Create a module and put this hook implementation in it:
function mymodule_theme($existing, $type, $theme, $path) {
'your_form_id' => array(
'arguments' => array('form' => NULL),
'template' => 'my_template',
)
}
Then create a file named my_template.tpl.php in your module directory.
Now empty your cache.
In that file, you can render form elements separately, like this:
<?php
print drupal_render($form['a_form_element']);
print '<h2>blah blah blah...</h2>';
print drupal_render($form['another_form_element']);
// this one is for rendering all the remaining items, like hiddens:
print drupal_render($form);
Use devel module during development. It contains many useful tools that makes development much easier.
Raw HTML CCK Field (Drupal 6) - no filters, formats or editor
Simple Fix! Just use plain text format for unfiltered HTML. Then convert it back to html in a field .tpl when the node is built.
Plain Text format on a CCK field will convert the HTML tags to entity special characters (this would make is so it reads like code on the page instead of being actual html tags). It stores the string encoded using php's htmlspecialchars($text, ENT_QUOTES, 'UTF-8') inside of drupal's check_plain() function.
The cleanest simplest way to decode it, is in a field tpl file. This avoids hooks, hook order problems, looping bugs, and performance issues. This is done by adding tpl files to the base themes: hq_base, odyssey_base and odyssey_admin. Here is how drupal decodes plain text on a cck node edit form: print html_entity_decode(strip_tags($text), ENT_QUOTES); Note - html_entity_decode turns php tags into html comments when it decodes back to html. Here are sample files with the correct naming convention to give php control over the fields:
• content-field.tpl.php
• content-field-[your_field_name].tpl.php
content-field.tpl.php is a copy from the cck contrib into the theme folders, this is a contrib override to make it available in the theme, and should not be modified (unless you wanted to change all the fields in the theme). The field specific file is also a copy of the tpl, it will work once the override file is there. Then decode to html in the field tpl file:
• // print $item['view'];
• print html_entity_decode(strip_tags($item['view']), ENT_QUOTES);
Drupal Version Note:
The tpl files are slightly different in Drupal 7 and Drupal 8. But the html_entity_decode() is a php function that won't change per Drupal version.
Security Note:
This decode trick for getting raw HTML goes against the way Drupal was built for text formatting security. It means that anyone with permissions to edit the page now has permissions to edit html structure, and add script tags on the page. This can break layouts, and potentially be dangerous. You are relying on editing permissions for security here, instead of Drupal's normal Formats-per-Role security.