Note: This is a duplicate issue. See #1805996: [META] Views in Drupal Core for the current status of Views in Core.


Views, is currently the most installed module. It counts ~210k installations for D6 (~80%) and another ~260k for D7 (~60%) with a total of ~470k installations. D6 + D7 installations count a total of ~700k, which takes the percentage of Drupal sites using Views to a ~70%.

- So, why put 7 out of 10 users through the trouble of downloading and installing this module? It should instead be in core and all users would have to do is enable it.
- We could convert most of the core admin UI in views and get rid of duplicated code.
- We could convert some core modules to views (blog/forum/?)

- While we could clearly benefit if Views functionality was added in Drupal core, there is also concern that if Views moves in core, its progress will slow down to a stall.
- There's also concern that we'll bloat core if we keep adding functionality that is already available in contrib.

Proposed resolution

Perhaps we should move the "core" Views as an API in Drupal core and leave the heavy UI in contrib. If there is need for a UI in core too, then perhaps we should consider doing something really basic. The contrib module SimpleViews is an excellent prof of concept that we can have a minimal UI in core:

Remaining tasks

- Get this feature request approved ;)
- Figure out the specifics, turn this into a meta-issue and split tasks to separate issues
- ???

Discuss more. In this issue here and in the Views Developers discussion of Views in Core.

User interface changes

- The core admin UI might be converted to views where applicable (with whatever changes this implies).
- There might be a minimal UI for creating basic views in core.

API changes


Original report by Pasqualle

I am interested about the plans including views in Drupal core.
Is there anything planned for Drupal 7?
Which parts of views would be good to include in core?
What is the status of this issue?
Any links to discussions, issues, documentation?

Please keep this issue open and updated.


moshe weitzman’s picture

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

bsherwood’s picture

Title: views in Drupal core » Moving Views into Drupal Core
Project: Views » Drupal core
Version: 6.x-2.x-dev » 7.x-dev
Component: Miscellaneous » base system

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


ainigma32’s picture

Status: Active » Postponed (maintainer needs more info)

Bump. Does anyone have any news on this issue?

- Arie

Pasqualle’s picture

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

Alan D.’s picture

-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.

bsherwood’s picture


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.

timmillwood’s picture

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!

bsherwood’s picture

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.


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.

ainigma32’s picture

tirsales’s picture

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.

bsherwood’s picture


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:

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.

tirsales’s picture

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.

bsherwood’s picture

Drupal already has 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).

wretched sinner - saved by grace’s picture

Status: Postponed (maintainer needs more info) » Closed (fixed)

Oops - this is the older issue!

wretched sinner - saved by grace’s picture

Status: Closed (fixed) » Active
Issue tags: +Views in Core
bsherwood’s picture

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.

alexanderpas’s picture

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

tirsales’s picture

@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.

merlinofchaos’s picture

Status: Active » Closed (fixed)
bsherwood’s picture

Status: Closed (fixed) » Postponed (maintainer needs more info)


Was there a reason for closing this issue?

RobLoach’s picture

ainigma32’s picture

Status: Postponed (maintainer needs more info) » Fixed

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

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

- Arie

Status: Fixed » Closed (fixed)

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

mitchell’s picture

Category: support » feature
Status: Closed (fixed) » Active

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

RobLoach’s picture

Status: Active » Closed (fixed)

Views is a feature, not a bug!..... Go here to discuss why:

mitchell’s picture

Status: Closed (fixed) » Postponed

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.

webchick’s picture

Version: 7.x-dev » 8.x-dev

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.

philbar’s picture


olamaekle’s picture

Any plans now? I think it is needed in core.

bojanz’s picture

Maybe for Drupal 9? Might be a bit too optimistic, but we can revisit the discussion in 2013.
In the meantime, you're free to help Views evolve in contrib (it's already a whole new beast compared to when this was discussed, with a new UI and more features).

nbz’s picture

