While I, Josh, had a rather short train journey from Germany, both Duncan and Erin arrived by plane. Erin even crossed the pond and came over from Vancouver, Canada! Some jet lag, stroopwafels (Dutch waffle), and a healthy dose of excitement set the tone for the week. The three of us (and many more) stayed at the Movenpick hotel right next to the venue, which made things much easier.
We decided to make the most of our time in the Netherlands by gathering the Statamic community the evening before the conference. So on March 1st, we hosted a Statamic meetup at Bar Botanique in the east of Amsterdam, known as the "green oasis". It was actually the exact same place we did our meetup two years ago. The place, once a primary school gymnasium and now a bar/café with a mezzanine and lush plants, served as our jungle‑themed living room.
More than 30 of you showed up! We chatted over drinks and food, brought some sweet Statamic stickers for you, and talked about Statamic and life. Every single one of you who attended helped make this gathering feel special, so Thank You!
Early Monday morning, registration took place and Nuno Maduro took the stage as MC to welcome everyone and kick off conference.
Here are some of the highlights from the first day:
Kind of a tradition by now, the day closed with the keynote from Taylor Otwell, creator of Laravel.
Taylor’s talk was pretty packed with updates regarding the Laravel core and framework itself (Laravel 13 drops March 17th) as well as updates related to the general Laravel product ecosystem and a wild demo using AI.
Laravel 13 will include some pretty neat things, like added PHP attributes across 15+ locations, a Reverb database driver (no need for Redis), built‑in passkey authentication, and a stable Laravel AI SDK. Official starter kits will gain proper team support as well. Those are just some of the coming updates.
The real showstopper was his live AI demo though. Taylor deliberately introduced a bug into a demo app. Nightwatch (Laravel's monitoring solution) caught the error. He then went on to ask his AI agent via voice prompt to fix it and the agent used Nightwatch’s API to analyze and suggest a fix, spun up a disposable Laravel Cloud instance, created a pull request and asked for approval. Watching the bug getting fixed and deployed by AI already felt pretty cool. When his personal AI assistant called him live on stage to confirm merging the PR though, that was just wild. I was both impressed and laughing at the same time.
As the sun set, we enjoyed a little team dinner and headed for the Laracon After Dark party, which was on the other side of the river IJ. That meant we actually had to take a ferry. Cool thing is that it's part of Amsterdam's overall public transport system, takes less than 5 minutes, and is even free!
The second day of the conference began with a talk by Joe Tannenbaum titled "State of the Frontend" in which he also talked about Inertia 3 launching soon. That's interesting for us since Statamic 6 now runs on Vue 3 and Inertia.js.
Even though the individual videos of the talks are not up yet, you can watch the entire stream for day 1 and 2 over on Laracon EU's YouTube channel. The individual videos should hopefully be up soon 🤞.
As always with Laracons, Laracon EU 2026 was more than a conference. It's not just about the talks, it's about spending time with like-minded people and sharing an experience as well as celebrating both the Laravel and Statamic community.
The conference left us inspired and sparked some new ideas for what we can do with Statamic (not that we have enough ideas already). Laravel 13 support for Statamic is just waiting to be merged once v13 officially gets released later this month. And above all, our community meetup and talking to you all at the conference reminded us how much we love connecting with you all face‑to‑face. Stay tuned for updates on Flat Camp #3 and we hope to see some of you at Laracon US in Boston, July 28-29!
From the canals (Grachten in Dutch) of Amsterdam to the talks inside the Passenger Terminal, Duncan, Erin, and I had an amazing time at Laracon this year and are really proud of this community. Until next time, tot ziens (goodbye in Dutch)!
]]>At this point you'd think we'd play it cool. Maybe a casual nod, a humble "aw shucks." But no — we're going to be annoyingly proud about this every single time, because every single time it means our community showed up and voted their hearts out. And that never gets old.
The CMS Critic Awards are an annual community-voted program now — apparently — in its 14th year. Thousands of people nominate and vote across categories like Best Enterprise CMS, Best Open Source CMS, Best Headless CMS, and — the one we have a pretty solid corner on — Best Flat File CMS.
It's not a panel of judges in a boardroom. It's people who actually use these tools, casting votes for the ones they believe in. That's the part that gets us.
We could give you the feature list — the giant pile of powerful fieldtypes, the raw power of Antlers, the Git-native workflow, the beautiful Control Panel that makes you forget you're using a CMS. And those things matter.
But honestly? We think we keep winning because Statamic feels different. It's a CMS built by people who care about the experience of building websites — not just the end result. Every decision, from the way you drag and drop pages to build navigations to the way the asset editor lets you set focal points and crop images, is made by a small team that uses this thing every day and refuses to ship anything they wouldn't want to use themselves.
We believe that philosophy shows up in the product. And apparently, people notice.
To everyone who nominated us, voted for us, shared the link, and rallied the community — thank you. Six years in a row doesn't happen without people who genuinely love what we're building. Maybe next year we can even pick up another category.
We don't take that for granted. Not even a little. Now if you'll excuse me, we have features to ship. 💜
]]>Well. Now it kind of is. At least in this one, very specific way.
Statamic now has built-in image cropping — right in the asset editor, right where you're already working. No more round-tripping to an external image editor just to chop off someone's elbow.
Here's what you get:
The whole thing is powered by cropper.js and feels snappy. No loading spinners, no waiting around — just grab, drag, crop.
When you finish cropping, you get a choice — save as a brand new image (with a timestamp so nothing gets overwritten) or replace the original entirely. Either way the image cache gets busted automatically, so no stale thumbnails.
This feature landed in Statamic 6.5.0, released on March 5th, 2026. 💜
]]>Not in a confetti-cannons-during-a-keynote-style-movie-trailer kind of way — just… done. Solid. Real. Tagged. Stable. Shipped. With immense pride in our human-written and hand documented code.
If you’ve followed along through the sneak peek, the beta, or the year-in-review post, you already know what went into this. We’ve talked about the architecture. We’ve talked about Vue 3. Inertia. The Control Panel redesign and rewrite. The UI component library. The foundational improvements. The refactors. The 1,000+ PRs. The commitment to the future.
This release is like a line in the sand. Or maybe more starter's pistol firing at the start of a marathon. The beginning of big things to come.
A lot of software gets louder over time. Busier, more complicated. The UI gets cluttered, the nav structured and reorganized into an obtuse mess in a desperate attempt to jam more perceived value into the shareholders report.
We wanted to do the opposite. Statamic 6 is us doubling down on being:
We said "not yet" to good ideas. Necessary ideas. We said "no" to trends. We said "later" for features people asked for — because the foundation wasn't ready. That's difficult for me because I genuinely want to make everybody happy. Restraint isn't easy. But by exercising it, we bought ourselves something more rare in the world today: confidence.
We removed unknown unknowns. We have the patterns and tools to build a whole new host of features and experiences needed to support the rapidly changing landscape of the internet today.
We nuked tech debt from orbit.
Statamic 6 is our way of recomitting to providing a certain kind of software. Software that's increasingly hard to find today. We're not trying to become:
We care about developers and the feeling you have when your tools bring you joy and earn your trust. We care about editors feeling empowered and confident in their experience, not overwhelmed or frustrated. We care about providing designers with freedom. We care about teams building things they're proud to maintain.
So yes — Statamic 6 is out, and yes — it’s the big one.
All the work we've put into it adds up in ways that are hard to screenshot but easy to feel. So we recommend you just install this sucker and feel it for yourself.
This release includes over 1,000 PRs of improvements, so we'll just keep this list short and sweet.
And that's just scratching the surface.
If you’re ready to dive in, here are a few good places to begin — depending on where you’re coming from.
New to Statamic? Start with the installation guide and get a fresh project up and running in minutes.
→ https://statamic.dev/installing
Upgrading from Statamic 5? We’ve put together a clear upgrade guide that walks through what’s changed and what to watch for.
→ https://statamic.dev/upgrade-guide/5-to-6
Want to explore what's new? Check out the changelog! Buckle up, there are 1000+ PRs in this release.
→ https://github.com/statamic/cms/releases/tag/v6.0.0
The docs have been updated alongside v6, with refreshed examples, screenshots, and guidance throughout.
→ https://statamic.dev
With v6 tagged, we can shift into several new efforts.
And time will tell what else. 😎
]]>We ran an extra-long Alpha Phase (21 releases to be exact) so as many developers as possible could have time to test it out, get their addons upgrade-ready, and be aware of the breaking changes from v5. No more rushing. No chaos. No surprises.
For this reason, I fully expect the Beta Phase to be quite short, relatively speaking. We're done making breaking changes — it's now just up to you, our community, to give it a go and let us know if we missed anything of vital importance that would prevent us from tagging the final stable build.
These would be (implausible but not impossible) things like – we accidentally deleted a whole feature unintentionally and didn't document it as a breaking change, a fatal error occurring on upgrade, and so on.
If you run into something like that, please open an issue! Otherwise sit tight, that stable label is coming real soon.
Honestly, the easiest way would be to just ask Claude Code to upgrade your project to Statamic 6 Beta, but if you want to do it by hand (we still love and mostly prefer to do things by hand), all you need to do is update your statamic/cms dependency constraint in your composer.json file to the following:
"statamic/cms": "^6.0"
And then run the following from the terminal:
composer update statamic/cms --with-dependencies
Statamic 6 does require the minimum version of 8.3 for PHP and 12 Laravel.
You may want to read the entire upgrade guide.
You can also read more about how we spent 2025 working on Statamic 6 and what's included in it. Cheers!
]]>If you’ve been following along, you may have noticed that Statamic 6 didn’t land as early in the year as originally planned. That wasn’t due to uncertainty, scope creep, or external pressure — in fact, quite the opposite.
We wanted this update to be different. Statamic 6 isn’t just another iteration — it's not a little makeover and a quick dependency update — it’s a release designed to set us up for the next 5–10 years. It's a chance to eliminate our technical debt and set the entire community up for massive success and reduced friction across the entire landscape of the Statamic ecosystem. And if that sounds ambitious, it's because it is.
Instead of trying to cut corners or cut out features we felt were critically important just to hit an arbitrary launch date, we just threw out the date altogether. In short — it takes what it takes, and that's that.
Here we are mid-December and I'm happy to say that Statamic 6 is ready. It's more than ready. By design. We'll wait until the New Year to tag everything and call it final, but as far as we're concerned here, we're just crossing our eyes and dotting the tees.
And all this along with keeping Statamic 5 up to date, adding quality of life improvements, fixing issues, and backporting a few nice things here and there from our v6 work.
As of this blog post, our Statamic 6 branch represents the efforts of 883 PRs.
What are these big, fundamental changes and updates, and why should you care? Glad you asked.
Those changes fall into 3 main buckets – Modernizing our architecture, Extensible UI/UX, and Security. I want to get into a bit more of the thought behind these changes, rather than just running down screenshots, which we've already done in this preview post.
If you peel back the sticker on Statamic 6, you'll find a major modernization of the control panel’s architecture. We didn't just paint the walls; we ripped out the wiring and replumbed it for the next decade.
We’ve fully embraced Vue 3, which brings improved performance, the ability to use the latest and greatest third-party components and libraries, and sets us up for long-term supportability. Vue 2 is dead. Long live Vue 3. We shoulda done this a while ago—it's table stakes. But this is just where Statamic 6 started and this part was finished back in February or March.
With all this new sexy JavaScript and Vue under the hood (and a little bit of TypeScript here and there), it was increasingly and painfully obvious that our Control Panel's MVC-type approach (using full page requests that require hydrating all of our Vue components every request) was no longer acceptable. If it ever was. I mean, for most people it really did feel snappy, but it had some serious flaws on more robust sites.
So rather than saying "oh well we'll fix it in Statamic 7" because the schedule says we ship now, we just kept our momentum moving forward and refactored the entire Control Panel to use Inertia.js. Inertia allows the Control Panel to run as a SPA (Single Page Application), but with controllers and blade templates, so we didn't have to rewrite everything from scratch and duplicate a ton of work.
We care immensely about upgrade experiences and feel the burden of not wanting to force people to write or abandon their addons and hard work, so we set out and solved the problem before it became one. Any addons or extensions that aren't updated to use Inertia will simply trigger a page reload and everything will Just Work™. Nobody's site breaks, everybody's happy.
This gives us a huge performance gains as the UI no longer has to reload statelessly every request. Every action you take feels nearly instant. It's smooth as butter and tastes even better. Butter is butter (IYKYK). 🧈
We created a brand new internal UI component system that we then used to redesign/refactor the UI. Instead of a bunch of one-off CSS classes and monolithic super components, the control panel is now assembled with lots of discrete, documented, and tested UI components that everyone can use to customize and extend their own addons and extensions.

Not only that, but we took the time to refactor many of our "internal" components (e.g. Listings) to make them easy to use in your addons or CP extensions.
We then integrated Storybook.js so you can explore all the components interactively along with proper documentation. It's a thing of beauty.
Many of these components are built on top of Reka UI, an unstyled primitive component library for Vue that helped us level up our accessibility and composability game.
We took the opportunity of a UI redesign to finally lean all the way into the Tailwind way of doing things. Statamic 6 uses native Tailwind color palettes, native CSS variable configuration, the latest Vite configs, and we've done what turned out to be the very painful, tedious work of fine-tuning a perfect front-end Vite build system for addons so everything Just Works™, compiles, and doesn't clash or collide with our first-party CSS. 😅
Antlers isn't going away and Blade is here to stay, so we did the hard work and made them play even nicer together. There is no right or wrong answer when it comes to template languages — this is a you preference. But in Statamic 6, you'll be able to use Blade Components in Antlers, and tap into Antlers Tags in Blade. Like so:
<!--This works in Antlers-->{{ collection:pages }} <x-card :$title />{{ /collection:pages }}
<!-- This works in Antlers *and* Blade --><s:collection:pages> {{ $title }}</s:collection:pages>
We now store dates in UTC but display them in each user's local timezone. We can write that in 14 words but I assure you, it took a lot more work implement. This was often a point of confusion as to what actual date an entry ever really lived on. If an author was in the UK and published an entry at 1am but the site was in the US, was it yesterday's? Gone is the confusion. Consistency is king.
The most visible change in Statamic 6 is the completely redesigned control panel — but what’s important isn’t just how it looks. That's why I didn't start this post with the obvious sizzle. I want you to understand why we did all the things we did.

This redesign represents a fundamental shift in how the control panel is structured, extended, and will continue to evolve. It wasn't just a redesign for redesign's sake.
One of the main things we wanted to solve with the redesign is to free us from some areas of the UI where we ran out of room to grow. Like, just literally there was no space left to put features, buttons, controls.
Here's just one example:
All of our listing tables in v5 used this pattern where when you click the checkbox for a row to perform bulk actions, those bulk action controls were absolutely positioned on top of the table header, which covered up the column names and made it near impossible to wrap a long list of actions to another row on smaller viewports.
This had the side effect of us not wanting to add new bulk actions because they had no space to live. This also made the Filter Bar unable to adapt responsively because of that same absolutely positioned bulk action toolbar. 👇
In v6 we popped out the Bulk Actions toolbar into an overlay which can now wrap as needed on its own, and the table design also stands alone in its own Card Panel, giving the filters area a chance to grow and shrink without needing to care about the table itself. 👇
We had so many of these little pigeonholes throughout the UI and now they're all gone. Every single one of them. It's such a huge weight off our shoulders to know that the Control Panel can grow in any direction again — it gives us room to adapt and react to whatever the future brings.
Any time you redesign something, there will be resistance. I'm the first person to complain about iOS/MacOS redesigns (I still refuse to switch to Tahoe), I totally get it. And this redesign was no exception — there was a bit of noise about our color and contrast choices and a few areas of the UI. We ruffled a few feathers, I guess you could say. Some feedback was preferential, while others were more universally valid and we worked through resolving those concerns without compromising the intent behind them.
In the new UI we opted for the default experience to be a bit more stark — a white content background by default (for example) compared to v5's gray. It's a bit more like Shadcn/Clerk/Laravel Cloud, and other — shall we say — "modern" UIs. I really like this look, it feels super fresh to me while still keeping everything pretty much right where it was before — positionally.
I just wanted to make sure we used this opportunity to keep Statamic from looking dated and not have people rule it out at first glance as old, abandonware. That first look experience is huge.
But some people really prefer a different contrast and/or color experience, and rather than push them away to a whole different CMS just because of a CSS value or two, we did the hard work and made the whole UI themeable with a dozen or so color variables you can control as you wish.
Now you can configure all the main global colors (header, background, sidebar, primary/accent/success, etc) to be just the way you like it, and the UI should (as much as is feasible) adapt to your choices with tinting, borders, overlays, etc and just look real tight and consistent. You could even just switch between Tailwind's different gray palettes (Stone, Zinc, Neutral, etc) with one click for an ever-so-slightly revised vibe.
Themes are stored as Preferences, which mean they can be set globally for the site and overridden on the role and user level.
You can even publish your theme to your statamic.com account and share it with the community.
Security features are usually the first thing companies lock behind a "Contact Sales" button. We think that sucks. In Statamic 6, we’ve decided to level the playing field by bringing these high-end security standards directly into the core. Our goal is to make enterprise-grade protection the default for everyone—from solo bloggers to global agencies—without the need for additional setup, third-party overhead, or "enterprise" tax.
The introduction of native Two-Factor Authentication is a major step in this direction. While 2FA has been possible through our third-party addon community, making it a first-class feature ensures that every site has a rock-solid, standardized path to secure user accounts. It supports TOTP apps like 1Password and Authy right out of the box, providing a seamless setup flow that feels like a natural part of the user experience.

