Categories
Development Uncategorized

Packagist & Github – How-To Guide

I’ve got a few PHP libraries and classes that I use regularly and, since making the decision to base all my projects on the Laravel framework, have gotten fairly used to installing packages using Composer.

I battled occasionally with getting my libraries to work with Laravel, mostly because of the way I’d written them, but I figured the smart way forward would be to make them available to other Composer users. For PHP, this means structuring the libraries in a specific way and making them available through Packagist, “The PHP package archivist”. You probably know this already, but when you add a package to your project’s composer.json file, Packagist is where it gets downloaded from.

Anyway, after some searching around, I found a bunch of articles that covered how to do *some* of the things needed to create Packagist packages, but no decent end-to-end guide.

So here we go – I’m going to write one. Hopefully it comes in useful.

Pre-requisites & initial steps

  • Sign up for Github. It’s free until you need to go beyond their basic account limitations. Packagist packages are based on Github repository *releases* (or tags).
  • Get familiar with Semantic Versioning, if you haven’t already.
  • Sign up for Packagist. It’s also free.
  • Decide on your *vendor* name – mine is ‘digitalformula’.
  • Install Composer

It’s an excellent idea to have the same usernames on Github and Packagist, if possible.

Creating the base package structure

Create the directory structure for your package. There’s no “right” way to do this, but I’m following the structure used by almost every Packagist package I’ve installed so far. The structure below is for the package we’ll be creating in this article.

Packagist directory structure

Here’s a basic explanation of what each part is.

  • digitalformula – your *vendor* name, your Github username and your Packagist username.
  • hello-world – the name of the package, following proper directory naming guidelines.
  • .git – Git repository information. This gets generated by git when you run ‘git init’ below.
  • .gitignore – list of files that should be ignored during git adds and commits. Each line should contain a filename, path or pattern.
  • src – the ‘root’ directory for your package. It’s also where we’ll tell the PSR-0 autoloader to look – we’ll get to that in a bit.
  • DigitalFormula – the first segment of the PHP namespace we’ll use. This must match your vendor name although at this point you’re free to use appropriate capitalisation, if you like.
  • HelloWorld – the second segment of the PHP namespace we’ll use.
  • HelloWorld.php – the PHP file containing our package’s code. Obviously more complex packages will have multiple files, but a single file will suit us just fine for now.
  • LICENSE – the license that covers usage of your package.
  • README.md – information about your package. Every Github repository should have one.
  • composer.json – probably the most important file here. It describes your package, what it’s for, who worked on it, dependencies and how PSR-0 autoloading will work. Unless you’re interested in the technicalities (I’m not), don’t worry about how PSR-0 works. It just works, I promise.

For those wondering, the complete PHP namespace will be *DigitalFormula\HelloWorld*.

Hold on … namespace? What’s that? If you’re not already familiar with PHP namespacing, I highly recommend reading Dayle Rees’ excellent PHP Namespaces Explained article.

Categories
AJAX Development JavaScript Laravel Uncategorized

Check Laravel user status with AJAX

Like most websites, my current project requires users to login.  For security reasons, user sessions timeout after a while, leaving the user without an authenticated session.  While this is fine for me, it’s not so good for users that may have entered something info a form, hoping to come back to it later.  In some cases, the text may be lost – annoying, no doubt.

Since my PHP framework of choice is Laravel, it was relatively simple to have a background process check the user’s login status and, if their session has expired, show an informative message.

Since this article is just a quick demo, I’m going to check the user’s login status every 60 seconds and show the message if nobody is logged in.  On the production site this will change, although the method will be the same

Step 1 – Setup the JavaScript timer

Here is the tiny bit of JavaScript you need to setup the timer.  Don’t forget to change the element you are binding this to in your application – I’m using <li>, as you can see.

window.setInterval(function()
{
    $( "li#status" ).timer();
}, 60000);

Step 2 – Write the AJAX function that returns the user’s session status.

public function getLoginStatus()
{
    return Response::json( array( 'status' => Sentry::check() ) );
}
/* getLoginStatus */

Step 3 – Setup the timer function that will call the associated AJAX function.

jQuery.fn.timer = function()
{
    $.get( "/ajax/login-status", function( data )
    {
        data.status == false ? $( 'li#status').show() : $( 'li#status').hide();
    });
}

For the functions above, you may need to alter the way they are called if you aren’t using Laravel in your projects (although I recommend it). You’ll also notice that I’m using Sentry::check() – this is how to check a user’s login status while using the excellent Sentry package from Cartalyst.

Here’s what the <li> element looks like.

The element that is displayed when no user is logged in.

That’s really all you need to do, although you may also want to change when the functions are called so that unregistered visitors don’t get shown the message, too.  Easy!