Timeline for How do I manage collaborative development?
Current License: CC BY-SA 4.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 15, 2023 at 7:38 | history | edited | avpaderno♦ | CC BY-SA 4.0 |
removed "Drupal" from the title
|
| Apr 13, 2017 at 12:46 | history | edited | CommunityBot |
replaced http://drupal.stackexchange.com/ with https://drupal.stackexchange.com/
|
|
| Dec 27, 2015 at 5:01 | history | tweeted | twitter.com/StackDrupal/status/680976662171881477 | ||
| Dec 26, 2015 at 17:58 | history | edited | avpaderno♦ |
edited tags
|
|
| Mar 31, 2014 at 4:26 | answer | added | Free Radical | timeline score: 0 | |
| Jan 31, 2012 at 17:22 | vote | accept | Chaulky | ||
| Aug 13, 2011 at 21:33 | history | edited | avpaderno♦ |
edited tags
|
|
| Jul 25, 2011 at 11:06 | answer | added | Jeremy French | timeline score: 5 | |
| Mar 3, 2011 at 1:23 | comment | added | Decipher | I never suggested that, I'm simply suggesting that there is already features support for the modules you suggested (assuming Flag is exportable via Strongarm). I'm not trying to force you down this path, it's just an alternative to going down a harder path, easier to maintain a code based approach in a team than a database approach. In my team I strongly dissuade non Features/Code approaches where I can. I am aware that there are a lot of things that Feature will not be capable of until it is a core part of Drupal, but it can do a lot. | |
| Mar 3, 2011 at 1:23 | history | edited | Chaulky | CC BY-SA 2.5 |
Added link to related question
|
| Mar 3, 2011 at 1:15 | comment | added | Chaulky | @Decipher Ok, so I'll agree with you that there are ways to store all blocks in code. But I still think it's unreasonable to have to add Features support to every module I want to use that doesn't already have it. | |
| Mar 3, 2011 at 1:11 | comment | added | Decipher | No, not end user blocks, but then that's not how I use blocks. I did work on one project that needed user editable blocks, so I wrote an interface where they could modify certain variables that the block would render out, so the block stays in code and the content in variable which is exportable via strongarm, however there are performance issues with that approach, but you could modify it to store your block variables in a custom table that was exportable via CTools. | |
| Mar 3, 2011 at 1:07 | comment | added | Chaulky | @Decipher I disagree that blocks should be defined in code. Yes, some blocks certainly should be, however I'm not going to ask an end user to write code for all his blocks. Drupal is meant to be maintainable by non-developers. So if part of the site is the ability to update a block, I don't want to have to do that every time. So I'd say there are definitely situations where blocks should not be defined in code. | |
| Mar 3, 2011 at 1:04 | history | edited | coderintherye |
edited tags
|
|
| Mar 3, 2011 at 1:03 | comment | added | Decipher | I can't speak for Flags, as it's not in my list of used modules, but you can export Taxonomy with UUID and UUID Features, Blocks should be defined in code with hook_block, Nodes via UUID and UUID Features (not the best approach, but it's an approach). I'm sure Flags would be exportable in some fashion as well, Strongarm exports variables. I'd certainly look closer at Features before ever considering doing database merges again (been there, done that :( ) | |
| Mar 3, 2011 at 1:03 | comment | added | coderintherye | I think we should do a "Features" sprint at Drupalcon to try to add support to some of the things missing. | |
| Mar 3, 2011 at 1:01 | answer | added | coderintherye | timeline score: 4 | |
| Mar 3, 2011 at 0:56 | comment | added | Chaulky | @Decipher I can think of Flags, Taxonomy, Menus, Blocks and actual content (though I believe there are other modules that do that)... I think it would be unrealistic to write my own code to export these things. Then every time I want to use a new module that doesn't support Features I have to first add support for it. I don't have time to be doing that. | |
| Mar 3, 2011 at 0:52 | comment | added | Decipher | I'm curious, what specifically can't you do via Features? The better question might be to ask how to export those things to code with or without Features instead of going down the database merge route. | |
| Mar 3, 2011 at 0:46 | history | asked | Chaulky | CC BY-SA 2.5 |