Friday, August 31, 2012

SQL DML and DDL

SQL can be divided into two parts: The Data Manipulation Language (DML) and the Data Definition Language (DDL).
The query and update commands form the DML part of SQL:
  • SELECT - extracts data from a database
  • UPDATE - updates data in a database
  • DELETE - deletes data from a database
  • INSERT INTO - inserts new data into a database
The DDL part of SQL permits database tables to be created or deleted. It also defines indexes (keys), specifies links between tables, and imposes constraints between tables. The most important DDL statements in SQL are:
  • CREATE DATABASE - creates a new database
  • ALTER DATABASE - modifies a database
  • CREATE TABLE - creates a new table
  • ALTER TABLE - modifies a table
  • DROP TABLE - deletes a table
  • CREATE INDEX - creates an index (search key)
  • DROP INDEX - deletes an index

What is difference between Primary Key and Unique key?

A UNIQUE constraint is similar to PRIMARY key, but you can have more than one UNIQUE constraint per table.
When you declare a UNIQUE constraint, SQL Server creates a UNIQUE index to speed up the process of searching for duplicates. In this case the index defaults to NONCLUSTERED index, because you can have only one CLUSTERED index per table.
* The number of UNIQUE constraints per table is limited by the number of indexes on the table i.e 249 NONCLUSTERED index and one possible CLUSTERED index.
Contrary to PRIMARY key UNIQUE constraints can accept NULL but just once. If the constraint is defined in a combination of fields, then every field can accept NULL and can have some values on them, as long as the combination values is unique.

Monday, August 27, 2012

Distributions

This section of the Drupal documentation covers distributions, which can be searched and downloaded from the Drupal distributions section of Download and Extend.

What are distributions?

Distributions are full copies of Drupal that include Drupal Core, along with additional software such as themes, modules, libraries, and installation profiles. There are two main types of Drupal distributions:
Full-featured distributions
All-inclusive products: complete solutions for specialized use cases.
Other distributions
Quick-start tools: starting points for developers and site builders.
With a "full-featured" distribution, you can quickly and easily set up a site for a specialized purpose such as academic, business, government, nonprofit, publishing, social, etc., in few steps:
  1. Choose your Drupal distribution. You can search on the Distributions page (Download & Extend), which is all-inclusive, or use this list of several specific distributions.
  2. Install it on your web server. See the Installation Guide, and specifically, the Using an installation profile section.
  3. Configure it and enable the desired features from your website's Administer section. See the Administration Guide.

Additional resources

Read More....

www.drupal.org

Friday, August 17, 2012

What is the difference between page callback and access callback


  • page_callback is a function called which will be used to generate contents of the page
  • access_callback is a function called which will be used determine if a user has access to view the page. This can be used where a simple permission isn't enough. An example would be that the author of the node would be allowed to edit the node or any user with a special admin permission.
    Note the access_callback will by default be the user_access function which will check that the user has a specific permission.
Both of these keys have a sidekick, [page/access] arguments which should be an array of arguments that is passed to the function. arguments can either be static or you can use numbers to reference the URL. If a load function us used on a URL arg, like %user, referencing it will yield the return of the load function, like the user object instead of the user id (uid).
Page callbacks will receive any URL args that aren't used for pattern matching. So if you define an URL foo/bar and user goes to foo/bar/bazbaz will be added to the list of args passed to the page callback. This can be handy in some cases where you can provide a default argument that can be overridden in the URL.

Thursday, August 16, 2012

Module - Views RSS

This module allows users to take control of their feeds by providing a fields-based views style plugin for RSS.

Extension modules for Views RSS 2.x

In addition to modules included in the main Views RSS package, there are several helper modules which extend its functionality with additional feed element sets:

Read More....

www.drupal.org

Module - Poormanscron

A module which runs the Drupal cron operation using normal browser/page requests instead of having to set up a crontab to request the cron.php script. The module inserts a small amount of JavaScript on each page of your site that when a certain amount of time has passed since the last cron run, calls an AJAX request to run the cron tasks. Your users should not notice any kind of delay or disruption when viewing your site. However, this approach requires that your site gets regular traffic/visitors in order to trigger the cron request.
The 2.x versions are a backport of the automatic cron-running functionality included in Drupal 7. This module also includes the performance improvements of #566494: Running cron in a shutdown function breaks the site and only runs through an AJAX callback that is triggered via JavaScript only when necessary. This verison will be completely compatible with Drupal 7 core, so when you upgrade, you will no longer need to use this module.
The 1.x versions of the module uses hook_exit() to run cron at the end of the page request after the page has been sent to the browser, but has problems dealing with page caching. The 2.x version does not have this problem.