@30 - this is quite early in the release cycle to make such a decision - especially as considering the current release plans, it means waiting around 6 years for views to be in core.

Now, that may be for the best or even then too early, but 6 years is an awful long time.

bojanz’s picture

If the choice is between having to download another archive VS crippling the module and cutting its growth, you can guess on which side I would be on.
There is absolutely no reason why Views even has to be in core. Reducing it's size by having the building blocks (plugins, context) in core is a worthy goal.
The rest doesn't matter.

Plus, actually accomplishing something like that would require an army of volunteers who are just not there. Views in contrib is understaffed as it is.
You can't make software happen with "+1" and "subscribe" comments.
(This is not targeted at you @nbz, I'm just commenting in general)

philbar’s picture

Changing development to be more modular would make Views in the Drupal "product" much more manageable. Drupal distros are to the point where this is possible now.

+1 for have Views stay a module, but officially supported by and included as part of the Drupal "product".

#908022: Small Core / Drupal Distro

klonos’s picture

Stepping here a bit late, but still I'd like to tell my opinion on this...

@bsherwood, #11: Thanx Brandon! I wasn't aware of SimpleViews before I read this issue. I've added that project to the issue's summary as a proof of concept of how a minimal version of Views (API, simple UI etc) could live in core. I really like the idea of converting most of the core admin UI to views.

@tirsales, #12:

Of course - disabling core modules is possible - but: Why put them into core in the first place?...

Sebastian, I think one of the main reasons we put them in core is because it was proven that the average user doesn't grasp the idea of modules to begin with (#1167458: New users do not know to click on 'Modules' to extend their site & #1164760: [meta] New users universally did NOT understand that you can extend Drupal), let alone to send them to d.o to search/find, download, extract and enable one (at least 4 multi-step tasks). By having these modules in core, we only have to teach them how to enable them (process reduced to one task). Finding a better name is also being discussed in #1464964: Rename "module" to a more generic term so people new to Drupal understand what it means but I seriously doubt it's going to happen.

...Take forums - a very nice feature, but I would wager that quite a lot of drupal-sites never use a forum.

We won't be able to know this (have actual, measurable data I mean) until #1036780: should collect stats on enabled sub-modules and core modules is implemented. So, I'll take your wager ;)


While I understand the idea and the advantages of a mini-core, I don't get the whole "size of core" concern at all. Is the download package size an issue nowadays? ...or is the server space an issue here? I seriously doubt that - if so, those with that issue can safely go ahead and delete the subfolders of disabled modules under /core/modules. Is RAM usage an issue? Again, I believe not since disabled core modules do not load/bootstrap. Is maintainability an issue? Well, not if core maintainers never touch that code. It's still there, available for everyone to suggest improvements, but there's not enough time & coordination I guess. This is an entirely different matter though...

From what I see in the MAINTAINERS.txt for D6, for D7 & for D8 there is no maintainer assigned in quite a few of the core modules. It so happens that these modules are also mentioned in this issue as lagging behind (blog, forum, profile). But moving all "orphan" core modules to contrib is not the solution either. We cannot simply remove features that we advertise for Drupal as provided out-of-the-box. Since there are a lot of contrib modules out there either replacing the ones in core or extending their features, then (also taking these contrib modules' popularity and maintenance activity into account) one thing that can be done is to urge their maintainers to apply as the respective core modules (co)maintainers. A second step would be to try to move these contrib modules' "core" features as an API in the respective core modules. Features that would qualify as APIs will be easy to spot: it'll be the code that does the same thing for all same-purpose contrib replacements out there. To that end, I don't see why all the contrib forum -for example- alternative contrib maintainers don't form a team and push things to happen. Once again to make it clear: a matter of coordination and agreement between people - not a problem with the amount of code and different modules included in core.


klonos’s picture

...hope you all like the new issue summary ;)

Please check and add/edit in case I've missed anything or got things wrong.

Gaelan’s picture

