In an attempt to keep #190867: Remove access check for anonymous users when creating aliases in scope, I'm opening a new issue here for the wider issue of validating menu paths as valid in general.

Files: 
CommentFileSizeAuthor
#77 absolute-paths-308263-77.patch2.73 KBdavisben
FAILED: [[SimpleTest]]: [MySQL] 34,382 pass(es), 1 fail(s), and 0 exception(es).
[ View ]
#60 local_domain_links.patch2.69 KBMixologic
FAILED: [[SimpleTest]]: [MySQL] 20,585 pass(es), 1 fail(s), and 0 exception(es).
[ View ]
#53 absolute_external_path.patch1.45 KBradolin
Failed: 11822 passes, 2 fails, 1103 exceptions
[ View ]

Comments

i'd say, keep validation, but make users with the right (new) permission to bypass the validation.

I'm prepared to "won't fix" this one. What's the motivation for removing validation? You can put the link using a full (http://) path if you want to bypass validation.

#2 is not an option if you're working in development on another location then the procuction site will be.

www.example.com/ is production,
www.example.org/drupaldev/ is your development location.

secondly, normal users with permission to change the menu, shoudn't be pointing to invalid links, however, during development, or when creating links to views with arguments, the validation should be able to be bypassed.

also it is a protection to typo's etc.

+1 for #1 =)

Also, it would be great if this was considered for back-porting to D6.

Title:Remove validation for menu itemsAllow privileged users to bypass the validation of menu items

Improving title to adhere to new scope.

Personally, I'm a fan of this idea: http://drupal.org/node/190867#comment-629783 (combined with requiring administer menus permission).

To me this is an example of Drupal trying to "protect" the user from doing something uncommon, but still useful, by disallowing it entirely (and not providing a way to bypass the protection). That's why I'm in favor of the linked solution, as it would inform the user they are doing something possibly unintentional while still allowing them to override the validation (if they have appropriate permissions).

path_redirects are one use case of where I'd like to be able to enter non-existent menu paths; development planning is another use case. (I don't think views arguments present this issue, they don't seem to be blocked by the validation check.) Using full menu paths is doable but annoying for development (as it would still require you to go back and alter the paths once the site is launched). It also defeats the whole purpose of avoiding hard-coding the basepath within the site.

I'm willing to put together a patch, but I would love more information regarding if there is another valid reason for this validation other than protecting the user from unintentional mistakes.

The fundamental reason this validation exists is so that links can be hidden if the user does not have access to the target of the link.

But aren't you referring to viewing a menu item/link? So users can only see items to which they have access. My question is what is the reason a user who has 'administer menus' permissions can't add any link, even ones s/he doesn't have actual (viewing) access to?