We’ve also brought Passkeys into the core, making passwordless authentication accessible to every project. Statamic 6 supports biometric login—like TouchID, FaceID, or hardware keys, so you can satisfy the needs of your organization or clients with whatever solution is best.
Security should also scale with how much damage you can do. We've introduced Elevated Sessions, which requires re-authentication before a user can perform high-stakes operations like changing system-level settings or managing users.
The real power of these features lies in their deep integration with the rest of the platform. Because they are native, you get a unified, polished interface where security doesn't feel like a separate layer you have to manage, but rather just another part of the tool you use every day.
Agencies can now breeze through security audits with a consolidated list of core-supported features, while smaller teams get world-class protection without the complexity. Everybody wins. We like it when that happens.
Of course there's so much more to v6 than these big bucket features. We'll be unpacking all the rest of the new goodies with you in the new year.
This is what deliberate product work looks like to me. It’s not about shipping one big feature or hitting big marketing deadlines — it’s about aligning hundreds of decisions toward a clear, long-term direction.
This is why we took our time when we could have shipped earlier. Statamic 6 isn't about hitting a date — it was about hitting a standard. And we're ready for the next phase of our world domination plan. 😘
We now have the groundwork for faster iteration, more ambitious features, and a control panel that can grow without collapsing under its own weight.
Thanks for being part of the journey — I hope you're as excited and optimisic about 2026 as we all are here.
I hope you all have a very Merry Christmas and happy holidays! Slow down, spend time with the ones you love, and we'll see you in the new year.
]]>Along the good company, there were drinks, an abundance of pizza (sadly none with pineapple), and swag like stickers, and even some adorable Ploi.io elePHPants for people to take home.
Both Duncan and Joshua from the Core Team made the trip to hang out with everyone. Mostly attended by people from the Netherlands, the love for Statamic knows no borders so some folks from Germany, Belgium, and even a fella from Ireland were there. You love to see it. 🇳🇱🇩🇪🇧🇪🇮🇪
The evening kicked off with Roy from JustBetter, who gave a talk about Runway — one of Duncan’s creations and part of the Rad Pack addons. Runway lets you manage your Laravel Eloquent models directly inside Statamic’s Control Panel — no hassle, just seamless integration.
After a general overview of the addon itself, Roy also showed how they utilize it with Rapidez, a headless Magento integration for Laravel and Statamic.
Next up was Duncan McClean, who introduced Cargo, his completely overhauled e-commerce addon for Statamic. If you’ve ever used Simple Commerce before, you’ll know that the name "Simple" was a bit of an understatement — and Cargo is taking things to a whole new level. Up to eleven, one might say. It’s simple to use but powerful under the hood, and it’s currently in alpha, set to launch alongside Statamic 6.
To wrap things up, Joshua Blum demoed what’s coming in Statamic 6 — walking through changes, new features, and showing off a few things. If you're interested in what's new in Statamic 6, have a look at our sneak peek post. Since we published it, we've actually added a ton more stuff.
When the talks were wrapped up, the mingling began and pizza got delivered. After people made sure their bellies were full, folks gathered in a side room to show off some of the cool stuff they’ve been building with Statamic. It’s always awesome to see what the community is doing out in the wild.
All in all, it was a great evening full of learning, chatting, and meeting people you know from the internet IRL. Thanks again to everyone who attended and especially to JustBetter for hosting!
We’ve got more meetups in the works, and we might even be brewing plans for Flat Camp #3. 👀
If you’d like to host a Statamic meetup, we’d love to help. Reach out to us at [email protected]. We're happy to cover expenses for food and drinks (within reason of course), send some swag, and help promote your event. You can also find past and upcoming ones on our /events page.
Until next time — keep shippin' and stay awesome! 💜
]]>Ploi Cloud is the latest from the team behind Ploi.io — a developer-first cloud hosting platform. If you’re a fan of clean, fast, and intuitive tools (hello, Laravel Forge vibes), you’ll feel right at home.
First, it has the out-of-the-box goodness you'd expect from a first class solution:
Plus, live Laravel/Statamic commands are accessible directly in the UI—clear caches, manage the Stache, run cron jobs, and more.
Oh, and it's built especially for Europe. Data never leaves European soil — fully GDPR compliant and sovereignty guaranteed.
Statamic is known for smoothing the dev-to-production workflow — flat-file content, beautiful control panel, and flexible templating. Ploi Cloud matches that ethos, removing friction around hosting and deployment so you can focus on building.
Curious yet? Head to ploi.cloud/features/statamic and test the waters. From trial on day one to GDPR-certified production-grade hosting—it might just become your new favorite workflow.
Big thanks to the Ploi team for building something that feels like a natural home for Statamic in the cloud, with love and attention for our large European audience. We’re excited to see what you all create next!
]]>
We’ve rethought every interaction and redesigned every screen. The new interface is cleaner, faster, more modern, and more consistent — with just the right balance of polish and practicality, all without arbitrarily moving things around just because a fancy-pants designer wanted to change things up out of boredom. You'll feel right at home, your muscle memory will be intact, and your sense of pride in your work — now showcased in a sexy, modern UI — will glow.
Breadcrumbs now understand the context of where they are in the control panel. Quickly jump between collections when editing an entry, or the various utilities when you're managing your search indexes. Always know where you are in your content structure.
Want to see all your most recent entries at a glance? Switch any collection to card view and manage your content in a more spacious, scannable format.
Adjust thumbnail sizes to suit your workflow — zoom in for detail, or zoom out to scan at a glance.
Managing media just got easier. Drag existing files directly into subfolders — no extra clicks required. It works just like your OS desktop.
Sometimes you need to double-check who’s behind the keyboard — especially before making changes that affect security or critical settings. Elevated Sessions require password re-authentication before high-stakes actions, helping you (and your team) stay safe.
A faster way to work. Hit a keystroke and jump anywhere in the control panel or run common actions without lifting your hands from the keyboard. Inspired by modern dev tools, the command palette puts power at your fingertips.
2FA is now built into the core. No more addons, no workarounds — just simple, secure authentication that helps protect your content and users. We'd like to say a special thank you to the folks at Mity Digital who were kind enough to let us Sherlock their 2FA addon as a starting point for us to build off.
A cleaner, more readable syntax is here. Taken from our Blade components feature, these component tags make Antlers templates look more like native HTML, which can make your templates much easier to read and scan. If that's your thing.
<statamic:collection:blog limit="5"> <a href="{{ url }}">{{ title }}</a></statamic:collection:blog>
Now when you scaffold a collection's index and show views, it will automatically generate template code including all of your blueprint fields, saving you time and energy working that all out.
We’ve rebuilt timezone handling from the ground up. It’s more accurate, predictable, and makes scheduling and timestamps behave exactly the way you’d expect — across daylight saving shifts and global teams.
Our new Vue.js powered UI component library — Kitt — powers the entire control panel and is available for your use too. Built on Reka, it's flexible, consistent, and comes complete with documentation.
It's like our very own, custom ShadCN, perfectly tuned for the Statamic experience. We even have a Figma file if you need it.
<ui-button variant="primary" text="Make it so" /><ui-switch v-model="published" /><ui-badge color="purple" text="New" />
Statamic 6 is built on Vue 3 and Pinia — giving addon developers modern tools, better performance, and a more future-proof ecosystem.
We've rebuilt listings and publish components from scratch. They’re faster, more customizable, and easier to extend.
<ui-listing :items="[ { title: 'One', description: 'The first', }, { title: 'Two', description: 'The second', }, { title: 'Three', description: 'The third', }]" />
Addons can now create their own settings pages, allowing non-developers to configure addons directly in the control panel. Settings are stored in YAML files by default, but can be easily moved to the database if you prefer.
And this is only the tip of the iceberg. Just wait until you see the full changelog.
We’re wrapping up final details and preparing for release. Statamic 6 is a big step forward — not just in how the control panel looks and feels, but in how it will be able to grow for years to come.
If you want to see more and are going to be at Laracon, come visit our special booth (you won't miss it). We'd love to show it off.
We can't wait to get it into your hands. Except for the part where someone says they liked v5 better. Not looking forward to that inevitability.
]]>For the past few months Jay has been working on redesigning and rebuilding our docs (which are nearly done by the way), and we both enjoyed working together on it so much that we didn't want it to stop. And starting in March, it won't have to.
This is very exciting for me personally. As the only designer and the primary front-end developer in the company – I can't wait to be able to collaborate with another talented designer and take the Statamic UI and UX right to the bleeding edge.
Be sure to congratulate Jay in Discord – this is the beginning of an exciting new era for Statamic.
]]>You put the time in and now it's time to share your work with the world. Our new showcase section puts the spotlight on the impressive work our community creates. And for our Certified Partners, we've supercharged your profiles with proper project galleries. Time to let those screenshots and links do the talking.
We've added a Community Links page because, let's face it, some of you explain Statamic better than we do. It's a curated collection of articles, tutorials, and videos from the community. Got something to share? Send it our way and we'll make sure the world sees it.
We've done some housekeeping in the account section:
Our marketplace got much more than just a fresh coat of paint:
We've added Enterprise Pricing for when your Statamic needs get serious. Perfect for those times when someone in management asks "but can it scale?" or "Who can we call when we have an emergency?"
This redesign is just the beginning. We've laid the groundwork for some exciting features we've got cooking (no spoilers). The new Statamic.com is faster, smarter, and ready to grow alongside our community.
Take it for a spin and let us know what you think. After all, most of these improvements came from your feedback – turns out you all have pretty good ideas.
]]>By enabling this feature on an Assets Field, each entry will automatically create a new sub-folder to store its assets in. You can set it to use the Entry's slug, id, or author field to generate the folder name from.
Now, each blog post in your Collection will store its images and other assets (like PDFs) in an auto-generated folder named after the slug of your blog post. Let's say you're running a wedding photography website. You have a Galleries collection and your latest wedding is a new entry titled Kate and Johnny, which would (unless you edit it), use the slug would be kate-and-johnny.
Now, all the photos you upload into your Photos Assets field will be uploaded into /img/galleries/kate-and-johnny/. If you decide to add more later or deselect some, you don't have to browse through all of your potentially thousands of images to find the right ones, and the changes of uploading two IMG_7337.jpg files goes down to next to zero.
Instead of having your asset containers being unstructured and cluttered with all kinds of random files, they can now look like this:
This works flawlessly with Statamic's and Laravel's powerful adapter-based filesystem approach. Whether you store your assets locally on the server or use an object storage like AWS S3 or one of its many API-compatible alternatives, this will just work™.
If you're interested in the implementation details, head over to GitHub and the corresponding PR.
We are also tinkering with a brand new photography-centric Starter Kit that will utilize this feature. We think you're going to love it.
Like other features, this one was a community request that got submitted via our statamic/ideas repo. Is there a specific feature you wish were in Statamic? Feel free to open a feature request on the repository. Please make sure to search first to avoid duplicates.
Questions about this feature or anything else Statamic? Hop on our community Discord, and don't forget to subscribe to our newsletter to get updates right into your inbox.
]]>Before we dive into what's new, let’s take a step back. Starter Kits have been an essential tool for Statamic users for quite a while, either as public ones on our Marketplace or private ones to jump-start your freelance, agency, or whatever-project-you-re-working-on kind of projects. Whether you're setting up a blog, an e-commerce site, or a portfolio, Starter Kits provide a solid foundation. And now, with support for modules, that foundation has become even more flexible, powerful, and customizable.
If you've used Peak before, one of Statamic's most popular Starter Kits, you might be somewhat familiar with the idea already. Created by Rob de Kort, one of our certified Statamic Partners and a beloved community member, Peak took a DIY approach to what we now natively support: modules.
In simple terms, modules allow you to include other dependencies inside your Starter Kit. Imagine being able to offer a Starter Kit with multiple levels of complexity. You could have a basic version and then let users opt-in to additional features like an SEO module, a social image generator, or even different tastes of pre-built templates and views, for example. This makes Starter Kits not just a starting point but a launching pad for some rad Statamic experiences.
Interested in using modules with your Starter Kit? It's a breeze to implement them. Just nest your modules in your starter-kit.yaml config file, and you're good to go. The beauty of it? It ties in seamlessly with our CLI, giving users the choice to install modules or skip them. Want to offer different stacks or flavors? No biggie. You can set up options for going other routes. Want to offer support for React, Vue, or Svelte, all within the same Starter Kit, for example? Let the user pick their favorite stack when they install the Starter Kit via our CLI.
But wait, there's more! You can even nest modules inside other modules. It's like a Matryoshka doll of possibilities — nesting modules inside modules inside modules.
Here's a simple example of how to use nested modules:
modules: seo: prompt: 'Would you like some awesome SEO with that!?' dependencies: - statamic/seo-pro modules: sitemap: prompt: 'Would you like additional SEO sitemap features as well?' dependencies: - statamic/seo-pro-sitemap
For those who like to get even more fancy, modules pair well with our existing Post-Install Hooks. This means you can run additional logic or scripts right after your Starter Kit is installed, ensuring that everything is perfectly tailored to the user’s needs. Even better, post hooks will get a small update soon that let you run them conditionally for each module.
We’ve only scratched the surface of what’s possible with module support in Starter Kits. Whether you’re a seasoned Statamic developer or just getting started, this new feature will open up a new world of possibilities. Want to dive deeper? Check out our docs on creating a Starter Kit for all the details. And don’t forget to explore our Marketplace to see what’s already out there.
With modules, your Starter Kits are no longer just a starting point — they're the foundation of a fully customizable, powerful, and tailored Statamic experience. Time to get building!
Building some cool with Starter Kit modules or something else you're proud of? Having questions about anything Statamic? Hop on our Discord and also subscribe to our newsletter to not miss updates on your favorite Content Platform.
]]>In a nutshell, the Dictionary Fieldtype is like the Select Fieldtype's varsity-football-playing cousin. It lets users pick from a list of options that can be sourced from external locations – essentially a super flexible and extendable key-value store.
Unlike the regular Select Fieldtype, where you manually define each option in the field’s config (which, let’s be honest, can be a little cumbersome and repetitive with common data), the Dictionary Fieldtype allows you to pull in options from JSON, CSV, or YAML files, or even fetch them from external APIs. No more tedious configuration, just pure data straight from any source of your choosing.
The beauty of the Dictionary Fieldtype is in its flexibility. Want to pull data from a JSON file sitting in your project? Drop your file in the resources/dictionaries directory and let Statamic handle the rest.
Need to grab data from an external API? Create your own custom dictionary class. This means you can read data from whatever format you prefer or already have (without having to convert it), and apply custom logic, like authenticating with an API. If you can dream it, you can probably dictionary it.
The Dictionary field even comes pre-built with a few super-common dictionaries:
Working with dictionary data in your views is simple, regardless of whether you're using Antlers or Blade.
Let's see an example:
past_vacations: - USA - AUS - CAN - DEU - GBR
<ul> {{ past_vacations }} <li>{{ emoji }} {{ name }}</li> {{ /past_vacations }}</ul>
<ul> <li>🇺🇸 United States</li> <li>🇦🇺 Australia</li> <li>🇨🇦 Canada</li> <li>🇩🇪 Germany</li> <li>🇬🇧 United Kingdom</li></ul>
You can see that by using the built-in countries dictionary your data is augmented to include matching emojis.
Using Statamic headless with GraphQL? The Dictionary Fieldtype has got you covered here as well. It automatically supports GraphQL, so you can query the fields in your custom dictionaries easily.
Wondering how to get started with a custom dictionary? See our docs with a full working example to guide you through the process.
So there you have it, folks! The new Dictionary Fieldtype is here. Whether you’re looking to streamline your previous Select Fieldtypes, manipulate or fetch data on the fly, or play around with a fun new toy, this Fieldtype is a new tool in your tool belt. Head over to its docs for more details.
Feel free to share your feedback with us on Discord, and don't forget to subscribe to our newsletter to keep up on all things Statamic.
]]>Forget the auditorium. Flat Camp is all about forging connections, sharing ideas, and getting hands-on with the coolest crew around. It’s a conference, sure, but one where the focus is on people and our lovely community, not the slides on a screen. Let’s be honest, conference talks can still be watched on YouTube anyway. But meeting people and sharing an amazing experience together? Only possible IRL. 50 people from all over the world made their way to Italy to join us.
Imagine this: three nights in a private Italian villa nestled in the countryside just outside Rome. Sounds like a dream, doesn’t it? Well, that was our reality at Flat Camp this year. From the moment we arrived, it was clear this wasn’t just any conference — it was a full-blown experience.
Some of us arrived a bit early or stuck around after to soak in Rome’s sights, sounds, and (of course) tastes. Whether it was exploring ancient ruins like the Colosseum, indulging in pasta, or just wandering through cobblestone streets, Rome was the perfect backdrop for our community to connect and unwind.
Having the entire Core Team — Jack, Jason, Jesse, Joshua, Duncan, and Erin — on-site was awesome since we don't see each other in person often as a remote-first team. It’s one thing to chat on Discord, but getting the community together and having actual face time is way more valuable. The show'n'tell session was particularly cool, with everyone showcasing their latest projects and ideas. Here are a few highlights:
This year's Flat Camp was everything we hoped it would be and more. It was an opportunity to talk about Statamic's roadmap with the people who use it the most and also to strengthen the bonds within our community. We left Rome with full hearts, full bellies, and a ton of new ideas. If you couldn’t make it this year, don’t worry — we’re already looking forward to the next one. Where will we go? You’ll just have to wait and see!
A massive thank you to our sponsors as well — Ploi.io, Pingu Solutions, Codetopia, and Arcustech — for helping make this event possible and allow more people to come. You guys rock!
Check out the photo gallery to relive some of the best moments, and start planning for next year. Flat Camp is more than just a conference — it’s a community, a family, and one heck of a good time. See you at the next one!
Statamic 5 delivers performance improvements from several different angles without changing the way content is stored (there have been changes to the Stache, however).
Most of these changes focus on intelligent caching and reusing results (like tree items and URLs) during the request lifecycle. But we didn't stop there — Statamic 5 has a massive number of under-the-hood improvements to the flat-file query builder, how Globals are stored and retrieved from the Stache, and augmentation learned some new tricks on how to process data more efficiently — lazily even — only when you need it. And that's just scratching the surface.
You probably just care about the bottom line differences. I know I would in your position.
For small, simple sites you might not see much of a difference — maybe 5-10% faster.
But for huge or complicated sites with multiple navs and structures, taxonomies, globals, multi-sites, and so on — we've seen truly staggering improvements in our benchmarks. We've seen 50-600% speed increases. From multiple second render times to a few hundred milliseconds. Or less.
And for those large sites that are using the static site generator — you're going to see some great improvements there as well. Not only do faster request cycles mean faster generation, but we've lowered overall memory and temporary cache storage use as well by improving the garbage collection process.
Thanks to many of you who had slow sites that were willing to share your codebases so we could use them in our tests. They made all the difference.
Where v4 was heavily focused on the authoring/control panel experience, this v5 major release is similarly focused on improving the developer experience everywhere we can.
We've added new commands for installing our main first-party packages collaboration, eloquent-driver and ssg. These commands take advantage of Laravel Prompts to walk you through various optional configuration steps.
We all know there's no database involved when you're running a site with the flat-file Stache driver. But what if you could see what the equivalent SQL queries would be, if you were?
Enter Fake SQL Queries! Statamic can now emit events that push approximated SQL queries to your database debugging tools. These fake queries will show in the Debug Bar, Laravel Telescope, and even Ray by using the ray()->showQueries() helper.
You've asked, we've delivered. You can add, edit, and remove Sites right in the control panel without having to touch code.
This means non-technical — or otherwise control panel-only — users can translate your site, build out landing pages and micro-sites, all without the aid of a developer. Assuming your site is built to support such things. 😊
If you've ever found wangjangling your addons for testing was a bit of a pain, it's time to breathe a sigh of relief. When you php please make:addon we'll scaffold out a proper PHPUnit test suite for you.
Our modernization efforts bring Statamic's dependencies up to the latest two major versions of Laravel (9 and 10). We've dropped support for outdated versions of PHP and updated, refactored, and removed a number of third-party dependencies and build tools to keep Statamic's core up to modern standards.
Statamic 5 supports Laravel 11, which was released in mid-March. We've gone beyond mere support, however, and have also added support for Laravel Reverb, integrated Laravel Prompts into our CLI,
In order to offer the latest and greatest features, as well as tightest security, we have dropped support for older and unsupported versions of Laravel and PHP.
Every new major version of Statamic will support the newest two versions of Laravel and whatever versions of PHP it supports. You can keep track of those versions at LaravelVersions.com.
For sites running on Laravel 10 — upgrading should be as easy as setting your composer constraint for statamic/cms to ^5.0 and running composer update. However, be sure to check the Upgrade Guide for any breaking changes that may affect your site.
For sites running Laravel 9 or older, you'll need up Upgrade Laravel before upgrading Statamic. Which brings me to...
If you need to upgrade Laravel, you have three options.
content, resources, and users directories over, along with anything custom in your app and any modifications to the config/statamic files.We're proud of all the changes and improvements in Statamic 5 and are eager for you to try it out and share your feedback with us. We especially want to hear about your speed improvements!
Check out the full changelog here to see every last little change.
Statamic v3 will continue to receive security fixes until July 2024, at which time it will reach end of life and receive no further updates.
The upgrade path from Statamic 3 to 5 is very straight-forward — these major versions are not codebase rewrites nor do they have major architecture changes. In short, there's no reason to put off updating to Statamic 5 and getting the very best performance, control panel, and developer experience we have to offer.
For more in-depth details on supported Laravel and PHP versions as well as support dates have a look at our release schedule.
We've also been hard at work bringing you a much improved statamic.com experience — with special detail focused on the Marketplace and Account area. Stay tuned for more news.
We'll soon be at our second Flat Camp in Italy, where we will be collaborating with the community on what's most important to focus on over the next year, 5 years, and beyond.
Follow us on Twitter, subscribe to our newsletter, or simply stand on a street corner and tell everyone you know about Statamic. Thanks!
]]>As this was the People's Choice awards, I just want to say thank you to our, as they put it, "tenacious" community. We love you.

