I was always curious about CraftCMS because it's built with Yii 2 instead of any other popular PHP framework. Sadly I never had the chance to look into it.
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.
Yeah we’re starting to investigate which route we’ll take (Yii 3, Laravel, or Symfony).
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.
Craft CMS follows an interesting business model: a self-host product which is purchased with the source code of the product i.e. 'source only'. It's not open-source - the source code of the product cannot be shared or distributed by others, but it can be modified by the customer to suit their needs.
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.
I know is more complicated than that but wasn't that how Stallman envision it? Free as in Freedom and not financially. By the way, I remember those Delphi days with UI widgets.
It is an interesting model. Does anybody knows how to handle the annual license renewal?
You mean in general, or how Craft does it? You set up an account with them, and buy as many licenses as you need. Furthermore, you also don't have to buy a license each year, you just won't get updates. The renewal fee stays the same, even if you pause it for a few years. See: "How Craft Licenses and Renewals Work" [1]
Source only / source available / dual licensing and so on is a common model for web development components and libraries. Some from the top of my head are tailwindui, mui, mapplic, flickity, many plugins for Wordpress and other plattform-like things and there are several additional CMS solutions, typically PHP based, that do this.
I tried Craft as an alternative to Wordpress-- couldnt even get it installed. The instructions assume you have a whole PHP dev environment setup-- very frustrating, after some time googling the various errors I kept hitting I just quit.
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
I'm not trying to sound harsh, but in that case, Craft CMS is probably not the right Wordpress alternative for you. Craft's philosophy is to give you the tool you need and make no assumptions about how you want to build your site. That means, there are no themes nor sites or blog posts by default. You have to set up your site's structure, the content fields yourself and then write the templates using TWIG. This is a CMS to be setup by developers.
> The instructions assume you have a whole PHP dev environment setup
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).
dev environment is the key word I assume. Wordpress is "upload to PHP-enabled webspace and run", many more modern things expect that you install them using composer etc pp and then deploy from there. (no clue if that's true of Craft or not, never used it)
> The instructions assume you have a whole PHP dev environment setup-- very frustrating, after some time googling the various errors I kept hitting I just quit.
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.
Raise your hands if you were an early user of ExpressionEngine or Textpattern — CMSs that weren't skewed into CRMs, Shops or PWAs. Good times, but then WP ate them all.
WP is completely unwork-able for me. I am not smart enough to deal with that codebase. 1-click install is great but the nightmare on the other side of the easy setup is just not something I can deal with.
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.
I would add to that list, that I can easily get by with zero plugins on a Craft install, it's impossible for me to do that on Wordpress. The over-reliance on Wordpress plugins and their often terrible security is my nightmare.
Textpattern was awesome and I loved the look of the admin interface and the default theme back in... probably 2003? (Wikipedia seems to agree) but I didn't get along well with Textile and so I went with serendipity[1] and also contributed a bit. (Although my timeline could be a little off here, but I did start that blog in late 2004.)
After fighting Headless CMS solutions for years I ended up with using Craft in headless mode with GraphQL. It solves pretty much everything a web CMS should do and I'm able to use modern frontends like Next.js. It's the ultimate no-code solution, and you don't need to touch PHP unless you want to create a plugin.
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.
Is there any guide (online) that you followed for this CraftCMS-GraphQL-Next.js architecture? I'm intrigued and would appreciate being referred to some source material, if any is available.
What do you use as your 'head', if you don't use CraftCMS's? Are you using something you create with Next.js?
I have been using Craft to run my newsletter, Tedium (https://tedium.co), since the start of 2019. I moved from Ghost, which at the time was not really designed for newsletters at all. I find Craft an amazing tool when I want to add new things—a big difference from Ghost, where everything is just kind of set for you and you have to rely on external integrations to expand functionality. I custom-code my emails and integrate design directly into the email, so that eventually became a nonstarter for me.
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.
I keep it minimal. I use Email Octopus, essentially as a front end to Amazon SES. I’ve used them since 2016 when it was literally two guys running the service.
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 was working at EllisLab on ExpressionEngine when Craft was first released. I don't know what things were like over at P&T, but it was interesting to witness from inside EllisLab. I would say Craft v ExpressionEngine is a case study in what happens when you don't pay your techdebt. Even if you have a lot of good ideas, if you don't stay on top of your techdebt, someone can always come, start fresh, cherry pick and build on/expand the best of your ideas (leaving you to deal with your bad ones), and quickly surpass you.
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.
Interesting scoop from the other side—thanks Daniel!
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 :)
Cheers, Brandon! I figured, since EL is long gone at this point, there was no harm in offering my postmortem perspective on what happened there.
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.
Hey Daniel, I remember that strong voice. You definitely had the right architectural instincts, basing everything on singletons in CodeIgniter was not great, plus all the other countless mixing of separate concerns, definitely made some things difficult. From my perspective, the whole lack of progress was not prioritizing the right things in the right way, i.e. there should have been an intense focus on delivering iterative value quickly, but the right value, like things the market wanted and that would actually make a difference in decisions about whether or not to choose another solution. I think we could have managed that even with the tech debt. My current project also has a lot of tech debt (some worse than EE), but we're still able to grow the business and are currently on a trajectory to become the market leader because we're still able to get the right value out quickly (well that plus good marketing, sales, etc). That's not to say we're just piling on more debt, we try to leave things better than we find it, new code is specifically designed for easy maintainability and extendability, and we still take time to invest (but not 2 years). But to me it says maybe we can have both, but it's all about priorities and trade-offs, and we just spent too much time on the wrong stuff.
Hey Kevin! Yeah, one of the things I've learned with age (and am still working on, probably a lifelong project) is tempering that voice.
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!
> My memory is that we didn't really know what those things might be and had no real way to find them out.
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.
Hey @brandonkelly, would Craft CMS be a practical foundation for a catalog of millions of "things", each of which contains anywhere from tens to hundreds of things? I'm thinking of a use case that I've been assuming would require an application-specific CMS, and now I'm wondering if Craft CMS might be an option.
I can't answer this specifically, but the consensus in the community is, that if your server can handle the database and requests, then Craft won't have a problem handling it.
> 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]
42 comments
[ 3.3 ms ] story [ 92.4 ms ] threadLast 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.
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...
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.
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.
https://textpattern.com/weblog/memories-of-dean-allen
I still am! We're a bit of an endangered species but we're making good progress:
https://github.com/textpattern/textpattern/
https://github.com/textpattern/textpattern/issues
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
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?
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.
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.
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...