Technical journal for task A and task B – Web development seems



Table of Contents

Web-based Technical Journal  3

Project Checklist  4

Task A – Analyse the specification and requirements  5

  1. What is your new website all about? 5
  2. Is there any pre-existing restraints that need to be considered when developing the website solution? 5
  3. Who is going to visit and use your website? 6
  4. Identify the content that you are going to deliver to your visitors 6
  5. Determine the appropriate server-side language and hosting environment 6
  6. What functionality (i.e. forum, blog, filtered listing…) are you going to deliver to your visitors? 6
  7. Describe what customisation will be necessary to match the requirements (i.e. create a custom content type, create a custom block… and detail them). 6
  8. Define the site structure 7
  9. Define custom content types and taxonomy structure 8
  10. Define the navigational structure of your website 17
  11. Define what views/listing you will need 18
  12. Validation of the front-end code markup against standards set by the World Wide Web Consortium (W3C) (to be given once task completed) 20
  13. Validation CMS performance in different browsers, checking compatibility and core CMS functionality (to be given once task completed) 20

Task B – Knowledge Evidence   20

  1. Explain markup language and their associated standards 20
  2. Describe server-side language 35
  3. Outline web security techniques – consider CMS 37
  4. Explain the importance of web accessibility 38

Bibliography – Book references  38

  1. explain markup language and their associated standards 38

Ref: 1   38

Ref: 2   38

Ref: 3   38

  1. describe server-side language 39

Ref: 4   39

  1. outline web security techniques – consider CMS 39

Ref: 5   39

  1. explain the importance of web accessibility 39
  2. Drupal 8 by Todd Tomlinson 39
  3. Documentation from class activity course subject: ICT50615 – Diploma of Website Development – Web Diploma Scripting 1 39






Web-based Technical Journal


Y/N Comments
Procedure to set up a Drupal-powered website on internet cloud Hosting

Domain registration

Acquia Drupal installation (of the right version, version 8 and/or above)

Requirements based site development


Procedure to Install and configure a Drupal-powered website using a local server As per technical journal on the WordPress driven site
Task A answers (See Task A in this file) Task A
Knowledge Evidence topics (Refer to the “Knowledge Evidence” list of topics in this file) Task B






Project Checklist


Created a website using the default functionalities and customised pages using Drupal.

Website complies with all the requirements on this checklist (including those described on Task A)


All the aspects listed below (Task A and Task B) are checked

Website available online


Y/N Comments
Website URL is provided Link:
The content matches with the described Task A
Website has at least 5 different pages
Website has custom vocabulary taxonomy
Website has a custom content type to accommodate clients requirements
Website has a block restricted to certain pages
Website has at least one custom view listing articles
Validate CMS performance in different browsers, checking compatibility and core CMS functionality
Validate the developed additional functional against the client requirements





Task A – Analyse the specification and requirements


According to the clients requirements, the website has to be developed accordingly:


1.    What is your new website all about?

The new website is all about:


Ventus Libraries

The Ventus Kids


A unique space for kids and family, with tailored information about books, events and activities dedicated to our little readers.


The site’s main aim is to provide content relevant to kids (babies to 12) and to parents – who in fact will access the website most of the time.


The site has the following features:

– new address and contact details of the libraries

– book recommendations

– provides functionality for visitors to access information about a topic  in an accessible way

– it is intuitive to the visitor – i.e. information is accessible easily

– promotes the libraries events and activities


2.    Is there any pre-existing restraints that need to be considered when developing the website solution?


The site is to be developed using Acquia Drupal, it’s default functionalities and customised pages.


The website complies with the specifications and requirements of the client such as:

  1. Website has atleast 5 different pages
  2. Website has custom vocabulary/taxonomy (Drupal does not constrain you as to how many vocabularies you can assign to a content type)
  • Website has a custom content type to accommodate client requirements
  1. Website has a block restricted to certain pages
  2. Website has at least one custom view listing articles
  3. CMS performance in different browsers should be validated checking for compatibility and core CMS functionality
  • Additional functionality developed has also been validated against the client requirements


3.    Who is going to visit and use your website?


The site’s main aim is to provide a unique space for kids (babies to 12) and family. Therefore, the visitors of the website mainly are children and their parents.


4.    Identify the content that you are going to deliver to your visitors