right - we should probably relax that part of the validation, but that would still mean that the target of the link must exist (if it's a drupal path) in order to be added.

in response to #6: this issue is specifically created for exactly that problem!

normal users with permission to change the menu, shoudn't be pointing to invalid links, however, during development, or when creating links to views with arguments, the validation should be able to be bypassed.

also,

internal menu item links *should* NEVER be used absolutely.

yes, it saves me from a typo... which is nice, but we should be able to bypass that validation on request (if you have the right rights)
remember, showing links leading to 404 pages (typo...) on a production site is ugly!
also, 403 pages are ugly too... don't say you want users to see your administer link?

(sorry if i'm too harsh, but i'm trying to keep this issue focused!)

Re: #9

but that would still mean that the target of the link must exist (if it's a drupal path) in order to be added.

Perhaps I'm being dumb, but this was not the case for D5 so why is it the case now?

The menu system was completely re-written for 6.x. See the Menu system overview: http://drupal.org/node/102338

Ok, so if I'm understanding you correctly you're saying the new way menus are implemented makes this feature request fundamentally impossible? That's a shame... =(

Version:7.x-dev» 6.x-dev
Category:feature» bug

This is a feature regression in Drupal 6 that makes the initial build-out of a site by the site builder more difficult. That is, it's a bug. "The menu system was rewritten" is not an excuse if it does not provide a workable alternative. I'm fine with a new permission for "bypass menu validation when editing" or something, but the current situation is not good.

Version:6.x-dev» 7.x-dev
Category:bug» feature
Priority:Normal» Critical

first fix in D7, then backport to D6

also, the actual regression part (the anon-acces only paths) are being handled in #190867: Remove access check for anonymous users when creating aliases, this is not the issue for that.

normal users with permission to change the menu, shoudn't be pointing to invalid links, however, during development, or when creating links to views with arguments, the validation should be able to be bypassed.

Also, i'm a webdevelopper myself, and by using this disallow of invalid paths, i can check very easily in the menu, if the main section of the site is finished, also it prevents me from creating hard to find and solve links to 404 pages.

This system will never be removed completely.

(sorry if i'm too harsh, but i'm trying to keep this issue focused!)

Just want to put in a +1 on #1.

The current path validation is very frustrating and time wasting when developing sites.
In my case I develop my sites in a subdomain of my clients extranet and then migrate the site to a completely different domain. Seems silly to have to hard code in my subdomain url for menu items and then edit each one before I migrate. Perhaps I'm missing some underlying reason for this new feature when compared to 5.x

Mike

Mike, the current behaviour "idiot-proofs" the menu system (there's no way you can link to a Drupal resource which does not exist) so I can definitely see its value from an admin perspective (many Drupal sites have a person, or even a team of people, probably non-technical, and with the new system they can't provide a dead menu item inadvertently, which is great) but it's frustrating from a web developer's perspective (hence this thread to make it permissions based). =)

Thanks Greg. That's makes total sense. As I've been working more with D6 over the last few days I can definitely see the benefit of this. I think the frustration part comes when one is forced to accept new ways of doing things. I've always built out the site menu first and then added nodes. To others who are similarly frustrated, don't worry, it's not that bad: with a small change in your process (ie. build placeholder nodes first, then menu items), you can move beyond it. Nevertheless, I'm still +1 >;-)

Mike

In response to #9, the last sentence of #8 should have read:

My question is what is the reason a user who has 'administer menus' permissions can't add any link, even ones that don't technically exist?

I didn't mean to refer to the user permissions validation, but rather the link exists validation. I don't think these two issues are really related*, but they've been intertwined in this thread and the previous thread, so it's hard to keep things straight. :)

As has been clarified in #14, this is a feature regression. AFAICT, the rationale is "idiot-proofing" menu management (re: #17) which may be an acceptable choice by default, but still needs an override because there are perfectly valid reasons for skipping this validation. Not to mention the fact that due to this regression, data loss occurs during an upgrade (http://drupal.org/node/190867#comment-1008619).

alexanderpas, in response to #15...

Also, i'm a webdevelopper myself, and by using this disallow of invalid paths, i can check very easily in the menu, if the main section of the site is finished, also it prevents me from creating hard to find and solve links to 404 pages. This system will never be removed completely.

And from the other thread:

you don't want 404 pages in production, they're ugly. also, you don't want to let a visitor see what paying customers can see, 403 pages are ugly too!

I think most people understand the benefits of this validation "feature" that you list, and I don't think anyone is asking to have it completely removed. But I'm not sure you see the perfectly valid use cases for not requiring this validation (it's not just useful during development, though that's been the primary example cited).

Just because a path is "invalid" according to Drupal doesn't mean it really is invalid. What if a section of my site is not managed via Drupal, but still lives under the same domain? I'd like to be able to link to it from within Drupal, and not be required to use absolute paths. This validation assumes a link is invalid if Drupal doesn't already know about it, and therefore should protect you from yourself... but there are many cases where Drupal doesn't know about a perfectly valid link.

I'll work on creating a patch to fix this regression... my next question is how should this override be allowed? Should users with 'administer menus' permission automatically skip the link validation, should there be a confirmation for all users or just users with this permission, or should an entirely new permission be created for 'skip menu item validation'? Personally, I'm in favor of providing a confirmation ("The path 'example' is either invalid or you do not have access to it. Are you sure that you want to add this menu item?") to users with the 'administer menus' permission. I think a new permission is overkill (and the confirmation is still crucial as a check against accidentally adding an invalid path by typo or other mistake).

*Actually, I do think they are slightly related in that I believe a user who has 'administer menus' permissions should be able to bypass both validation checks.

