"More link" option should have configurable target for views page displays

Closed #1438742: "Link Display" does not appear as a duplicate of this issue.

Looking at this a little further, in my case anyway I can see the "Link display" option on my block displays, but not my page displays.

Setting this option for all the displays only applies to the block displays, however. So the issue still remains that the more links on a page display cannot be changed.

Subscribe. Would like to link page display A to page display B, however link display options do not appear on page displays.

even though it doesn't affect the use of views, it still looks like a major bug to me...

I too would like to link from one page to another. I have promoted items on the front page and want the 'more' link to direct to all items on another page.

"Link Display Above" should be replaced with "'Link Display' field under the 'Advanced' section."

@frazras - I agree the wording could be improved. I think that might be a "User interface" patch for a separate issue. Setting back to active because we don't have a patch yet - see http://drupal.org/node/156119 for an explanation of the different issue statuses.

Yeah for setting the right issue status, this really helps to keep track of them.

I totally agree that the working is not perfect, what about this kind of change?

Committed to 7.x-3.x and 8.x-3.x

So I see that the wording is now fixed, but looking in the patch we have just changed the wording. I think (along with a few other folks) were noting that having a Page view be able to specific a different linked page would be great. At present this is only available for blocks.

I changed the status since it's not really closed. I think the original poster wasn't just commenting on the wording but also functionality. Hope that's ok.

I am not seeing a valid use case for having a "more" link on the page view. Shouldnt a pager suffice?

Well your title indicates that this is not visible (and for pages that's true).

Here's my use case which I reckon is pretty common one...

* You create a view for the frontpage and only show a few streaming articles
* You make that view a page and then want the link to be to something else...

In this case you have to set the frontpage to be a page (or view of a page) rather then a block since it won't work otherwise. For now I am 'hacking' the tpl file to change the link but I don't see why we couldn't just expose this feature for pages too...

Pretty please...

thats what the view footer is for IMHO

The "link display" setting is not visible for page displays, only for block displays.
This makes no sense. It should be possible to link from a page view to another one with the more link. A typical case is a home page showing x items with a more link to a page with a list with more possibilities like filters and so on.

A workaround is indeed to work with a footer but I don't see a reason why this is not available for page displays.

I agree. This doesn't make any sense, usability-wise.
I have the same case as #14 and using More Link would be the most straightforward way to do this.
I see no reason why I would have to resort to footer if I have the exact functionality right there.

Anyway, in current shape, More Link in page displays doesn't make any sense.
If fixing this would be too much work then, I would suggest removing it completely from page displays to avoid confusion.

I'm divided on this.
I understand why the paging system's more link is not available on a page display, it's just not logical.
And I also agree that having to use the footer is wonky too.
I often use the Global: Text area with Full HTML and <span style="float: right;"><a href="PAGE-more">more</a></span>
Maybe we need to add a simple 'Link to Display' option to PAGE SETTINGS in views, and leave the Pager alone?

I like that idea!
Link to display and you get to choose which page display you want to link to.

If I may add my input, a *very* common use-case where "more" links are appropriate for page displays is as follows:

1. A user creates a views page and sets the drupal site front page to this view path.
2. This view only shows a few items and thus has a "more" link pointing to an internal page with many more items

Thus one views page requires a more link that points to another views page.

Agree with #21 - it does not have to be a front page, but a page with 3~6 fully detailed elements and "more" link to more tidy and brief list of all items is pretty common. Sporting events, for example. Or repertoire - 2 or 3 high budget movies multiplex cinema is playing today and a link to full list. they all work just as a "more" link does. So I cannot agree with #19 that it is not logical. It is and it is common.

I was always thinking that Drupal (and Views) is to provide tools, not solutions. So the question should not be "is this a right solution for web developers?". They will know themselves. They are paid to know. The valid questions, as I see it, are:
"Is this a tool that will be used?" - from this thread seems so. And I know people placing block in dummy page just to get it work, wanting it to be simplier.
"Can it be added without cramming interface?" - blocks suggest it can.
"Should it be in views directly, or a contrib module?" - again, blocks suggest direct approach.
"Can it be added without breaking other things?" - I have no idea.
"Who will make it happen?" - I have no idea. 2 other issues have testbot-OK patches by me waiting, 2 more waits with patches tested by me... I will not write more until what I have already done will get evaluated.

Last but not least, blocks and pages have no inherited use cases. There can be only one page display on a page, and many block displays, and only pages can be linked to as blocks does not have URI. But that does not, in any way, specify how people would need to place a links from. All functionalities, except those directly tied to having an URI and to being able to appear in many pages / many blocks in one page, should be the same, shouldn't it? Let user decide what parts of it he needs.

The link display setting is only visible for views that don't have their own URL. So the link display on a page means, 'link to itself.'

I agree with the above comment that this sounds like it could be done adequately simply by using a footer. There's no reason to try to use the link display (which you can't use on something with its own path already anyway without potentially breaking things).

