Craft CMS 4 Released
craftcms.com
craftcms.com
The source code is published on GitHub so anyone can see it. Presumably the product creators trust customers will pay for the product (if some do not, it probably doesn't matter to profitability). Another profitable PHP product called 'Kirby CMS' also follows this model.
The idea of 'source only' is not new at all. Back in the late 90s when Delphi was popular, many developers created and sold components to other developers (e.g. UI widgets). These components came with full source code of the components but they were not open source.
The label 'source only' is considered a dirty word among some open source advocates. But if you are building a B2B (Business-to-Business) software product, 'source only' is a viable option to successfully make a living from your product - one that isn't completely closed source.
(As an aside, here's the Craft CMS licence: https://github.com/craftcms/cms/blob/develop/LICENSE.md)
It is an interesting model. Does anybody knows how to handle the annual license renewal?
[1] https://craftcms.com/knowledge-base/how-craft-licenses-and-r...
Just as an example, I handle sponsorships by creating a category and adding it to my workflow. My email templates are designed using MJML—and I can create secondary views that allow me to view the completed template and copy the raw code of the email into the newsletter platform of my choice. (I could even run the newsletter soup to nuts via plugins, though I prefer to pay someone for that right for support reasons.)
The plugin ecosystem is relatively strong, but I will point out that some of the plugins are paid—and at least one has gone commercial after previously being open-source.
I did a lot of research into CMS platforms (static site, monolithic, flat file, and so on) that I felt could get me to this point where I could have a CMS that simplified the production process of building a twice-weekly email, and Craft got me closest.
So I’m happy to see Craft continue to evolve. It’s a great tool and I recommend it highly.
For my needs I want something I can literally paste completed template code into that will not get in my way and will have decent deliverability. Email Octopus does a decent job on that front.
I will say that I use hosted forms, though I had a bad support experience with my provider there, MailMunch, so I’m thinking of switching to someone else.
I also like how I can host it myself locally and on the server of my choice. Throw it on a Hetzner cloud instance and get 20 000GB bandwidth each month and unlimited requests. Store the assets on S3 with Cloudfront, without any third plugins, and pay pennies. Invite as many users you want with no extra cost. Having the ability to watch the logs is also a huge benefit over Headless SaaS CMSes. No more request spikes without knowing what I did wrong.
What do you use as your 'head', if you don't use CraftCMS's? Are you using something you create with Next.js?
I hadn't looked at Textpattern in a long-time, so I went searching, only to discover Dean Allen had passed away (https://om.co/2018/01/18/dean-allen-rest-in-peace/). I'm glad the software lives on.
I still am! We're a bit of an endangered species but we're making good progress:
Compromised, incompatible with each other plugins, the legacy blogging engine architecture, the horrible admin UX, the need for additional solutions to have any kind of sane CMS functionality.
[1]: https://s9y.org
This has been my issue with most Wordpress alternatives-- they assume you are a professional PHP developer, rather than someone who just wants to try a CMS. And then everyone complains whY dO yOu uSE wordPResS iT is hOrriBle
How else would you expect to run a PHP-based application? WordPress also requires a PHP environment and database.
I wouldn't argue against Craft being more difficult to install than WordPress but I also wouldn't describe it as difficult (I'm a FE dev, no PHP wizard).
And I don't recall Craft every being marketed as a WordPress alternative - it's always been a "CMS for developers" (I think this may have been a tagline on their homepage at one point).
You do need to embrace Composer, though, which is kind of a key element to how it works/is managed.
There are also some Craft-specific hosts, like Fortrabbit (disclosure: Fortrabbit user) that can take the guesswork out of managing Craft pushes.
Sorry you had trouble. Craft definitely has stricter requirements than WP. v4 requires PHP 8, a handful of PHP extensions, and MySQL 5.7.8+/MariaDB 10.2.7+/PostgreSQL 10.0+.
Most modern local dev environments will have everything it needs – DDEV (https://ddev.com/), Lando (https://lando.dev/), our own Craft Nitro (https://getnitro.sh/), even MAMP, etc. –, but I realize these come with a learning curve. We do our best to ease you into it without making too many assumptions in our tutorial, so you might want to try giving it another go with that: https://craftcms.com/docs/getting-started-tutorial/
If you’re a Mac user, you’re going to need to start moving in this direction even to get WordPress running, as built-in PHP support has been deprecated and Apple plans to stop shipping it in future versions of macOS.
> This has been my issue with most Wordpress alternatives-- they assume you are a professional PHP developer, rather than someone who just wants to try a CMS
No argument there. WP is built for the masses; Craft is a developer tool. It doesn’t assume PHP knowledge (the built-in templating system is powered by Twig), but you will need a strong understanding of web standards and basic logical concepts. Or you can get your content out using the built-in GraphQL API, to hook it into a decoupled front-end like Next.js or Gatsby.
ExpressionEngine had a lot of great ideas in it, but its code was an absolute a mess, and its leaders had no understanding of the concept of technical debt. They just kept racking it up until, by the time I joined in 2012, any changes were expected to take months because the code was a nest of interdependent singletons. While I was there, we spent a lot of time basically responding to the moves of P&T.
If you weren't part of the ExpressionEngine community, then you might not know that P&T started out making paid add-ons for ExpressionEngine. I might be misremembering, but I think relationships and matrix were their main ones. One of the first projects I was given as a new engineer at EllisLab was essentially making an native relationship field for ExpressionEngine in response to P&T. If I remember correctly, we knew Craft was coming and were trying to undercut P&T even though they were one of EL's most popular plugin makers.
We ended up taking on a rewrite for EE3, because the techdebt was that bad and refactoring wouldn't have got us where we needed to go in time. In retrospect, I'm not sure if that was the right choice, even though I was one of the strongest voices in EL arguing for it at the time. I definitely thought it was the right choice at the time, but I was also a really inexperienced engineer. I don't know if there were any right choices though. Thinking back, I have a hard time imagining a path forward that didn't involve some level of rewrite. It's one of those experiences you can go round and round in your head about wondering whether you did/argued for the right things. In the end, I think EL's fate was already sealed by how much techdebt they'd racked up.
The rewrite took a solid two years, Craft was released first, and was better than EE2 in every way (and EE3 if you ask me), and thus began the death spiral. EllisLab is no more (though the rewritten ExpressionEngine lives on as an open source project maintained by one of the agencies that used it), and Craft is clearly still around.
From the outside, there were some weird vibes coming out of EL back then – they’d taken a bit of an adversarial tone with the community, which had us wondering whether it was a good idea to have all our eggs in the EE basket. Then an EL designer publicly ranted about P&T, calling us a “direct competitor”, on the EE Podcast, when Craft was just a twinkle in our eye. Which ironically, was the exact moment we decided to really commit to building a CMS. Self-fulfilling rant I guess :)
That podcast was either before my time or maybe just when I was starting, but yeah, that was definitely the mentality when I was there. There was also a bit of a siege mentality. My onboarding involved being instructed to join twitter, but warned that the community would be mean to me. Thing was, I found most of the criticism coming from the community to be warranted and valid and thought we should have been listening to it, instead of writing it off as a loud, mean, disgruntled, few.
Either way, you guys did a great job with Craft!
My memory is that we didn't really know what those things might be and had no real way to find them out. But I could easily be misremembering.
It's one of the things I really appreciate about my current role - we have sales, marketing, product, and design functions responsible for figuring out what to build (which we offer input into), but largely, in engineering, we can trust they're doing a good job and just figure out how to build it. We definitely still have our techdebt, but we manage it very intentionally - where that sometimes means intentionally leaving it in place and adding to the ball of duct tape because we can't unwind it now. But it's never reached the point of becoming systematic. Our worst techdebt is tucked into corners where the unintended consequences caused by touching it can't reach too far.
I feel like it's a really good balance, take on techdebt intentionally, don't let it get systematic, and pay it off intentionally when you can.
With EllisLab, a more piecemeal approach very well may have been the right one. How do you think we should have approached it? EE was so tightly coupled through those singletons at the time - maybe singleton wrappers around subsystems, taking one at a time as features touched them? What features do you think we should have focused on? I'd be really interested in hearing more of your perspective on EllisLab before and post Craft. You lasted a lot longer than I did and probably have a lot more insight and thoughts!
Haha yeah this is basically what happened. I don't want to get too far into the weeds on a public forum, but in general, the suggestion of market research was initially met with resistance. I think they came around to the idea eventually but it was too late.
> I feel like it's a really good balance, take on techdebt intentionally, don't let it get systematic, and pay it off intentionally when you can.
That's a great summary. Stop the systems that create the debt by learning to separate concerns or discouraging other anti-patterns, and only take out debt if the trade-offs make sense and hopefully have a plan to pay it off.
> With EllisLab, a more piecemeal approach very well may have been the right one. How do you think we should have approached it?
I think were going in the right direction with the Relationships parser and later the new conditionals parser, they were very object-oriented and easily testable, and weren't too coupled with persistence or presentation concerns like the typical patterns of just putting everything in a library or controller, but not all of us were skilled enough to keep doing that. I feel like later on we naturally started using patterns like you see in Working Effectively with Legacy Code in order to keep newer code testable and easier to maintain, and then plugging those things into legacy where they were needed. These days, my bias is to fit things into Hexagonal Architecture so if it were me now, I would try to decompose the various major areas into loosely-coupled modules bound by well-defined interfaces, and the internals of those modules would be highly cohesive. You can kind of work towards this piecemeal as you work on various features but there's an awkward in between phase that can last for years on complex domains.
> EE was so tightly coupled through those singletons at the time - maybe singleton wrappers around subsystems, taking one at a time as features touched them?
Yeah maybe, we eventually made a solution for the `$db` singleton by making it so you could just ask for a new instance every time, that way no other code could mess with your in-progress query-building. I'd bet most of the classes that were singletons didn't have to be that way and we could just make new instances when we needed them. They were probably only singletons because it was convenient access and looked magic in CodeIgniter, and most of us were so green that we didn't know better.
> What features do you think we should have focused on?
Probably the things people asked for for years that Craft launched with and Packet Tide is now adding. We did come around to things like Live Preview and Fluid fields there towards the end but like I mentioned earlier, at a certain point it was too late. The market had gotten away from us and the community was fractured.
> I'd be really interested in hearing more of your perspective on EllisLab before and post Craft. You lasted a lot longer than I did and probably have a lot more insight and thoughts!
Sure feel free to reach out on Facebook if you want, I think we're still connected here. Yes I was there for too long.
Last thing I heard it they were looking to migrate the codebase to Laravel as Yii 2 is no longer up to date and Yii 3 is far from being complete and production-ready.
Congratulations on the release.
These days everything is so componentized it’s becoming less and less important, though. Craft has always pulled in a various Symfony components, and v4 adds Laravel Collections.
Have been using it for over 5 years, on multiple sites.
Clean architecture, excellent documentation, good support.
Highly recommended.
What's a "large site", and what would be your go-to for that?
> There are Craft CMS and Craft Commerce sites in the wild running smoothly with tens of millions of elements, and we’ve seen smaller sites struggle to keep up with modest amounts of traffic. The answer is usually “yes, Craft can handle that,” but you should take care with a few things that maximize your site’s ability to handle a growing body of content [1]
[1] https://craftcms.com/knowledge-base/how-much-content-can-a-c...