I actually favor a new permission on the grounds that "administer X" permissions are a kluge that need to die, as they are nowhere near fine grained enough to be actually useful. However, we can't do that in D6 so D6 will need a non-string-change solution. The only non-string-change solution is to simply not perform that check for "administer menus" users.

For D7, +1 on a new permission.

Category:feature» bug

Forgot to switch back to bug report. Since this can cause data loss when upgrading, it's clearly a bug...

let's first fix D7, then worry about D6 ;)

I like where this is going, the only thing missing is a patch.

Re #21: Yes, this *does* cause data loss! I just "magically" lost 3 out of 4 menu items during an upgrade from Drupal 5.1 to Drupal 6.8. No warning in the upgrade log, the items were simply gone... I am left to wonder whether or not update.php might have silently killed other stuff, too...

Anyway, I would welcome *any* way to bypass menu path validation. The main reason why I would like this is mentioned in comment #19:

What if a section of my site is not managed via Drupal, but still lives under the same domain? I'd like to be able to link to it from within Drupal, and not be required to use absolute paths.

For instance:

http://www.example.com/drupal/ is the drupal site
http://www.example.com/gallery/ is the picture gallery (menu path would be "/gallery/")
http://www.example.com/wiki/ is the wiki (menu path would be "/wiki/")
[...]

What is the status on this issue for Drupal 6? I am not looking forward to editing a large number of absolute paths I had to use for things like flat files and anchors, when I move my sites soon. Do I need to apply a special patch or will something be bundled into an upcoming update?

From what I can see this validation system prohibits menus urls from linking to View page urls or from linking to regular node urls with parameters on the end?

Is that right?

I'm all in favor of at the very least giving admins the ability to disable the validation on a menu item by menu item basis. Or doing away with it all together. Did anyone think it was broken before? I for one didn't.

BTW. If anyone knows of a way to link to view page urls or to use parameters in Drupal 6 I'd appreciate any links you can point me toward to learn. I keep getting errors. Don't say to use absolute URLs please.

Thanks!

This situation is getting extremely frustrating. Can anyone in the know provide some input about how to enable such a bypass for privileged users, or at least point us to a post or resource that does?

@ecksley, that's a different issue - #204077: Allow menu links pointing to dynamic paths - it also has a patch which needs testing.

Version:7.x-dev» 6.1

Ugh, this drives me nuts too, I can't even do a menu path to a static file that's sitting there... I have a static features.html and can I link to it from the menu? nope! And yes, it's a multi-site installation and I could put the full path in on all of them but...

The developer(s) appear to have decided to give us all the middle finger

The developer(s) appear to have decided to give us all the middle finger

I might not go quite that far in my own assessment, but the situation is certainly confusing and aggravating. Yes, this issue was changed from 6.x-dev to 7.x-dev in #15 above (with the comment, "first fix in D7, then backport to D6"), but is that really the final word?

As we are preparing to go live with a site, this issue has become a big sticking point and something of a joke, here. There is now quite a lot of maintenance overhead to keep our menus between sandbox/dev/qa/prod systems all up-to-date, because we utilize the menu extensively for flat files, static pages and anchor jumps within (otherwise valid) nodes, in addition to regular drupal nodes.

Can a dev please confirm that nothing will be done to address this until after it gets fixed in Drupal 7?

Version:6.1» 7.x-dev

If the bug exists in the latest version, the policy is to fix it in the latest version first and then backport. No one is attempting to be rude, nor downplay the very real concerns for 6.x (note that this will never be fixed for versions of 6 other than the latest version). Fixing bugs in HEAD first (if they exist there) is just the way the project makes sure that the development version gets all the latest fixes.

The way to move this issue toward getting fixed in the development version of 6 is to provide a patch for Drupal 7, get that committed, and then argue for a backport to 6.x-dev. The thing this issue is missing is a patch.

Category:bug» feature
Priority:Critical» Normal

Complaining about 'the developers' doesn't motivate anyone to fix things - this is a volunteer project, people work on what they want to work on. Issues which get bumped by 'me too', 'why isn't this fixed' and 'giving us the middle finger' tend to discourage people from working on it. I linked to a patch above which fixes at least some of the problems reported here, I don't see either of you reporting back that you tested it?

