drupal 7
Drupal 7 notes: unsetting formatting tips
Following on from hiding unwanted elements in comment forms, I found this tip on one of the many threads in Drupal of people trying to hide the pesky formatting guidelines and came up with:
template.php
<?php
function [theme_name]_form_comment_form_alter(&$form, &$form_state, $form_id)
{
$form['comment_body']['#after_build'][] = 'remove_tips';
}
function remove_tips(&$form)
{
unset($form['und'][0]['format']['guidelines']);
unset($form['und'][0]['format']['help']);
return $form;
}
?>
That gets rid of everything but the fieldset container and for the roles that can use multiple text formats, the select box (the “Text format” label can be easily removed with $form['und'][0]['format']['format']['#title'] = '';
in the comment_form_alter
).
Drupal 7 notes: node--[type].tpl.php being ignored
If you change the machine name of a content type, make sure you bump all the nodes that were created under the old machine name. If that doesn’t work or there are too many of them, change them in the database.
In the below example I was trying to theme the “estimate” nodes with node–estimate.tpl.php. It wasn’t working because node 1 in this case still had the original type of “screen”.
Drupal 7 notes: the submit button on the node creation form isn't working!
In template.php
:
<?php
function [theme-name]_theme($existing, $type, $theme, $path)
{
return array
(
'[content-type]_node_form' = array(
'render element' =>
'form', 'template' => 'node--[content-type]-form', )
);
}
?>
If you keep template files in a subdirectory (eg sites//all/themes/[theme-name]/templates
or something to that effect) this may help:
'path' => drupal_get_path('theme', '[theme-name]') . '/subfolder',
After you’ve put all your fields where you want them in your pretty node--type.tpl.php
:
<?php
echo render($form['title']);
echo render($form['field_[field_name]']);
// etc
// with whatever formatting around it
?>
At the end put
Drupal 7 notes: unserialize() and undefined index notices after importing users from a csv
Long title is going to break my pretty layout.
So following on from the task of having to import a csv file of users into Drupal 6, I upgraded that install of Drupal 6 to 7, then exported the users, user roles and role tables into csv files for insertion into the database at work. Of course I had to test it out on my local to make sure nothing was too broken.
Work, Wannabe and other projects and a dash of unschooling
[minor pseudonymising edits during Drupal to hugo migration for all the good that will do now]
Firstly, what in the hell is with the life category?!
I’ve been (very slowly!) importing livejournal entries so I can replace missing photos. Very minor regret that I didn’t bother skimming through my shadowshifter livejournal before I deleted it as I probably had a few progress reports for my various projects kicking around on it, but oh well.
Drupal 7 notes - putting submenus in different places from the parent menu while keeping your active-trail
By default, when you set up a child menu, it appears directly under and slightly indented from the parent item. Occasionally, there is a need (such as with the kiosk I’m currently working on for the Christmas Island Tourism Association) where you need an active-trail but the menus need to be in different regions.
Rather trying to do everything with blocks in regions I found it easier to dump code in templates.
Drupal 7 notes hiding unwanted form elements comment forms
Just so I don’t drive myself completely insane again.
It’s a fairly standard theming problem, you have your Drupal comment form rendering thusly:
Your site is set to not allow posting by anonymous users, rendering the “Your name” field superfluous and you think the subject line looks ugly, is unnecessary or you just don’t want users giving their comments subjects for whatever reason.
Drupal 7 notes - dealing with "ghost fields"
Came across a problem someone else on Drupal dubbed “ghost field” in one of the issue queues. My issue with ghost fields came about while setting up Profile2 to use in my profile (strangely), but the problem happens in other modules as well.
The problem
- create a profile type (or modify the main one)
- add a field
- delete the field (I don’t recall seeing any difference between saving data in the field or not)
- try to add a new field with the same name, get an error saying the field name is already in use, but it doesn’t appear in the “Add existing field” list
The solution
- manually edit the database. I use phpmyadmin. Whatever works
- find the tables
field_config
andfield_config_instance
, browse them and delete all incidences of the “ghost fields” - fields can now be recreated
After deleting the ghost field instances the php fatal error and associated debug messages I’d been having trouble tracking the source of (Entity was getting blamed) disappeared, quite conveniently.
Beta!
I survived the alpha iterations! Learned a bit but didn’t end up helping much (or at all really) aside from something like a bug report and confirming a UX issue. So now we’re sitting on beta1 and I feel slightly more confident putting stuff here as from memory the betas are upgradeable. Alphas are not.
I remembered to export my Views this time so didn’t have to completely redo them :) I’ve left out the links view though as I’m formulating a better idea on how to do that page, the feed and the fynposts though were a bit of naffing around and twice over was enough. I’m slightly miffed that Zemanta isn’t picking up the editor but I’m currently not sure if that’s the fault of D7, or some component of the editor (it’s Wysiwyg with TinyMCE). Somehing there has changed as it works fine with D6. Hoping that they’ll upgrade Zemanta and it will miraculously fix everything.