SIFO features

MVC pattern

SIFO uses the MVC pattern to sepparate your project in 3 different areas:

• Models: Contain the business logic. Where all the data is taken from (e.g: Queries to database)
• Views: HTML templates with a little bit of logic such as iterations. It's just the presentation of your web. Smarty by default.
• Controllers: The ones that put it all together with any necessary logic.

If you never used this pattern before, you should start now if you don't want to become insane once your applications start to grow. Don't feel overwhelmed, it's easy.

Scalable

SIFO has been developed thinking in scalability and performance. You can configure right from the beginning features like load balancing, separate your static and dynamic content or add advanced caching to your pages.

Proved

Well proved, running since year 2008 and used in a large base of heterogeneous web projects with very different needs and technologies.

Powers big sites, some of them with up to 16M page views/month (and raising!)

Inheritance across different projects

Let's say you have several sites running. Doesn't make sense to you that a project inherits the functionality from another one, or even configurations? Wouldn't be good to reuse the code from a "parent" project?

Project inheritance allows you to create several projects (we call it instances) based on a previous one. Be configuration, templates, controllers, models or other libraries. Create an instance that inherits from another one and just overwrite/extend/limit the desired functionality

Have you developed a tracking system? A module for advertisement? A fancy WYSIWYG implementation? Why coding it again or even pasting it for yet another project? Reuse!

You can run unrelated projects that share common base code.

Environment aware

Via a single file, the mighty config/domains.config.php, you define the behaviour of your application depending on the URL you are requesting. For instance, if you want to code the webpage http://sifo.me you might want to set at least 2 domains, one for production usage under http://sifo.me and a fake one for local development like http://sifo-web.local

In the config/domains.config.php you can set up things per domain like:

• Show/hide the debug (devel flag)
• Languages accepted by your application
• Credentials to several services, init commands, master/slave configurations, database passwords or libraries used (e.g: mysql)
• Related hostnames, error reporting and other specific PHP.ini settings.

Nice URLs and Routing

When you type an URL there is a mapping between what you are typing in the address bar and the controller that should reply to that request. Is what we call the router and is located under config/router.config.php. If your application has urls translated you can also use the router_xx_XX.config.php files, where the xx_XX is the language and country code of your app. SIFO supports as much languages as you need.

The router is flexible to do all you like, even set controllers to subdomains.

Powerful Debug

The SIFO debug contains a lot of interesting stuff to debug your application:

• Benchmark: Full decomposition and analysis of times of execution per file and method
• Parameters that every Controller received
• Variables every template received (smarty)
• Queries launched to the database
  • Automatic commenting of the queries
  • Nice print of the final SQL launched
  • Different coloring for write/read operations, with times
  • Slow query alert
  • Printed recordset returned in tabular data
  • Host, database, and replica the query went in
• Data stored in Session (and kill session)
• Data stored in user Cookies
• Cache control (names of the keys, remaining TTL...)
• Sphinx Debug
• Cache invalidation
  • AUTOMATIC: While browsing
  • Manual: By flag

Multilanguage

Almost every SIFO programmer has multi-lingual projects, because it is very easy. We even have translation tools based on config files or in database, so you can pass the URLs to your non-programmers colleagues the URLs for proper translation.

All the templates come with the i18n plugins that allow you to write your files in a single language. Example: If we had an application with 6 possible languages, we could have in the template something like:

<h1>{t 1=$place}Welcome to %1!{/t}</h1>

This code would produce a different outputs depending on the current active language:

English: <h1>Welcome to Sifo!</h1>
Spanish: <h1>Bienvenido a Sifo!</h1>
Catalan: <h1>Benvingut al Sifo!</h1>
Arabic: <h1>أهلاً بك إلى Sifo!</h1>
German: <h1>Willkommen bei Sifo</h1>
Russian: <h1>Добро пожаловать на Sifo!</h1>

Of course you can translate strings in controller, models or your own custom classes (see I18N Class). There is support for non-latin alphabets. We do have several installations in Russian, Arabic, Japanese, Chinese, Hebrew... so yes, and also design with RTL text.

Lazy Loading

The less classes are in-memory, the better. We stick to the principle of loading the classes only if they are going to be used. The autoloader will do the job for you.

There are a lot of classes available and interesting libraries ready to use. Just to solve common problems.

You can even create several profiles of libraries: maybe you want to play with the latest unstable library in local, while keeping the stable one in production. That's defined in libraries.config.php

A piece of config/libraries.config.php:

$config['classes_always_preloaded'] = array(
    'Exceptions',
    'Registry',
    'Cache',
    'CantLiveWithoutThisClass'
);

// Contains all the libraries available.
$config['default'] = array(
    'mylibrary' => 'Mylibrary-1.5-stable'
);
$config['bleeding_edge_insane'] = array(
    'mylibrary' => 'Mylibrary-2.0alpha-unstable'
);

Multiple databases flavour

From Key-values like Redis to common RDBMS like Mysql, Postgres, Oracle, Firebird or even SQLite. You can choose to use Mysql PDO or any of the ADODB drivers. For redis, Predis is an excellent solution we use a lot.

Command Line support

Yes, you like to code your cron jobs in PHP, so do we. Take profit of your existing models. Create your scripts extending from the Command Line. The CLI tool lets you define the supported parameters of the script and automatically builds the help for you. If you are interested in receiving email reporting is also already done.

Dynamic/static distinction

You never know what is going to happen. Putting your static files in a different host is always a win-win decision. If your site grows you will be able to set up a CDN quickly. The domains.config.php file contains special entries to separate dynamic (PHP) from static files (CSS, images, media).

Lots of helpful classes

Many projects share the same needs. Do you need to send nice emails? Geo-localise the users? Facebook/Youtube/Twitter integration? Quick searches using Sphinx? Upload files to Amazon S3? Do not reinvent the wheel, invest your time in something else.

Extendable

What would be the framework if you couldn't add our own classes and libraries? There is room for entire libraries, simple classes or helpers. Before coding something from scratch, ensure there is not something done already.

Tools, tools, tools

We do lot of tools and share it with others. From whole instances to deploy your sites in production, to simple scripts to ease administration or develop faster.

Yes, more...

It's just that I am tired of writing, it is late night. If you arrived here it's time to get a little bit deeper yourself guided by the documentation. It might be a little poor, if you'd like anything to be added or have suggestions, please contact me via GitHub.