I’ve recently been working on overhauling the test database fixture system in CakePHP . My goals are to separate fixture schema management from fixture data management. By doing this applications will more easily be able to use their existing schema management to generate their test database. This project has entailed fixing many differences between the database servers that CakePHP supports.
Tagged with CakePHP
Cake PHP framework
Over the last month, I’ve been building a ‘fun’ project that uses CakePHP, TypeScript and React. While I maintain AssetCompress it is poorly suited for react or vue applications.
CakePHP ships with PHP based templates, and while this works for many people we’ve also recently re-launched the Twig plugin. For that past several years Wyrihaximus has maintained the excellent TwigView plugin. The CakePHP core team has joined forces with Wyrihaximus and taken over completing the 4.
Upgrading major libraries that your application depends on can be a tedious and time consuming process. Dealing with deprecations and backwards incompatible changes can consume a significant amount of time and energy. In the past we’ve relied on manually updating code or using find and replace. But in last few years new techniques have emerged that make routine upgrades easier to do.
A few weeks ago I ran into a tricky to solve issue in CakePHP. It involved an iterator that needs be grown during iteration, and nested loops over that same iterator. While infrequent, there are scenarios where you would want to grow an iterator as it is being iterated. My situation is the plugin registry for CakePHP. Plugins support a
bootstrap hook method that is used to initialize a plugin.
With the release of CakePHP 3.7.0 quickly approaching, I wanted to help validate the release candidates by upgrading a few of my sites and seeing how much work it was. I’d like to share the process I followed for my upgrades on Stickler CI, this site and a few others I maintain.
In the next major release of CakePHP we’re going to be removing the
AuthComponent. This component and its helpers have been part of CakePHP since the 1.2 days, but their time has come to an end. Over the years,
AuthComponent has become a complex and difficult to extend piece of CakePHP. In its wake, we’re promoting two new plugins.
In this three part series, I’m going to cover the evolution of Stickler CI in the past 2 years from the initial prototype to the present day. This specific article will cover how I brought Stickler CI from an unprofitable project to a revenue generating product and the growing pains surrounding that journey.
In this three part series, I’m going to cover the evolution of Stickler CI in the past 2 years from the initial prototype to the present day. This specific article will cover how I built the initial prototype and then added paid plans.
Stickler CI users have expressed that automatically enabling default linters can create a flood unwanted comments in pull requests, which is overwhelming and noisy. In response to these issues, we have changed the process of connecting a repository to Stickler CI.
Integration testing with external webservices, has historically been an uncomforable process in PHP for me. It frequently involves complicated mocking that was fragile and hard to maintain. I’ve long wished for a PHP library that was as simple to use as HTTPretty is in Python.
I’d like to introduce a project I’ve been working on over the past few months. Stickler-CI helps automate the tedious process of ensuring coding standards are followed during pull requests. Like many teams, FreshBooks uses pull requests as a way to solicit feedback from other developers, ensure consistent coding practices and catch bugs before they can cause real problems.
I’m excited to announce the availability of a PSR7 Bridge plugin for CakePHP. This plugin lets you bridge PSR7 Middleware with CakePHP 3.3+ applications.
With CakePHP 3.0 out the door, I thought it would be good to reflect on the project. CakePHP 3.0 is the longest and largest open source project milestone I’ve ever participated in. At FreshBooks we do retrospectives on large projects as a way to see what went well, and what could have gone better. The goal is to discover things we should keep doing, and what to improve the next time around.
One approach to scaling out a database for a multi-tenant application is to horizontally shard or partition the data by customer. This often takes the form of having multiple identical copies of an application’s schema in each shard. For example customer A’s data would be in shard 1, while customer C’s data would be in shard 2.
I recently finished upgrading this site to CakePHP 3.0.0-dev from 2.5.5. I thought I’d share my experiences, as they might be helpful to other people attempting to update a CakePHP 2.x application to 3.0.
In terms of scale & size, this site is pretty small and simple. It has a mere 12 tables, and ~5000 lines of code including HTML, and uses 3 plugins.
Earlier today, I packaged up AssetCompress 0.17. This release has a few noteworthy features.
A few weeks back during CakeFest 2014, I had the opportunity to hunker down and get DebugKit upgraded to CakePHP 3.0. While it was less of an upgrade and more of a re-design and re-write, I think the end results justify the drastic approach I took. First, a few of the problems I was trying to solve in the new version:
1. It is hard to make DebugKit look great as it lives on the same page as your app.
There will be a number of backwards compatibility (BC) breaks in the CakePHP 3.0.0 release. I thought it might be helpful to go over some of the reasons breaks in compatibility have been made. Each time we’ve had to break compatibility with 2.x we’ve done so because the existing behaviour fell into a few categories of problems. I’ll go over a few of the bigger categories in detail.