Update Aug, 11: This post was well received on Reddit, so I added new anti-patterns to reflect the comments. Recently, I had the chance occasion to work on numerous legacy PHP applications. I spotted common anti-patterns that I had to fix. This article is not about rewriting an old PHP application to <insert shiny framework name here>, but about how to make it more maintainable and less of a hassle to work on....
Let’s face it, WordPress’ reputation among PHP developers is atrocious. It is, for the most part, justified by the questionable code quality of most plugins (because the barrier entry is very low), the will of the core developers to keep backwards compatibility at all cost, and, as a result, its architecture. However, as you may have noticed, this blog is running WordPress. Why would you ask me? Well, despite all its flaws, WordPress is stupidly easy to use and complete....
Since I’ve been playing around with Laravel Envoy, I kept wondering how I could improve the deployment process. For sure it works and I’ve been using it for 6 months or so on a project in production, but having to deal with a physical server has drawbacks I wanted to overcome. For example, the PHP team just released 7.4 packed with cool features I am eager to try. But on a physical server, one has to manually upgrade the PHP version, for each environment and this is a process prone to errors and can lead to different results in different servers....
I was looking for a replacement for the syntax highlighter I was using on my blog, since SyntaxHighlighter Evolved never really gave me satisfaction (unwanted advertisements next to the code blocks, poor styling). I wanted a lightweight solution and found highlight.js. It highlights blocks on code on the client side and can be enabled with just a few lines: <link rel="stylesheet" href="/path/to/styles/default.css"> <script src="/path/to/highlight.pack.js"></script> <script>hljs.initHighlightingOnLoad();</script> There used to be a plugin to integrate it to WordPress but it was removed for security reasons (I am not sure what this means)....
I had to work on a project that made heavy use of MySQL routines: stored procedures, views, functions and triggers. In the process of adding Laravel to the application, I found good packages to seed the database from existing data, create models from the existing schema and create migrations from existing tables. However, I could not find anything to migrate the existing routines as a migration. I needed this to be able to make the existing application work when seeding a new database....
Recently, I was looking for a way to deploy a Laravel application with ease and no headache. After some time, I wrote a very basic Bash script to automate the common deployment tasks: pulling changes from Git, installing Composer dependencies, building NPM scripts, running migrations and so on. But it was still feeling primitive. There had to be a better way. After some research, I found Laravel Envoyer. This service offers everything I needed but I was not ready to pay the costs associated....
As part of my Software Verification and Testing class at Concordia University, my team and I chose to study empirically the performance of some popular Laravel applications. The goal was to replicate the paper “How not to structure your database-backed web applications: a study of performance bugs in the wild” by Junwen Yang et al. This paper, focused on the Ruby ecosystem, found that ORM API misuses such as inefficient queries, lack of pagination, inefficient eager loading or lazy loading were common causes for performance degradation....
Lors d’une requête POST en Ajax sous Laravel 5, il faut passer le jeton CSRF sous peine de recevoir une erreur de TokenMismatch, la protection contre les failles CSRF s’activant. Pour ce faire, je ne trouve pas la documentation très simple, alors qu’il suffit de passer l’attribut ‘_token’ dans le champ data (sous jQuery). Ainsi, il n’y a qu’une ligne à rajouter : $.ajax({ type: "POST", url: "{{ url('/votre-url') }}", data: { ....