Regarding Tech Support

Extending Statamic’s Raven ‘From Name’

16th September 2014

I’ve recently integrated Raven Forms into my Statamic website and adding some new features as well as extending some existing ones: namely the feedback form. (More to come shortly)

I had been using Eric Barnes excellent email_form which uses the standard PHP Mailer however Raven gives me a bit for flexibility in a lot of other areas and supports third party transactional email services. There was one thing that annoyed me with Raven though: when sending emails through it and Mandrill (my transactional email service of choice) the "From Name" was absent and all I got was an email address.

Given that A) the standard PHP Mailer supported this via Erics add-on in my previous implementation, B) a bit of research showed that Mandrill supports this as standard, and C) the little details like that bug the crap out of me; it was time to do something about it.

Hack The Core Code

Would I do such a thing? Apparently so. Ignoring some of my own advice previously whereby modifying core files on a platform that you don’t own/control is a recipe for long-term disaster and that I’m unlikely to perform the sorts of regression testing the Statamic team would do, push that to one side, stick your fingers in your ears and let’s hack…

Note: All line number references are for v1.8.4 of Statamic which is current at time of publishing, although the last modified date of most of these files goes back several revisions.

FILE: _app/core/api/email.php

Around Line 26:

public static $allowed = array('to', 'from', 'subject', 'cc', 'bcc', 'headers', 'text', 'html', 'email_handler', 'email_handler_key');

Becomes: (by adding ‘fromname’,)

 public static $allowed = array('to', 'from', 'fromname', 'subject', 'cc', 'bcc', 'headers', 'text', 'html', 'email_handler', 'email_handler_key');

Around Line 103: Insert:

$email->setFromName($attributes['fromname']);

Around Line 187:

$email->FromName = $attributes['from'];

Becomes: (by adding ‘name’)

$email->FromName = $attributes['fromname'];

Around Line 271 add:

/**
 * Message fromname address
 * @var string
 */
public $fromname = "";

Around Line 354 add the Setter/Getters:

/**
 * Sets the fromname of the message
 *
 * @param string $from
 * @return void
 */
public function setFromName($fromname)
{
    $this->fromname = $fromname;
}

/**
 * Gets the fromname of the message
 *
 * @return string
 */
public function getFromName()
{
    return $this->fromname;
}

FILE: _app/vendor/Stampie/MessageInterface.php

Around Line 18 add the Getter:

/**
 * @return string
 */
function getFromName();

FILE: _app/vendor/Stampie/Message.php

Around Line 101 add the Getter:

/**
 * @return string
 */
public function getFromName()
{
    return $this->getFromName();
}

FILE: _app/vendor/Stampie/Mailer/Mandrill.php

Around Line 59 add the Getter:

'from_name'   => $message->getFromName(),

YAML

Once all that has been updated (it’s really not that much in the grand scheme of things) all you need to do is add something like this to your Raven YAML formset:

email:
  fromname: "John Chidgey"

Some notes to bear in mind:

  • I’ve only looked into Mandrill: the other supported mailers are your problem to figure out if you’re going to use them instead. The process should be very similar.
  • Hacking the Vendor add-on and the Core Statamic Email Library is kinda a bad idea. I know, I know already…
  • I’ve raised a feature request at The Lodge but I’m impatient okay?
  • No warranty is provided, implied, or any other disclaimer you might choose to think of: Insert disclaimer here. Don’t cry to me if something breaks after doing this you good for nothing hacker.
  • Hackin’s…hackin’s bad…mmm-kay?

Codium Extend Child Theme Headers: Taking Control

9th June 2012

If you’re like me and you like using WordPress you may want to modify the themes that are commonly used and customise them to your own liking. The WordPress supplied themes TwentyTen, TwentyEleven are quite commonly used and there is a lot of support for them on WordPress’ own site but those suggestions won’t help if you are using a different theme: such as Codium-Extend that already includes a customisable header.

It is generally considered to be bad practice to modify existing themes mainly because their complexity sometimes leads to bugs that require patching/updating and hence your updates to the parent theme can be wiped out by a single careless "yes I’ll update that theme" moment one late night. Of course you could just resolve to NEVER update your theme but there may be a time when you really want that new feature or bug fix and you have to update the parent theme. In these cases and for best practice it’s best to create a child theme and update the style.css file as you see fit. In my case this wasn’t enough as there were functions called in my theme of choice that could not be over-ridden by modifying the style.css file.

Presented with the issue of updating the header of a codium-extend themed site I spent a lot of time both searching and learning how WordPress have implemented their PHP/CSS before I came up with the following solution - which I might add was not actually presented in full on any one site I found in my searching.

Before I go on I need to say that this is likely not the only solution nor is it necessarily the best solution I know only that it works well for me on my site.

The way codium-extend creates its custom header is by using the function add_custom_image_header() and it references two functions to do so: codium_extend_header_style() and codium_extend_admin_header_style(). These are all located in the functions.php file in the parent theme (codium-extend). Since you can’t redefine previously defined variables and since you can’t over-ride already defined functions neatly, it’s just easier to ignore those two functions created by codium-extend and simply create your own.

Start by copying the existing two header style functions from codium and renaming them to whatever you like. From there modify them as you see fit/require. Here’s what mine looked like after I had done this:

<?php
// gets included in the site header
function td_header_style() {
?><style type="text/css">
div#header {
    background: url("http://techdistortion.com/wp/wp-content/themes/codium-extend-td/TD-1090x120.png") no-repeat;
    height :120px;
    -moz-border-radius:6px;
    border-radius:6px;
}
<?php if ( 'blank' == get_header_textcolor() ) { ?>
    h1.blogtitle,.description { display: none; }
<?php } else { ?>
    h1.blogtitle a,.description { color:#<?php header_textcolor() ?>; }
<?php
} ?>
</style><?php
}