Ping ponging issues between 6.x and 7.x reduces the chance that they'll be fixed since active development is on Drupal 7 and the code for this hasn't changed. So a Drupal 7 fix is also a Drupal 6 fix, except it'll be one that's much better tested. If you want to help, review these three issues below. It's very unlikely anyone's going to remove validation for menu items until these actual bugs with menu validation as it is currently are fixed. If you'd rather sit and moan, feel free.

#204077: Allow menu links pointing to dynamic paths
#123103: Retain #anchors during path alias -> normal path saving
#325533: Allow <current>#fragment as a menu path

No moaning here just yet, but it looks like there will be some more waiting, noting the prioritization and assignment status of the linked issues. Thanks for the response and clarification.

Version:7.x-dev» 6.0

Yea sorry for the middle finger comment, I still love the drupal crew and have more or less found ways to work around this bug on my end, although it wouldn't work for a lot of the people who are complaining above :(

Version:6.0» 7.x-dev

@plato1123, did you *READ* #33 by catch? Specifically:

Ping ponging issues between 6.x and 7.x reduces the chance that they'll be fixed since active development is on Drupal 7 and the code for this hasn't changed. So a Drupal 7 fix is also a Drupal 6 fix, except it'll be one that's much better tested.

Please can *EVERYONE* leave the version the hell alone if you want this issue to be taken seriously. Every time someone changes it to 6.x and we have to change it back again it goes off the 7.x radar and joins the back of the queue. You've been told this twice in one thread now. Please stop doing this.

THE SAME APPLIES TO ALL DRUPAL ISSUES. Changing a bug from 7.x to 6.x only SETS IT BACK.

(Sorry, raw nerve, we see this all the time. It's very frustrating, ESPECIALLY when someone does it right after the reasoning and process has just been clearly explained just a couple of posts above. Sheesh!)

Category:bug» feature
Status:Needs work» Active

To kill menu system validation in Drupal 6, edit /includes/menu.inc line 2402 from
$colonpos = strpos($path, ':');
to
$colonpos = TRUE; // $colonpos = strpos($path, ':');

A bit of an amateurish hack but seems to do the trick.

------------- update ------------
There seem to be a variety of problems that may or may not be related to this change. Make sure you are doing backups with "backup and migrate" module or phpmysql. One error I see is an unsupported operand type in system.module line 628. Another is admin items disappearing from the admin page. Again, not sure if these are related but they may be.

EDIT: THIS PATCH NOT WORTH IT, DO NOT USE

To kill menu system validation in Drupal 6, edit /includes/menu.inc line 2402 from
$colonpos = strpos($path, ':');
to
$colonpos = TRUE; // $colonpos = strpos($path, ':');
A bit of an amateurish hack but seems to do the trick.

Ah, thank you very much, cryptkeeper. I may end up using this in time.

@greg.harvey:

Eek! I had never noticed the "Note: changing any of these items will update the issue's overall values" and feel like such an idiot now. I promise I'll raise my hand before speaking from now on :)

People, linking outside of Drupal is done with absolute URLs. Nothing will change this fact. Drupal paths are, well, Drupal paths.

People, linking outside of Drupal is done with absolute URLs. Nothing will change this fact. Drupal paths are, well, Drupal paths.

I'm not sure at whom this sweeping statement was supposed to be directed. (Honestly - I'm not trying to be snarky or anything). Most of the people who have complained here (16, 19, 23, 25, 29) simply want to use the menu system for their entire website, including both Drupal- and non-Drupal content, without having to constantly re-edit their so-called external links each time dev/qa/prd data gets replicated around. Or maybe your point just got lost on me.

Do we really have to relist all the reasons the current menu system is just plain inferior/a huge nuisance? That was one heck of a sweeping statement and lets hope you're not in a position to have sway over the developers.

After reading through this thread here are my comments...

I just upgraded a site from 5.x to 6.x and witnessed first hand the loss of my menu items. That is most definitely a bug that should be sent to the user upon upgrade (as mentioned above).

Also, my opinion on the whole thing is as follows: while I think it's a great idea to prevent the possibility of a menu item linking to nothing, it's causing more problems then solving them. I have a site that needs to provide multiple PDF files in the menu structure when visiting a certain page. While I know that there's a workaround, it was nice to be able to have them underneath that menu item in a dynamic block that would display any menu items below the active page.