Something worth knowing: 1 MB of the views code is simply images in the help. If we shrunk that down, we could reduce the size of views by a lot.

Gaelan’s picture

Issue summary: View changes

...updated issue summary to comply to standards:,

lpalgarvio’s picture

more accurately, Views 7.x-3.5...

by directory:

/css: 67,2 KB
/drush: 15,5 KB
/handlers: 322,9 KB
/help: 1,30 MB
/images: 13,8 KB
/includes: 387,4 KB
/js: 56,7 KB
/modules: 549,7 KB
/plugins: 446,6 KB
/tests: 410,4 KB
/theme: 57,7 KB
/views_export: 284 Bytes
/: 213,4 KB

Big Total: 3,90MB

by functionality:

Views UI:
/css/views-admin*: 62,3 KB
/js/views-admin.js: 37,7 KB
/plugins/views_wizard: 58,8 KB
/theme/views-ui*: 3,5 KB
/views-ui*: 28,9 KB

Total: 191,2 KB

Views Export:
/plugins/export_ui: 15,3 KB
/views_export: 284 Bytes

Total: 15,5 KB

/drush: 15,5 KB

Simple Tests:
/tests: 410,4 KB

Advanced Help:
/help: 1,30 MB

Views Core:

Total: Big Total - other totals = ~2 MB
and i guess some code could be removed from /includes, /modules, /plugins, /themes, .module, etc...

lpalgarvio’s picture

regarding the Views API only vs Views API+UI, perhaps the best approach should be to move the Views API only.

this follows more or less the path that CTools and also CCK for D7 took when parts of its code got into D7: migrators and some UI stayed in contrib.

at very least, the Help system (advanced help), drush support and views export (deprecated by bulk exporter/ctools exporter in ctools and features) could probably be left in contrib.

as for Simple Tests, since core also ships with some (2,3 MB), maybe they need to by moved to core.

webchick’s picture

For people who haven't seen this, this is basically already happening:

The 8.x branch of Views is working against the current 8.x version of Drupal. After some CTools dependencies are in, the plan is to move the entire thing in, UI and all, because the value of it being in core is greatly diminished unless people can actually use it.

If you want to help, most of the effort is happening in

webchick’s picture

Also D8 is already 5.5MB zip (up from 3.4MB in D7) due to Symfony. File size is a false comparison. If the file size is bigger, but you gain more functionality, it's still a major win.

lpalgarvio’s picture

yes, size is always relative.

what about turning some administrative pages into views? ala
is that planned for D8?

webchick’s picture

It is if someone works on it. :)

Sylvain Lecoy’s picture

If we want to move Views in core, we need to create an API first, I started a discussion here:

EDIT: Also, I have just a little concern, what is so wrong having Views as contrib ? Following #1260214: Choose your Drupal let's put the effort of doing Drupal distro. That's the way unix succeed by the past. That's also the way Dries tell us to do since 2006.

I believe in a cleaner separation between the “product” and “framework” sides of Drupal: looser coupling, better and more consistent APIs.

Where our visions collide, is making Drupal core smaller.


I am not against Views, but I found its architecture really not matching the framework concept that we build upon Synfomy 2. In fact, as a developer, having Views in core is not of my interest unless we manage to create a quality API. Views is a really good product (which has flaws of course) but not a platform neither a framework.

Unless we want drupal to be a good product, I see no benefits - as a developer - to include it in core.

pounard’s picture

I won't troll in here, already done so much on g.d.o, but just in case for people that didn't had the chance to read it: I really think integrating Views as it exists is a major error. Its design comes from the past (really early past, PHP 4) and is definitely wrong. It will be hard to maintain. There is no clear API, interfaces and no real separation of concerns. I'm not always worried by the lack of separation of concerns, but I'm definitely worried when it's in 2MB of code. That said, there are a lot of good ideas in Views, and lot of bad ideas too. I know that stepping back a few hours and try look at the big picture in order to refactor it is definitely not an easy task, especially on such huge codebase, but its potential integration to core is the right moment to do it, if it's not done right now, it will never ever be done.

