Changing a title on a draft of an already published article generates a 404 when publishing

Installing and enabling Pathauto Persist should take care of this issue -- it did for me: http://drupal.org/project/pathauto_persist

It's also a suggested module in the Workbench Moderation docs: http://drupal.org/node/1175576

Matt Butcher, let me know if that fixes the problem for you.

Using Pathauto Persist does not fix the problem for me. I am using a complex pattern in Pathauto that relies on several fields in my content, not just the title.

A possible solution is to simply ignore the path alias when redirecting. The drawback is that the page will be loaded with the system path (node/1234) instead of the alias, but that is easier to digest than a 404.

Test failed due to git.drupal.org being unreachable. Trying again.

#3: 1379088-3-workbench_moderation-pathauto_404.patch queued for re-testing.

#3: 1379088-3-workbench_moderation-pathauto_404.patch queued for re-testing.

pfrenssen, what is your pathauto pattern? I'd like to test with it.

@stevector this is the pattern that was the use case for the patch: [node:regiontype]/[node:og-group-audience:first]/nieuws/[node:title]

* [node:regiontype] is a custom token that returns one of two different strings: 'provincie' (= 'province') or 'gewest' (= "state"), depending to which Organic Group the content is posted.
* [node:og-group-audience:first] is a custom token that returns the machine name of an Organic Group (ref this sandbox: http://drupal.org/sandbox/pfrenssen/1315154).
* Nieuws: fixed string (= "news")
* [node:title] is a standard token

A typical use case that triggers this bug is that one of the moderators changes the Organic Group a piece of content belongs to. This would for example change the clean URL from "provincie/antwerpen/nieuws/title" to "gewest/vlaanderen/nieuws/title". But simply changing the title also triggers the bug.

I have Pathauto Persist installed. I have not looked into why Pathauto Persist does not cache this path. Anyway my patch also solves the problem for people that do not use Pathauto Persist.

I've been told that the patch mentioned in #8 also solves my problem mentioned here...

http://drupal.org/node/1700778

This problem has been outstanding for some time now. I think it's important to fix the problem because most people who use Workbench also use Pathauto. Is this patch ever going to make it into a new version of the module? Our department's policy is to only use official releases of contrib modules, not patches or customizations. If the patch is not going to result in a new version/revision of the contrib module any time soon, then is there another solution for me?

Please advise. And as always, thank you in advance for any assistance.

Thanks,
John

@TheSasquatch: I'm sorry to hear that your company's policy is to avoid using patches. This issue is still awaiting review. Somebody will have to take the time to test and review the patch and mark it as "Reviewed and tested by the community". Following that the maintainers can take this patch into consideration for inclusion in the module. For more info please refer to Reviewing patches.

This might also be relevant for you: Getting an issue addressed sooner.

I would love to help review it, but that is outside the scope of my skill set and availability. I'm simply too busy with work and family to contribute at that level, plus I do not have experience with such things. I would consider donating cash to pay someone else to do it if there is such an option. Hopefully someone else can help review the patch in the meantime, as I think this is a serious glitch. I would assume that most people who use Workbench also use Pathauto.

doesn't pathauto persist simply ensure that if you manually enter a path it doesn't get overwritten by the pathauto module? That's my understanding of it. This issue seems to be with new aliases being created that aren't being used by workbench when saving a new published version.

If so then it seems that pathauto_persist would not address this issue. I am having the same issue where if you update a previously saved node and change the title, then when you publish the node it can't find the page. This is because you are redirected to the old url but that is gone now and there is a new url.

E.g.
the title was "Local man saves dog"
the url is www.site.com/local-man-saves-dog

now the title is "Local man saves cat"
the url is www.site.com/local-man-saves-cat

instead of going to "www.site.com/local-man-saves-cat" it goes to "www.site.com/local-man-saves-dog"

Everything works ok but when the new draft is published the old url disappears and the new one is effective. The problem is that you are redirected to the old url and it doesn't exist.

I don't think that the complex pattern was even an issue. I have the default pattern in my url and I have the same issue.

If you can't use a patch and need a workaround just change the url alias setting so that it creates a new alias and leaves the old alias functioning. Then maybe use the redirect module to ensure that users are always sent to the canon url if that's an issue.

This seems to be an issue with Workbench not sending you to the correct url. Workbench should get the correct url and send you there. Everything else seems to be functioning as intended.

Sorry for repeating details that Matt Butcher already stated when he submitted the issue but just wanted to clarify that I don't think pathauto_persist will address the issue since it looks to me like it's function is to make sure pathauto doesn't overwrite any manual url entries with an automatic url alias.

The patch worked for me. It sends you to the actual url instead of the url alias. The url alias is still created though, which is good.

Thank you Pieter Frenssen, you saved me some trouble :)

#3: 1379088-3-workbench_moderation-pathauto_404.patch queued for re-testing.

Never mind.

Here's a version of the same patch that includes a test of whether applying the patch results in a redirection to a valid path upon republishing the node after title change.

Here's a slightly revised patch that cleans up some comments and removes trailing whitespace. Bbinkovitz, you can configure your IDE to automatically remove that too.

I've also remove the setting of the body field in the test and the intermediary transition to "needs review." The bug still occurs without these.

I shouldn't have changed the status there. Bbinkovitz, any objections to these changes? I think this is commit-ready.

Cool, thank you Steve.

http://drupalcode.org/project/workbench_moderation.git/commit/931e01e0b7...