Anyway, all frustration aside—this should be something on the top of a lot of people's list, but I'm sure it probably isn't. So far this is the only thing in 6.x that's been frustrating. The rest is excellent! Great job, team (if any of you are reading this)! I'd love to see this permission change an option in Core.

Good point.
I'm trying to encourage some non-technical colleagues to play around with Drupal - grooming them, so to speak.
This will discourage them - it discourages me. We know a link won't work if there's no content behind it. That doesn't mean the link should be forbidden.

Thanks very much to cryptkeeper (#37), I will try the hack.

I did the following to fix the "menu validation" problem when I wanted to link to document-type files on my Drupal site. For those who aren't willing to wait for this apparently contentious issue to get resolved to your satisfaction and who aren't willing to hack module code, you can try it, too. It seems to be working for me at the moment. YMMV.

1. Enable the PHP module
2. Create a new page and set the content filter to PHP
3. Enter the following code as the content:

<?php
$q
= $_GET['q'];
$url = implode('/', array_slice(explode('/', $q), 2));
//drupal_goto($url);
?>

4. make a note of the node id that is created, and edit the content again, removing the comment "//" from the last line of the code. Save and you'll get redirected to the front page of your site. (If you need to edit the code again later, you'll need to find the page in your Content listing in Admin and edit from there.)

