Per-bundle node listing pages, blocks, feeds.

I took a quick stab at what this might look like and created a single custom module that does all of what's described above. if we were to refactor a couple of node module helper functions (notably node_get_recent(), node_page_default(), and node_feed()) we could probably eliminate about 2/3 of the code. As it stands it's only about 200 lines.

Thoughts and feedback on how to best turn this into a patch (rather than a separate module) are welcome. I like the fact that it provides an obvious on-ramp for the Views module; it could easily provide default views that mirror each of these content type pages and blocks.

Two details that probably need loving. First, the menu path (/content/$typename) is a bit crap, since there's no /content url. Ideally, we'd use something other than /node for the promoted content listing page, and we could have that be the top-level path. We'll see. Second, when you choose to enable a listing page for a given type right now, it also inserts the listing page into the breadcrumb trail when content of that type is being displayed. Should that be part of the behavior? I'm not sure, but providing it as a default when the listing page is activated certainly simplifies the creation of a nicely built-out site.

Also, I think it's probably worth removing the toggle-switch for RSS feeds - we don't allow peopel to turn off RSS on the front page, and toggling it for the individual content types is probably unnecessary. A global toggle switch ala #28337: Add permissions to disable RSS feeds would make more sense.

...And for those who want to see this get all official-like, the 'Lister' module attached above now has an actual sandbox project.