Read More....

www.drupal.org

Wednesday, August 15, 2012

Module - Responsive Images

The purpose of this library is to load images in different sizes based upon
the resolution of the browser loading the page. This allows for mobile-optimized images.
This module provides a "Responsive Images" image field formatter for which you can select
both a small (mobile-optimized) image style as well as a large (for normal screens) image style.
The image style configuration options are provided by Drupal core.

IMPORTANT

This module is currently no longer actively maintained.
Alternative modules that you might want to check out:
If you like to revive this project and have some good ideas on how to implement responsive images into Drupal, get in touch!

Read More....

www.drupal.org

Module - Scheduler

This module allows nodes to be published and unpublished on specified dates.
Dates can be entered either as plain text or with Javascript calendar popups (JSCalendar in Drupal 5, Date Popup in Drupal 6).
JSCalendar is part of the JSTools module.
The Date Popup module is part of the the Date module.
Notice:
  • Please check if cron is running correctly if scheduler does not publish your scheduled nodes.
  • Scheduler does only schedule publishing and unpublishing of nodes. If you want to schedule any other activity check out Workflow, Rules and Actions.
Scheduler is the work of many people. Some of them are listed here: http://drupal.org/project/developers/3292. But there are even more: All the people who created patches but did not check them in themselfs, who posted bug or feature request and those who provided translations and documentation.
Translations to other languages than English can be found over there: http://localize.drupal.org/translate/projects/scheduler
Heather James has recorded a nice tutorial screencast about publishing nodes with scheduler: http://www.youtube.com/watch?v=G7VfhGI4aoE

Read More....

www.drupal.org

Saturday, August 11, 2012

API reference

Welcome to the Drupal 6 developer's documentation. Newcomers to Drupal development should read the conceptual information provided in the "Components of Drupal" section, and then proceed to examine one of the heavily-documented example modules below. The examples are fully-functioning Drupal modules, so you can download them from the contributions repository and alter them as you experiment.

Views' hooks

Hooks that can be implemented by other modules in order to implement the Views API.

Functions & methods

NameDescription
hook_views_admin_links_alterThis hook should be placed in MODULENAME.views.inc and it will be auto-loaded. This must either be in the same directory as the .module file or in a subdirectory named 'includes'.
hook_views_apiRegister View API information. This is required for your module to have its include files loaded; for example, when implementing hook_views_default_views().
hook_views_convertStub hook documentation
hook_views_dataDescribe table structure to Views.
hook_views_data_alterAlter table structure.
hook_views_default_viewsThis hook allows modules to provide their own views which can either be used as-is or as a "starter" for users to build from.
hook_views_default_views_alterAlter default views defined by other modules.
hook_views_form_submitViews form (View with form elements) submit handler. Called for all steps ($form_state['storage']['step']) of the multistep form.
hook_views_form_substitutionsThis hook is called to get a list of placeholders and their substitutions, used when preprocessing a View with form elements.
hook_views_form_validateViews form (View with form elements) validate handler. Called for all steps ($form_state['storage']['step']) of the multistep form.
hook_views_handlersRegister handler, file and parent information so that handlers can be loaded only on request.
hook_views_pluginsThe full documentation for this hook is now in the advanced help.
hook_views_plugins_alterAlter existing plugins data, defined by modules.
hook_views_post_buildThis hook is called right after the build process. The query is now fully built, but it has not yet been run through db_rewrite_sql.
hook_views_post_executeThis hook is called right after the execute process. The query has been executed, but the pre_render() phase has not yet happened for handlers.
hook_views_post_renderPost process any rendered data.
hook_views_preview_info_alterThis hook should be placed in MODULENAME.views.inc and it will be auto-loaded. This must either be in the same directory as the .module file or in a subdirectory named 'includes'.
hook_views_pre_buildThis hook is called right before the build process, but after displays are attached and the display performs its pre_execute phase.
hook_views_pre_executeThis hook is called right before the execute process. The query is now fully built, but it has not yet been run through db_rewrite_sql.
hook_views_pre_renderThis 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.
hook_views_pre_viewThis hook is called at the very beginning of views processing, before anything is done.
hook_views_query_alterStub hook documentation
hook_views_query_substitutionsStub hook documentation

