Phinx joins CakePHP!

These are some really good news – Phinx joins CakePHP family!  If you are from a different technology stack and not familiar with these, Phinx is an excellent database migrations tool, which has been used by CakePHP framework for a while now.  The two worked great together.  Now that they are under the same roof, I’m expecting even more goodies!

We are very excited to announce that Phinx has joined the CakePHP team. The Github project has already been moved to the CakePHP organisation. The project itself will stay MIT-licensed but be gradually transformed into a Cake Software Foundation project. Other great news is that the current way to install and update Phinx remains unchanged.

As you are aware, CakePHP has been using Phinx since 3.0.0 for database migrations. The CakePHP Core team welcomes the opportunity to look after and maintain the project and will now start making changes to bring the code in line with the CakePHP (our) coding standards. As well as cleaning up issues and PR’s soon. We will be following up with our plans for the code and setting roadmaps in the coming weeks.

We welcome Phinx to the CakePHP family and hope to see Rob Morgan, Richard Quadling, Woody Gilk around!

Getting started with workflows in PHP

For a large project at work, we need to integrate or develop a workflow engine.  I worked a little bit with workflow engines in the past, but the subject is way to big and complex for me to claim any expertise in it.

So, I am looking at what’s available these days and what are our options.  This post is a collection of initial links and thoughts, and it’s goal is mostly to document my research process and findings, and not to provide any answers or solutions yet.

Continue reading “Getting started with workflows in PHP”

CakePHP 3 : Remove Shell Welcome Header

CakePHP 3 has an excellent support for command line Shells, Tasks, and Console Tools.  There are a few that are bundled with the framework itself, and that come from a variety of plugins.  And, of course, you can have your own commands, specific to your application.

$ ./bin/cake

Welcome to CakePHP v3.4.3 Console
---------------------------------------------------------------
App : src
Path: /home/leonid/Work/cakephp_test/src/
PHP : 7.0.16
---------------------------------------------------------------
Current Paths:

* app:  src
* root: /home/leonid/Work/cakephp_test
* core: /home/leonid/Work/cakephp_test/vendor/cakephp/cakephp

Available Shells:

[Bake] bake

[DebugKit] benchmark, whitespace

[Migrations] migrations

[CORE] cache, i18n, orm_cache, plugin, routes, server

[app] console

To run an app or core command, type `cake shell_name [args]`
To run a plugin command, type `cake Plugin.shell_name [args]`
To get help on a specific command, type `cake shell_name --help`

There is one tiny little annoyance though.  Sometimes, it’s useful to get an output of the CakePHP Shell and use it in another script.  For example, you might need to get a list of all loaded plugins and loop over them, performing another action, outside of CakePHP.  Say, in a bash script.  Getting a list of loaded plugins is easy with the bundled shell like so:

$ ./bin/cake plugin loaded

Welcome to CakePHP v3.4.3 Console
---------------------------------------------------------------
App : src
Path: /home/leonid/Work/cakephp_test/src/
PHP : 7.0.16
---------------------------------------------------------------
Bake
DebugKit
Migrations

But, as you can see, the output is not very useful for machine processing. The welcome header is in the way.  Sure, you can parse it out with regular expressions, or even a simple line count.  But that lacks elegance.  Is there a better way?  I thought there was.

My first approach was to use the –quiet option, which, I thought, would leave me with just the needed output.  It turns out, that’s not what it does.  It strips out all the output, and there is no list of plugins at all.

The second approach worked out better.  I learned about it from this thread.  The solution is to extend the needed CakePHP shell and overwrite the protected _welcome() method.  Here’s the content of the newly created application level shell in src/Shell/PluginShell.php:

<?php
namespace App\Shell;

use Cake\Shell\PluginShell as Shell;

class PluginShell extends Shell
{
    /**
     * Silence the welcome message
     *
     * @return void
     */
    protected function _welcome()
    {
    }
}

And now running the same command as before produces a cleaner output:

$ ./bin/cake plugin loaded
Bake
DebugKit
Migrations

This now can be easily used in other scripts without any need for regular expressions and other trimming techniques.

Composer require inline alias

Here’s a feature of composer that I didn’t know about until a few days ago – require inline alias.  Here’s the example from the documentation:

{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/you/monolog"
        }
    ],
    "require": {
        "symfony/monolog-bundle": "2.0",
        "monolog/monolog": "dev-bugfix as 1.0.x-dev"
    }
}

This is super useful when you have dependencies in your project that require a particular version of a third-party library or plugin, and you want to try a branch of that library or plugin. Switching to the branch alias doesn’t solve the problem, as everything that has version constraints on that requirement, will complain. With inline alias, you can alias a particular branch of the dependency as a particular version.

With inline alias, composer will fetch the branch that you want, but will assume that that branch works as a particular version that you specify, and thus satisfy all the other dependencies that require that particular version.

In my particular case, I was working on the CakePHP-based application, which was using a few CakePHP plugins (installed via composer).  Those plugins require CakePHP v3+.  I wanted to test a branch of CakePHP which had a particular fix I was interested in, but without disabling all the plugins.  Switching my application’s composer to require a branch dissatisfied all the plugins, as now composer didn’t know if the branch that I am requiring is of the CakePHP v3 or not.  Aliasing the branch to v3.4.1 (current stable version at the time) worked like a charm.

CakePHP 3 and the need for breadcrumbs

I’ve been catching up with the CakePHP roadmap.  One of the tickets for the next release (CakePHP 3.3.10, scheduled for tomorrow), is this ticket, relating to the breadcrumbs navigation.

