I don't know if this package is still maintained, but I hope so as it's a must for enterprises (I would like to see it in core!).

Each time a user log in, its "blog path" set through "pathauto" package is reseted. So, for example: if before logging was "blogs/foo", after the log in the alias is removed and the link becomes "blogs/5".

To recreate it:

  1. enable the "blog" core module.
  2. install and enable "token" and "pathauto" modules.
  3. to automatically create content, install "devel" package and enable "devel generate" module; use it to create some blog posts (of course some user must be already setup with LDAP support).
  4. all content should now have correct URL aliases (if not, with the "root" account go to "URL aliases" menu and force bulk rebuild of all aliases).
  5. log in with a normal LDAP user account.
  6. It's "blog/[user-raw]" alias is removed.

It seems to affect only the "blog paths" setting.

A workaround seems to set "LDAP data synchronizing options" to "On each page load"; the other two values show the previous wrong behavior.

Regards,
Daniele.

CommentFileSizeAuthor
#2 ldap.jpg24.14 KBaschiwi
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

aschiwi’s picture

I have a similar problem with user aliases. My pathauto token is users/[user-raw], which gets transformed into users/firstname.lastname. Now when anyone with an ldap account visits a user with an ldap account, and I mean just visits, the alias gets lost, the URL turns into users/[user-raw]-1 or whatever. Took me forever to find out where this was coming from, especially since I go through the site as user 1, who is not an ldap user. I finally found the source of the problem when the problem didn't show up for one guy, who seems to not be an ldap user. I guess I just want to document it here, will solve it by using uid as a token, which I _hope_ will solve this.

aschiwi’s picture

FileSize
24.14 KB

Using the [uid] token does not solve this.

It happens because Synchronizing options were set to "Every time user object loaded in Drupal. (May cause high LDAP traffic.)" on admin/settings/ldap/ldapdata

Setting it to "when user logs in" solves my problem, but I can't tell yet if new problems will crop up this way.