http://drupal.org/node/409808

Read More .....

Wednesday, August 8, 2012

Module - Embedded Google Docs Viewer

Overview

The Embedded Google Docs Viewer module adds a new formatter to the File field using the Field API. This formatter displays PDFs, Microsft Word documents, Powerpoint presentations, or Excel spreadsheets directly within a Drupal node.

Requirements

The Embedded Google Docs Viewer is a custom formatter for the Core "Field" module - therefore the "Field" module must be enabled.
Any files to be formatted/rendered by this module must be accessible on the open web - Google needs to be able to access them in order for Google Docs to be able to format them - so your Drupal system must not be behind a firewall, must be reachable by normal web users, and your system must store the files as "public:".

Tutorials

To use this module and add embedded documents to your Drupal nodes, add a "File" field to one of your site's Content Types. Under the "Manage Fields" tab, add appropriate "Allowed file extensions," i.e. one or more of pdf, doc, docx, xls, xlsx, ppt, or pptx. Then under the "Manage Display" tab, select "Embedded Google Docs Viewer" as the field formatter. From then on you will be able to upload/add and display pdfs, etc. to the content type to which you added the new field.
When displaying a page containing an Embedded Google Docs field, the formatter builds an iframe within the current node using the url of the file to construct a larger url for Google's embeddable Google Docs viewer. That combined Google url is the source for the iframe's content. The iframe is stylable (as much as any iframe is) using the CSS selector ".gdoc-field". The default values for .gdoc-field are included in the project's file "gdoc_field.css."
\

For Drupal 6 -


Use Iframe module and this google service https://docs.google.com/viewer

Read More....

Friday, August 3, 2012

jquery.md5.js.

 Problem :-

Safer Login is not configured correctly. Please download the jQuery MD5 plugin and install it under sites/all/modules/safer_login/jquery_md5. If you are using the Libraries API module, you may also install it under site/all/libraries/jquery_md5. The file should be renamed to jquery.md5.js. If you have already installed the plugin using the Libraries API method and have just enabled this module, try refreshing the page to see if this message disappears.

Solution :-

Requires the jQuery MD5 plugin, available here:
http://plugins.jquery.com/files/jquery.md5.js.txt
or here: http://www.richardpeacock.com/dev/files/jquery.md5.js.txt

Module - Safer Login

This module encrypts the user's password when they type it in during login, so a 3rd party up to no good can't see the user's plain text password (as is currently the case with Drupal logins).
Encryption is accomplished by replacing what the user enters for their password with a uniquely-salted MD5 hash of the MD5 hash of what they typed (so it is 2-layers deep). If the user does not have JavaScript enabled, then the default Drupal behavior (no hashing) still works.
Of course, this is no substitute for an SSL certificate on your server, as that would protect all form submissions, as well as prevent other types of attacks. This module is intended for those who desire password security, but either cannot afford a certificate, or only need basic protection from hackers during login.

Read More...

www.drupal.org

Wednesday, August 1, 2012

Module developer's guide


A Drupal site can have three kinds of modules (the 3 Cs):
  1. Core modules that ship with Drupal and are approved by the core developers and the community.
  2. Contributed modules written by the Drupal community and shared under the same GNU Public License (GPL) as Drupal.
  3. Custom modules created by the developer of the website.
This section of the Developing for Drupal handbook will help you to write your own modules and to collaborate with the community on shared projects.
Before you begin writing your own modules you should also become familiar with the following sections of the Developing for Drupal handbook:

Collaboration over competition

Module duplication is a growing concern within the Drupal community, which values joining forces on improving one awesome project rather than building several sub-standard ones that overwhelm end users with choices. Please remember to search existing modules andthemes first before embarking on your quest, and consider whether your project would be better as a feature addition or patch on an existing project. You could save yourself some time, and earn community karma by helping others!
The following pages will guide you step-by-step through the creation of modules.

Module - Module Grants

