It's nearly been five years since I started working on Simple Commerce. It started out as a way for me to play around with the Statamic 3 Alpha, but slowly and surely grew into the most popular way to build e-commerce sites with Statamic.

From the beginning, I wanted Simple Commerce to feel "native" to Statamic. It should take advantage of using entries to store products, it should tightly integrate with Antlers and seamlessly fit into the Statamic way of doing things.

I also wanted it to be simple to use - without getting in the way when you need to extend it to do something custom.

And from what I can tell from customer feedback, it seems like I've achieved that (🎉).

Over the last couple of months, I've realised that Simple Commerce has become pretty bloated and honestly not as polished of an overall product as I'd like.

So, after thinking about it for a while and doing some exploratory coding, I've decided it's time to rewrite Simple Commerce.

Laravel Herd now has first-party support for profiling, without needing to change any Xdebug settings. See their documentation: https://herd.laravel.com/docs/1/advanced-usage/profiler

I recently made the switch to Laravel Herd, after using Valet for years. Even though Herd is still using Valet under the hood, I've found it to be considerably faster than plain Valet.

One of the things I've been wanting to do for a while is to setup Xdebug in order to perform performance profiling, without needing to subscribe to a service like Blackfire.

Setting up Xdebug with Laravel Herd is pretty simple - you just have to follow a couple of steps on their docs to get it configured. Or, if you're using Herd Pro, it'll automatically enable Xdebug when it detects breakpoints in your code.

By default, Xdebug's debug mode will be configured. However, in order to do profiling, we need to switch to its profile mode instead, this involves a few additional steps:

1. Install Laravel Herd if you haven't already.

