That's the beginning of unit, acceptance, & integration testing about to hit core.
Open source doesn't mean nattering about UI features in the forum, it means jumping into the GitHub source and contributing. So, if you want to participate...
@vrijvlinder, 3 of our last 4 hires have been women so we're doing better!
Speaking of which, I've made a terrible omission.
I'd like to welcome @beckyvb, who was just hired as a full-time frontend developer! She interned with us for the summer and is here to stay. She also got a .org account while I was in town so now I can mention her
You're seeing the groundwork for what a fully API-driven 3.x looks like as it gets slowly built - with full testing suite built alongside it.
That is really informative! So if you are re-building Garden, I guess you'll built Vanilla on that framework one day. I bet you have spoken about using an existing framework as a beginning - since Slim is mentioned as an inspiration for Garden, it might have been one hypothetical alternative fundament for a new Vanilla main version. Could you give some insight, why you are not using one of the existing frameworks (personally I'm a fan of elefantcms?
@R_J said:
Could you give some insight, why you are not using one of the existing frameworks?
The framework will be the new foundation of our business. Just as you won't see Facebook or Google using Laravel, nor are we going to use something off the shelf. We need absolute control over it. And, this is still what open source is fundamentally all about: sharing ideas.
Is it a completely new framework or will the "new garden" be mostly backward compatible?
I realize it is far-off in the future, but I'm always kind of worried when software projects anounce a full rewrite.
Is there something fundametally wrong with the current garden framework?
@Bleistivt said:
Is there something fundametally wrong with the current garden framework?
Yes, there's quite a few problems. I'll try to get @Todd to talk about some of the big-picture stuff that is getting rectified sometime soon. Basically: after 5 years of lessons learned, we realize it's easier to rebuild the framework and transplant Vanilla onto it slowly than to try and refactor it in-place.
I think I'd say the primary goal is to use an API-first mindset, which is a different world than our current framework. It isn't a reboot so much as an iteration.
@Bleistivt said:
I'm always kind of worried when software projects anounce a full rewrite.
Remember that we build Vanilla scaffolded on top of the framework, so this isn't an all-in-1 shot; we're going to let the new framework & our existing code meet in the middle. As we build the new framework, we're also working on test coverage for the current product. When the new framework is mature and we feel like the current product can be moved without breaking our tests, we're going to start moving to the new framework and refactoring.
A key point is that our "breaks" will be easily resolved (example: convert your plugin's 'about' array to JSON, which we will help with) not the insane full break we did from 1.x to 2.x. Another key point is that the product isn't being stopped & restarted. We're building towards a gradual framework hand-off instead.
tl;dr: This is a long transition not a reboot. Our current codebase isn't being left behind, so don't think the work we're doing now is somehow doomed. 90% of the work we do has precious little to do with the framework anyway.
A good analogy would be doing a major Rails upgrade. It doesn't mean you're starting your Ruby app over from scratch, it just means you gotta do a lot of work to make it compatible again. And test the hell out of it!
Comments
If you want to see something far off on the roadmap, pay closer attention to our other repositories.
You're seeing the groundwork for what a fully API-driven 3.x looks like as it gets slowly built - with full testing suite built alongside it.
Or, keep an eye even just on core's branches & pull requests: https://github.com/vanilla/vanilla/blob/feature/codeception/tests/README.md
That's the beginning of unit, acceptance, & integration testing about to hit core.
Open source doesn't mean nattering about UI features in the forum, it means jumping into the GitHub source and contributing. So, if you want to participate...
Get in there!
@vrijvlinder, 3 of our last 4 hires have been women so we're doing better!
Speaking of which, I've made a terrible omission.
I'd like to welcome @beckyvb, who was just hired as a full-time frontend developer! She interned with us for the summer and is here to stay. She also got a .org account while I was in town so now I can mention her
That is really informative! So if you are re-building Garden, I guess you'll built Vanilla on that framework one day. I bet you have spoken about using an existing framework as a beginning - since Slim is mentioned as an inspiration for Garden, it might have been one hypothetical alternative fundament for a new Vanilla main version. Could you give some insight, why you are not using one of the existing frameworks (personally I'm a fan of elefantcms?
Welcome home @beckyvb !!!
❌ ✊ ♥. ¸. ••. ¸♥¸. ••. ¸♥ ✊ ❌
The framework will be the new foundation of our business. Just as you won't see Facebook or Google using Laravel, nor are we going to use something off the shelf. We need absolute control over it. And, this is still what open source is fundamentally all about: sharing ideas.
Is it a completely new framework or will the "new garden" be mostly backward compatible?
I realize it is far-off in the future, but I'm always kind of worried when software projects anounce a full rewrite.
Is there something fundametally wrong with the current garden framework?
My themes: pure | minusbaseline - My plugins: CSSedit | HTMLedit | InfiniteScroll | BirthdayModule | [all] - PM me about customizations
VanillaSkins.com - Plugins, Themes and Graphics for Vanillaforums OS
Yes, there's quite a few problems. I'll try to get @Todd to talk about some of the big-picture stuff that is getting rectified sometime soon. Basically: after 5 years of lessons learned, we realize it's easier to rebuild the framework and transplant Vanilla onto it slowly than to try and refactor it in-place.
I think I'd say the primary goal is to use an API-first mindset, which is a different world than our current framework. It isn't a reboot so much as an iteration.
Remember that we build Vanilla scaffolded on top of the framework, so this isn't an all-in-1 shot; we're going to let the new framework & our existing code meet in the middle. As we build the new framework, we're also working on test coverage for the current product. When the new framework is mature and we feel like the current product can be moved without breaking our tests, we're going to start moving to the new framework and refactoring.
A key point is that our "breaks" will be easily resolved (example: convert your plugin's 'about' array to JSON, which we will help with) not the insane full break we did from 1.x to 2.x. Another key point is that the product isn't being stopped & restarted. We're building towards a gradual framework hand-off instead.
tl;dr: This is a long transition not a reboot. Our current codebase isn't being left behind, so don't think the work we're doing now is somehow doomed. 90% of the work we do has precious little to do with the framework anyway.
A good analogy would be doing a major Rails upgrade. It doesn't mean you're starting your Ruby app over from scratch, it just means you gotta do a lot of work to make it compatible again. And test the hell out of it!
Both of these things sound awesome!
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
Especially testing, which is something I've been looking for.
My shop | About Me
You will be happy to know we've made the decision to incrementally refactor our existing framework instead.
As Al Murray says "Common Sense".
grep is your friend.