Ember.js say hello to Apigility.

Developing web applications today is quite easy, you will find always a framework/library that does most of the work for you.

Some month ago, I heard about Apigility and lately I have been playing a little with it. So what’s Apigility?: Apigility is an API Builder, designed to simplify creating and maintaining useful, easy to consume, and well structured APIs.

For this tutorial I’m going to show you how to create a Todo-Api, using Apigility on the backend and Ember.js on the front end.

Installing Apigility

Installing Apigility is easy, you download it from www.apigility.org or installing using composer by running this cmd:

php composer.phar create-project –sdev zfcampus/zf-apigility-skeleton path/where/to/install

After that it is just to fire it up.

Remember you have to disable the opcode on Apache/PHP or the Apigility admin dashboard won’t work, when developing the API it is best to use the build in web server in PHP (>5.4.8+).

To fire it up, first open you cmd and go to the installation folder and run following cmd to put the application into development mode:

php public/index.php development enable

Then run the server:

php -S -t public public/index.php

Change the port if you are also using Apache or other http server on that machine.

Open the browser and go to your url, in my case im using apigility.empirio.local:8082, and if everything is installed correctly you will be transferred to zf-apigility-welcome module, click on «Get started» to continue to the admin panel.

Create a database adapter

On the left side you find a menu on the admin dashboard, click on «Database Adapters» then «Create New DB Adapter«, fill the field according to you setup, in my case Im going to be using pdo_mysql and name the adapter «Demo\Apigility\TodoApi».

Create a new API

After creating the db adapter now its time to continue with our api, click on the button «Create new API» on the top right corner and fill out the name of you api, in my case we are going to name it «TodoApi».

And that’s all, you have now created your first API.

Create a REST Service

The API need some configuration, otherwise its just a dumb and empty API, so go ahead and create a new REST service.

Click on your API on the top, and then «REST Services» and then «Create new REST Service», here you have 2 options:

  • Code-connected – Custom rest services, easier to manipulate the data, and/or for third party APIs
  • DB-connected – You get a lot functionality for free, more difficult to add custom manipulation.

We are going for the DB-connected, so select that and under «DB Adapter Name» select the db adapter we created earlier and as well fill the table name on your database, we are going to create the table after this.

Create the table

Create you database table, in our case we are going to name it «todos» and have following attributes:

todos_id (primary key),
name (string),
is_completed (bool)


Before starting on the front-end, we can test our api using a rest client, im using Advanced Rest Client on Google Chrome.

