Live preview of what the URL will be in the field.

It's at least as high priority if not more than the other issue.

I was working on a separate module to do this.

Will now look at doing it as a patch.

I have been working on this for two hours. Here's what I have so far.

Would be great if someone could take a look at it.

I am going to do a bit of testing and work on it for the rest of the day.

I haven't looked at it properly but there is at least one line of debug code that needs to come out

//drupal_set_message('<pre>'.print_r($placeholders,true).'</pre>');

Oops, thanks stewsnooze.

Also it works great when adding a new node, but seems to break when editing an existing one.

Access argument changed to "create url aliases".

Next iteration.

Now works better for existing nodes, and previously noted comments fixed.

A lot of this should be able to be simplified as you can use pathauto_create_alias() with the 'return' op.

It cannot use the return op until the alias has been created.

Unless the patch patches pathauto_create_alias() to return paths for uncreated aliases.

What's wrong with pathauto_create_alias() with the 'return' op before an alias is created? I would think we would need to fix it to work in that case.

Oh, because node->nid is empty a lot of stuff goes wrong with that.

pathauto_create_alias() (http://drupalcontrib.org/api/function/pathauto_create_alias/6) requires the $src (The "real" URI of the content to be aliased (e.g., "node/$node->nid")). This (nid) is not available until the node has been saved. One option is passing the part of the node (such as nid or title) instead of $src, then doing a node load. If the node does not exist them a dummy node can be created with all known information.

Maybe this method needs a little more discussion, IRC anyone?

The current patch seems to do a good job in my view without any fundamental changes to the existing pathauto code. FAQ and Ubercart modules uses
pathauto_create_alias(), so they will be affected by the changes.

This patch now uses pathauto_create_alias().

A few things I've already noticed:
1. This won't work if the clean urls are turned off (using paths like ?q=node/add/story) because the JS tries to load a clean url path which may not work. We have to add a JS setting to give us the proper base URL because Drupal.settings.basePath does not provide the necessary information.
2. We should probably add the node type as a Drupal.settings.pathauto['nodeType'] instead of parsing it from the form ID and then having to strip '_node_form' from it.
3. So to review this will only work with basic tokens, like node title, and not with field values.
4. All of our JS callbacks return JSON, so it seems odd that this doesn't.
5. The JS callback should probably call a direct exit() because currently this will still allow modules to execute in hook_exit() (e.g. devel and it's query output).

Factored in all Dave's suggestions.

I will install vertical tabs and test.

I am also thinking of removing the "Automatic alias - An alias will be generated for you. If you wish to create your own alias below, uncheck this option." text along with the checkbox and replacing it with an edit button next to the live URL.

Much like Wordpress.

I don't think that makes sense as a solution for all of Pathauto's users. We should make it easy to do that for an installation profile that needs it, but I'm not sure for everyone else.

Greggles: Would this be better as a contrib module?

I love the idea of alias preview prior to node submission in Pathauto itself but I think we should put it where we put all the other metadata - in the fieldsets at the bottom of the node.

I'm just not sure (though could be convinced) that putting it under the title is the best place for it. I saw that feature in Jens' presentation about Wordpress and was instantly excited about putting it in Drupal. But having it right under the title - i.e. the second most important spot on the page - feels like an overemphasis on something that is mostly not important (the url).

If Drupal were only a blogging platform, I could definitely see sticking it right under the title.

Sorry, I guess I didn't explain correctly.

My only change would be removing the "Automatica alias" checkbox and replacing it with an edit link / button next to the live URL. The edit link will perform the save function as unchecking the checkbox.

The pathauto settings would stay in the save place on the node/add form in the same field set.

Here's where I am so far.

Sub. Nice work so far, Tim. Is this for Project Verity, by any chance?

I guess what I'm unsure of is what is actually being moved/removed from the 'Path' fieldset on the node add/edit form. Any number of modules could add form elements to the fieldset, so we can't get rid of it all. Or maybe you're changing the weight of the path fieldset to move it up above. Maybe longer screenshots would help me see the context?

The only reason it is up the top is that I am using the nodeformcols (http://drupal.org/project/nodeformcols) module to sort the fields. Maybe if I install the patch on an vanilla drupal install and allow anonymous posts you can all take a look.

Give it a try.
http://pathauto.millwoodonline.co.uk/

Here is the latest patch and the new pathauto.css file.

I can image a ton of support requests with people saying "I changed this random field value which is used to generate the URL. Why didn't the preview change?" I feel like we need to add something in the help text that says "This only previews changes to the title."

It will only be an issue if the settings on "admin/build/path/patterns" are changed. Maybe the help text should go there.

Or maybe if the pattern is invalid for live previews, then live previews is disabled.

I agree that help text makes more sense in the admin area and/or the idea of disabling the live previews for patterns that are weird. I think this functionality should work for title, global tokens (i.e. date), and most node tokens, right?

I'm a little wary of only enabling it for certain patterns (i.e., those in which the only token is the node's title, I guess?). Seems like it would only add confusion for it to work on some content types and not on others, depending on how the patterns for those content types are set up.

IMO, it either needs to work consistently no matter what field is being changed and no matter what the pattern is (which may or may not be realistic), or it should not be included by default.

@greggles: yes, the patch generates a fake node object with $node->uid, $node->name, $node->title and $node->type, this is then passed to pathauto_get_placeholders() to generate which creates the tokens. So, yes, a lot of global and node tokens are available.

@mcrittenden: I think if we all can't agree on on things like this I would vote for it to be another contrib module "pathauto live" or something.

I just tested out the demo, it seems awesome to me.

Tim, what do you think, can you figure out which tokens won't work and disable it in those cases? I'd love to get this patch in and have some time to review/commit if we can get that last piece.

Shouldn't be a problem, I'll see what I can do over the next 24 hours.

It has been a month since I said "I'll see what I can do over the next 24 hours", but I have just been super busy with client work, drupalcon etc.

I do still want to get this done for Pathauto!

pong.

It's still on my todo list.

Features must go in 7.x-1.x and then get backported to 6.x-2.x.

Here's an approach that uses AJAX, so that it works for any token pattern without exposing the token structure to the client-side code. Whenever any form element is changed, the "live preview" is marked as needing an update, and via css, becomes grey. An AJAX request to update it is only triggered when the preview element is visible, so that if its vertical tab isn't currently open, we don't generate needless round trips to the server.

Because Pathauto is already at RC status, and this is experimental code, this is implemented as its own module. That way, people wanting it can enable it, but not every user of Pathauto has it forced on them until it's been well tested in the wild.

@effulgentsia: Can you provide this is a sandbox in the meantime so I can easily check this out via git?

@Dave Reid - I have gone ahead and set this up as a git project here: https://github.com/webgeeks/pathauto_live_preview

I am interested in getting this functionality working and so I will be taking a look at it and seeing what I can do.

Thanks!

Sean

Thanks @pyrello for #48, which works fine. However, I haven't managed to move the live preview out of the default vertical tabs to directly below the title field where it properly belongs. Neither hook_form_alter() nor hook_form_BASE_FORM_ID_alter() seem to operate on the vertical tab groups. I also tried using Renderable elements together with Field group to move the relevant fields to near the top of the node edit form, but this is cumbersome, results in the relevant fields appearing twice, and breaks the edit button functionality. Any clues would be appreciated.

@cbrody - I am accomplishing it via a custom module. Here is the code I am using:

function YOURMODULE_form_alter(&$form, &$form_state, $form_id) {
  if (isset($form['#node_edit_form']) && $form['#node_edit_form']) {
    $form['path']['#group'] = ''; // <-- This is what you are really looking for
    $form['path']['#title'] = '';
    $form['path']['#collapsible'] = FALSE;
    $form['path']['#collapsed'] = FALSE;
    $protocol = isset($_SERVER['HTTPS']) ? 'https://' : 'http://';
    $hostname = $_SERVER['SERVER_NAME'];
    $form['path']['alias']['#title'] = t('<strong>Link:</strong> @baseurl/', array('@baseurl' => $protocol . $hostname));
  }
}

This removes the path section from vertical tabs, as well as making several other modifications that I needed to make. Also, you could set the weight here, but I do it via the manage fields page for that content type.

Hope this helps!

Sean

Nice work so far.

This is a fringe case, but an AJAX error occurs if you make a change to the title and then immediately close the editing form. (Say you spontaneously changed your mind about making the edit.)
This happens with both the patch in #46 and the github project in #48.

An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /system/ajax
StatusText:
ResponseText:
ReadyState: 4

Re #51: Thanks. It's a known and frustrating core bug: #1232416: Drupal alerts "An AJAX HTTP request terminated abnormally" during normal site operation, confusing site visitors/editors.

Hi all, if anyone wants a simple, stable implementation of this on node forms, you can use alias_preview.

That said, this looks like a better general solution that could be integrated into a nearly-ubiquitous module! The issue in #51 seems to have been resolved (see https://www.drupal.org/project/drupal/issues/2808789), so maybe this can be merged in to 7.x-1.x?

Update: I just re-queued tests and there is one new failure:

"The Pattern for all Basic page paths cannot contain fewer than one token."