If you're interested, you can learn more about how Statamic works as a Static Site Generator.
]]>Duncan, who hails from Glasgow, Scotland 🏴 , has been a big part of the Statamic community for quite a few years now. If you missed meeting him at Flat Camp earlier this year or don't recognize his name, you might recognize his work. He built Simple Commerce, Runway, Guest Entries, and Cookie Notice, just to name a few.
Recently he's been working for Steadfast Collective, one of our partner agencies, building and managing some of their client Statamic sites and building custom addons.
Check out some additional Duncan-related links:
Please wish him well as he dives into working on Statamic directly starting next Monday, October 2nd. We can tell great things are ahead.
]]>Imagine we had a template similar to the following example:
<div class="hidden xl:block bg-gray-200 p-4"> <nav> <ul class="flex space-x-4"> {{ nav:main }} <li> <a href="{{ url }}" class="text-gray-700 hover:text-gray-900"> {{ title }} </a> </li> {{ /nav:main }} </ul> </nav></div> <div class="xl:hidden bg-gray-100 p-2"> <button id="menuToggle" class="mb-2">Toggle Menu</button> <div id="mobileMenu" class="hidden flex flex-col space-y-2"> <nav> <ul class="flex space-x-4"> {{ nav:main }} <li> <a href="{{ url }}" class="text-gray-700 hover:text-gray-900"> {{ title }} </a> </li> {{ /nav:main }} </ul> </nav> </div></div>
We are achieving our goal of utilizing the same HTML markup. Still, we are duplicating the Antlers template that produces the shared markup. We can extract the common parts to a partial to clean this up.
In resources/views/_nav.antlers.html:
Have you seen template names with a leading underscore and wondered what that was about? This is a naming convention that helps to differentiate regular templates or layouts from partials. When using the Template Fieldtype, files we name using this convention are hidden by default (as well as any file within the views/partials folder).
<nav> <ul class="flex space-x-4"> {{ nav:main }} <li> <a href="{{ url }}" class="text-gray-700 hover:text-gray-900"> {{ title }} </a> </li> {{ /nav:main }} </ul></nav>
With our new partial, our template can now become:
<div class="hidden xl:block bg-gray-200 p-4"> {{ partial:nav /}}</div> <div class="xl:hidden bg-gray-100 p-2"> <button id="menuToggle" class="mb-2">Toggle Menu</button> <div id="mobileMenu" class="hidden flex flex-col space-y-2"> {{ partial:nav /}} </div></div>
Fantastic! We've cleaned up our template significantly by extracting a partial. However, what if our partial contained some complex logic that took significant time to complete? We are now rendering that partial twice!
We can solve this by assigning the results of the partial tag to a custom variable and using our new variable instead:
{{ _nav = {partial:nav} /}} <div class="hidden xl:block bg-gray-200 p-4"> {{ _nav }}</div> <div class="xl:hidden bg-gray-100 p-2"> <button id="menuToggle" class="mb-2">Toggle Menu</button> <div id="mobileMenu" class="hidden flex flex-col space-y-2"> {{ _nav }} </div></div>
An important thing to note — When working with tags and custom variables is that we need to wrap our entire tag call within a set of single curly braces. Without this, Antlers will treat everything as standard variables and modifiers, which can lead to unexpected behavior and errors.
]]>Multi-site Permissions, our highest-voted feature request is finally here! Multi-site is useful in many different ways, from building site networks, multi-lingual versions of sites, and running extra subdomains.
This Feature Request was no small task and took a Herculean effort on Jesse's part to bring it to the finish line. We're adding a few more tests and it'll be in Core before you know it. 🎸
Did you catch Jess Archer doing her thing at Laracon US? In case you missed it, she introduced the super tremendous new Laravel Prompts feature. We were so hyped up, Jason straight-up sprinted to get a PR out with support for it.
Watch her talk to see it in action.
For those who love a good show and tell, Jack’s video shows it in action.
Oh and here's a bonus treat – you will bask in the Prompt glory even outside of our CLI (like when running php please do-something) if you’re running Statamic in a Laravel 10+ app since it just extends those commands with Prompts and uses them by default.
Our Static Site Generator package has leveled up and is flexing hard with its new pagination support. Big ups to Jesse (man's on fire!) for diving deep and crafting out the intricate details.
The update brings finer control on site generation with new options for generating individual URLs, as well as a --disable-clear option to save time and potential headaches. If you've got your sights on edge hosting with Netlify, Vercel, or similar — this package will be your new security blanket.
Head over to the release notes and read the details. 📚
And last, but certainly not least, is the pumped-up Markdown Fieldtype. From description lists to task lists (and everything in between), this update is all about bringing more control and markup potential to your content. Need more details? Just take a gander at theis PR or our docs on the Markdown Fieldtype.
Plus, with added support for custom Markdown extensions you get even more possibilities, it’s all in the extend docs for Markdown.
]]>It's specifically aimed at organizations building large networks of sites using Statamic as part of their own SaaS stack or large volumes of client sites. Consider it Statamic as a Service.
Statamic Platform starts at a flat $7 per-month per-site. No up-front or renewal fees.
More details, exact pricing, and the sign-up are all on our specific landing page about Platform Pricing.
This Platform pricing model isn't designed for everyone — we will continue to support single Site Licenses as always, as well as volume discounts through our Master License.
If you have any questions at all, our support team is more than happy to answer them. Go forth and build something awesome!
]]>When Nature Played the Opening Act
Living in Germany, I've seen storms, but never a heavy-hitter like the one Nashville served up on Tuesday. The downpour and thunderstorm meant flights got delayed and even canceled. Jason, Jesse, and a bunch of others felt Mother Nature's wrath. Some even missed part of the conference because of it. In Nashville they say It ain’t the heat, it's the humidity and it's true. This can't be explained but can only be felt, especially in July.
Despite this tempestuous start, we cozied up and shared a spacious Airbnb just a hop away from the venue.
Music City Madness
Nashville's bar scene is as vibrant as a fresh coat of paint on a barn. Honky Tonkin’ on Broadway, the Laracon After Dark party at Tin Roof, and of course, the ubiquitous country music – it's like being in a never-ending encore.
For a German, the culinary scene was a bucket list moment (lol). Between Hattie B’s hot chicken that set my soul (and mouth) on fire, southern BBQ goodness, Shake Shack burgers, and Chick-Fil-A, I was in food heaven. And the sweet tea! I have learned from my mistake at Flat Camp and went with the unsweetened one.
Tuesday evening we went to the 16-bit Bar and Arcade enjoying some fine beverages while playing all kinds of arcades, bowling, and Mega Jenga (I made the tower fall over 😅). We were also on a mission to make Vim fill up the entire leaderboard on one of the arcades. Jesse approved of this with great joy.
"Laracon in Nashville was RAD... Awesome talks, cool tech, great music, amazing food, and absolutely wonderful people! I’m thankful for such a kind and encouraging community, even if only 1.2% of them use Vim!"
— Jesse Leite
"Had a great time at Laracon this year. It was great to see everyone again after so long. The talks were inspiring, the people were friendly, and the chicken was hot. Especially looking forward to using Laravel's new Prompts feature!"
— Jason Varga
Conference Highlights
The scheduled talks were hand-picked and very well-balanced. From inspirational talks to demos of new and existing projects, there was something for everyone.
Jason, Jesse, and I liked the Laravel Prompts talk from Jess Archer the most since we just love and live in the terminal.
Kudos to Jason for being quick on the draw — he's already working on bringing the feature to our CLI (check out the progress here).
The introduction of Livewire v3 by Caleb Porzio as well as the State of Laravel keynote by Taylor Otwell with the announcements of Herd, Folio, Volt, and more, were also among our highlights.
Laravel Herd will make it even easier for new folks to give Laravel and Statamic a try by simplifying the setup on their machines. We'll bring you some more content on this in the near future. Check out all of the conference talks right here.
And Vince, you legend! He whipped up an addon while at the conference, mostly during the break between the talks. What a guy!
Also, we had an epic Statamic meetup on Thursday evening at the Urban Cowboy in east Nashville. Cocktails, whiskey, bourbon, and wood-fire pizza! Christian, you da MVP for that recommendation!
Jesse got out of this trip what he wanted for a long time: A picture with the mysterious Mr. Ninja.
In Closing
Laracon US 2023 was more than a conference. It was a rendezvous of minds and a celebration of Laravel and Statamic (shoutout to all the Statamic Partners and community members that were there).
Already strumming my guitar and looking forward to the next Laracons, and of course, Flatcamp EU. Till then, keep the code clean and the BBQ messy!
]]>It's like having Sammy Davis Jr. and Frank Sinatra working on your web project - they're part of the show, but they're playing their own tunes. The Rad Pack focuses on crafting "second-party" Addons, bridging the gap between the Statamic core and third-party packages. These packages are third-party rockstars, but with a twist: they're backed up by first-party support, as reliable as Dean Martin's croon.
And we're not here to drop a one-hit wonder and then leave. These Addons are built, documented, and fine-tuned to the same standards as our core, with a commitment to regular maintenance. They won't end up like forgotten B-sides.
We believe that every artist in our group deserves their fair share of the spotlight, and that includes getting compensated for their gig. We're dedicating a part of our GitHub Sponsorships to keep the Statamic Rad Pack juiced up and ready to roll.
And here's where the chorus comes in: we want you to join in our jam session. Whether you're interested in joining the Rad Pack with your existing Addon or have an idea for a new one, we're all ears. It's all about the harmony of the community, after all. Have another idea or suggestions? Let us know!
The first act to hit the Rad Pack stage is Erin Dalzell's Mailchimp Addon. Erin wanted to take a bit of a backstage role for this addon, and we decided to step in to keep the Mailchimp integration grooving smoothly.
What Addons or Starter Kits are we looking for?
We prefer original scores. That doesn't mean remixes or mashups are not allowed.
This example from the README is a good way to illustrate it:
A Mailchimp integration is a great Rad Pack Addon because lots of people use Mailchimp, but nowhere near 80%. Therefore, it would not be a good candidate for a Core Feature as it just doesn't make sense to ship updates to Statamic just to make a Mailchimp fix.
As long as it adds value and makes the user experience simpler, it's okay to make the Addon a wrapper around another package or an external API.
Also, keep in mind that the goal is not to make money. All packages that are part of the Rad Pack are free. That's why we dedicate a share of our GitHub Sponsorships to the people involved.
To keep the show organized, we've set up our very own dressing room, a GitHub organization under the name statamic-rad-pack. Check it out, see what we're up to, and maybe join us for the encore. Head over to the organization on GitHub: Statamic Rad Pack on GitHub. More details can be found in its README.
So, buckle up and get ready for the ride, folks. With the Rad Pack, we're looking to make some sweet music, contribute to the Statamic ecosystem, and have a blast doing it. It's gonna be one helluva show! 🎸
If you want to join, have suggestions, or have any other questions, reach out to us on Twitter or Discord.
]]>Flat Camp was no ordinary tech conference, as we tend to buck the norms with most things we do. We said sayonara to formal talks and lectures, in favor of a a non-formal, relaxed, and hands-on gathering. A cozy, mountainside retreat in the stunning Blue Ridge Mountains of North Carolina. Seven cabins tucked away amidst breathtaking views and the quiet whisper of nature. We wanted it to feel like summer camp for grown-ups. – only this time, we traded ghost stories for tech-talk and cabin raids for scotch and bourbon tastings. As one does.
If you prefer photos to words, jump right into our photo gallery. And if you're more of a moving-picture person, relive some of the magic with our little recap video:
44 people from all corners of the globe descended on our mountain retreat. A few locals arrived by car, while the rest were shuttled in from the airport, hailing from Canada, Ireland, England, Scotland, Poland, Portugal, Germany, Saudi Arabia, and even all the way from Australia (g'day Marty and Michael 🦘). All uniting under the hot-pink flag of Statamic. We swapped stories, shared experiences, and lost a drone (and found it after a most-memorable recovery mission).
Activities? The days were brimming with fun and friendly shenanigans. Hiking adventures through the rugged mountain trails, heart-to-heart chats by the campfires enjoying some sweet S'mores, exercising in the early morning, relaxing in hot tubs, and indulging in the age-old tradition of Street Fighter II on the SNES.
One evening, we held a trivia quiz about Statamic and our history. It was a safe space.
Flat Camp was also a celebration of the senses. We had a hearty sip of culture with whiskey and bourbon tastings, and dove nose-first into a wine-tasting session from a nearby vineyard. So nearby we could literally see the vineyard from the balcony of the main cabin as we sipped.
And not to forget, the Camp Store – a treasure trove of exclusive and rad swag which you could snag with Camp Bucks, our custom, non-legal tender only accepted at Flat Camp. Skateboards, Yetis, whiskey glasses, t-shirts, posters, mouse/desk pads, and more.
Of course, it wasn't all play and no work. We did shine a light on how the future of Statamic can be shaped to serve us all. We talked business (lots of agency owners and freelancers were there) and web development in general. A Q&A session with the core team got everyone in the know and provided some really valuable feedback to us for the roadmap of Statamic. One morning was dedicated to community presentations where people showed what they've built with or for Statamic, inspiring us all. Like Andrew Welch demoing Spin Up Statamic, an easy way to quickly create a working Statamic instance with Docker and GitHub Codespaces. Super cool to show Statamic to a potential client and provide a demo that they can interact and play around with.
Now, an event like this doesn’t just materialize out of thin air. It was also made possible by our amazing sponsors:
A big, heartfelt "Thank You" to each of you. You’ve truly helped make Flat Camp a memorable experience.
We believe the first Flat Camp was a great success, and it's in great parts thanks to this fantastic community. It wasn’t just about code and Statamic; it was about connecting, sharing, learning, and forging relationships that go beyond the (mechanical) keyboard. That's the beauty of such an event.
<img src="/img/blog/flat-camp-group-shot.jpg" ="Group shot of Flat Camp attendees taken with a drone">
Flat Camp is here to stay. This is part of our future, and we’re already dreaming and scheming about the next Flat Camp. Next stop? Europe! That's right, Flat Camp is coming to you, dear European friends on the other side of the Atlantic. The where and when are still in the works, so be sure to sign up for our newsletter to stay in the loop. Ideas or suggestions for possible locations? Hit us up on Twitter or Discord (there's a #flat-camp channel).
Here's to the fantastic memories made, friendships forged, and drones found.
See you next year 👋
Until then, stay rad!
The changes in Statamic 4 focus on two main categories: User Experience (UX) and continued modernization.
The UX updates are the culmination of a thousand little enhancements all throughout the control panel. From re-imagined fieldtypes, UI components, and improved colors and icons, to new batch actions and filtering behaviors — it's more intuitive, more consistent, more accessible, and simply more beautiful to look at.
Our modernization efforts bring Statamic's dependencies up to the latest two major versions of Laravel (9 and 10). We've dropped support for outdated versions of PHP and updated, refactored, and removed a number of third-party dependencies and build tools to keep Statamic's core up to modern standards.
Oh and if you'd prefer to watch a video on all the new v4 goodies, we have that for you right here.
Statamic 1, 2, and 3 were each fundamental and architectural rewrites, and as such are essentially separate products with migration paths between them. However, going forward, Statamic 4 will just become "Statamic". It is the same architecture as version 3 (a composer package with Laravel as a framework dependency) and we plan to keep it that way.
No more big migration effects when a major release is dropped. Just keep using the latest version Statamic just like you use the latest version of Chrome, Firefox, or whatever your browser of choice is.
CSS's new Container Queries feature have allowed us to make fieldtypes and components much more adaptable to the the size of their container, rather than the browser viewport.
Let's look at an example how this plays out. The Assets Fieldtype can now adjust its UI to remove less critical elements like file size, the "Alt Text" button, and help text while inside small spaces like a Grid field, Asset Editor, a narrow Live Preview pane, on mobile devices, and so on.
We used to have to write JavaScript watchers and dynamically add or remove classes to do this kind of styling, and because of the overhead and potential performance degradation from too many watchers — we tended to avoid doing it unless it was absolutely critical.
We've made Container Query-powered improvements to nearly every fieldtype and component in the Control Panel. If you spot anything that looks janky in small spaces please let us know so we can continue to improve the UI.
Tabs and Sections are a new way to help organize your Blueprints and publish forms. Statamic 3's concept of "Sections" are now Tabs, and Sections are just that — visually distinct sections (some may call them "cards") in the form.
This will help you group your fields with headers and instructions much like you could do with the (admittedly now slightly confusingly named) Section fieldtype, but better in every way.
We've also added the option to hide the display label for any given field, which can help streamline Sections with a single field and/or reduce duplicate labels and instructions.
Bard and Replicator Set Pickers can now be organized into groups (using the same Tab and Section GUI that Blueprints gained) and assigned icons. We've preloaded the interface with over 150 new icons hand-picked for common "content block" types.
We greatly improved the looks and behavior of lists and data tables. Where there was overflow before, the checkbox and action columns now stay in view all the time. Other improvements are the dedicated status column, the title and content wrapping to a maximum of two lines, and other small adjustments.
Filters in v3's table views could be a little clunky, not to mention they took up more space than necessary. So we completely redesigned them. They're now more intuitive, not to mention responsive. They look and work great on mobile and other smaller screen devices.
In addition to the facelift, we also wired up filters in the Users area.
We updated and redesigned our Color fieldtype to offer a better and more simplified UX. Defining swatches with predefined colors is now a simple and smooth experience instead of a clunky off-road adventure.
The list field also got its own facelift along with a more intuitive and consistent experience in line with our other 40+ fieldtypes. Reordering and removing items is now clearer than before, and keyboard support is also greatly improved.
The improved Time fieldtype is better in every possible way.
It allows for natural keyboard entry and automatically formats itself without having to tab and use the up/down arrows. Just type the time. If you happen to enter invalid times (e.g. 27:21).
What might appear as a small addition to our family of built-in fieldtypes at first may just be a mighty one for the right project.
You can now use your favorite icon sets from the Control Panel, or define the path to the directory and/or folder of your own that contains SVG icons. It has a very minimal UI which will help streamline your Blueprints and help authors build pages faster with less clicks.
The Width Fieldtype was part of Statamic for quite some time but it has now been exposed to the Blueprint builder and its UI has been scaled up to match other fieldtypes. It's a perfect option to use on utility fields that may control the width of a content area or media element.
The asset editor now has — you guessed it — a more elegant and streamlined UI with a clearer structure, updated icons, and other small improvements and refinements.
Bard and Markdown have had Fullscreen Modes, but they aren't the only "big" fieldtypes in our arsenal. So we enhanced Table, Grid, and Replicator with their own Fullscreen Modes.
Sometimes you just need more space to work with, and now you have it.
We've been huge fans of Tailwind since its inception. Statamic 3 had previously been running on Tailwind v1, but this major version update gives us the breaking change opportunity we needed to upgrade to Tailwind 3 and use a more standardized config. This should come as a blessing to anyone with Tailwind experience who wants to build addons for the Control Panel.
But we only have your attention for so long. Here's a quick punch list of a few other things that have been improved in Statamic 4.
Laravel transitioned to yearly releases along with Laravel 8. Going forward from Statamic 4, our major releases will follow behind Laravel's, meaning a there will be a new "major" version of Statamic every year.
Our goal is to trail behind Laravel's major version by a month or two to harden our code and offer you the most seamless experience possible when upgrading.
Laravel 10 was released in mid-February, and Statamic 4 has full support.
We will now be using the more traditional semantic versioning so we can ship new features when they're ready 🚢 without having to wait to assemble enough features to justify a "major" version (like 3.1, 3.2, etc) for marketing purposes. This allows us to steadily improve the platform and introduce breaking changes only when necessary at the annual major version window.
In order to offer the latest and greatest features, as well as tightest security, we have dropped support for older and unsupported versions of Laravel and PHP.
PHP 7.4 was released in 2019 and official support for it ended back in November of 2022. If you're still running PHP 7.x on your server, it's time to upgrade to PHP 8.
Going forward, every new major version of Statamic will support the newest two versions of Laravel and whatever versions of PHP it supports. You can keep track of those versions at LaravelVersions.com
It feels like it was yesterday, but we released Statamic v2 more than seven years ago. It's time. Statamic 2 has reached end of life. If you still need to move a site off v2, be sure to check out the Official Migrator Package.
Statamic v3 is closing in fast on its third anniversary and will continue to receive critical bug fixes until January 2024 and security fixes until January 2025. That should give you enough time to prepare an upgrade in the coming months (or years even).
For more in-depth details on supported Laravel and PHP versions as well as support dates have a look at our release schedule.
Accelerated Mobile Pages, or AMP, was (or still somewhat is) Google's framework to "improve the loading times on the web". AMP pages got a preferential rank in their search algorithm for a few years, but that stopped in June 2021.
Since then, a majority of CMS, platforms, and publications removed support for it. Statamic 4 also takes this stance and removed support for AMP.
Upgrading from v3 is free as long as you're inside your support & updates window. You're never required to keep an active update subscription, you can wait as long as you'd like before purchasing another year (or more). Your Statamic site is yours and will continue to run indefinitely as long as your server supports the appropriate version of PHP.
We are no longer discounting upgrades from Statamic v2 or earlier.
For most sites — as long as you're running Laravel 9 or 10 — upgrading should be as easy as setting your composer constraint for statamic/cms to ^4.0 and running composer update. However, be sure to check the Upgrade Guide as there are breaking changes that will affect some sites.
If you need to upgrade Laravel, you have three options.
content, resources, and users directories over, along with anything custom in your app and any modifications to the config/statamic files.We're proud of all the changes and improvements in Statamic 4 and are eager for you to try it out and share your feedback with us.
We'll soon be at our very first Flat Camp where we will be collaborating with the community on what's most important to focus on over the next year, 5 years, and beyond.
You can also take a look at our Roadmap and share your ideas and feature requests over on GitHub in the statamic/ideas repo.
Be sure to follow us on Twitter, subscribe to our newsletter, and tell your grandmother you love her, if you're lucky enough to still have her.
]]>CMS Critic has been awarding the best CMS since 2012 which is, coincidentally, the same year Statamic 1.0 got released.
This year's awards "had record participation from around the globe for both the nominations and final voting" which makes us feel even more honored.
Stay on your feet!👏We’re celebrating @statamic as the winner of the #CMS Critic People’s Choice Award for “Best Flat File CMS!” https://t.co/cJ68j5q84Q pic.twitter.com/cCuS4gPjQw
— CMS Critic (@cmscritic) March 2, 2023
In last year's Critic's Choice Awards, they praised Statamic's flexibility and the highly customizable content editing experience, amongst other things.
What really stands out for us is the flexibility of Statamic's headless Content REST API, which can deliver content from Statamic to your frontend, external apps, and other endpoints. It's also a Git-integrated platform, meaning users can directly manage their version control workflow and automatically commit, schedule, and push content from a simple control panel.
Another milestone: We also reached 2,5k stars on GitHub last week 🌟
We want to say Thank You to everyone who voted for us or starred our repo on GitHub.
]]>3.4 also sets the new Runtime Antlers Parser as the default. Let's wave farewell to our old friend Regex Parser — he who so faithfully carried the burdens of parsing our tags and variables — as he sails off into the sunset.
3.4 is packed full of improvements and enhancements across the entire application, but we'll cover the big ones here in this blog post. To explore all the smaller, more nitty gritty details, check out the Release Notes. Grab a fresh cup of coffee, there's a lot.
If you've ever thought to yourself "Gee, I'd love to move this Articles collection to the top level of the nav and hide the Collections area entirely for my editors", you're in luck.
You can now rearrange and customize the side nav all day and all night long. You can add your own links, remove links and sections, and have different navs for different User Roles or Users.
You get to this area from a new link in the Global Header.
This screenshot leads us to the next big feature in 3.4...
The Control Panel now has the ability to edit all of your relevant preferences — settings stored on the User or Role level. Now you can easily set the Locale used to translate the Control Panel, set your Start Page, edit your Favorites, and have them each be unique to a user or Role.
Addons can tap into Preferences and add fields, allowing a whole new level of customization into the Control Panel experience.
TipTap, which powers the Bard fieldtype, has been upgraded to version 2. This was a significant update (thanks for being a huge help, Spiegel) and enables a lot of new addon and extension possibilities, as well as bringing a number of features into core that needed to be addons in TipTap 1 (e.g. Text Alignment, Character Limit, Smart Typography).
Most people might not really notice a difference as everything works the same as before, but we promise that cool things are coming with this update.
Bard now has an inline/minimal UI mode, which allows it to be more easily dropped into Grids, Replicators, and other tight spaces. Thanks to Jack Sleight for this PR!
You can now configure preset transformation rules to run on all uploaded images, which provides the solution to the age old "how to I stop my client from uploading 20mb JPGs" problem. Hurray! 🎉
There shouldn't be any breaking changes for most users — though if you were relying on a few bug behaviors (namely with custom content queries on multi-sites), be sure to view the upgrade guide to see how to make the appropriate improvements and adjustments.
Check out the Release Notes to see the full list of enhancements and fixes in 3.4, and take a peek at the the roadmap to see what's coming next!
]]>But enough time goes on and you know not enough people know the addon exists or they don't realize how well integrated it is, and it's just a shame.
We reached that point with Duncan McClean's Duplicator addon. For the last 2 years it has allowed you to easily duplicate entries, terms, assets, and forms. And thanks to Duncan's generosity, it has just been integrated into core. The stew is served.
We tweaked it a little bit, removed some of the config in favor of some smart and thoughtful defaults, and have let it loose in Statamic 3.3.59. We hope you enjoy it!
And if you have a minute, it would be awesome if you can spare a minute of your time to thank Duncan on Twitter for all the work he's put in maintaining this feature. 👏
]]>In this series — in addition to learning the Statamic basics — we'll get into building add-ons, starter kits, and even pop the hood and explore just how all the flat file Statamic Magic works.
This course features 3 hours of brand new content across 22 episodes, and even covers how to get Statamic running on a MySQL database in less than 5 minutes. The first 17 videos are free while the last 5 (the "Tasty Extras") require a Laracasts subscription (money well spent even if this course wasn't on there).
I hope you find it informative and entertaining!
]]>And of course, a lot more. Jonas is no stranger to scaling Statamic sites — having been a part of highly respected agency before joining Spiegel and helping to run the largest Statamic site on the planet.
I'm probably going to take this course myself, there's always something new to learn.
So go check it out! It's 59€, which I'm sure is a steal for that level of expertise. He also has a bunch of free Statamic tutorials as well, so be sure to check them out.
]]>Quite a few updates have been released in the past weeks. Besides the general bug fixes and improvements™, we want to highlight two new features today that we think you'll like.
The first feature, replace assets, is targeted at users of the Control Panel while the second one, post-install hooks, is targeted at creators of Starter Kits.
Did you ever upload an asset just to see you selected the wrong file? We simplified the workflow for this so you can now replace the asset in place. Statamic can even take care of deleting the old file if you want.
Oh, you also see a "Set Alt" button now when an image doesn't have an alt text yet. How neat is that?
Are you creating Starter Kits? We got a nifty new feature for you!
You can now use post-install hooks and run commands when a user installs your starter kit via the CLI. Get user input on questions like:
Do you want to enable rad feature xy?Do you want to support this project by giving it a star on GitHub?One of the most popular starter kits, Peak, already makes use of this.
Jesse even headed into the land of Windows to bring you this feature. What a brave bearded man. According to him, it was 4/5 of the work. So let's be thankful and honor his sacrifice.
Want to create your own Starter Kit? Have a look at our docs on it.
We also shipped additional things in the past few weeks, like default preferences (in preparation for the upcoming customization capabilities for the Control Panel's navigation, the new cookie tag, and other new features and improvements to existing tags and fieldtypes.

September 8th marked the inaugural Statamic Berlin meetup 🎉
Hosted by prepend in a coworking space in Kreuzberg, we saw three talks:
You can watch the recordings on YouTube.
Our very own Joshua also attended the event as our field reporter and did some live coverage on Twitter.
If you want to attend the upcoming events make sure to join the group on meetup.com.
You probably already knew that we have a monthly newsletter, didn't you?
Well, you can now access past issues of our newsletter in the archive.
The newsletter includes some exclusive content that you won't find elsewhere. Like a collection of new site launches, community links (like blog posts, videos, tutorials), and more.
Head to the archive, check out some of the older issues, and, while you're already at it, subscribe to it if you like.
Our repo on @github recently crossed 2,000 stars! 🥳🌟
— Statamic (@statamic) September 12, 2022
Thanks to every single one who starred it or supports us in any other way! 🙏
Head to the repo, click that little ⭐ button, and spread the love if you haven't done so already ❤️https://t.co/JFDKodjvqH pic.twitter.com/WxgekRUEZD
That's a huge milestone!
We just want to say thank you to everyone who supports us 🙏
We got two new partners that joined our program in the past few weeks.
So if you're looking for an agency or a freelancer to help you with your project, make sure to have a look at our full list of partners.
Got anything you want to share with us, like an idea or something you built? Hit our Discord or send an email to [email protected].
Interested in what we're working on next? Have a look at our not so secret roadmap 👀
]]>Raycast, think macOS' Spotlight on steroids, has been gaining in popularity quite a bit in the past few months. Earlier this year, an extension for searching the Laravel docs was released. Now, there is also an extension for searching the Statamic docs via Raycast, courtesy of André Breia from Steadfast Collective, one of our certified partner agencies.
Give the extension a try and you are even closer to searching your favorite documentation ❤️
Using Visual Studio Code as your editor of choice? The Antlers Toolbox from John Koster gets updated quite frequently. The most recent version not only introduced support for newly added tags and modifiers, like user_roles and user_groups but now also warns you on dynamic CSS class names.
Make your templating with Antlers a breeze and install it right from the Visual Studio Marketplace.
Preferring PHP Storm over VS Code? Try out the Antlers language support plugin for it.
Not a fan of either PHP Storm or VS Code? Even Neovim now supports Antlers thanks to our very own Jesse and his contribution on GitHub.
A recent thread on the /r/webdev subreddit popped up asking "How is this website so fast?". The site in question was Laravel News.
Last year's relaunch of Laravel News included a switch to Statamic and was also mentioned in our blog. They make heavy use of our static caching feature and also wrote a summary of why they chose Statamic.
Steadfast Collective is striking again! Duncan McClean, developer at Steadfast and one of our community heroes, released a GitHub Action that formats and lints your Antlers templates for you. Under the hood, it uses the Antlers Toolbox mentioned above. Using the Action in your project will make sure that all your templates will follow a consistent style. Even if you work on a project with multiple people, everything will be clean and tidy.
Not familiar with GitHub Actions yet? Have a look at their docs on it. It's an awesome feature that enables you to automate all the things™!
We got four new partners that joined our program in the past few weeks with one of them getting the certified status ✅.
So if you're looking for an agency or a freelancer to help you with your project, make sure to have a look at all of our partners.
Got anything you want to share with us, like an idea or something you built? Hit our Discord or send an email to [email protected].
Interested in what we're working on? Have a look at our not so secret roadmap 👀
]]>With this change you will now able to see usage stats on repositories, proper syntax highlighting on Antlers files (.antlers.html) and use highlighting in code blocks you create on issues, discussions, READMEs, and everywhere else on GitHub. It also works on Gists which is super handy for sharing code snippets or saving them privately for later reuse.
All your Antlers files and templates now have proper syntax highlighting. If you want to check it out in action, take a peek at a file like this one.