The content to deliver to the visitors is described briefly as follows:


  • Library/s details, venue, access open timings
  • Reading lists
  • Articles
  • Activities and events happening details for story telling, lego club, book club, movie exhibition


5.    Determine the appropriate server-side language and hosting environment


The hosting environment and server-side language details are as below:

  • Acquia Drupal 8 as the website development front-end
  • PHP 7.1 server-side language
  • mySql databases
  • Apache web server


6.    What functionality (i.e. forum, blog, filtered listing…) are you going to deliver to your visitors?


Blog is delivered to the visitors for constant updates on the happenings, events and activities on a regular basis for the visitors to stay updated about the libraries. This shall also include article/s and other post/s for news and more related information too.


7.    Describe what customisation will be necessary to match the requirements (i.e. create a custom content type, create a custom block… and detail them).


  • Website has custom vocabulary/taxonomy (Detailed in Task A 9.)
  • A custom content type to accommodate clients requirements (Detailed in Task A 9.)
  • A block restricted to certain pages

The website has a custom block created and displayed on the “The Hobby Page (/the-hobby-page)” and “Activities & Events (/activities-and-events)” pages only.


Custom Blockname:

Quote of the day


Within, Home à Administration à Structure à Block layout, the block has been placed under the header for the two pages only The Hobby Page (/the-hobby-page)” and “Activities & Events (/activities-and-events)”.


  • At least one custom view listing articles


8.    Define the site structure

The site structure is to be as follows:

  1. HOME
  4. BLOG






The Hobby Page



Activities & Events






Contact Us



About Us



Home >> Activities & Events









9.    Define custom content types and taxonomy structure

Custom content types:


Description: A content type used to capture the details about the upcoming events.

Name or title of the event

The date and time

The address where the even will be held

A description of the event






Finally, click “Save and manage fields”


At this time we created our new custom content type, Event content type which has only two fields, an Event Title and a Body. Changes to the Label: ‘Body’ to Label: ‘Event description’ for better indicator of the type of text to be entered for the person creating the event.



Adding a field to the event (date field)




We have other fields for the custom type Event:




Example of custom content type used on the website for an event called ‘Australia Day’:












The Basic Pages Content Type (following basic pages were created):

The Hobby

Activities & Events


Contact Us

About Us


Article Content Type (following article content type was created on the Home page):

Ventus Libraries – The Ventus Kids



Taxonomy structure


The Taxonomy module allows users who have permission to create and edit content to categorize (tag) content of that type. Users who have the Administer vocabularies and terms permission can add vocabularies that contain a set of related terms. The terms in a vocabulary can either be pre-set by an administrator or built gradually as content is added and edited. Terms may be organized hierarchically if desired.


We added the taxonomy structure as shown below by going to the Home à Administration à Taxonomy


Taxonomy is for categorizing content. Terms are grouped into vocabularies.

For example, a vocabulary called ‘Fruit’ would contain the terms ‘Apple’ and ‘Banana’.


In our example we have the Structure à Taxonomy à Library with the vocabulary called Library, with the terms as below:


Ventus libraries

Ventus library

The Ventus Kids


Library Reading List


Library Events

Kids activities event

Story telling activity event

Lego club event

Treehouse book club event

Movie Exhibition Event

Finding Dory movie event

Moana movie event


Click Add vocabulary












Below screenshots are steps in configuration of Drupal for assigning a taxonomy vocabulary to a content type.











Changing the default autocomplete field widget to a select list on the Manage form display:






Creating Human-and Search Engine-Friendly Lists:





Example of taxonomy structure – vocabulary term being added to article content type:







10. Define the navigational structure of your website





































11. Define what views/listing you will need


View of recent articles (by title) on the side bar of the Blog page of the website:

Recent Articles:


Includes only the title/s of the latest 3 articles. Example here has 3 article titles – Australia Day, Chinese New Year 2018, Movie Exhibitions


Below is a view/listing of all articles with detailed back-end configuration screenshots as per requirements:







For every new module or customisation created:


12. Validation of the front-end code markup against standards set by the World Wide Web Consortium (W3C) (to be given once task completed)


13. Validation CMS performance in different browsers, checking compatibility and core CMS functionality (to be given once task completed)



Link to the website: (to be given once task completed)



