Thursday, 1 August 2013

Content Types in Drupal 7

There can be different types of content you can write. The default installation of Drupal 7 includes the following two types of content:
  1. Articles
  2. Basic Pages
Articles Basic Pages
Articles in Drupal 7 can be thought of as news and announcements. This is content that you publish frequently, and the time or frequency that you publish the content is important. Basic pages in Drupal 7 is content that is more permanent, such as an About Us type page. Sure, you can edit your About Us page whenever you would like, but it is generally not a page that you would remove from your navigation, such as a news item. 
There are more content types that you can create in Drupal 7, but Articles and Basic Pages are the only ones that are ready for you to use right now. As we progress further into our Drupal 7 education channel, we'll cover other content types more in depth.
Now that we covered the basics on Articles vs. Basic Pages, let's now look into how to create them:
For more information on this course please visit Working with Content in Drupal 7.

Writing module .info files (Drupal 7.x)

Overview

Drupal uses .info files (aka, "dot info files") to store metadata about themes and modules.
For modules, the .info file is used for:
  • rendering information on the Drupal Web GUI administration pages;
  • providing criteria to control module activation and deactivation;
  • notifying Drupal about the existence of a module;
  • general administrative purposes in other contexts.
This .info file is required for the system to recognize the presence of a module.

Example

The following is a sample .info file:
name = Really Neat Widget
description = Provides a really neat widget for your site's sidebar.
core = 7.x
package = Views
dependencies[] = views
dependencies[] = panels
files[] = example.test
configure = admin/config/content/example
The .info file should have the same name as the .module file and reside in the same directory. For example, if your module is named example.module then your .info file should be named example.info.
This file is in standard .ini file format, which defines properties in key/value pairs separated by an equals sign (key = value). You may use quotation marks to wrap the value. Quoted values may contain newlines.
.info files may contain comments. A semi-colon [;] placed at the beginning of a line makes that line a comment, and that line will not be parsed.
Note: Whenever you create or change your .info file, you will need to clear your site's cache for your changes to take effect.

Properties

The .info file can contain the following properties:
name (Required)
This displays the name of your module, which will appear on the Modules page. Since module names are proper names, it should be capitalized as a proper name (e.g., "Really Neat Widget", not "really neat widget" or "Really neat widget"), and it should be a human-readable name (not really_neat_widget). If your module name includes an acronym (CSS, WYSIWYG, UI, etc.) or a third-party trade name (jQuery, JavaScript), of course follow the standard capitalization for those.
name = Really Neat Widget
description (Required)
A short, preferably one-line description that will tell the administrator what this module does on the module administration page. Remember, overly long descriptions can make this page difficult to work with, so please try to be concise. This field is limited to 255 characters.
description = Provides a really neat widget for your site's sidebar.
Descriptions can contain links to documentation and sources. The following example shows a link to the author. It could be a link to a documentation node on Drupal.org. This is useful when the online documentation is better than the readme file and when you want to read about a module before switching it on.
description = Domain manager by <a href="http://petermoulding.com">Peter Moulding .com</a>.
core (Required)
The version of Drupal that your module is for. For Drupal 7 this would be 7.x, etc. Note that modules cannot specify the minor version of a branch of Drupal. 6.x is correct; 6.2 is not.
core = 7.x
stylesheets (Optional)
Drupal 7 allows you to add CSS files in the module's .info file if it should be added on every page, just like theme .info files do. Here is an example from the node module's .info file:
stylesheets[all][] = node.css
scripts (Optional)
You can now add Javascript in the module's .info file if it should be added on every page. This allows Javascript to be aggregated in an optimal way, and is the preferred method of adding Javascript that most visitors will need on a typical site visit:
scripts[] = somescript.js
For more information see Managing JavaScript in Drupal 7.
files (Optional)
Drupal now supports a dynamic-loading code registry. To support it, all modules must now declare any code files containing class or interface declarations in the .info file, like so:
name = Really Neat Widget
...
files[] = example.test
When a module is enabled, Drupal will rescan all declared files and index all the classes and interfaces that it finds. Classes will be loaded automatically by PHP when they are first accessed.
dependencies (Optional)
An array of other modules that your module requires. If these modules are not present, your module cannot be enabled. If these modules are present but not enabled, the administrator will be prompted with a list of additional modules to enable and may choose to enable the required modules as well, or cancel at that point.

