Is it a good idea to have two different types of URL for many administration functions in core?

I was thinking about this the other day but did not file an issue - thanks for doing so :)

For documentation purposes, I think it's definitely the case that http://localhost/drupal7/admin/config/modules should be used. Perhaps the overlay module will wind up auto-redirecting that to http://localhost/drupal7/#overlay=admin/config/modules to force it to appear in the overlay for users who have appropriate permissions (there are a variety of reasons why that should make sense), but the standard URL should be used in documentation.

The opposite direction: I definitely agree that's a problem. We do not want people passing around URLs like http://localhost/drupal7/#overlay=admin/config/modules if they only work when a certain module is enabled. This is a general issue, though, and perhaps a problem for core to solve either way (using fragments for JavaScript like this is getting very common - see, for example, Gmail). I think it is not hard for core to automatically redirect URLs like http://localhost/drupal7/#overlay=admin/config/modules to http://localhost/drupal7/admin/config/modules in the case where the overlay module is not enabled. That redirect won't work if JavaScript is disabled, though, which I guess would cause problems if this stuff is ever getting indexed by search engines - however, these aren't the types of pages that tend to be.

Also, ideally we would not special-case the overlay here; there would be a more general fragment name (something like #display rather than #overlay) that any module could use, and some kind of method for modules to tell Drupal that they want to actually use it - the overlay module being just one example. If no module claims it, Drupal would redirect to the canonical URL.

I'm just subscribing here- the answer seems obvious to me: it's a terrible idea to have two different types of URLs for most admin functions (I'm assuming this will happen for contrib modules as well).

Right, this is not about ugly URLs - and I'm not sure what I wrote above that suggested it was :) ....

I don't actually think multiple URLs are a fundamental problem. Drupal already allows you to make URL aliases (which are true duplicates in functionality, as compared to the ones we're talking about here, which are not). The problem here is just that when the overlay is not available, the duplicate URLs do not display what we'd want them to.

Again, we ideally need a general way to fix this because you need this method to do any kind of real navigation using JavaScript. The jQuery BBQ plugin for handling these types of URLs is available to be loaded whenever it is needed (http://api.drupal.org/api/function/system_library/7). The question is how to use it in a general and efficient way. I don't have a good sense of how to do this at the moment, but I think it starts by looking at the Drupal.overlay.trigger() function and trying to generalize that.

Patch in #668104: Make overlay respect other click handlers at least keeps all origional URLs in html source; users can easily copy them.

Sub.

This is *really* going to hurt documentation and support.

I suggest upping this to critical.

I think that having two URLs for these pages is going to really confuse and probably anger some groups of people. If it doesn't get fixed I can see it being another DrupalWTF (adding the tag).

Isn't there some other (invisible) way that Overlay could decide if something should be shown in an overlay or not?

@shunting

Why is the hash syntax needed in the first place?

I believe the main reason was that it allowed for the browser's forward/back buttons to remain intact. So, you click a link in the toolbar and decide you didn't want that, you can just click back to make the overlay go away, whereas without the hash syntax, clicking back would take you all the way back to the previous page. It's also useful for navigating inside the overlay...such as if you click Configuration and Modules in the toolbar to open the overlay, then click Modules inside the overlay, and then decide you really wanted Configuration, you can just hit back.

So whatever this issue does, I think it's pretty important that it keeps the forward/back buttons working as expected.

Is there some Javascript trick that can be used to replace the address that is shown in the address bar once the page has loaded (I doubt it)? eg. replace http://localhost/drupal7/#overlay=admin%2Fconfig%2Fmodules with http://localhost/drupal7/admin/config/modules so that anyone copy/pasting the link gets the non overlay version, but forward/back still works as expected? Just a thought.

Not really, not without a reload of the page. It cannot be done for security reasons.

as I thought.

I guess the following might throw some light to this issue:

suppose you have clean URLs enabled, but suddenly they stop working (upgraded the host, disabled mod_rewrite, migrated the site, whatever reason) then all URLs you have distributed (e-mails, other websites like: twitter/slashdot, etc) will stop working, since now they require a ?q= prefix that didn't previously existed

on the site note: also if you didn't previously disabled clean URL through the admin interface you'll have to go to the {variable} table and manually set clean_url to false (i.e. s:1:"0";) to get the site back

isn't the #overlay= prefix the same case just with inverted logic?

probably they should be a README.txt note stating that in this case an HTTP 301 should be returned for those URLs, even through RewriteRules, PHP code, Global Redirect, etc

There should be a standard for linking to the non-overlay URL in documentation. #668104: Make overlay respect other click handlers fixes the rest of the issue. This isn't critical.