opdavies/oliverdavies.uk-old-sculpin
Archived
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity

Started adding posts

Browse source
This commit is contained in:
Oliver Davies 2015-03-16 11:22:24 +00:00
parent c87a353705
commit 661eaae6c9
7 changed files with 353 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

58
source/_posts/2012-07-14-install-nomensa-media-player-drupal.md Normal file
View file

@ -0,0 +1,58 @@
---
title: Install and Configure the Nomensa Accessible Media Player in Drupal
slug: install-nomensa-media-player-drupal
tags:
- Accessibility
- Drupal
- Drupal Planet
- Nomensa
---
*The official documentation for this module is now located at <https://www.drupal.org/node/2383447>. This post was accurate at the time of writing, whereas the documentation page will be kept up to date with any future changes.*
This week I released the first version of the Nomensa Accessible Media Player module for Drupal 7. Here's some instructions of how to install and configure it.
## Initial configuration
### Download the Library
The library can be downloaded directly from GitHub, and should be placed within you *sites/all/libraries/nomensa_amp* directory.
~~~~
drush dl libraries nomensa_amp
git clone https://github.com/nomensa/Accessible-Media-Player sites/all/libraries/nomensa_amp
cd sites/all/libraries/nomensa_amp
rm -rf Accessible-media-player_2.0_documentation.pdf example/ README.md
drush en -y nomensa_amp
~~~~
### Configure the Module
Configure the module at <em>admin/config/media/nomensa-amp</em> and enable the players that you want to use.
## Adding videos
Within your content add links to your videos. For example:
### YouTube
<a href="http://www.youtube.com/watch?v=Zi31YMGmQC4">Checking colour contrast</a>
### Vimeo
<a href="http://vimeo.com/33729937">Screen readers are strange, when you're a stranger by Leonie Watson</a>
## Adding captions
The best way that I can suggest to do this is to use a File field to upload your captions file:
1. Add a File field to your content type;
2. On your page upload the captions file.
3. Right-click the uploaded file, copy the link location, and use this for the path to your captions file.
For example:
<a href="http://www.youtube.com/watch?v=Zi31YMGmQC4">Checking colour contrast</a> <a class="captions" href="http://oliverdavies.co.uk/sites/default/files/checking-colour-contrast-captions.xml">Captions for Checking Colour Contrast</a>
## Screencast
<a class="player" href="http://vimeo.com/45731954">Nomensa Accessible Media Player for Drupal</a>

56
source/_posts/2013-01-09-checking-if-user-logged-drupal-right-way.md Normal file
View file