Task B – Knowledge Evidence


1.    Explain markup language and their associated standards


Drupal Markup Style Guide (Ref:1)

Drupal Coding Standards (Ref: 2)


Drupal Markup Style Guide

Create good HTML/markup

Create good base templates for themers to stylize

Create good CSS classes


Discuss the Drupal Markup Style Guide

This guide is intended to tell all Drupal developers how to:


Create good HTML/markup

Create good base templates for themers to stylize

Create good CSS classes

This guide is not intended to tell Drupal developers how their applications should look — that would be a design guide or an interface guide. This guide is only intended to explain the considerations how to create HTML, templates and CSS that are easy for a themer to deal with.

This guide will serve as a basis for creating patches to Drupal 7 that will standardize the HTML and CSS classes.



As a general rule: don’t use the id attribute.


Unless you are absolutely 100% sure that your template file or theme function will only be called once per user-request, then your ID might cause the markup not to validate (the value must be unique to every other DOM element’s id in the whole DOM tree).


That means, don’t use the id attribute on templates of nodes and users and even common forms like search and login forms. Even if you include the object ID in the id attribute. You, as a developer, can not guarantee that particular node, form or user will only be on the page once. Remember that views and panels can pull lots of stuff into blocks and pages.


If you need an ID for javascript, consider refactoring the javascript to use a class. If that is not an option then run the id through a static incrementer so that it gets an indexing integer appended to it; #your-id-0, your-id-1, #your-id-2, etc. See how the zen theme does this with zen_id_safe(). (This function should really go into core for d7 — search and/or open a ticket please someone. Please see also



Remember that id of the id=”” attribute stands for identifier, while class in the class=”” attribute stands for classifiers. So CSS classes are just taxonomy terms for DOM elements!


Rules of thumb for module developers:


every div must have at least one identifying class.

most divs should have three;

what object it contains, e.g. node/user/message/tree

what variation/permutation/state of that object/markup it contains e.g. full/teaser/node-typ/apple-tree/collapsed

a unique identifier, where appropriate; e.g. node-123/tree-456

The module-name should be a class on the root DOM element of each theme_*() function: class “tagadelic” on the div containing the tagadelic block, but not necessarily its descendants, which can be targeted using ascending elements’ class/es.


Use classes on containers, not on elements. /elv

use more classes if they provide a further classification that other classes have not covered, and are not inherited by ancestral DOM elements. (I wonder if this is necessary, when is a class not inherited? /elv)

the name of the theme token, vis, theme(‘foo’) would be wrapped in a div of class “foo”. (<- where? is a class on the body element enough? Is this really needed as website usually use only one theme?)

strings always make better identifiers than integers. (seems redundant with the “most divs should have three” rule)

it’s better to have too many classes than not enough, as long as they have unique meaning not already defined or implied by other classes in the element or on of it’s ascendants

elements that aren’t divs usually follow the same rules as above — with the exception of extremely explicit elements like <strong>, <em>, <p> etc. If they are used correctly then they normally wouldn’t need any/many classes.

to indicate variation/state, use the class on the outermost element. ie: on a list of link use “active” on the <li>, not on the <a> (This is now the case in Drupal 6 core menus). (redundant with rule 3?)

if you can’t think of a class for the div, then you probably shouldn’t have a div for it. (However divs are usually useful to themers (better too many than not enough), so first try harder to think of a meaningful class.)

Examples: A div wrapping a teaser might have class=”node teaser blog-node node-123″. The apple tree in the example might have class=”tree apple-tree ready-for-picking tree-456″


Check out the html5 spec for motivation as to what classes might be useful:


W3C working draft

IBM’s article sums it up better than reading the draft could. Just looking at the example’s will give you a good enough idea of what it’s all about.

This view on the Working Draft might be useful.


Spans vs. Divs


Spans and Divs have default properties that you should bear in mind:


A span works in-line.

A div works as a block element.

In other words, spans can be used to affect styling of content without taking it out of its place in the flow (e.g., for targeting a phrase or piece of jargon within a sentence). On the other hand, divs operate as block elements by default, and thus are best used to define page content that should be handled as a block somehow distinct from its surrounding content (e.g., the node and block divs that are generated in core Drupal).


Use the regular mark-up before using a div or span