Repo stats are only updated after pushes to the main branch of your repository, so if you don't see Antlers in your project sidebar, make any commit + push. When you're done, it should look something like this:
To indicate Antlers syntax in any Markdown code blocks on GitHub — such as creating an issue, opening a discussion, or inside a README, you'll need to put your code between three backticks and append "antlers" after the opening set of ticks. This also works with "blade", "php" and anything else supported in GitHub Linguist.

Searching for Antlers files globally on GitHub will follow once this PR is merged. Apparently this part of GitHub's workflow is managed by an entirely separate team and they're not quite in sync. 🤷♂️
Huge thanks to Jonathon Koster for his work on the Antlers Language Server for VS Code which made this whole thing possible. ❤️
And finally, while we're on the subject of Antlers — if you're using Visual Studio Code or PHP Storm, check out Antlers Toolbox for VS Code and Antlers Language Support for PHP Storm. Both are packed with features to maximize your Antlers experience in their respective editors.
]]>I honestly couldn't be happier with the journey. Working on a product like this with a community like ours means I get to spend most of my time helping people build more successful companies.
Sure, it might be a bit indirect, but I have the honor turning feedback into action, which helps agencies and freelancers build better websites for their clients more efficiently and effectively.
Which means those people can (hopefully) spend more time on things that truly matter in this world (spoiler: they aren't the internet).
I want to say thank you to so many people and instead of being all cliché and saying "but there's no time", I took the time.
Here we go. Deep breath.
🙏 Thank you to Jason and Jesse, my inner circle. You're so much more than developers. You're the magic makers. Statamic would probably still be running on SlimPHP and jQuery if it weren't for you. I look forward to waking up every morning to build this thing with you guys.
🙏 Thank you to Erin Dalzell for being a relentless helpful ally in Discord, and for not being afraid to point people to the docs. Thank you for help with support and many PRs, practical ideas, and personal experience in many areas.
🙏 Thank you to Joshua Blum for your fresh and helpful energy you've brought to the team and community.
🙏 Thank you to André Basse, Jonas Sieweertsen, Wiebke Vogel, and the rest of the team at Spiegel for championing and supporting us in countless ways.
🙏 Thank you to John Koster for the wizardry you do behind the scenes – for the new Antler Parser, Antlers Toolbox, performance tuning, and the forthcoming secret lab projects ⚗️.
🙏 Thank you to Stefano Kowalke for building the PHP Storm package for Antlers.
🙏 Thank you to James Blair for being our biggest financial supporter — I don't know how you do it but we sure do appreciate it.
🙏 Thank you to Jack Sleight for becoming the community Bard expert, whether you knew it or not. You've been more helpful than you know.
🙏 Thank you to Rob de Kort for Peak and the awesome little community around the kit. And for everything else you do in the community.
🙏 Thank you to Ben Furfie, Duncan McClean, Greg Colker, Jelle Roorda, Michael Aerni, Rias Van der Veken, Ross Wintle, Ryan Mitchell, Rob de Kort and so many others for being heroes in the community, for having (nearly) limitless patience helping out new people, teaching them to learn, and debugging problems.
🙏 Thank you to Jonas Siewertsen for putting so much love and attention into your Statamic Tutorials.
🙏 Thank you to Steven Grant for building and running the Work with Statamic job board.
🙏 Thank you to Arthur Perton for the incredible amount of PRs you've submitted to fix our silly (or not so silly) mistakes.
🙏 Thank you to the team at visuellverstehen for organizing and running Statameet out of the kindness of your hearts. I can't wait to do it again.
🙏 Thank you to all of our Partners – for all the hours on our video calls, collaborating on ideas, talking through feature requests and bugs, for all the honest feedback and priceless insight into using Statamic in the wild.
🙏 Thank you to David Lindahl and Simon Hamp for your help with the community newsletter and attention to detail making sure no links went unnoticed.
🙏 Thank you to Justin Jackson for all the shoutouts and livestreams on Twitter. You've helped many people discover Statamic.
🙏 Thank you to Alexander Stoffel, Jay George, Duncan McClean, Yoeri Boven, Rob de Kort, Jack Sleight, Ben Furfie, Rias, Maciek Palmowski, Andy Griffiths, Steven Grant and so many others for writing, streaming, and screencasting about Statamic.
🙏 Thank you to Emmanuel Beauchamps, Daniel Kaufmann, Joachim Rütter, Tom Helmer, Jaime Smeke, Peter Matkovsky,
Joshua Siagian, Davide Bellini, Brad Zunnur, Håvard, Rob de Kort, Rias,
Damian Chojnacki, Vitor Pinho, Bugo, Gal Jakič, Andréas Lundgren, Jeffrey Q, BinotaLIU, Espen Grimsgaard, Marcel Weidum, Andrew Jelley, Jan Östlund, Roy van Veldhuizen, César A. Ramírezand Samuel De Backer for translating to and maintaining Statamic in more than a dozen languages.
🙏 Thank you to all the addon and starter kit developers — there's so many of you now! I get excited everytime I see something new hit the marketplace.
🙏 Thank you to Taylor Otwell for Laravel, we never could have done this without the best PHP framework in history. 🏎
🙏 Thank you to Mubs, Fred, Gareth, and Jaggy for all being important parts of the team over the last decade.
🙏 And thank you to all the open source package developers out there we rely on – I've done my best to sponsor you all on GitHub to express my gratitude. It's the least I could do.
And finally, to everyone else who deserves a thank you that I missed here – I'm positive I'm forgetting at least this many names again. Please accept my deepest gratitude and apology for missing your name here. I hope I remember you and update this post before you read it. 😅
Okay, that's all I got. My brain is mush tracking everyone down all over the internet.
Joshua is a full stack developer from Cologne, Germany with lots of experience with our beloved SALT stack (Statamic, Alpine, Laravel, Tailwind). He'll be jumping into customer support, building and improving our learning content, encouraging and empowering the community, and helping to grow Statamic awareness across the weird wide web.
With his help (and timezone) — we're able to extend the hours we can provide support, which will go a long way in serving our rapidly-growing European community.
I'm really excited to have his help, ideas, contagious energy, and fluency of the German language on the team.
Check out some Joshua-related links:
Follow and congratulate him on Twitter or Discord – he's here to help!
]]>3.3 includes a brand new Antlers engine packed with powerful new features, streamlined Blade interoperability and tag/modifier helpers, dynamic conditional form fields, new query builder methods, and whole lot more. Feel the excitement and energy by watching this announcement video!
3.3 is packed full of improvements and enhancements across the entire application, but we'll cover the big ones here in this blog post. To explore all the smaller, more nitty gritty details, check out the Release Notes. Grab a fresh cup of coffee, there's a lot.
The new Antlers Engine is a complete and fundamental rewrite that takes a more sophisticated and elegant approach to the business of parsing templates.
The original parser was — essentially — a glorified find and replace machine relying heavily on RegEx. It parsed and evaluated logic as it worked its way in one direction through the template, from top to bottom. This means it couldn't stop, go backwards, set variables, or in many cases handle nested logic well because something deeper or further down couldn't stop logic already begun. It also had performance issues as templates got larger. The more characters you push through RegEx, the more processing power it took to process.
The New Antlers Engine now has two stages – first, it parses and builds an Abstract Syntax Tree (AST) from your templates, and then it evaluates and executes the nodes and logic in the tree during runtime (much like a programming language) according to established rules.
This affords Statamic an incredible amount of control. It can go sideways and slantways and longways and backways and squareways and frontways and any other ways that you can think of. Code at the bottom of a template inside several nested tags can bubble up and be available at the top, or in a called partial, and so on.
In turn, this allowed us to build dozens of new features, fix all known Parser-related bugs, and support syntax scenarios that were impossible in the previous "parse and evaluate" flow. Features like...
next and previous loop traversal helpersThis new engine is a powerful factory, mad scientist laboratory, and wizarding school all rolled into one. 🏭🧑🔬🧙♀️
Because of how fundamental Antlers is to the entire Statamic experience, we're shipping this new version under an opt-in feature flag until Statamic 3.4 — just in case it affects the behavior or output of one or more of your templates in an unexpected way.
We recommend starting new sites with the new "runtime" engine, but highly suggest testing it for existing sites before just shipping it to production.
Explore all the new Antlers goodies.
Blade finally gets the attention it has always deserved. And ->value() is obsolete. 🎉
Statamic now injects a $page variable into your Blade views — an Entry class with magic property access. You no longer have to "resolve" your variables with the ->value() method, you can interact with them in a standard object fashion.
<h1>{{ $title }}</h1> <div class="grid md:grid-cols-3 gap-3"> @foreach($page->images as $img) <img src="{{ $img->url }}" alt="{{ $img->alt }}"/> @endforeach</div>
If a variable is a query builder (e.g. entries or terms), you can manipulate them with property access:
@foreach ($page->related_posts as $post) {{ $post->title }}@endforeach
Or with the method approach, which has the added benefit of supporting method chaining:
@foreach ($page->related_posts()->where('title', 'like', '%awesome%')->get() as $post) {{ $post->title }}@endforeach
You can now tap into Statamic's Tags with the new Statamic::tag() helper.
@foreach (Statamic::tag('collection:blog')->limit(10) as $entry)...@endforeach
In the a similar fashion, you can tap into Statamic's Modifiers with the new Statamic::modify() helper.
{!! Statamic::modify('hello wild')->slugify()->upper() !!}HELLO-WILD
Your frontend forms can now automatically tap into conditions (like "show when", "hide when", "show unless", and so on) as configured in the control panel. The logic is handled with JavaScript and 3.3. ships with an Alpine.js driver to do it all for you.
If you you're using a different JavaScript framework you can write your own JS Driver.
Live Preview got an upgrade and is now configurable to work with headless sites using GraphQL. You can define your Live Preview URL and handle rendering the page in your frontend framework of choice.
This update also allows you to set your own Live Preview targets so you can view how a change to your entry affects the show page, listing page, or any other page you feel is important.
Statamic 3.3 adds support for Laravel 9 and drops support for Laravel 7. Supporting multiple Laravel versions becomes a big challenge when each version has a different supported PHP version range. It is our position that it is better to stay up to date and progressively drop backwards support for out of date and end-of-life PHP versions than it is to hold the product and ecosystem back trying to avoid the need for server updates.
Everyone is better off running of the the latest, stable, supported version of PHP and Laravel. We wrote about this up and coming changes a few months ago, and you can review the whole major release schedule here.
However, we didn't want to force anyone to have to jump too far on short notice, so we spent the month of February to bridge the gap between PHP 7.4 and 8.1, Laravel 8 and 9, and all of their respective dependencies.
In short:
If you installed Statamic before October 5th, 2020 and have not upgraded the underlying version of Laravel, you're most likely running Laravel 7 and will need to make a few extra manual steps as part of the 3.3 update.
There are a few breaking changes in 3.3 — all for very good reasons, so be sure to view the upgrade guide to see if they affect you (hint: they probably don't).
Check out the Release Notes to see the full list of enhancements and fixes in 3.3, and take a peek at the the roadmap to see what's coming next!
]]>This information is out of date. For the latest official information, please check out our Release Schedule & Support Policy page in the docs.
As a modern PHP application, and even more-so as a Laravel package, it's important to keep Statamic's codebase up-to-date and have a roadmap extending out as far as we can reasonably plan to decide how and when to handle inevitable breaking changes to the greater ecosystem.
Statamic is a developer-centric platform. We don't want to encourage bad practices or hold our community back from using new, modern coding practices and tools.
Today we're announcing our new release schedule that accounts for all of these factors. Going forward you will be able to plan ahead for keeping your sites and servers secure and up-to-date. Since you're here for the details, here they are – followed by the thoughts and implications behind them.
| Statamic | Laravel | PHP | Release | Bug Fixes Until | Security Fixes Until |
|---|---|---|---|---|---|
| 3.2 | 7 — 8 | 7.2 — 8.0 | Aug 2021 | Mar 2022 | Mar 2023 |
| 3.3 | 8 — 9 | 7.4 — 8.1 | Mar 2022 | Mar 2023 | Mar 2024 |
| 3.4 | 8 — 9 | 7.4 — 8.1 | Jan 2023 | Jan 2024 | Jan 2025 |
| 4.0 | 9 — 10 | 8.0 — 8.1 | Mar 2023 | Mar 2024 | Mar 2025 |
| 5.0 | 9 — 11 | 8.0 — 8.1 | Feb 2024 | Feb 2025 | Feb 2026 |
Dates subject to change based on factors outside of our control.
The first and most significant change is starting next year we will be going to an annual major release trailing Laravel's by a month, and supporting the same PHP versions as Laravel.
These major releases are not going to be huge feature-packed marketing extravaganzas, but rather "maintenance" releases focused on upstream dependencies (Laravel, Symfony, Flysystem, Glide) and boring (but necessary) language-level updates.
Over the last 10 years we've put an extraordinary effort into making Statamic work on older, outdated versions of PHP and the latest and greatest. We did this because we didn't want to "create" more work for our users. However, the result of this position, over enough time, is a codebase that begins to feel like Stretch Armstrong, destined for a big ol' painful tear at some point in the future.

We'd like to avoid that hypothetical event. And we'd like to encourage — push even, our community to do right by their clients and own projects and keep them up to date. If these businesses are worth running, they're worth running on secure servers with modern code. We never want Statamic to start feeling like WordPress.
Going forward, we'll be moving away from the notion of "Statamic 3" vs "Statamic X" entirely and focus on building and maintaining "Statamic".
There will not be any additional cost to upgrade to Statamic 4, 5, and so on. Just like how it works currently, a site license of Statamic can be used indefinitely for a single site and includes 1 year of updates. When your update period expires, you can continue to use Statamic as long as you'd like. If you want to get the updates, you can renew for another year (or more).
At the moment updates cost $59/year. This may be subject to change in the future, but we have no plans to do so at this time.
If you follow our current release patterns, you know we regularly ship small features and enhancements in "patch" releases (e.g. the x in 3.2.x). We don't like the idea of hoarding them to launch bigger "dot" releases for marketing purposes or anything like that. Once a feature is ready, there's always someone who can use it — or let's be honest, who has been waiting a while for it. Ship it.
After we release Statamic 4.0 next February, we'll start following semantic versioning more closely, bumping those minor numbers every time we ship something that isn't a bug fix. Expect to see version numbers like 4.35.3 much more often than 4.3.35.
Our plan is for at least one release per week, with additional releases as needed. If there's a feature or enhancement in that release, it will be a minor number increase, otherwise a patch.
Here are some of the major dependencies of Statamic along with known events in their respective release schedules. We've taken all of these things into consideration with our schedule.
See the full Laravel Release Schedule.
See the full PHP Release Schedule.
At this time we have no plans to upgrade from Vue 2 to Vue 3. There is nothing Vue 3 can do that we haven't already solved with Vue 2, and the effort represented in the upgrade for little-to-no actionable gain makes the whole idea silly compared to other ways we can spend our time.
There are many other smaller components and dependencies, like Flysystem, TipTap, Glide, and more. Each of these packages has their own requirements, and using the latest of any often requires the latest version of something else, which requires the latest version of another thing...
In short – it usually pays to get onto the latest versions and not fall behind. We'll be taking the opportunity for an annual breaking change to eliminate unnecessary, dated, or poorly supported packages.
On this new schedule, we'll be able to back-port important bug and security fixes to previous versions for a time, which should give you more time in case you need to put off major updates longer.
Statamic 2 will be officially retired and will receive no further updates in February, 2023 – coinciding with the release of Statamic 4.
We truly feel that transparency is one of the most important things we can offer the community, and hope that this schedule helps in more ways than one. Stay tuned for Statamic 3.3!
]]>The original docs were designed and built during the beta period of the Statamic 3 development, and ran on an early version of the beta itself. Since then there have been many updates to the content, but it wasn't until now that we took the time to take a few steps back and determine what was working, what wasn't, and identify gaps in the content.
Everything was under evaluation. The design, organization, architecture, URL structure, each and every letter, and most — but not all — punctuation marks.
I also brought in Dave and Colin from Scruples (some of our awesome Statamic partners) to drive some outside thinking and design ideas. They were immensely helpful for helping me see things from a new perspective, and most of their awesome design work made it in.
Here's a fairly summary of what changed as part of this overhaul:
I hope they help! We're only getting started.
]]>Back in January when the plans began, Jonas (and the rest of world) had hoped the COVID-19 situation would be in the rearview mirror by September. Since you're a human on this planet along with the rest of us, you know that isn't yet the case, especially when it comes to crossing borders.
So while we're all hoping that day will come soon and we do more things like travel the world, meet in person, and do full-blown conferences, Jonas decided the best thing to do is make this mini-conference online-only. And once an event goes online-only, the world becomes the audience.
So, next month — on September 16th — you can join in and be a part of the first real Statamic mini-conference. There are 6 coordinated talks covering 5 different angles of Statamic development — kickstarting new projects, better debugging, building addons, deploying, and performance optimization. The final of the 6 talks will be me talking about the future of Statamic.
You can checkout all the details, the schedule, and see who all the speakers are on statameet.com. Tickets are €19, and the money goes to covering the cost of the software needed to run an online conference, which isn't cheap.
If you or someone you know can't afford to attend but would like to, please let me know, I'm happy to sponsor some folks and a few other Statamic Partners have said they would do the same. Don't let cost be an issue!
Hopefully we'll see you (or more like — you'll see us) there!
]]>Here are all the big ones. The rest of the smaller ones can be found in the Release Notes).
By far — and we really mean by far — the most requested feature since version 3 is the ability to customize the fields available on Navigations.
You now have full control over your Navs with Blueprints. Go ahead and add asset fields to control an icon, extra text fields to add descriptions under links, toggle fields to control fancy logic things, select boxes to control Tailwind classes — hopefully you get the idea. Flex it as far as you'd like. It can take it.
Custom fields in your navs will indicate if you're overriding a field on an entry and give you the option to keep it in "sync", or to stomp over it locally with another value. At any time you can snap it back in sync.
Furthermore (or "more further" if you prefer poorerly written English), we've improved some of the UI/UX of the Navigation section. Each "node" in a nav tree is now referred to as an "item" instead of a "link" in the UI so it feels more natural to add items that don't have links. This is useful for making top level sections with child pages that aren't links themselves. You could always do this functionally, but before it felt like you were abusing the feature. Now we (and the UI) encourage you to do it.
If you thought we were done making Navs better, you were mistaken. Nav Trees are now collapsable, making it much easier to work with large ones. It will also remember the state each user leaves any given nav in using localStorage. It doesn't alter any long-term preferences or files that require version control, so it's perfectly seamless.

