You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After talking with @medlefsen, I think it might be a worthwhile exercise to see if we can put everything into features. There's obviously the chicken/egg problem with building these foundational features, so some bootstrapping would need to be done first.
One problem I hope to solve with this approach is making sure we only need to run site-install once. Site-install is rather destructive during development since it wipes out the existing database and needs to create settings.php and the files folder.
I also want to explore how we can support the drush-deploy workflow along with a manual deployment workflow during development. Not sure if this is necessary though. We may just say you have to use the drush-deploy workflow and make that as easy as possible. One big reason for that is you have to use symlinks for components such as the sites/default folder so the settings.php file and and files folder aren't blown away during a drush make. If we require drush-deploy, users will need to have a current ruby environment...which can be daunting for non-developers. Something we need to keep in mind. We need to make it very apparent that this whole toolset is not for non-developers.
Still a lot to think about and work through here. Just wanted to get some thoughts down.
The text was updated successfully, but these errors were encountered:
Would we have xforty feature modules set up certain things such as site info, roles, and themes? Then have site feature modules that override those xforty feature modules? Seems complex.
After talking with @medlefsen, I think it might be a worthwhile exercise to see if we can put everything into features. There's obviously the chicken/egg problem with building these foundational features, so some bootstrapping would need to be done first.
One problem I hope to solve with this approach is making sure we only need to run site-install once. Site-install is rather destructive during development since it wipes out the existing database and needs to create settings.php and the files folder.
I also want to explore how we can support the drush-deploy workflow along with a manual deployment workflow during development. Not sure if this is necessary though. We may just say you have to use the drush-deploy workflow and make that as easy as possible. One big reason for that is you have to use symlinks for components such as the sites/default folder so the settings.php file and and files folder aren't blown away during a drush make. If we require drush-deploy, users will need to have a current ruby environment...which can be daunting for non-developers. Something we need to keep in mind. We need to make it very apparent that this whole toolset is not for non-developers.
Still a lot to think about and work through here. Just wanted to get some thoughts down.
The text was updated successfully, but these errors were encountered: