Ever wanted a quick summary of how many rows are in all of the tables in a MySQL/MariaDB database?
This query will provide that for you. If you’re using the InnoDB storage engine, it’s an estimate; if you’re using MyISAM, then it should be accurate.
SELECT table_schema AS `Database`,
table_name AS `Table`,
FORMAT(table_rows, 0) AS `Rows`
FROM information_schema.tables
-- WHERE table_schema = 'database_name'
ORDER BY table_rows DESC;Inspired by a comment in the Mastering Laravel community, here is a list of resources that have really helped me absorb the ethos of the “Laravel way” of doing things.
The Laravel Podcast has over 130 episodes to date; each season usually has a particular focus. Season 4 in particular covers individual concepts of the ecosystem, while season 5 covers major packages, and season 6 covers more recent developments with Laravel the company. Season 3 interviews well-known and lesser-known developers in the community.
Especially in the first season of the BaseCode podcast, Jason McCreary and Jess Archer discuss general principles not specific to Laravel. This season is basically the podcast form of the book by the same name.
For fortnightly news and events, the Laravel News Podcast fits the ticket. Jacob Bennett and Michael Dyrynda discuss new releases, packages, and tutorials. On the opposite weeks, they also release new episodes of North Meets South, discussing challenges and technical approaches in more detail.
In No Compromises, Joel Clermont and Aaron Saray (self-described as “two old web developers who have seen some things”) discuss a wide range of practical tips for Laravel development, with a special focus on testing.
Mostly Technical is a longer, sometimes-rambly podcast with Ian Landsman (the “godfather” of Laravel) and Aaron Francis. They tend not to be nearly as technical as the others above, but frequently discuss the Laravel community.
The BaseCode Field Guide is a “field guide to writing code that lasts.” It covers a bunch of general recommendations for making your code easier to read and debug.
Laravel Queues in Action provides in-depth look at Laravel’s queue system and how to optimize it for your particular needs.
The Laravel docs: this is the best documentation I have seen anywhere, and I fully credit them for a huge amount of my knowledge about the framework and ecosystem. I’ve read the entire site front to back three times (on different versions) and learned so much every time. While I fully acknowledge that everyone learns differently and reading is not for everyone, I still highly recommend every Laravel developer should read them front-to back. You will learn so much about all the available features and see so many applicable code examples, and will pick up the “feel” along the way.
Spatie open-source packages: you’d be hard-pressed to find more high-quality code written for Laravel than by browsing this site or their GitHub profile.
Harris Raftopolous has been writing an excellent series of daily tip articles exploring features of the framework and how they can be used in real-world applications.
Streaming: I tend not to watch developers live-streaming; it’s just not my preferred method of learning. That said, there are a growing number of great developers streaming and explaining code as they write it. Here are just a few:
Laravel Herd Pro has a really slick SPX profiler integration. Unfortunately, at work I’m on a Ubuntu machine using a custom Docker container to run our app, so can’t take advantage of it.
We have one specific artisan command that takes many hours to run and I’m working on improving the performance.
I wanted to use SPX profiler to track down what was taking so long, and here’s how I got it to work.
Note: I know this is a bit of an unorthodox approach to using Docker containers, but it works for now…
docker compose exec www bash to open a terminal inside the containersudo since we’re already running as a root user inside the container)/usr/local/etc/php/php.ini and add these lines to enable SPXextension = spx.so
spx.http_enabled = 1
spx.http_key = "dev"
spx.http_ip_whitelist = "*"
spx.http_trusted_proxies = "*"pkill -o -USR2 php-fpm inside the container to restart the PHP service (thanks for the tip)http://myapp.test/?SPX_KEY=dev&SPX_UI_URI=/ to visit the SPX Control PanelSPX_ENABLED=1 SPX_REPORT=full php artisan listI spent way too long this morning debugging an issue with Debugbar for Laravel.
I had recently deleted the storage/debugbar directory while troubleshooting a different issue. Even though I had recreated the directory and all of the filesystem permissions seemed to be correct, I was still getting errors like this in my logs every time I loaded a page, and the debug bar would not show up at all:
local.ERROR: Debugbar exception: File does not exist at path /srv/storage/debugbar/01JP802XSAAA12MP4PZMARSPZD.jsonEventually I was able to solve it by following these steps:
php artisan vendor:publish and choose Barryvdh\Debugbar\ServiceProvider to publish the config/debugbar.php file (if not already published)storage.driver section from 'file' to 'redis''file'config/debugbar.php file (if no other customizations are needed)I had a need today for a Livewire component to set a cookie, and wanted to test that it was actually set correctly.
Livewire includes support for reading cookies, but not for writing them.
And unfortunately, the redirect helper method doesn’t include any way to set a cookie.
Thankfully, Laravel provides a Cookie::queue() method that will attach set the cookie on the next outgoing response, and since Livewire method calls result in a HTTP response (unless you use the renderless attribute), the framework takes care of attaching the cookie for you:
Cookie::queue('name', 'value', $minutes);However, I found it counterintuitive to test this behavior.
There is an assertCookie() method available when testing the component, but it always fails because we’re testing a Livewire component, not a request, and so the framework doesn’t attach the queued cookie(s).
My solution: use Cookie::queued() to retrieve the queued cookie, and then run assertions against that:
Ever needed to cancel a specific batch of queued jobs? Neither the framework nor Laravel Horizon provide an easy way to do this.
Introducing the macbookandrew/laravel-queue-cancel-batch package: you can run php artisan queue:cancel-batch and it will ask you which of the current batches you wish to cancel.
Find more here.
TL;DR: pass a function instead of Feature::active(…) to your console jobs’ ->when(…) method.
I recently upgraded an app from Laravel 10 to Laravel 11 (I know, I know…I’m a few months behind).
This app was using Laravel Pennant to conditionally register some jobs, based on feature flags:
Schedule::job(GetNewOrders::class)
->when(Feature::active(GetOrders::class))
->everyFiveMinutes();Laravel Shift moved these jobs from app/Console/Kernel.php to routes/console.php as expected for the new Laravel 11 structure.
However, for every test that I ran, I was getting these errors:
Base table or view not found: 1146 Table 'test_database.features' doesn't existI spent a bit of time troubleshooting and verifying that the migration existed, the database schema was squashed, etc. I was expecting it to fail during the setUpTraits() step of booting the framework, but it actually failed while booting the application. I stepped through more of the setup steps (thanks, xdebug!) and realized that it failed while discovering commands.
That prompted me to comment out the ->when(Feature::active(…)) lines, and voila! my tests suddenly worked!
The when() method accepts either a boolean or a Closure, so I tried wrapping the feature flag in a closure, and my tests still worked:
Schedule::job(GetNewOrders::class)
->when(fn () => Feature::active(GetOrders::class))
->everyFiveMinutes();It appears that if your scheduled job ->when(…) conditions depend on the database, you’ll want to wrap them in a function so they aren’t evaluated until they’re actually needed, after the database has already been set up.
If you are using Laravel Herd Pro with a MySQL database, you may run into the “Error establishing a database connection” error.
To fix this, change your database host settings from define('DB_HOST', 'localhost'); to define('DB_HOST', '127.0.0.1'); and that should do the trick.
This can also fix errors from other software that attempts to connect using a socket (e.g., “Can’t connect to local MySQL server through socket ‘/tmp/mysql.sock’”).
Laravel Herd is an amazing application designed to make it as easy as possible to get started with PHP development.
I have been using Homebrew to run MySQL, Redis, Meilisearch, and more, but since we recently got Herd Pro, I figured it made sense to consolidate.
Here are a few other articles on how to migrate databases to Herd Pro:
mysqldumpMy method is a combination of the two: copy the data files from the Homebrew MySQL to Herd Pro to save the time that it would take to dump and import.
Note: this only works if your homebrew MySQL and Herd Pro MySQL are on the same minor version (8.0.1 to 8.0.3 would work; 8.0.x to 8.4.x would not).
brew services stop mysql (or maybe [email protected] if you’ve updated in the past few months)open $(brew --prefix)/var/mysql to open the directory in Finderbrew uninstall [email protected]I had the privilege of going to Laracon this past week and thoroughly enjoyed both the talks and hanging out with people I previously knew only online.
There are enough other articles about the announcements, so I won’t really recap them too much, but wanted to note some of my thoughts and reactions for each.
Overall, I loved the chance to hang out with and meet other Laravel developers. I got to meet several friends that I only knew online, and got to meet a bunch of new people as well.