Problem mit pathauto und i18n - URL-Alias wird nur für Source-Node erstellt

Kann es sein, dass es einfach nur an der Reihenfolge liegt?
Weiss jemand, welches der beteiligten Module definitiv als erstes bzw. letztes arbeiten muss?

Hast Du dafür eine Lösung gefunden? Habe hier das gleiche Problem.

Nope... keine Änderung.

Ich weiß ja leider auch nicht genau seit wann das problem besteht, da wir ne Weile schon keine Artikel veröffentlicht haben...

Ich hab in der Zwischenzeit das Update auf Drupal 6.16 durchgeführt. Und natürlich noch ein paar Modul-Updates. Aber ich hab keinen Schimmer, seit wann ich die Alias-Probleme habe.

Ich hab jetzt mal pathauto deaktiviert: keine Änderung, also scheint der Übeltäter woanders zu liegen.

Beim Versuch einen Beitrag eines anderen Inhaltstyps zu editieren, um zu überprüfen ob es ein generelles Problem, oder nur ein Typspezifisches ist, bekam ich beim Aufruf des Editors folgende Meldung gezeigt:

bio/2009 war aber genau der Alias diesen Beitrags (war da jetzt der Genitiv korrekt eingesetzt? ;-) )

Irgendwas stört die korrekte Alias-Erzeugung.
Ich war auch immer der Meinung, dass das Erzeugen bzw. Überprüfen des Alias erst beim Speichern des Beitrags stattfindet, denn solche Meldungen waren mir vorher immer erst da angezeigt worden.

OK, mir scheint, in der Datenbank ist etwas nicht in Ordnung. Bei der Aktion, aus einer "einfachen" eine Multi-Site Installation zu machen - also extra Domain-Ordner angelegt, themes und files aus dem all- in den Domain-Ordner verschoben, neue settings.php - ist vielleicht etwas kaputt gegangen.
Gibt es ne Möglichkeit, die Aliase neu aufzubauen? Vielleicht stimmt da einfach etwas nicht?
Oder Datenbank reparieren?

Nun gut, so richtig systematisch war das jetzt auch nicht, aber ich stehe auch vor einem riesigen Heuhaufen und hab keine Ahnung wo die Nadel sein könnte...

Kann sein, dass ich den Fehler gefunden hab.

Das Nachdenken über die DB brachte mich drauf, dass es ja auch noch das htaccess-File gibt, welches nach einem Verschieben der Ordner nicht mehr unbedingt passt.

Ich habe also admin/settings/clean-urls "Lesbare URLS" einmal deaktiviert und dann wieder aktiviert, damit der richtige Code in die htaccess geschrieben wird und es scheint geholfen zu haben.

@legolas: Vielleicht kannst du das ja bestätigen?

Zu früh gefreut.
Beim Überprüfen des zuletzt gesagten auf der Online-Installation mußte ich feststellen, dass das Problem nicht behoben ist. Es wird pro Node weiterhin nur ein Alias korrekt erstellt, und die zwei Übersetzungen bekommen keine Clean-URLs, egal wie ich es auch probiere, ob mit Automatischem Alias oder manuell eingefügt.

Merkwürdigerweise passiert das aber nicht bei allen Node-Typen. Aber eben zum Beispiel beim Typ News, der am häufigsten benutzt wird...

Hier ein Auszug aus der URL-Alias-Liste bevor ich einen der Beiträge editiere:
(Es handelt sich um folgenden Node: 2010 | 17 HIPPIES)

Nach dem Speichern kommt folgende Bestätigungsmeldung:

Und danach sehen die Einträge in der URL-Liste so aus:

Aus den unabhängigen Aliasen werden drei mal die gleichen.
Irgendwer ne Idee?

Hallo,

ich hab jetzt mal was anderes versucht. Üblicherweise installiere ich immer die deutsche Drupalversion vom drupalcenter. Jetzt habe ich mal eine von Drupal.org geholt, deutsche Sprache hinzugefügt ....

In Pathauto habe ich folgendes eingestellt: [language]/[menupath-raw]

Das funktioniert nur für die Beiträge der Standard-Sprache (deutsch), bei den englischen Übersetzungen bekomme ich /node/

Also noch keine Lösung