tim.plunkett’s picture

@Sylvain Lecoy you have clearly not been following the work of VDC. You are describing Views 7.x-3.x, and your comments are as incorrect as they are inconsiderate.

pounard’s picture

I do follow from time to time the VDC tag, but I can't see everything. There is a lot of effort made to normalize everything with what D8 brings, and that's good, but that doesn't mean the design of Views itself radically changes or changed.

EDIT: I also follow the code on the 8.x-3.x branch of the views project sometime.

Sylvain Lecoy’s picture

@tim.plunkett I am pulling regularly the 8.x branch (on a daily basis). I may have missed some stuff but I am actively following the issue list tagged VDC. Would be positively curious of work that I am not aware of.

Maybe you are refering at Data Sources?

EDIT: Also, you saying that I am hostile to Views, but as a developer, the Views project is hostile to me (for reasons that I explained in g.d.o). But still, when I started worked with views 2 on drupal 6, the doc was a bit hard to digest, moving to views 3 on drupal 7, still unclear and with one more dependency (ctools). When I tried to open the View class to understand, the size of the object has stopped my efforts: I was not prepared for that.

When I found myself spending more time on understanding how to work with Views, than working against Views - that is not using it - I decided to let it alone. My thoughts was confirmed when I saw the time it took to port to drupal 7 (nearly one year). So yes my comments are inconsiderate, but have you ever considered that the "API" is inconsiderating most developers here ?

You are taking in consideration the 70% of users/developers using Views but not taking in consideration the 30% that does not use it, if it is just for the sake of not having to download one extra package, then I think its futile. There is distributions for this: Choose your Drupal.

Michelle’s picture

Having Views in core isn't just to avoid downloading one module. There are many custom things in core that could be done using Views instead to make them more flexible and reduce code. It's also about first impressions and what Drupal can do "out of the box" and Views is a clear winner there.


pounard’s picture

The UI is a clear winner, it's true, what's inside a lot less IMO, not for living side by side with the new Drupal that rises since the Symfony inclusion. EDIT: A lot of those "custom things" are actually not that custom. With the numerous widgets available we have, the SQL query abstraction, EFQ and other things, core is already using high level APIs for almost everything. I don't think that there is that much "custom" in it. There always will be custom as long as there is business, no custom would mean nothing.

webchick’s picture

Sylvain and pounard, please keep your soapbox to We don't need two parallel discussions about this same thing happening.

This is an issue for helping with implementation of this feature request. If you want to submit patches to Views to clean it up architecturally and API-wise, go for it. Otherwise, please step back and let the people who want to do the work here carry on.

webchick’s picture

Priority: Normal » Critical

Also, escalating to critical. The work the Views in Core team is doing is already uncovering a number of underlying API limitations in CMI, Entities, and other subsystems, so it's an incredible asset to ensuring Drupal 8 is battle-tested, not to mention the obvious end-user benefits.

xjm’s picture

Status: Postponed » Closed (duplicate)

This issue is from 2008 and does not summarize nor reflect the Drupal 8 Views in Core initiative (a.k.a. VDC). A separate core issue will be posted once the initiative has a working core sandbox, which should be in the next several weeks.

Meanwhile, you can see the initiative's issues and progress in the following places:

pounard’s picture

If that matters, I don't trust this roadmap, I don't trust Views either, and I don't believe that anything of Views will be beneficial to core alone. That said, I yield and let you do bomb Drupal core in peace.

klonos’s picture

Status: Closed (duplicate) » Postponed

@xjm: while I respect the reasons for #52, I think that while there is not a separate issue filed to point to, this shouldn't be closed as duplicate. If the does not summarize VDC, then please update the issue summary - that's what we have it for. Hell, if that's the reason, I'll just copy-paste the text from the VDC Roadmap/Initiative pages to the issue summary.