Prior to v3.2, when you renamed an Asset or Taxonomy (like a Tag or Category) in the Control Panel, it wouldn't update any references to it throughout your content.
Now it does. It's automatic and works magnificently. This explanation doesn't require any further words, but it was so much work it feels like there should be more. Oh well. Enjoy it!
We launched Statamic 3.0 a year ago with the notion of "Starter Kits". We wanted to have a way to kickstart a new Statamic project with prebuilt functionality and/or design, and to make it easy as possible.
Initially we thought they could tap into Laravel Frontend Presets, but after experimenting with the file structure, they were incredibly frustrating and time consuming to build. Laravel even abandoned them in 8.0, so we feel justified there.
After tinkering around with other ideas, we went with the simplest thing we could think of – using alternate starter repos that import the core Statamic application – (statamic/cms on Github).
It was pretty simple to fork the empty site repo and build a new site with it. But we neglected to think about how much of a pain it was to keep them updated. Since each Starter Kit was its own fully-functional application that had dependencies on Statamic, Laravel, and various npm packages, everything quickly got out of date. Blind-merging automated PRs is never a great idea, and so everything slowly fell away from cutting edge, even though all we really cared about were frontend resources (HTML, CSS, JS) and some config stuff (Blueprints, Asset containers, etc).
So we did a bunch of hard work up front to make everything easy going forward. We worked out the most ideal workflow we could imagine and then built custom tools around it. We're super happy with it. Honestly, I think it might be the single most important feature for Statamic's future.
Starter Kits can be anything from a developer boilerplate designed to make setting up new sites quicker, to a full app-in-a-box. To show you what we mean, we built Podcaster, an end-to-end podcast-hosting solution. Seriously, it does everything except mix and master your mp3s and tell you to stop saying "um" and "uh".
New Starter Kit packages contain only the files relevant to the kit itself, and not a full Statamic/Laravel instance. Our Import/Export cli tools allow you to maintain only those relevant files without having to worry Statamic, Laravel, or npm version dependencies.
Installing a Starter Kit is done with a single command, using either the Statamic CLI or starter-kit:install Please command inside a new Statamic project.
For example, to install a free kit like Cool Writings, run one of the following commands:
statamic new site-name statamic/starter-kit-cool-writingsphp please starter-kit:install statamic/starter-kit-cool-writings
If you previously installed
statamic/cli, make sure to update to the newest version withcomposer global update statamic/cli.
For paid kits, like Podcaster, it works exactly the same, except you'll be prompted to purchase a license and paste the key in as part of the install process. License keys for paid starter kits, just like addons, are intended for use in one project. When you install a commercial/paid kit, that key is permanently bound the site you're building. This allows you install it multiple times if you need access to updates, but reminds developers that new licenses are needed for new projects.
If you're building a Starter Kit, the new starter-kit:export command copies all files & directories you deem necessary for the kit to run into a new location (usually something like ../starter-kit-super-cool-name). This is the directory that becomes the kit, proper.
All you need to do is push these files to a Github repo and list it on the Statamic Marketplace. If your dev site (the one you use to export the kit files) ever falls too far out of date, or you want to start from a newer (or even older) version of Statamic or Laravel for testing purposes, create a new Statamic project and import your own Starter Kit and you're good to go.
We have a whole new section in the docs that get into more detail, so if this excites you either as a creator or a consumer, go check it out! We'll be doing a new guide and screencast series on building Starter Kits, as well as hopefully releasing a bunch of useful and fun kits over the coming months.
To support all this new goodness, we just opened up the Starter Kit area of the Marketplace Marketplace that supports free and paid Starter Kits. Check it out — we hope to see this area flourish over the coming months!
On that note – the more Github sponsors we get the more free kits (and addons) we'll be able to build and release. I would love to team up with some freelance designers and developers to work on this this effort – so please reach out if you're interested!
The goodies don't stop there. We gave our addon generators some much needed attention. Now addons and extensions are ready to go immediately, no more copy and pasting or stumbling through the docs to wire up boilerplate code.
# Generate a new Fieldtype, Tag, and Widget (for the win)php please make:addon -ftw
If your addon needs JavaScript in the control panel, it now creates your npm, webpack, and other necessary .js files, and injects the proper class and component names into them. All you need to do is cd addons/your-addon && npm install && npm run watch and you're cooking with fire. And with fire I mean JavaScript that actually compiles and does something, which is basically the same thing.
And that's not all. Packages now update your ServiceProvider, generate a README file that gives you a jumpstart on writing documentation, and last and probably least — a good starter .gitignore file. If there's anything the generator can't do, it'll give you some instructions or link to the proper docs in the console output.
We hope this makes it significantly easier to get those ideas out there and into the community.
You'll also notice a bunch of small UI improvements throughout the control panel, mostly with fieldtypes, tables, and SVGs. Enjoy!
That's all we have for now. If you're wondering what's next for Statamic, check out the roadmap! We're still tinkering with it, but there are some updates there for ya.
]]>3.2-beta.1. We're super happy with it but there's a really awesome new feature we want you try before we release it all into the wild. Backwards compatibility and ease-of-updating is important to us and we don't want to have to change the way it works right away if we missed an important aspect (or worse, broke something).
3.2 adds the single most requested feature of all time – the ability to add extra fields on Navigations. A small thing you say? Sure, maybe in terms of UI, but it required a whole lot of planning and architecting and edge-case testing to build it properly.
You see, a Nav can add items that are text only (like a section header), or a hyperlink to anywhere, or (here's the big one) an entry relationship. If you pull in a reference to an entry, what happens if you add a field with the same name to the Nav Blueprint? There are so many ways that could be handled.
I'll tell you exactly what it does. It will indicate that you're overriding a field and will give you the option to keep it in "sync" with the entry, or to stomp over it locally with another value. At any time you can snap it back in sync.
It's this feature we want you to try before we ship it. We want it to solve our problems as well as feel natural and intuitive, so we want to see if you can figure it all out without any documentation.
If you've been waiting for this, now's your time to provide feedback. Don't delay, there's nothing else holding this release back except happy developers.
Share that feedback here: https://github.com/statamic/cms/issues
Make the following changes to your composer.json file:
minimum-stability to "dev" or "beta""statamic/cms" to "3.2.*"// composer.json "minimum-stability": "beta","require": { "statamic/cms": "3.2.*", // all that other stuff...},
Then run: composer update statamic/cms --with-all-dependencies.
In a few days or so we'll slap the 3.2.0 tag on there and give you the full, glorious details on everything that's included.
]]>3.1 is packed with new features and enhancements, big and small. Let's run through some of the best stuff.
GraphQL is the single, largest, most game-changing feature in 3.1. GraphQL is a super-modern query language that provides a powerful and standardized syntax for requesting data from your application — in this case, Statamic. It allows you to define exactly what data you want, and makes it very simple to aggregate data from multiple sources (in our case — collections, taxonomies, users, and so on).
It is primary the engine behind the Jamstack approach to building website frontends.
GraphQL is another tool in the headless toolbox, sitting right beside the Content API. You can now easily build your frontend as a single page application (SPA), or with Gatsby.js, Next.js, Nuxt.js, and other, similar bleeding-edge JavaScript frameworks.
Jason built a few prototypes using a few of these approaches so you can see how everything fits together.
You can also use the "out of the box" Gatsby Source GraphQL Plugin to use Statamic as your headless backend for Gatsby.js sites.
We also integrated GraphiQL into the Control Panel to give you a user-friendly way to interact with the data and build your queries.

White Labeling allows you to customize the logo, visible name, and basic theme of the CMS throughout the control panel. The primary purpose of white labeling is to customize a control panel instance for a client, not to resell Statamic as a separate product. Keep that in mind, because it's an important part of our terms.

Update scripts allow Statamic and addon developers to make changes to data, settings, templates, and other necessary things after updates are performed. It may seem like a small thing, but it opens up huge possibilities in the future and should allow us to avoid breaking/manual changes down the road.
3.1 introduces new author permissions that can prevent users from editing or deleting other author's entries. These permissions are additive, which means that the existing 3.0.x behavior has been pushed into new permissions that must be "checked". The aforementioned Update Scripts will perform this update for you automatically.
You'll need to have an author field defined on your blueprint to take advantage of "unchecking" these new permissions.
The Content API now has caching controls and new Nav and Collection Structure Tree endpoints. As requested. 👏
We significantly improved our Amazon S3 filesystem integration. Benchmarks and tests on real customer sites have shown speed improvements around 8-15x faster. You'll love it.
We've also shipped a whole bunch of smaller, scattered improvements throughout 3.1. From Control Panel UI tweaks and new options and settings for various to a big old bag of bug fixes, you'll fine little things everywhere that might make you happy.
First, check out the release notes to see every little thing we squeezed into this big release.
Next, take a quick look at the Upgrade Guide for 3.1. These changes should all be automated thanks to the new Update Scripts, but if due to an unforeseen circumstance they don't fire, we've written a guide on how to do the upgrade yourself if absolutely necessary.
We hope these new features open up some brand new possibilities for you and your projects. We would also love to hear your thoughts — so as always, please send us some email!
]]>Plausible by Visuellverstehen adds a link to the sidebar of the control panel to easily navigate to your Plausible Analytics site.
Fathom by Michael Aerni adds a link to the sidebar of the control panel to easily navigate to your Fathom site.
Plausible Analytics by Jack Whiting pulls your analytics right into the dashboard.
YumYum from Duncan McClean (aka Double Three Digital) lets you import entries and taxonomies from RSS and JSON feeds. It costs $29 and will easily save you 10x that much in time saved alone.
Table on Steroids for v3 by Goellner is a fieldtype that lets you paste CSV data right into a table. It's super slick and costs a mere $10.
Bard Text Color by Mosteanu Bogdan-Mihai is a little free addon for Bard that lets you change text color.
Dynamic Cache from the prolific Michael Aerni gives dynamic super powers to fully static caching allowing you to use forms, sort="random" and other super useful things without losing the benefits of that full caching mode.
Events by Transform Studios allows you to create a calendar of events or list the next few upcoming events. This also includes the ability to create recurring events, which is pretty awesome.
]]>Eric Barnes just posted a write-up on the site about why they chose Statamic as their new CMS. It's a great, honest read. Check it out! Here's a short excerpt in case you don't feel like clicking.
With v3, you can install [Statamic] with any Laravel app, which meant I could keep a lot of the existing secondary code that runs Laravel News. These are things like the links section, the automated daily newsletter, the account management, etc. Knowing I could keep all that and gain a new control panel to write and publish posts was a big win.
Another advantage is Statamic allows you to mix and match with a database and flat files. We already had users in a table, but we had a weird mismatch with our old system where we had article authors in two systems, our user's table, and a WordPress site. I was manually syncing those to keep authors matched, and it made allowing guest posting quite tricky.
The article dives into how they combine static caching with one line of Alpine.js to load fresh data without having to clear a thing. Very slick. Totally stealing this approach.
]]>Jay George has been writing a whole "Setting up Statamic v3 on MacOS" blog series. Here are his January posts. It's more blog posts than we usually write in a year. 👏
Statameet is a recently announced Statamic meetup/mini-conference planned for September in northern Germany. If the pandemic situation is in a better place, the hope is for this to be an in-person event. Statameet is being organized by Jonas Siewertsen from Visuellverstehen.
Aggregate Assets by Giovanni Buffa aggregates CSS and JavaScript files into a single file for better loading performance. This seems most useful for developers who don't use a Mix, Webpack, or similar build system.
Stack by Joe Tannenbaum provides stack tags — similar to Blade stack directives — to Antlers templates.
HelpScout Beacon by Mike Martin makes it easy to provide support to your Statamic clients with HelpScout, right inside the Control Panel. A very clever idea.
Instagram User Feed by Pixney allows you to fetch an Instagram feed and stories without OAuth. This uses a scraping approach and is inherently at risk of not working at any given time if Instagram changes their markup, so I'd recommend only using it in non-critical uses. I've totally done this before and it's so much easier than the OAuth approach that I think it's worth the "risk".
Twitter by Pixney displays your Twitter feed using the Twitter v1.1 API.
Thumbnails by Flame generates social media thumbnail images on the fly based on the title of an entry. How neat is that? I think it's pretty neat.
UUID by Aryeh Raber auto-generates UUIDs for empty fields. This is useful if you need unique, persistent IDs for each row in a Replicator, for example.
Live Search by Jonas Siewertsen is a Laravel Livewire powered Live Search component. It's a powerful way to skip Algolia entirely.
]]>This preview release will not be shown in the control panel updater to prevent over-eager folks from accidentally upgrading.
Make the following changes to your composer.json file:
minimum-stability to "dev" or "alpha""statamic/cms" to "3.1.*"// composer.json "minimum-stability": "alpha","require": { "statamic/cms": "3.1.*", // all the other stuff...},
Then run: composer update statamic/cms --with-all-dependencies
After updating you should notice:
pre-update-cmd section has been added to composer.json.roles.yaml will be updated (if you had any edit, publish, or delete entry permissions).If you want to experiment with and provide feedback on any of the new major features, here are some summaries and tips for you. Enjoy!
GraphQL is a query language for APIs that has become a commonplace in the Jamstack and frontend developer communities. It provides a way to get all the data you want in a single request, with nothing you don't want. Tools like Gatsby.js take advantage of GraphQL to power their static site generators.