Yep, that's exactly the reason I'm hoping it goes through (It's listed in the first post in this issue). The language is currently a little awkward, but that would smooth it quite a bit. A couple of other possible directions for this module have been suggested by the kind folks in #drupal:

1. Refactor node_get_recent(), node_feed(), and node_page_default() to do the bulk of the work
2. If a content/$type page is empty, display a 'No content available' message and an 'Add content' link instead of a 404 page.
3. INSTEAD of having node module do the bulk of the work, keep the functionality in a separate module AND move the front page from /node to /content, and have this module take it over. That would accomplish the eternal request of allowing people to disable /node if they don't want people seeing a duplicate URL, or if they aren't using the promoted flag at all.
4. Use EntityFieldQuery instead of db_select().
5. Make the sidebar block themable.
6. Add a 'view $type content' permission that acts as a content-type-wide toggle switch, rather than a per-node toggle switch. Then use that permission as the default access control on the listing pages as well.

I'm particularly interested in #3, because it would split out a lot of oddball special casing in Node module, and make the "Make node module optional" patch that's been floating around a lot more doable. Baby steps, though.

Regarding entities, I think we could probably benefit from some generic 'get me a list of things and show them' code. Doing an unfiltered entity-level listing page would actually bring us very close to the standard /node page behavior, which definitely interests me.

Because it's being driven by the roadblocks we're hitting while working on the Snowman project, the actual end-user-facing functionality is actually what I'm most concerned about in this patch. Every site that's been built for that project has run into the "I can't just list nodes of X type" problem, without fail. None have run into similar issues with any other entity types, at least not yet.

I'm not sure that the /blog and /poll functionality would be a great mix either, for the following reasons:

1. It would require a fair amount of extra configuration, including customizable paths for the listing pages. While it's not a show stopper, it introduces a lot of extra configuration questions and possible collision problems
2. blog module, forum module, and poll module all do extra "stuff" on their pages that goes above and beyond a simple filtered teaser list. They're good examples of modules doing the heavy lifting so that a 'simple listing page' is unnecessary.

One possible option is to include some kind of option in the node type info itself, specifying that there's a listing page or block provided by the module that exposes the content type. If one is made available, the 'generic' listing page or block can't be turned on. I'm not sure there's a lot of value in that, though, especially if we don't have the listing page or block turned on by default. Turn on blog module, and it provides a page. If you go in and manually add another listing page, it doesn't hurt anything. In addition, it would lead towards tight coupling of the Listing functionality and the general node type system, which I'm hoping to avoid.

I'm open to alternative approaches on any of these, though. Just wanting to hold the line on the original intent, ie "Provide a simple way to list stuff with no fuss and no muss, then punt to Views/contrib for anything more."

Some related patches that might be worth looking into:

• #404300: "Promote to front page" is a misnomer
• #545758: Make q=node behavior optional/configurable
• #1066830: Change /node path to /latest and allow admins to disable.

A final idea about the blog/forum/poll intersection. node_type_get_types() lets modules return custom flags in the node type definition, and they get cached along with the 'standard' information. At least in theory, that would mean that a module could include 'listing_page_already_provided' => TRUE or something like that to disable the option for module-provided content types.

For blog and poll, couldn't we move them and provide url aliases in the upgrade path or something? I did not look at extras they might be adding though, agreed if those have extra special-casing it's OK to leave them.

We could -- blog module's top-level page at /blog does just list blog posts, so aliasing it would work. The only trick (I think?) is whether we would want the sub-pages linked to /blog/$uid or /content/blog/$uid. The breadcrumb trail behavior that's current provided in Lister would have to be disabled or overridden as well, since the blog nodes themselves would be a level or two deeper.

Poll is probably a good candidate, though, as I look closer. Currently it exposes an unordered list of poll links rather than teasers. Moving from D7 to D8, I don't think there would be a huge amount of pushback just nuking that custom page entirely, enabling the centralized listing page, and aliasing /polls to /content/poll. Removing the custom page would give us 50 lines of code for free! ;-)

one of the top complaints about Drupal listing pages from the mutlilingual realm is that there is no control on their language filtering. Although Drupal supports node language association (even if you don't have translations turned on), none of the listings will let you list only nodes in certain languages.

Hmmmm. If we were to add a custom tag to all of the queries being run by these listing pages, would the language/locale configuration screens be able to offer their own checkbox/selection behavior? IE, 'Filter listing pages by language', then hook_query_alter just the listing page queries to add an extra condition? That would allow the complexity to still live on a module-by-module basis, and other modules that offer listing pages would be able to tag themselves as supporting the same functionality...

Hm. I was tempted to ask whether we don't waste time here in light of having Views in core at some day in the future, but well, yeah, I know, still a long way... Hm.

An excellent question. Basically, Views isn't in core and I haven't (yet) seen a credible proposal to get it there. I'm against creating a "customizable page builder" in core, but now that most content types are in CCK rather than custom modules like Poll or Blog, we need some way of listing them. If/When Views goes into core this module can be replaced with a set of Default views, but the decisions being hashed out in this thread (what should be displayed on the page, what options should be selected by default, where the paths should live, etc) are all ones we'd have to make when building out default views, too.

the idea for Drupal 8 not that locale module will do this magically for everybody else, because, frankly that is what i18n module did all these years, and it is a major mess.

Hmm. I can see that. This feels like it's a general issue that we may run into all over core as different systems are decoupled from each other. The tag-it-and-hand-it-off approach is one that we're taking in similar situations like node access control, for example. This is a problem we'll probably be encountering on Taxonomy pages, too.

Now for the concrete suggestion, the question is if the same setting for all these listings is appropriate. Do you use the same "how many items to display", "which ordering to use for display", "what properties to display" logic for all these listings? Blog, poll, taxonomy, other content types, the front page, etc?

My philosophy going into the patch is something like this:

1. The Drupal 'Core product' should provide good, usable defaults that allow people to build out a reasonable site skeleton
2. The core product should provide global toggle-switches and options wherever possible, rather than lots of granular configuration.
3. The core product should punt to contrib for complex/granular configuration, unless providing those options tools in contrib is impossible.
4. When end-user-facing features are provided in the core product, they should be alterable or completely disable-able, to be replaced in contrib.

Given those principles (which I understand not everyone shares, naturally!) I'd favor either no control over the number of items, display order, and display style on listing pages, or a single global toggle-switch that applies to all listing pages. If a content type (like blog) needs a very specific set of options for its functionality to make sense, or it needs "Defaults plus X," it should implement its own custom listing page, because that custom presentation logic is integral to the concept of, say, "Multi-user blogging" or "Forum navigation." That would keep the custom logic custom and the 'Simple listing page' logic simple (and easy to replace).

One of the concerns I have about leaving language-awareness up to each individual module is that it's unclear what different 'language display' philosophies make sense. I can think of four off the top of my head: Listing pages should display the site's default language, Listing pages should display all languages, and Listing pages should display the currently logged in user's preferred language. Fallback to a language-neutral version, or some sort of negotiation if the 'preferred' language isn't available, would probably make sense. I can't help but think that centralizing that logic in some way, and allowing listing pages from various modules to take advantage of it if appropriate, is preferable to reproducing the same config options and logic everywhere.

Perhaps I'm misunderstanding the nature of the problem? Admittedly, I've only worked on a small number of sites that really utilized the localization system.

I would support this direction for the standard profile it makes sense to have better defaults when it comes to created listings and blocks. I have no idea why you placed the admin settings like that though.

Toggling the feature on and off on a per-content-type basis seemed to make sense; other than that, there's no particularly solid reason for where the settings went. I'm open to any and all ideas on that front.

We have to consider enabling this functionality for basic page/article content types or not, by default

That's an issue for the profile to figure out -- clearly Minimal isn't going to use it. The 'Snowman' profile will be using it for a number of content types, which is why the functionality is needed. The standard profile is in an odd place - articles are already promoted to the front page by default, so they have an obvious place to live, while pages don't. I'm not sure a listing page of pages makes a lot of sense, though. Open for discussion.

There is little to no discoverability of these pages/blocks. We have a page where you can "find" blocks, but not a page where you can find pages.

Emma Jane Hobgin in IRC has suggested that the listing pages themselves should be added to a sidebar block, or perhaps a custom menu that's displayed in a sidebar block. That would make them relatively easy to enable/disable, just by editing the menu block.

Also, I'm not particularly happy with the /content/$type paths use for the pages, but I'm stymied trying to come up with a better location. Simply placing the pages at a top level url like http://sitename.com/$type could work, but the odds of a collision with existing paths is very high. /node/$type doesn't work, as we've already overloaded the /node path beyond recognition. I'm leaning towards the idea of moving the default '/node' listing page over to the same url path as the pages generated by this feature. In that model the default front page would be at /content, the listing pages would be at /content/$type, and so on. That would leave /node as an orphan path, however, and people wouldn't be able to hack /node/1 to get back to the root level page. I think better handling of the /node page is probably a separate issue.

You solve the problem of configuration of these blocks/pages by saying, there should be no configuration. Which makes sense in many ways, but also short term thinking in educating our users of this flexibility. This is my biggest concern, I'd love to discuss this more on IRC.

This has been a topic of some debate, and I feel really strongly that the long term solution is to use Views. Period. Once we start adding a pile of different configuration options to these pages ("Only show things tagged with X, only show articles with a photo attached, show 20 items on this page but 15 on that one...) we're on the road to rebuilding Views in core, and that's a losing game. Getting Views into core is a good goal, but building it piecemeal on top of a simple feature like this would be a recipe for #fail.

Based on the R&D sites we built for snowman earlier this year, the "80%" problem is not being able to list content types on their own page, and the simplicity of the solution is a major feature IMO. I'm happy to discuss it IRC, though. ;-) I'm popping in and out of #drupal-contribute, and there's also a #drupal-snowman channel that I and a number of people hang out in.

We could consider placing the creation of these blocks and pages in their own vertical tab. This would follow a similar pattern to other places in core, such as menu creation as vertical tab in content creation.

Makes sense. That also gives other modules a sensible place to put related options. Any thoughts on what tab title would make sense for it? Display pages? Viewing options? Listing options?

A couple key issues are fixed in the dev sandbox version of the code. The config options are now in their own vertical tab and have descriptions, though the JS to update the vertical tab isn't in place yet. As per webchick's comments in IRC, turning on a page and visiting it when there's no matching content nets a "No content has been created" message, and a link to create a node of the appropriate type.

Keeping the code in a separate module makes sense right now but it's definitely requiring some duplicate code. I think it's obvious after some investigating that the code to generate these pages should live in the same location as the code to generate the standard /node page and /rss.xml feed. That leaves us with two choices:

1. Roll this code directly into node module, and refactor node module's node_page_default and node_feed functions to support it cleanly
2. Move the site front page and the standard feed OUT of node.module into this module, and start rolling a real core patch.

I lean towards the latter option, because I dislike the hard-coded nature of the front page listing of promoted content, but I'm on the fence about which direction to pursue. Thoughts, anyone?

OK, this has been brewing for a week or so and I had a chance to chat with Bojhan in IRC about one of the issues that concerned me the most: the path handling. He feels that inconsistency in the paths is acceptable at this point -- ie, /node, /node/1, /content/articles, and so on -- because few users actually navigate by URL. It still leaves us with the problem of menu-tree management; IE, does /content/articles get highlighted in the nav menu when you're on an article node. I lean towards 'Yes,' and I'm going to write the patch with that assumption in mind. Because the goal is to provide a single checkbox that handles all reasonable behaviors, I think that's probably for the best.

For the time being, I'm going to punt on the node module separation issues and just roll this functionality into node.module. Subsequent patches that focus on splitting this functionality (and the front page) out into a separate optional module should come later, unless someone is feeling super ambitious.

Here's a first pass at an actual patch; it's definitely still rough and the node/%node_type paths are currently not possible -- the menu router collapses all wildcards to '%' in the actual router table, so it collides with node/%node. I've got them at content/%node_type as discussed, at least for the moment.

Outstanding problems:

• Page generation duplicates node_page_default() code.
• Probably should use entityFieldQuery() rather than db_select()
• Function names are a little funky, but that's par for the course in node.module.
• Proper title should be generated for RSS feeds. Perhaps '[Site name] - Latest [type] content'?
• Node Type Page needs a summary value for the 'Content list' vertical tab.
• Paths still kind of suck; using /content is crummy, but node/%anything doesn't work.

Potential follow-up-patches:

• Block generation code should probably be themable.
• Breadcrumb trails/active trails don't reflect the sub-listing pages. Discussed this with Sun and it might be a future feature request.
• This functionality, the default front page, and the default RSS feed paths should all be moved to a separate module. Probably best save that for a future patch.

At this point, it would be great to hear some feedback from both UX team members, site builders, core devs, and core committers who have thoughts or input on this.

1) It is probably better to put the settings in a separate field set rather than vertical tabs, if we redesign field ui this might fit in better. But its a bit weird to hide important "creation" functionality in meta vertical tabs.

Hmmm. That would make this the only core functionality for content types that's NOT in a vertical tab set. Is that kosher? I'm not against it, just wanted to make sure it followed the existing patterns. Since it's also an easily toggle-able behavior I assumed that it wouldn't be problematic leaving it out of the main flow.

2) The drupal_set_message after enabling this configuration is missing. It should mention a block is created at blocks and a page is created at content/article/

Good catch, thank you! I hadn't even thought of that...

3) There is no block title that a user can change?

Admins can override any block title -- we don't have to make special provisions for it here. Is there a downside to letting them use the common "Custom block title field?"

4) The checkbox/description could probally use some work (for example, Create a page that lists *article* content).

The only downside to this is is that when you first go to create a content type, the typename isn't known and the text is funky. I just realized, actually, that it causes problems for the existing description text, where we try to say what the path will be. Does anyone on the tweaky dev side know if there is a workaround for this, or should we just be sure to use type-name-neutral language in the labels and descriptions?

Another, wider issue is the discoverability and flow of this feature -- initially it's not super-clear where I can see those listings in action, you gotta create a _block_ first to ever discover the listing _page_ (by clicking "More" link).

Indeed. One person suggested creating actual menu links in the nav sidebar for each of these pages, but that would require them to be top-level items (ie, /article rather than /content/article or /node/article) to automatically show up. Thoughts, anyone?

In the Snowman profile that's being planned, the assumption is that these blocks will be activated for most content types and links to the listing pages will already be in the primary links. They're easier to demonstrate than they are to discover.

Great feedback from everyone -- thanks! This version incorporates most of the comments made so far. A minor exceptions:

This doesn't look too bad to me. Wondered whether we couldn't re-use some more existing node_page_*() functions and/or whether there couldn't be a query helper function to not repeat more or less the same manually crafted query all over again.