5. To create a link to a file, create the menu item using the path "node/##/path/to/file" (where ## is the node id of the page you created, and the "path/to/file" is the path to the place you want to go on your site.

The code will strip away the first 2 items in the path "node/##/" and will redirect you to the location of your file.

Note that this is ugly, probably doesn't work in all cases, and doesn't work with the path module (you can't alias the redirector page to another path name). But it works for me, and it doesn't require a patch. So I figured I'd post it.

Here's hoping someone figures out how to make everyone happy on this issue. It was a big deal for me to be able to do this.

Version:7.x-dev» 6.12
Category:feature» bug

Hello.
Just wanted to let you know the pro's and cons of the method posted as #37 in this thread.

The pro's is that I really was able to submit whichever path I wanted.

The BIG CON is that it broke my drupal, menu items started disappearing, others were born out of nowhere, and I couldn't open certain pages as Site Building, Site Configuration and others. This was the error: Fatal error: Unsupported operand types in modules/system/system.module on line 626

So... it is dangerous.

Anyway... I would still like to insert whichever path I wanted... but not at the price of ruining my drupal installation. Any ideas?

Version:6.12» 7.x-dev

@rucativava: Please go back and read #36, and then refrain from touching the version selector as described.

I will kill a kitten each time i find the version selector on anything besides 7.x-dev before we have a fix in 7.x-dev

Sorry.
I am new at this.
Because I am not so used to these kind of forums/issues/threads, I have not assimilated all the "protocols" and "netiquettes"!
Of course I am also interested in good organizations.
Sorry once again.

I'm not sure this relates, but I get the following fatal error when trying to browse to admin/user in the July 1, 2009 version of Drupal 7 dev:

Fatal error: Unsupported operand types in drupal7/modules/system/system.module on line 1095

I also have CCK module 7 dev installed from June 29, 2009.

I´m also getting problems on d6 when creating a link in a multi-language site and do not know where best to report this, so i'll add another reason why administrators should be able to bypass checks (although, to me, this multi-lang issue really is a bug that doesnt have to do much with this issue). I have i18n enabled with spanish as the principal language and english is located at example.com/en

By creating a menu item with Path "en" i get the error message:

The path 'en' is either invalid or you do not have access to it.

note that "/en" and "en/" and even "en/" get the same error.

Hello,

I have recently stumbled upon this problem as well. Currently there are two types of path to be distinguished - internal Drupal paths and external paths. The latter being the ones starting with http://, ftp://, etc. If the link is external no validation is done.

What do you think about classifying absolute links (beginning with / ) like /some_dir/file.htm as external. Basically the scenarios mentioned above about linking to http://www.example.com/wiki/ or http://www.example.com/downloads/file.pdf will be resolved by this. And thinking about it for a wile this is what they actually are - external links (to Drupal) even though they reside in the same domain. May be also links beginning with .. should be classified the same.

As far as I can see this will not be hard to implement and only require minor changes in 1-2 places.

I tried naively changing the menu_edit_item_validate function and I am able to add whatever path I type but deeper problems arise. It looks like if there is no corresponding entry in menu_router for the link and the external flag is FALSE it is not rendered in the menus at all. So either invalid links all need to be marked external or bigger changes made to the menu handling code.

What are the downsides of defining paths beginning with / as external?

Best regards,
Rado

Status:Active» Needs review
StatusFileSize
new1.45 KB
Failed: 11822 passes, 2 fails, 1103 exceptions
[ View ]

I have created a patch that classifies all paths that have '/' as the first character as external. As explained above I think this is the cleanest solution for linking to static files or other non-Drupal applications.

Minor changes in both menu.inc and common.inc are required but this is because the code is duplicated in both places. I am just beginning to look at how Drupal core works, so I don't know if it will be OK to call menu_path_is_external from within common.inc instead of the copy/pasting we have now. If someone confirms this is OK I can file a separate issue for code cleanup and submit another patch to remove the code duplication.

The way that the menu system in Drupal 6+ works I don't know what is the right way to fully implement what's requested in this bug. If anyone can give a general direction of how it can be done I can give it a try. It is easy to override the menu path validation, but then what?

Now you end up with 'hidden' items that exist in the menu_links table but are not displayed in the menus or even the admin UI from the menu module. The way it is now the menu module makes sure that only items than will take the current user to an actual page are displayed. If the user doesn't have privileges or the page does not exist the menu item is simply not displayed.

Status:Needs review» Needs work

The last submitted patch failed testing.

while i agree with absolute paths being handled as external, it is not a solution to this problem.

subscribe

subscribe

Hi,

Is there any resolution on this? It is really frustrating as I can not add simple menu item under primary links and all the previous menu settings are gone after upgrade. Here is an error I am seeing whenever I tried to add a menu item.

1. The path 'page' is either invalid or you do not have access to it.
2. The path 'gallery-assist' is either invalid or you do not have access to it.

I really appreciate if someone can post a workaround on this blocker.

Rgds

I would like to a "me too" to this thread. I would like the ability to link files such as PDFs from the menu without having to use the FQDN in the link (i.e. be able to specify "files/somefile.pdf" rather than "http://mywebsite.com/files/somefile.pdf"). This comes up often enough for it to be a pain. The same goes for page anchors.

Status:Needs work» Needs review
StatusFileSize
new2.69 KB
FAILED: [[SimpleTest]]: [MySQL] 20,585 pass(es), 1 fail(s), and 0 exception(es).
[ View ]

Okay, I dug a little deeper into this one and based on the solution presented in #53 have re-rolled a patch.

There are three classes of links two of which are handled properly by the menu system.

  1. Drupal paths - handled wonderfully. Thanks menu.
  2. URL's linking to external domains. - Again. no sweat, works great.
  3. URL's linking to my domain, but outside of drupal. - Ugh. Must use absolute urls to link to resources within my domain.

There are several scenarios where #3 can be a problem. If I have a dev/test/staging environment, I must change the menu items to reflect each environment - which can be massively painful you have a lot of links. Additionally if you change your domain name, or even have multiple domains resolve to the same server, you pretty much have to pick one to be on the menu. A prime example would be a site that uses drupal for all content management, but has a separate online store at the same domain.

So this patch makes use of a preceeding / to indicate "local to my domain, but not a drupal path".
It modifies url_is_external() to be aware of links local to the domain, changes _menu_link_translate() to strip the extra / off the front for display purposes, and alters menu_admin.inc to reflect the changes in the form instructions.

Please review with security in mind. I tried adding url's like '/<script type="text/javascript">alert('foo')</script>' and was unable to push a script tag through to the browser, but thats as far as I got.

This should *definitely* be its own issue as it does *not* solve the problem where an admin *wants* to add menu items for something that does not exist. A very useful feature IMO. I only attached it here as it was based on #53.

This seems like a very valid use case that's not handled well by core at the moment.

Status:Needs review» Needs work

The last submitted patch, local_domain_links.patch, failed testing.

I am absolutely unable to duplicate the failing test in my local environment. I have ran it against a clean HEAD, a clean drupal-7.x-dev, as well as drupal-7.0-alpha5.

Any ideas?

Status:Needs work» Needs review

#60: local_domain_links.patch queued for re-testing.

Status:Needs review» Needs work

The last submitted patch, local_domain_links.patch, failed testing.

I think It might have something to do with ssl not existing in my local dev environment, so, no idea how to even tell whats wrong here.
I guess I'll get ssl up and running.

Guys the patch at #37 was a complete failure. My drupal install went to shit too... DO NOT USE THAT CODE. Sorry.

Category:feature» bug
Status:Active» Needs work

#53 and what about "file://" link to local drive for intranet purpose? I can't get this to work at all. Can it be solved with bypassing the validation. Working on d6, but would'nt dare to touch the version selector :-)

See also http://drupal.org/node/361535#comment-3118130

subscribe

subscribe

This module is very handy for people who want to 'build up' sites without having content ready (which is my interest in this patch):
http://drupal.org/project/menu_editor

Thanks go to stevecowie for pointing it out.

Drupal paths - handled wonderfully. Thanks menu.
URL's linking to external domains. - Again. no sweat, works great.
URL's linking to my domain, but outside of drupal. - Ugh. Must use absolute urls to link to resources within my domain.

There is also links to tabs on the pages (i.e. quick_tabs)

This is where you might want to link to an anchor point or block within a node from a menu item. i.e still within drupal

I see that this has been quiet for some time now but I just ran into it on a site I'm developing.

What about adding a token capability?
Examples: the token [site] would validate but when rendered it would be replaced with the appropriate "http://site.domain/"

  • node/x => Drupal internal node
  • blog/my_latest_rant => alias
  • http://site.domain.com/some/resource => external link
  • [site]/sites/default/files/documents/The_document.pdf => static resource within the Drupal structure

I suppose that Drupal could also validate that the static resource exists too but it would be good enough if it just considered a link that started with the [site] tag as valid by default.

I'm still in the D6 development world and I need something to help me with my myriad pdf links.

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

Shouldn't this now be a D8 issue?

@74 Yes, and not a single kitten was killed for that.

Just for reference, I will kill a kitten each time i find the version selector on anything besides 8.x-dev before we have a fix in 8.x-dev from now on.

@73 I like that thinking, however, I personally think we should keep focus on the issue, and create a new feature request for token and/or streams (public:// and private:// at least) support in the menu system.

StatusFileSize
new2.73 KB
FAILED: [[SimpleTest]]: [MySQL] 34,382 pass(es), 1 fail(s), and 0 exception(es).
[ View ]

Here's a reroll of the patch in #60 for D8.

Status:Needs work» Needs review

Status:Needs review» Needs work

The last submitted patch, absolute-paths-308263-77.patch, failed testing.

Status:Needs work» Needs review

#77: absolute-paths-308263-77.patch queued for re-testing.

Status:Needs review» Needs work

The last submitted patch, absolute-paths-308263-77.patch, failed testing.

Tagging.

Hi guys, I made a module for this problem in d7 for a client that you may want to review.

http://drupal.org/node/1671230

Would appreciate any thoughts!

Category:bug» task
Priority:Normal» Major
Issue tags:+Usability

This remains one of the biggest UX WTFs we regularly encounter in testing (see #1167418: Workflow: What comes first while creating a page with a menu? Page or Menu?, which is marked as a duplicate), as well as a regression from D5 and earlier.

Does D8's routing system make this easier by chance?

The patch from #77 needs a re-roll (doh).

Experimenting with a solution for #1337546: Cannot reorder 'User Menu' items for user/register user/login as these are not accessible by admin give this issues title different meaning. What is meant by 'bypass'?

The patch from #77 just wants to add links like /my-page.html which is quite valid.

But the following issues
#308263: Allow privileged users to bypass the validation of menu items
#1337546: Cannot reorder 'User Menu' items for user/register user/login as these are not accessible by admin
#190867: Remove access check for anonymous users when creating aliases
suggest different bypass options.

Do we need to re-roll patch #77 or first figure out the issue summary?