The string value of each dependency must be the module filename (excluding ".module") and should be written in lowercase like the examples below. Spaces are not allowed.
dependencies[] = taxonomy
dependencies[] = comment
In addition, test_dependencies[] can be used to indicate dependencies which are optional but recommended. At this writing they are supported only by Drupal.org's automated testing system. They cause the testbots to check out the projects suggested. Generally any modules that you have listed in the 'dependencies' array in the getInfo() function of your module's tests should be added as test_dependencies[].
test_dependencies[] = autoload
If you need to specify that a certain module's version number is required Drupal 7 provides a way for this in the dependencies[] field. Version numbers are optional and only necessary if the module absolutely requires another module's specific version or branch.
The syntax for the dependencies[] field(s) is:
dependencies[] = modulename (major.minor)
Where major is the numeric major version number and minor is the numeric or alphanumeric minor version number. x can be used to denote any minor version. Some examples follow.
name = Really Neat Widget
description = An example module
dependencies[] = exampleapi (1.x)

test_dependencies[] = autoload (>7.x-1.5)
...
In the above .info code, the "Example" module requires an "Example API" module with the major version of 1 and any minor version.
dependencies[] = exampleapi (1.0)
This means that the module requires the 1.0 (and only the 1.0) version of the Example API module.
dependencies[] = exampleapi (1.x)
The above module requires any minor version of the module in the 1.x branch (1.0, 1.1, 1.2-beta4, etc.)
The dependencies[] property in the .info file can also optionally specify versions:
  • = or == equals (optional: equals is the default)
  • > greater than
  • < lesser than
  • >= greater than or equal to
  • <= lesser than or equal to
  • != not equal to
dependencies[] = exampleapi (>1.0)
The above module requires any version greater than version 1.0.
You can optionally specify the core version number as well:
dependencies[] = exampleapi (>7.x-1.5)
The above module requires a 7.x version compatible version of the module and a version greater than 1.5.
Additionally, multiple version dependencies can be specified as comma-separated values within the parentheses:
dependencies[] = exampleapi (>1.0, <=3.2, !=3.0)
This facility can be used to specify a minimal core version by using system as the module name:
dependencies[] = system (>=7.53)
This makes the module require at least Drupal 7.53.
package (Optional)
If your module comes with other modules or is meant to be used exclusively with other modules, enter the name of the package here. If left blank, the module will be listed as 'Other'. In general, this property should only be used by large multi-module packages, or by modules meant to extend these packages, such as Fields, Views, Commerce, Organic Groups, and the like. All other modules should leave this blank. As a guideline, four or more modules that depend on each other (or all on a single module) make a good candidate for a package. Fewer probably do not. An exception to this rule is the "Development" package, which should be used for any modules which are code development tool modules.

If present, the package string groups modules together on the module administration page (admin/modules); the string should therefore be the heading you would like your modules to appear under, and it needs to be consistent (in spelling and capitalization) in all .info files in which it appears. It should not use punctuation and it should follow the Drupal capitalization standard as noted above.

Capitalization is important because package string is case sensitive, and using package = fields in one module and package = Fields in another would yield two different packages on the module administration page. This can be highly confusing as Seven (the default administrative theme) capitalizes fieldset legends, making fields and Fields indistinguishable. Using package = Fields is the correct way.
package = Views
Suggested examples of appropriate items for the package field:
  • Administration
  • Commerce
  • Development
  • Fields
  • Media
  • User interface
  • Views
  • Voting (if it uses/requires VotingAPI)
The Package names for contributed modules wiki tries to track current package names; this does not mean they are recommended.
php (Optional)
As of version 6.x, module and themes may specify a minimum PHP version that they require. They may do so by adding a line similar to the following to their .info file:
php = 5.3
That specifies that the module/theme will not work with a version of PHP earlier than 5.3. That is useful if the module makes use of features added in later versions of PHP (improved XML handling, object iterators, JSON, etc.). If no version is specified, it is assumed to be the same as the required PHP version for Drupal core. Modules should generally not specify a required version unless they specifically need a higher later version of PHP than is required by core. See the PHP Manual for further details on PHP version strings.
version (Discouraged)
The version string will be added by drupal.org when a release is created and a tarball packaged. However, if your module is not being hosted on the drupal.org infrastructure, you can give your module whatever version string makes sense.

Users getting their modules directly from git will not have a version string, since the .info files checked into git do not define a version. These users are encouraged to use the git deploy module to provide accurate version strings for the admin/build/modules page for modules in directories checked out directly from git.

Because Drupal core uses a slightly different packaging process than contributed modules, the core modules have a version line predefined. This is an exception to the rule, not the model for contributed modules.
configure (Optional)
As of version 7.x, the path of the module's (main) configuration page.
If a module is enabled, a "Configure" and "Permissions" link appear. This will be the path of the "Configure" link for this particular module on the modules overview page.
configure = admin/config/content/example
required (Optional)
As of version 7.x, modules and themes may specify that they are absolutely required and should never be disabled by adding required = TRUE. These modules will be enabled automatically during install. In most cases it should only be used with the Drupal core required modules (e.g. Node, User, etc.).
hidden (Optional)
As of version 7.x, modules and themes may specify that they should not be visible on the modules page by adding hidden = TRUE. This is commonly used with testing modules used with SimpleTest where end-users should never enable the testing modules.
project (Discouraged, packaging use only)
Module maintainers should not use this at all. The packaging script on drupal.org will automatically place a string here to identify what project the module came from. This is primarily for the Update status module, so that Drupal installations can monitor versions of installed packages and notify administrators when new versions are available.
project status url (Only used for custom modules not submitted to drupal.org)
Allows module maintainers to define a URL to check for updates to their module using the Update status module. No module released on drupal.org should define this parameter. URL should point to an XML feed that accepts requests in the form of http://my.domain.com/projects/{project}/{core}. In that example, project status url should be set to http://my.domain.com/projects.
For more information on info file formatting, see the drupal_parse_info_file() documentation.

Troubleshooting

I added the core = 7.x line, but my module still says "This version is incompatible with the 7.x version of Drupal core" on the modules page. What gives?
Be aware that the "dependencies" format changed between Drupal 5.x and 6.x.
Wrong:
name = Really Neat Widget
...
dependencies = foo bar   ; 5.x dependency format.
core = 6.x
Correct:
name = Really Neat Widget
...
; Note the [], and that each of the dependencies is on its own line:
dependencies[] = foo
dependencies[] = bar
core = 7.x

Description and Non-ASCII Characters

Note that if you want to use accented characters or other non-ASCII characters in your .info file's description field, you should include the HTML escaped notation, e.g., &ouml; for the "รถ" character or &copy; for the "©" character.

Tuesday, 30 July 2013

Sugar Developer Guide 6.5

The Sugar Developer Guide is designed for developers who are new to Sugar, or to CRM and Web-based applications. This guide introduces you to some basic CRM concepts and helps you get familiar with the Sugar system. It describes how to configure and customize the Sugar platform for a broad range of tasks applicable to companies, government agencies and other organizations that have a need to manage business relationships with people.
Readers are expected to have basic programming and software development knowledge, be familiar with the PHP programming language and the SQL database language.
Topics

Monday, 29 July 2013

Sugar Community Edition 6.5.0 Administration Guide

