"%" may not be used for the first segment of a path.

I am in the same boat. I think this is by design, but don't know why.

In my case I wanted to create lists of entries by node types, with the node types in the "root" directory (/blog will display all the blog nodes, /photos will display all my photographs, and so on).

I found that the Node Type Views does that and provides me with the urls I want, but lacks the fantastic flexibility that Views provides (such as modifying the feeds title and description).

Maybe someone else might give you better help than I can.

There are no options; Drupal's menu system simply does not support % as the first placeholder.

Thanks for confirming, Merlinofchaos.

Miraploy, your only option is changing your urls, then (unless someone changes that). Assuming you're using pathauto, you should be using something like "users/[user-raw]" in the pattern for the user accounts.

And if you ask me, this is in fact the way to go, and a good thing in your case, because:

1. You'll be able to create a view which path is "/users" and outputs the actual list of all (or you can restrict) all your users.

and more importantly:

2. You'll avoid having a user registering with a name that clashes with one of your urls. You're currently letting your users use up lots of "root directories", which is not a good idea. An example:

Say you have a node with a title of "Michael Jackson", or say, "History". If I'd register in your site as "Michael Jackson" or "History" I bet Drupal will have an issue to really know if http://yoursite/history is the path to a node or the path to a user. Or if you happen to want to create a page or a path redirect from "/blog" (or whatever, there's simply too many options) to other page or section; again, if someone chooses "blog" as i username your links could be ruined. I even wonder what would happen if someone wants to register as "node" in the first place. Do you want to give it a go?
;-)

In my case, that's different, since I would have had the control on the node type names I'd be using, all the base paths, etc. So if I wreck it, it's my fault, not someone else.

I have the same issue, I have taxonomy items (say 10 items) and want to list special listing based related with them.
taxo items are exam types I'm tyring to list them as taxoName/books taxoName/news taxoName/teachers the root name is handled by panels where it shows all of them but limited.

If there is notting but path confusion problem, I'm changing line with follows

        if (false && (strpos($form_state['values']['path'], '%') === 0)) {
          form_error($form['path'], t('"%" may not be used for the first segment of a path.'));
        }

file is located sites/all/modules/views/plugins/views_plugin_display_page.inc

#5: Changing that line will not address the problem I mentioned in #2, namely, that Drupal's menu system does not support % as the first item. Views cannot do anything about this.

Same problem here. Why drupal's menu system does not support it?

Does it matter? It doesn't support it. I can't change it.

I understand it cannot be changed, even though I would love to see this made possible.
Right now I have to add an additional /thismustbehere/main_category/sub_categorie just in order to trigger a specific view.
Or create lot's of views just for every main category which in my case doesn't sound appealing.

theres no path clashes from letting users register top domain paths, if i have /blog and a user registers with "blog", they get /blog-0.. pathauto works that way

I'm upgrading a site from D5-Views to D6-Views 2 and have a bunch of views that have arguments as the first segment of the path. After doing some tinkering, I was able to get it to work with the following combination of items. Maybe this will steer someone else in the right direction.

Installed the "URL alter" module:
http://drupal.org/project/url_alter

Wrote a custom module and implemented these hooks:
hook_menu
hook_url_inbound_alter (don't forget to also add hook_boot)

This is not Views specific, but a Drupal issue. I have recently faced the same limitation, wanting to allow an administrator to be able to define the first segment of a path via content management tasks as opposed to site building tasks. Also we needed to follow that first segment with wildcard arguments to build a taxonomy-based content filter. I discovered the following:

- You can use Path core module for aliasing URLs to system paths, including the first segment, but this is a very static mapping. Forget about adding any wildcards to an aliased path.
- PathAuto will allow you to bulk automate the mapping of Paths to Nodes, Terms or Users using pattern matching. But still no wildcards (the path has to exist)
- You can hack the incoming URL with url_alter mentioned above. I considered this risky as it throws a lot of default Drupal stuff away.
- You can combine url_alter with http://drupal.org/project/subpath_alias and it gives you access to wildcards combined with Path aliases, but after the first (aliased) segment. Also you still have no access to the path segments as arguments, as it's sent to node, taxonomy, or user core modules, so it was no good to me.

I have opted for a combination of PathAuto, allowing admin users to create first segment nodes via normal content creation tasks. And further wildcard functionality is under a first segment ("filter/%") which is a custom module defined menu item.

It sometimes feels redundant to have that extra static first segment that has no meaning, and clients' marketing departments really dislike it, but it seems we are stuck with it.

@Scott Earnest It seems like a smart solution... Can you share with us?

Hi,
I've created a temporary solution by changing my view display form page to block and created a seperate node where I only show this block. Now I can control my URL path exactly like I want...

I'm manually migrating a D5 site to D7 (and D8). This "bug" is a real issue for me. Here's the use case that explains why I think it's a bug.

My existing D5 site is for an annual conference, so "example.com/yyyy" takes you to the info for that year. The "yyyy" ripples through to

- which menus appear
- which blocks appear for sponsors, etc
- which views should be used for organisers, committees, awards, schedule, programme content
- etc, etc.

To me, this is an obvious and clear URL structure that fits the rest of Drupal. It has worked well since the days of D4 and D5.

The old version had no problem with a leading "$args". But now it's "broken" in D6 and D7; Views don't support a leading "%'.

This is the only thread I can find where someone else has struck this problem, so I might seem rude in labelling this as a "bug". But based on the comments above, I either have to

- add an extra component ahead of the "%", which breaks all existing links, menus, etc. As Admataz says, that sucks.

- write a custom module as per scott's approach. That sucks too.

Can someone explain why my use case can't work in Drupal? I can't see what the Menu system has to do with it.

I'm hoping D8 will fix this problem.

Thanks!

Steve.

Hi again

To add further support to my case that this is a bug, please note that my view, based on "/%/item" works fine in Preview mode. It doesn't work in "real" mode.

Also note that if I fix the code to allow "%/item", it is rewritten as "/%/item".

Yes, it may have something to do with the core URL rewriting rules. But that doesn't convince me: I have a working D4/D5 site. D6/D7 has broken it. I'm looking for a reason why I'm wrong, and Drupal is right. Any takers?

Thanks!

Drupal's design is to seek segment by segment what to do with a path. First first, last last. If your module would grab everything at first segment, no other module would ever be able to show any page.
Without a change to that design it's not a views bug at all. It works the same for custom modules, and for everything.
Custom modules can kinda get around it being the last ones in matching queue. Or defining more predictable patches. Universal modules like views, that must grab everything afver main patch for themselves (for things like filters and arguments) simply cannot afford to hope for being called last (which view should be alst, exactly?) and are technically unable to provide constant predictable set of things after their last %.
It was screwing Drupal 5 websites on a pretty regular basis, so it was blocked in views.

Without serious core rework it's impossible to provide that functionality in any stable, safe manner, and next serious redesign that's not to late to include that change is Drupal 9.

Moving where it seems to belong.

Just wanted to say this is causing me serious issues too.

I have a site where I'm setting urls for taxonomy terms to be simply /taxonomytermhere

This is because each taxonomy term is meant to serve almost as like a "homepage" for that category of content so site.org/taxonomy is a "nice url".

But apparently that means I can't use any contextual filters at all in views, etc.

Thanks,

-Peter

This is because each taxonomy term is meant to serve almost as like a "homepage" for that category of content so site.org/taxonomy is a "nice url".

The way you should probably do it, is to use url aliases for your taxonomy terms.

@Mołot: Are you sure that this is really for 9.x? I don't see a fundamental problem that you can't do that with the new router system in theory.

A simple solution here is to use a generic static argument for the whole site (like site, live, new etc) as a starter path. Some developers also use this by default so they can alter it later on upcoming versions or on new functionality (for example they may have path /a/%some_args and a new version will be /b/%some_args).

Update to comment #14: this module seems to offer more functionality.

If we decided this was desirable, and it's possible without a backwards compatibility break, then it could be tried in a minor release

Is there any update on this issue? I've found two cases in the current site that i'm building that this would save me a lot of work, but this seems to be still unavailable.

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!