When building applications with CakePHP, you have a couple of easy ways to generate breadcrumbs for the easier user navigation.  One, is to use HTML Helper, which provides a quick and simple way.  The other, is to use a feature rich Breadcrumbs Helper, available since CakePHP version 3.3.6 (but not mentioned in the release notes).

Digging further down into templates, and best practices for user navigation, and different ways of styling breadcrumbs (Smashing Magazine, Hongkiat, UI Patterns), I thought – wouldn’t it be nice to have breadcrumbs navigation built into a human brain?

I mean, how many times did you catch yourself in some dark corner of the Internet, trying to figure out how did you get there?  If only humans had breadcrumbs navigation built into our brains, that would be so easy to trace back the steps.  Browser history can, of course, help, but with so many open tabs and several things happening in parallel, a flat list of tabs is not much help.

Adventure in composer private repositories

First of all, I would like to take this opportunity and wish composer a happy birthday and many more years to come.  It’s been five years, and the world of PHP has changed so drastically that not many people remember how it used to be before.

I would have completely missed the birthday if it wasn’t for all the Google searching I did while working on a weird problem.  But before I get to the problem, let me set the scene.

The big part of composer success is Packagist.org – the repository of almost 100,000 packages (93,572, according to statistics, as of this writing, to be precise), which help one to solve pretty much any problem that PHP can be used for.

As good as the Packagist is, there is often a need for a repository or a package elsewhere.  Whether it’s a commercial library, or sensitive corporate code, having an ability to store it outside of public eye and handle with the same ease and the same tool as the rest of the dependencies is a very welcome feature.

Now we are getting closer to what actually happened.  A while back, I’ve setup deployment and development process for WordPress-based projects.  WordPress doesn’t support composer natively, but there are ways to make it work.  Huge thanks here goes to Roots.

So.  The composer.json file was filled with additional repositories and requirements which told composer where from to fetch things, and where to install them.  Here’s an example:

"repositories": [
    {
        "type": "package",
        "package": {
            "name": "wordpress",
            "type": "webroot",
            "version": "4.4.1",
            "dist": {
                "type": "zip",
                "url": "https://github.com/WordPress/WordPress/archive/4.4.1.zip"
            },
            "require": {
                "fancyguy/webroot-installer": "1.1.0"
            }
        }
    },
    // ...

This got especially useful, when we need to work with commercial plugins, which we couldn’t push to our public repositories, and which we didn’t want to re-distribute with every project.

So far so good. Fast-forward to a few month ago. We are setting up similar development and deployment process, but now for CakePHP-based projects. Things are much easier, since CakePHP 3 natively supports composer for the application itself and for its plugins.

But we still have the need for private repositories here and there, so we follow the same setup as we did for WordPress. This week, we had an unexpected roadblock, which wasn’t making much sense to me. When trying to pull a CakePHP plugin from a private repository, we’d get a nasty exception like this:

$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing qobo/cakephp-test-foo (1.0.1)
    Loading from cache


                                                                                                                                              
  [RuntimeException]                                                                                                                          
  Unable to get primary namespace for package qobo/cakephp-test-foo.                                                                          
  Ensure you have added proper 'autoload' section to your plugin's config as stated in README on https://github.com/cakephp/plugin-installer  
                                                                                                                                              

This was confusing. First of all, I’ve never seen this error before. Secondly, I’ve read the README and had the autoloader section in the composer.json as instructed. Thirdly, very similar plugins were working fine.

Long story short, the issue wasn’t related to whether or not the GitHub/BitBucket repository was private or public. It was related to how the repository was configured in the composer.json. Reading and re-reading composer documentation about Repositories finally helped.

You can have a look at our test setup:

CakePHP plugin installer requires the autoload section in composer.json.  But, when the repository is of type “package“, for some reason, the autoload section is ignored altogether.  The RuntimeException “Unable to get primary namespace for package” is thrown by cakephp/plugin-installer (src/Installer/PluginInstaller.php line 274).  The problem is not actually in the cakephp/plugin-installer, but somewhere in the composer.  Maybe it’s intentional or maybe it’s not.  I didn’t have the time to investigate and understand it further.

Switching the repository to type “vcs” fixes the problem.  It also simplifies the composer.json file and removes the need for multiple version definitions, as now composer is using BitBucket/GitHub API to fetch available versions.

CakeFest 2016

I’ve just purchased my ticket for CakeFest 2016! Feeling super excited … Whoop whoop! :)

I’ve attend quite a few events in the last 15-20 years, ranging from generic TEDx, through startup and entrepreneur, generic technology, web development, PHP, and software specific ones.  CakeFest 2014 back in Madrid, Spain was one of the most memorable and is definitely in top 3 of my all time favorites.  So I’m excited about the opportunity to do it all over again, this time in Amsterdam, Netherlands.

If you are involved at all with CakePHP framework, I strongly recommend you get your ticket, while it’s still at the “blind bird” price of $150 USD for the two day conference event.  If you are very new to CakePHP, you might want to consider the workshops as well, but make sure you do the main conference no matter what.

CakeFest 2015 Presentations

CakeFest 2015 Presentations – a convenient list of all CakeFest 2015 presentations in one place.  Not sure how permanent the site is (I have a feeling this is a quick CakePHP coding experiment during the event), so hurry up and grab the links just in case, until something better comes out.  There were some really good talks by the looks of it.  Too bad I didn’t make it this year.