How could everyone win and get Views in Drupal 8?
I (that means I. Disclaimer: this is my idea. blame me.) would like to see -- Views in core. Without Merlin burning out. -- more shops contributing to core. The biggest deterrent currently IMO is that their work might or might not be accepted and even if gets in, it might be two years before they can use on a client site. -- the security team to only deal with releases that have automated testing so they have a good chance of their patches not breaking core. To achieve all this in one plan, I would like first to ask everybody who wants to contribute core to go to the Views queue and help out! Support requests, bug reports, many things are doable without being the Grand Master of Views. This has immediate returns in fixed bugs, or just a little bit less immediate with less load on Merlin resulting in better Views. But it does not take two years to get deployable results, not at all. And then, if we have brought down the Views queue to a managable size, then we should write tests for Views. Again, this is something a lot of people should be capable of even without knowing the innards of Views and usable right now even with Drupal 6 -- simpletest is backported. Once we have a lot of tests, we should commit them to core along with skeleton code that makes the tests pass. This is a radical but logical change to our core development model. Hopefully this can lead to many smaller patches striving to replace smaller pieces of skeleton code with real instead of few gigantic patches trying to get some major part of Views in core. We do not do anything else for Drupal 8. No other major API changes just tests for Views which are immediately and easily backportable to Drupal 7, once again allowing for immediately deployable code. Obviously there will be changes as our old and hardwired modules get partially replaced by Views. However, this plan would hopefully allow for a short Drupal 8 cycle instead of a year plus long one and when Drupal 8 gets released, the security team has an easier work. Another side benefit is that I can see people jumping over Drupal 6 completely with the D7CX movement quickly putting a deployable (I seem to like that word) Drupal 7 on the table. So relatively quickly (but still it gets more than two years) deprecating D6 wont be as bad. Also, as Drupal 8 won't break APIs as bad as usual, the contrib authors will have an easier job of maintaing D7 and D8 branches. Another benefit is that the usability folks can work on a stable platform so Drupal 8 can be even more usable than Drupal 7. I should list the drawbacks here but aside from a few crazy core developers (like little me) being a bit frustrated for being in a soft API freeze for Drupal 8, I can't see any. I will certainly be less frustrated over not being able to overhaul everything than I would be to being able to but working almost in isolation. There is a huge chasm between real world sites and core development and this would allow us to bridge.
Why would you want views in core? You put views in core and it is frozen. Nobody can do anything with it (as far as changing it: adding new features, reworking existing code, etc). As a contrib module, the Views maintainers can decide how they want to run the release process for Views, and I personally would like to keep it that way -- it allows for a LOT more flexibility and a much faster development lifecycle. Plus, core is already weighing in at around 9.5 MB. Adding another 4.5 MB of code to maintain doesn't seem like a good idea to me. Just my $0.02 ----- Cameron Eagans Owner, Black Storms Studios, LLC http://www.blackstormsstudios.com On Mon, Aug 10, 2009 at 11:13 AM, Karoly Negyesi <karoly@negyesi.net> wrote:
I (that means I. Disclaimer: this is my idea. blame me.) would like to see
-- Views in core. Without Merlin burning out. -- more shops contributing to core. The biggest deterrent currently IMO is that their work might or might not be accepted and even if gets in, it might be two years before they can use on a client site. -- the security team to only deal with releases that have automated testing so they have a good chance of their patches not breaking core.
To achieve all this in one plan, I would like first to ask everybody who wants to contribute core to go to the Views queue and help out! Support requests, bug reports, many things are doable without being the Grand Master of Views. This has immediate returns in fixed bugs, or just a little bit less immediate with less load on Merlin resulting in better Views. But it does not take two years to get deployable results, not at all.
And then, if we have brought down the Views queue to a managable size, then we should write tests for Views. Again, this is something a lot of people should be capable of even without knowing the innards of Views and usable right now even with Drupal 6 -- simpletest is backported.
Once we have a lot of tests, we should commit them to core along with skeleton code that makes the tests pass. This is a radical but logical change to our core development model. Hopefully this can lead to many smaller patches striving to replace smaller pieces of skeleton code with real instead of few gigantic patches trying to get some major part of Views in core.
We do not do anything else for Drupal 8. No other major API changes just tests for Views which are immediately and easily backportable to Drupal 7, once again allowing for immediately deployable code. Obviously there will be changes as our old and hardwired modules get partially replaced by Views. However, this plan would hopefully allow for a short Drupal 8 cycle instead of a year plus long one and when Drupal 8 gets released, the security team has an easier work.
Another side benefit is that I can see people jumping over Drupal 6 completely with the D7CX movement quickly putting a deployable (I seem to like that word) Drupal 7 on the table. So relatively quickly (but still it gets more than two years) deprecating D6 wont be as bad. Also, as Drupal 8 won't break APIs as bad as usual, the contrib authors will have an easier job of maintaing D7 and D8 branches.
Another benefit is that the usability folks can work on a stable platform so Drupal 8 can be even more usable than Drupal 7.
I should list the drawbacks here but aside from a few crazy core developers (like little me) being a bit frustrated for being in a soft API freeze for Drupal 8, I can't see any. I will certainly be less frustrated over not being able to overhaul everything than I would be to being able to but working almost in isolation. There is a huge chasm between real world sites and core development and this would allow us to bridge.
Cameron Eagans wrote:
You put views in core and it is frozen. Nobody can do anything with it (as far as changing it: adding new features, reworking existing code, etc). As a contrib module, the Views maintainers can decide how they want to run the release process for Views, and I personally would like to keep it that way -- it allows for a LOT more flexibility and a much faster development lifecycle. I agree. This is the biggest drawback to putting things in core. They get stale really fast. Until such time that core becomes less rigid I don't see this as a good idea. Plus, core is already weighing in at around 9.5 MB. Adding another 4.5 MB of code to maintain doesn't seem like a good idea to me. Not so much of an issue. I'd like to see better install profiles such that the big modules are downloaded along with core instead of having to be downloaded alone.
Darthclue
Quoting Darth Clue <darthclue@gmail.com>:
Not so much of an issue. I'd like to see better install profiles such that the big modules are downloaded along with core instead of having to be downloaded alone.
I would like to see install profiles a major focus for D8. Providing the users a default wiki install or a default blog install or a default eCommerce install or a combination of profiles to choose from, etc would make Drupal even more useful to those who don't code. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
Talking as someone who has not used views extensively, has views really changed that greatly within versions? Going by the numbers alone, Views 1.x was for Drupal 5, Views 2.x is for Drupal 6. Maybe I am wrong but I would assume that the changes from 2.0 to 2.5 the current release do not impact on the underlying infrastructure all that much? And this is with a "freak" core lifecycle of two years which I assume will not remain the norm. 2009/8/10 Cameron Eagans
Why would you want views in core?
You put views in core and it is frozen. Nobody can do anything with it (as far as changing it: adding new features, reworking existing code, etc). As a contrib module, the Views maintainers can decide how they want to run the release process for Views, and I personally would like to keep it that way -- it allows for a LOT more flexibility and a much faster development lifecycle.
Plus, core is already weighing in at around 9.5 MB. Adding another 4.5 MB of code to maintain doesn't seem like a good idea to me.
Views is an query builder, and there's going to be an query builder in D7...couldn't views pretty much work out to a consistent UI for that? On Tue, Aug 11, 2009 at 11:56 AM, Naheem Zaffar<naheemzaffar@gmail.com> wrote:
Talking as someone who has not used views extensively, has views really changed that greatly within versions?
Going by the numbers alone, Views 1.x was for Drupal 5, Views 2.x is for Drupal 6. Maybe I am wrong but I would assume that the changes from 2.0 to 2.5 the current release do not impact on the underlying infrastructure all that much?
And this is with a "freak" core lifecycle of two years which I assume will not remain the norm.
2009/8/10 Cameron Eagans
Why would you want views in core?
You put views in core and it is frozen. Nobody can do anything with it (as far as changing it: adding new features, reworking existing code, etc). As a contrib module, the Views maintainers can decide how they want to run the release process for Views, and I personally would like to keep it that way -- it allows for a LOT more flexibility and a much faster development lifecycle.
Plus, core is already weighing in at around 9.5 MB. Adding another 4.5 MB of code to maintain doesn't seem like a good idea to me.
+1 for views in core d8. It's a pretty useful module, and I'm guessing most of us use it in the vast majority of our sites. wrt code flexibility, I think it's a fair trade off for lowering another barrier to entry for new users. It's one less blog/forum/module search a new user has to read/do in order to get/understand/use what again I'd guess most drupal sites consider standard/necessary. Just my thoughts though. Cheers, tim On Tue, Aug 11, 2009 at 12:29 PM, Earl Dunovant <prometheus6@gmail.com>wrote:
Views is an query builder, and there's going to be an query builder in D7...couldn't views pretty much work out to a consistent UI for that?
On Tue, Aug 11, 2009 at 11:56 AM, Naheem Zaffar<naheemzaffar@gmail.com> wrote:
Talking as someone who has not used views extensively, has views really changed that greatly within versions?
Going by the numbers alone, Views 1.x was for Drupal 5, Views 2.x is for Drupal 6. Maybe I am wrong but I would assume that the changes from 2.0 to 2.5 the current release do not impact on the underlying infrastructure all that much?
And this is with a "freak" core lifecycle of two years which I assume will not remain the norm.
2009/8/10 Cameron Eagans
Why would you want views in core?
You put views in core and it is frozen. Nobody can do anything with it
(as
far as changing it: adding new features, reworking existing code, etc). As a contrib module, the Views maintainers can decide how they want to run the release process for Views, and I personally would like to keep it that way -- it allows for a LOT more flexibility and a much faster development lifecycle.
Plus, core is already weighing in at around 9.5 MB. Adding another 4.5 MB of code to maintain doesn't seem like a good idea to me.
-- Tim Loudon t: 781.686.6096
With plugin manager in core, it should not be necessary to bundle views with core. It will be a simple matter of selecting the module for installation, after which plugin manager will download the module, install and enable it for you. I think the argument of 'let's put views in core because it'll make setting up sites easier' is kind of a bad one in this case. Views is neither easy nor essential for -every- site out there. ----- Cameron Eagans Owner, Black Storms Studios, LLC http://www.blackstormsstudios.com On Tue, Aug 11, 2009 at 11:15 PM, T L <tloud365@gmail.com> wrote:
+1 for views in core d8.
It's a pretty useful module, and I'm guessing most of us use it in the vast majority of our sites. wrt code flexibility, I think it's a fair trade off for lowering another barrier to entry for new users. It's one less blog/forum/module search a new user has to read/do in order to get/understand/use what again I'd guess most drupal sites consider standard/necessary.
Just my thoughts though.
Cheers, tim
On Tue, Aug 11, 2009 at 12:29 PM, Earl Dunovant <prometheus6@gmail.com>wrote:
Views is an query builder, and there's going to be an query builder in D7...couldn't views pretty much work out to a consistent UI for that?
On Tue, Aug 11, 2009 at 11:56 AM, Naheem Zaffar<naheemzaffar@gmail.com> wrote:
Talking as someone who has not used views extensively, has views really changed that greatly within versions?
Going by the numbers alone, Views 1.x was for Drupal 5, Views 2.x is for Drupal 6. Maybe I am wrong but I would assume that the changes from 2.0 to 2.5 the current release do not impact on the underlying infrastructure all that much?
And this is with a "freak" core lifecycle of two years which I assume will not remain the norm.
2009/8/10 Cameron Eagans
Why would you want views in core?
You put views in core and it is frozen. Nobody can do anything with it
(as
far as changing it: adding new features, reworking existing code, etc). As a contrib module, the Views maintainers can decide how they want to run the release process for Views, and I personally would like to keep it that way -- it allows for a LOT more flexibility and a much faster development lifecycle.
Plus, core is already weighing in at around 9.5 MB. Adding another 4.5 MB of code to maintain doesn't seem like a good idea to me.
-- Tim Loudon t: 781.686.6096
Cameron Eagans wrote:
I think the argument of 'let's put views in core because it'll make setting up sites easier' is kind of a bad one in this case. Views is neither easy nor essential for -every- site out there.
The argument for having Views in core is that Views would then power a whole ton of core: tracker.module: Just a view. blog.module: Just a view. /node front page: Just a view. /rss.xml: Just a view. node content admin: Could be a view, with VBO. user admin: Could be a view, with VBO. recent comments block: Yep, a view. recent blog posts block: Yep, a view. active forum posts? Sho 'nuff. Having a bunch of this stuff be Views natively, instead of hardcoded queries and whatnot, would be a big step closer to separating the API from the Application, and the Application would become *much* more replaceable. And tweakable. Because once it's a view, then on your site you can tweak it as much as you can tweak any view. And that's rather a lot.
I didn't mean to say that it would not be useful. On the contrary, views would be *useful* in core...I just don't think it would be a good idea to put it there, especially with plugin manager making it so easily accessible from the ui. That said, I would support putting a views api in core and leaving the UI in contrib, like what is done with cck right now (but only because it's obvious that lots of people want views in core -- if it's gonna go in, that's the way I'd wanna see it there) ----- Cameron Eagans Owner, Black Storms Studios, LLC http://www.blackstormsstudios.com On Wed, Aug 12, 2009 at 12:04 AM, Earl Miles <merlin@logrus.com> wrote:
Cameron Eagans wrote:
I think the argument of 'let's put views in core because it'll make setting up sites easier' is kind of a bad one in this case. Views is neither easy nor essential for -every- site out there.
The argument for having Views in core is that Views would then power a whole ton of core:
tracker.module: Just a view. blog.module: Just a view. /node front page: Just a view. /rss.xml: Just a view. node content admin: Could be a view, with VBO. user admin: Could be a view, with VBO. recent comments block: Yep, a view. recent blog posts block: Yep, a view. active forum posts? Sho 'nuff.
Having a bunch of this stuff be Views natively, instead of hardcoded queries and whatnot, would be a big step closer to separating the API from the Application, and the Application would become *much* more replaceable. And tweakable. Because once it's a view, then on your site you can tweak it as much as you can tweak any view. And that's rather a lot.
Cameron Eagans wrote:
That said, I would support putting a views api in core and leaving the UI in contrib, like what is done with cck right now (but only because it's obvious that lots of people want views in core -- if it's gonna go in, that's the way I'd wanna see it there)
FYI this is impossible with the current architecture. It's also turning out to be really bad with CCK, which is why they're trying to get the CCK UI into core after all. And it's the same reason: Both systems are really pluggable, and in order to work right, the pluggable systems need their own additive UI bits. And you can't do that without a core UI for them to add *to*.
I really like that whole idea. Then we could have handy hooks to easily modify those queries if someone wishes, like maybe an easy way to add index hinting. Jamie Holly http://www.intoxination.net http://www.hollyit.net Earl Miles wrote:
The argument for having Views in core is that Views would then power a whole ton of core:
tracker.module: Just a view. blog.module: Just a view. /node front page: Just a view. /rss.xml: Just a view. node content admin: Could be a view, with VBO. user admin: Could be a view, with VBO. recent comments block: Yep, a view. recent blog posts block: Yep, a view. active forum posts? Sho 'nuff.
Having a bunch of this stuff be Views natively, instead of hardcoded queries and whatnot, would be a big step closer to separating the API from the Application, and the Application would become *much* more replaceable. And tweakable. Because once it's a view, then on your site you can tweak it as much as you can tweak any view. And that's rather a lot.
Quoting Jamie Holly <hovercrafter@earthlink.net>:
I really like that whole idea. Then we could have handy hooks to easily modify those queries if someone wishes, like maybe an easy way to add index hinting.
But we can have those hooks maintained in a contrib module as well. We just need to have a api.contrib.drupal.org or drupal.org/contrib/api. I am with the crowd of keep Drupal core lean. The less optional modules Drupal has to consider the better it would be. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
I am with the crowd of keep Drupal core lean. The less optional modules Drupal has to consider the better it would be.
Wouldn't adding views to core do just that, ie the 8 or so module Earl mentioned? re-pasted below. tracker.module: Just a view. blog.module: Just a view. /node front page: Just a view. /rss.xml: Just a view. node content admin: Could be a view, with VBO. user admin: Could be a view, with VBO. recent comments block: Yep, a view. recent blog posts block: Yep, a view. active forum posts? Sho 'nuff. Jim On Wed, Aug 12, 2009 at 11:46 AM, Earnie Boyd <earnie@users.sourceforge.net>wrote:
Quoting Jamie Holly <hovercrafter@earthlink.net>:
I really like that whole idea. Then we could have handy hooks to easily
modify those queries if someone wishes, like maybe an easy way to add index hinting.
But we can have those hooks maintained in a contrib module as well. We just need to have a api.contrib.drupal.org or drupal.org/contrib/api. I am with the crowd of keep Drupal core lean. The less optional modules Drupal has to consider the better it would be.
-- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
Quoting Jim Taylor <jim@rootyhollow.com>:
I am with the crowd of keep Drupal core lean. The less optional modules Drupal has to consider the better it would be.
Wouldn't adding views to core do just that, ie the 8 or so module Earl mentioned? re-pasted below.
No, it would add another module to core I might not use (most likely wouldn't use). Another module that the boot process has to consider in its processing. Another module that is taking up disk space for no reason. Another module that won't get a speedy needed fix. Core needs to be lean, a provider of the low level API. Everything else should be a contrib module maintained outside of core. Or maybe, if we have an issue with these module being contrib, a core-optional set of modules that get maintained separately from core. Core-optional modules would have the additional requirement that they need to be ready to release an updated module on core release night.
tracker.module: Just a view. blog.module: Just a view. /node front page: Just a view. /rss.xml: Just a view. node content admin: Could be a view, with VBO. user admin: Could be a view, with VBO. recent comments block: Yep, a view. recent blog posts block: Yep, a view. active forum posts? Sho 'nuff. Jim
Some of these could be moved to a contrib module (or core-optional module) and maintained outside of core. Only the required modules need to be retained within core. Sure the maintainers need to be on top of the development of Drupal and be ready for a new release. If the tracker module was turned into a view then the contrib module info file would make views a dependency of the module. What needs to be considered as we have said before is a choice of install profiles for a user to use. The install profiles would be responsible for the dependencies of its package and can be updated as a contrib module is updated. A contrib module maintainer could even be responsible for the patch to the install profile. The install package file build process could even include the contrib module dependencies it requires. BTW, the same goes for themes. Only the default garland theme needs to be delivered with core. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
And I am glad people contributing hard to core are making such claims and writing so worthy and important followups in this thread. (Hey! I resisted writing an answer like this for two days. Not easy.) On Wed, Aug 12, 2009 at 12:26 PM, Jim Taylor<jim@rootyhollow.com> wrote:
On Wed, Aug 12, 2009 at 3:13 PM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
BTW, the same goes for themes. Only the default garland theme needs to be delivered with core.
I agree with that for sure
I don't think the problem is difficulty of installation per se. Drush is the bee's knees and I'm definitely looking forward to a plugin manager, but personally downloading a tarball is not that tough for me. However, when you combine moderate computer skills with a total lack of knowledge about Drupal (talking about new users here :) ); I think it becomes a big obstacle. You are asking a majority of end-users to know about views--there's so much information to take in...it just doesn't make sense to me. To put it another way, think of it like an api. I think someone may have mentioned this blog post before here ( http://jdegoes.squarespace.com/journal/2009/5/2/good-api-design-part-1.html) but I see the essential point being the api hides all the hard, gnarly stuff so it's easy to use. What I think is interesting, is the suggestion that one breaks down the end-user time-savings vs the developer's time spent in writing more perfect code. To me, it makes sense to look at it in terms of numbers and in that case, views in core looks like a good move. Additionally, I'm not being facetious or trying to be inflammatory here--what does 'lean in core' mean? We're talking about less than 20mb of code that allows novices to build $50k websites. To me, Moore's law suggests developer and end-user time + market share is more precious than hardware. Thanks, Tim On Wed, Aug 12, 2009 at 3:47 PM, Karoly Negyesi <karoly@negyesi.net> wrote:
And I am glad people contributing hard to core are making such claims and writing so worthy and important followups in this thread. (Hey! I resisted writing an answer like this for two days. Not easy.)
On Wed, Aug 12, 2009 at 12:26 PM, Jim Taylor<jim@rootyhollow.com> wrote:
On Wed, Aug 12, 2009 at 3:13 PM, Earnie Boyd < earnie@users.sourceforge.net> wrote:
BTW, the same goes for themes. Only the default garland theme needs to
be
delivered with core.
I agree with that for sure
-- Tim Loudon t: 781.686.6096
Quoting Karoly Negyesi <karoly@negyesi.net>:
And I am glad people contributing hard to core are making such claims and writing so worthy and important followups in this thread. (Hey! I resisted writing an answer like this for two days. Not easy.)
I'm surprised it took you that long. ;p First let me say that I am not trying to belittle those who do much work for Drupal core. You, Karoly, alone provide many hours of code to the core API. I recognize that but you did ask for comments and I have given them. I also realize that those who contribute long hours to core usually win the battle of what core becomes. However, you shouldn't ask for comments if you don't want to hear the opposite of what you asked comments about. There have been many releases focused on improving the API. The API has become a power horse for developers. What we need to strive for now is someone who wants to install a no fuss minimal configuration blog or wiki or whatever installation profile. I would like to see a focus for the inexperienced or non-technical person so that Drupal can become even more used than it is today. Have a short cycled D8 to make this focus where new or changed API only addresses this need. And if you feel that the only way to do that is put Views in core then fine do it but only if it is required to meet that goal. D9 can add/change the API as much as you like. I am still of the opinion that optional modules should reside outside of core and the maintenance for those modules could be handled such that a fix for a bug in taxonomy doesn't take as long. But, that is my opinion and you are entitled to yours. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
Earnie Boyd wrote:
Or maybe, if we have an issue with these module being contrib, a core-optional set of modules that get maintained separately from core. Core-optional modules would have the additional requirement that they need to be ready to release an updated module on core release night.
Good idea. I believe I remember something similar being discussed before. http://drupal.org/node/311893 I believe the impetus for that discussion was originally spurred by frustration about several contrib module's development not syncing with core's release cycle in the early days of 6.0 In my personal opinion, a goodly portion of 'core' should be moved to a 'golden contrib' category. But I don't pursue this soapbox, as I don't believe it has much support, and its easier for me to disable or remove those modules myself. As for views particularly, I'd rather not see it in core and adopt a system like the above, however, I'd rather see it in core than see it remain as-is. I think there is a ternary operand in that thought somewhere. -S
Yeah I agree we really need to keep Drupal lean. I wouldn't want to see the entire Views package integrated as-is. I wouldn't mind some of the functionality included though that would give an easy way to alter some core queries. One that comes to mind is the comment query. Sometimes there are needs for extra data from the user table to be pulled in, and currently there really isn't an easy way to alter that query in comments.module. I've thought in the past about a hook_query_alter, but that could really add some overhead - especially on sites with a large number of queries. Jamie Holly http://www.intoxination.net http://www.hollyit.net Earnie Boyd wrote:
Quoting Jamie Holly <hovercrafter@earthlink.net>:
I really like that whole idea. Then we could have handy hooks to easily modify those queries if someone wishes, like maybe an easy way to add index hinting.
But we can have those hooks maintained in a contrib module as well. We just need to have a api.contrib.drupal.org or drupal.org/contrib/api. I am with the crowd of keep Drupal core lean. The less optional modules Drupal has to consider the better it would be.
-- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
On Wed, Aug 12, 2009 at 6:01 PM, Jamie Holly<hovercrafter@earthlink.net> wrote:
I've thought in the past about a hook_query_alter, but that could really add some overhead - especially on sites with a large number of queries.
Your wish has been granted. http://api.drupal.org/api/function/hook_query_alter/7 Damien
Um. hook_query_alter() went into core nearly a year ago as part of DBTNG. It only applies to dynamic SELECT queries, which is a small minority of the queries Drupal runs. Jamie Holly wrote:
Yeah I agree we really need to keep Drupal lean. I wouldn't want to see the entire Views package integrated as-is. I wouldn't mind some of the functionality included though that would give an easy way to alter some core queries. One that comes to mind is the comment query. Sometimes there are needs for extra data from the user table to be pulled in, and currently there really isn't an easy way to alter that query in comments.module.
I've thought in the past about a hook_query_alter, but that could really add some overhead - especially on sites with a large number of queries.
Jamie Holly http://www.intoxination.net http://www.hollyit.net
Earnie Boyd wrote:
Quoting Jamie Holly <hovercrafter@earthlink.net>:
I really like that whole idea. Then we could have handy hooks to > easily modify those queries if someone wishes, like maybe an easy > way to add index hinting.
But we can have those hooks maintained in a contrib module as well. We just need to have a api.contrib.drupal.org or drupal.org/contrib/api. I am with the crowd of keep Drupal core lean. The less optional modules Drupal has to consider the better it would be.
-- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
Learn something new every day! I haven't started playing with D7 yet, but I can see that becoming a very handy hook. By the way, do you have a decent reference to the new Database layer for D7? I got some stuff to start converting and I would like to start that in the near future. Jamie Holly http://www.intoxination.net http://www.hollyit.net larry@garfieldtech.com wrote:
Um. hook_query_alter() went into core nearly a year ago as part of DBTNG. It only applies to dynamic SELECT queries, which is a small minority of the queries Drupal runs.
Jamie Holly wrote:
Yeah I agree we really need to keep Drupal lean. I wouldn't want to see the entire Views package integrated as-is. I wouldn't mind some of the functionality included though that would give an easy way to alter some core queries. One that comes to mind is the comment query. Sometimes there are needs for extra data from the user table to be pulled in, and currently there really isn't an easy way to alter that query in comments.module.
I've thought in the past about a hook_query_alter, but that could really add some overhead - especially on sites with a large number of queries.
Jamie Holly http://www.intoxination.net http://www.hollyit.net
Earnie Boyd wrote:
Quoting Jamie Holly <hovercrafter@earthlink.net>:
I really like that whole idea. Then we could have handy hooks to > easily modify those queries if someone wishes, like maybe an easy > way to add index hinting.
But we can have those hooks maintained in a contrib module as well. We just need to have a api.contrib.drupal.org or drupal.org/contrib/api. I am with the crowd of keep Drupal core lean. The less optional modules Drupal has to consider the better it would be.
-- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
Docs have been here for the past 11 months: http://drupal.org/node/310069 Or track me down in Paris, as I fully expect to spend most of the code sprint(s) helping people with upgrades. Jamie Holly wrote:
Learn something new every day! I haven't started playing with D7 yet, but I can see that becoming a very handy hook.
By the way, do you have a decent reference to the new Database layer for D7? I got some stuff to start converting and I would like to start that in the near future.
Jamie Holly http://www.intoxination.net http://www.hollyit.net
larry@garfieldtech.com wrote:
Um. hook_query_alter() went into core nearly a year ago as part of DBTNG. It only applies to dynamic SELECT queries, which is a small minority of the queries Drupal runs.
Jamie Holly wrote:
Yeah I agree we really need to keep Drupal lean. I wouldn't want to see > the entire Views package integrated as-is. I wouldn't mind some of the > functionality included though that would give an easy way to alter some > core queries. One that comes to mind is the comment query. Sometimes > there are needs for extra data from the user table to be pulled in, and > currently there really isn't an easy way to alter that query in > comments.module.
I've thought in the past about a hook_query_alter, but that could really > add some overhead - especially on sites with a large number of queries. Jamie Holly http://www.intoxination.net http://www.hollyit.net
Earnie Boyd wrote: Quoting Jamie Holly <hovercrafter@earthlink.net>:
I really like that whole idea. Then we could have handy hooks to easily modify those queries if someone wishes, like maybe an easy > >> way to add index hinting.
But we can have those hooks maintained in a contrib module as well. >> We just need to have a api.contrib.drupal.org or >> drupal.org/contrib/api. I am with the crowd of keep Drupal core >> lean. The less optional modules Drupal has to consider the better it would be.
-- >> Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
Jamie Holly wrote:
Yeah I agree we really need to keep Drupal lean. I wouldn't want to see the entire Views package integrated as-is. I wouldn't mind some of the functionality included
This one drives me crazy. There really isn't a 'some'. There is no Views lite. Stripping out functionality does not make Views lighter, it just makes it less useful, and that is ultimately harmful. The reason Views is useful is because it is flexible. The reason it seems like it is 'heavy' is because it's defining handlers to deal with a couple dozen core tables, hundreds of core fields, half a dozen different styles (table, unformatted, node view, rss, etc). It is replacing a LOT of core functionality. When it goes into core, a lot of core code just gets thrown away. Anyway, people who have this attitude are really saying they don't want Views in core. That's fine, but what that really means is that core doesn't get the benefit of Views functionality. It degrades the overall user experience and it creates a lot of dead code in core that mostly is never used because 90% (or more) of the people using Drupal install Views anyway. (Right now, statistically, views is on 60% of all reporting Drupal sites). Also, one day I may not be able to maintain Views. I don't want to sound like an asshole...but I am an asshole. Every one who doesn't want Views in core had better consider the day that I move on from my current position, and am no longer able to maintain Views more or less full time on someone else's dime. If it's not in core, it could just become another unmaintained contrib module. Core is maintained by a large community. Views is maintained 95% by me and 5% by a handfull of other people who've gotten into it enough to understand it. But also, and this is the real reason: Core would be *better* with Views in it. Views in core is actually part of the #smallcore ideal, IMO, because it lets us do a better job of reducing core to APIs and building the Application on top of it, rather than core being half framework and half application, like it is now.
On Wed, Aug 12, 2009 at 1:34 PM, Earl Miles <merlin@logrus.com> wrote:
Jamie Holly wrote:
Yeah I agree we really need to keep Drupal lean. I wouldn't want to see the entire Views package integrated as-is. I wouldn't mind some of the functionality included
This one drives me crazy. There really isn't a 'some'. There is no Views lite. Stripping out functionality does not make Views lighter, it just makes it less useful, and that is ultimately harmful. The reason Views is useful is because it is flexible.
The reason it seems like it is 'heavy' is because it's defining handlers to deal with a couple dozen core tables, hundreds of core fields, half a dozen different styles (table, unformatted, node view, rss, etc). It is replacing a LOT of core functionality. When it goes into core, a lot of core code just gets thrown away.
Anyway, people who have this attitude are really saying they don't want Views in core. That's fine, but what that really means is that core doesn't get the benefit of Views functionality. It degrades the overall user experience and it creates a lot of dead code in core that mostly is never used because 90% (or more) of the people using Drupal install Views anyway. (Right now, statistically, views is on 60% of all reporting Drupal sites).
Let's get real. Views should be in core because it really is at the core of what sets Drupal apart from other CMS frameworks. And at the same time it being in core would be part of a positive refactoring which would go a long way towards paying some of the code debt Drupal has. Let's get real. Views in core: +1. Victor Kane http://awebfactory.com.ar
Also, one day I may not be able to maintain Views. I don't want to sound like an asshole...but I am an asshole. Every one who doesn't want Views in core had better consider the day that I move on from my current position, and am no longer able to maintain Views more or less full time on someone else's dime. If it's not in core, it could just become another unmaintained contrib module. Core is maintained by a large community. Views is maintained 95% by me and 5% by a handfull of other people who've gotten into it enough to understand it.
But also, and this is the real reason: Core would be *better* with Views in it. Views in core is actually part of the #smallcore ideal, IMO, because it lets us do a better job of reducing core to APIs and building the Application on top of it, rather than core being half framework and half application, like it is now.
Sorry - I should have expanded more on what I meant. What I think would work out good is having the actual storage and execution of views handled by the core. Then the GUI to edit/create views could be offered as a contrib module. Storing things like "blog" as just a view would be a great step forward in flexibility IMHO. If someone doesn't like how the "blog" displays, then they could download the contrib "views-gui" and alter that view. My thinking is more or less in future upgrades. For example - D8 has this built in, then D9 comes out. People would still be able to use the views they built through the D8 views-gui, even if that contrib module isn't released by the time D9 comes out. There are countless sites that rely on views, but how often to they actually edit and/or create views? I know a few that I maintain views has been there, but once the view was created that was pretty much it. I have had no need to go back and edit that view. I'm just spinning this off the top of my head and not entirley sure if its doable or not, but if it is I can see it having the benefit of a) having core able to process and utilize views while maintaining a more conservative code base and b) make maintaining views-contrib more easily maintained by having to focus mainly on the GUI. Jamie Holly http://www.intoxination.net http://www.hollyit.net Earl Miles wrote:
Jamie Holly wrote:
Yeah I agree we really need to keep Drupal lean. I wouldn't want to see the entire Views package integrated as-is. I wouldn't mind some of the functionality included
This one drives me crazy. There really isn't a 'some'. There is no Views lite. Stripping out functionality does not make Views lighter, it just makes it less useful, and that is ultimately harmful. The reason Views is useful is because it is flexible.
The reason it seems like it is 'heavy' is because it's defining handlers to deal with a couple dozen core tables, hundreds of core fields, half a dozen different styles (table, unformatted, node view, rss, etc). It is replacing a LOT of core functionality. When it goes into core, a lot of core code just gets thrown away.
Anyway, people who have this attitude are really saying they don't want Views in core. That's fine, but what that really means is that core doesn't get the benefit of Views functionality. It degrades the overall user experience and it creates a lot of dead code in core that mostly is never used because 90% (or more) of the people using Drupal install Views anyway. (Right now, statistically, views is on 60% of all reporting Drupal sites).
Also, one day I may not be able to maintain Views. I don't want to sound like an asshole...but I am an asshole. Every one who doesn't want Views in core had better consider the day that I move on from my current position, and am no longer able to maintain Views more or less full time on someone else's dime. If it's not in core, it could just become another unmaintained contrib module. Core is maintained by a large community. Views is maintained 95% by me and 5% by a handfull of other people who've gotten into it enough to understand it.
But also, and this is the real reason: Core would be *better* with Views in it. Views in core is actually part of the #smallcore ideal, IMO, because it lets us do a better job of reducing core to APIs and building the Application on top of it, rather than core being half framework and half application, like it is now.
Exactly right. I can't even name all the places in core where the core almost gives me what I want, but not quite because of a missing CCK field or column in a view. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Earl Miles Sent: Wednesday, August 12, 2009 2:05 AM To: development@drupal.org Subject: Re: [development] How could everyone win and get Views in Drupal 8? Cameron Eagans wrote:
I think the argument of 'let's put views in core because it'll make setting up sites easier' is kind of a bad one in this case. Views is neither easy nor essential for -every- site out there.
The argument for having Views in core is that Views would then power a whole ton of core: tracker.module: Just a view. blog.module: Just a view. /node front page: Just a view. /rss.xml: Just a view. node content admin: Could be a view, with VBO. user admin: Could be a view, with VBO. recent comments block: Yep, a view. recent blog posts block: Yep, a view. active forum posts? Sho 'nuff. Having a bunch of this stuff be Views natively, instead of hardcoded queries and whatnot, would be a big step closer to separating the API from the Application, and the Application would become *much* more replaceable. And tweakable. Because once it's a view, then on your site you can tweak it as much as you can tweak any view. And that's rather a lot.
You know I love you, Earl, but just as a counter argument to all of these pieces of core that can be replaced by Views: in my experience, Views is significantly less efficient at doing most of those things. I do admit and agree, that Views would replace a ton of core code, just as you write. And that a huge amount of flexibility would be gained, as well. I'm kind of obsessive about having fast, lightweight core code so that I can still build a very fast site without throwing lots of hardware at it. So, is there a way to incorporate Views in core, but avoid using its code in a specialized application built upon Drupal (except for perhaps rarely loaded pages, like user admin)? I can wish for the moon, can't I? :-) On Wed, Aug 12, 2009 at 12:04 AM, Earl Miles<merlin@logrus.com> wrote:
Cameron Eagans wrote:
I think the argument of 'let's put views in core because it'll make setting up sites easier' is kind of a bad one in this case. Views is neither easy nor essential for -every- site out there.
The argument for having Views in core is that Views would then power a whole ton of core:
tracker.module: Just a view. blog.module: Just a view. /node front page: Just a view. /rss.xml: Just a view. node content admin: Could be a view, with VBO. user admin: Could be a view, with VBO. recent comments block: Yep, a view. recent blog posts block: Yep, a view. active forum posts? Sho 'nuff.
Having a bunch of this stuff be Views natively, instead of hardcoded queries and whatnot, would be a big step closer to separating the API from the Application, and the Application would become *much* more replaceable. And tweakable. Because once it's a view, then on your site you can tweak it as much as you can tweak any view. And that's rather a lot.
Chris Johnson wrote:
I'm kind of obsessive about having fast, lightweight core code so that I can still build a very fast site without throwing lots of hardware at it.
tracker.module: Just a view. blog.module: Just a view. /node front page: Just a view. /rss.xml: Just a view. node content admin: Could be a view, with VBO. user admin: Could be a view, with VBO. recent comments block: Yep, a view. recent blog posts block: Yep, a view. active forum posts? Sho 'nuff.
Out of curiousity, how many of those things do you use on your fast, lightweight sites? tracker.module: Not fast. blog.module: Does anybody *really* use this? node front page, river of news: The weight of 10+ node_load() calls vastly outweighs anything Views adds to this. admin pages: It's ok for them to be a little heavy. The blocks can be cached.
On Wed, Aug 12, 2009 at 11:50 AM, Earl Miles<merlin@logrus.com> wrote:
Chris Johnson wrote:
I'm kind of obsessive about having fast, lightweight core code so that I can still build a very fast site without throwing lots of hardware at it.
tracker.module: Just a view. blog.module: Just a view. /node front page: Just a view. /rss.xml: Just a view. node content admin: Could be a view, with VBO. user admin: Could be a view, with VBO. recent comments block: Yep, a view. recent blog posts block: Yep, a view. active forum posts? Sho 'nuff.
Out of curiousity, how many of those things do you use on your fast, lightweight sites?
tracker.module: Not fast. blog.module: Does anybody *really* use this? node front page, river of news: The weight of 10+ node_load() calls vastly outweighs anything Views adds to this. admin pages: It's ok for them to be a little heavy.
The blocks can be cached.
Darn fine argument. :-) Few of them, except node front page. Tracker would be second most common, probably, even though it's slow. I'll have to admit I use the blog module on my personal site. Any side effects of having Views in core, e.g. loading code not used? That's where my biggest concern would be now.
I'm not familiar with the particulars of how Views would be exist in core, but strictly as an abstract architecture question, could not Views have a core-required 'kernel' and core-optional portions. Perhaps there would be a way to modularize it so that the savings on code by the other core elements that would use it would result in a small net gain in size of the install package if the core-optional modules aren't enabled? Just a thought.
On Wednesday 12 August 2009 11:04:08 pm Jeff Greenberg wrote:
I'm not familiar with the particulars of how Views would be exist in core, but strictly as an abstract architecture question, could not Views have a core-required 'kernel' and core-optional portions. Perhaps there would be a way to modularize it so that the savings on code by the other core elements that would use it would result in a small net gain in size of the install package if the core-optional modules aren't enabled? Just a thought.
This was already mentioned and disposed of. Too few people are familiar enough and competent and willing to put the time in to deal with Views on its own not to speak of modularizing Views. My code-foo is too small to contribute meaningfully to getting Views into core so I'll restrict myself to helping the thread stay on track. -- Samir Nassar http://samirnassar.com 612-481-0843 samir.nassar@gmail.com
Chris Johnson wrote:
Few of them, except node front page. Tracker would be second most common, probably, even though it's slow. I'll have to admit I use the blog module on my personal site.
Any side effects of having Views in core, e.g. loading code not used? That's where my biggest concern would be now.
Very little of Views' code is loaded (obviously the .module file) is loaded if no view is ever invoked on the page. And I'm sure Views would remain a disable-able module.
That is assuming, of course, that the rest of core is not rewritten to utilize Views for lists of nodes. (/node, /rss.xml, and the other examples given previously in the thread. ----- Cameron Eagans Owner, Black Storms Studios, LLC http://www.blackstormsstudios.com On Wed, Aug 12, 2009 at 10:10 PM, Earl Miles <merlin@logrus.com> wrote:
Chris Johnson wrote:
Few of them, except node front page. Tracker would be second most common, probably, even though it's slow. I'll have to admit I use the blog module on my personal site.
Any side effects of having Views in core, e.g. loading code not used? That's where my biggest concern would be now.
Very little of Views' code is loaded (obviously the .module file) is loaded if no view is ever invoked on the page. And I'm sure Views would remain a disable-able module.
Cameron Eagans wrote:
That is assuming, of course, that the rest of core is not rewritten to utilize Views for lists of nodes. (/node, /rss.xml, and the other examples given previously in the thread.
There's still no reason to make it so you can't disable Views and get rid of all that stuff and replace it with something else. Maybe make the 'ihateviews.module' which does all that stuff without it.
On Wed, 2009-08-12 at 10:50 -0700, Earl Miles wrote:
Out of curiosity, how many of those things do you use on your fast, lightweight sites?
tracker.module: Not fast.
If you're building a fast lightweight site that needs a tracker, you'd replace the core module with this: http://drupal.org/project/tracker2
blog.module: Does anybody *really* use this?
Sure.
node front page, river of news: The weight of 10+ node_load() calls vastly outweighs anything Views adds to this.
You'd fix this with one of these patches: http://tag1consulting.com/patches/load_cache http://drupal.org/node/111127
admin pages: It's ok for them to be a little heavy.
But why should they be if they don't have to be?
The blocks can be cached.
Caching is great, but it shouldn't be an excuse for unoptimized code. -Jeremy
Jeremy Andrews wrote:
Caching is great, but it shouldn't be an excuse for unoptimized code.
What does this mean? Are you saying that because generated queries are by default unoptimized they should not be used? I really don't understand what your point is here.
On Thu, 2009-08-13 at 07:50 -0700, Earl Miles wrote:
The blocks can be cached.
Caching is great, but it shouldn't be an excuse for unoptimized code.
What does this mean? Are you saying that because generated queries are by default unoptimized they should not be used? I really don't understand what your point is here.
Simply (and generically) that a cache should not be justification for slow queries. -Jeremy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeremy Andrews schrieb:
On Thu, 2009-08-13 at 07:50 -0700, Earl Miles wrote:
The blocks can be cached. Caching is great, but it shouldn't be an excuse for unoptimized code. What does this mean? Are you saying that because generated queries are by default unoptimized they should not be used? I really don't understand what your point is here.
Simply (and generically) that a cache should not be justification for slow queries.
I think that if we replace most or all of the listing queries by views, we'd make sure that they'd be optimized as well. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqELQkACgkQfg6TFvELooRQewCfcNMg8qYOu/Fja/nbqnWgrZ4N zVkAoKPspYgqF1r5mU5nRFtGMdeqvImf =lUsJ -----END PGP SIGNATURE-----
Jeremy Andrews wrote:
On Thu, 2009-08-13 at 07:50 -0700, Earl Miles wrote:
The blocks can be cached. Caching is great, but it shouldn't be an excuse for unoptimized code. What does this mean? Are you saying that because generated queries are by default unoptimized they should not be used? I really don't understand what your point is here.
Simply (and generically) that a cache should not be justification for slow queries.
I wasn't justifying a slow query, I was commenting on using the cache to offset the additional overhead of actually building the view. I have no illusions that building a query takes the same amount of time as having the query. Neither should we be under any illusions that from a purely performance perspective, a generated query will be as good as a properly tuned query. That said, individual views can be tuned to generate nearly identical queries, it's just that it doesn't happen in a vacuum. You have to intend to do it and know enough to do it. We make performance to flexibility tradeoffs all the time, so implying that performance should be the only consideration is also wrong.
It's not even close to that simple. Views is a lot more than "just a query builder". The query builder in Drupal 7's database layer is strictly a tool for building up an SQL query dynamically rather than as a literal string. That's extremely powerful and lets us do a lot of nifty stuff, but that's only a small fraction of what Views does. While Views will, hopefully, be able to leverage the core query builder for its Drupal 7 version (that was a design goal from the beginning, although vetting the success of that is still in progress), that in no way replaces the rest of Views. Really, as of Views 2 the connection to SQL per se is rather tenuous. A View is a collection of field and filter handlers that inject "stuff" into a query object, then the query runs, then each of those handlers gets a chance to render the bits of the result that it wants to. (That's something of an over- simplification, but that's the general idea.) What that "stuff" is is entirely up to the handlers, and the rendering is also greatly affected by the style and display plugins. There's work going on to allow the same framework to support non-SQL query objects, which is just plain sexy. Of course, at that point the new database layer in D7 wouldn't be of any use at all since the query being built is not SQL to begin with. On Tuesday 11 August 2009 11:29:11 am Earl Dunovant wrote:
Views is an query builder, and there's going to be an query builder in D7...couldn't views pretty much work out to a consistent UI for that?
On Tue, Aug 11, 2009 at 11:56 AM, Naheem Zaffar<naheemzaffar@gmail.com> wrote:
Talking as someone who has not used views extensively, has views really changed that greatly within versions?
Going by the numbers alone, Views 1.x was for Drupal 5, Views 2.x is for Drupal 6. Maybe I am wrong but I would assume that the changes from 2.0 to 2.5 the current release do not impact on the underlying infrastructure all that much?
And this is with a "freak" core lifecycle of two years which I assume will not remain the norm.
2009/8/10 Cameron Eagans
Why would you want views in core?
You put views in core and it is frozen. Nobody can do anything with it (as far as changing it: adding new features, reworking existing code, etc). As a contrib module, the Views maintainers can decide how they want to run the release process for Views, and I personally would like to keep it that way -- it allows for a LOT more flexibility and a much faster development lifecycle.
Plus, core is already weighing in at around 9.5 MB. Adding another 4.5 MB of code to maintain doesn't seem like a good idea to me.
-- Larry Garfield larry@garfieldtech.com
It would be a great accomplishment to get Views in core for D8. But there are major challenges to getting there: 1. Get core ready for Views. By this, I'm mainly referring to finishing the CCK in core effort, which is itself still far from complete. In particular, I don't think we should even consider starting to put Views in core until the CCK UI hits core in some shape or form. The low-level Field API also still has plenty of issues to be resolved (although these are largely on track for being done by D7 release). 2. Get Views ready for core. Let's face it, the current Views contrib module is not suitable core material. Views in core needs to be much leaner, it needs significant usability re-working (according to recent D7UX commentary), and it needs to be much more themer-friendly (according to recent Design 4 Drupal commentary, and my own experience). Of course, this isn't exactly groundbreaking news - we should all know that moving a module / API from contrib to core is never simply a matter of copying and pasting. As for "we do not do anything else for Drupal 8"... hahaha!! You're dreaming. Cheers, Jaza. On Tue, Aug 11, 2009 at 3:13 AM, Karoly Negyesi<karoly@negyesi.net> wrote:
I (that means I. Disclaimer: this is my idea. blame me.) would like to see
-- Views in core. Without Merlin burning out. -- more shops contributing to core. The biggest deterrent currently IMO is that their work might or might not be accepted and even if gets in, it might be two years before they can use on a client site. -- the security team to only deal with releases that have automated testing so they have a good chance of their patches not breaking core.
To achieve all this in one plan, I would like first to ask everybody who wants to contribute core to go to the Views queue and help out! Support requests, bug reports, many things are doable without being the Grand Master of Views. This has immediate returns in fixed bugs, or just a little bit less immediate with less load on Merlin resulting in better Views. But it does not take two years to get deployable results, not at all.
And then, if we have brought down the Views queue to a managable size, then we should write tests for Views. Again, this is something a lot of people should be capable of even without knowing the innards of Views and usable right now even with Drupal 6 -- simpletest is backported.
Once we have a lot of tests, we should commit them to core along with skeleton code that makes the tests pass. This is a radical but logical change to our core development model. Hopefully this can lead to many smaller patches striving to replace smaller pieces of skeleton code with real instead of few gigantic patches trying to get some major part of Views in core.
We do not do anything else for Drupal 8. No other major API changes just tests for Views which are immediately and easily backportable to Drupal 7, once again allowing for immediately deployable code. Obviously there will be changes as our old and hardwired modules get partially replaced by Views. However, this plan would hopefully allow for a short Drupal 8 cycle instead of a year plus long one and when Drupal 8 gets released, the security team has an easier work.
Another side benefit is that I can see people jumping over Drupal 6 completely with the D7CX movement quickly putting a deployable (I seem to like that word) Drupal 7 on the table. So relatively quickly (but still it gets more than two years) deprecating D6 wont be as bad. Also, as Drupal 8 won't break APIs as bad as usual, the contrib authors will have an easier job of maintaing D7 and D8 branches.
Another benefit is that the usability folks can work on a stable platform so Drupal 8 can be even more usable than Drupal 7.
I should list the drawbacks here but aside from a few crazy core developers (like little me) being a bit frustrated for being in a soft API freeze for Drupal 8, I can't see any. I will certainly be less frustrated over not being able to overhaul everything than I would be to being able to but working almost in isolation. There is a huge chasm between real world sites and core development and this would allow us to bridge.
participants (22)
-
Cameron Eagans -
Chris Johnson -
Damien Tournoud -
Darth Clue -
Earl Dunovant -
Earl Miles -
Earnie Boyd -
Gerhard Killesreiter -
Jamie Holly -
Jeff Greenberg -
Jeremy Andrews -
Jeremy Epstein -
Jim Taylor -
Karoly Negyesi -
Larry Garfield -
larry＠garfieldtech.com
-
Naheem Zaffar -
Sam Tresler -
Samir Nassar -
T L -
Victor Kane -
Walt Daniels