Category: MySQL

I was asked to do a coding test to create a basic blog. I decided to to use CodeIgniter 3.1 (yes – it’s not dead as was widely reported a few years ago) because I’ve been working with it recently. CodeIgniter may not be as fashionable as Laravel but it is considerable smaller and will run fast on a small/cheap server, it is also quick and easy to learn how to use it.

My source code is available on BitBucket if anyone is interested to take a look: https://bitbucket.org/richardwo/coding-test-blog-ci. There are 2 controllers for users and posts, 3 models for categories, posts and users, 5 admin view files and 3 front-end view files. Overall it took me about 4.5 hours.

Lessons learnt:

Some other PHP Frameworks like CakePHP or Laravel can include registration and authentication by running a few commands. This would have saved me a lot of time because I had to write my own login system and it took a while.

I also ran into some issues with redirects because I was running using the PHP built-in webserver trying to make the application self contained – after some investigation it turns out I needed $config['base_url'] = 'http://localhost:8000/'; in application/config/config.php for the redirects to work properly.

More time was wasted writing the usual CRUD methods and creating Bootstrap forms (even if this is only a cut/paste job). CakePHP scaffolding / Code Generation with Bake would have saved more time (although out of the box it doesn’t use Bootstrap).

On a more positive side, I did like the validators where using 'is_unique[posts.slug]' will automatically check that table/field for you and return an error if it’s already been used.

Next time I’ve got to do this I’ll use Laravel as it seems more popular than CakePHP and I’ll benefit from the nice extras this has to offer over CodeIgniter. However I could just reuse my authentication code and save time.

Here is an SQL query I construct to extract customers with billing and shipping address from a Magento 1.9 store.
This joins on table sales_flat_order_address to ensure that only customers that have ordered are included.

You may need to adjust the entity attribute id’s – if you look in those tables it is pretty obvious what each value represents.

SELECT
    ce.entity_id AS customer_id,
    ce.email,
    cev2.value AS firstname,
    cev3.value AS lastname,
    caet.value AS billing_first_line,
    caev1.value AS billing_town,
    caev2.value AS billing_postcode,
    sfoa.entity_id AS sfoa_entity_id,
    sfoa.street AS shipping_first_line,
    sfoa.city AS shipping_city,
    sfoa.postcode AS shipping_postcode
FROM
    customer_entity ce
    -- first name
    INNER JOIN
    customer_entity_varchar cev2 ON (ce.entity_id = cev2.entity_id
        AND cev2.attribute_id = 5)
    -- last name
    INNER JOIN
    customer_entity_varchar cev3 ON (ce.entity_id = cev3.entity_id
        AND cev3.attribute_id = 7)
    -- address first line
    INNER JOIN
    customer_address_entity cae ON (ce.entity_id = cae.parent_id)
    INNER JOIN
    customer_address_entity_text caet ON (cae.entity_id = caet.entity_id)
    -- town
    INNER JOIN
    customer_address_entity_varchar caev1 ON (cae.entity_id = caev1.entity_id
    AND caev1.attribute_id = 26)
    -- postcode
    INNER JOIN
    customer_address_entity_varchar caev2 ON (cae.entity_id = caev2.entity_id
    AND caev2.attribute_id = 30)
    -- sales
    INNER JOIN
    sales_flat_order sfo ON (ce.entity_id = sfo.customer_id)
    -- shipping address
    INNER JOIN
    sales_flat_order_address sfoa ON (sfo.entity_id = sfoa.parent_id)
    WHERE sfo.status = 'complete'