I'm going to mark this won't fix; if someone can explain why a footer is simply inadequate to the task, it can be reconsidered.

I haven't used this module but it might be applicable here for adding "real" links in headers/footers instead of markup: http://drupal.org/project/views_linkarea

I don't understand the conclusion here. Is it impossible to link from one page view to another via the 'More' link?

Is the help text "If you have more than one page view, the link will point to the display specified in 'Link display' section under advanced. You can override the url at the link display setting." not valid for page views?

While I understand that this can be done via markup in the footer, I believe it would be far more simple to allow the 'link display' to connect to a different page via the 'more' link.
Sometimes you want to create a page view, let's say 'Latest Stories' with one video in full view, then below it you would want a 'Previous Stories' block with five videos as teasers, and then you may want a more link to a grid style page with All Latest Video.
So linking to a page; '.../video/latest' more link display to '.../video/latest/all', would be far more easier, and faster than creating markup.
I do agree that there is no reason to link to the current page.

I think using the footer is not sufficient (but not 100% sure) if you only want the 'more' link displayed when you actually have more. E.g. If I set my view to display 5 items (no pager) and I only have 5 items, I may not want the 'more' link displayed as the view would be the same. But when a 6th record gets added, I would want the 'more' link automatically displayed and pointing to another page with a more robust version of the view.

It's a link and HTML format in the footer/header makes it untranslatable :( . To keep everything working "as should" you'll need a php field, t(), additional work with language specific path aliases...
If you want a footer (and a header) and put the more link in a different place using the tpl (at the side of the title, for example) you simply can't.
Doesn't make much sense for me, since the page display generates the link, not to choose wich display to link to. At least could be given the option to use a URL, don't you think so?

@ merlinofchaos:

* The usecase for having a link from a page to another page is clear, like for "/top-news" to "/all-news"
* Using a "Global text" footer makes you hard coding the link. And it can't be translated.
* Why should a page link to itself in the "More" link?

Please reopen and consider fixing it.

In the meantime I'will use view_php for a global footer :(

I would like to pile on here.

1) One often needs a "more" link functionality on a page display. (And if you think not, why is the option and help text there on the page display to begin with?)

2) A footer is a poor substitute, for the reasons mentioned above: it appears whether or not there are more documents to display; it is difficult to translate.

Given that the underlying functionality already exists, and seems simply to require extension, why not implement?

For anyone who needs a quick hack around this problem:

a) edit options_summary() in plugins/views_plugin_display at line 1349 -- change "if ($this->uses_link_display())" to "if (true)" ; this will cause the Link Display option to appear on your page display.

b) do NOT choose one of the existing displays. Instead, choose the Custom URL, and provide the path, using the available tokens if necessary. (if you do not pick Custom URL, then render_more_link() will override your choice of display).

Please note that I have NOT tested this hack for side effects. YMMV.

I am also missing this feature.

For example, when using Views Lightapger, users lose opportunity to "jump" to older entries (if they prefer not to use search for some reason).

I though that "more" link could be used to view custom title-only view with many (all?) nodes...

I think Molot in comment #22 is right.
Someone can try to make a patch for it?

That's not the first time I run into that kind of issue.
The fact that the more link on a page display points to itself is unlikely to be useful to anyone. I cannot imagine an unique use case in which this behavior would be needed.

I see two possible resolutions:

1. remove the ability to use the more link on all the displays that have a path
2. fix the more link to avoid it looping on the current display is it has a path

I chose the second one. This patch enables the link display option on page displays by overriding the views_plugin_display::uses_link_display() into the views_plugin_display_page class. It also alters the views_plugin_display::render_more_link() and views_plugin_display::get_path() to skip the test on the display's path and avoid it to be chosen instead of the link display setting.