To help with testing:
White Labeling allows you to customize the logo, visible name, and basic theme of the CMS throughout the control panel.
To help with testing:
"business" theme, etc and let us know of any issues or want to be able to customize anything else globally in a similar fashion.Update scripts allow Statamic and addons to make changes to data, settings, templates, and other necessary things after updates are performed.
To help with testing:
3.1 introduces new author permissions that can prevent users from editing or deleting other author's entries. These permissions are additive, which means that the existing 3.0.x behavior has been pushed into new permissions that must be "checked". The aforementioned Update Scripts will perform this update for you automatically.
To help with testing:
author to your entries and see if things are appropriately restrictedThe Content API now has (much needed) caching controls. GraphQL has the same, equivalent caching controls too, just FYI.
To help with testing:
You can now fetch Nav and Structure data from the Content API.
To help with testing:
The Statamic 3 Screencast Guide - while not technically from the community, you probably still won't want to miss our new, official screencast series on learning the ins-and-outs of Statamic 3.
Peculiar Pointer by Sorta Rad replaces your boring default OS mouse pointer with much more interesting – and possibly peculiar — ones.
Ghostwriter by Sorta Rad makes it easier to create animated text and typewriter effects with typed.js.
Needledrop by Sorta Rad helps you quickly add hover sound effects to your sites. The web is too quiet, let's make it noisy again.
Snippet by Kolaente is a modifier to create a text snippet out of any given string. It's pretty similar to the core truncate modifier, but there's always room for variations on a theme, right?
Runway by wunderkind Duncan McClean helps you manage Laravel Eloqquen models in the Control Panel and output them in your Antlers template. How cool is that? Oh yeah, and it's free.
WordPress Users by Arthur Perton imports WordPress users into Statamic so you preserve their original passwords. This is a super smart way to smooth out the transition between platforms! At $19/site it seems like a deal to us.
Quick Brown Fox by Sorta Rad helps you build your own font showcases with Google Fonts. Like all of their addons so far, it's completely free.
TinyMCE Fieldtype by Mity Digital adds and integrates the TinyMCE 5 cloud editor as an available fieldtype.
]]>Here's a look at some of the best November had to offer. There were some great things in October too, so we're fudging the dates. Don't look too closely.
Building Websites with the CMS for Laravel – Statamic! This livestream by by Norfolk Developers is nearly 4 hours long and covers a wide range of aspects of Statamic development, including configuring git repos, servers, and deployments.
The Statamic 3 Screencast Guide - while not technically from the community, you probably still won't want to miss our new, official screencast series on learning the ins-and-outs of Statamic 3.
Aardvark SEO for Statamic 3 — Candor just launched Aardvark SEO for Statamic 3 yesterday. It supports multisite, JSON Schema, breadcrumbs, and more. Read about all the new features here.
Meerkat by John Koster is here (though in beta) for those who want comments on your site. This is the only native comments solution for Statamic that we're aware of, so keep it in box your of tricks!
Silhouette by Pattern lets you sprinkle user data into static sites. How cool is that?
Redirect by Rias allows you to redirect legacy URLs to keep that SEO juice.
Forma by Erin Dalzell is a nice little utility package for other addon developers to help them make config pages much easier. We might need to merge this into core in the near future. 🤔
Zipper by Michael Aerni lets you zip up assets on the fly — pretty useful for e-commerce or resource sites. Ziiiiiip.
SortaRad has been building things that are basically just for fun. And we love that. For a good time, check out lol and facepalm, while extraextra pulls in the latest Statamic news to your control panel. Rad.
Ripe is a really simple e-commerce Starter Kit from Mike Riethmuller and Mike Martin. It's really, really slick! I might even buy it myself. As of right now, it's on sale.
Peak by Rob De Kort is not technically brand new, we've never featured it before and it's getting pretty popular. It's an opinionated and robust Starter Kit that has quite a lot of features baked right in. Check it out and see if you like the approach!
Statamic Docs Workflow for Alfred by Briant Gillespie is a neat little way to quickly jump into the docs from — you guessed it — Alfred.
Gatsby Source Statamic is a Gatsby plugin that allows you to pull data from the Statamic Content API into a Gatsby site
Today we're kicking off something fun! Anyone who writes a blog post, records a screencast, or livestreams about Statamic during the month of October 2020 will receive a coupon code for 10% off a Statamic Pro license and be entered into a drawing for a free license and epic swag package.
Additionally, the top 5 links will be tweeted and added into our next email newsletter.
Create some fresh, original content, email your link to [email protected], and we'll reply once with your coupon code, and a second time if you win the swagtastic bundle of radical majesty! If you've already written content earlier in the month, that counts too. No worries.
Your content must be original, fresh (act like we might check archive.org to make sure you're not recycling anything old), and focused on Statamic 3. Blog posts must be at least 500 words and videos at least 3 minutes long.

Here some example headlines if you need some ideas:
See you out in the blogosphere!
]]>Confession: I used up most of my best words redesigning and rewriting the site you're looking at right now, but I managed to save a few for this post and this very moment.
I am full of pride. Pride in my team. Jason and Jesse have carried this project on their shoulders like unsung heroes, relentlessly pushing forward, week after week, month after month, towards a goal that always seemed just a few more weeks away. They've done more than I ever could have asked them to do — and if achieving this goal depended solely upon my own willpower ‐ we surely would have failed. So if you feel the desire to congratulate anyone, aim your confetti cannon at them. Blind them with colorful and high-velocity pieces of paper as we savor this moment as a team. And a community.
Today marks not the end of a long journey, but the beginning of a new and exciting one. Yes, Statamic 3 is faster, more capable, flexible, extendable, and has hundreds of new features. But more than that, it's positioned to grow in ways it couldn't before.
Statamic 3 is built as a Laravel CMS package, which means you can drop it into just about any Laravel application and have a full CMS at your fingertips without having to wangjangle WordPress or another platform onto a subdomain or (God forbid) subdirectory and glue it and your app together with bubblegum and rubberbands.
Statamic 3 is open source and completely free for personal use. Just grab it off Github and start building.
Statamic 3 is designed to scale. You can start with flat files and transition to a database or cloud storage service when you need to by using data repositories.
Statamic 3 can be used as a headless CMS with our content API and upcoming GraphQL implementation.
Statamic 3 can transform into a static site generator with our ssg package.
And that's just the beginning.
There are too many to list, but here's a highlight of some of our favorite new things:
And of course, lots more.
Statamic 3 Pro is $259 and includes 1 year of updates and developer support. After that, each additional year of updates and basic support is $59. You will never have to "renew" your site to keep using it or leave it online, but rather only when you want to get the latest updates and support. Your site is yours forever and we like it that way.
Statamic 3 Solo is free and open source! It doesn't quite have every feature included in Pro, but is certainly more than capable to handle most personal and hobby sites. Head to the pricing page to see the side-by-side feature breakdown.
If you've purchased Statamic in the last year, you can upgrade to Statamic 3 for free. 🎉 Head to your account and drill down into any license to see the upgrade link.
To make the upgrade process easy on the code side, we built a migrator that does just about all the work for you automatically. Give it a try!
We're excited to pursue lots of new open source possibilities with Statamic. New Starter Kits, addons, third party integrations with other tools and platforms like GraphQL and Gatsby.js, data repository drivers, and more.
If this is exciting for you too, you can consider sponsoring Statamic on Github. We have goals and perks and all that stuff set up so we can grow this ecosystem from every angle.
That's all I have to say for now. In this post. Now that we're on the other side of this launch, we can start to put the next several phases into order. We'll be setting up a public roadmap, opening up the new Statamic Partners directory, building new features, and of course, fixing bugs. There's always bugs to fix.
Thank you for supporting us these last 8 years! We hope Statamic 3 provides you with all the tools you need to build and grow your businesses.
Please share this big news with everyone, yes even your mother-in-law. We would love to see and share your blog posts, articles, videos, site launches, and anything else you put out there, so make sure to tell us about them!
Stay tuned, stay classy, and most of all — hug someone you love today.
]]>There were so many things we didn't know when we set out to build v3. We couldn't have predicted the rise of JAMstack and static site tools and platforms like Netlify and Gatsby (although we're not surprised, we've been pushing this idea since 2012). We didn't know some of the big changes Laravel would make (all of them good). We didn't know Caleb Porzio would build Alpine.js. We didn't know there was a pandemic coming. We didn't know the Friends Reunion would be significantly delayed.
The web has been changing faster than ever these past few years and we wanted to make sure that Statamic 3 would be poised to ride the wave of our users needs, wants, hopes, dreams, and deepest desires. If we rushed it, we might miss the wave and be lost at sea, destined to drift quietly into the fog like so many other platforms.
We're not launching today. I'll explain why in a moment. The code base is as ready as its ever going to be. All the big launch features, architecture decisions, and breaking changes are done. We're very happy about that. You can use it today, just like you could yesterday, as part of the beta period. It's production ready in all but the most edge case scenarios (like multi-site, multi-lingual using an Eloquent driver), and kicks some serious buttocks.
We also invested a significant amount of time to building an automated upgrade path with the use of the Migrator package (seriously, most sites take less than 5 minutes). We hope you take advantage of it.
But there are a few other things that need attention for a proper launch. Here's the shortlist.
We're finishing a significant upgrade to the Marketplace. Statamic 3 is completely composer driven from end-to-end, so there's a bit of rewiring to do to get that ready. But the great news is that you'll be able to browse, install, and update addons from inside the v3 control panel or command line – whichever you prefer. 🎉
We're almost done with the docs. Super close. But they're just not quite there yet. We have very high standards for our documentation and hope that you appreciate that about us.
One does not simply launch a major new version of your product and not rework the marketing content and apply a fresh coat of paint. This is well under way.
We're also improving the way you manage licenses, organize your sites, and hand off projects to clients or other teams. It's a huge improvement.
Here's what you probably came for.
I'll answer these in the order they're asked most frequently. I also must say that until it's launched and official, I reserve the right to come back and edit this post and change the details. I probably won't, but just need to say that. In the past I've regretted saying things with finality before they're actually final.
First, and most excitingly for a lot people: Statamic 3 Core will be free!
We want everyone to be able to try and fall in love with Statamic. We don't want the price to get in the way of using Statamic for your personal side, hobby project, tutorial site, demos, examples, or one off site that'll never get updated after the day it launches in a million years.
Statamic 3 Pro will have unlimited users and forms, include basic developer support, and also include the following team/client focused features:
While in development you'll have the option to try out and use all the pro features without having to purchase a license.
Statamic 3 Pro will cost $259 and include 1 year of updates and developer support. After that, each additional year of updates and basic support is $59. You will never have to "renew" your site to keep using it or leave it online, but rather only to get the updates and support. Your site is yours forever and we like it that way.
Any Statamic 2 license purchased in the last 18 months is eligible for a free upgrade to Statamic 3. Upgrades to licenses purchased before January 1, 2019 will cost $59. Don't be alarmed if we ask gently for an optional donation – we worked really, really hard on v3. You can always say no.
We don't have one. Commence the the eye rolls and facepalms! Let me just say that we feel the same way as you do. 🙄🙄🙄🤦♂️🤦♂️🤦♂️ But before you smash CMD+W, hear me out here. There's good news and silver linings waiting.
As I mentioned before, the codebase is in fantastic shape. The new features are delightful. It is a vast improvement over v2 in every conceivable way.
It's faster, better tested, more flexible, easier to customize, more maintainable, can be dropped into existing Laravel apps, used as a headless CMS, can generate and deploy fully static sites, so why wait to use it? In fact, there's no reason why you shouldn't be using Statamic 3 over 2 right now.
The only major thing holding back the "official launch" is the rest of the ecosystem updates. It wouldn't be fair to do one side without the other.
And we're really close on those things, but just like with Statamic 3, we don't want to rush them and miss something important.
Thank you for hanging in there with us, for beta testing, building addons, writing blog posts, sending PRs, and everything you all have been doing thus far. We hope to make you more proud and excited to use Statamic than ever.
]]>If you paid attention you may have noticed that if you buy v2 now for $199 and wait a just a hair longer for v3 you'll save yourself $60. We don't mind at all if you do that. Consider it an unofficial, pre-launch sale.
The GitHub repos are public, the docs are alive, and the feedback so far is
outstanding. If you've been waiting to dive in, now's the time!
#v3 channel.If you don't even plan on reading the docs (you should though, please read them), here's how to get started. First, install Statamic via composer in your command line.
composer create-project statamic/statamic my-site --prefer-dist --stability=dev
Then cd into that project and make your first user...
php please make:user
And then get busy reading the docs! 😁
We hope you love Statamic 3 as much as us, and even more than v2. We're ready and waiting for your feedback. And make sure to star the GitHub repos. Show us and the rest of the internet your excitement!
]]>Very often Statamic sites are build by designers, developers, or agencies on behalf of clients, and then handed-off. These clients don't generally expect to code, and will interact only with the final, configured control panel.
Since every Statamic site is unique, the power and simplicity of the control panel is almost completely up to the developer to configure. The "end user" experience can vary a great deal from site to site.
We receive support requests from these clients, and the situations vary.
Sometimes their developer has gone dark, or they're trying to avoid getting billed for asking questions. Often they don't understand that we (Statamic the organization) don't have access to their site.
Whatever the reason, I've compiled a checklist of proactive things I recommend doing as part of the wrapping up and hand-off process to help smooth those scenarios out, whether you're staying around in a maintenance capacity or not.
Yes, it may be very easy to paste a Google Analytics embed script into the layout file. For you. But if someone ever needs to replace Google Analytics with Fathom or something else, they'll have to call you.
Google Tag Manager is a good way to solve this. If Google isn't an option though, you could create global variables for head and footer scripts, meta tags, and other similar things.
And if that client ever ends up hiring an SEO firm, you can bet there's going to be a lot of meta tags, site verification codes, and other miscellaneous copy pasta 🍝.
Make life easy for them and give them a simple way to DIY.
Here's a quick Gist with the above fieldset config if you want to grab it and go.
We often get emails from people asking for help resetting their password. If email sending isn't configured, the only other option is to reset the password manually in the file system, which is generally out of the realm of possibility for these types of requests.
Nobody likes setting up email, but it's part of the job.
If your server supports PHP Mail or Sendmail, it might just work. But few virtual/cloud hosts have these modules enabled by default, and so you should probably be using SMTP and a transactional email service like Spark Post.
Here's our documentation on setting up email.
This should go without saying, but I'll say it anyway. Don't handcuff your client and walk away. Also make sure they know their server credentials, have access to their repo if there is one, and so on.
We've had to static scrape a site and rebuild it from the markup for a mom-and-pop company who sunk their life savings into a site only to have their dev go dark before it was done. Don't be that dev.
Sure you can say don't upload 20mb images, but it's still going to happen. Eventually. Take it a step further and implement responsive images with srcset. It's really easy with Glide.
It'll take you five minutes and will save you and your client hours, over time. Teams turn over eventually, and given enough time someone new will push to rebuild the site in WordPress because they're familiar with it and don't want to learn something new. Get ahead of that scenario.
It doesn't have to be much more than "here's where you add new press releases, here's where you can edit the footer info, and if you rearrange these pages over here it'll update the order of your nav. Oh, and you can make new users over here."
It doesn't matter if you use Seo Pro, Aardvark SEO, or just add a few text fields to each fieldset. Just make sure to do it. It's a real bummer to get refund requests because "Statamic doesn't do SEO" when they should be taking it up with the "developer that didn't bother".
When a site is in local dev you usually want to rebuild the cache every request so you never have to deal with stale data. Once the site is live and users are making all changes through the control panel, you can turn that off. Any change to the site from the control panel will rebuild the cache when it needs to.
This usually cuts load times in half.
# config/caching.yamlstache_always_update: false
There are plenty of great lists that cover platform-agnostic website launches. Here are two of my favorites.
Go build something awesome. 😎
]]>Exactly seven years ago I was up late. I mean, late late. I was in my home office, revising documentation for the 10th time, writing and rewriting a blog post entitled "Introducing Statamic: The Dynamic Flat File CMS", and watching the sun come up.
That blog post began much like this one, like so many entries written by designers, developers, and entrepreneurs on the precipice of a new chapter in their lives. Full of hope and anticipation at the possibility of wild success come morning.
"We're very pleased to be unveiling the result of many, many long days and sleepless nights..."
Come join me on a trip down my own personal memory lane as I reflect on the last seven years of Statamic history. And I'll just get this out of the way now, there is no v3 announcement or launch hidden in this blog post. 😊 We'll get there. Patience is a virtue.
On June 19th, 2012, we launched Statamic 1.0. It was an exciting day full of congratulatory tweets and well wishes. At the end of it we had earned $970. My dreams of overnight wild success appropriately dashed, I reluctantly admitted that a thousand bucks in a day was still a great thing. After all, what if we did that every single day, all year long? The math was simple and the future became bright again.
I had delusions of grandeur and imagined numbers increasing every month, accelerating our success into ever escalating glory and internet-wide domination. I still do.
After our first month, Statamic had earned $3,153. In all honesty, pretty good for a new bootstrapped product in a highly competitive space jam-packed with free solutions. A flat-file CMS? What even is that? Why isn't it free? We still get the same questions.
I pushed very hard the rest of the year. I cut my teeth on marketing this strange new product. I had a degree in marketing rendered useless by the real world. We released regular updates, added features, fixed blogs, wrote blog posts, built a mailing list, and tweeted. Boy did I ever tweet.
By the end of 2012 Statamic had earned $24,864.50. Not bad for a side project. But it wasn't a side project. I was putting every spare minute into it. I turned away client work, let go of some other recurring revenue, dipped into savings, all to keep the pressure and focus on.
By the end of the year it was pretty clear it couldn't support me as a full time gig. Not yet at least. The slow growth curve of the software startup had begun. But first, I had to face reality. I had a 3 year old son and a newborn baby, so I started taking client work again. A father does what a father must. I did my best and carved out as much time as I could spare for Statamic.
Fred LeBlanc joined as partner shortly after I lost my co-founder Mubs. Mubs always had a special love for building shiny new things, but wasn't into the marathon of maintenance and organic growth. Not everyone is built for it. We hired our first intern Matt (that didn't last long), followed not far behind by our first community and support gentleman, Gareth. His announcement blog post mentioned Google+ circles, whatever those are. Did anyone ever know?
Revenue went right to these fellas. I made my living on client work, hoping that one day Statamic would take off and I could focus on it full time without "distractions".
Statamic did a bit better than 2012. It didn't hurt that we had a full 12 months to work with.
In 2014 Jason Varga joined the team and we announced that work on Statamic v2 had begun. Slowly.
Statamic grew slowly as we dedicated as much time to it as we could. As a team we tackled interesting client projects (like Laravel.com, Forge, Envoyer, Nutrifox, and a bunch of others).
Overall it was a good year. Statamic grew another 20%. We were a couple of devs on it part-time, which mathematically equaled more than one full-time person, but as I've learned over the years...there's no replacement for whole-assing one thing instead of half-assing two things.
I also lost Fred in 2014. It was time for a major change in his personal life, so I bought him out and he was able to move on. Statamic was now ultimately my full responsibility.
We spent most of 2015 building Statamic v2 from scratch, carving out every minute we could spare to work on it.
We launched the beta in Q4 and spent a few months refining it with community feedback. We learned a hard lesson though and immediately knew we opened the beta too soon. What would have probably taken 6 weeks of focused work took nearly 4 months while handling support, managing expectations, communicating changes, and replying to repetitive bug reports we knew were there since before beta.
This is something we want to avoid with v3. We have significantly raised the bar as what we consider "beta-ready".
2016 was another year of marginal growth. Nothing spectacular, but respectable. No possibility of full-time yet.
We launched Statamic 2.0 on March 31st, 2016. You can even read the blog post if you'd like. It was a full (and necessary) rewrite. I mention how pleased, excited, and relieved I was to launch it, but in all honesty I was terrified. What if nobody bought it or used it? What if it was confusing and terrible? What if it broke when you touched it? What if that whole year was for nothing?
It worked out fine. People loved Statamic v2. It was a lot closer to my initial vision for what I had hoped Statamic could be. Sites like asana.com, freshbooks.com, and kellyclarkson.com were using Statamic.
Also in 2016 we said goodbye to Gareth and hello to Jaggy. Jaggy tinkered on Statamic a bit before ending up working primarily on client projects. That situation allowed me to put more of my time into Statamic, and it worked pretty okay.
We grew a bit more that year and my Hopeful Math™ proved that maybe someday soon we could all really do this thing for real, full-time.
Features, features, and more features. We built everything we could and then built some more stuff. We launched and then retired Statamic Unlimited. I pushed harder on marketing, did more things that didn't scale to build relationships and happy customers, and did some conference speaking.
Spiegel began using Statamic and we flew to Germany to collaborate with their team.
We were doing everything right to the best of my ability, and revenue shrank. 2016 was simply a better year than 2017, probably in large part to revenue lost from the Unlimited program. It was a flawed model and to be honest, it almost killed us. That's just how business goes sometimes. Another lesson learned.
At the end of the year I finally took some advice from a friend who told me that I was missing out one of the best marketing tools available: me. I had been trying to build this persona for Statamic that wasn't quite natural, trying to get the product to speak for itself on its own. I had hid behind the company and hedged my bets to some degree. This friend recommend I just pour my own personality all over Statamic and light a match.
I went for it. Enter the rebrand: the hot pink infused glory of the late 80's/early 90's was here. We immediately saw an uptick in buzz, engagement, conversions, mailing list sign-ups, and best of all — sales. We stood out in a world of flat, stark, sterile design. Even if you hated pink (and some people sure did), Statamic became visually memorable (if not pronounceable), and the brand voice was simply my own. It was easier to relate to, easier to understand, and the promises we made were no longer vague.
"Better, faster, more flexible" is never enough detail to convince someone to quit using what they're using. Remember that.
The turning point year. A lot happened in 2018. We launched the marketplace, said goodbye to Jaggy, hello to Jesse, built some great features like Bard, rewrote the caching layer, switched from Slack to Discord, and made one small change that very well may have had the biggest impact of any other decision up to this point.
I took Jason off client work. It was clear that someone needed to be full-time, someone who didn't have to switch context several times a day. No more 3 days on, 2 days off. If I couldn't whole-ass Statamic myself, then I made darn well sure somebody could. And who better than the lead Statamic developer?
It was like pouring gasoline on the hot-pink-infused fire. Jason crushed it. Bugs were fixed faster, features were built quicker and better, and it was infectious. I found myself being more productive, carried along with the momentum, inspired to tackle things as team I had lost hope of ever building.
In 2018 Statamic's revenue doubled and by the end of the year all three of us were on it full-time.
And here we are, nearly halfway through 2019. We're pretty close to being in beta with v3 and I'm getting those mixed feeling of excitement and fear again. We've come further than I ever dreamed, and it was harder than I ever expected. But with seven years of work behind us, a fantastic team around me, and incredible community around us, we can finally see the real fruits of our labor.
It's never been all about the money. If it was I would have taken one those job offers from PayPal, Google, or Facebook. I would have just used a database and built another WordPress clone. But I love creating something unique that others can fall in love with. Something that can change the game. People don't just build websites with Statamic, but businesses.
So from the bottom of my heart, if you've ever bought a license, thank you. You laid a brick in the foundation of my dream, making this whole thing possible. We don't have recurring revenue like a traditional SaaS company and every month is a walk of faith, starting with close to zero dollars and zero cents of guaranteed income. Every month God is faithful. Every month you all come through. Every month I'm renewed in my efforts to do my part and make Statamic the greatest CMS of all time.
I never take it for granted. Because of the sites you all build, we can homeschool our kids. Jesse and his wife can homeschool their kids. Jason and his wife can get back to Australia once a year and visit his family. We can afford homes, groceries, and life insurance. To me this is a successul company. I don't want to play the Silicon Valley game and chase venture capital or angel investors. This is the company I wanted to build. It's here now, thanks to you.
I hope Statamic always delivers drastically more value than its cost. I hope you keep building sites and supporting us. For those on the agency/freelance side, I pray you make a fantastic living on delivering great websites for your clients, and that Statamic becomes (or remains) a big part of how you do it.
Here's to the next seven years!
And now let's have a little fun! Want to see how far Statamic has come in the last 7 years?
I dug up a copy of Statamic 1.0 and after fiddling around with MAMP for a while to get PHP 5.3 running (I don't want to mess up my beautiful Valet environment), I took some screenshots.
For those of you who never used v1, it was so basic. The entire package was 766kb. The control panel was just a glorified YAML editor, you couldn't create collections, taxonomies, manage settings, or anything like that. Composer was nowhere in sight. It was built on SlimPHP and nearly the entire control panel was written in a single routes file, inside closures.
But it worked! It was the first stepping stone to where Statamic is today and I'll always have a special place for the version that could fit on a single floppy disk.
If you want to try Statamic 1.0 out for fun (and can manage to get PHP 5.3 running somewhere), you can download it here. This should go without saying but please don't use it in production, it's super buggy and probably insecure. Okay, definitely insecure. You can find the docs at v1.statamic.com.
There is no one perfect platform or architecture for every website. Just like a wrench will not fix all broken things in your home, fried chicken is not suitable for all meals, and the color hot pink (probably) does not belong on all walls. Your content is unique. Your company is unique. You are unique.
Over the last seven years we've taken a hard and opinionated stance on how content should be structured. We don't believe in the WordPress-style approach of jamming all content into a database as a giant blob of text. Instead, we highly encourage and enable a unique, bespoke content model for every website.
Titles, subtitles, images, content blocks, summaries, excerpts, video embeds, code snippets, related content, and on and on — we believe it should all be broken up, structured, and stored in an object model instead of one big ol' blob. This approach enables you to adapt and stay flexible in how you want to present and organize your content for the world. This separation of content and presentation has many, many benefits.
In Statamic 3, we're taking this principal & extending it to data storage.
You cannot beat the stability and flexibility of storing data in flat files. They can be backed up, compressed easily, are highly portable, can be version controlled, accessed on any platform, and manipulated in batch by any number of external tools and languages. The only real downside to flat files is performance. Reading, writing, parsing, indexing, and manipulating thousands or millions of files is not a small task, especially if done on the fly while rendering a dynamic request. That's literally why databases were invented more than 50 years ago.
Here Statamic has been poised, at the crossroads between flexibility and performance, not willing to sacrifice one for the other. So we blazed a new trail into uncharted territory.
What if you didn't have to choose between flat files and databases? What if you didn't have to pigeonhole your entire site into a relational database to handle a large dataset with a good control panel? What if you wanted to version control some of your content and configuration but have millions of entries to manage? What if you wanted to use No-DB, or run a headless CMS on your own server?
We thought those very same things and SPIEGEL helped us realize we already had most of the answer.
Statamic 3 has an end-to-end abstraction layer that allows you completely swap out the storage mechanism in a "driver" like fashion, allowing you to connect to just about anything as a data source. Let's unpack this with some examples.
If you have a lot of small bits of relational data — like an ecommerce system with thousands of products, manufacturers, parts, and variants, you likey want to use a relational database like MySQL or Postgres handle the complex many-to-many relationships. Fantastic, now you can with Statamic. Grab an Eloquent driver, tweak it to your needs, map a fieldset (aka blueprint in v3) to match your table schema, and you're off and running.
Perhaps you have a huge content store of articles, like SPIEGEL. Write a MongoDB, ElasticSearch, or Firebase driver to your needs.
The control panel will pull your data, populating the control panel as usual through the driver's query builder, and push it back out as you desire. Essentially, the entire control panel only cares about JSON-in and JSON-out.
If you want to use Statamic's front-end engine (Antlers), our tags take advantage of the same abstractions and will work exactly the same way you're used to with Statamic v2. Swap drivers, populate your data store (whatever that is), and your {{ collection:articles }} tag keeps doing its job.
Don't want to use Antlers? You're already in a Laravel app — write a few controllers & routes and render your site with Blade. Or Twig. Or push it into a Vue or React SPA. With Statamic 3 you can go full headless mode and take whatever approach you need.
Out of the box, Statamic 3 will behave in the same way you may love today, storing its content in YAML front-loaded Markdown files and consuming data from the Stache compiled from them. It works better than ever and you can worry about scaling later. This abstraction is ready for you if and when you need it.
With Statamic 3 you can scale from a hobby blog to a world-class news publication without changing platforms.
Curious about how SPIEGEL's stack works? Here's their high level approach, keeping in mind this is running on v2. Upgrading to v3 streamlines even more of their stack.
Statamic is no longer a one-size-fits all solution. It adapts to many sizes, making it a great fit for an increasingly wider set of challenges. It can be a standalone control panel, a headless CMS, a backend for your Laravel application, a simple markdown editor for your company blog, and many other things in between.
Statamic 3 isn't finished yet, but we're happy to start talking to teams interested in running larger sites with Statamic. André Basse from SPIEGEL has even volunteered to be available to share their team's experience with Statamic. I'm happy to put you in touch if you're seriously interested (email me at [email protected] for an introduction).
Statamic can be a standalone control panel, a headless CMS, a backend for your Laravel application, a simple markdown editor for your company blog, and many other things in between.
Our next milestone is Alpha 2, which will be an invite-only small group of folks who are very experienced with v2. If you've never used Statamic before, Alpha 2 is not for you. Tire-kickers can jump into the open beta when that's ready.
We encourage you to jump into the #v3 room in our Discord chat server to continue this conversation and explore the future of possibilities. We're excited to see where things grow from here, and hope you are too. 😁
Back in October 2017 we scheduled what seemed to be a relatively routine video chat with a larger Statamic customer. They had done some custom stuff they were excited to show us and wanted to pick our brain about our upcoming features and roadmap. I'll be honest, as a mono-lingual American, I hadn't heard of SPIEGEL _techlab before and only Googled them as the call was ringing. These types of calls usually come from some beige-souled corporate IT solutions company running .NET and generally look like this:
"Hey there, we were wondering if you had any plans to incorporate ENTERPRISE FEATURES A, B, C, F, and N-Z. Oh and E-commerce, SAP integration, and can guarantee 24/7 phone support at risk of severe contract breach."
We're a 3 person company. The answer is probably nope.
Instead of this Groundhod Day scenario playing out yet again — I realized this was the dev team behind Der SPIEGEL, the huge German media and publishing company with a Top 500 site...right as the video screen popped out of black. André Basse and his energetic developers were excited to chat with us, and formalities and introductions concluded, they dove right into a demo of what can only be described as my grand vision for Statamic — something I've dreamed about since its earliest conception.
There was Statamic, running spiegel.de/plus and bento.de, two sites on a scale we had yet to encounter.
They dove right into a demo of my grand vision of Statamic, something I've dreamed about since the very inception of Statamic.
I knew almost immediately how they were doing it, at least on a high level. There's only one way to run at that scale. And no, it's not MySQL or PostgreSQL. We had been hoping to maybe, eventually, arrive there someday, taking efforts to carve its shape out as a trail of secret breadcrumbs, abstractions, stubbed out hooks, and unfinished endpoints.
I'm not sure if you knew that. Building the software is often the easy part. Making a business out of it without losing sight of the reason you built it in the first place is very hard. I'm sure many of our readers know it first-hand. It's a constant trade-off between immediate cashflow needs (payroll comes twice a month, did you know that?) and long-term goals. I never wanted to just bolt-on custom services as the plan for profitiability. I wanted to build a dream platform. The next level of CMS. I could see it. I could taste it.
I had been hoping to build out the rest of our dream platform for years, but we could never find enough time between the more immediate needs of our current customers, and the marketing efforts needed to reach new customers in the short-term. And so Statamic stayed a really great flat file CMS, capable of running small to medium sites (or large sites with good caching), but confined by pre-concieved conceptions and technical bottlenecks.
You see, flat file architecture is blazing fast...to a point. If you want to fetch single entries by URL or the last $n entries from a collection, it'll scale forever and stay quick. But the moment you want to sort, filter, search, or order, you need a lot of data. Maybe all of it.
Once you reach thousands of files in a folder, it takes a painfully noticible amount of time to parse them all on the fly. We knew this of course, and as far back as Statamic 1.5 we built a proprietary caching system (called the Stache) to store pre-parsed data with indexes, keys, and other chunkes of data used to help you perform those sorts, filters, and searches quickly. It works really well, and as long as you can throw some static caching on the front-end, your response times will be nice and fast.
However, since files are the permanence layer for your data, the control panel side of the application can't work with statically cached data or rendered files. At some fairly hard-to-guesstimate tipping point for an amount of data in your site, your experience will begin to lack in the performance department. It's usually somewhere around 2,500-5,000 entries, but it can be less or more depending on the raw amount of text.
2 weeks later Jason and I were getting off a plane in Hamburg, Germany. It was clear from our chat that we would both have a lot to gain from spending some time together.
They had found our breadcrumbs, saw the potential, and built out the missing pieces. Excited by the possibilities, we spent the week in Hamburg cleaning up some abstractions to let them have a cleaner integration with the custom side of their stack. We also built out some additional features that made a lot more sense to be in core rather a custom addon. The bulk of these features became Statamic 2.8 - namely custom publish forms, Bard, and database users.
As a bootstrapped company, it's not often you get to experience a living use case like this. It was surreal to see the Statamic control panel up on screens everywhere I looked. Developers, writers, you name it. There was Statamic. Running on the same playing field as the New York Times and The Guardian.
A fair question. Yes, SPIEGEL had the golden goose, and they even graciously offered us their code if it would help grow Statamic. However, Statamic v2's codebase was stretched too thin in too many places to roll out these kinds of big changes. Yes, it was totally feasible to do as a one-off, but plug-and-play friendly with a streamlined upgrade path and clear docs? Not so much. Rather than comission the hype train without a finished track, I decided it was best to bide our time and we began working on Statamic 3.
We just got back from another trip to Germany two weeks ago where we showed the SPIEGEL team what we've built, and within just a few hours we had Statamic 3 alpha running with millions of entries, blazing fast response times, and no SQL involved. Now that we know for sure we can pull this off, we're breaking the radio silence.
🔥 Tip: at this kind of scale, MySQL can simply fall apart.
I can hear your questions. So how does it work? What's the secret sauce? Is it in Statamic 3? Can we have it now? I know you all want to know more. I promise to get into all the glorious details NEXT WEEK IN PART 2. I don't mean to tease, but it's Friday after 5pm, and you should be ordering pizza. Or at least I should. Until next week...👋
]]>We are pushing blog posts to the site every Tuesday and Friday for the foreseeable future. If you want THE OFFICIAL SOURCE OF TRUTH on all things v3, v3.statamic.com is the place! Everything else is rumors and heresay. Including Discord's #v3 room.
So head on over to Threeville, there's an FAQ section and a few blog posts waiting for you already. We can't wait to show you what's in store.
]]>For many, Bard is a focal point feature. Perhaps the selling feature, depending on the site. Not only is it an easy to use content editor, but it enables you to configure any combination of custom blocks full of fields that can be inserted anywhere in your content. You can build just about anything with it, in terms of content schema and rearrangeable configuration.
Naturally, it suffered from something most (if not all) web-driven editors run into. Inconsistent markup, and edge-case behavior. If you were a casual user, you may have not noticed anything, but some of our power users and their writing teams were finding the editor experience to be glitchy at best.
The main issue was inconsistencies with the browser's contenteditable API, the main source of pain and anguish for every developer building a custom WYSIWYG-type field. I'll spare you the long and miserable details and cut to the chase. We had built Bard on top of MediumEditor, which in turn was built directly on top of contenteditable. There was no fixing the behavior problems without a forking the library and working through the list of 40+ browser inconsistencies ourselves. 😱
While I enjoy a good challenge now and then, we did some research before canceling our plans for the next 3 months. I'm glad we did.
As luck would have it, The Guardian also ran into the same problem, and put a team on it. They wrote a library called Scribe that serves as a wrapper around contenteditable and patches the browser inconsistencies.
We put Bard up on a lift, ripped out MediumEditor, and rebuilt the editor from the ground up with Scribe. And as long as we had everything taken apart, we took the opportunity to wire up some great new features and settings. The result is a leaner, meaner, and significantly improved writing experience.
Let's take a look at some of Bard's new hotness. 🔥
If you had built any custom Bard + MediumEditor addons, unfortunately they won't be compatible with the Scribe interface and will need to be rewired. We have docs on how to do it, and overall it's more simple and flexible than before. If you need help, just let us know.
There is a pile of other improvements and fixes to be found. As always, you can read them all in the changelog. Go forth, update, and enjoy!
]]>And then the problems began. Slowly, quietly, lurking in the shadows. Perhaps not affecting everyone, but they began to stack up.
TL;DR: We've moved to Discord. Come join us!
Notifications on top of notifications with no way to truly mute channels. Simply being signed in was stressful.
The 10k message cap for free accounts was frustrating. Just a day or two after a helpful conversation, it was gone forever (unless we paid). Yes, chat transcripts aren't as useful as docs, forum posts, or knowledge base articles, but that doesn't mean we still didn't want to dig them up from time to time. Especially in DMs.
File upload limitations with no way to bulk delete old files. Every new person to join the Slack workspace and upload an image would be blasted with a message saying you were out of space and the account needed to be upgrade. This would spawn the inevitable conversation topic "Why doesn't Statamic pay for Slack? It's just $8/mo per user, we're all loyal, I'd even pitch in!" Then you do the math. 1,800*8 = $14,400 per month. No thanks.
We would have happily paid $50/mo or more to file storage, or the ability to connect to an S3 bucket or something. But this isn't Slack's business model, and we don't fit their target use case. Slack was designed for teams, not communities.
Slack is missing granular roles, which meant that to have certain features enabled, everyone could control them. Everyone can spam @channel or @here, DM anyone, and get away with it. This didn't happen often, but just knowing it could meant we needed to be proactive with sending messages to members informing them of the "rules".
If we wanted to "elevate" a community member to a high role or status to let them help with moderation, there really wasn't a way, short of putting them in the "owners" seat.
Again, since Slack was designed for private teams and not open communities, we had to use a third party node app that used the API to initiate invites and auto-resolve the confirmation process. These tools are not that secure, and early on one of them was exploited and a spam bomb went off, inviting thousands of people to our Slack workspace.
I got emails saying "We would never work with a company that used such invasive marketing tactics!!" and "What the heck is a Statamic?" I remember that disaster mitigation week very well, working through hundreds of 1-on-1 conversations, apologizing to people, sending apology emails as we patched up the node application and added ReCaptcha and other checks and throttles.
This is not an attack vector you want to be constantly worried about.
We use Slack internally here at Statamic because it does work really well for teams, especially when you combine it with Basecamp for longer-term planning and asynchronous communication.
By having the Statamic community in the Slack tab bar, there was always a badge lighting up. There was nothing that could be done about it, short of remove it from the app and open it in a web browser from time to time.
It's not that we want to ignore the community chat, but we have a lot of work to do, supporting our users with direct support, working on the core, and finishing v3. We have to balance a lot of things with a small team, and having a separate application entirely is a wonderful way to enter "Focus Mode".
If you've used Slack, you can probably relate to our laundry list. It was clear we needed a new platform, that people love live chat (and we already have an active forum), and all that was left was to figure out which one.
So I started researching. I looked at Spectrum, Google Chat, Telegram, Discourse, Gitter, and a bunch of others, and kept coming back to Discord.
If you're familiar with it, you know it's primary audience is gamers. It's integrated into a lot of games and platforms directly as a way for communities/guilds/clans to chat. What you may not know is that they've been working to build up their secondary audience: developers. They have a roadmap of features and things they're working on, and many of them are dev-focused. They've integrated webhooks, have an API, and all the stuff you'd need to customize your "Server" as they call it. And I like where they're heading.
Discord's business model focuses on the individual user instead of the organization/company. They have a laundry list of features you can enable by paying $4.99 per month (this is called Discord Nitro), like animated avatars and emojis, boosted upload limits, high quality screen sharing, choosing your discord tag, and a special profile badge. If someone in the Statamic Discord wants these features, they can have them for just a few bucks a month. In turn, we have unlimited file storage, unlimited messages, and a whole lot more that we didn't in Slack.
The interface is very similar to Slack (also offering a Dark Mode, which is pretty rad) and supports most, if not all of the main keyboard shortcuts. Honestly, you'll feel right at home in 5 minutes or less.
We can now group channels into categories, allowing us to stay a lot more organized, and avoid the firehose problem.
We can now call out different roles for the users in Discord. Like Core Team, Support Heroes, Partners, and so on. Plus, you can tell Discord to show what game you're playing. It turns out, Sublime Text and VS Code are the most popular "games" in our community. 😂
When you mute a channel, it's muted. No little white badge. Nothing. Like it doesn't exist, until you go unmute it. ❤️
It's just the way it's supposed to be. Nothing more to say.
In private groups of up to 10, this is built right in. Not tucked away behind a premium tier.
Since this is happening, and we've already had a few hundred move over from Slack already, here are some tips we found to get the most out of Discord as a developer.
Discord uses the dark theme by default. If you like it, great. If you want it to feel more like Slack, head into User settings (press cmd+, for short) and under Appearance you have your choice of themes, font size, and all that stuff.
Also under Appearance you should enable Developer Mode. This will give you additional contextual message options when you click a message's options (those 3 dots). You can get the link to a message so you can paste it elsewhere and reference it. Something very useful when chatting through support topics.
Discord supports specific-language syntax highlighting, which is pretty cool. After your three ticks ```, you can add css or php and it will highlight accordingly.
Read about the Markdown and Code Highlighting options.
Just like Slack, Discord has native apps for a better experience. Download them here.
In User Settings > My Account You can set your username to whatever you want. We recommend using your real name, or at least your first name. And upload an Avatar. This isn't the dark web. Let's get to know either other.
Come join us in Discord. If you want. We're just not going to be in Slack anymore. 😊 Rest in peace, Slack.
]]>Jesse has recently become a father (for the fourth time!), and during his parental leave we started talking about a possible fit here at Statamic. It was clear he had the skills and the desire, the rest was merely details.
Jesse is certified Laravel Elite , uses Vim, hails from London, Ontario, has a fantastic beard, and with literally no delay is already raising the bar for our TDD efforts in Statamic v3. He doesn't play D&D, but given his HeroQuest™ hobby, all is forgiven.
Check out some Jesse-related links:
His official first full-time day is October 1st (my birthday, no big deal 😏), but he'll be ramping up between now and then. Follow and congratulate him on Twitter, he's one of us now!
]]>If you are Laravel developer or are migrating from another platform and have some DB tables full of data you don't want to migrate to flat files, or some other similar use case, this article is for you.
Typically, content is stored in YAML Front-Loaded Markdown files. When you edit content in the Control Panel, the data is loaded into a standardized object structure, injected into our Vue-powered Publish component, is available to be manipulated by your custom fields, and then is transformed back into that YAML Front-Loaded Markdown format again on save.
However, if you want your data to live somewhere else, you can write your own load/save logic and let the Publish component do all the hard work. We have a page dedicated to the Publish component in our docs, but sometimes it's better to see stuff in action. So, we built two real-world use cases/demos for you to play around with. Feel free to use and modify them however you'd like!
Eloquent, included with Laravel, provides a beautiful, simple ActiveRecord implementation for working with your database. Each database table has a corresponding "Model" which is used to interact with that table. Models allow you to query for data in your tables, as well as insert new records into the table. You can learn more about Eloquent in the Laravel docs. Just keep in mind: Statamic 2.x runs on Laravel 5.1.
We built an addon that hooks up a generic Product Eloquent model/table to a custom Publish component in its own area of the Control Panel. The package also includes templates, routes, and tags that allow the products to be displayed on the front-end in standard Statamic style.
Check out the repo here (docs in the README):
Another use case may be to publish content to a completely different app via an API. You might want to do this if you have an existing Laravel app and want to manage content in your Statamic site. Just an idea.
This addon works the same way as the Eloquent example, except the data is stored in completely separate site. This repo holds two separate apps:
Here's the repo (docs in the README):
Here are a few tips if you decide to experiment with this approach.
Each model needs a corresponding fieldset with fieldnames that match the column names.
Be sure to whitelist the columns you want Statamic to be able to manipulate.
Database credentials are stored in your .env file.
DB_HOST=localhostDB_DATABASE=database-nameDB_USERNAME=usernameDB_PASSWORD=password

We've redesigned the Fieldset Builder from the ground up. No more modals on top of modals, this experience is as intuitive as we could possibly make it. You can now scaffold out your fields on the fly, rearrange and reorder at will, control field widths inline, filter and search fieldtypes with a new picker, and more. We think you're gonna love it.

This has probably been the number one feature request of all time. We reimagined the entire Publish process, from the Fieldset Builder all the way through to the Publish screen on all device sizes to ensure every aspect of the experience was intuitive and tightly integrated.
Not only can you now group your fields into tabs, but you now have complete control over the required system fields, labels, and even sidebar.

Like...
So go visit the changelog to explore the full list of features, enhancements, and fixes, and tell us what you think!
]]>As of today, the brand new Statamic Marketplace is live and open to the public!
The Marketplace is the authoritative spot for all Statamic addons and themes, both free/open source and paid/commercial.
Everything is integrated with your existing statamic.com account and all paid products are kept in your account just like Statamic licenses.
So if you're interested in listing Statamic bits and bobs, open up a shop, connect your Github account and you're off and running. Want to sell stuff? Connect your Stripe account, set a price for your products, and you're done. You keep 75% of all transactions, while the rest goes to covers fee, VAT tax when necessary, and supports ongoing development of Statamic and the Marketplace.
We've built dashboards, sales reports, order and customer lists, download counts, and all sorts of great tools for Sellers. We have an FAQs section to help any questions you might have about every little detail.

New first-party addons are on their way, and we have a roadmap full of great new features coming to the Marketplace over the coming weeks and months. We hope that this will be a place that helps the community in all sorts of new ways as Statamic continues to grow and support an ever increasing number of developers, companies, and websites.
We hope you love it.
]]>
Keep in mind that this is all still in development. The following information may change.
The guiding force of this next major version is to make Statamic more customizable and open. We don't have too many game-changing user features planned, but rather are focusing hard on the framework and architecture in such a way to make future game-changing, mind-blowing, productivity-enhancing, retro-t-shirt-wearing features more possible.
For this reason, we will not be charging for the v3 upgrade. We all will benefit from v3, so we want to lower the barrier as far as possible in hopes that we can get everyone upgraded. We are doing our best to make the upgrade as automatic as possible, but there will inevitably be a few things you'll need to do by hand.
Statamic v2 was built on top of Laravel 5.1 and packaged up into a bundle. Statamic v3 will be a self-contained Laravel package, designed for Laravel 5.6+. There are a quite a few benefits to this approach, especially if you're a PHP developer.
Your Statamic will be an instance of the laravel/laravel application itself. If and when you want to pop the hood and customize system behavior or add functionality, the framework itself is now the limit, not Statamic. You can make your own routes, controllers, classes, composer dependencies, and whatever else you can think of, just like a vanilla Laravel app. You'll no longer need to create a Statamic addon just to add one little thing.
For those who don't need this flexibility (which might still be the majority of you), we will also be providing a ready-to-go Statamic package, just like v2. You'll hardly notice a difference.
If you ask us "How can I use Statamic with my Laravel app?" today, the answer is kind of awkward. You need to run it separately - in a subdomain, subdirectory, or with a set of complex server rewrite rules. Then you can make the two apps talk to each other. Kinda.
With v3, if you have a Laravel app and you want Statamic to handle the marketing pages and blog? No problem. composer require statamic/cms and you're nearly done.
Statamic 2 consumed Laravel as a dependency, which means you're "stuck" on the version we provide and support. No longer so in v3! You control the laravel/framework dependency in your composer.json, so you can update whenever you like. Hello Laravel 5.6.x!
The Statamic source code will be in a public Github repo. Everyone will be able to contribute; whether a pull request, bug report, or comment about a ridiculous commit message. Like when Jack "fixes tpyos".
Are we asking you to contribute? Certainly not! But if you enjoy popping the hood and tinkering, want to help translate the control panel, or have some other cool idea, it's now possible. Statamic won't be "Open Source", but neither will it be private. With an open repo, Composer now becomes a tool instead of a barrier.
It will also let you stay on the very cutting edge without having to wait for patch releases. If we fix a little bug that's holding up your progress, you won't need to ask for a custom build, a cherrypicked fix, or a 1 commit patch release.
Our beloved templating language – Antlers – will have its file-type upgraded from a plain .html extension to .antlers.html. This will allow IDEs to better detect when you're working in a Statamic template vs a regular HTML file.
Not only that, but the filename convention can better allow for additional template parsers in the future.
99% of the time the site/themes directory has just one theme in it. Statamic is so good at bespoke sites, and data models are so unique, that inter-compatibility between themes isn't a very common occurrence.
In v3, your "theme" will be located in /resources. Just like a like a regular Laravel app. On that same note, there's no longer separate templates, partials, and layouts directories. Just put all your files inside views and arrange things however you like.
This lets your gulp, grunt, or webpack files stay in the root of your project, and those who use the command line often won't miss the regular trips to cd site/themes/theme_name to get things done.
That doesn't mean you won't be able to design and build "Themes" from a design standpoint. We fully expect the theme area of the perpetually-coming-soon Marketplace to be a thriving place. It'll just be more clear that these theme packages are for new sites, rather than existing sites (which was always the case anyway).
We decided to take a step back and think about the way we manage the various settings and types of settings in v2. If you've spent any significant time building sites in v2 you may feel that the configuration area of the Control Panel (or settings YAML file area) feels a bit...disorganized. Like a big grab bag full of random stuff. While it was a big improvement over v1, we've learned a lot in the last few years, and it's time to change a few things.
There are several distinct types of settings. Some affect the whole system and are usually set once and left alone, like cache modes. Some only affect the Control Panel fieldtypes, like Redactor configs. Some are merely preferences that affect only certain areas of the Control Panel, like Dashboard Widgets. They're all mixed together like a bad Hawaiian t-shirt.
In v3 we're going to be moving all those "developery" things, like system and caching settings, to Laravel-style PHP config files. There's no real need for everyone to tinker with them in the Control Panel. The consequences of turning on Static file Caching without understanding its nuances may be unwelcome, like a slap bracelet to the face.
The Control Panel's settings area will be trimmed down to things that affect the Control Panel, and things that are more preference-driven. Like Fieldset and Form builders, Widgets, Permissions, and the like.
Statamic v1 was a rough and simple tool, but it had one big advantage over v2. You could use symlinks. You could put addons or content folders in one place and toss symlinks around like Johnny Appleseed.
But as the story goes, in v2 we used the Flysystem package to abstract the way we interacted with the filesystem. We thought it would give us more flexibility because you could connect to all different file systems, like s3, Dropbox, and FTP. But it turns out, it wasn't all that useful most of the time, and Flysystem didn't support for "arbitrary" symlinks. We kind of made a mess of the implementation.
In v3 we return to our bare metal file-touching roots. Things that belong in the local filesystem (content, form submissions, etc) will remain there, and we'll interact with them directly. You probably won't even notice a difference, except now you can use symlinks again.
However, Asset Containers will still use Flysystem under the hood. You'll be able to hook into Laravel's native file storage disks for any container. This means that you can put your assets in Amazon S3, Rackspace, or FTP server. And that covers a real-world use case, and leverages Flysystem the way it was intended. And everyone is happy. And there was much rejoicing.
But that's all we have to share today. We'd love to hear your feedback! You know where to find us. We want everyone involved as much as you wish to be. Stay tuned for more updates as we get closer to something that resembles a beta!
If you're wondering if you should wait until v3 to jump into Statamic, the answer is no way! Don't wait. Everything you'll love about v2 will be in v3, and there's no upgrade fee. So get going! Build!
]]>The secret to doing anything is believing that you can do it. Anything that you believe you can do strong enough, you can do. Anything. As long as you believe.
— Bob Ross
Statamic 2.8 has one crowning feature -- a giant, ambitious, delightful master piece -- and lots of small enhancements that snuggle up to it for a contact high. I dislike long rambling intros so let's get right into it. Here are 2.8's top 5 new features.
We've thought long and hard about what Statamic users do most. About what content authors do most, for that matter. We've looked at the landscape of the competition and other publishing tools, what interfaces people gravitate towards, and think the answer is painfully simple.
People just want to write.
The thing is, writing has evolved. Sites grow, layouts change, and writing tools grow stale. WYSIWYG fields are often regarded as the devil (a sentiment we share). Markdown is great a lot of the time, but it has limitations when dealing with rich content. Wouldn't it be great if it was easy, seamless even, to create highly structured content so your site can evolve with the times?
If WordPress's Gutenberg (or Medium.com) got married to our Replicator and had a grownup baby all Benjamin Button style, it would be Bard.
We've spent a few months working on Bard. It's a text field. It has rich formatting controls but it's not a WYSIWYG. It shares many features with Replicator, enabling you to create and rearrange sets of fields and insert them anywhere in your text content. It stores structured content like Replicator, allowing your markup to evolve over time without having to rework your content.
I could talk about it all day, but how about just watching it in action?
With Bard, just like with Replicator, you can figure an unlimited number of sets of fields that can be inserted into your main content flow. You could build almost anything with it. We can't wait to see what you do with it.
If you want to see how to template it out, check out the What I Did Last Summer sample post and long_form fieldset in a fresh Statamic download package.
Embedding YouTube and Vimeo videos is a pretty common action, yet extracting the ID and using the correct embed code is pretty painful if you want to support multiple services.
So we made it easy for you. Paste a URL or embed code into the the Video fieldtype and it will extract the correct URL and show you a preview to make sure it's the right one. Pair it with two new modifiers and you'll be embedding videos faster than ever.
Use embed_url to convert the URL of a YouTube or Vimeo to the proper embed format.
Use is_embeddable to check whether a given string (i.e. the URL) is actually embeddable as an iFrame. Put these together and you have a reusable code block that looks like this:
{{ if video | is_embeddable }} <!-- Youtube and Video --> <iframe src="{{ video | embed_url }}" ...></iframe>{{ else }} <!-- Other HTML5 video types --> <video src="{{ video | embed_url }}" ...></video>{{ /if }}
This has been an often requested feature. Perhaps you want to have a single source for your user accounts across all of your websites. Or maybe you have thousands of users. Or maybe you want to tie into an existing database. No matter your reason, it's now supported. Here's how to do it.
The most common follow up question we've had on to feature is "can this work for entries too?" Alas, no. That's a completely different challenge we won't be tackling in v2.
Ever create a one-off page as a route and wish you could just load content from another page or entry automatically and cut out the get_content tag? Well, now you can. Pass a URL or ID into the load var and you're done.
routes: super-special-event: template: landing-page load: /faqs
Another often requested feature makes its debut in 2.8. Read-Only permissions can be set, like all other permissions, on a per-collection/taxonomy/asset container basis.
So go visit the changelog and checkout the 42 new things 2.8 has to offer. We worked hard on it and hope it makes your day. We'll be back soon with a new post on where we're headed with Statamic v3. Until then...
We ❤️ ya'll!
]]>Because we're all about developers, developers, developers, we now have a brand new command line updater!
Starting in 2.6, you will be able to update Statamic with the command php please update. You will be on the latest and greatest version faster than you can google for a Mario coin sound effect and play it. Which would happen automatically if you used the control panel.

Statamic now also has a command line tool for installing new instances of Statamic. Create a brand new Statamic site by running statamic new project-name in any directory, just like Laravel's installer. That's all there is to it!

You can read about how to install and update using the command line in more detail on our docs.
When you have an itch to scratch that you can't reach natively (talking about features here), you've always able to extend Statamic by creating an addon.
However, creating a whole addon, with all of it's naming requirements and whatnot just to write (for example) 3 lines of PHP can be annoying and time consuming. With site helpers, you can just drop your code into a single file and call it a day.
With the Marketplace launch rapidly approaching, we are encouraging developers to treat addons as packages you may want to distribute. For single-site specific code, just use a helper. It's quicker and cleaner, even if it does remind you of that one blogging-platform-you-swear-you'll-never-use-again's functions.php file.
<?php namespace Statamic\SiteHelpers; class Tags extends \Statamic\Extend\Tags{ public function foo() { // {{ site:foo }} in your templates } public function bar() { // {{ site:bar }} in your templates }}
Learn more about how to use site helpers.
We've noticed serious addon developers being frustrated by the limitation of only one "aspect" being permitted, per addon (Fieldtypes, Modifiers, etc). If you wanted your addon to have two different modifiers, you've simply been out of luck. Now you're making a pile of addons and trying to figure out how to group them all for distribution.
No more of that nonsense. Now you can simply add as many as you need.
addons/`-- Bacon/ `-- Modifiers/ |-- BaconModifier.php `-- BitsModifier.php
{{ var | bacon }}{{ var | bacon.bits }}
You can now protect pages of your site (or the whole site!) with passwords, by authentication status, or by IP addresses.
---title: My Secret Pageprotect: type: password allowed: ['secret']---The nuclear launch code is 12345.
Find out more about how to use protect your content.
There is a bunch more! Check out the changelog and enjoy!
🎉 ♥️
]]>I write what feels like the same blog post every year..." I can't believe it's been $age years already!" Well, it's true. In internet years, Statamic is a fully grown adult with mortgage payments and a 401k. Statamic can relax with a glass of single-malt scotch whiskey, teach younger softwares how to grow up and be a responsible citizen, pay taxes, treat others like you'd treat yourself, and to be sure to vote in elections.
Statamic has seen other CMSes come and go, watched the rise and fall of Angular, joined in the search-party for PHP 6, danced like nobody was watching along with Gangnam Style, and saw the birth of Condescending Wonka, the Overly Attached Girlfriend, and the Ermagerd girl. Statamic enjoyed new episodes of House and 30 Rock during the week, cried during The Office's finale, and doesn't really understand the appeal of fidget spinners (but secretly wants one).
A lot happens in 5 years. And a lot stays the same. Statamic is still fast and flexible. More-so than ever. Statamic is still way better than WordPress (it's just science). And still to this day, almost nobody can pronounce Statamic correctly.
So what's in store for the next 5 years? In short, we have no idea. We do have plans, hopes, and dreams, and maybe they'll come true. They're all dependent on you. If you still love building version-controllable, flat file websites with an intuitive control panel (and other marketing phrases), we'll be here supporting it.
We'll build the features needed to stay up to date with the modern web, keep the bugs fixed, help you become better developers, hop on calls with your clients, explain why it's better than WordPress, log into your servers and fix configuration issues (when we have time), hang out with you in Slack, meet you at conferences, record screencasts and show you neat tricks you have missed in the docs, continue to improve the design and UX of the control panel, hopefully grow our dev team, and take the weekends off to be with our families.
If you keep using Statamic to grow your business, we'll keep growing Statamic to make you more effective. It's as simple as that. That's the 5 year plan. The 10 year plan. There is no other plan, not one that matters.
We take our responsibility seriously. We're here to support you, because when you buy Statamic, it supports us. We're not looking for an exit. Are there even exits for self-hosted content management systems? I doubt it. We're just planning to continue grow this product as a sustainable, mutually beneficial business. That's the deal.
Thank you for 5 years. We hope you stay with us for many more. Keep requesting features, reporting bugs, telling other developers about Statamic, pitching it to your clients, blogging about it, tweeting your site launches, and trying to pronounce it. We'll be here with you every step of the way.
❤️
]]>Go check it out: Laravel News Podcast Episode 39.
Just an FYI, my portion of the episode is the first 27 minutes, after which they get into the news portion of the show.
]]>Partyline allows you to push to the console from OUTSIDE your Command class.
Statamic has a number of features that have a browser and command line interface, like setting configs, generating image manipulation presets, or updating your search index.
Let's use updating the search index as an example. You can trigger an index update from the control panel, by hitting a URL, or or running php please search:update. Behind the scenes we run Search::update() and the deed is done.
On the command line side we have the ability to stream output to you as code is executed. We can show messages, progress bars, and so on. However, the mere act of sending feedback to the console would require duplicating the entire method and modifying it. Not very DRY. Not very awesome.
// Console command without Partylinepublic function handle(){ $this->line('Updating the index...'); Search::update(); // ¯\_(ツ)_/¯ $this->line('Surprise! It is finished!');}
With Partyline we can bake in console output feedback right into our single Search::update() method. All Partyline code is ignored outside of the command line context.
// Our Search classclass Search { public function update() { Partyline::line('Updating the index...'); $entries = Entry::all(); $bar = Partyline::getOutput()->createProgressBar($entries->count()); foreach ($entries as $id => $entry) { $this->index->insert($id, $entry); $bar->advance(); } $bar->finish(); Partyline::line('All done!'); }}
// Console command *with* Partylineclass Command { public function handle() { Search::update(); }}
Partyline in action:

If you're a design pattern purist, you may notice this goes against the single responsibility principle. Yes, the search updater in this example probably shouldn't be responsible for creating progress bars and outputting to the console, but which is worse? A little extra easy-to-read code in one place, or core application logic duplicated in two places, begging to be diverged and broken down over time?
Weigh the pros and cons. You might just fine the tradeoff to be well worth it. We did. If you find it to be useful, awesome! We'd love to hear about it.
You can find Partyline on Github.
]]>Given the rate that new frameworks, SCSS libraries, build tools, and even programming languages are being released, how will we know if if they're worth spending time learning or evaluating? The thought alone can be overwhelming and anxiety inducing. It feels like we simply can't keep up anymore. It may even feel like you're in last place in a race, and everyone else is already celebrating. And one can only assume it's only going to get worse.
All I can do is tell you how I handle this phenomenon, especially in terms of building and growing Statamic, and perhaps you'll find value the approach and try it yourself.
Ignore them all. All of them. All of it. Everything. Every single new library and framework that comes out, just pretend it doesn't exist. Go as far as setting Twitter mute filters to avoid them. Give them space to breathe. Let things settle. Let an early adopter community form around then before you give them any of your precious time. Many of these projects are rehashes of other similar projects, internal tools being released to promote a company and attract developers, or devs trying to get their name on the map. We can't fault them for that. We're all trying to get noticed.
But here's the practical side. If what you're using now is working well for you, why would you change it? Let the time you spent learning your current stack pay you back with a return before you start over again in another arena. Given the choice between 10 years of experience in one thing, or 1 year of experience in 10 things, which do you think will make you a more efficient, profitable developer, designer, or entrepreneur?
I'm not saying ignore it forever. Just let it become a standard solution. Let people write blog posts, work through the scaling issues, try it in production, and build a company around it. Let those other people do their time in the trenches, and then when the time is right, simply walk into the established community.
I didn't spend one minute learning about Flexbox until it became a cross-browser standard, at which point I learned everything I needed to know in an afternoon, and now it's a permanent part of my front-end toolkit.
Still using Bootstrap? Don't be ashamed, just get the work done. Grunt? It still works. Don't let someone guilt you into learning Gulp or Webpack if you don't need to change it. Keep doing what you're doing. (But if you do, check out Laravel Mix, it's a much simpler wrapper around webpack)
jQuery? Hold up. It probably time to peek your head out and take a look around. jQuery has been a vital part of the web's growth, but much of its capability have been normalized into browsers. Check out http://youmightnotneedjquery.com, you may find that what you're using it for has a simple vanilla JavaScript replacement. Other frameworks like Vue.js have come along with amazing solutions to jQuery's weaknesses. If you're not taking advantage of two-way data binding, you're really making your life harder than it needs to be.
So there you have it. Ignore everything as long as you can and ask friends if you're missing out. Spend your free time with your family and go hiking or play frisbee on the beach. You're welcome.
Oh, and there is at least one exception to this strategy. If you make a living teaching people, screencasting, and blogging about the latest frameworks and libraries, you're on your own. You do need to keep up, and I wish you the best. I don't envy you.
]]>A few weeks ago I was interviewed by Lea Alcantara and Emily Lewis on the Ctrl+Click Cast podcast where I answer those very questions. I also talk new Statamic features, books, my current boardgame obsession, and other reasonably interesting things.
Check it out on ctrlclickcast.com, it's a pretty good time. They even have a full transcript in case you're audio impared, or refuse to acknowledge the proper pronunciation of "Statamic".
]]>We did it. An immovable line was drawn at the beginning of the month and we drove hard to hit that deadline. I'm really quite proud of my team.
This Monday we seeded a Release Candidate version of 2.5 to a dozen developers willing to run the upgrade process through the meat grinder. It was just what we needed and I'm grateful to them all for helping this release be as perfect as possible.
That's the big question, isn't it? The answer is: A LOT. So much so that we made a video to show off some of our favorite things.
In short (way short), Assets are better. Taxonomies are better. And neither require dealing with IDs anymore. You can simply use URLs and tags like the good old days (if you were around in the good old days of v1). The developer experience is way more productive, the control panel is way more powerful, and we have a lot of surprises in store for you.
It's our best Statamic yet.
So what are you waiting for, go checkout the changelog!
Our focus is on making Statamic a highly productive platform, perfect for agencies and dev teams. If you're in an agency looking for a CMS designed to solve your problems, I would love to chat with you! Whether you've never touched Statamic or are running 200 sites as we speak, I want to know what problems you're running into in your business. Send me an email and we can set up a time to talk.
Enjoy 2.5! 😊
]]>I am sorry to have left you hanging this long, wondering what's happening. I imagine you may feel we've been taking you for granted, or taking advantage of your patience. I also imagine you've begun to wondering if anything is even happening. I acknowledge that you've been promised this major release and that it should have been here already. I can even imagine some of you might see us as a greedy (or perhaps even lazy), small company intent on taking your money and performing the minimum amount of work possible to prevent refunds. We made promises and we didn't deliver on them.
So here I am today, to peel back the curtain and provide you an explanation and an updated timeline. But first, brace yourself. You're probably going to be upset about the release date.
In short, here's what has been happening. For 2.2 we bit off a piece of work that was larger than originally expected (our signature move), and couldn't quite finish it before it collided with the holidays, travel, and temporary time zone challenges. It was close. But close isn't enough. Last week was my first full week back after Christmas break, and as a team we're not yet back up to 100% capacity yet. I wish we were, but we're not.
This update's primary focus is on a rework of the Assets system, making it operate outside the cache. There are big performance benefits to take advantage of by doing this, not to mention that not having to interact with those IDs directly anymore will make development more enjoyable again. There are a lot of things that needed to be done to make the update seamless, from writing migration scripts to convert IDs to file paths, to rewriting all the Control Panel interactions and features to work directly with folders instead of the cache.
The cascade effect was rather massive. Ironically, this was one of the features that made 2.0 take so long to build in the first place. Lessons learned the hard way.
We were pretty close to having these pieces complete in early November before I did something that was rather foolish in hindsight, I slated a Taxonomies rework to the release as well. Their update had been slated for 2.3, but they were going to receive a similar treatment (eliminate much of the cache, removing IDs, migration scripts, logic to resolve duplicate slugs, fieldtype updates, etc), it felt right to combine them. It is The Great ID Exodus of 2016!
The update's primary focus is on Asset/Taxonomy performance and ease-of-use.
It was logical. It felt right. I knew it would have been a half-assed update without the pairing. I still feel that way, but wish we could have had one more week before the holidays threw a grenade into the schedule. And here we are, still at it. I hope we haven't lost you in the wait. It's been several months now, and if there was anything i could have done anything to speed this up, I would have. I take full responsibility for the failure, both to deliver, and to communicate.
As you are probably aware, we don't generally share timelines and release dates because they're hard to hit. I fear the failure of a missed deadline, and so we don't set them. I need to get better at that. A lot better. I owe you all a date, a new hope even, so I doing that which I fear, for you, to hold us accountable. It's not going to be this week, nor the following week. We are officially targeting the week of January 23rd. That gives us two weeks to wrap this up internally, with a few more days to test.
If you're available and interested in helping test the upgrade process at the beginning of that week, please let me know. I would be most grateful.
We are officially targeting the week of January 23rd.
Also, we are planning on calling this update 2.5. Yes, it disregards SemVer. Oh well. It represents a rather large change, and a significant shift in how things work (though the update itself will take care any necessary changes to your templates and configs). We want the version number to reflect that.
I've learned a lot over the past (almost) 5 years working on Statamic, mostly the hard way. I learned that I was arrogant, when I thought myself humble. I learned I was very busy, not productive. I shunned the expertise of others, actively choosing to not read, study, and learn from the experts on how to plan, be highly productive, and how to grow. I thought I knew better, that my experience combined with brute force, good code, and intuition would more then compensate for my lack of continual self-improvement.
I'm here to say that after a number of years in this mindset, they don't. Statamic could be a better, more coherent product, more successful, less expensive, with better support, better docs, and a larger, more educated community if I took the time to focus. To plan. To learn and grow, instead of plowing forward with the team's nose to the grindstone.
I can't go back, and I've decided I can't waste anymore energy on guilt and regret. All I can do is move forward, work on converting failures into fuel, ignorance into focus, and do what needs to be done, starting now.
I spent the bulk of my free time over the holidays reading and studying. I read a literal stack of books - the very stack I should have worked through years ago. I sat by the fireplace and read, and highlighted, and took notes. It was like a training montage, except not short, and not set to inspiration 80s music. I focused. I planned. I communicated with my team. I changed the way we're going to work as a team in 2017, not in a few small ways, but in huge, radical ways. I choose to treat this moment like a tipping point, instead of just another missed target.
I pray you stick with us as we continue this journey. I don't take you for granted. I do appreciate you. We will deliver the value you deserve and the features you need for the hard earned money you spend on supporting Statamic.
Most sincerely,
Your scrappy leader – Jack
Today marks our first "major" feature release for Statamic 2! We rolled up our sleeves pretty high and did our best to make Statamic even more enjoyable to use, with 2.1. Let's look at some of the highlights, the fruits of our 523 commits, shall we?
This is the kind of thing that isn't particular exciting at first glance. If we did our job well, most of you won't even notice anything. At first.
Statamic 2.0's content cache (called the "Stache" -- which is kinda funny because wordplay) was one giant object that contained data, indexes, and lookups for all Content Types. It made sense to structure it that way to ensure it was always up to date. Except that it wasn't very performant without other caching techniques once your site got rather large.
So we got out the scalpel and extracted numerous smaller cache objects, separate indexes, and other helpful tools from it, and married it to a brand new Eloquent-style, fluent interface to all your data.
Blah blah blah fancy words right? What does it mean? Faster sites, easier to build addons, and significantly improved internationalization. As a matter of benchmarking, sites with 2,000 Assets now load 25x faster after the initial cache warmup. Not bad.
Now in 2.1 you can now create a blog entry like this if you want:
$entry = Entry::create('hello-wilderness') ->with(['title' => 'Hello Wilderness!',]) ->date('2016-08-03') ->save();
Good things. Lots of docs on that stuff by the way. Learn all about Data Factories. Or don't, and buy Workshop and have it do all the work for you!
We workshopped with a handful of our users, looked at their control panels, publish screens, fieldset arrangements, and filtered all the feedback into an end-to-end UI/UX improving blitzkrieg-style sweep across the entire application.
Publish screens are more concise, more responsive, and really just more better. For the first time, we actually want to use them ourselves (we kinda like the files-only method to be honest).
Listing tables are more friendly, widgets are more useful (and plentiful), and fieldtypes look nicer, some with lighter weight empty states. All in all, we're very happy with the changes. We won't ever stop improving things, but this is a big step forward.
You can check out a quick video preview below!
You asked, we delivered! You can now configure Statamic to use any of the Laravel Socialite providers, or make your own with, starting with the OAuth Bridge base class.
Yeah, we're embarrassed we didn't ship with this, but it's really kind of a big deal so it made this blog post. You can now create new Taxonomy Terms right inline when publishing your content.
There are a pile of other smaller things and bug fixes that will make you smile, chuckle, or breath out a sigh of relief. They live in the changelog, and you should read every single line because we did it all for you and it would be a little rude not to.
So go check it out! Statamic 2.1! It's a thing. One click update yo'self.
We have a new addon coming out in the next few days called Workshop. It gives you the ability to create and edit content, from Entries to Taxonomies to Globals, right on the front-end of your site. No need for Users to touch the control panel. It's like Raven from v1, but a lot better. We were gonna call it CRUD, but that sounded messy. Workshop is classy. It's shipping as soon as we can finish designing the product page for it. We wanted to release it at the same time but, why hold up 2.1 any longer, right?
Also, we were at Laracon last week. It was a lot of fun getting to meet some of you. I spoke. It went pretty well.
]]>Great! But wait...once you start building your own bespoke website, you find yourself spending precious time that could be spent napping in the sun, deleting, renaming, and messing around with unnecessary files. Unacceptable.
Well, never again. Now in v2.0.3 you can run a single command and have your site wiped clean so you can be up and running in just a few seconds. Watch it in action.
]]>To say this was a significant undertaking would be an understatement. I could write a book (and maybe will) about everything Jason and I have learned by rebuilding a product from the ground up, but this is neither the time and the place. This is a day for celebration and much merryment! 🎉
Statamic 2 took a year of hard work, sweat, and whiskey tears, 4,000 commits, 200 beta testers, and 43 alpha/beta releases.
We love you all. We built this for you and we sincerely hope you like it.
You probably would never make it to the bottom of this blog post if we listed everything here, so I'll just give you a few of the high points and then recommend you jump over to the Features section to see even more details.
PHP developers rejoice! Addons can take advantage of all its built in features and any 3rd party composer packages you want to bring in as dependencies. We use Laravel's validation, caching system, Flysystem for file drivers - which means you can now mount Assets, Content, Users, or other areas on Amazon S3 or any other supported location -- and lots more.
With 100x more capabilities than v1's, you are no longer limited to simply editing content and adding entries. It leverages the amazing Vue.js library to power fieldtypes, live preview, drag and drop reordering, and a pile of other useful and neat features. We even took the effort to properly theme Bootstrap to make extending it simple and familiar for developers.
We even had 31Three dive in with UI concepts that got the ball rolling. Those guys are awesome.
Where v1 had Pages and Entries, Statamic 2 extends those features (like customized fieldsets, relationships, and so on) to Taxonomies, Assets, Users, and Globals. Your photos and files can now have their own custom fields and data that you can use and reuse anywhere in your site. We think it's pretty cool. You probably will too.
You are no longer limited to building your content through file and folder hierarchy. Collections of entries now have their own routes, letting you create whatever URL pattern you'd like. Fancy a WordPress style for legacy purposes? No problem.
collections: blog: /blog/{year}/{month}/{day}/{slug}
Not only did we make our template language a lot more powerful with a more flexible syntax and roughly a hundred new modifiers, we've also added support for Laravel Blade.
Multilingual capabilities are built right in. By configuring additional locales, content becomes translatable with the flick of a switch. Each language can run on its own URL, so you can have example.com and example.com/de or fr.example.com, or example.de. Lots of control. Lots of options.
The features that Raven and Bloodhound provided as addons are now part of the core Statamic experience. We felt that Statamic 2 should be able to deliver the features needed for 85% of the normal sites out there.
I could go on forever on features. We'll be showcasing things you can do now with screencasts, blog posts, and articles, but we must get to the end of this post eventually so you can you know, go buy it. Right? Onwards!
Aside from a new site, new features, new docs, and all that...
You will certainly have noticed a new website by now. In fact, all of our various websites have been completely redesigned. And for the first time ever, all share the same brand experience letting you use a single account!
Honestly that shouldn't be a big deal in today's world, but it is to us. It took a lot of work. You'll notice everything now shares a very minimal UI. You might even think too minimal for our brand. And while you might be right, we had a ton of content and features, between the site, docs, forums, user account, and store/checkout experience to consolidate, and going as minimal as possible was the best way to get to the finish line. Expect fun updates over the coming months. We needed to ship this thing!
The Lodge had a lot of different rooms to have different types of conversation in. Inside those rooms you could make all different types of posts. It was kind of confusing to be honest. It may have even prevented people from using it. So we stripped it down to 3 areas:
We hope that between the redesign and the simplified experience we can give revive the Lodge to its former (pre-Slack) glory. It will also be the source of our "Official Support", so keep that in mind.
This is important! If you've purchased any v1 licenses, you'll need to migrate your old account data to your universal Statamic account. If you joined the Lodge, you already have one - it's the same platform.
Create an account or sign in to you current one and head to https://account.statamic.com/migrate. There we'll walk you through the 3 step process. It should take about 2 minutes. We tried to come up with a solution that didn't take an action on your part, but there just wasn't one. It's a security thing. Thanks in advance for being so understanding.
You can upgrade your Pro v1 licenses for $99 and Personal for $169. Statamic 2 is a single license for a single price, hence the difference. As for how to upgrade, head over to the Upgrade Guide.
The v1 docs are still available and you can still download and use v1, Raven, and Bloodhound from your account (purchasing a v2 license gives you the option of using v1 or v2 - for those that may need that for legacy purposes).
While we head off to work on 2.0.1 you should Buy Statamic 2 and go build something awesome, please! Read the docs. Tell your friends. Let us know what you think. Or hey, go hiking! It's springtime and the crocuses are in bloom.
]]>