2. Enable Xdebug manually or purchase Herd Pro.

   Herd Pro includes some pretty nifty features - like one-click setup for MySQL, Redis, Meilisearch, as well as local email debugging and dump logging (useful if you don't have a Ray license).

3. We need to append a short snippet to Herd's php.ini configuration file in order to change the Xdebug mode. You can find Herd's php.ini files at ~/Library/Application Support/Herd/config/php/<version>/php.ini.

In addition to changing Xdebug's mode, it also sets the output directopry for the generated "cachegrind" files. I've got this set to the root of my project, but you're free to change this to where ever you like.

xdebug.mode = profile
xdebug.start_with_request = trigger
xdebug.output_dir = /Users/duncan/Code/Statamic/sandbox

4. In order for our changes in the php.ini file to take affect, we'll need to reset Laravel Herd. You can do this from Herd's menubar menu:

   
   Click "Stop all", then "Start all".

5. Next, in order for Xdebug to know you want to profile incoming requests, you'll need to install the Xdebug browser extension for whichever browser you're using (found in the Chrome & Firefox extension stores).

   It'll add a little widget to your browser, allowing you to start and stop profiling sessions (or debugging sessions, if you switch back to debug mode).

6. Finally, you'll need to "Start Listening for PHP Debug Connections" in PHPStorm.

After PHPStorm is listening, visiting a page in your browser will generate a cachegrind.out... file in your chosen directory. The "Analyze Xdebug Profiler Snapshot" action will let you open this file and view the profiling snapshot.

If you ever need to switch back to debug mode, simply comment out the additions in Herd's php.ini file and restart Herd for the changes to take affect.

Note: I've only tested this on macOS, however, in theory, it should work the same way on > Windows but the php.ini file will be different.

I've recently found myself going to the GitHub website multiple times a day to gather context on the code I'm looking at in my code editor.

I looked at some VS Code extensions which allow you to view a "git blame" inside VS Code but I didn't really like any of the ones I tried.... so I thought it'd be a fun evening project to build one.

Introducing "Simple Git Blame". Install it, go to a file, select a line (or multiple) and summon the action. The "Blame" page will open in your browser.

You can view the source code here.

An application I work on automatically generates & sends an spreadsheet export, with a few fields pre-filled. The user can then populate the rest of the data and upload it back into the application.

However, one of the fields that's part of that spreadsheet is an enum field. This means that whatever value that's used for the field in the spreadsheet needs to match exactly with the backing value of the enum.

After some digging, I found that I could add a 'select dropdown' to the relevant cells in the spreadsheet. The user could then select what they want from that dropdown and it'll match exactly... woo hoo! 🎉

I've just tagged the latest release of Simple Commerce, version 5. It includes a new concept of order & payment statuses, now supports Stripe Payment Elements out of the box, improves developer experience around building custom gateways & adds support for Statamic 4.

It's come a long way since it was released back in 2020. Let's dive into some of the big new features!

Over the next few days, it's looking like more and more folks will start moving away from Twitter after all that's happening right now.

It looks like Mastodon seems to be the Twitter replacement for lots of Laravel/PHP folks. After seeing Freek's post about Laravel & PHP developers to follow on Mastodon, I thought I'd make an additional list for Statamic developers to follow on Mastodon.

If you want to be featured on this list, reply to my Tweet or post on Mastodon and I'll get you added. I know I've probably missed some people.

• Joshua Blum: [email protected]
• Rob de Kort: [email protected]
• Erin Dalzell: [email protected]
• Dave Smyth: [email protected]
• Me: [email protected]
• Jack Sleight: [email protected]
• Ryan Mitchell: [email protected]
• David Lindahl: [email protected]
• Marty Friedel: [email protected]
• Rias Van der Veken: [email protected]
• ncla: [email protected]
• Johannes Schuba: [email protected]
• Simon Schweissinger: [email protected]
• Konafets: [email protected]
• klickreflex: [email protected]

There's a bunch of different Mastodon "servers" - you can signup for any of them really & you can follow people from different servers. I'm on mastodon.social (a popular one) but there's also other options like mastodon.cloud, mstdn.social and phpc.social.

Justin Jackson has written a post if you're interested in getting started with Mastodon.

Torchlight is a really awesome API for syntax highlighting. In the past, folks might have used libraries like Prism or highlight.js. These libraries work but they're not completely accurate.

Whereas, Torchlight uses the same syntax highlighting system under the hood as VS Code which means it can support any language that VS Code can (including Antlers!)

I've been using Torchlight on this site for a while, along with on my documentation sites. And as I'm seeing more and more folks using it, I thought I'd share how to setup Torchlight to work with Statamic's Bard field.

Duplicator is by far my most popular Statamic addon, by downloads at least. And to be honest, it's probably one of my simplest.

Duplicator registers a few actions: one for each of the 'things' you can delete - an entry, an asset, a term and soon (hopefully) a form.

Actions are what you see when you click the 'three dots' on the listing tables:

Today, I'm going to walk you through the action for duplicating entries (which is probably the one used most often). So let's dig in:

Last year, I unified the way I handled the docs sites for my addons.

They're all handled by a single Laravel app which pulls in the content from each addon's GitHub repo.

I thought it could be interesting to share how it works...

Today I've been playing around with using Laravel Dusk to test a payment form on a small website.

The payment form is a key part of the owner's business so it's crucial it works all the time, whenever the customer makes a purchase.

The site uses Stripe Elements to let the customer enter their payment information securely.

Elements creates its own iframe element which makes it a little tricky to target and test. However, there's a handy method in Dusk which allows you to type inside of an iframe.

$this->browse(function ($browser) {
  $browser->type('@input', 'whatever')
    ->withinFrame('.__PrivateStripeElement iframe', function ($browser) {
      $browser
        ->type('[placeholder="Card number"]', '4242424242424242')
        ->type('[placeholder="MM / YY"]', '0923')
        ->type('[placeholder="CVC"]', '123');
    });
});

Anything you need to type inside of Stripe's iframe you can do inside the withinFrame method and target the relevant inputs via their placeholders.

Hopefully someone finds that helpful! 🙂