// gets included in the admin header
function td_admin_header_style() {
?><style type="text/css">
#headimg {
    width:1090px;
    height:120px;
}
</style><?php
}
?>

After this we’ve now setup the two functions how we want them and it’s time to remove the existing image header for which WordPress provide a function appropriately called remove_custom_image_header(). In order to execute this and our two new functions we need to wrap them in an action that takes place after the theme has finished its setup (if we don’t we’ll be removing an image header that hadn’t been created yet = this is bad) as follows:

<?php
    add_action( 'after_setup_theme','remove_image_header', 100 );
    function remove_image_header() {
    remove_custom_image_header();
    add_custom_image_header('td_header_style', 'td_admin_header_style');
}
?>

Of course you can name your two new functions whatever you like but I prefixed mine with "td" after this site.

All of this is all very well and sedentary but the problem is that as of WordPress v3.4 (not released yet but will be soon) the add_customer_image_header is going to be deprecated. It’s advisable then to look into add_theme_support(‘custom header’); after that point. I’m assuming there will be an update to codium-extend to support add_theme_support at that time.

The same principles in this article can be used to create your own functions that are executed in a child theme to supplement functionality not present in the parent theme, without having to modify the parent theme.

FaceTime Setup: ‘It just doesn’t work…’

21st April 2011

Apple place a great deal of stock in the catch-cry "It just works…" with reference to all of their products simplicity and usability. Every now and then however it becomes a bit harder to swallow. Today’s case in point: FaceTime setup, that frankly didn’t just work at all.

For iPod Touch users (about 37% of Apple’s user base based on recent numbers) a user requires an email address that is also an AppleID to make it all work. This seems okay to me so upon purchasing a new iPod Touch for my son I created a new account for him and started setting it up.

I chose to create the AppleID through the Apple website. When creating a new AppleID this way it looks something like this:

Entry

The resulting window looked like this: Result

Naturally I thought all was well as I verified my email address and proceeded to the new iPod Touch. When I entered the correct information into the "Enter AppleID" dialog:

Entry Attempt Entry Failure New Account Creation Account Creation Failure

Once told my password was incorrect I tried re-entering it with no success. Then I tried recreating the account using the iPod Touch interface (3rd pane above) and was pleased to find the helpful password guidelines in small text below the Verify field. I decided to flex the muscles of this password checker and was surprised that whilst it found my 3 consecutive characters (4th pane above) it did NOT find the missing uppercase character in a subsequent attempt to break it.

Hitting the forums I found that it was about February, 2011 that Apple changed their password requirements to something stricter. The problems here are three-fold: A) The password rules are not enforced or even suggested directly on the Apple Website, B) the error indicating the password is incorrect is in itself incorrect, and C) the iOS interface doesn’t fully enforce the password rules either.

To get FaceTime to work you need a mostly compliant password - stick to the rules and you’ll be fine. My problem with this is more that this issue is hardly new (nearly 8 months old - It appeared as early as I could find it, on the 8th of September 2010 in this Apple support article) and it could be easily rectified with an update to the web-site backend code and the FaceTime application on iOS. A series of solutions that worked for me showed up about a month later with no help from Apple. Sorry Steve but the rules weren’t equally applied and as such, it didn’t just work.

Import Non-iPhone/iPod Touch/iPad 2 Video into iMovie 1.2 for iOS

19th March 2011

Despite Apple’s suggestions to the contrary it is possible to take footage on a camera or another kind of phone other than an iPhone, iPod Touch or iPad 2 and edit it using iMovie for iOS. My instructions are for 720p video however it should work for any resolution and type of video up to 720p. Here’s how to do it. If you don’t already have it download and install the latest version of MPEG Streamclip (v1.2 for Windows and v1.9.2 for OSX). Open the file you want to convert in MPEG Streamclip then "Export to Other Formats…". If MPEG Streamclip can open and play it then it can export it - if not you’re out of luck. There are several settings that work however my favourite that seems to maintain the best quality (in my tests thus far - I’ll let you know if/when I find better settings or alternative software) are: Format = Quicktime Movie, Frame Size = 1280x720 HDTV 720p (or match the source of your video - don’t rescale the video unless you want to lose quality). Save the destination file somewhere on your PC. Now the video is in a compatible format so then you need to get it onto the iPad. I have the camera connection kit which makes it really easy. If you have an SD card and you can write files to it that works, or if you have a USB Flash Disk (Thumb Drive, USB Disk whatever you want to call it) put it in your PC and make sure there’s a directory called "DCIM" at the root level of the folder structure, then copy your modified movie files onto the card/drive. Make sure the movie file names are no greater than 8 characters long and end in ".MOV" or it won’t work. Now eject your flash card/drive and then plug it into your camera connection kit and then into your iPad/iPhone/iPod Touch 4th Gen with iMovie installed. Photos will load up and ask you to import the video files off your card/drive. Import them - it’s up to you if you want to then delete them from your card/drive it doesn’t make any difference to getting this to work. Close Photos and open iMovie and your videos should load when you open/create a project and browse your video media files. I’d like to say it couldn’t be easier but oh well. We live in hope that Apple improve things in future and make this process easier. Enjoy editing whatever video you like on your iOS device with iMovie.

Update: There are limitations to the size of the flash disk as larger flash disks when using the USB Camera Connection kit. A 2Gb drive works okay but an 8Gb will not. An SD Card is a better option for transferring larger files.