Forcing composer to use https connections to Packagist

Been having problems with composer from behind a company firewall. The firewall was blocking us from accessing a particular package.json file from the http://packagist.org website

What was strange though was that it was only blocked over http:// connections and perfectly accessible from https:// connections.

However, I have, after much trial and error and research, found a workaround. It's not a particularly graceful workaround but it takes advantage of the fact that composer does not recursively resolve repository locations and only takes commands from the main project's composer.json configuration.

I realised when reading the documentation on the composer github site that you could disable the default packagist configuration. In addition, of course you can add your own repositories to the composer.json in your project.

So, adding the following to the composer.json solves the problem and I'm able to bypass the blocks put in place by the firewall.

    
    "repositories": [
        {
             "type": "composer", 
             "url": "https://packagist.org" 
        },
        { "packagist": false }
    ]

Of course, this does solve a problem that was only relevant in a particular scenario and probably won't be relevant to the vast majority of people. But if you have a similar situation, hopefully this will help.

Conversion of UTF-8 form fields in Multi Part Form

Got to say a big thanks to Abhishek at Running Commentary for the solution to this problem.

While using the Apache Commons File Upload Library on a Spanish Language form, I was having problems with the UTF-8 characters that were being submitted in people's names etc. Everything else was working properly, the rest of the Spanish characters on the page were displaying properly but the input was being translated into garbage when submitted.

The solution ultimately was to change

item.getString()

to

item.getString("UTF-8").trim()

While extracting the items from the List element that the FileUploadHandler returned after parsing the request object.

Bear in mind, it doesn't matter what you do before calling this, if you don't explicitely tell the FUH what encoding you want to you use, you'll always get standard ASCII back (and subsequently garbage if your form fields contain anything other than standard ASCII...

Hope this helps.

Organising Partials in Symfony

A little tip for organising partial templates in Symfony.

If you want to store partials in sub folders, simply name the first level of folders prefixed with an underscore and remove the underscore from the partial name (or make sure include the underscore when you're calling it.

That way, let's say you send out emails for various reasons on your site, so you have lots of templates (partials) in a mailer module to make your emails nice and easy to manage. If you wanted to organise your registration email body and subject partials in sub folders, you could do the following:

Your subject partial would be located at:

    /apps/frontend/modules/mailer/templates/_subjects/registration.php 

and your body partials might be located at:

    /apps/frontend/modules/mailer/templates/_registration/body_html.php
    /apps/frontend/modules/mailer/templates/_registration/body_text.php

You would then call these partials from your sendMail action as follows:

    // subject 
    include_partial('mailer/subjects/registration');

    // email body
    $message->setBody($this->getPartial('mailer/registration/body_html'), 'text/html')
        ->addPart($this->getPartial('mailer/registration/body_text'), 'text/plain');

Thanks to my colleague Eric for helping work this one out. A good idea that we'll use a lot now to help organise our templates and partials in all sorts of wonderful ways