Open the REST client and send a GET request to the server/api (http://apigility.empirio.local:8082/todos), the server will return something like this:

    _links: {
        self: {
            href: http://apigility.empirio.local:8082/todos
    _embedded: {
        todos: [0]

As you can see its just an JSON string.

Now try to do a POST request, set the header content-type to application/json and under payload put this JSON string:

{"name":"My first task", "is_completed":false}

In return, you will get a 201 created response from the server with the created task as JSON:

    todos_id: "1"
    name: "My first task"
    is_completed: "0"
    _links: {
        self: {
            href: "http://apigility.empirio.local:8082/todos/1"

And so, you can try to get a single task, delete one and play more if you want.


In you Apigility installation, you have a module named «Application», all it does is to redirect you to the zf-apigility-welcome module, so I’m going to use this for my front-end.

But we have to do some changes on the ApplicationController, we have to remove the code that redirects you to zf-apigility-welcome module, we do this by removing this line of code from the index action:

return $this->redirect()->toRoute('zf-apigility-welcome');

And then in my case im going to use asset manager to load my assets and static files. So create a folder named «asset» under «Application»-module then open the confige-file and put this on the top:

// ...
'asset_manager' => array(
    'resolver_configs' => array(
        'paths' => array(
            __DIR__ . '/../asset',
// ...

Now you can put all the javascript and css files under the folder we just created.

Downloading Ember.js

I’m going to use canary build of Ember.js and Ember Data, you can download them here: http://emberjs.com/builds/#/canary. I’m also going to use twitter bootstrap for styling.

Here it is how my folder structure looks like it:

// ...
            // boostrap fonts
// ...

And here is my layout:

<!DOCTYPE html>
    <meta charset="utf-8">
    <title>Ember.js & Apigility TodoApi</title>
    <link rel="stylesheet" href="css/bootstrap.css">
    <link rel="stylesheet" href="css/app.css">
    <script type="text/x-handlebars" data-template-name="application">
        <div class="container">
            <h1>Ember.js & Apigility TodoApi</h1>


    <script src="javascript/vendor/jquery-1.10.2.js"></script>
    <script src="javascript/vendor/handlebars-v1.3.0.js"></script>
    <script src="javascript/vendor/ember.js"></script>
    <script src="javascript/vendor/ember-data.js"></script>
    <script src="javascript/vendor/bootstrap.js"></script>
    <script src="javascript/app.js"></script>

If you open this on your browser you should just see the «Ember.js & Apigility TodoApi» if everything is okey.

Now open the app.js-file remove everything and just leave the definition of the application:

App = Ember.Application.create();

Then we need to define our resource, here its how we do that:

    this.resource('todos', {path : '/'});

As you can see we just defined one resrouce named «todos».

Then we define an adapter and a store:

// ...
App.Adapter = DS.RESTAdapter.extend({
    namespace: ""

App.Store = DS.Store.extend({
    adapter: App.Adapter

The adapter extends DS.REST adapter and the store extends DS,Store and uses the adapter.

We then continue and create the model, called «todo», with a name attribute as string and an isCompleted attribute as Boolean.

// ...
App.Todo = DS.Model.extend({
    name: DS.attr('string'),
    isCompleted: DS.attr('boolean'),

So far so good but still nothing happens, its time to add the handlebar template for our «todos» resource that we defined earlier and then create a form with an input field.

// ...
<script type="text/x-handlebars" data-template-name="todos">
    <form {{action "add" on="submit"}}>
        {{view Ember.TextField valueBinding="todoName" placeholder="Add a new task" class="form-control"}}<br />
// ...

The form has an action that will be trigged on submit, and the input field has an attribute bound to the controller.

We need now to create the Todos-route and define the model we are going to use, then add the action the will handle form submission.

// ...
App.TodosRoute = Ember.Route.extend({
    model : function(){
        return this.store.find('todo');
    actions : {
        add : function(){
            var self = this;
            var todo = this.store.createRecord('todo');

            todo.set('name', this.get('controller').get('todoName'));
            todo.set('isCompleted', false);

                self.get('controller').set('todoName', '');
                console.log('Todo added ...');

The first part is easy to understand, we define a model function that returns the «todo» model from the store.

On the add-function we first create a todo record from the store, set the name from our input field and then save it, if everything went well on the server we reset the value of the name field.

If the server we send the request supports the data on the format Ember.js sends it, you should be able to create a task now, unfortunately Apigility doesn’t do that and we need to do some extra changes.

First we need to create our own serializer that extends «ActiveModelSerializer» and define the extract function like this:

// ...
App.ApplicationSerializer = DS.ActiveModelSerializer.extend({
    primaryKey: 'todos_id',

    extract: function(store, type, payload, id, requestType) {
        this.extractMeta(store, type, payload);

            payload = payload._embedded;

        if(requestType == 'updateRecord' || requestType == 'createRecord'){
            var data = {};
            data[type.typeKey] = payload;
            payload = data;
        var specificExtract = "extract" + requestType.charAt(0).toUpperCase() + requestType.substr(1);
        return this[specificExtract](store, type, payload, id, requestType);

All I did was copying the same function from ActiveModelSerializer and do some changes, we check if the payload has the key _embeded, if so use that as the payload. Then we check if the reqestType is updateRecord or createRecord, since the Apigility returns just the data we need to manipulate the payload and send it to in the right format to Ember.js.

Also the default primary key in Ember.js is «id» so if you have something else you can define it here.

The serializer is used when we need to change the default behavior when we get a response from the server.

Now if we reload the page and write something on the input field and hit enter we will get an 500 Internal Server Error, and the reason for this is that Apigility expects following format on the payload:


But Ember.js by default sends following payload to the server:


And we have to do something with this, so we manipulate the payload by extending (copying from the «RESTAdapter) the createRecord-function change the behavior on the adapter like this:

// ...
createRecord: function(store, type, record) {
    var data = {};
    var serializer = store.serializerFor(type.typeKey);
    serializer.serializeIntoHash(data, type, record, { includeId: true });
    return this.ajax(this.buildURL(type.typeKey), "POST", { data: data[type.typeKey] });
// ...

It’s a minimal change on the last line, from returning just the data array to data[type.typeKey].

If we now refreshes the page again and try to create a new task it will work now.

Now its time to display the tasks on our page, we loop trough the tasks on the controller from the template like this:

// ...
<ul class="list-unstyled">
        <li {{bind-attr class="isCompleted:text-muted isCompleted:done"}}>
            <button {{action delete this}} class="btn btn-danger btn-danger-round btn-xs">x</button>
            {{view Ember.Checkbox checkedBinding="isCompleted"}} {{name}}

The route provide the model to the controller and we just loop trough that, and for each tasks we create a delete button with a delete action and a checkbox bound to the isCompleted attribute.

Then we need to create an observer to observe the checkbox when a task is marked as complete, and here I think Ember.js really shines.

By just creating a function on our model and attach the observer to it like this:

// ...
changeObserver: function(){
    if(this.get('isDirty') == true && !this.get('isNew')){
            console.log('Model changed and saved!');

If the model is changed but it is not a new model then we save the model. The Ember.js observer is attached to the changeObserver-function and passed the bounded attribute «isCompleted», so every time isCompleted is changed this function will be triggered.

Yet again the default payload from Ember.js is not supported in Apigility so we need to extend a new function named updateRecord on our adapter, like this:

// ...
updateRecord: function(store, type, record) {
    var data = {};
    var serializer = store.serializerFor(type.typeKey);
    serializer.serializeIntoHash(data, type, record);
    var id = Ember.get(record, 'id');
    return this.ajax(this.buildURL(type.typeKey, id), "PUT", { data: data[type.typeKey] });

Same thing here as in createRecord, on last line just changed data to data[type.typeKey].

Now you can refresh the page and try clicking on one checkbox and it works.

Now at very end we need to add support for deleting a task, you can do this in different ways, one way is by creating a function on TodosRoute under actions like this:

// ...
delete : function(model){
    if (confirm("Are you sure you want to delete the selected record ? Click OK to continue.")) {
        //deletes record from store

        //persist change
            console.log('Todo deleted');

First we delete the record from the store and then we persist the changes to the server.

Demo and source code

You can find a demo of this todo app here, and you will find the source code on GitHub.

And that’s all for now, on my next tutorial I will add the functionality for pagination. Hope you learn a thing or two and I appreciate your feedback.

Follow me on twitter @oxodesign

Reset forgotten MySQL password on Windows.

For some unknown reason I couldn’t log into my mysql database today. The error message was clear and simple, couldn’t connect to the database, wrong password.

After searching for about one hour, followed as well the guide from MySQL on «How to Reset the Root Password» without any luck, I found a solution that worked in my case, and I want to share that with you.

  1. Stop your MySQL server completely.
  2. Open your command line (cmd) and go to the MySQL bin folder.
  3. Excecute the following command:

    mysqld.exe -u root --skip-grant-tables

  4. Open a new command line without closing the previous one.
  5. Go to MySQL bin folder again, enter «mysql» and press enter.
  6. Now connect to «mysql» database by typing this command:

    use mysql

  7. Reset the root password by executing following command:

    UPDATE user SET Password=PASSWORD('yourpwd') WHERE User='root';

  8. Type exit on this cmd and close the other command line

Be aware sometime we have multiple «root»-users connecting with different hosts!

Hope this will help you as well.

Ember.js, hapat e parë.

postimin time të parë tregova se si zgjodha Ember.js dhe veçorit e këtij framework-u. E në këtë postim do shfaq nga një shembull për secilën veçori.

Instalimi i Ember.js është shumë i thjesht, vizitoni ueb faqen dhe shkarkoni «starter-kit» dhe aty i keni te gjitha fil-et e duhura për të filluar.

Struktura fil-eve ne «starter-kit» është e këtij lloj:


Organizimin dhe strukturën e fil-ve mund ta bëni sipas dëshirës suaj por ne shembujt në vijim ne do përdorin strukturën më lart.

Unë do fshij përmbajtjen në tërësi tek js/app.js dhe gjithashtu do fshi pjesën që ka te bej me Handlebars.js në index.html, e në rastin tim index.html duket kështu:

<!DOCTYPE html>
    <meta charset="utf-8">
    <title>EmberJS më shembuj</title>
    <link rel="stylesheet" href="css/normalize.css">
    <link rel="stylesheet" href="css/style.css">

    <script src="js/libs/jquery-1.9.1.js"></script>
    <script src="js/libs/handlebars-1.0.0.js"></script>
    <script src="js/libs/ember-1.0.0.js"></script>
    <script src="js/app.js"></script>


Se pari duhet te definojmë fillimin e aplikacionit në Ember.js këtë e bëjmë në këtë mënyrë:

var App = Ember.Application.create();

Dhe unë, si shumica e programueseve e emërojmë programin «App», gjithsesi ju mund ta emërtoni programin tuaj sipas dëshirës por keni vëmendje që emri duhet gjithmonë të filloj më një shkronje të madhe.


Përpos që duhet të definojmë programin ne duhet gjithashtu ti tregojmë programit se ku të shfaq logjiken e tij, këtë e bëjmë përmes librarisë Handlebars.js.

Kur definojmë një program Ember.js shikon (dhe kërkon) gjithmonë një template të pa emëruar (ose te emëruar më emrin «application»). Definimin e templates e bëjmë kështu:

<!DOCTYPE html>
    <meta charset="utf-8">
    <title>EmberJS më shembuj</title>
    <link rel="stylesheet" href="css/normalize.css">
    <link rel="stylesheet" href="css/style.css">

<script type="text/x-handlebars">
    Mirë se vini në ketë mësim në Ember.js

Kurse emërimin e bëjmë duke shtuar atributin «data-template-name» (ose ne disa vende mund ta shikoni duke shtuar vetëm atributin «id»), qe ne rastin tone do dukej kështu:

<!-- header ... -->
<script type="text/x-handlebars" data-template-name="application">
    Mirë se vini në ketë mësim në Ember.js

Data binding

Pa shtuar asgjë në app.js, tek index.html, në template «application», krijojmë një tekst boks ku ne mund ta shkruajmë emrin dhe ai emër të shfaqet gjithashtu më poshtë.


Handlebars.js veçohet për mundësin e krijimit të «helpers» për paraqitje të ndryshime dhe me kodin me lart shikoni përdorimin e një «helper» që quhet «input» që është pjesë e Ember.js.

Dhe siç e shini lidhshmëria mes vlerës së tekst boksit dhe shfaqja e asaj vlere është funksionale pa pasur nevojë për logjike shtesë.

Emërtimi (Naming convention)

Kur ne definojmë një program (i cili ne këtë rast është dhe një resource) Ember.js automatikisht gjeneron disa «routes» dhe «controllers», «views» për ne dhe ato janë:

template: application
template: application/index

Në raste kur neve na nevojitet ndonjë logjike shtes ateher ne mundemi ti definojm vete këto instanca te programit, dhe kete do ta bejm ne vijim tek shembulli i «Observers».

Siç e shihni emërimi ndjek një standard që e bën më të lehtë dhe me te lexueshme kodin e programit.


Për ta demonstruar këtë veçori po e marrim një shembull që programi ynë ka dy atribute, emër dhe mbiemër, këto dy atribute do i vendosim në «ApplicationController», dhe ne duam të krijojmë një funksion që sa herë dikush ndryshon emrin një funksion te ekzekutohet. Ember.js e bën këtë duke ja bashkangjitur atij funksioni një «observers»-metodë.

Përpos metodës «oberves», Ember.js mundëson që një funksion ta kthesh në atribute duke shtuar metodën «property», e n.q.s. do ta observosh një atribute për ndryshime atëherë shton emrin atributit në fjalë brenda metodës «property». Siç e kam bere unë në funksionin «fullName» më lart tek JavaScript.

Kjo ishe e gjitha për tani, shpresoj qe t’ju ka pëlqyer, për çdo kritik apo sugjerim ju lutem me kontaktoni përmes twitter (@oxodesign).

Ember.js – një JavaScript framework tjetër.

Para disa muajve rastësisht përderisa isha duke shikuar rreth e rrotull neper internet më kapi vëmendjen AngularJS, duke shikuar një video, kisha një ndjenje «wow», me të vërtet u habita dhe menjëherë fillova te kërkoj më shume informata mbi të. Pas disa orëve dhe pasi që lexova gati gjithë dokumentacionin isha mbet me goje hapur, «si s’kam gjetur diçka të tillë më herët?».

Menjëherë fillova të testoj duke bere një webapp të thjesht dhe shumë shpejt pash anët pozitive dhe negative të këtij framework-u. E këtu duke kërkuar zgjedhje për disa probleme neper internet ne një postim u propozua dhe EmberJS si një alternativ pak me komplekse se AngularJS por qe ne rastin time mbulonte kërkesat e mija. E nga ai rast shndërrova vëmendjen prej AngularJS tek EmberJS.

Sot ne internet çdo gjë fokusohet tek shpërndarja e informacionit më të tjerët, dhe kur kemi ndërtuar aplikacione (webapp) ne front-end me JavaScript problemi kryesor ishte përkrahja e URL, e mu këtë problematik kanë dashur ta zgjedhin zhvilluesit e EmberJS me këtë framework, çdo gjë fokusohet tek «URL».

Përpos fokusit në problematiken e URL, duke strukturuar një faqe më mirë dhe duke e bere atë me te lexueshme për të tjerët, EmberJS veçohet edhe për:

  • Databinding - Çdo objekt apo atribut është gjithmonë e lidhur dhe ndryshimi i bere në një vend reflekton ne gjithë aplikacionin pa patuar nevojë funksione shtesë për një gjë të tille.
  • Emërtimi (Naming convention) - EmberJS ndjek një mënyrë emërtimi të standardizuar, dhe në raste kur nuk nevojitet ndonjë logjike specifike EmberJS auto gjeneron logjiken e duhur për të funksionuar (controllers, views, etj.), kjo na jep përparësi për te krijuar një aplikacion më shpejt gjithashtu kodimi behet me i lexuar për te tjerët atëherë kur punojmë ne grupe.
  • Observers - Mundëson ekzekutimin e një logjike të specifikuar atëherë kur një funksion/kode ndryshon.
  • Handlebars.js - EmberJS përdor Handlebars.js librarin si template për te fuqizuar interaksionin më aplikacionin.

Se fundi, EmberJS është një framework i lehtë, por jo dhe i thjesht për ta mësuar. Unë ju propozoj ta përdorni këtë framework për projekte pak më të mëdha ku nevojitët strukturë dhe komplicitet. Për projekte më të thjeshta ndoshta kryen pune dhe AngularJS.

Vizitoni faqen e EmberJS për të mësuar më shumë.

ADO + ADSI LDAP Provider + PHP

I know it’s crazy, to communicate with LDAP-server using ADSI LDAP Provider and ADO in PHP but sometimes you have to do crazy things.

The Active Directory Service Interfaces (ADSI) Lightweight Directory Access Protocol (LDAP) provider implements OLE DB interfaces that allow you to use ActiveX Data Objects (ADO) which are a set of Component Object Model (COM) objects that allows us to access objects in LDAP compliant directories such as Microsoft Active Directory.

PHP has a COM extension/class that is only available for the Windows version of PHP.

First you have to create an «ADODB.Connection», and set its Provider to «ADsDSObject» and open that connection by executing the «Open()»-function as shown in this example:


$conn = new \COM('ADODB.Connection');
$conn->Provider = "ADSDSOObject";
$conn->Open("Empirio AD Provider", 'username@empirio.local', 'password');

The «Open()»-function take 3 arguments, the first one is the connection name it must be a string, even an empty string "" is fine. In case you want to authenticate with the server you put the username as second parameter and password as the 3rd one. Those two parameters are optional.

After we have done that it’s time to build the query, in this case we are going get a list of all the users under a specific container (OU).

The query is composed of four elements separated by semicolons in the following format:


  • server: is the name (or IP address) of the server hosting the directory.
  • adsidn: is the distinguished name (DN) of the starting point for your query expressed ADsPath format with "/" separators and the root of the namespace to the left. You can also use an X.500 style attributed name format with the relative distinguished names separated by commas and the root of the name space to the right.
  • ldap filter: is the LDAP filter string
  • attributes: is a comma separated list of names of the attributes to be returned for each row in the recordset.
  • scope: is either: base, onelevel, or subtree.

Here is the example of the query I’m going to use:

// ...

$ADsPath    = "LDAP://dc-empirio-01/CN=Users,DC=empirio,DC=local";
$filter     = "(&(objectCategory=person)(objectClass=user))";
$attributes = "name,distinguishedName,sAMAccountName";
$scope      = "subTree";

$query      = '<' . $ADsPath . '>;' . $filter . ';' . $attributes . ';' . $scope;

It does not need much explaining. Now it’s time to execute the query and get back the result like so:

// ...

$result = $conn->Execute($query);
$count  = $result->RecordCount();

while (!$result->eof()){
    echo $result['sAMAccountName'] . '<br>';


The result returned is an «ADODB.Recordset» and you iterate using the «while()»-function in PHP. All the available methods for «ADODB.Recordset» you can find here.

Localize WordPress archive when using Stella-plugin

I’m using «Stella-plugin» on a project I’m working on and while working on the archive page, found out that in free version of Stella when using the «wp_get_archives()» it does not filter on the current selected language.

To fix that, all you have to do is create a function in «functions.php»-file and attach into the «getarchives_where»-filter. Here is the code for you:


 * Empirio archive localizer ...
 * @param string $where
 * @return string
function __empirio_archive_localize($where){
    global $wpdb; $language = STELLA_CURRENT_LANG;
        $where.=" AND exists ( SELECT * FROM $wpdb->postmeta pm
            WHERE pm.post_id = $wpdb->posts.ID
            AND (pm.meta_key = '_title-{$language}'
            OR pm.meta_key = '_body-{$language}'))";
    return $where;

add_filter('getarchives_where', '__empirio_archive_localize');

Git & GitHub për fillestaret ... në shqip

Në qoftë së ende jeni të panjohur më sistemet e kontrollimit të versioneve dhe merreni më programim atëherë keni ende diçka për të mësuar.

Sistemet për kontrollimin e versioneve ruajnë gjurmët e të gjitha ndryshimeve të dosjeve (files&folders) dhe lejon zhvilluesit për të bashkëpunuar në një mënyrë më efikase. Më tjera fjalë ruajnë çdo ndryshim të kodit tuaj në një mënyrë kronologjike që të mundëson të rikthehesh në një faze të mëhershme.

Ekzistojnë disa sisteme të ndryshme, nder to, CVS, i cili është një nder sistemet me të vjetra, Subversion (i njohur dhe me shkurtesën SVN) një alternative e mire më burim të hapur (open source), përdoret dhe nga Google Code, dhe në fund GIT një sistem pak më ndryshe në ruajtjen e informatave që kohen e fundit së bashku më GitHub.com po përdorët shumë.

Si të instalojmë Git në Windows?

Ekzistojnë dy mundësi, njëra përmes «msysGit» dhe mundësia tjetër përmes programit nativ të GitHub për Windows, të cilin unë ja u preferoj. Procesin e instalimit nuk do ja u shpjegoj pasi qe është shumë i thjesht. Pas instalimit ju udhëzoheni të kyçeni më të dhënat tuaja të GitHub.com, n.q.s. nuk keni një llogari atëherë krijojeni një.

Kështu duket programi i Github për Windows, në anën e majtë shfaqen «repositories» lokale dhe ato në github.com, lart keni mundësin të krijoni një «repository», kurse tek «tools» dhe nën «options» keni mundësi konfigurimi së në cilin dosje dëshironi ti vendosni «repository-it» lokale. Kësaj radhe ne do të përdorim «Git Shell» për krijimin dhe menagjimin e tyre në GitHub dhe jo programin më lart.

Krijo një «repository» të re

Një «repository» është një set më dosje (files&directories), me te dhëna të ndryshimeve. Për të krijuar një «repository» shko tek GitHub.com, kyçu dhe tek «Your Repositories», klikoni «New repository», shkruani emrin e depos, përshkrimin dhe klikoni «Create repository», si shembull kësaj here unë do krijoj një «repository» më emrin «Tung-GitHub».

Pasi që keni krijuar një «repository» të re, në faqen tjetër do shfaqen udhëzimet së si ta përdorni atë «repository», pasi që jemi duke përdorë programin e GitHub për Windows atëherë konfigurimin në «Global setup» e tejkalojmë.

Tash hapni programin «Git Shell» i cili është një terminal për ekzekutimin e komandave, shkoni ne «root» të serverit tuaj (aty ku dëshironi të keni një «repository» lokale) dhe krijoni një dosje (folder), në shembullin time unë do krijoj një dosje më emrin «Tung-GitHub» duke ekzekutuar komandën:

mkdir Tung-GitHub
cd Tung-GitHub

Tash ekzekutojmë komandën:

git init

Më të cilën tregoni se kjo dosje është një «repository» për GIT, tash krijojmë një dokument më emrin «Readme.md» dhe në të shënojmë diçka, mbylleni duke ruajtur atë që shënuat dhe kthehemi prapë tek terminali dhe ekzekutojmë këtë komandë:

git add readme.md

Më komandën me lart i tregoni sistemit që ky file duhet te vendoset ne GIT. Që pastaj të mund ti ruajmë çdo ndryshim të tij.

Pastaj bëjmë «commit» e pare duke ekzekutuar këtë komandë:

git commit –m "First commit"

Deri më tash çdo gjë është lokale, tash është koha ti tregojmë GIT që të dhënat të ruhen në «repository-in» që kemi krijuar në GitHub, këtë e bëjmë duke ekzekutuar këtë komandë:

git remote add origin https://github.com/oxodesign/Tung-GitHub.git

«origin» është thjesht një emër (shkurtes) qe zëvendëson adresën më lart. Dhe ju mund ta ndryshoni atë sipas dëshirës.

Pasi që i kemi treguar GIT se ku do ti ruajmë ndryshimet tash është koha të bëjmë atë duke ekzekutuar këtë komandë:

git push origin master.

«Master» është «branch» kryesor te cilin duam ta kopjojmë ne «origin».

«Branch» është një kopje që referon në «commit-in» e fundit, dhe të mundëson zhvillimin e ideve të reja pa rrezikuar projektin në tersi. Supozojmë qe kemi një projekt që funksionon dhe dëshirojmë të krijojmë funksionalitet shtesë, atëherë për këtë krijojmë një «Branch», pasi qe kemi bere ndryshimet dhe jemi te kënaqur më rezultatin atëherë mundem ta «shkrijmë (merge)» atë më kodin kryesor («Branch») «master».

Kaq për fillim, shpresoj që të keni mësuar diçka. Kritikat dhe sugjerimet janë të mirëseardhura në Twitter.

Krijo një «Widget»-plugin tëndin në Wordpress

Para së të filloj më këtë shkrimin dua të ceki që sot është hera e pare që shkruaj një plugin për Wordpress, dhe kam njohuri shume te kufizuara mbi këtë CMS.

Sot kisha nevojë për një widget/plugin të thjesht në wordpress që mundësonte shfaqjen e x-numër shkrimeve të një kategorie. Pas një kërkimi të shpejt, gjeta disa zgjidhje, por disa ishin shumë të avancuara e disa nuk funksiononin ashtu siç doja unë, kështu që vendosa të krijoj një vet.

Fillojmë atëherë

Që të krijosh një widget/plugin se pari duhet te krijojmë një dosje (folder), nen “wp-content/plugins”, emërimin e zgjidhni vete, pastaj krijojmë një php-file, prapë vendosni vet për emërimin. Unë në shembullin që do marr këtu do e emëroj dosjen “empirio-postrender”, me te njëjtin emër do emeroj dhe php-dokumentin e krijuar.

Wordpress merr te dhënat (emrin, përshkrimin, autorin) e plugin-it përmes komentimit ne dokumentin e po sa krijuar, kështu që fillojmë me atë:

Plugin Name: Empirio PostRender Widget
Plugin URI: http://www.empirio.no
Description: A widget listing posts from a category
Version: 1.0
Author: Flamur Mavraj
Author URI: http://www.empirio.no

Besoj që është vet shpjeguese pjesa më lart kështu që vazhdojmë duke krijuar një klas (class). Çdo plugin duhet të zgjeroj (extends) klasën bazë “WP_Widget”, në rastin time unë do emeroj klasën “Empirio_PostRender_Widget”, kështu që kodi jone do duket diçka i tille tani:

class Empirio_PostRender_Widget extends WP_Widget {
    \\ your code here ...

Janë 4 funksione që çdo plugin duhet patjetër ti përmbaj:

  • Krye funksioni/konstruktori (cili ka emrin e njëjtë si vete klasa)
  • form (Këtu shfaqim opsionet për konfigurim që pastaj ruhen përmes funksionit “update”)
  • update (Këtu bëjmë azhurnimin e të dhënave nga paneli i administratorit)
  • widget (këtu shfaqim te dhënat në faqe)
Fillojmë me funksionin e pare, e vetmja gjë që nevojitët të bëjmë këtu është të thërrasim funksionin kryesor te klasës baze duke ja dhen si parametër emrin e plugin-it:

class Empirio_PostRender_Widget extends WP_Widget {
    function Empirio_PostRender_Widget() {
        parent::WP_Widget(false, $name = 'Empirio PostRender Widget');

Vazhdojmë me funksionin “form”, ky funksion përmban një parametër te quajtur “$instance” e cila përmban të dhënat.

class Empirio_PostRender_Widget extends WP_Widget {
    // ...

    function form($instance) {

        $title              = esc_attr($instance['title']);
        $category_id        = esc_attr($instance['category_id']);
        $number_of_posts    = esc_attr($instance['number_of_posts']);
        $template           = esc_textarea($instance['template']);

        $defaults    = array(
            'template' => "<li><a href='%post_link%'>%post_title%</a></li>",
            'number_of_posts' => '5'

        /** Category list */
        $categories = get_categories(array('type' => 'post', 'hide_empty' => 0, 'orderby' => 'name', 'order' => 'ASC', 'taxonomy' => 'category'));


        <label for="<?php echo $this->get_field_id('title'); ?>"><?php _e('Title:'); ?></label>
        <input class="widefat" id="<?php echo $this->get_field_id('title'); ?>" name="<?php echo $this->get_field_name('title'); ?>" type="text" value="<?php echo $title; ?>" />

        <label for="<?php echo $this->get_field_id('category_id'); ?>"><?php _e('Category:'); ?></label>
        <select class="widefat" id="<?php echo $this->get_field_id('category_id'); ?>" name="<?php echo $this->get_field_name('category_id'); ?>">
            <option value="-1"<?php if(-1 == $category_id) { ?> selected="selected"<?php } ?>>Select category ...</option>
            <?php foreach($categories as $category) { ?>
                <option value="<?php echo $category->term_id; ?>"<?php if($category->term_id == $category_id) { ?> selected="selected"<?php } ?>><?php echo $category->name.' ('.$category->count.')'; ?></option>
            <?php } ?>

        <label for="<?php echo $this->get_field_id('number_of_posts'); ?>"><?php _e('Number of posts to show:'); ?></label>
        <input id="<?php echo $this->get_field_id('number_of_posts'); ?>" name="<?php echo $this->get_field_name('number_of_posts'); ?>" type="text" value="<?php echo ($number_of_posts ? $number_of_posts : $defaults['number_of_posts']); ?>" size="4" style="text-align: center;"/>

        <label for="<?php echo $this->get_field_id('tpl'); ?>"><?php _e('Template:'); ?></label>
        <textarea class="widefat" rows="5" cols="4" id="<?php echo $this->get_field_id('template'); ?>" name="<?php echo $this->get_field_name('template'); ?>"><?php echo ($template ? $template : $defaults['template']); ?></textarea>


Të shpjegoj më në detaje këtë funksion, nga linja 7-10 formatojmë të dhënat, duke përdor funksionet bërthame (core) të Wordpress-it, në linjën 12 kemi disa të dhëna standarde, në linjën 18 nxjerrim të dhënat mbi kategoritë nga databaza përmes funksioni get_categories(), dhe ky është funksion nga bërthama e Wordpress-it. Dhe pastaj krijojmë të dhënat e formularit (inputs, textareas ...), funksioni _e() është një funksion ndihmës që ndërlidhet më funksionin translate(), që shfaq fjalinë e përkthyer!

Vazhdojmë më funksionin “update”, i cili ekzekutohet kur bëjmë ruajtjen e informatave të funksionit “form”. Ky funksion përmban dy parametra, te të dhënave të instancës së re dhe asaj të vjetër, dhe këtu bëjmë formatimin e të dhënave para së të ruhen në databaze.

class Empirio_PostRender_Widget extends WP_Widget {
    // ...

    function update($new_instance, $old_instance) {
        $instance = $old_instance;

        $instance['title']          = strip_tags($new_instance['title']);
        $instance['category_id']    = strip_tags($new_instance['category_id']);
        $instance['number_of_posts']= strip_tags($new_instance['number_of_posts']);
        $instance['template']       = $new_instance['template'];

        return $instance;

Tash vazhdojmë më funksionin e fundit, “widget”, dhe ky funksion përmban dy parametra, e para përmban disa të dhëna të vet plugin-it kurse parametri i dyte përmban të dhënat e instancës (formularit).

class Empirio_PostRender_Widget extends WP_Widget {
    // ...

    function widget($args, $instance) {

        $title = apply_filters('widget_title', $instance['title']);

        $postargs = array(
            'cat' => $instance['category_id'],
            'numberposts' => $instance['number_of_posts'],
            'orderby' => 'date',
            'order' => 'DESC',

        $posts  = get_posts($postargs);
        $output = '';

        $output.= $args['before_widget'];
        $output.= $args['before_title'] . $title . $args['after_title'];

        $output.= '
    '; foreach($posts as $post){ $post_link = get_permalink($post->ID); $post_title= $post->post_title; $post_date = $post->post_date; $output .= str_replace(array('%post_link%', '%post_title%', '%post_date%'),array($post_link, $post_title, $post_date), $instance['template']); } $output .= '
'; $output.= $args['after_widget']; echo $output; } }

Dhe këtu po e shpjegoj pak më në detaje, në linjën 7, vendosim titullin duke aplikuar filtrin “widget_title” përmes funksionit apply_filters(). Në linjën 16 nxjerrim postimët nga databaza përmes funksionit get_posts(), i cili pranon një parametër, ne te cilën ne specifikojmë të dhënat në linjën 9 (nga cila kategori, renditjen, sa postime etj...). Pastaj bëjmë një “loop” të postimeve dhe ruajmë të dhënat në variabëlin $output ku ne fund te funksionit e shtypim.

Ne fund, duhet ta regjistrojmë këtë plugin, këtë e bëjmë në fund të dokumentit, pasi që kemi mbyllur klasën më lart, duke thirrur funksionin add_action() si më poshtë:

class Empirio_PostRender_Widget extends WP_Widget {
    // ...

add_action('widgets_init', create_function('', 'return register_widget("Empirio_PostRender_Widget");'));

Tash shkoni në panelin e administrimit, tek “Plugins->Installed Plugins”, aty do e shikoni pluginin e posa krijuar, aktivizoni dhe pastaj shkoni tek “Appearence->Widgets” dhe tash mundeni ta përdorni këtë plugin si widget në “sidebar”.

Kodin e plote mund ta shkarkoni nga këtu, Empirio PostRender Widget.

How to attach MvcEvent’s in Zend Framework 2

Zend Framework 2 is an event driven framework, which means you can attach listeners/functions almost before/after anything.

The ModuleManager has some predefined listeners, such as:

AutoloaderListener (getAutloaderConfig)
ConfigListener (getConfig)
InitTrigger (init)
OnBootstrapListener (onBootstrap)

ModuleManager also inherits some events/ triggers /listeners from the ServiceManager, such as:


But what about MVC events? How can we attach a function/listener from our module? MvcEvent has 6 event triggers (bootstrap, dispatch, dispatch.error, finish, render, route) and you can easily trigger a function for each of them from your module.

In my example im using the «dispatch»-trigger, open your module-file (in my case «module/Empirio/Module.php») and create a function «onDispatch» like this:

namespace Empirio;
// ...
class Module{

    // ... your code

    public function onDispatch(\Zend\Mvc\MvcEvent $e){
        // ... your logic here ...

Now we want to attach this function when our application is dispatched, we do this from our onBootstrap-function, like this:

namespace Empirio;
// ...
class Module{

    // ... your code

    public function onBootstrap(\Zend\Mvc\MvcEvent $e){
        // ...

        $em = $e->getApplication()->getEventManager();
        $em->attach(\Zend\Mvc\MvcEvent::EVENT_DISPATCH, array($this, 'onDispatch'));

Or you can attach the function from the init-function as well, like this:

namespace Empirio;
// ...
class Module{

    // ... your code

    public function init(\Zend\ModuleManager\ModuleManager $mm){
        // ...

        $sem  = $mm->getEventManager()->getSharedManager();
        $sem->attach('application', \Zend\Mvc\MvcEvent::EVENT_DISPATCH, array($this, 'onDispatch'));

As u can see the «init»-function uses ModuleManager, where «onBootstrap»-function uses MvcEvent as its parameters.

Create your own controller plugin in ZF2

Creating and loading a controller plugin is easy in ZF2, be aware that the loading method has changed on beta 5, and hopefully it will stay stable from now on.

On my previous post I described how to get started with zf2 using a skeleton application, so I will start from there.

I will create a new folder named «Plugin» under «module/Empirio/src/Empirio/Controller» and then create a new file named «MyFirstPlugin.php», which will be a php class that will extend the «AbstractPlugin»:

namespace Empirio\Controller\Plugin;

use Zend\Mvc\Controller\Plugin\AbstractPlugin;

class MyFirstPlugin extends AbstractPlugin{
    public function doSomething(){
        // ...

Now after we have created the plugin, we need to load it on our application, we do this on our module config file, by adding those lines of code:

return array(
    // ... your configuration

    'controller_plugins' => array(
        'invokables' => array(
            'MyFirstPlugin' => 'Empirio\Controller\Plugin\MyFirstPlugin',

    // ...

Now we can call the plugin inside the controller by just doing this:

namespace Empirio\Controller;

use Zend\Mvc\Controller\AbstractActionController;
use Zend\View\Model\ViewModel;

class IndexController extends AbstractActionController{
    public function indexAction(){
        $plugin = $this->MyFirstPlugin();

        return new ViewModel();

And that’s it. Comments are welcome on twitter.

Getting started with Zend Framework 2

I’m going to use my own skeleton project, zf2skeleton, but if you prefer you can also use ZendSkeletonApplication, the only difference is that I use my own module, named «Empirio», but on ZendSkeletonApplication the main module is named «Application». Also the ZendModuleApplication uses Twitter bootstrap as layout.

You start by downloading the skeleton application into a folder, in my case im going to use git, so I just run this command from my terminal:

git clone git://github.com/oxodesign/zf2skeleton.git

And then I will use composer.phar to install my dependencies (in this case, zend framework 2 beta 5).

php composer.phar install

The composer will also set up the autoloader for you. And that’s all you have to do, now you have a working application using zf2. The structure on your application now looks something like this:


Inside config-folder you have the «application.config.php»-file where you can state your configuration, ex. what modules you are going to use, module paths and so on. The data folder is self-explained, the module folder is where you put your zend framework modules (will write a blog post on how to create a module from scratch), inside public folder you have the index.php-file which is the starting point for your application, also under this folder you put your media files such css, images and javascript-files. On vendor folder you have third-party dependencies (libraries), such as ZF2, Doctrine and so on.

Composer, a smart way of installing dependencies

I have been a PHP developer for some years, and I have always found it hard to maintain dependencies on my projects. You had to download this and that, use different loaders for different libraries, create a bootstrap and if you are lucky it works!

But now all that have changed with composer, and if your libraries follow the PSR-0 standard the composer will configure and use the autoloader for you as well.

Composer is a command-line tool that installs packages, inspired by NPM and Bundler, it contains an dependency solver that is able to recursively resolve package dependencies.

All you should do is create a composer.json file into your project where you will state your dependencies and run php composer.phar install. Packeges are registered at packagist.org and are easy to depend on, but you can also use custom/other repositories as well.

Let’s take an example, I have created a zend framework skeleton application that use composer, check it out and downloaded from here, open the composer.json file to take a look, on this file I have stated the dependencies for this application, in this case zend framework 2 beta 5,

    "name": "empirio/zf2skeleton",
    "description": "ZF2 skeleton application",
    "homepage": "http://www.empirio.no/",
    "require": {
        "php": ">=5.3.3",
        "zendframework/zendframework": "2.0.0beta5"

Line 2-4 are self-explained, on line 5 we tell the composer the requires for our applications, in this case we have 2 requirements, one, php version equal or larger than 5.3.3 and the zend framework 2 beta 5, the package name for zf2 on packagist.org is “zendframework/zendframework” and the tag for beta 5 is “2.0.0beta5”.

Now download the skeleton from github (zf2skeleton) and run command from the terminal to install the dependencies:

php composer.phar install

As u can see inside the vendor folder the composer installed the zend framework 2 beta 5 for you.

For more information about Composer. Check out their webpage at getcomposer.org.

Zend Framework 2 URL Rewriting in IIS7

Some weeks ago I started to play with Zend Framework 2, and im impressed with what I have seen so far.

Lately I have started to use PHP with IIS (using the PHP manager, check it out: php.iis.net) and since everyone knows that IIS does not support .htaccess-files I had to find a way around it, after a quick search I found a blog post written by Rob Allan, but his suggestion didn’t work in my case.

By default IIS7 does not have the URL Rewrite module installed, so you have to install manually by downloading from the IIS.net webpage.

When that’s done, go to your public-folder (where the .htaccess-file is) create a new file, name it “web.config” and paste this rewrite rule:

<?xml version="1.0" encoding="UTF-8"?>
                <rule name="Empirio (www.empirio.no)" stopProcessing="true">
                    <match url="^(.*)$" ignoreCase="false" />
                        <add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" negate="true" />
                        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" negate="true" />

                    <action type="Rewrite" url="index.php" />

Restart IIS and now the routes on ZF2 should work.

I present to you «Empirio Lab»

It has been on my mind to start blogging for some time, but until now, I never found the right moment. Yes I tried before, using other platforms, blogging with others but I always wanted my own (unique) blog, build and designed by myself.

This blog will be a Zend Framework lab (of course using version 2.0, from now on I will just refer as «zf2»), but I will also blog about PHP in general, Doctrine, graph databases (Orientdb and Neo4j), document databases (MangoDb, CouchDb and OrientDb) and much more, like IIS, ActiveDirectory, LDAP etc.

The main goal with this blog is to create a step by step tutorial on “how to code a blog from scratch using zf2”, and as I write something I will implement that on this blog, because right now this page is just a static HTML page.

With time you will have the opportunity to comment on my posts, until that’s fixed u can comment & follow me on twitter (@oxodesign).