Bei mir scheint es zu funktionieren, wenn ich bei den Einstellungen der Inhaltstypen unter Multilanguage Options > Synchronize Translations keine Felder auswähle.
Welches der Felder beim Sync Probleme bereitet konnte ich noch nicht genau rausfinden, aber wenn alle deselektiert sind funzt Pathauto wieder...

Da war und ist bei mir keine der Checkboxen aktiviert ...

Na super, dann sind wir keinen Schritt weiter... oder?

Sieht wohl momentan so aus ...

aber ich habe das problem auch ohne locale module. plötzlich werden aliase zwar noch geniert, aber aufrufen funktioniert nicht mehr... clean url de- und reaktivieren hat auch nichts gebracht.

selbst deaktivieren, deinstallieren und neu aktivieren der beiden module hat keinen erfolg gebracht.

absolut rätselhaft.

Ich habe ebenfalls das Problem. Für die Quelle werden Namen etc. generiert, aber nicht für andere Sprachen. Wer weiß woran das liegt.

Das Problem liegt am Modul pathauto und tritt beim Update von Pfaden auf. Der erste Pfad bei i 18n wird korrekt dargestellt, beim Erstellen der Übersetzung wird der vorhandene Pfad zerstört.
Das Ganze gibt es als issue auf drupal.org .

Außerdem gibt es einiges an Patchen, damit habe ich herumprobiert und bin nicht glücklich geworden, da das Modul auch regelmäßig erneuert wird.

Für mich, ich brauche nur eine Handvoll Seiten in verschiedenen Sprachen, die sich auch erstmal nicht ändern, werde ich die Einträge per Hand in der Datenbank vornehmen. Sicher eine primitive Lösung, aber für ein korrektes Hacken der Module, habe ich doch zu wenig Kenntnisse über alle Konsequenzen.

Es ist die Tabelle url_alias

80 node/73 danora de
81 node/74 fr/danora fr

Ich habe noch ein Ländercode (fr) davorgesetzt. Da das Modul path vor dem Modul i18n aktiv wird, kann es gleiche Pfade nicht erkennen. Für mich war nur wichtig, das "danora" im Pfad steht.

Wer eine bessere Lösung hat, würde ich gerne testen.

Gruss

Katasun

Ich habe das Problem auf meiner eigenen Seite. Meine temporaere Loesung ist es, nach der Einstellung von neuen Uebersetzungen einmal auf admin/build/path/pathauto die Option "Massenerstellung von Aliasen für alle vorhanden Beiträge ohne Alias" anzuklicken und zu speichern.

hab das gleiche problem. Ennos Lösung ist noch die beste zur Zeit...

tja - und ich hab genau das gleiche Problem.
Solche Lösungen sind ja schön, wenn man Entwickler und gleichzeitig "Seitepfleger" ist. Aber wenn das - wie bei mir - ein Kunde ist ... :S
Kommt ja irgendwie blöde dem zu sagen: Sie müssen dann hier und da klicken und dann da den Haken setzen etc. pe pe

Gibt's da echt keine Lösung? Das würde ich ja schon fast als Major-Bug titulieren ...

tjaja, so ist das leider bei open source lösungen...
kann ganz schön nerven.
du könntest den funktionaufruf herausfinden und dann per cron oder bei jedem seitenaufruf neu ausführen lassen.

puh - das wird aber bei vielen Artikeln ne ganz schöne Serverbremse, zumindest wenn man das bei jedem Seitenaufruf ausführt. Per Cron wäre ok, aber dann sieht der Kunde trotzdem nicht den richtigen Pfad, nachdem er den Artikel gespeichert hat.
Es wäre aber natürlich denkbar den Bulk-Alias-Vorgang innerhalb einer Aktion beim Speichern des Artikels zu triggern, bzw. über "rules". Ich schau mir das mal an und gebe bescheid ...

so - ich hab jetzt "rules" installiert und zwei Regeln angelegt. Eine, die beim Speichern einer neuen node und eine, die beim Aktualisieren einer node ausgelöst wird. Bei beiden Regeln wird folgender PHP Code ausgeführt:

node_pathauto_bulkupdate();

Das scheint prima zu funktionieren und ich bin glücklich ;) Sollte sich (wider erwarten) eine Disfunktionalität herausstellen, werde ich es hier melden ...

sauber!
kannst du die angelegte regel näher beschreiben für leute, die rules bisher noch nie benutz haben?