Posted by fundam on July 29, 2011 at 10:36am
3 followers
Jump to:
| Project: | Content moderation |
| Version: | 6.x-1.9 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
There is a strange behavior with the content moderation and pathauto module used in a multi-language use case.
Under the following settings:
- Content Moderation: "Force publishing on new nodes" = deactivated
- Content type xyz = published setting = deactivated
- i18n module active and Language negotation = path prefix only or path prefix with language fallback
- Create a new page/node within the default language e.g. englisch = page is in draft (correct)
- Create a new Translation of this new node e.g. in german = translation page is directly live (not correct, should be also in draft)
- For the new translated node which is referenced by a tnid to his language friend the path alias is not working anymore in anonymous state.
If you logged out and look into the source code of your site, the href will be set to node/123 instead of the path alias of the translated page.
Also any manually changes to the path alias will not be set.
If I use the content moderation module with setting the Force publishing on new nodes to yes, the path alias for the translated node is working correct.
To get the path alias back for broken translated pages, I have to delete this pages and then translate it again with content moderation module = setting the Force publishing on new nodes to yes.
In a nutshell, I cannot use "force publishing on new node" = deactivate for a multilanguage website.
Would be great if this could be fixed.
Tested under Drupal 6.22
Comments
#1
Because I am at the point of using this module in a multi language site I browsed the issue cue. I tested all the above and I must say that I do not have this issue with Pathauto/path alias. I can access the nodes with the correct translated path alias.
I do experience the issue with the translated node is published while the source node is not.
#2
with the current API we have in D6, and the core implemention of i18n this is close to not fixable. Iam open for any suggestions, but marking it as an optional feature request as i18n is contrib ( and what a kind of contrib..... )