When you can avoid it, don’t add a div or span to an element already defined in the mark-up. Instead, simply add a class or id, as appropriate (see above), to the existing element. For example:






<h2 class=”foo-title”>example</h2>






<p class=”foo-box”>example</p> [in this case if it’s all in one paragraph]



<span class=”foo-link”><a href=”foo”>example</a></span>



<a href=”foo” class=”foo-link”>example</a>


If you’re in doubt, put it in a div (and give it classes).


Don’t leave content adrift on the page with no mark-up at all. Every chunk of html whether in a tpl file or a theme function should have a root DOM element. For module developers this is a div 95% of the time. In page.tpl.php it’s the <html> element. (or <body>?)




Each chunk of cohesive html gets its own containing element.



This is some stuff
Here is the stuff that I need to plant, grow and pick my apple tree

<ul class=”stuff-items”>

<li>apple seeds</li>







Wrap dynamic values in sentences in inline element (span, strong, a).



<p>Posted by <a href=”/user/123″>Johnny Appleseed</a> on <span class=”date yesterday”>1 October 2007</span></p>


Leave out presentation formatting


In the interest of maintaining the separation of logic and presentation, and moving all formatting control to the theming layer, avoid using presentation mark-up like <b> and <i>. Not only are these deprecated tags, they force formatting that may not be appropriate in all contexts. Better to use <strong>, <em> or even <span> to provide handles to themers for distinct stylings.


Page structure


The site-title should use an <h1 id=”site-name”> tag. No other element on the page should use that tag.

The page-title should use an <h1 class=”title” id=”page-title”> tag. No other element on the page should use that tag.

Sub-headings within the page’s content body should use an <h2> tag.

Block titles should use an <h2> tag.



Before publishing your theme to validate your site:


W3C’s CSS Validator – CSS 2.1 should be the standard unless it is for an experimental theme

W3C’s HTML Validator – XHTML 1.0 STRICT should be the standard

WAVE Web Accessibility Evaluation Tool – identified accessibility issues should be removed



Tables shall not be used for structure, only for tabular data output.



Drupal Coding Standards

Drupal coding standards are version-independent and “always-current”. All new code should follow the current standards, regardless of (core) version. Existing code in older versions may be updated, but doesn’t necessarily have to be. Especially for larger code-bases (like Drupal core), updating the code of a previous version for the current standards may be too huge of a task. However, code in current versions should follow the current standards.


Note: Do not squeeze coding standards updates/clean-ups into otherwise unrelated patches. Only touch code lines that are actually relevant. To update existing code for the current standards, always create separate and dedicated issues and patches.


See the Helper modules section at the bottom of this page for information on modules that can review code for coding standards problems (and in some cases, even fix the problems).


Proposed changes to Drupal coding standards are first discussed in the Coding Standards issue queue.


Here is a helpful overview video tutorial, Understanding the Drupal Coding Standards, about the Drupal coding standards, why they are important, and how to use them.


Contents of this Page

Indenting and Whitespace



Control Structures

Line length and wrapping

Function Calls

Function Declarations

Class Constructor Calls



String Concatenations


Including Code

PHP Code Tags


Example URLs

Naming Conventions (Functions, Constants, Global Variables, Classes, Files)

Helper Module


# Indenting and Whitespace

Use an indent of 2 spaces, with no tabs.


Lines should have no trailing whitespace at the end.


Files should be formatted with \n as the line ending (Unix line endings), not \r\n (Windows line endings).


All text files should end in a single newline (\n). This avoids the verbose “\ No newline at end of file” patch warning and makes patches easier to read since it’s clearer what is being changed when lines are added to the end of a file.


All blocks at the beginning of a PHP file should be separated by a blank line. This includes the /** @file */ block, the namespace declaration and the use statements (if present) as well as the subsequent code in the file. So, for example, a file header might look as follows:




namespace This\Is\The\Namespace;


use Drupal\foo\Bar;



* Provides examples.