This guide describes options that enable Sugar administrators to configure the application to meet their organization’s requirements.
Topics
  • The Admin Wizard displays when you log into Sugar for the first time after installation. This wizard guides you through the process of branding, localizing, and configuring email settings in Sugar that will be applicable to all users in your organization. You can skip this step if you prefer to do it at a later time.
  • This section describes how to manage teams, users, and roles.
  • Connect to the various SugarCRM services where you can access the SugarCRM forums and Sugar Wiki, search FAQs (Frequently Asked Questions), download the latest Sugar version, file and research reported bugs, request new features and more.
  • This section includes options to configure system-wide settings that apply to all users in your organization.
  • Administrators can setup and manage mail accounts for inbound and outbound emails, including campaign emails, using the options defined in this section.
  • The Developer tools section displays options that enable you to build new modules and customize existing ones. The Module Builder enables you to build custom modules; Studio enables you to customize existing modules. To create relationships between modules, see Creating Relationships. After you build a module in Module Builder, you can deploy the module directly within the current instance, or you can use the Module Loader to install it in another Sugar instance. For more information, see Module Loader.
  • This section provides the Releases option that enables you to maintain a list of releases for your product. This list will be available in the Release drop-down box that is displayed when reporting a new bug in the Bug Tracker module.
  • As an administrator, you can create and manage employee records. When you create an employee record, it is automatically added to the Employees list as well as the Users list. Similarly, when you delete an employee, the associated user record is also deleted.
  • Advanced Configuration options enable you to exercise tighter control over user actions in your Sugar instances.

Sugar Community Edition 6.5.0 Application Guide

The Sugar Community Edition Application Guide introduces you to some basic CRM concepts and helps you get familiar with the Sugar system. It describes how to access Sugar through a personal computer and a web browser. It also describes how to perform a broad range of customer relationship management tasks and related administration tasks.
Readers are not required to have any programming or software development knowledge, but should be generally familiar with the use of a personal computer and a web browser such as Mozilla Firefox.

Topics
  • Welcome to Sugar Community Edition, a commercial open source Customer Relationship Management (CRM) application.
  • This guide assumes that you have the required resources to access the Sugar application and you are familiar with how to use them. Contact your system administrator for issues and concerns.
  • The Sugar user interface consists of various modules designed to help you manage customer-related records such as contacts and accounts. Each module, representing a record type, groups the tools and functions needed to perform specific tasks. This enables you to work more efficiently.
  • When you log into Sugar, you will see your Home page. Tabs for other modules display alongside the Home tab. Other users do not have access to your Home page. The Home page displays a collection of Sugar Dashlets that display information related to your activities such as meetings and calls. It also displays records assigned to you, such as Accounts, Opportunities, and Cases. Sugar Dashlets are user-configurable panels that you can add, remove, and move as needed. For more information, see Managing Sugar Dashlets.
  • Leads are early contacts in the sales process. Use the Leads module to create, manage, and track sales leads or unqualified opportunities along with related activities, sales campaigns, and history. You can associate a lead with any type of campaign to track the effectiveness of the campaign in generating opportunities for your organization.
  • Use the Contacts module to create and manage contacts for your organization. A contact is any individual who is a valid sales lead; a lead that has been evaluated and assessed for a possible sales opportunity. You can associate a contact with any record such as an Account, Opportunity, or Campaign. Associating a contact with a campaign enables you to track the effectiveness of the campaign in generating opportunities for your organization.
  • Use the Accounts module to create and manage customer Accounts for your organization. An Account contains your customer information such as name and address. Each Account can be associated with other records such as Opportunities and Contacts.
  • Use the Opportunities module to create and manage sales opportunities, qualified leads, and view related records. An opportunity specifies the estimated amount of a sales deal and is tied to a sales stage. A sales stage, such as Qualification, Closed Won, or Closed Lost identifies how close you are to making the sale. The administrator defines and sets the sales stage depending upon the requirements in your organization. The estimated amount can vary depending on the sales stage.
  • Use the Documents module to create and manage files that you share with users and contacts.
  • The Calendar Module has been introduced as a separate module in Release 6.2.0 to allow for ease of use and access. Use the Calendar module to schedule and manage activities such as calls, meetings, and tasks.
  • The Calls Module has been introduced as a separate module in Release 6.2.0 to allow for ease of use and access. Use the Calls module to log, view, and import calls.
  • The Meetings Module has been introduced as a separate module in Release 6.2.0 to allow for ease of use and access. Use this module to schedule, view, and manage meetings.
  • The Emails module enables individual users to send and receive emails from within Sugar.
  • The Tasks Module has been introduced as a separate module in Release 6.2.0 to allow for ease of use and access. Use the this module to schedule and manage tasks.
  • The Notes Module has been introduced as a separate module in Release 6.2.0 to allow for ease of use and access. Use the this module to create, view, and import Notes and attachments to records in Sugar.
  • Use the Targets Module to track and manage targets as part of mass marketing campaigns. You can create many types of campaigns as described in Creating a Campaign.
  • Use the Target Lists Module to track and manage mass marketing campaigns. You can create many types of campaigns as described in Creating a Campaign.
  • Use the Campaigns Module to track and manage mass marketing campaigns. You can create many types of campaigns as described in Creating a Campaign.
  • Use the Cases module to track and manage services-releated problems reported by your users and customers. After you create a case, you can associate it with related bugs.
  • Use the Bug Tracker module to report, track, and manage product bugs.. Bugs are defects or features associated with a particular revision of a product. The administrator populates the drop-down list of product releases. After you create a bug, you can associate it with the related case. Note: This module is hidden by default. The administrator must display it for your use.
  • Use the Projects Module to create and manage projects for your organization.
  • You can export Sugar records in .csv format to your local machine. Use Microsoft Excel, Notepad, or other text editors to open .csv files. The .csv file displays column titles, including the Record ID (a long string of letters and numbers used as a unique reference to each account record) and all the other fields in the module. Note: When exporting values for drop-down list options, Sugar exports the ID associated with each option (that is, item name) and not the display labels.
  • Import data for modules such as Accounts, Contacts, Leads, Opportunities, Targets, Calls, Meetings, and Tasks with the help of an easy-to-use User Import Wizard. Refer to the tool-tips and instructions provided in the wizard at every step of the import process.
  • Use the Employees module to view information such as name, title, and email address for employees in your organization. All Sugar users are employees, not all employees are Sugar users. An employee needs a username and password to log into Sugar to be a user.

