Install PECL uploadprogress on Ubuntu 12.04 to 22.04

If saw this warning in your site's status report:

Your server is capable of displaying file upload progress, but does not have the required libraries. It is recommended to install the PECL uploadprogress library.

… googled for a solution, and arrived here, then please read this core issue: #2718253: Uploadprogress PECL, documentation and recommendation on status report.

Learn PHP programming basics

The goal of these videos is to prepare those who are newer to programming with the tools they need to eventually code in Drupal.

Introduction and getting a simple development environment set up

Services 7.x-3.3, REST Server using 2-Legged OAuth in PHP, OAuth 7.x-3.x-dev

The Drupal REST services is an user-created module for Drupal 7 and 6.

The module converts resources on Drupal sites - content types - into REST, XMLRPC, JSON, JSON-RPC, SOAP, AMF and other types for easy parsing by external applications.

It can also enable Drupal sites to accept CRUD operations to modify resources.

The requests between Drupal and external applications can have authentications via OAuth.

Installation

  1. Install Services module 7.x-3.3 - http://drupal.org/project/services
  2. Install Services Views module 7.x-1.0-beta2 - http://drupal.org/project/services_views
  3. Enable both modules and the REST server module.
  4. Install OAuth 7.x-3.0+18-dev - http://drupal.org/project/oauth (You must use this version because the recommended version - 7.x-3.0 - is bugged)

Note:
The Libraries module must be at least version 7.x-2.0 for REST server.

Config

This is a two-stage process.
First, make a Service Endpoint that hosts REST resources; it is seen as the first part of the URL to your resource.
Next, make a REST resource, which is a View customized by the Services View module; in it, you specify which Content Types are included.
Authentication is configured afterwards.

Config Endpoint / View without OAuth

Testing a three-legged and two-legged OAuth REST, using Services 7.x-3.2 and Oauth 7.x-3.0, with PHP Client

Here I will post all my system settings and configurations to test it out.

Prerequisite

System

  • CentOS 6.3
  • PHP 5.3.18
  • PECL Oauth extension (via command pecl install oauth)
  • Drupal-7.17
  • Server URL: http://core.zeus.lan (you can use any URL BUT You SHOULD really going for HTTPS)
  • Client URL: http://localhost/oauth.php (this will be used below)

Modules

Step-by-Step

I use location sites/all/modules/contrib for my drupal modules.

Services Configuration

First we set up the services with oauth.

  1. In Drupal site, install modules: REST Server, OAuth Authentication, OAuth Provider UI.
  2. In Drupal directory, comment out line 6 to 8 in file oauth/lib/OAuth.php, since it will conflict with PECL OAuth.
  3. In Drupal site, Create OAuth context in admin/config/services/oauth/add, make sure to create Authorization level and set as default.

Clientside Validation API

PHP

Some modules allow users to define extra validation rules defined in a hook. (e.g hook_webform_validation_validators()). To support these custom rules, clientside validation has its own hook, hook_clientside_validation_rule_alter. We had to use an 'alter' hook because module_invoke and module_invoke_all does not support passing arguments by reference, drupal_alter does.

If you want to add support for your custom validation rules defined for webform_validation, fapi_validation or field_validation, you can use this hook. Every validation rule that is defined for any of these modules and is not implemented as standard by clientside_validation is passed through to this hook (given that the related clientside validation module is enabled and that clientside validation is enabled for the specific form).

The first parameter to this hook is an array. This array, consitently named $js_rules, is passed by reference throughout the entire module and is the key to the entire functionality of this module.

The second parameter is the form element or webform component (dependend on third parameter)

The third parameter, named $context, is a structured array. It consists of the following keys:

  • 'type': The type of form validation we are dealing with. Can be either 'webform', 'fapi', 'field_validation' or 'element_validate'.

Clientside Validation Code Examples

Creating custom validation rules

Webform

Let's say you have written a custom PHP validator for the Webform Validation module that looks like this (assuming your custom module is named potpourri):

potpourri.module

/**
 * Implementation of hook_webform_validation_validators().
 */
function potpourri_webform_validation_validators() {
  return array(
    'phonefield' => array(
      'name' => "Phonefield",
      'component_types' => array(
        'textfield',
      ),
            'description' => 'Check phone number'
    )
  );
}

/**
 * Implementation of hook_webform_validation_validate().
 */
function potpourri_webform_validation_validate($validator_name, $items, $components, $rule) {
  if ($items) {
        $errors = array();
    switch ($validator_name) {
      case 'phonefield':
                foreach ($items as $key => $val) {
          if ($val && (!isTelefon($val))) {
            $errors[$key] = t("%value is not a telephone.", array('%value' => $val));
          }
        }
        return $errors;
        break;
    }
  }
}

/**
 * Validation callback function.
 */
function isTelefon($text) {
    return preg_match('/^(\+){0,1}(\([0-9]+\))?[0-9_\-\/]{6,}$/', str_replace(' ', '', $text));
}

Pages

Subscribe with RSS Subscribe to RSS - php