@ -0,0 +1,56 @@
---
title: Checking if a user is logged into Drupal (the right way)
description: How to check if a user is logged into Drupal by using the user_is_logged_in() and user_is_anonymous() functions.
tags:
- Drupal
- Drupal 6
- Drupal 7
- Drupal Planet
- PHP
---
I see this regularly when working on Drupal sites when someone wants to check whether the current user is logged in to Drupal (authenticated) or not (anonymous):
~~~~
global $user;
if ($user->uid) {
// The user is logged in.
}
~~~~
or
~~~~
global $user;
if (!$user->uid) {
// The user is not logged in.
}
~~~~
The better way to do this is to use the [user_is_logged_in()](http://api.drupal.org/api/drupal/modules!user!user.module/function/user_is_logged_in/7) function.
~~~~
if (user_is_logged_in()) {
// Do something.
}
~~~~
This returns a boolean (TRUE or FALSE) depending or not the user is logged in. Essentially, it does the same thing as the first example, but there's no need to load the global variable.
A great use case for this is within a `hook_menu()` implementation within a custom module.
~~~~
/**
* Implements hook_menu().
*/
function mymodule_menu() {
$items['foo'] = array(
'title' => 'Foo',
'page callback' => 'mymodule_foo',
'access callback' => 'user_is_logged_in',
);
return $items;
}
~~~~
There is also a [user_is_anonymous()](http://api.drupal.org/api/drupal/modules!user!user.module/function/user_is_anonymous/7) function if you want the opposite result. Both of these functions are available in Drupal 6 and higher.

46
source/_posts/2013-11-19-dont-bootstrap-drupal-use-drush.md Normal file
View file

@ -0,0 +1,46 @@
---
title: Don't Bootstrap Drupal, Use Drush
tags:
- Drush
- Drupal Planet
- PHP
---
There are times when doing Drupal development when you need to run a custom PHP script, maybe moving data from one field to another, that doesn't warrant the time and effort to create a custom module. In this scenario, it would be quicker to write a .php script and bootstrap Drupal to gain access to functions like `node_load()` and `db_query()`.
To bootstrap Drupal, you would need to add some additional lines of code to the stop of your script. Something like:
~~~php
<?php
// Bootstrap Drupal.
$drupal_path = $_SERVER['DOCUMENT_ROOT'];
define('DRUPAL_ROOT', $drupal_path);
require_once DRUPAL_ROOT . '/includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
// Do stuff.
$node = node_load(1);
~~~
The script would need be placed in the root of your Drupal directory, and you would then have had to open a browser window and visit http://example.com/foo.php to execute it. This is where the "drush php-script" command (or "drush scr" for short) is useful, and can be used to execute the script from the command line.
$ drush scr foo.php
It also means that I no longer need to manually bootstrap Drupal, so my script is much cleaner.
~~~~
<?php
// Just do stuff.
$node = node_load(1);
~~~~
I prefer to keep these scripts outside of my Drupal directory in a separate "scripts" directory (with Drupal in a "drupal" directory on the same level). This makes it easier to update Drupal as I don't need to worry about accidentally deleting the additional files. From within the drupal directory, I can now run the following command to go up one level, into the scripts directory and then execute the script. Note that you do not need to include the file extension.
$ drush scr ../scripts/foo
Or, if you're using [Drush aliases](http://deeson-online.co.uk/labs/drupal-drush-aliases-and-how-use-them "Drupal, Drush aliases, and how to use them"):
$ drush @mysite.local scr foo
If you commonly use the same scripts for different projects, you could also store these within a separate Git repository and checkout the scripts directory using a [Git submodule](http://git-scm.com/book/en/Git-Tools-Submodules "Git Submodules").

32
source/_posts/2014-11-20-using-remote-files-when-developing-locally-stage-file-proxy-module.md Normal file
View file

@ -0,0 +1,32 @@
---
title: Using Remote Files when Developing Locally with Stage File Proxy Module
tags:
- Drupal
- Drupal Planet
- Servers
---
Download the [Stage File Proxy](https://www.drupal.org/project/stage_file_proxy) module from Drupal.org and enable it on your site.
As this module is only going to be needed on pre-production sites, it would be better to configure this within your settings.php or settings.local.php file. We do this using the `$conf` array which removes the need to configure the module through the UI and store the values in the database.
~~~php
// File proxy to the live site.
$conf['stage_file_proxy_origin'] = 'http://www.example.com';
~~~
~~~php
// Don't copy the files, just link to them.
$conf['stage_file_proxy_hotlink'] = TRUE;
~~~
~~~php
// Image style images are the wrong size otherwise.
$conf['stage_file_proxy_use_imagecache_root'] = FALSE;
~~~
If the origin site is not publicly accessible yet, maybe it's a pre-live or staging site, and protected with a basic access authentication, you can include the username and password within the origin URL.
~~~php
$conf['stage_file_proxy_origin'] = 'http://user:password@prelive.example.com';
~~~

75
source/_posts/2014-11-27-pantheon-settings-files.md Normal file
View file

@ -0,0 +1,75 @@
---
title: Include environment-specific settings files on Pantheon
slug: pantheon-settings-files
tags:
- Drupal
- Drupal Planet
- Pantheon
- settings.php
---
I was recently doing some work on a site hosted on [Pantheon](http://getpantheon.com) and came across an issue, for which part of the suggested fix was to ensure that the `$base_url` variable was explicitly defined within settings.php (this is also best practice on all Drupal sites).
The way that was recommended was by using a `switch()` function based on Pantheon's environment variable. For example:
~~~php
switch ($_SERVER['PANTHEON_ENVIRONMENT']) {
case 'dev':
// Development environment.
$base_url = 'dev-my-site.gotpantheon.com';
break;
case 'test':
// Testing environment.
$base_url = 'test-my-site.gotpantheon.com';
break;
case 'live':
// Production environment.
$base_url = 'live-my-site.gotpantheon.com';
break;
}
~~~
Whilst this works, it doesn't conform to the DRY (don't repeat yourself) principle and means that you also might get a rather long and complicated settings file, especially when you start using multiple switches and checking for the value of the environment multiple times.
My alternative solution to this is to include an environment-specific settings file.
To do this, add the following code to the bottom of settings.php:
~~~php
// If using Pantheon, include an environment-specific settings file, for example
// settings.dev.php, if one exists.
if (isset($_SERVER['PANTHEON_ENVIRONMENT'])) {
$environment_settings = __DIR__ . '/settings.' . $_SERVER['PANTHEON_ENVIRONMENT'] . '.php';
if (file_exists($environment_settings)) {
include $environment_settings;
}
}
~~~
This means that rather than having one long file, each environment has it's own dedicated settings file that contains it's own additional configuration. This is much easier to read and make changes to, and also means that less code is loaded and parsed by PHP. Settings that apply to all environments are still added to settings.php.
Below this, I also include a similar piece of code to include a settings.local.php file. The settings.php file then gets committed into the [Git](http://git-scm.com) repository.
Within the sites/default directory, I also include an example file (example.settings.env.php) for reference. This is duplicated, renamed and populated accordingly.
~~~php
<?php
/**
* This is a specific settings file, just for the x environment. Any settings
* defined here will be included after those in settings.php.
*
* If you have also added a settings.local.php file, that will override any
* settings stored here.
*
* No database credentials should be stored in this file as these are included
* automatically by Pantheon.
*/
$base_url = '';
~~~
The environment specific files are also committed into Git and pushed to Pantheon, and are then included automatically on each environment.

39
source/_posts/2014-12-20-include-local-drupal-settings-file-environment-configuration-and-overrides.md Normal file
View file

@ -0,0 +1,39 @@
---
title: Include a Local Drupal Settings file for Environment Configuration and Overrides
tags:
- Drupal
- Drupal 6
- Drupal 7
- Drupal 8
- Drupal Planet
- settings.php
---
At the bottom of settings.php, add the following code:
~~~php
$local_settings = __DIR__ . '/settings.local.php';
if (file_exists($local_settings)) {
include $local_settings;
}
~~~
This allows for you to create a new file called settings.local.php within a sites/* directory (the same place as settings.php), and this will be included as an extension of settings.php. You can see the same technique being used within Drupal 8's [default.settings.php](http://cgit.drupalcode.org/drupal/tree/sites/default/default.settings.php#n621) file.
Environment specific settings like `$databases` and `$base_url` can be placed within the local settings file. Other settings like `$conf['locale_custom_strings_en']` (string overrides) and `$conf['allow_authorize_operations']` that would apply to all environments can still be placed in settings.php.
settings.php though is ignored by default by Git by a .gitignore file, so it won't show up as a file available to be committed. There are two ways to fix this. The first is to use the `--force` option when adding the file which overrides the ignore file:
git add --force sites/default/settings.php
The other option is to update the .gitignore file itself so that settings.php is no longer ignored. An updated .gitignore file could look like:
~~~
# Ignore configuration files that may contain sensitive information.
sites/*/settings.local*.php
# Ignore paths that contain user-generated content.
sites/*/files
sites/*/private
~~~
This will allow for settings.php to be added to Git and committed, but not settings.local.php.

47
source/_posts/2014-12-22-configuring-the-reroute-email-module.md Normal file
View file

@ -0,0 +1,47 @@
---
title: Configuring the Reroute Email Module
tags:
- Drupal
- Drupal 6
- Drupal 7
- Drupal Planet
- Email
draft: true
---
[Reroute Email](https://www.drupal.org/project/reroute_email) module uses `hook_mail_alter()` to prevent emails from being sent to users from non-production sites. It allows you to enter one or more email addresses that will receive the emails instead of delivering them to the original user.
> This is useful in case where you do not want email sent from a Drupal site to reach the users. For example, if you copy a live site to a test site for the purpose of development, and you do not want any email sent to real users of the original site. Or you want to check the emails sent for uniform formatting, footers, ...etc.
As we don't need the module configured on production (we don't need to reroute any emails there), it's best to do this in code using settings.local.php (if you have one) or the standard settings.php file.
The first thing that we need to do is to enable rerouting. Without doing this, nothing will happen.
~~~php
$conf['reroute_email_enable'] = TRUE;
~~~
The next option is to whether to show rerouting description in mail body. I usually have this enabled. Set this to TRUE or FALSE depending on your preference.
~~~php
$conf['reroute_email_enable_message'] = TRUE;
~~~
The last setting is the email address to use. If you're entering a single address, you can add it as a simple string.
~~~php
$conf['reroute_email_address'] = 'person1@example.com';
~~~
In this example, all emails from the site will be rerouted to person1@example.com.
If you want to add multiple addresses, these should be added in a semicolon-delimited list. Whilst you could add these also as a string, I prefer to use an array of addresses and the `implode()` function.
~~~php
$conf['reroute_email_address'] = implode(';', array(
'person1@example.com',
'person2@example.com',
'person3@example.com',
));
~~~
In this example, person2@example.com and person3@example.com would receive their emails from the site as normal. Any emails to addresses not in the array would continue to be redirected to person1@example.com.