When using "Override path" and an argument with "input on pane config", the argument is appended to the overridden path

Ideally, views_content would provide an option to override the path in a way that does not then have argument values appended. Perhaps the view pane content_type could (optionally) set link_display/custom_url rather than setting override_path.

Workaround:

Modify view content pane display:

1. Add a Global: Text argument (I label with admin name: More link path workaround)
2. Change "Link Display" option to "Custom URL".
3. Set Custom URL for Link Display to the Global: Text argument's input (in my case, I entered "!2")
4. Set argument input for the Global: Text argument to "Input on pane config"

Now, when this content pane is added to a panel, you can enter a path for the Global: Text argument, which will then be used for the more link path, without appending the arguments to the path.

Same here, still in D7

My suggestion is to change:

$view->override_path = $_GET['q'];

to

$view->override_url = $_GET['q'];

in views_panes.inc. In this way, views doesn't add the arguments. Adding arguments to a full URL is pointless, so I think this change will make the function work like people expect.

Please see the attached patch.

I think the behavior you are asking should also be applied to the "Override path" option, not only to the "Use panel url" option.

And, of course, it should be optional.

Here is a patch which includes an option to add the arguments, that is enabled by default, and that applies to both url override options.

Fixing the synax error.

Lets try again.

You should post a patch with all changes, not just an incremental patch. #10 contains just one change.

You should post a patch with all changes, not just an incremental patch. #10 contains just one change.

I think you mean that the patch in #8 only contains one change.

The patch in #10 is complete and works great from the testing I've done.

You're right, I definitely did not look well enough. Patch #10 looks good, although there is one small typo: 'optioons'.

Sorry @Jorrit and @Pedro Lozano, I tried both of your patches but nothing changed the more link for me. My views content pane has exposed filters on it that are used to allow who ever is placing the pane to configure each instance. The problem is that the exposed filters still add values to the end of my "more link"

Marking needs review pending previous comment. It looks like this feature isn't totally fleshed out yet.

Similar issue with a patch #564106: More links pointing to custom URLs don't respect entered fragments and query parameters

Sorry for the noise that issue was for Views not ctools.

patch #10 comment works fine, i particularly liked the solution of bypass the appending of the argument path as a configuration option in the pane. While I don't think it truly addresses the issue there might be some edge case scenario or frequent scenario that dictates the appending of the argument path as a default; it works and with a little effort of un-checking that configuration checkbox it solves this issue.

@gmclelland reading your comment i suspect that you only applied the patch but did not un-checkbox the box provided by the settings of that ctools pane.

#10 RTBC vote 1. technically correct, but does not truly fix the root issue of the default behavior of appending argument path to the more link pane. I sympathize with the approach because addressing the root issue requires more digging.

marking RTBC because I addressed comment #14 in comment #18. I leave it up to the architect whether the fix is good enough.

This appears to be pretty robust, and is a great feature addition (allowing for much greater view re-usability across various panels). For what it's worth I'm throwing in a +1 on the RTBC.

Hey all, I believe what you're all looking for is doable with the "Skip Default Argument for View URL" checkbox on the default arg for your contextual filter(s).

My use case was as follows:

1. Create a content pane that shows the top 5 news articles for an OG

2. Expose an overridable "more" link, because we have crazy requirements for url structure (ex. people want pages at mysite.com/%groupname/news, which is impossible with views pages). In our system we have users creating a panelized basic page at '/whatever/my/insane/url/structure/may/be/news' and expect the "More" link from their landing page news feed to go to that "news" basic page.

3. Check the "Skip Default Arguments" checkbox for Group ID contextual filter

4. Now we can enter arbitrary URL's for the path override on the panels interface.

I'm sorry to be a bearer of bad news, but I'm marking this won't fix.

The main reason is that panels is at a stable API release, and this would change existing site functionality. It also seems like the patch is a hack on already dubious architecture.

Nothing stopping folks from using the patch, but at least for now, this isn't getting pushed up unless some other maintainers have some compelling reason to do it... with some way to not alter existing functionality.