This patch applies on the 7.x-3.x and the 7.x-3.8 versions.

Hi,

I tried this patch to get a more link inside my block view.

It works well but when you use EVA: Entity Views Attachment module, you get an strict warning on your page :

Strict warning : Declaration of eva_plugin_display_entity::get_path() should be compatible with views_plugin_display::get_path($return_own = true) dans _registry_check_code() (ligne 295 de /var/aegir/platforms/drupal_suite_7.41.2/sites/all/modules/VIEWS/eva/eva_plugin_display_entity.inc).

To solve this warning, I turned back your patch and I just added the end of your patch :

+++ b/plugins/views_plugin_display_page.inc
@@ -17,6 +17,11 @@ class views_plugin_display_page extends views_plugin_display {
   function has_path() { return TRUE; }
   function uses_breadcrumb() { return TRUE; }
 
+  /**
+   * Allows the define the link display for the page displays.
+   */
+  function uses_link_display() { return TRUE; }
+
   function option_definition() {
     $options = parent::option_definition();

Now it works perfectly and I can add my more link inside my block views.

I hope that's the good way ;)

If not, please let me know where i'm wrong :) I'd would like to remake a patch if it's good ;)

Let's get some input from the maintainers as it's likely to be ported to D8 to avoid regressions.

This patch apply to Drupal 8.1.1, it includes the display_links options for views of type page. Also it includes at checkbox for select a _blank target.

the following line is fixed as well:
if ($this->getOption('link_display') == 'custom_url' && $override_path = $this->getOption('link_url')) {

Thank you for moving the issue to core itself.
To be honest I don't get the most recent patch. Why do we also allow people to configure the target, even this issue is just about being able to provide a more link in the first place?

@dawehner do you think it'd be better to just reroll my patch from #35?

Hi,
@dawehner - I submitted the patch for the D8 more links and target options because for a project we needed a shareable widget.
So to have the widget pointing somewhere else beside itself it was needed to have the more links options available, also a way to select the link target was needed so the widget was able to open content in another tab/page.

When I uploaded the patch I didn't think on separate the functionality, but I can see the point of separate issues.

So, please find attached the patch that only fix this issue:

@axel.rutz:
a) a patch that only fixes this issue

And the patch for the more link target in as separate issue ( https://www.drupal.org/node/2743631 ) .

@axel.rutz:
a patch that adds a link_display_target setting (shich sounds useful by itself but is a separate issue)

updated paths, this patch should pass the test...

Why is this in "Needs Review" if it has been committed?
Should we consider it fixed for 8.3.x?
Ignore this, I looked at the commit code and it's just a description change.

I have fixed the patch from #49 removing the first hunk as suggested by Axel (#50), considering it definetly look like a mistake.

Note: (I have also added a backport patch for 8.2.x. if anyone needs it, pretty much the same, just some line differences.)

Hi,
@esolitos

I believe that the patch I added in #49 was correct and still the correct one.

If I'm not wrong, the comment that @axel.rutz (#50) added was confirming that previously to my path that line had an error that was done by mistake.

- if ($this->getOption('link_display') == 'custom_url' && $override_path = $this->getOption('link_url')) {
+ if ($this->getOption('link_display') == 'custom_url' && $override_path == $this->getOption('link_url')) {

I did testing before submitting the patch and the "=" instead of "==" in the if condition was causing a different behaviour than the expected.
If that line is not corrected then the override path would never work.

Thank you for adding a back-port patch, but that one still need the hunk you removed.

Regards,
Blanca

Hi @esolitos,

You and Axel were right I was wrong...
You were right on remove that line. I was getting this error trying to use an external link and my first impression was that it was related to that line:

InvalidArgumentException: The internal path component 'http://google.ca' is external. You are not allowed to specify an external URL together with internal:/. in Drupal\Core\Url::fromInternalUri() (line 409 of .../docroot/core/lib/Drupal/Core/Url.php).

Regards,
Blanca

Included a patch that correct the following two errors for the custom URL option:

1.- path with / at the beginning wasn't working. Now both cases work (sample: /node/[nodeId] vs node/[nodeId] )
2.- external links were causing an error, not external links can be used (sample: http://google.ca )

Rerolled for 8.4, still needs a reroll for current dev (8.6)

I've updated the patch from #58 and removed the url handling of paths with a leading slash. This should be handled in a different issue, maybe #2423913: Leading slash in link fields and views has different UX? I've also reused the logic already present in getLinkDisplay to keep things DRY ;)

I see now that #564106: More links pointing to custom URLs don't respect entered fragments and query parameters has made a bunch of rework and improvements, so the above patch does not apply to 8.8-dev. I've rerolled (again) so that a) page displays can confiure a more link and b) the configured link is used when building the more link (and not the current display)

Patch #68 confirmed to fix this issue.

Discussed this with Lendude at Drupalcon:
"
This needs testcoverage.
We need to prove nothing breaks for existing sites.
The issue summary needs to be updated to better reflect the feature request and answer what is arguments are why this was re-opened.
"

Added updated patch with extended testcoverage for more links.

note: this test does not prove that this was not working before this patch. In fact it was working: you could add any type of more link to page displays using code or config import. You just could not add- or adjust those in the admin UI.
Adding a JavaScript test just to prove this seems overkill to me.

Updated title and IS, and also added credit for bird-cage as I'm marking this issue #2570293: Views more link not working. closed as a duplicate.

I did manual testing and took screenshots, all on Drupal 9.2.x. Although the screenshots are in the IS, the IS still needs an update so not removing tag.

I added content with devel generate and made a view of content with two pages. For one page I changed the more link to have a custom link, of /admin/modules. Then saved the view, cleared cache, navigated to the view, hovered on a more link and the more link still pointed to the node, not the custom link. Clicking on the more link and it did go to the node and not the custom link. Needs work for that.

This patch cleanly applies on 9.2.x branch on local.
Triggering test from patch #72 for the 9.2.x branch.
Let's see how it goes.

Moving to needs review as test cases are passing in #72 for 9.2.x branch.
Patch already contains a few tests.

My manual testing in #80 showed this was not working.

Can someone else test this as well?

Thanks a lot. The Patch #72 works for me on Drupal 9.3.7, php 7.4.9.

Reroll the patch against 9.4.x branch & added reroll diff.
Keeping this issue in NW as it requires manual testing on 9.4.x

Patch #88 applied successfully

Issue summary still needs updating per #80

I didn't get same results as #80 but it's not working as expected.

I tested using the Content view.
If I set the more link to the page then it just redirects back to the page I'm on
If I give it custom URL it's passing all the filter variables to it test?title=&type=All&status=All&langcode=All

So don't think this is working correctly.

Also shows the test coverage needs to be expanded.

Hi @smustgrave

I tried to reproduce the issue and it seems to be working for me.

If I set the more link to the page then it just redirects back to the page I'm on

This is partially because of the confusing naming convention may be.
When we are on the modal to select the more link page, it shows the name of view's display.
You might have selected the same page i.e. "page" (option 3 in the following screenshot), which is same page.
So link might be taking you to the same page.

I have added another test case where we are linking a separate page (page_2) from page_1 view. This might clarify things further.
Keeping the "needs tests" tag for now until we are sure that we have sufficient test coverage.

If I give it a custom URL it's passing all the filter variables to it test?title=&type=All&status=All&langcode=All

I think this change was introduced in http://drupal.org/node/564106. So probably this is by design.
When we have any exposed form, view gets the exposed_raw_input from the current view and appends to more-link.
Happy to have feedback from other folks about how we should proceed further.

+++ b/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php
@@ -685,7 +685,7 @@ public function hasPath() {
   public function usesLinkDisplay() {
-    return !$this->hasPath();
+    return TRUE;
   }

For an issue that wants to add this to Page displays, changing this in the base class sounds way too generic and might break BC for modules adding pathed displays that don't want this.

Not totally sold on needing to support this in core, since looking at this, all you would need to do is add a new display plugin "Page with more link" that extends path but returns true for usesLinkDisplay(), pretty trivial, but ¯\_(ツ)_/¯

The Patch #94 works for me on Drupal 10.2.3, php 8.1.2. Thanks.

Rerolled the patch #94 with 11.x.

@sakthi_dev, I think patch is already getting applied on 11.x
We probably don't need to re-roll the patch.
Can you please upload the re-roll diff, if possible.