Moving Views into Drupal Core

No progress has been made to date. This is looking very unlikely for D7.

Moving to Drupal issue queue for more exposure. Even though moshe has stated that it is unlikely for D7, I set it for the most current drupal dev snapshot (7.x-dev). We can move to 8.x when possible.

I would like to see views move closer to core as well. +1

Subscribing...

Bump. Does anyone have any news on this issue?

- Arie

There is one views related issue:
#322344: (notice) Form improvements from Views

-1 Two reasons not to move the entire module into core:

As soon as a module is moved into core, the development of that module slows to a crawl. Just look at Poll. Around since 4.7(?) and it still can not handle many basic Poll requirements like anonymous voting of users, such as cookie based voting. Another huge issue with it, is caching and anonymous users.

The second reason is simply the size and negative impact on performance. Using the most simplistic approach to emphasize this, the size of Drupal 6 is 3.3M, and Views adds another 2.4M. Core Drupal 6 installs are already marginal on many shared hosts, and the baseline requirements would need to be increased if views were standard.

Alan,

I do agree with you on the points that you made. I do notice that when code gets into "core" the development slows to a crawl, so I am with you on this. Just look at poll, forum, blog, etc...

I do think the basics of Views should be added to "core" though. The nice thing about views is that it is almost endlessly customizable and the nice thing about code being in "core" is that it's guaranteed to be there. I guess what I am saying is maybe getting Views-lite into core should be the goal. Also, most of the space required by views is taken up by the UI. Maybe the Drupal developers could create a more friendly framework that can 1) be used by other modules and 2} makes the burden on the views developers lighter.

One of the praises I have with Drupal is that it is moving into a more lego-like system. Gone are the days where modules are creating "hard" content types and duplicating code that views can do.

To the best of my knowledge, what they are doing with "fields in core" for Drupal 7 is what they should do with Views. Get the "core" of CCK into D7, but leave most (if not all) of the widgets and field types to external module developers. I think this provides the "best of both worlds" attitude.

I see "fields in core" as a catalyst to reworking the profile module and if Views gets in D8 I see it as the catalyst for rethinking the forum and blog module. Which I would like to see get a MAJOR overhaul.

I know of, understand and agree with the negatives of putting Views into core, but there are so many pages in Drupal which would be so much better if they were generated by Views. The good out weighs the bad!

I think if they can do the same thing with views as they are doing with 'Field API', I think it could work. As long as they make it flexible and allow other contrib modules to expand on it.

@timmillwood:

I also agree a lot of /admin pages could be changed into views, which would allow users to change and expand on the content/comment pages.

See also http://drupal.org/node/363411

- Arie

Well, I know that I am very new to drupal, ntl I'll give my 2 Cent to this topic and hope not to annoy :-)

What would be the possible benefit of including more stuff in the core? I myself like to keep cores minimal (I personally believe the drupal-core is too big already - it includes a couple of optional items (poll, blog, forum,..)).

Why not create several profiles instead? (Say: "Drupal Core" -only including core, "Drupal Normal" - as drupal is now, "Drupal Recommended" - including Views and whatever else), where "Drupal Recommended" could be the default download. I agree that profiles tend to get ignored nowadays - okay, make a couple of "standard profiles" more visible on the core-page (e.g. including them in Download-lists), etc. Like this modules (and Views, Polls, etc are just this - optional modules) could be opted-out by experts, with a default opt-in (for average joe) and could be developed more "efficiently".
The concept of profiles is a wonderful one - so please, go the full way: A minimal core and extensive profiles! (Even better: Several profiles to 'add together', like a profile giving three/four/whatever options (say: blog, forum, views with needed modules each) and loading needed modules automatically).

Don't forget: Most pages on the web simply don't need most of the "core" modules / optional modules, and just need a (very) basic web-content management system. This is especially true for pages on shared servers.

@tirsales:

The benefit of adding Views into core would be:

1. Making Views API available for all modules without dependencies
2. Ability to make admin pages customizable (admin/content/comment or admin/content/node)
3. The potential to rework blog, forum, etc... as a view instead of a module.

I do agree to some extent that Drupal core is rather bulky. But Drupal core is there to satisfy most users out of the box. It needs to have a few basic modules out of the box.

Also, you are not required to enable any core modules. So even though you may have modules on your web server, it doesn't mean Drupal is including the code when it bootstraps every time. Just don't enable the modules, and Drupal can stay nice and light.

I would also say that Views UI is the behemoth of Views. Maybe creating an easier UI to include in Drupal core like Simpleviews:

