Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#103 | 308263-menu-103.patch | 9.04 KB | dawehner |
#86 | local_domain_links.patch | 2.74 KB | uklcpsgr |
#77 | absolute-paths-308263-77.patch | 2.73 KB | davisben |
#60 | local_domain_links.patch | 2.69 KB | Mixologic |
#53 | absolute_external_path.patch | 1.45 KB | radolin |
Comments
Comment #1
alexanderpas CreditAttribution: alexanderpas commentedi'd say, keep validation, but make users with the right (new) permission to bypass the validation.
Comment #2
pwolanin CreditAttribution: pwolanin commentedI'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.
Comment #3
alexanderpas CreditAttribution: alexanderpas commented#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.
Comment #4
greg.harvey+1 for #1 =)
Also, it would be great if this was considered for back-porting to D6.
Comment #5
alexanderpas CreditAttribution: alexanderpas commentedImproving title to adhere to new scope.
Comment #6
joshuajabbour CreditAttribution: joshuajabbour commentedPersonally, 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.
Comment #7
pwolanin CreditAttribution: pwolanin commentedThe 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.
Comment #8
joshuajabbour CreditAttribution: joshuajabbour commentedBut 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?
Comment #9
pwolanin CreditAttribution: pwolanin commentedright - 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.
Comment #10
alexanderpas CreditAttribution: alexanderpas commentedin response to #6: this issue is specifically created for exactly that problem!
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!)
Comment #11
greg.harveyRe: #9
Perhaps I'm being dumb, but this was not the case for D5 so why is it the case now?
Comment #12
pwolanin CreditAttribution: pwolanin commentedThe menu system was completely re-written for 6.x. See the Menu system overview: http://drupal.org/node/102338
Comment #13
greg.harveyOk, 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... =(
Comment #14
Crell CreditAttribution: Crell commentedThis 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.
Comment #15
alexanderpas CreditAttribution: alexanderpas commentedfirst 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.
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!)
Comment #16
mpaler CreditAttribution: mpaler commentedJust 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
Comment #17
greg.harveyMike, 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). =)
Comment #18
mpaler CreditAttribution: mpaler commentedThanks 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
Comment #19
joshuajabbour CreditAttribution: joshuajabbour commentedIn response to #9, the last sentence of #8 should have read:
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...
And from the other thread:
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.
Comment #20
Crell CreditAttribution: Crell commentedI 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.
Comment #21
joshuajabbour CreditAttribution: joshuajabbour commentedForgot to switch back to bug report. Since this can cause data loss when upgrading, it's clearly a bug...
Comment #22
alexanderpas CreditAttribution: alexanderpas commentedlet's first fix D7, then worry about D6 ;)
I like where this is going, the only thing missing is a patch.
Comment #23
herzbube CreditAttribution: herzbube commentedRe #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:
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/")
[...]
Comment #25
silurius CreditAttribution: silurius commentedWhat 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?
Comment #26
ecksley CreditAttribution: ecksley commentedFrom 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!
Comment #27
silurius CreditAttribution: silurius commentedThis 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?
Comment #28
catch@ecksley, that's a different issue - #204077: Allow menu links pointing to dynamic paths - it also has a patch which needs testing.
Comment #29
plato1123 CreditAttribution: plato1123 commentedUgh, 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...
Comment #30
plato1123 CreditAttribution: plato1123 commentedThe developer(s) appear to have decided to give us all the middle finger
Comment #31
silurius CreditAttribution: silurius commentedThe 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?
Comment #32
keith.smith CreditAttribution: keith.smith commentedIf 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.
Comment #33
catchComplaining 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
Comment #34
silurius CreditAttribution: silurius commentedNo 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.
Comment #35
plato1123 CreditAttribution: plato1123 commentedYea 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 :(
Comment #36
greg.harvey@plato1123, did you *READ* #33 by catch? Specifically:
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!)
Comment #37
cryptkeeper CreditAttribution: cryptkeeper commentedTo 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
Comment #38
silurius CreditAttribution: silurius commentedAh, thank you very much, cryptkeeper. I may end up using this in time.
Comment #39
plato1123 CreditAttribution: plato1123 commented@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 :)
Comment #40
chx CreditAttribution: chx commentedPeople, linking outside of Drupal is done with absolute URLs. Nothing will change this fact. Drupal paths are, well, Drupal paths.
Comment #41
silurius CreditAttribution: silurius commentedPeople, 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.
Comment #42
plato1123 CreditAttribution: plato1123 commentedDo 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.
Comment #43
amariotti CreditAttribution: amariotti commentedAfter 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.
Comment #44
Anonymous (not verified) CreditAttribution: Anonymous commentedGood 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.
Comment #45
jptillman CreditAttribution: jptillman commentedI 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:
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.
Comment #46
rucativava CreditAttribution: rucativava commentedHello.
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?
Comment #47
Crell CreditAttribution: Crell commented@rucativava: Please go back and read #36, and then refrain from touching the version selector as described.
Comment #48
alexanderpas CreditAttribution: alexanderpas commentedI 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
Comment #49
rucativava CreditAttribution: rucativava commentedSorry.
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.
Comment #50
adellefrank CreditAttribution: adellefrank commentedI'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.
Comment #51
jwilson3I´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.
Comment #52
radolin CreditAttribution: radolin commentedHello,
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
Comment #53
radolin CreditAttribution: radolin commentedI 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.
Comment #55
alexanderpas CreditAttribution: alexanderpas commentedwhile i agree with absolute paths being handled as external, it is not a solution to this problem.
Comment #56
jennifer.chang CreditAttribution: jennifer.chang commentedsubscribe
Comment #57
attheshow CreditAttribution: attheshow commentedsubscribe
Comment #58
zirafi CreditAttribution: zirafi commentedHi,
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
Comment #59
sreese CreditAttribution: sreese commentedI 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.
Comment #60
MixologicOkay, 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.
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.
Comment #61
pwolanin CreditAttribution: pwolanin commentedThis seems like a very valid use case that's not handled well by core at the moment.
Comment #63
MixologicI 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?
Comment #64
greg.harvey#60: local_domain_links.patch queued for re-testing.
Comment #66
MixologicI 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.
Comment #67
cryptkeeper CreditAttribution: cryptkeeper commentedGuys the patch at #37 was a complete failure. My drupal install went to shit too... DO NOT USE THAT CODE. Sorry.
Comment #68
Siekee CreditAttribution: Siekee commented#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
Comment #69
idflood CreditAttribution: idflood commentedsubscribe
Comment #70
cbear42 CreditAttribution: cbear42 commentedsubscribe
Comment #71
greg.harveyThis 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.
Comment #72
2dareis2do CreditAttribution: 2dareis2do commentedDrupal 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
Comment #73
Anonymous (not verified) CreditAttribution: Anonymous commentedI 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/"
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.
Comment #74
greg.harveyShouldn't this now be a D8 issue?
Comment #75
alexanderpas CreditAttribution: alexanderpas commented@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.
Comment #76
clemens.tolboomXRef #1337546: Cannot reorder 'User Menu' items for user/register user/login as these are not accessible by admin
Anyone up for an issue summary on this one?
Comment #77
davisbenHere's a reroll of the patch in #60 for D8.
Comment #78
davisbenComment #80
davisben#77: absolute-paths-308263-77.patch queued for re-testing.
Comment #82
yoroy CreditAttribution: yoroy commentedTagging.
Comment #83
caseyc CreditAttribution: caseyc commentedHi 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!
Comment #84
webchickThis 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?
Comment #85
clemens.tolboomThe 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?
Comment #86
uklcpsgr CreditAttribution: uklcpsgr commentedUsing any_menu_path module requires some coding in my case, since I'm using menu_editor on my project. So I've updated #60 a bit to make it work against current D7 core. Are there any other options available by now to solve this problem?
Comment #87
chx CreditAttribution: chx commentedThis is a D7 issue now. D8 has added a permission to bypass. It occurs to me that adding such a permission would be the best for D7 as well. David, is adding a new permission OK with you?
Comment #88
webchickNo... D8 doesn't yet bypass 404 validation, which was the entire point of this task; to restore D5-esque behaviour of allowing you to build out your entire site tree *first* and then fill it out with pages later.
Comment #89
dawehnerWhich is exactly what the "link to any page" permission allows.
Comment #90
dawehnerMh I talk about 403 you about 404, maybe this is the difference.
Comment #91
webchickRight. So AFAIK this is still valid for 8.0.x. Or, we need a dedicated follow-up for 8.0.x for expanding "bypass link validation" to 404s as well in order to actually, you know, bypass validation. ;) And then make this issue a D7 issue just about matching existing D8 behavior, which is bypassing 403 checking only.
Comment #92
dawehnerWell, technically isn't that a feature request compare to the state of d6 and d7?
Comment #93
MixologicWould the 'link to any page' work if I've got multiple services on my domain and they are not all drupal? I.e. If I want to link to my discourse forum that I have running on mydomain.com/forum, will that permission allow me to link to "/forum" such that it works on my staging server as well as on production, without having to hardcode the mydomain.com or staging.mydomain.com?
Comment #94
David_Rothstein CreditAttribution: David_Rothstein commentedWhat @webchick said makes sense to me.
Regarding adding a new permission to a stable D7 release, that seems pretty consistent with https://www.drupal.org/node/1527558 (actually I just read it now and it mentions "new permissions" specifically!), so sure, why not.
I'm not clear if the new permission would be strictly needed for 404s (i.e. if there are potential security issues with opening that up to regular admins too?) or just for 403s... All else being equal, I would suspect the 404 functionality is more useful to people, but I suppose we could look into backporting either.
Comment #95
chx CreditAttribution: chx commented404 can't happen for D8. It is not possible without some interesting refactor cos the route name and parameters are stored IMO for menu links. Even if the TODO is resolved to use a link field #2302205: Create link field for menu_link_content baseFieldDefinitions it will still store the route name and parameters.
Comment #96
dawehner@chx
. If you have something like 'link to any page' in place, you could store the url instead of route name + parameters, in case
you don't know them. This itself though would require internal changes ALL over the place as code assumes that internal bits are represented
as routes, as chx wrote.
Comment #97
webchickThis may be a stupid question, but can we store something like a "null" route? This would prevent wide-spread systemic changes that no one wants to do (least of all this close to beta) and would also give us something to hinge off of if we wanted to in later minor releases of D8, or contrib, add features like a Wikipedia-esque "This page doesn't exist. Would you like to add it?"
Comment #98
chx CreditAttribution: chx commentedMy idea was: Add an
extracted
0/1 flag. When the caller (don't touch anything in Routing) sees a 0 extracted flag it tries to extract as it does now on save time. If extracting succeeded; save the parent (good that typed data lets fields save their entities) and retry rendering a link which will now succeed. If extracting failed then do not even attempt rendering a link just print the link title -- cos you are linking to where?Comment #99
MixologicYou might be linking to your own domain, just *not drupal*. Its not even a 404 or a 403, its a 200.
Does the d8 menu assume that a local link has to be a drupal link?
Comment #100
dawehnerI would argue that it does not explicit at the moment, but implicit you cannot link to something else than drupal provided links,
exactly like Drupal 6 and Drupal 7.
Comment #101
MixologicWhich comes back to something Webchick hinted at in #88 - do we consider this a new feature, or a fix of a very old regression from d5?
Comment #102
Crell CreditAttribution: Crell commentedThis is a very old regression.
Comment #103
dawehnerTried to implement that for link items, as they should be used for menus as well on the longrun (you though for sure can use the unterlying features
also to support it in menu links directly).
This was primarily just an exercise to figure out whether it is possible at all, note: This doesn't update the link items
automatically yet once the routes exists, but this is not a big deal tbh.
Comment #104
dawehnerLet's see how broken it is atm.
Comment #107
effulgentsia CreditAttribution: effulgentsia commentedComment #108
dawehner@effulgentsia
So do you think we should simply mark this issue as duplicate of the one you linked?
Comment #110
dawehnerYeah I think we have solved that now with the #404 resolving and the
link to any page
permission.Comment #111
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedComment #112
clemens.tolboomThis issue is marked Fixed for D8 in #308263-110: Allow privileged users to bypass the validation of menu items due to #2418181: Remove 404 validation from link creation I don't think we will solve this for D7 anymore.
> Supported until (at least) November 2023. Use this version for sites already running Drupal 7.
Should we close this?