Social

Preface

Often enough I must localize the web app that I’m building. Usually it’s a quite tedious thing to code, but luckily for me October CMS already has a plugin that supports localization. The only real turn down would be that the language code is not persistent in the routes.

October is a free, open-source, self-hosted CMS platform based on the Laravel 5 PHP Framework.

I wanted my application to have this language code in the route as a prefix at all times. This is how I did it.

How to

It’s easy to implement this method, but to actually figure it out.. well, for me it was a few hours worth of headaches.

We will be building routes with this pattern:

http://example.com/en

http://example.com/en/page

http://example.com/ru/page

http://example.com/lv/page

First of all lets create a new plugin with

$ php artisan make:plugin mja.extensions

Once that’s created – go ahead and make a new file in the root directory of the plugin and call it routes.php. This code will be responsible for:

Now that page URLs will be prefixed, we must prefix the app URLs aswell ({{ ‘/contact-us’|app }}). This can be accomplished by overwriting the existing twig extension. Add these methods to the Plugin.php file:

PyroCMS is a content management system that’s built on Codeigniter PHP framework. For the last few years I’ve been developing on it. It has a really clean and modular codebase, but, if you use this beast improperly, it can become extremely slow. So here are a few tips on how to create fast sites with PyroCMS.

1. Enable production environment.

This simple, but yet so often forgotten task is a must do for sites that are in production mode (live for client to see).

To enable production environment you have to add this line to your .htaccess file.

SetEnv PYRO_ENV production

Or alternatively you can use this line to enable it only on a certain domain.

What does this do?

Enables the usage of different config files for different environments (but this is not necessarily a speed improvement).

2. Get to know the asset config file

Located in: system/cms/config/asset.php.

Once you’ll open this file, you will a lot of comments. This file is documented brilliantly, so I don’t see much that I could explain here.

Probably the only thing that they forgot to document is the asset_filepath_callback config variable. It’s a callback that get’s called once a filename has been built. I use it to append timestamp to the asset files and I’d suggest you to do the same.

Please notice the cache_on and cachedir lines. They are responsible for the magic.

Note: Don’t forget to create the new db-cache folder.

5. Disable the installation check hook.

This is dead simple, but often developers forget about it. After we’ve installed PyroCMS – we should disable the installation check hook. It will not give you a huge boost in speed, but every small bit counts.

The installation hook can be found in system/cms/config/hooks.php. It should look somewhat like this:

TL;DR: This is a story of how I hacked Airbaltic’s cheap flight calendar to find even cheaper offers.

Airbaltic site has an interesting feature – a low fare calendar. One can choose the boarding and landing airport and see if there are any cheap flights in the selected month. All of these prices change daily. Perhaps even hourly – I’m not entirely sure.

But how can we make this even better? How can we use the calendar to find out about bargains to our desired location? This is where my hacking came in to play.

At first I had to find out all of the airport codes. This was not a hard task. To be honest – quite frankly it was as simple as taking a candy from a kid. All I had to do was open up the developers console and view the network tab. I was able to see the data that must be sent to a AJAX url and the URL itself.

Now that I had the airport codes, I had to get the prices. This task was basically the same as getting the codes, but… yes, the prices aren’t sent to the client in a JSON array. The JSON response contains HTML code. Hmm? Why would they send so much useless data? Why not simply send the prices+dates and then build the HTML on the client side?

Ah, who knows.. anyways, to get the prices I had to parse the HTML. That was not a difficult task (Ha, even for me.. a person who’s terrible at RegExp).

So now that I had aggregated all of this data, what could I do with it? Sort it by the price and see when are the cheapest flights and to where. I can store the data somewhere and pull it daily to get a sense of how the prices change, and perhaps see a pattern. Who knows.

Anyways, with this – bare price/date data – I can find quite a few bargains. For example – 30 EUR for a flight to Germany? Why not?

#!/bin/php
// We still want to use this
$route['admin/navigation/groups/(:any)'] = 'navigation/admin_groups/$1';
// Overwrite the default core modules with a custom one (if one exists)
$route['admin/navigation/(:any)'] = 'navigation/my_admin/$1';
$route['admin/navigation'] = 'navigation/my_admin/index';

cms/helpers/

Recently I started using Laravel PHP Framework and I must say – it is one of the most modular, orthogonal and CLi (command line) friendly frameworks out in the wild. CodeIgniter is nothing compared to this amazing piece of art.

But… as much as I love Laravel, it has a few downsides compared to other frameworks. One of the largest turndowns is the lack of community and stupid questions. What do I mean by that? Well, there are plenty of “How do I do X?” CodeIgniter questions out there and it’s easy to just google for a solution, but Laravel doesn’t have such. Therefore it is a wee-bit harder for newbies to adapt to this framework.

Never the less, this is a tutorial.. a guide of how to build a simple authorization system with Laravel. Let’s jump right in, shall we?

1. Create the User table

Obviously this is the first thing that we are supposed to do. I assume that you already have set up your database.

Lets create a new migration to create this awesome user table. Run this command in CLi.

<code>php artisan migrate:make create_user_table
</code>

Now open up the new migration at application/migrations/…_create_user_table.php and add the table creation and deletion queries.

If it’s not in the file – add it as we will need it. Basically it’s a filter that we can call whenever we want. It checks if the user is a guest (not logged in) and redirects the user to the login page.

To activate this filter in our routes we simply have to add a _before_ param with the filters name to our route. For example: