We shouldn`t modify drupal core files.
Reason: – a. If we will modify core modules that make it complicated, difficult or near impossible to apply site updates such as Security and bug fixes. b. You will make it difficult for those that come after to maintain the site. c. You could possibly leave your site vulnerable to exploits.
Suppose you want to add a extra field in “user registration” then create your own module and hook and alter ‘user_register ‘ function as a ‘user_rerister_alter’ and add new field.
The Drupal core has been designed to be modular, so there should be no reason to hack it . If there is a feature you want and it cannot be accomplished outside of modifying core, consider submitting your hack as a patch .
If you write the code, and then go back to document it, the chances are you'll either give up because you can't be bothered, or your documentation will be worse because you won't remember as clearly what each individual function does.
Suppose I have done a `Job` custom module .Main aim for job modules user entry various job, display job list ,modify jobs etc.
Create a floder : sites/all/modules/jobs
There have minimum 2 files required
1.
Job.module
2.
Job.info
3.
Job.install (optional if need to job table control through module install/uninstall)
4.
Job.api.php (For Documentation)
Job.api.php
/**
* Sample summary line.
*
* Next paragraph. Etc.
*/
(code being documented goes here, such as a function declaration, class, etc.)
Job.info

.info files require to render a module . name = Job //require description = Provides a job information. //require core = 7.x //require
//package = Jobs //optional if it belongs to any package then it require
//dependencies[] = views //optional if it depend on other module it require files[] = job.inc
Job.module hook_menu() page router callback functions: function job_menu(){
$items['job/add'] = array(
'title' => ‘Add Job’, //title of menu
'page callback' => 'drupal_get_form', //for drupal form render
'page arguments' => array('job_add_form'), //page argument as a function name
'access arguments' => array('access site-wide job’), //access for rolewise
'type' => MENU_SUGGESTED_ITEM, //menu type
'file' => 'job.pages.inc', //which file include for this menu
); return $items;
}
Function hook_help()
{//implement help path
}
Function hook_permission(){
/* Implements hook_permission().
'access site-wide job form' => array(
'title' => t('Use the site-wide job form'),
),

//for module and role wise permission setting
} function job_add_form($form, &$form_state)
{
$form['name'] = array(
'#type' => 'textfield', //for text box
'#title' => t(‘title'),
'#default_value' =>’’,
'#maxlength' => 127,
);
$form['body'] = array(
'#type' => 'textarea', //for text area
'#title' => t(‘body’),
'#default_value' => ‘’,
'#maxlength' => 127,
);
$form['selectbox'] = array(
'#type' => 'select',
'#title' => t('Select box'), //select box
'#default_value' => ‘’,
'#options' => array(
1 => 'Option A',
2 => 'Option B',
3 => 'Option C',
),
'#description' => t('Choose an option.'),
);
$form['submit_button'] = array(
'#type' => 'submit',
'#value' => t(Submit'),
);
Return $form;
} function job_add_form_validate($form, &$form_state)
{ if (empty($form_state['values']['name'])) {
form_set_error('name', 'Please enter name');
$form_state['rebuild'] = TRUE;
}
Return $form;
} function job_add_form_submit($form, &$form_state)
{ try {
$insert = db_insert('job')->fields($fieldarray)->execute();
}

catch (PDOException $e) {
drupal_set_message(t('Error: %message', array('%message' => $e->getMessage())),
'error');
}
//insert data into job table
Return $form;
}
In drupal all html display through theme() function.
Reason – hook theme function an HTML string that generates the themed output .Any framework when I add a theme in theme folder there have render all output blockwise. Using theme () generates the themed output. All requests for theme hooks must go through this function. It examines the request and routes it to the appropriate theme function. The theme registry is checked to determine which implementation to use, which may be a function or a template.
I have given a example how I use theme function.
* Implements hook_block_view().
*
*/ function job_block_view($delta = '') {
$block = array();
$users = "edf";
$title = "sdfsd";
$block['subject'] = t('Jobs');
$block['content'] = theme('jobs_output', array('users' => $users, 'title' => $title));
return $block;
}
/**
* Implement hook_theme()
*/ function job_theme() {
return array(
'submenus_output' => array(
'variables' => array('users' => NULL, 'title' => NULL),
),
);
}
/**

* Display output
*/ function theme_jobs_output($somearray) {
$content = '<div>TEST</div>';
return $content;
}
A Drupal schema definition is an array structure representing one or more tables and their related keys and indexes. A schema is defined by hook_schema() , which usually lives in a modulename.install file.
By implementing hook_schema() and specifying the tables your module declares, you can easily create and drop these tables on all supported database engines. You don't have to deal with the different SQL dialects for table creation and alteration of the supported database engines.
Hook_schema() should return an array with a key for each table that the module defines.
$schema['node'] = array(
'description' => 'The base table for nodes.',
'fields' => array(
'nid' => array('type' => 'serial', 'unsigned' => TRUE, 'not null' => TRUE),
'vid' => array('type' => 'int', 'unsigned' => TRUE, 'not null' => TRUE,'default' => 0),
'type' => array('type' => 'varchar','length' => 32,'not null' => TRUE, 'default' => ''),
'language' => array('type' => 'varchar','length' => 12,'not null' => TRUE,'default' => ''),
'title' => array('type' => 'varchar','length' => 255,'not null' => TRUE, 'default' => ''),
'uid' => array('type' => 'int', 'not null' => TRUE, 'default' => 0),
'status' => array('type' => 'int', 'not null' => TRUE, 'default' => 1),
'created' => array('type' => 'int', 'not null' => TRUE, 'default' => 0),
'changed' => array('type' => 'int', 'not null' => TRUE, 'default' => 0),
'comment' => array('type' => 'int', 'not null' => TRUE, 'default' => 0),
'promote' => array('type' => 'int', 'not null' => TRUE, 'default' => 0),
'moderate' => array('type' => 'int', 'not null' => TRUE,'default' => 0),
'sticky' => array('type' => 'int', 'not null' => TRUE, 'default' => 0),
'tnid' => array('type' => 'int', 'unsigned' => TRUE, 'not null' => TRUE, 'default' => 0),
'translate' => array('type' => 'int', 'not null' => TRUE, 'default' => 0),
),
'indexes' => array(
'node_changed' => array('changed'),
'node_created' => array('created'),
'node_moderate' => array('moderate'),
'node_frontpage' => array('promote', 'status', 'sticky', 'created'),
'node_status_type' => array('status', 'type', 'nid'),
'node_title_type' => array('title', array('type', 4)),
'node_type' => array(array('type', 4)),
'uid' => array('uid'),
'tnid' => array('tnid'),

'translate' => array('translate'),
),
'unique keys' => array(
'vid' => array('vid'),
),
'foreign keys' => array(
'node_revision' => array(
'table' => 'node_revision',
'columns' => array('vid' => 'vid'),
),
'node_author' => array(
'table' => 'users',
'columns' => array('uid' => 'uid'),
),
),
'primary key' => array('nid'),
);
For Database connection and mysql query example: db_set_active('YourDatabaseKey');
$result = db_query('SELECT ...'); //Your own queries on the external DB.
$node = node_load(123); //This would fail on the external DB.
$result = db_query('SELECT ...'); //Your own queries on the external DB. db_set_active();
//select node blog content type
$nids = db_select('node', 'n')
->fields('n', array('nid', 'created'))
->condition('type', 'blog')
->condition('status', 1)
->orderBy('created', 'DESC')
->range(0, variable_get('feed_default_items', 10))
->addTag('node_access')
->execute()
->fetchCol();

Setting.php db information
$databases = array (
'default' =>
array (
'default' =>
array (
'database' => 'db1',
'username' => 'user1',
'password' => 'pass',
'host' => 'host1',
'port' => '',
'driver' => 'mysql',
'prefix' => '',
),
),
'extra' =>
array (
'default' =>
array (
'database' => 'db2',
'username' => 'user2',
'password' => 'pass',
'host' => 'host2',
'port' => '',
'driver' => 'mysql',
'prefix' => '',
),
),
);
Module.install
in every module folder there have .install files there we have write table schema and modulewise insall and uninstall function call.
For e.g-
$schema['contact'] = array(
'description' => 'Contact form category settings.',
'fields' => array(
'cid' => array(
'type' => 'serial',
'unsigned' => TRUE,
'not null' => TRUE,
'description' => 'Primary Key: Unique category ID.',
),
'category' => array(
'type' => 'varchar',
'length' => 255,
'not null' => TRUE,

'default' => '',
'description' => 'Category name.',
'translatable' => TRUE,
),
'recipients' => array(
'type' => 'text',
'not null' => TRUE,
'size' => 'big',
'description' => 'Comma-separated list of recipient e-mail addresses.',
),
'reply' => array(
'type' => 'text',
'not null' => TRUE,
'size' => 'big',
'description' => 'Text of the auto-reply message.',
),
'weight' => array(
'type' => 'int',
'not null' => TRUE,
'default' => 0,
'description' => "The category's weight.",
),
'selected' => array(
'type' => 'int',
'not null' => TRUE,
'default' => 0,
'size' => 'tiny',
'description' => 'Flag to indicate whether or not category is selected by default. (1 = Yes, 0 =
No)',
),
),
'primary key' => array('cid'),
'unique keys' => array(
'category' => array('category'),
),
'indexes' => array(
'list' => array('weight', 'category'),
),
); function contact_install() {
// Insert a default contact category.
db_insert(' contact ')
->fields(array(
'category' => 'Website feedback',
'recipients' => variable_get('site_mail', ini_get('sendmail_from')),
'selected' => 1,
'reply' => '',

))
->execute();
} function contact_uninstall() {
variable_del('contact_default_status');
variable_del('contact_threshold_limit');
variable_del('contact_threshold_window');
}
//install Function for create table and uninstall for drop table.
Security:-
Database API reduces opportunity for SQL Injection:
SQL Injection makes up roughly 10% of the vulnerabilities that have been found in Drupal core or contributed modules. A lot of the times this comes from people not using query placeholders, using the wrong placeholders, or trying to build dynamic queries without properly filtering user inputs. The new database API solves these three problems:
-thinks how placeholders work making it so the right placeholder will be automatically inserted wither your argument is a number, string, or an array of data.
It's still possible to create SQL Injections in Drupal 7, of course. The first is to use the this->where() method of conditional clauses which "allows for the addition of arbitrary SQL as a conditional fragment." If your code can insert arbitrary SQL then it can insert a SQL Injection. The other way is to simply use db_query for a static query but put concatenated user input into the query string.
Luckily both of those things are easy to spot in a review and will soon become red-flags for every code reviewer.
Improved hashing algorithms:
We moved away from the increasingly crackable md5 hashing algorithm for all hashes. Passwords are now hashed with a user specific salt which makes them harder to crack. By default they are hashed
2^15 times, though you can control that number by setting.

<?php
$conf [ 'password_count_log2] = 16
?>
//sitewise salt added
<?php
$drupal_hash_salt
?>
This feature was added in the issue to Improve security: rate limit login attempts which does not provide a specific user interface to the feature. It does, however, have four important variables. The first two are for limiting the failed logins by IP: user_failed_login_ip_limit which defaults to 50 and user_failed_login_ip_window which defaults to 3600 seconds (i.e. one hour). The second set are for limiting failed logins per user: user_failed_login_user_limit which defaults to 5 attempts and user_failed_login_user_window which defaults to 21600 seconds (i.e. 6 hours).
Drupal 7 includes the ability to install or update modules via the administrative interface making it much easier to keep a site up to date.
?php
$conf [ 'allow_authorize_operations' ] = FALSE ;
?>
For cleaning and checking user input as provided:
Drupal API provides function you can use to cleanse data to make safe for HTML output. For instance, if you are outputting data that is suppose to be plain text then it will pass to the check_plain() . If you are outputting data suppose to be HTML tags then it will pass through the check_markup() (which should be limited for untrusted user). check_url(): Strips dangerous protocols from a URI and encodes it for output to HTML. drupal_set_title($node->title); // XSS vulnerability drupal_set_title(check_plain($node->title)); l(check_url($url)); //link
Checking Drupal Permission :
Drupal has a rich permission system, every module need to interact with properly to ensure to that users, including anonymous site visitor, are only allowed to see information and perform actions that they have permissions for. There are several system for permission checking in drupal core, and some contributed modules have there own permission system.
The main system of permission checking hook_permissions()

Mymodule_permission()
{
'access site-wide job form' => array(
'title' => t('Use the site-wide job form'),
),
}
Site Administrator create various role and set permission role wise. A user account set to one or more role. If a user have access permission then user can access the actions.
5. What is your experience with testing Framework and automated tests?
Unit tests can be converted quasi-verbatim, requiring some minor adjustement due to the difference of APIs. They will extend the Drupal\Core\Testing\UnitTestBase class.
<- DONE !
Database tests , such as UserSaveTest, which only asserts Database interaction, will extend the
Drupal\Core\Testing\DatabaseTestBase. These tests will require some refactoring as we need to mock the needed subsystems such as config, cache, etc.
<- Work is in progress in that area, see the commits.
Functional tests WebTestCase. These tests will requires a minimal bootstrapped environment to be run, and an internal browser, such as Guzzle. Because recreating a mocked environment like we do in DatabaseTests would take too much time, we'll bootstrap a DrupalKernel. Also as PHPUnit assumes database schemas already exists we have to write procedure to drop them in order keep a good level of isolation in the test suit.
<- No work has been done yet.
Automated Testing:
If you've worked on a multi-developer project, you've probably seen it. Everyone works on their own copy of the repository, finishes a batch of changes, integrates changes to the repository...and at some point, someone discovers that there is a bug.
Perhaps they or someone else were coding against uncommitted changes on their own checkout, or two developers working on seemingly unrelated components accidentally introduced a conflict.
Whatever the reason, such a bug may go undiscovered for some time, making it that much harder (and more expensive!) to track down and fix.
Automated testing, paired with the Agile practice of continuous integration, can help your team to avoid these problems. With frequent integrations into the main repository, there is less risk of accumulating conflicts and regular opportunities to check for them. Applying automated testing at each integration allows robust, consistent testing to be applied against the entire system, and new bugs or conflicts are found within minutes.
There are fewer bugs and conflicts, and those that occur are fixed in less time with less frustration.

In this session, I'll go over automated testing and continuous integration principles, best practices for applying these principles, and technologies that allow you to do so.
I am hard worker, dedicated, on time, reliable and quick learner.