We definitely could, I think. I'd like to make a helper function for the little 'create a url-safe version of the machine name' snippet, and I'm wondering whether anyone sees value in having a version of node_type_get_type() that just takes a type name instead of a full node (that would save a bunch of odd little snippets, but probably not have a big impact on the overall code footprint).

Merging the page generating functions would make the queries themselves simpler -- a simple switch would allow us to add a type filter or a 'promoted' filter, for example. The downside is that the ordering of the logic for both pages is a little tangly; things like 'what should be there on the empty page' and 'what should the RSS feed URL be' need to be handled after the query is run, and the MENU_NOT_FOUND needs to be returned very early in the process, so at least at some point it would get tangly. One function would make sense though, and it's on the to do list once some of the underlying functionality and behavior is better settled.

I like 'Provide' - I'll change that in the next roll of the patch.

We can replace one page (/blog) that used to be provided by the newly removed blog module with this, see #1263208-3: Upgrade path for blog module removal.

Only if we solve the 'where do these URL paths end up' question. 'blog' would be replaced with 'content/blog' in the current patch, which I'm OK with for a first pass. The specific path is easy for us to create, it's just a matter of deciding where a consistent location will be that doesn't collide with other stuff.

This is pretty much where I'm hoping that we can get a once-over from Dries or Webchick. At this point, the patch is functinoal, useful, and what improvements could be made to it go in a number of different directions. (Making our pathing more consistent across core, consolidating node module's internal listing pgae code, adding support for this same functionality across all bundle types, and so on.) Each of those would qualify as a separate patch, IMO, if this one gets the thumbs up.