class ExampleClassName {

Or, for a non-class file (e.g., .module):





* @file

* Provides example functionality.



use Drupal\foo\Bar;



* Implements hook_help().


function example_help($route_name) {


# Operators

All binary operators (operators that come between two values), such as +, -, =, !=, ==, >, etc. should have a space before and after the operator, for readability. For example, an assignment should be formatted as $foo = $bar; rather than $foo=$bar;. Unary operators (operators that operate on only one value), such as ++, should not have a space between the operator and the variable or number they are operating on.


Checks for weak-typed inequality MUST use the != operator. The <> operator MUST NOT be used in PHP code.



# Casting

Put a space between the (type) and the $variable in a cast: (int) $mynumber.



# Control Structures

Control structures include if, for, while, switch, etc. Here is a sample if statement, since it is the most complicated of them:


if (condition1 || condition2) {



elseif (condition3 && condition4) {



else {



(Note: Don’t use “else if” — always use elseif.)


Control statements should have one space between the control keyword and opening parenthesis, to distinguish them from function calls.


Always use curly braces even in situations where they are technically optional. Having them increases readability and decreases the likelihood of logic errors being introduced when new lines are added. The opening curly should be on the same line as the opening statement, preceded by one space. The closing curly should be on a line by itself and indented to the same level as the opening statement.


For switch statements:


switch (condition) {

case 1:




case 2:







For do-while statements:


do {


} while ($condition);


Alternate control statement syntax for templates


In templates, the alternate control statement syntax using : instead of brackets is allowed. Note that there should not be a space between the closing parenthesis after the control keyword, and the colon, and HTML/PHP inside the control structure should be indented. For example:


<?php if (!empty($item)): ?>

<p><?php print $item; ?></p>

<?php endif; ?>


<?php foreach ($items as $item): ?>

<p><?php print $item; ?></p>

<?php endforeach; ?>


#Line length and wrapping

The following rules apply to code. See Doxygen and comment formatting conventions for rules pertaining to comments.


In general, all lines of code should not be longer than 80 characters.

Lines containing longer function names, function/class definitions, variable declarations, etc are allowed to exceed 80 characters.

Control structure conditions may exceed 80 characters, if they are simple to read and understand:

if ($something[‘with’][‘something’][‘else’][‘in’][‘here’] == mymodule_check_something($whatever[‘else’])) {


if (isset($something[‘what’][‘ever’]) && $something[‘what’][‘ever’] > $infinite && user_access(‘galaxy’)) {


// Non-obvious conditions of low complexity are also acceptable, but should

// always be documented, explaining WHY a particular check is done.

if (preg_match(‘@(/|\\)(\.\.|~)@’, $target) && strpos($target_dir, $repository) !== 0) {

return FALSE;


Conditions should not be wrapped into multiple lines.

Control structure conditions should also NOT attempt to win the Most Compact Condition In Least Lines Of Code Award™:


if ((isset($key) && !empty($user->uid) && $key == $user->uid) || (isset($user->cache) ? $user->cache : ”) == ip_address() || isset($value) && $value >= time())) {


Instead, it is recommended practice to split out and prepare the conditions separately, which also permits documenting the underlying reasons for the conditions:


// Key is only valid if it matches the current user’s ID, as otherwise other

// users could access any user’s things.

$is_valid_user = (isset($key) && !empty($user->uid) && $key == $user->uid);


// IP must match the cache to prevent session spoofing.

$is_valid_cache = (isset($user->cache) ? $user->cache == ip_address() : FALSE);


// Alternatively, if the request query parameter is in the future, then it

// is always valid, because the galaxy will implode and collapse anyway.

$is_valid_query = $is_valid_cache || (isset($value) && $value >= time());


if ($is_valid_user || $is_valid_query) {


Note: This example is still a bit dense. Always consider and decide on your own whether people unfamiliar with your code will be able to make sense of the logic.



# Function Calls

Functions should be called with no spaces between the function name, the opening parenthesis, and the first parameter; spaces between commas and each parameter, and no space between the last parameter, the closing parenthesis, and the semicolon. Here’s an example:


$var = foo($bar, $baz, $quux);


# Function Declarations

function funstuff_system($field) {

$system[“description”] = t(“This module inserts funny text into posts randomly.”);

return $system[$field];


Arguments with default values go at the end of the argument list. Always attempt to return a meaningful value from a function if one is appropriate.


Anonymous functions should have a space between “function” and its parameters, as in the following example:


array_map(function ($item) use ($id) {

return $item[$id];

}, $items);


# Class Constructor Calls

When calling class constructors with no arguments, always include parentheses:


$foo = new MyClassName();

This is to maintain consistency with constructors that have arguments:


$foo = new MyClassName($arg1, $arg2);

Note that if the class name is a variable, the variable will be evaluated first to get the class name, and then the constructor will be called. Use the same syntax:


$bar = ‘MyClassName’;

$foo = new $bar();

$foo = new $bar($arg1, $arg2);


# Arrays

Arrays should be formatted using short array syntax with a space separating each element (after the comma), and spaces around the => key association operator, if applicable:


$some_array = [‘hello’, ‘world’, ‘foo’ => ‘bar’];

Note that if the line declaring an array spans longer than 80 characters (often the case with form and menu declarations), each element should be broken into its own line, and indented one level:


$form[‘title’] = [

‘#type’ => ‘textfield’,

‘#title’ => t(‘Title’),

‘#size’ => 60,

‘#maxlength’ => 128,

‘#description’ => t(‘The title of your node.’),


Note the comma at the end of the last array element; This is not a typo! It helps prevent parsing errors if another element is placed at the end of the list later.


Please note, short array syntax is unsupported in versions of PHP prior to 5.4. This means that Drupal 7 core and Drupal 7 contributed projects without an explicit PHP 5.4+ requirement must use long array syntax.



# Quotes

Drupal does not have a hard standard for the use of single quotes vs. double quotes. Where possible, keep consistency within each module, and respect the personal style of other developers.


With that caveat in mind, single quote strings should be used by default. Their use is recommended except in two cases:


Deliberate in-line variable interpolation, e.g. “<h2>$header</h2>”.

Translated strings where one can avoid escaping single quotes by enclosing the string in double quotes. One such string would be “He’s a good person.” It would be ‘He\’s a good person.’ with single quotes. Such escaping may not be handled properly by .pot file generators for text translation, and it’s also somewhat awkward to read.


# String Concatenations

Always use a space between the dot and the concatenated parts to improve readability.



$string = ‘Foo’ . $bar;

$string = $bar . ‘foo’;

$string = bar() . ‘foo’;

$string = ‘foo’ . ‘bar’;


When you concatenate simple variables, you can use double quotes and add the variable inside; otherwise, use single quotes.



$string = “Foo $bar”;


When using the concatenating assignment operator (‘.=’), use a space on each side as with the assignment operator:



$string .= ‘Foo’;

$string .= $bar;

$string .= baz();



# Comments

Comment standards are discussed on the separate Doxygen and comment formatting conventions page.



# Including Code

Anywhere you are unconditionally including a class file, use require_once(). Anywhere you are conditionally including a class file (for example, factory methods), use include_once(). Either of these will ensure that class files are included only once. They share the same file list, so you don’t need to worry about mixing them – a file included with require_once() will not be included again by include_once().


Note: include_once() and require_once() are statements, not functions. You don’t need parentheses around the file name to be included.


When including code from the same directory or a sub-directory, start the file path with “.”:

include_once ./includes/

In Drupal 7.x and later versions, use DRUPAL_ROOT:

require_once DRUPAL_ROOT . ‘/’ . variable_get(‘cache_inc’, ‘includes/’);


To include code in a module:


module_load_include(‘inc’, ‘node’, ‘node.admin’);


# PHP Code Tags

Always use <?php ?> to delimit PHP code, not the shorthand, <? ?>. This is required for Drupal compliance and is also the most portable way to include PHP code on differing operating systems and set-ups.


Note that as of Drupal 4.7, the ?> at the end of code files is purposely omitted. This includes for module and include files. The reasons for this can be summarized as:


Removing it eliminates the possibility for unwanted whitespace at the end of files which can cause “header already sent” errors, XHTML/XML validation issues, and other problems.

The closing delimiter at the end of a file is optional. itself removes the closing delimiter from the end of its files (example:, so this can be seen as a “best practice.”


# Semicolons

The PHP language requires semicolons at the end of most lines, but allows them to be omitted at the end of code blocks. Drupal coding standards require them, even at the end of code blocks. In particular, for one-line PHP blocks:


<?php print $tax; ?> — YES

<?php print $tax ?> — NO


# Example URLs

Use “” for all example URLs, per RFC 2606.



# Naming Conventions

Functions and variables


Functions should be named using lowercase, and words should be separated with an underscore. Functions should in addition have the grouping/module name as a prefix, to avoid name collisions between modules.


Variables should be named using lowercase, and words should be separated either with uppercase characters (example: $lowerCamelCase) or with an underscore (example: $snake_case). Be consistent; do not mix camelCase and snake_case variable naming inside a file.


Persistent Variables


Persistent variables (variables/settings defined using Drupal’s variable_get()/variable_set() functions) should be named using all lowercase letters, and words should be separated with an underscore. They should use the grouping/module name as a prefix, to avoid name collisions between modules.




Constants should always be all-uppercase, with underscores to separate words. (This includes pre-defined PHP constants like TRUE, FALSE, and NULL.)

Module-defined constant names should also be prefixed by an uppercase spelling of the module that defines them.

In Drupal 8 and later, constants should be defined using the const PHP language keyword (instead of define()), because it is better for performance:


* Indicates that the item should be removed at the next general cache wipe.



Note that const does not work with PHP expressions. define() should be used when defining a constant conditionally or with a non-literal value:


if (!defined(‘MAINTENANCE_MODE’)) {

define(‘MAINTENANCE_MODE’, ‘error’);


Global Variables


If you need to define global variables, their name should start with a single underscore followed by the module/theme name and another underscore.




All standards related to classes and interfaces, including naming, are covered on instead of here.


File names


All documentation files should have the file name extension “.txt” to make viewing them on Windows systems easier. Also, the file names for such files should be all-caps (e.g. README.txt instead of readme.txt) while the extension itself is all-lowercase (i.e. txt instead of TXT).


Examples: README.txt, INSTALL.txt, TODO.txt, CHANGELOG.txt etc.



# Helper Modules

There are several contributed modules/projects available to assist with review for coding standards compliance:


Coder module, which includes both Coder Review (reviews) and Coder Upgrade (updates your code). To use it:

Install the module (like any other module)

Click on the “Code Review” link in your navigation menu.

Scroll down to “Select Specific Modules”.

Select the module you wish to review, and click the “Submit” button.

As an alternative to starting from the Code Review link in navigation, you can also review a particular module’s code by clicking on the link on the Modules admin screen.


Dreditor (a browser plug-in for reviewing patches and more)

PAReview (a set of scripts for reviewing project applications, which runs some coding tests)

Coder Sniffer (runs coding standards validation without loading drupal)

The Grammar Parser module provides an automated way of rewriting code files in compliance with code standards. You’ll probably also need the Grammar Parser UI module.


Ref: 3


Drupal 8.0.0, 2015-11-19


– Significantly improved the front end:

  • Several large scale cleanups of the markup produced by Drupal.
  • Added support for HTML5 elements.
  • Made use of semantic HTML 5 tags when possible. This also makes form input on mobile devices much easier for users.



– Improved authoring experience:

  • Added the CKEditor WYSIWYG editor. Clean markup guaranteed thanks to tight integration with the filter system.
  • Added a drag-and-drop configuration UI, which automatically updates the HTML filter settings, making configuring text formats trivial for typical use cases.


– Tremendously improved language support all around:

  • Added HTML 5 language markup; language information added in markup in
  • several more places.
  • Much improved language APIs for developers:
  • The text formatter from t() is now available as FormattableMarkup. Translates a string to the current language or to a given language.




2.    Describe server-side language


Ref: 4

Server-side language/Server-side scripting

Server-side scripting is a technique used in web development which involves employing scripts on a web server which produce a response customized for each user’s (client’s) request to the website. The alternative is for the web server itself to deliver a static web page. Scripts can be written in any of a number of server-side scripting languages that are available (see below). Server-side scripting is distinguished from client-side scripting where embedded scripts, such as JavaScript, are run client-side in a web browser, but both techniques are often used together.


Server-side scripting is often used to provide a customized interface for the user. These scripts may assemble client characteristics for use in customizing the response based on those characteristics, the user’s requirements, access rights, etc. Server-side scripting also enables the website owner to hide the source code that generates the interface, whereas with client-side scripting, the user has access to all the code received by the client. A down-side to the use of server-side scripting is that the client needs to make further requests over the network to the server in order to show new information to the user via the web browser. These requests can slow down the experience for the user, place more load on the server, and prevent use of the application when the user is disconnected from the server.


When the server serves data in a commonly used manner, for example according to the HTTP or FTP protocols, users may have their choice of a number of client programs (most modern web browsers can request and receive data using both of those protocols). In the case of more specialized applications, programmers may write their own server, client, and communications protocol, that can only be used with one another.


Programs that run on a user’s local computer without ever sending or receiving data over a network are not considered clients, and so the operations of such programs would not be considered client-side operations.



In the earlier days of the web, server-side scripting was almost exclusively performed by using a combination of C programs, Perl scripts, and shell scripts using the Common Gateway Interface (CGI). Those scripts were executed by the operating system, and the results were served back by the web server. Many modern web servers can directly execute on-line scripting languages such as ASP, JSP, Perl, PHP and Ruby either by the web server itself or via extension modules (e.g. mod_perl or mod_php) to the web server. For example, WebDNA includes its own embedded database system. Either form of scripting (i.e., CGI or direct execution) can be used to build up complex multi-page sites, but direct execution usually results in less overhead because of the lower number of calls to external interpreters.


Dynamic websites sometimes use custom web application servers, such as Glassfish, Plack and Python’s “Base HTTP Server” library, although some may not consider this to be server-side scripting. When designing using dynamic web-based scripting techniques developers must have a keen understanding of the logical, temporal, and physical separation between the client and the server. For a user’s action to trigger the execution of server-side code, for example, a developer working with classic ASP must explicitly cause the user’s browser to make a request back to the web server. Creating such interactions can easily consume much development time and lead to unreadable code.


Server-side scripts are completely processed by the servers instead of clients. When clients request a page containing server-side scripts, the applicable server processes the scripts and returns an HTML page to the client.


There are a number of server-side scripting languages available, including:

ASP (*.asp)

ActiveVFP (*.avfp)

ASP.NET (*.aspx)

ASP.NET MVC (*.cshtml)

ColdFusion Markup Language (*.cfm)

Go (*.go)

Google Apps Script (*.gs)

Hack (*.php)

Haskell (*.hs) (example: Yesod)

Java (*.jsp) via JavaServer Pages

JavaScript using Server-side JavaScript (*.ssjs, *.js) (example: Node.js)

Lasso (*.lasso)

Lua (*.lp *.op *.lua)

Parser (*.p)

Perl via the module (*.cgi, *.ipl, *.pl)

PHP (*.php, *.php3, *.php4, *.phtml)

Python (*.py) (examples: Pyramid, Flask, Django)

R (*.rhtml) – (example: rApache)

Ruby (*.rb, *.rbw) (example: Ruby on Rails)

SMX (*.smx)

Tcl (*.tcl)

WebDNA (*.dna,*.tpl)

Progress WebSpeed (*.r,*.w)

Bigwig (*.wig)



3.    Outline web security techniques – consider CMS


It is important to keep your code secure.


Following are some some ways to keep your code secure as outlined in writing secure code on


  • Use check functions on output to prevent cross site scripting attacks


  • Use the database abstraction layer to avoid SQL injection attacks


  • Use db_rewrite_sql() to respect node access restrictions.


Find more @ Ref: 5






4.    Explain the importance of web accessibility


  • Accessibility best practices


  • Use tools to evaluate your module’s pages for accessibility


  • Use the Form API appropriately
    • Use #title and #description
    • Use fieldsets to group elements which belong together logically
    • Form field focus


  • Make accessible Javascript widgets
    • Autocomplete widgets
    • Date/Calendar popup widgets



  • Creating accessible themes
    • Tools for validating accessibility
    • Accessibility validation


Find more @ Ref: 6


Bibliography – Book references


1. explain markup language and their associated standards


Ref: 1

Drupal Markup Style (Ref: 1):


Ref: 2

Drupal coding standards (Ref: 2):

PEAR Coding standards:



Ref: 3


eg of documentation



(5 markup…)




2. describe server-side language


Ref: 4


3. outline web security techniques – consider CMS

Ref: 5

outline web security techniques – consider CMS


4. explain the importance of web accessibility

Ref: 6

explain the importance of web accessibility


5.    Drupal 8 by Todd Tomlinson


6.    Documentation from class activity course subject: ICT50615 – Diploma of Website Development – Web Diploma Scripting 1



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s