Module Grants makes modules that deal with content access permissions operate better on unpublished (as well as published) content. It also makes sure that access grants behave in an orderly fashion when such modules are used together.
  • Access grants are tested for unpublished content just as they are for published content
  • Allows modules that feature fine-grained access control (e.g. Workflow, TAC-Lite) to work together
  • While Module Grants' raison d'etre is to act as a catalyst amongst other modules when dealing with unpublished content and/or fine-grained access control, it does come with a handy feature of its own via the Module Grants Monitor submodule, which is bundled with the package download. After enabling Module Grants Monitor, a new item,Accessible content, appears in your navigation menu. Clicking on it reveals a summary of all the content the logged-in user has access to (i.e. view, edit) after access controls have been applied by the content access modules installed on your site. So if you have Workflow installed then what's editable to you and what's only viewable to you will depend on the workflow state the content is in. With the TAC-Lite module enabled it will depend on the vocabulary term(s) used in the content.
  • Thanks to dankh, Module Grants now also has Viewssupport, allowing you to add to your views edit and delete links that properly honour permissions (check out Module Grants 6.x-3.x-dev or 6.x-3.8)
Read More ....
www.drupal.org

Module - Content Access

What is Content Access?

Yet another content access module.
This module allows you to manage permissions for content types by role and author. It allows you to specifiy custom view, edit and delete permissions for each content type. Optionally you can enable per content access settings, so you can customize the access for each content node.

Features

  • It comes with sensible defaults, so you need not configure anything and everything stays working
  • It is as flexible as you want. It can work with per content type settings, per content node settings as well as with flexible Access Control Lists.
  • It tries to reuse existing functionality instead of reimplementing it. So one can install theACL module and set per user access control settings per content node. 
    Furthermore the module provides conditions and actions for workflow-ng / rules, which allows one to configure even rule-based access permissions.
  • It optimizes the written content node grants, so that only the really necessary grants are written. This is important for the performance of your site.
  • It takes access control as important as it is. E.g. the module has a bunch of simpletests to ensure everything is working right.
So the module is simple to use, but can be configured to provide really fine-grained permissions!

Module - Revisioning

Revisioning is a module for the configuration ofworkflows to create, moderate and publish content revisions. You use it in scenario's like this:
  • Authors write content that prior to being made publicly visible must be reviewed (and possibly edited) by moderators. Once the moderators have published the content, authors should be prevented from modifying it while “live”, but they should be able to submit new revisions to their moderators.
  • We shouldn't have to grant these roles “god-like” powers (e.g. D6's "administer nodes" permission) to implement this.
For the majority of use-cases configuration is straight-forward. The tricky bit are the permissions. To get you up and running quickly (D6 or D7), follow the steps described here:Revisioning at its simplest.
www.drupal.org

Module - Workflow

The workflow module allows the creation and assignment of arbitrary workflows to Drupal node types. Workflows are made up of workflow states. For example, a workflow with the states Draft, Review, and Published could be assigned to the Story node type.
Transitions between workflow states can have actions assigned to them. In our example, we could assign an action so that when the story moves from the Draft state to the Review state an email is sent out. Another action could be assigned to the transition from Review to Published so that the node's status is set to Published (and becomes visible on your website).

Module - User Permissions

User Permissions provides an interface for giving additional permissions to individual users without the need to assign them to a special role. When this module is enabled, users with the 'administer permissions' permission can access the 'User Permissions' tab on each user's account.

Read More ....


www.drupal.org

Module - Taxonomy Term Permissions

This module allows taxonomy administrators the ability to restrict setting individual terms on nodes by user or role. This developed out of a need to allow limiting creation of specific newsletters in the SimpleNews module to a user or role. For example, franchise owners can be limited to their own newsletters while managers can have access to all newsletters. However, the module could be applied to other situations where specific terms are considered to be "privileged" terms, such as marking a wiki page as stable or verified.

Read More........


www.drupal.org

Module - Menu Subtree Permissions

Provide means to allow users to modify parts of the menu without giving permissions for the whole menu structure.

Read More ....

www.drupal.org

only show translated menu items into current language (Drupal 8)

function MY_THEME_preprocess_menu(&$variables) {   if ($variables['menu_name'] == 'brancott-header-menu') {    $langu...