Anyone else have any thoughts on this?

After a brief discussion with webchick, I'm marking this RTBC. The outstanding issues with the patch are not related to the underlying functionality, rather to our overall strategy on RSS exposure, pathing conventions, and entity related functionality. Each of those, IMO, deserves a separate issue to iron out the details as they affect more than just this feature.

A very, very simple version of this feature can be rolled using Views. The four questions still remaining are the trickiest ones:

1. URL path structure. Using /node/[type] is a nonstarter as it collides with our standard node/1 URL paths. Using /content/[type] seems uncontroversial, but also implies that /node should really be /content. I'd be +1 on changing that. Thoughts?
2. Navigation questions. Nav menus links for these content type list pages would make a lot of sense. Figuring out the best place for them feels like a companion question to the path structure.
3. Pluralization and language. As mentioned earlier, URLs like /content/article make less sense than /content/articles. In addition, titles like "Latest Article Content" are less desirable than "Latest Articles." Using one contextual-filter-driven View makes sense from an implementation standpoint, but makes it very difficult for site builders to override language without baking plurals into the content type definition. That's sadly a nonstarter due to the complexity of capturing "localizable plural forms."
4. If we don't use a contextual filter approach, we'll need to bolt a checkbox or somesuch onto the node type editing form, and generate a one-off custom view for each content type that the option is checked for. That makes customizing the paths and so on a lot easier, but adds code complexity. Any thoughts on which direction would be best?