Friday, 26 July 2013

Retrieving a List of Fields From a Module - REST and PHP

Overview

A PHP example demonstrating how to retrieve fields vardefs from the accounts module with the get_module_fields method using cURL and the v4 REST API.
This example will only retrieve the vardefs for the 'id' and 'name' fields.

Example

01<?php
02 
03    $url = "http://{site_url}/service/v4/rest.php";
04    $username = "admin";
05    $password = "password";
06 
07    function call($method, $parameters, $url)
08    {
09        ob_start();
10        $curl_request = curl_init();
11 
12        curl_setopt($curl_request, CURLOPT_URL, $url);
13        curl_setopt($curl_request, CURLOPT_POST, 1);
14        curl_setopt($curl_request, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_0);
15        curl_setopt($curl_request, CURLOPT_HEADER, 1);
16        curl_setopt($curl_request, CURLOPT_SSL_VERIFYPEER, 0);
17        curl_setopt($curl_request, CURLOPT_RETURNTRANSFER, 1);
18        curl_setopt($curl_request, CURLOPT_FOLLOWLOCATION, 0);
19 
20        $jsonEncodedData = json_encode($parameters);
21 
22        $post = array(
23             "method" => $method,
24             "input_type" => "JSON",
25             "response_type" => "JSON",
26             "rest_data" => $jsonEncodedData
27        );
28 
29        curl_setopt($curl_request, CURLOPT_POSTFIELDS, $post);
30        $result = curl_exec($curl_request);
31        curl_close($curl_request);
32 
33        $result = explode("\r\n\r\n", $result, 2);
34        $response = json_decode($result[1]);
35        ob_end_flush();
36 
37        return $response;
38    }
39 
40    //login -------------------------------------------
41 
42    $login_parameters = array(
43         "user_auth"=>array(
44              "user_name"=>$username,
45              "password"=>md5($password),
46              "version"=>"1"
47         ),
48         "application_name"=>"RestTest",
49         "name_value_list"=>array(),
50    );
51 
52    $login_result = call("login", $login_parameters, $url);
53 
54    /*
55    echo "<pre>";
56    print_r($login_result);
57    echo "</pre>";
58    */
59 
60    //get session id
61    $session_id = $login_result->id;
62 
63    //retrieve fields -----------------------------------
64 
65    $get_module_fields_parameters = array(
66 
67         //session id
68         'session' => $session_id,
69 
70         //The name of the module from which to retrieve records
71         'module_name' => 'Accounts',
72 
73         //Optional. Returns vardefs for the specified fields. An empty array will return all fields.
74         'fields' => array(
75             'id',
76             'name',
77         ),
78    );
79 
80    $get_module_fields_result = call("get_module_fields", $get_module_fields_parameters, $url);
81 
82    echo "<pre>";
83    print_r($get_module_fields_result);
84    echo "</pre>";
85 
86?>

Result

01stdClass Object
02(
03    [module_name] => Accounts
04    [table_name] => accounts
05    [module_fields] => stdClass Object
06        (
07            [id] => stdClass Object
08                (
09                    [name] => id
10                    [type] => id
11                    [group] =>
12                    [id_name] =>
13                    [label] => ID
14                    [required] => 1
15                    [options] => Array
16                        (
17                        )
18 
19                    [related_module] =>
20                    [calculated] =>
21                    [len] =>
22                )
23 
24            [name] => stdClass Object
25                (
26                    [name] => name
27                    [type] => name
28                    [group] =>
29                    [id_name] =>
30                    [label] => Name:
31                    [required] => 1
32                    [options] => Array
33                        (
34                        )
35 
36                    [related_module] =>
37                    [calculated] =>
38                    [len] => 150
39                )
40 
41        )
42 
43    [link_fields] => Array
44        (
45        )
46 
47)

Creating Custom Web Services In SugarCRM

I have been using web services to access Sugar for sometime now, for purposes of integration and for accessing data from a portal. While it is reasonably well documented, there are restrictions, and last week I cam across a requirement I just couldn’t meet with the standard web services methods. It was time to explore custom web services.
When I did, I suddenly realised that it was very simple to implement, and allowed me to push much of the business logic back into the server where it belongs. I could create a new method that had all sorts of complex logic,and expose the results via web services.
Now I did think that this might restrict the ability of the client software; any time it needs to access a Sugar instance, that instance needs the custom web service installed. By zipping up the custom web service as a loadable module (a topic I’ll discuss in the future as it is a very easy and powerful way to deploy any sort of customisation) this objection was quickly overcome. In any cases I would normally have access to the server when doing this type of work.
So, I have included a trivial method here, just to prove that I can. I think you will see that just about anything can go into such a method, allowing the web service to provide complex functionality to its client.
Before tackling that, lets see how the standard web service works. We will look at the version 4.1REST option from Sugar PRO 6.5.13.
service/v4_1/rest.php
You can try this in a browser directly, as follows (your url will be slightly different)
http://localhost/sugarPro6.5.13/service/v4_1/rest.php
This will show you documentation of the standard Sugar methods you can call, and their parameters.
Custom Web Service
Now our custom web service is to reside at custom/service so that it its upgrade safe. Lets look at the code, and compare it with the standard Sugar version above.
You will see we just extend the standard classes and create our own. These are below (MySugarRestService.php and MySugarRestServiceImp.php, though we could do without the first)
and MySugarRestServiceImpl.php below. You can see how it extends the Sugar class and adds a new method (getContactDetails).
Note that the method just returns hard coded values.
Accessing The Web Service
To prove that it works you need some a client. The following is very basic code to act as a client calling our new method. In a later post I will show more examples of client code, but for now this is enough to get started.
When you run that client you get the following response.
Which are just the hard coded value set in our server method.
I think that is enough to get started. I haven’t shown the login process, or how values can be retrieved from Sugar. All will have to wait for a new post.