Newsfeeds

So you're launching a new website or replacing an old one and want to make sure everything goes smoothly? This guide will give you a run-down of everything you can check to avoid common pitfalls!

Site status

You should always start by checking the status report (http://example.com/admin/reports/status). This page shows you all of the basic requirements for your Drupal site to run correctly.

Any issues will be highlighted in red and typically have a link to a configuration page or the documentation to help you resolve the problem.

Scheduled tasks

Drupal 7 will run scheduled tasks (known as cron jobs) out of the box, but only when users are visiting your site.

This is great for small sites which don't need much housekeeping, but if your site is a bit bigger or if you don't have visitors 24/7, you should set up a cron job to run periodically.

You can also look at a module such as Ultimate cron which gives you fine grained control over when each scheduled task will run.

Web services

Many web services such as Mollom or Google analytics need a domain name specific API key to use.

If you use any of these services on your website, you should ensure that you've registered your real domain name with the service and you've updated Drupal with your new API key.

Broken links

It can be easy when copying and pasting to accidentally link directly to a file or image on a development site.

These links can often stop working or perhaps worse, may direct users away from your live site and onto the development site instead.

You can use a module such as Link checker to ensure this doesn't happen, and it is good practice to password protect your development website, so that users (or more likely Google!) cannot stumble accross it.

Site optimisation

The site performance page (http://example.com/admin/config/development/performance) will allow you to configure a number of options to help optimise your Drupal site. This includes page caching and optimising CSS and JavaScript files.

See our series on High Performance in Drupal for some expert tips - High performance in Drupal Part 1: Give your site a boost and High performance in Drupal Part 2: Lightning fast code.

Development modules

Development modules such as devel can often reduce your website's performance, so it's worth turning them off on your live site. You can still keep them running in your development environment if needed.

User accounts

Many of us are guilty of using a common or simple password to make life easier when building a website.

Once the site is live, it's worth taking the time to update any administrative accounts with secure passwords.

It is also worth removing any unnecessary development accounts and content. Just in case.

Error messages

Being able to see debug messages and errors are handy when creating a site, but may scare off users once the site is live.

Ensure that errors and warnings are hidden by visiting the Logging and errors config page.

Site information

The site information config page holds all of the most common site information, such as the website name and email address.

It's worth double checking that all of this information is correct. It could be quite embarrassing if your first newsletter arrives from dev@example.com.

 

Some of these pitfalls can be avoided from the get go, if you follow a few simple principles. Check out Rick Donohoe's blog article Drupal site building 101 for some handy hints and tips on this!

Moving Drupal website clients to cloud hosting has been great as they're able to get high performance, scalable capacity at a pretty reasonable rate. However, we have discovered when clients offer an email sign-up, the emails that are generated from the cloud-hosted Drupal website are often rejected as spam. For those clients who have chosen the Rackspace cloud, here is a step-by-step solution to the problem.... Read more

This post discusses the differences between Drupal and WordPress, and also takes a quick look at a couple of other web frameworks. What are the benefits with each platform, and how do you know which one to choose?

Objective

• Create a case tracker that maintains a history of various stages of product development.
• Create a graphical representation for comparison of current status with dates as promised by the e-Commerce store/artisan.

Description

• Make a case tracker to track various stages of product development throughout, from the customer to an e-Commerce store (in case of a commissioned product).
• Provide a timeline, that is, a graphical representation of a comparison of current status of the product with the pre-decided dates as promised by the e-Commerce store or by the artisan to the customer.

Benefits

• Ease for a customer to keep informed about the current track of the product - only the manufacturing status.
• Advantage for a customer to compare the efficiency of an e-commerce store or an artisan by looking at the graphical chart of the current status of product development with that of completion dates as promised by the store.

Functionality

• Dependency – The module is dependent on product module of Ubercart.
• After installing the module, set ubercart classes on which case tracker is to be allowed with an optional timeline feature.
• View case tracker after creating a node of the set ubercart class type.

Developed by : gauravjeet_singh, itsmebhupendra
Sponsored by : OSSCube

This module create a token type called 'views'. This token can be used to embed
your views into your content.

Prerequisites

• Token
• Views

You also need the token_filter module to enable toking replacing in your node fields if you wish to use these tokens in node fields like body f.ex.

Installation

To install, copy the token_views directory and all its contents to your modules
directory.
To enable this module, visit Administration -> Modules, and enable token_views.

We are pleased to announce that Commerce Kickstart has won the Walkthrough documentation prize. The prize, which was determined by votes from Walkthrough.it backers, will use the Commerce Kickstart Drupal distribution to showcase the capabilities of Walkthrough.it.

Commerce Kickstart is the quickest way to get up and running with Drupal Commerce. The distribution provides everything to create a fully-featured demo store out of the box, complete with theme, catalog, and custom back office interface.

Simple SSO is specifically designed for Drupal sites that need a simple, intuitive and functional SSO system. The Simple SSO module can securely log in users accross several Drupal sites without needing to redirect the user to a single login form. The user always uses the login form on the site he's currently on.

Quick setup

Simple SSO comes with 2 modules, Simple SSO Client and Simple SSO Server. One Drupal site must act as the Simple SSO Server. All other Drupal sites are SSO Clients.

Simple SSO will not automatically create new users on client sites. It's up to the site administrators to make sure all users are shared amongst their Drupal sites (like using a shared user table for a multisite install).

Simple SSO uses a private key for token encryption. This key must be shared across the entire network (clients and server). The key should be added to each sites settings.php file. At the end of the file, add

<?php
$conf['simple_sso_key'] = 'YOJlYpWSO4cDW8KnnKeOYImXysLJr6nBt7f07U0'; // The longer and more random, the better.
?>

Remember that the key must be the same for all sites (tip: you can store this key in a plain text file outside the webroot for more security. In that case, just do $conf['simple_sso_key'] = file_get_contents('/path/to/key.txt');).

For each client site, go to the settings page and set the address for the SSO Server site and you're good to go. Simple SSO will automatically start logging in users across your site network.

this modules add the goenames api to the geocoder using ctools.

This module will enhance the editor experience by providing a great menu for editors

Field as Block is a lightweight module that allows you to display a field as a block. The same results can be achieved by using Panels, Display Suite or custom code but this module offers a lightweight alternative.

CCK Blocks offers similar functionality, however on the project page they recommend that you use Field as Block for new projects. It looks like CCK Blocks will be deprecated in favour of Field as Block. For more details read issue #1920636 (comment #4).

Review Token provides a tokenised URL for bypassing access restrictions on unpublished content.

It can be used to provide per-node access for unpublished content to users without logins, though a specially crafted URL.

Currently incompatible with modules which provide workflowed versioning, as the module will load the current published content, rather than a specific draft.

This module was originally created by Boztek.

Sponsored by the Australian Government Department of Sustainability, Environment, Water, Population and Communities.

This modules provides an api and set of tools for creating flexible content types, taxonomy terms, and their respective fields and field groups. Although the base functionality is similar to what is offered by Features, these tools are entirely maintained in simple to create/edit/update yaml files with only as much information as is needed; there is no need to alter fields or content types in the UI and then recompile; just alter or add a setting in the code, rebuild the content type or taxonomy vocabulary, and you're done. When utilized to it's fullest potential, this module provides a code-based alternative to the Field UI.

Today Google announced PHP support for Google App Engine! I have been one of the lucky folks who had early access and so of course I worked on getting Drupal up and running on GAE. There are a few things that still need to be worked out which I will continue to discuss with the app engine team, but I have a working Drupal setup which I will detail below. Note that much of this may also apply to other PHP frameworks.

Getting up and running

I will cover the steps specific to getting Drupal 7 (notes for Drupal 6 along with branches in repository) up and running on App Engine and not how to use the SDK and development flow which is detailed in the documentation. For an example (minimal profile from core) of Drupal running on Google App Engine see boombatower-drupal.appspot.com.

Sign up to be whitelisted for PHP runtime

Currently, the PHP runtime requires you to sign up specifically for access. Assuming you have access you should be able to follow along with the steps below. Otherwise, the following steps will give you a feel for what it takes to get Drupal running on GAE.

Create an app

Create app by visiting appengine.google.com and clicking Create Application, see the documentation for more details.

Create a Cloud SQL Instance

Follow the documentation for setting up a Cloud SQL Instance. Be sure to give your application access to the instance.

Once the instance has been created select the SQL Prompt tab and create a database for your Drupal site as follows.

CREATE DATABASE drupal;

Download Drupal

There are a few tweaks that need to be made to get Drupal to run properly on GAE which are explained below, but for the purposes of this walk-through one can simply download my branch containing all the changes from github.

git clone --branch 7.x-appengine https://github.com/boombatower/drupal-appengine.git   # or for Drupal 6 git clone --branch 6.x-appengine https://github.com/boombatower/drupal-appengine.git

or download as a zip or for Drupal 6 download as a zip.

Configure Drupal database settings

Since GAE does not allow the filesystem to be writeable one must configure the database settings ahead of time.

Copy default.settings.php as settings.php and add the following bellow <?php $databases = array(); ?> around line 213.

<?php
$databases = array();
$databases['default']['default'] = array(
  'driver' => 'mysql',
  'database' => 'drupal', // The database created above (example used 'drupal').
  'username' => 'root',
  'password' => '',
  // Setting the 'host' key will use a TCP connection which is not supported by GAE.
  // The name of the instance created above (ex. boombatower-drupal:drupal).
  'unix_socket' => '/cloudsql/[INSTANCE]',
//  'unix_socket' => '/cloudsql/boombatower-drupal:drupal',
  'prefix' => '',
);
?>

For Drupal 6 around line 91.

<?php
$db_url = 'mysql://root:@cloudsql__boombatower-drupal___drupal/drupal';
?> Push to App Engine

Update the application name in the app.yaml file to the one you created above and upload by following the documentation.

# See https://developers.google.com/appengine/docs/php/config/appconfig.   application: drupal # <-- change this to your application version: 1 runtime: php api_version: 1 threadsafe: true   handlers: # Default handler for requests (wrapper which will forward to index.php). - url: / script: wrapper.php   # Handle static requests. - url: /(.*\.(ico$|jpg$|png$|gif$|htm$|html$|css$|js$)) # Location from which to serve static files. static_files: \1 # Upload static files for static serving. upload: (.*\.(ico$|jpg$|png$|gif$|htm$|html$|css$|js$)) # Ensures that a copy of the static files is left for Drupal during runtime. application_readable: true   # Catch all unhandled requests and pass to wrapper.php which will simulate # mod_rewrite by forwarding the requests to index.php?q=... - url: /(.+) script: wrapper.php appcfg.py update drupal/ Install

Visit your-app.appspot.com/install.php and follow the installation steps just as you would normally except that the database information will already be filled in. Go ahead and ignore the mbstring warning and note that the GAE team is looking into supporting mbstring.

Explanation of changes

If you are interested in what changes/additions were made and the reasons for them continue reading, otherwise you should have a working Drupal install ready to explore! There are a few basic things that do not work perfectly out of the box on GAE. The changes can be seen by diffing the 7.x-appengine branch against the 7.x branch in my repository.

File directory during installation

The Drupal installer requires that the files directory be writeable, but GAE does not allow for local write access thus the requirement must be bypassed in order for the installation to complete.

Author: boombatower <boombatower@google.com> Date: Wed May 15 15:49:03 2013 -0700   Hack to trick Drupal into ignoring that file directory is not writable.   diff --git a/modules/system/system.install b/modules/system/system.install index 1b037b8..9931aad 100644 --- a/modules/system/system.install +++ b/modules/system/system.install @@ -333,6 +333,8 @@ function system_requirements($phase) { } $is_writable = is_writable($directory); $is_directory = is_dir($directory); + // Force Drupal to think the directories are writable during installation. + $is_writable = $is_directory = TRUE; if (!$is_writable || !$is_directory) { $description = ''; $requirements['file system']['value'] = $t('Not writable'); Clean URLs

In order to take advantage of clean urls, of which most sites take advantage, mod_rewrite is required for Apache environments. Since GAE does not use Apache it does not support mod_rewrite and thus another solution is needed. The app.yaml can configure handlers which allow for wildcard matching which means multiple paths can easily be routed to a single script. Taking that one step further we can alter the <?php $_GET['q']?> variable just as mod_rewrite would so that Drupal functions properly. Rather than modify core this can be done via a wrapper script as show below (this should work well for other PHP applications).

<?php
/**
 * @file
 * Provide mod_rewrite like functionality and correct $_SERVER['SCRIPT_NAME'].
 *
 * Pass through requests for root php files and forward all other requests to
 * index.php with $_GET['q'] equal to path. In terms of how the requests will
 * seem please see the following examples.
 *
 * - /install.php: install.php
 * - /update.php?op=info: update.php?op=info
 * - /foo/bar: index.php?q=/foo/bar
 * - /: index.php?q=/
 */

$path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);

// Provide mod_rewrite like functionality. If a php file in the root directory
// is explicitely requested then load the file, otherwise load index.php and
// set get variable 'q' to $_SERVER['REQUEST_URI'].
if (dirname($path) == '/' && pathinfo($path, PATHINFO_EXTENSION) == 'php') {
  $file = pathinfo($path, PATHINFO_BASENAME);
}
else {
  $file = 'index.php';

  // Provide mod_rewrite like functionality by using the path which excludes
  // any other part of the request query (ie. ignores ?foo=bar).
  $_GET['q'] = $path;
}

// Override the script name to simulate the behavior without wrapper.php.
// Ensure that $_SERVER['SCRIPT_NAME'] always begins with a / to be consistent
// with HTTP request and the value that is normally provided (not what GAE
// currently provides).
$_SERVER['SCRIPT_NAME'] = '/' . $file;
require $file;
?> PHP $_SERVER['SCRIPT_NAME'] variable

The <?php $_SERVER['SCRIPT_NAME'] ?> implementation differs from Apache mod_php implementation which can cause issues with a variety of PHP applications. The variable matches the HTTP spec and not the filesystem when called through Apache.

For example a script named foo.php contains the following.

<?php
var_dump($_SERVER['SCRIPT_NAME']);
?>

When executed from command line here are the results.

$ php foo.php string(7) "foo.php"   $ php ./foo.php string(9) "./foo.php"

When invoked through Apache like http://example.com/foo.php.

string(8) "/foo.php"

The documentation does not talk about this behavior (although many comments demonstrated the expected Apache behavior), but it is definitely depended on.

The difference causes Drupal to format invalid URLs.

example.com.foo.css (instead of ...com/foo.css) example.comsubdir/foo.css (instead of ...com/subdir/foo.css)

Drupal derives the URL from <?php dirname() ?> of <?php $_SERVER['SCRIPT_NAME'] ?> which will return . if no slashes or just / for something like /index.php.

The wrapper script above solves this by ensuring that the SCRIPT_NAME variable alway starts with a leading slash.

HTTP requests

GAE does not yet support support outbound sockets for PHP (although supported for Python and Java) and if/when it does the preferred way will continue to be streams due to automatic caching of outbound requests using urlfetch. I have included a small change to provide basic HTTP requests through drupal_http_request(). A proper solution would be to override the drupal_http_request_function variable and provide a fully functional alternative using streams. Drupal 8 has converted drupal_http_request() to use Guzzle which supports streams. Making a similar conversion for Drupal 7 seems like the cleanest way forward rather than reinventing the change.

php.ini

GAE disables a number of functions for security reasons, but only softly disables some functions which may then be enabled. Drupal provides access to phpinfo() from admin/reports/status and uses output buffering, both of which are disabled by default. The included php.ini enables both functions in addition to getmypid which is used by drupal_random_bytes().

# See https://developers.google.com/appengine/docs/php/config/php_ini.   # Required for ob_*() calls which you can find by grepping. # grep -nR '\sob_.*()' . output_buffering = "1"   # See https://developers.google.com/appengine/docs/php/runtime#Functions-That-Must-Be-Manually-Enabled # phpinfo: Provided on admin/reports/status under PHP -> "more information". # getmypid: Used by drupal_random_bytes(), but not required. google_app_engine.enable_functions = "getmypid, phpinfo" Future

I plan to continue working with the GAE team to ensure that support for Drupal can be provided in a clean and simple manner. Once current discussions have been resolved I hope to provide more formal documentation and support for Drupal.

File handling

I worked on file support, but there were a number of upcoming changes that would make things much cleaner so I decided to wait. GAE provides a stream wrapper for Google Cloud Storage which makes using the service very simple. Assuming you have completed the prerequisites files on GCS may be accessed using standard PHP file handling functions as shown in the documentation.

<?php
$file = 'gs://my_bucket/hello.txt';
file_put_contents($file, 'hello world');

$contents = file_get_contents($file);
var_dump($contents); // prints: hello world
?>

Unfortunately, the wrapper does not currently support directories nor does file_exists() work properly. Keep in mind that the filesystem is flat so a file may be written to any path without explicitly creating the directory. Meaning one can write to gs://bucket/foo/bar.txt without creating the directory foo. With that being the case it is possible to get some hacky support by simply disabling all the directory code in Drupal, but not really usable. It should be possible to hack support in through the stream wrapper since directories are simply specially name files, but the app engine team has indicated they will look into the matter so hopefully this will be solved cleanly.

Assuming the stream wrappers are fixed up then support can be added in much the same way as that Amazon S3 support is added except that no additional library will be needed.

Additionally, the documentation also notes the following.

Direct file uploads to your POST handler, without using the App Engine upload agent, are not supported and will fail.

In order to support file uploads the form must be submitted to the url provided by CloudStorageTools::createUploadUrl() and the forwarded result handled by Drupal. A benefit of proxying requests through uploader service is that uploaded files may be up to 100TB in size.

Other

There are a number of additional services provided as part of GAE of which Drupal could take advantage.

• Task Queue API
• Google account authentication
• Memcache seems to work out of the box with the memcache module
• <?php $SERVER['HTTP_X_APPENGINE*'] ?> variables (like geo information) Large number of services in API Console

Closing

Hopefully this will be useful in getting folks up and running quickly on GAE with Drupal and understanding the caveats of the environment. Obviously there is a lot more to cover and I look forward to seeing what others publish on the matter.

Tags:

• drupal
• drupal 6
• drupal 7
• google
• google app engine

A look at Storm Fleet and its enemies.

This is a simple module that wraps around a php translation of the reddit api. Upon activation, Redditview creates a block that will pull in a set number of the most popular items from the users subreddit of choice, including the item title, preview thumb (if available - with link to original image), and a link to the comments associated with the subreddit item. The api can be extended much further to include commenting from drupal, upvote count, etc.

Once activated, this module creates a db table that is populated with:

1. Reddit Username
2. Reddit password
3. subreddit name
4. Number of posts to return

The form is found here: /redditview/form-fill

I intend to develop this module more and add features to include upvote count, commenting, as well as views integration, and js prettifying. Right now, I'm placing this rudimentary implementation to gauge interest in this project / module.

This module integrates with the liveDocx third party service for generating dynamic microsoft word and pdf documents. For templates this module uses a docx file, supplied by the user, with mail merge fields for variables. This module is currently under development and the initial proof of concept was sponsored by Forum One Communications.

Credit goes to Eric (Last Name?) and his blog post here for a great start to the proof of concept.

Road Map Items:
coming soon!

Come meet Drupal.org team in person at DrupalCon Portland!

We’re hard at work upgrading Drupal.org to Drupal 7. DrupalCon is a perfect opportunity for you to find out what is going on with the upgrade, give us feedback on the new issue page layout and, of course, help us in the issue queue.

Where to find us:

• Weekend before DrupalCon - We are taking part in the extended sprints, come and help us close some issues
• Tuesday, May 21, 4:30pm - We’re having a BoF, Drupal.org improvements and D7 upgrade (Room B112)
• Wednesday, May 22 at 6pm - I’m presenting D7 upgrade report at the Drupal Association board meeting
• Thursday, May 23, 10:15am-1:15pm - I’ll be at the Drupal Association booth in the Exhibit Hall’s Community Village
• Friday, May 24 - We'll be closing more issues at the Contribution Sprint

Come and learn how you can help out with development, site building, or QA!

This is my personal version of Devel, which utilises Devel functions in a slightly different way.

It's main use is to provide an analogue to dpm(), xdump().

The key differences are:

• xdump() does not try to guess whether your data should use krumo or not, and this will properly differentiate between FALSE, 0 and NULL, and give you line numbers for text dumps
• xdump() can be used within batch processes or other places dpm() will turn itself off

Though patches are welcome this module is largely unsupported and may break at any time, but if you know what it does that probably wont bother you.

API

<?php
// Dump a variable to messages.
xdump($some_var, $name = NULL, $type = 'status');

// Dump using KrumoNG (if installed)
xkng($args);

// Dump using Kint (if installed)
xkint($data, $type = 'status');

// Export a human-readable CSV of all modules and their installed state.
//
// This should be called from devel/php, as it will spit out a CSV file.
xdevel_module_list_csv();
?>

Here are the highlights from a few of the conversations I had with attendees of the 2013 Drupal Camp Alpe-Adria, held in April in Ljubljana, Slovenia. The camp was a wild success and attracted a large, international crowd. I'll post a couple more interviews I did at this event in coming weeks.

alpe-adria-voices.mp3

This module will allow you change the view mode of an entity via Context module. A reaction will also be available.

(See #1221892: Context module integration)