Reasons for setting it back to postponed (besides the reason already stated and the reasons why it was set as such before) being that I personally find it easier to follow issues while I cannot do the same with search result pages and documentation pages. So, till we perhaps have #1304216: A user should be able to "follow" individual pages of content and receive email notifications for new comments please let us interested in the progress of this task have this issue to follow. Thanx.

If you still feel strong about closing this as a dupe, then please file a separate issue and copy-paste the summary from the VDC Roadmap/Initiative page and link to it. Thanx again.

PS: ...would it help if this was a meta-issue?

Michelle’s picture

I have to agree. I went and looked at the links and was disappointed there was nothing I could easily follow as a non-participant but interested observer.


tim.plunkett’s picture

Priority: Critical » Normal
Status: Postponed » Closed (works as designed)

I was just told this was reopened again. You may change the status back to whatever you like in the future, just know that no one actually working on Views in Core actively follows this issue or will be using it in the future.

klonos’s picture

Priority: Normal » Critical
Status: Closed (works as designed) » Postponed

Hmmm, right. That's the way to go. Simply ignore everything I said back in #54 plus the 38 people following this issue. Heck, I've been working with Drupal for 3 years and I know my way around enough to simply use the contrib module if this doesn't get into core. Why should I care about this (apparently "private") initiative in the first place?

I just don't get how this issue being left open effects any of the developers involved in the initiative if they're not following it anyways. Can't you just unfollow and leave it set to postponed for us? It doesn't even have the "VDC" tag, so it won't even end up in your queue.

...Oh, btw right after posting this I'll simply go ahead and unfollow showing the same kind of community spirit. Guess the devs don't need the community to know the status/progress and will have the time to test things by themselves. We'll have to wait for a year or so and then find out if Views was actually included in D8 core or not. It'll be a surprise for us all. Yey!

xjm’s picture

We'll add a link here to the new issue once it is available.

@klonos -- Sorry, we didn't mean to give the impression that the initiative is "private"--quite the opposite--we just don't have a core sandbox ready yet and so the work is currently going on in the Views 8.x-3.x branch until the non-core dependencies are resolved. It's just that this issue predates the initiative and is sort of a distraction in that regard because it's not current or accurate, nor am I going to spend my time reading all the comments in here from years ago and replying to them. :)

@Michelle -- I don't understand the claim that there's "nothing I could easily follow as a non-participant but interested observer"--the progress report includes a very high-level summary, as does the roadmap. They should be accessible to most developers.

Please join us in #drupal-vdc or check out the links above if you'd like to jump in and help. I'll try to remember to link the new meta here once we've filed it. More announcements coming soon. Thanks!

xjm’s picture

Issue summary: View changes

...updated the usage stats of Views & Drupal core.

Michelle’s picture

@xjm: I just meant that none of them had a "follow" button. Since I'm not actively involved in the effort and following all the related issues, it's handy having a "meta" issue like this to follow so it pops up in my tracker if something noteworthy happens. It's not a huge deal to me and I'm not going to mess with the status but I just wanted to say I understand klonos's wanting to have an actual followable issue to latch onto.


DamienMcKenna’s picture

Should we really have "critical" issues that are "postponed"? :-)

mgifford’s picture

How does the "Views in Core" thread compare with the "VDC" - Views Drupal Core thread?

There's a lot of interest in Views in Core, but Google is sending folks here.

This page is out of date too -

Let's point folks somewhere rather than just say this is postponed.

lpalgarvio’s picture

nice summary juan!

xjm’s picture

Status: Postponed » Closed (duplicate)
xjm’s picture

Title: Moving Views into Drupal Core » SEE ISSUE #1805996 -- Moving Views into Drupal Core
Issue tags: -Views in Core

Adding a note to the title for people who might not be familiar with issue queue conventions.

xjm’s picture

Issue summary: View changes

Direct people to the correct issue.