http://drupal.org/project/simpleviews

This way the Views API can get included as well a Simpleviews-like module. We can also keep the default UI in contrib.

Another option is to include a limited API in Drupal core and keep the rest in Views.

Yes, I can imagine quite a number of benefits by Views (I am using it myself everywhere I can) - still I personally do not believe that this is a reason to further expand the core. Standard Profiles would give "most users" satisfaction out of the box - and a small core allows more experienced users for smaller installations.
Of course - disabling core modules is possible - but: Why put them into core in the first place? Take forums - a very nice feature, but I would wager that quite a lot of drupal-sites never use a forum.

A "download needed modules" would give the same "no need to manually download dependencies"-feature, as would (for most users) to change the standard download from "core download" to "standard profile". Most users would never need to know the difference, but development could be separated. And reworking forum/blog/etc into "Views submodules" - well, this does (in my opinion) give further fire for my point: A core - as small as possible (that is: without any optional modules), several profiles (and - even better - module combinations as "additional profiles", so you could install "forum-profile" which includes "forum and all dependencies") - and a fine-tuning of available modules aside from core. As mentioned before, this enables for a faster and more flexible development of e.g. "forum using non-core modules".
Apart from that: A small "minimal views-API" that e.g. Adminpages could use, and "views itself" as module would result in a similar solution - a (minimalistic, non-optional) core and a (very beautiful, operational, wonderful) set of modules, e.g. "Views", "Forums", etc

I didn't have a look for a "automatically download modules"-module (could be limited to core by default with possible updates like "add another repository"), and I know that quite a number of expert admins wouldn't use it - but then again, they should be able to load modules by hand, thus wouldn't mind a smaller core. Oh and a "automatically download module" would give supporters a great tool. And I apologize for getting offtopic.

Drupal already has installation profiles @ http://drupal.org/project/installation+profiles. While they are not "official" by any stretch of the imagination, they at least fill a need.

Also, adding Views to core may not make Drupal as bulky as you think. Here is an example:

1. Add views (minus UI)
2. Add a simpleviews frontend to keep things simple
3. Remove blog and forum by creating a view that comes shipped with Drupal.
4. Make all potential changes to admin pages (remove redundant code).

Oops - this is the older issue!

I also forgot that the 'tracker' module could be completely replaced if Views API got in core as well. So we add one ridiculously flexible and extendable module and we could potentially remove three modules right off the top. While blog, forum and tracker only take up 95KB's of space, that's at least removing some redundant code.

So if we take in just the API and a lightweight frontend, that's roughly 500KB's of code. Minus the 100KB for all the replaced modules.

I wonder what other code could be made redundant if Views got into core? All the code to generate the admin pages? Maybe?

The idea of moving Views into core is not about just adding it in, but to find out where it can make Drupal more flexible while making as little performance hit as possible.

+1 for something like Views API in Core for 8.x or above ;)

@specmav: I know, that profiles exist - otherwise my proposal to "make a minimal core and extensive standard-profiles" wouldn't make any sense. What I meant was the following: Exchange the "standard download link" from "core" to "standard profile". Make core minimal (not including anything optional) and "standard profile" including whatever.
Add a *minimal* views-api to core (that is: Only what you need in order to support admin-views, etc), move everything else (that is: everything from views that could potentially be optional) to a module. Get that module into the standard profile.
Like this, the majority of users would have everything they need (views, forum, etc) - but the (specially guarded) core would be minimal.

In my opinion this gives the best of two worlds: Minimal core (that is: flexibel development of everything else, a small guarded area) and a "large enough" standard download for the majority of users.

@Merlin:

Was there a reason for closing this issue?

Take part in the Views Developers discussion of Views in Core.

Sounds like a better place then a support request...

Setting this to fixed but feel free to reopen if you disagree.

- Arie

Automatically closed -- issue fixed for 2 weeks with no activity.

Is it really that hard to tell the difference between a bug and feature? You tell me: #441358: Bug or Feature?.

Views is a feature, not a bug!..... Go here to discuss why: http://groups.drupal.org/node/19097

Rob@: So you agree it's a feature? The whole bug/feature thing is actually out of place, because...

I realize now it was marked as 'support request.' That's probably why ainigma32 closed this issue saying, "[the group discussion] [s]ounds like a better place [for] a support request."

imho, the best way to file this is postponed till #363410: Port Views to the Drupal 7 database layer.

This is obviously not happening for Drupal 7. It would still be very good for folks to work on porting Views to D7 within the remaining time for code slush, however.