Hello. I think I've found a bug in the way Workbench handles automatic aliases in conjunction with pathauto. I've tested very thoroughly on a number of clean installs and have also searched extensively through the issue queue to make sure I'm not duplicating the issue.

Configuration Summary:

Installed Drupal version: 7.8

Enabled modules:

  • views-7.x-3.0-rc1
  • ctools-7.x-1.0-rc1
  • token-7.x-1.0-beta6
  • pathauto-7.x-1.0-rc2
  • workbench-7.x-1.0
  • workbench_access-7.x-1.0

Steps Taken:

  1. Perform default Drupal 7.8 install
  2. Install and enable above listed modules
  3. Proceed to configure Workbench Access screen
  4. Select the Install the test configuration for Workbench. option
  5. Confirm installation of test configuration
  6. Proceed to admin/config/search/path/patterns to set alias pattern, using [node:workbench-access-sections]/[node:title] as the default path pattern for Content Paths
  7. Proceed to node/add/page and add page of type Basic Page called Pathauto Test
  8. Ensure that Automatic alias is checked
  9. Save page.
  10. Resulting URL is unassigned/pathauto-test
  11. Verify this is accurate by running the query select * from url_alias and see that the alias value for the newly created page is unassigned/pathauto-test
  12. Click Edit tab on unassigned/pathauto-test page
  13. Select URL path settiongs option
  14. Automatic alias is unchecked.
  15. Check Automatic alias and click Save
  16. Resulting URL is museum/pathauto-test
  17. Verify this is accurate by running select * from url_alias and see that the alias value for the page is now museum/pathauto-test

I am thinking this is a bug since it happens with a vanilla install of Workbench and Workbench access using the test configuration. If not can anyone point out anything that I've missed in my setup that could be causing the problem?

Thanks,
Pablo

CommentFileSizeAuthor
#12 1319988-fix-token-outputs-unassigned-new-content.patch1.25 KBdave reid
#8 token_array-1319988-7.patch739 bytesstevector

Comments

stevector’s picture

stevector
he/him
commented
Status: Active » Postponed (maintainer needs more info)

Have you seen this issue? #1087044: Custom URL path settings do not survive moderation

Are you using Workbench Moderation?

Pablo Gosse’s picture

Pablo Gosse commented

I had it enabled in my initial install where I encountered the same behaviour. I did not have it enabled in the install from which I outlined the steps listed above.

I just enabled it and the behaviour is the same. Add a page and it gets aliased to unassigned/node-title. Edit the page and the Automatic alias checkbox is not checked. Check it, save, and the alias is updated to museum/node-title. On subsequent edits the Automatic alias checkbox is checked.

If there is any other info you need or anything you'd like me to test please let me know.

Thanks,
Pablo

stevector’s picture

stevector
he/him
commented

Are you using Pathauto Persistent State? Your issue sounds similar to the one described in #1087044: Custom URL path settings do not survive moderation

Pablo Gosse’s picture

Pablo Gosse commented

Sorry, forgot to include my reply to your question about the previous issue. Yes, I saw that issue but felt that it wasn't the same issue since in my situation the problem is being encountered upon first creation of the page, not on page revision. I am selecting 'Automatic alias' when creating the page, but the alias isn't getting created correctly using the [node:workbench-access-sections] token.

Am I incorrect in thinking this?

Thanks,
Pablo

Pablo Gosse’s picture

Pablo Gosse commented

Nope. I've not seen the Pathauto Persistent State module. I'll install it and see if that rectifies the situation.

Thanks,
Pablo

Pablo Gosse’s picture

Pablo Gosse commented

Tried using Pathauto Persistent State. Same result, the alias museum is not being set on creation and is instead set as Unassigned.

Thanks,
Pablo

stevector’s picture

stevector
he/him
commented
Project: Workbench » Workbench Access
Priority: Major » Normal

This sounds like an issue of Workbench Access tokens not working until after the node is created.

stevector’s picture

stevector
he/him
commented
Status: Postponed (maintainer needs more info) » Needs review
StatusFileSize
new token_array-1319988-7.patch739 bytes

I don't fully understand the difference between $node->workbench_access and $node_workbench_access_id. Switching to the latter seems to fix this particular issue.

This comment in workbench_access_node_insert() suggests to me that one of these arrays should be eliminated.

  // Temporary fix for node property mis-match between node_load() and node_save().
  if (!isset($node->workbench_access_id) && !empty($node->workbench_access)) {
    $node->workbench_access_id = $node->workbench_access;
  }
Pablo Gosse’s picture

Pablo Gosse commented

Yep, I've been playing around with this since late last week and suspected it was related to the tokens. That had previously led me to this issue, http://drupal.org/node/1237284#comment-4876508, which seems to be related and raises the exact question that you raise around $node->workbench_access and $node_workbench_access_id.

I'm still pretty new to Drupal and the university where I work is currently evaluating a few products as candidates for our new CMS (Drupal and two others). Sorry I wasn't able to dive more deeply into the code to help fix the issue but being new to Drupal and still in the evaluation process my time is limited with this (I'm the only web developer here).

Thanks so much for your prompt replies and the fix. I'm really hoping we select Drupal as it will provide me the opportunity to get more deeply involved with the project.

Thanks,
Pablo

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

@stevector see #1252460: Node property mis-matches between node_load() and node_save() for details about the code comment in #8.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Title: Workbench & Pathauto: Automatic Alias setting not being maintained when page created » With new section-assigned content the [node:workbench-access-sections] token is 'Unassigned'
Version: 7.x-1.0 » 7.x-1.x-dev

This is a better fix in the meantime until #1252460: Node property mis-matches between node_load() and node_save() is fixed.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
StatusFileSize
new 1319988-fix-token-outputs-unassigned-new-content.patch1.25 KB
dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

The patch in #8 will cause a regression if you are using just node_load() and node_save() directly as $node->workbench_access_id does not exist from a node_load().

bneil’s picture

bneil commented

The patch in #12 works for me.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Status: Needs review » Reviewed & tested by the community

Marking as RTBC as per #14.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Status: Reviewed & tested by the community » Fixed

Committed #12 to Git. Thanks all!
http://drupalcode.org/project/workbench_access.git/commit/5e6ddfc

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.