I found this very helpful video by Arlin Sandbulte on the
Drupal Calendar version 7.3 configuration (Calendar 7.x-3.x-dev).
The interface on this Calendar is quite different than what is shown in other slightly older videos.
The new video for Drupal 7 Calendar New Interface Set Up.
First of all, a big “thank you” to the author at snowleopardtips.net who wrote “Everything you need to know about customizing screen captures“! This very helpful article cut through the chase and made changing the screen shot folder easy.
OK, so here is the “How To”:
1) open your terminal and enter the following line. Note:The default location for screenshots is ~/Desktop.
defaults write com.apple.screencapture location <your new path ie ~/screenshots>
2) Reset the System UI Server so you can see the change.
killall SystemUIServer
Isn’t it nice when web developers make it easy for end users to fill out a form? One way to make for a pleasant user experience is to offer suggestions on a form’s input field. HTML5 now has a cool feature that makes this easier for the developers too!
The HTML5 datalist element provides an “autocomplete” feature on form elements. With it, you can provide a list of predefined options to the user as they input data.
Now, when a user is entering some text into a text field, a list can drop down with pre-filled values for them to choose from.
How to Make a datalist for a Form Field Input Element
The datalist tag was introduced in HTML 5.
Use the ID of the datalist tag to associate it with the appropriate input.
For example, if the datalist tag has an id=”myDataList”, then the list attribute of the input element will look like this: list=”myDataList”.
You can fill the datalist element by nesting option tags inside the datalist tag. Here is an example of the code for the HTML5 datalist element:
23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 | <p> <label> Enter your favorite Star Trek character:<br /> <input type="text" name="favCharacter" list="myDataList"> <datalist id="myDataList"> <option value="Captain Kirk"> <option value="Spock"> <option value="Bones"> <option value="Scotty"> <option value="Sulu"> <option value="Chekov"> <option value="Uhura"> <option value="Jean-Luc Picard"> <option value="Data"> <option value="Geordi La Forge"> <option value="Worf"> </datalist> </label> </p> |
OK, so now you know. Go be nice to your users with the HTML5
An excellent read about GIT and how to use it: “A successful Git branching model” on a blog named nvie.com maintained by Vincent Driessen
Great article, Vincent, thanks!
Drop shadows are a nice way to add dimension to a site. Creating them used to be a real task. Combining multiple divs and floats and trickery with CSS that were basically hacks. Not to mention how difficult it was to accomplish creating shadows programmaticlly. Well, making a drop shadow on an image is easy now thanks to CSS3!
Enter the box-shadow element! The box-shadow element is supported in IE9+, Firefox 4, Chrome, Opera, and Safari 5.1.1. The syntax of the box-shadow CSS3 element is as follows:
box-shadow: h-shadow v-shadow blur spread color inset;
The box-shadow element is a comma separated list of properties that effect the position and size and color and even the opacity of the shadow. Note the inset perimeter. That controls wether the shadow is inside of or outside of the object getting the shadow.
23 24 25 26 27 28 | .image-framer img { border-radius: 5px 5px 5px 5px; /* box-shadow: h-shadow v-shadow blur spread color inset;*/ box-shadow: 3px 3px 5px 0 rgba(0, 0, 0, 0.5); } |
The first to parameters control the horizontal and vertical position of the shadow.
Next is the optional blur distance measure followed by the optional spread (or size) of the shadow.
The next paramiter is the color parameter. Here is where you can use the new CSS3 rgba(0, 0, 0, 0.5) element. With the rgba(0, 0, 0, 0.5) element you can control the opacity as well. Or you could use the color number here if you like without opacity.
OK, well, enough talk. Go try it out!
Drupal sites often use wildcards in their URL. In Drupal, this is accomplished in the hook_menu() function. In the hook_menu() function, the URL is defined as the key of the $item array. The wildcard value is represented by the token, % (percent sign). But did you know the % can proceed the name of a callback function? Drupal automatically “knows” to look for the callback function you call out. There is a bit of a trick to it, though. Note in the example that there is ‘my_function’ immediately after the wildcard (%). That would be the call to the callback function. The little trickiness is that you need to define the function in your module suffixed with the word ‘_load’. The function you define as my_function_load( $nid ), also needs to have an argument of $nid. Pretty easy, huh? Drupal will “know” that the wildcard (%) is a token representing the parameter ($nid) for the function.
100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 | <?php ... some code ... $items['node/%my_function/someplace'] = array( 'title' => 'My Ttitle', 'page callback' => 'mymodule_page', 'page arguments' => array(1), ); ... some code ... /** * Menu loader callback. Load a webform node if the given nid is a webform. */ function my_function_load($nid) { .... do some stuff here ... return $node; } ?> |
In most cases dynamic data in forms is handled by the forms API which does a pretty good job of keeping it clean. Since the variables in hook_menu() for example are picked up as a % sign and then translated into a callback array, they are “cleansed” as they are passed through the Drupal Core code.
345 346 347 348 349 350 351 352 353 354 355 356 357 358 | <?php function hook_menu(){ ... some code $items['my-module/%/edit'] = array( 'page callback' => 'mymodule_abc_edit', 'page arguments' => array(1), ); more code ... return $items; } ?> |
On the other hand, there may be times when you you really need to pass dynamic data as a $_GET variable that is tacked onto an URL. In this case you need to pass the code through the urlencode() function.
When you are passing a user submitted URL in a hyperlink, rather than using check_plain(), the Drupal documentation says to use urlencode() instead.
Knowing which PHP function call the code we are working on can give us the clues we need for de-bugging a script.
Getting the calling function is easy in PHP, thanks to the debug_backtrace() function.
Just put the following code wherever in your script you need to know what function is calling the part you are working on.
45 46 47 48 49 50 | <?php> $backtrace = debug_backtrace(); print "The function that just called this code is <strong>" .$backtrace[1]['function'] . "<strong>."; </php> |
This will output something like this:
The function that just called this code is DrawWidget.
Where DrawWidget is the name of the function.
I hope this comes in handy for someone. Thanks for visiting!
When creating a module in Drupal it is very important to be aware of some security best practices when outputting text into HTML. This helps prevent XSS (Cross Site Scripting) exploits and keeps your code in general good health as it prevents problems with user input like angle brackets or ampersands.
Be sure to read the documentation for db_query() on how to use the database API securely.
When passing plain-text from the user to HTML markup, you need to pass it through the check_plain() function first. Drupal’s check_plain() converts quotes, ampersands and angle brackets into entities. This causes the string to be shown in a literal way on the browser screen.
There are a few themeable functions that automatically sanitize text by first passing it through check_plain(). They are: t() , menu items and breadcrumbs, Block descriptions (‘but not titles’), theme(‘ plain-text placeholder’), theme_username() and Drupal Form API #default_value element and #options element when the type is a select box.
Examples:
23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 | <?php> $form['safe_way'] = array( '#type' => 'textfield', '#default_value' => $user_supplied, ); $form['not_safe_way'] = array( '#type' => 'select', '#default_value' => 0, //FORM API will pass this through //check_plain(), '#options' => node_get_types('names'), // DANGER: FORM // API will NOT sanitize the // '#options' attribute with // check_plain(). ); ?> |
As a Drupal module developer, it is important to commit to memory some common places where sanitizing plain text is important.
Setting the page title:
Examples:
23 24 25 26 27 28 29 30 | <?php> drupal_set_title($node->title);//BAD, XSS vulnerability drupal_set_title(check_plain($node->title));// Correct way //NOTE: The same applies to block titles that are // passed through hook_block(). ?> |
Form elements #description and #title
Examples:
23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 | <?php> $form['wrong_way'] = array( '#type' => 'textfield', '#default_value' => check_plain($user_supplied), //←-escaped twice '#description' => t("Old data: !data", array('!data' => $user_supplied)), // XSS ); $form['right_way'] = array( '#type' => 'textfield', '#default_value' => $user_supplied, '#description' => t("Old data: @data", array('@data' => $user_supplied)), ); ?> |
Form elements – #options when #type = checkboxes or #type = radios
Examples:
23 24 25 26 27 28 29 30 31 32 33 34 35 | <?php> $form['wrong_way'] = array( '#type' => 'checkboxes', '#options' => array($user_supplied0, $u_supplied1), ); $form['right_way'] = array( '#type' => 'checkboxes', '#options' => array(check_plain($user_supplied0), check_plain($user_supplied1)), ); ?> |
Form elements – #value of #type markup and item need to be safe.
Note that the default form element #type is markup!
Examples:
23 24 25 26 27 28 29 30 | <?php> $form['wrong_way'] = array('#value' => $user->name); //XSS $form['right_way'] = array('#value' => check_plain($user->name)); // - or - $form['right_way'] = array('#value' => theme('username', $user)); ?> |
This information was gleaned from the Drupal documentation at “Handle text in a secure fashion”, which covers this topic more extensively than this post.
