It would be a wise marketting move to have some sort of slogan or branding of Backdrop CMS as being Drupal Classic. With that said, given the long term success of Drupal 7 having penetrated 1 million plus installs and still around 500,000 installs 12 years later, I would think that forking Drupal 7 as-is and backporting the look and feel of Backdrop into Drupal 7 Fork Classic , leveraging nearly or possibly ALL of Drupal 7 contrib would seem like a very logical way to go.
There's some very strong developers in the Backdrop CMS project that have dedicated years to the project , I realize that it would be difficult to convince these members of the idea of Forking Drupal 7 and porting some of the Backdrop CMS look and feel and functionality to it while maintaining a high degree of drop-in compatibility.
I guess what I'm looking for is a way to unify Backdrop CMS with Drupal 7 in a compatible way to harness a super easy drop in replacement upgrade path for Acquias Drupal 7 core.
I have a script that managed to clone over 42000 repositories linked to Drupal.org , however so much intelligence of Drupal is in the actual drupal.org site, it would pretty much be necessary to clone that as well and fork it with all the comments and patch files.
Maybe talking into the wind here but I think many will see what I'm saying and understand it.
Dries seems bound and determined to end Drupal classic so I think the only option is to fork and clone. The way way back machine probably not powerful enough to store drupal.org so we'd have to probably find some way to keep that intelligence before they break it.
This might be a crazy idea and/or impossible. BUT...
It's my understanding that there is legacy code from Drupal 7 that is still in Backdrop but not necessarily exposed or required for new Backdrop sites. That some Drupal 7 things that are not officially supported for Backdrop, will work if folks know how to access them.
Would it be possible to provide alternative upgrade paths for some Drupal 7 sites that making upgrading easier, but doesn't provide all of the new features for Backdrop - and that sites have a way of doing a minimal upgrade with the hope that we might be able to provide easiser upgrade paths for other Backdrop features in the future.
I'm thinking about a world in which a Drupal 7 site is able to upgrade to Backdrop, but bypass the layout system and use their Drupal 7 theme on a temporary basis. Would they be able to get some basic Backdrop features, but not have access to the ones that make upgrading more complicated for them?
It has been argued quite persuasively to me, that the term 'recipes' implies a list of instructions on how to do something. In Drupal land there is a recipe initiative which centers around a collection of "best practices" and or tested instructions on how to acheive specific goals.
Is our use of "recipes" confusing? Is there a better term?
Personally, I think that this concept is still new enough that we could change the terminology with little cost (and potentially an improved understanding of what we intend).
In Drupal 7 these were "features," but the term features has a very specific meaning to former Drupal 7 users and we think it would be confusing to use it for this purpose in Backdrop land.
Many of my D7 modules rely on adding controls to existing settings pages, and looking to porting to Backdrop CMS I wonder what the strategy is for doing this sort of thing without the page array.
I was once told by a Drupal colleague that he wasn't sure how seriously to take Backdrop until he saw businesses and developers that were dependent upon it's success for their livelihood.
We already have a number of developers in our community that make significant portions of their income working with Backdrop. But, in my view we need to see more Backdrop based businesses promoting Backdrop and helping to build it's infrastructure.
Triplo has been working on a SASS idea based upon Backdrop CMS - https://simplo.site/
I'd like feedback on Simplo.site as a product AND as importantly, where it fits in the Backdrop community. I'd also like to hear more about how others are making a living by working with Backdrop and how we better support the Backdrop business community.
My team still uses SASS on all our big Drupal client projects. I used to love the Zen theme for Drupal 7, because it came with config files and instructions for SASS tools, first Compass and then Gulp.
When I use SASS I still use Gulp. I've done some Drupal Camp presentations on how to set up and customize Gulp in a Drupal 7 theme, based largely on this excellent blog post: https://chenhuijing.com/blog/drupal-101-theming-with-gulp/
I would not recommend using Gulp and SASS for anyone that is only theming a single site. But, if you plan to theme a bunch of sites, you might find it useful. It does add complexity to a site and I've spoken to some prolific and talented front end developers that prefer to work in straight CSS.
I think it might be helpful if we had better starter themes for Backdrop that include an optional SASS starter kit.
I'm interested to learn something about the mechanics behind: How user settings are working? Why a registered user can't be deleted? Where is a possibility to solve this?
How could I carry a group membership to a user (enter a group), set automatically the group membership for content, while carrying this membership (content autotag) and how could I release it (leaving a group)?
How could I display all group content or group members, just while carrying the membership info?
Please realize, that this is different than to register to a group for membership.
My idea:
To enter a group, should go trough a gateway or link on the groups main page (the group itself). The membership to a group is already required to be allowed to enter this group. The state is carried like a flag (entered or not). A view should be able to act as a group menu.
If you're new to Backdrop, come in for a discussion on how Backdrop can be the best option for creating your new website. As we all know, WordPress has been the goto for new sites and it has a large user base. But if you plan to do anything other than a basic site of a few pages and a blog, WordPress can require custom code for most things that are even a little bit off the beaten path.
Backdrop allows users to create custom views easily and to create pages that draw from databases, and it doesn't require custom code. You may not need this now, but it's good to have this power in the future.
Backdrop is built on expanded Drupal 7 code. Drupal 7 still powers over 50% of Drupal sites, but it is coming up on End of Life, not immediately, but the modules may not receive updating even though Drupal 7 does for a while yet.
It's time for both new users and Drupal 7 users to step up to a powerful CMS built on proven code.
Here is a link to the collaborative notes we took:
https://docs.google.com/document/d/1a5iim2C4KkAM69chh-53ogfiqL1z5qcUfPRa...
Here is the blog post I wrote immediately after this discussion:
https://www.triplo.co/blog/drupal-and-backdrop-cms-opportunities-collabo...
I missed this conversation last time -- did anyone take notes?
It would be a wise marketting move to have some sort of slogan or branding of Backdrop CMS as being Drupal Classic. With that said, given the long term success of Drupal 7 having penetrated 1 million plus installs and still around 500,000 installs 12 years later, I would think that forking Drupal 7 as-is and backporting the look and feel of Backdrop into Drupal 7 Fork Classic , leveraging nearly or possibly ALL of Drupal 7 contrib would seem like a very logical way to go.
There's some very strong developers in the Backdrop CMS project that have dedicated years to the project , I realize that it would be difficult to convince these members of the idea of Forking Drupal 7 and porting some of the Backdrop CMS look and feel and functionality to it while maintaining a high degree of drop-in compatibility.
I guess what I'm looking for is a way to unify Backdrop CMS with Drupal 7 in a compatible way to harness a super easy drop in replacement upgrade path for Acquias Drupal 7 core.
I have a script that managed to clone over 42000 repositories linked to Drupal.org , however so much intelligence of Drupal is in the actual drupal.org site, it would pretty much be necessary to clone that as well and fork it with all the comments and patch files.
Maybe talking into the wind here but I think many will see what I'm saying and understand it.
Dries seems bound and determined to end Drupal classic so I think the only option is to fork and clone. The way way back machine probably not powerful enough to store drupal.org so we'd have to probably find some way to keep that intelligence before they break it.
This might be a crazy idea and/or impossible. BUT...
It's my understanding that there is legacy code from Drupal 7 that is still in Backdrop but not necessarily exposed or required for new Backdrop sites. That some Drupal 7 things that are not officially supported for Backdrop, will work if folks know how to access them.
Would it be possible to provide alternative upgrade paths for some Drupal 7 sites that making upgrading easier, but doesn't provide all of the new features for Backdrop - and that sites have a way of doing a minimal upgrade with the hope that we might be able to provide easiser upgrade paths for other Backdrop features in the future.
I'm thinking about a world in which a Drupal 7 site is able to upgrade to Backdrop, but bypass the layout system and use their Drupal 7 theme on a temporary basis. Would they be able to get some basic Backdrop features, but not have access to the ones that make upgrading more complicated for them?
Just a crazy idea...
It has been argued quite persuasively to me, that the term 'recipes' implies a list of instructions on how to do something. In Drupal land there is a recipe initiative which centers around a collection of "best practices" and or tested instructions on how to acheive specific goals.
https://foxvalleydrupal.org/article/announcing-drupal-recipes
Is our use of "recipes" confusing? Is there a better term?
Personally, I think that this concept is still new enough that we could change the terminology with little cost (and potentially an improved understanding of what we intend).
In Drupal 7 these were "features," but the term features has a very specific meaning to former Drupal 7 users and we think it would be confusing to use it for this purpose in Backdrop land.
Are there potential core features that have been blocked by the lack of references in core in the past?
What kinds of features have been added to Drupal 8/9/10 that are related to references (if any)?
Not sure where to put this...
Many of my D7 modules rely on adding controls to existing settings pages, and looking to porting to Backdrop CMS I wonder what the strategy is for doing this sort of thing without the page array.
I need to port a D7 site that makes heavy use of
I have no experience with Backdrop yet, and I'm trying to estimate the required effort...
This is really cool! We are so happy to have the folks at Stanford as part of the Backdrop CMS community.
@laryn, thanks for your message. Hope you can attend. But agreed in any case that we should take notes.
I was once told by a Drupal colleague that he wasn't sure how seriously to take Backdrop until he saw businesses and developers that were dependent upon it's success for their livelihood.
We already have a number of developers in our community that make significant portions of their income working with Backdrop. But, in my view we need to see more Backdrop based businesses promoting Backdrop and helping to build it's infrastructure.
Triplo has been working on a SASS idea based upon Backdrop CMS - https://simplo.site/
I'd like feedback on Simplo.site as a product AND as importantly, where it fits in the Backdrop community. I'd also like to hear more about how others are making a living by working with Backdrop and how we better support the Backdrop business community.
@olafski I may not be able to attend sessions on the 12th due to a prior commitment. Take good notes? :)
My team still uses SASS on all our big Drupal client projects. I used to love the Zen theme for Drupal 7, because it came with config files and instructions for SASS tools, first Compass and then Gulp.
When I use SASS I still use Gulp. I've done some Drupal Camp presentations on how to set up and customize Gulp in a Drupal 7 theme, based largely on this excellent blog post:
https://chenhuijing.com/blog/drupal-101-theming-with-gulp/
Here is a recorded version of my Gulp session:
https://www.midcamp.org/2019/topic-proposal/introduction-gulp
I would not recommend using Gulp and SASS for anyone that is only theming a single site. But, if you plan to theme a bunch of sites, you might find it useful. It does add complexity to a site and I've spoken to some prolific and talented front end developers that prefer to work in straight CSS.
I think it might be helpful if we had better starter themes for Backdrop that include an optional SASS starter kit.
I'm interested to learn something about the mechanics behind: How user settings are working? Why a registered user can't be deleted? Where is a possibility to solve this?
How could I carry a group membership to a user (enter a group), set automatically the group membership for content, while carrying this membership (content autotag) and how could I release it (leaving a group)?
How could I display all group content or group members, just while carrying the membership info?
Please realize, that this is different than to register to a group for membership.
My idea:
To enter a group, should go trough a gateway or link on the groups main page (the group itself). The membership to a group is already required to be allowed to enter this group. The state is carried like a flag (entered or not). A view should be able to act as a group menu.
Unfortunately I don't know, how to realize it.
If you're new to Backdrop, come in for a discussion on how Backdrop can be the best option for creating your new website. As we all know, WordPress has been the goto for new sites and it has a large user base. But if you plan to do anything other than a basic site of a few pages and a blog, WordPress can require custom code for most things that are even a little bit off the beaten path.
Backdrop allows users to create custom views easily and to create pages that draw from databases, and it doesn't require custom code. You may not need this now, but it's good to have this power in the future.
Backdrop is built on expanded Drupal 7 code. Drupal 7 still powers over 50% of Drupal sites, but it is coming up on End of Life, not immediately, but the modules may not receive updating even though Drupal 7 does for a while yet.
It's time for both new users and Drupal 7 users to step up to a powerful CMS built on proven code.