Closed (won't fix)
Project:
Revisioning
Version:
6.x-3.15
Component:
Code
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
30 May 2012 at 11:54 UTC
Updated:
5 Apr 2013 at 03:56 UTC
This commit broke my workflow that was calling the "Publish the most recent pending revision" action and was tacitly updating the alias.
To fix this, I call the "Save post" action before "Publish the most recent pending revision", but I wonder what was the reason of the change reflected in the above commit. AFAIU, there's already a configuration option in pathauto to prevent updating aliases.
Comments
Comment #1
jelo commentedI just spent a few hours tracking down this issue. I use revisioning with workflow (states: draft, pending, approved, review, expired).
During an upgrade of core (6.22 -> 6.26), revisioning (6.x-3.13 -> 6.x-3.15), pathauto (6.x-1.5 -> 6.x-1.6) and token (6.x-1.x-dev (2011-Nov-07) -> 6.x-1.18+3-dev (2012-May-09)) path alias creation suddenly stopped working.
Triggers between workflow stages were defined as follows:
- from creation to draft: none
- from creation to approved: publish the most recent pending revision
After the update, the result was that a content editor who can only publish by going through the draft state could still create a node which would get a proper alias (from creation to draft to approved).
However, a content supervisor who could directly go to the approved state would publish pages, but no alias would get created at all.
Given this result, I wonder about the reason for the change like mikhailian does...
My interim solution was to change the trigger from "publish the most recent pending revision" to "publish post" which automatically adds "save post". However, this only works for this particular case because I know that there cannot be another revision in this particular state change.
Btw: as a result of the update / this change, I am now seeing errors in the watchdog about duplicate entries in xmlsitemap: "Duplicate entry '7458' for key 1 query: INSERT INTO xmlsitemap_node (nid, changed, previously_changed, comment_ratio, priority_override) VALUES (7458, 1338398894, 1338398893, 0, -2) in [...]includes/common.inc on line 3579."
mikhailian: do you have a similar issue? I will have to investigate this more and will then start a separate issue...
J.
Comment #2
mikhailian commented@jelo I do not use xmlsitemap, so can not say.
Comment #3
jelo commentedWeird. Since the update something seems to fire multiple times. The sitemap issue disappeared when I upgraded to RC1.
However, I am now having issues with Taxonomy and duplicate entries. I use nodewords and page titles to automatically create page titles and metatag description. When I create a node, this is what shows in the watchdog:
content May 30 2012 - 4:31pm award: added Award Duplicate. admin view
nodewords May 30 2012 - 4:31pm User admin changed the meta tags for type ... admin
content May 30 2012 - 4:31pm Published rev #8496 of award Award ... admin view
nodewords May 30 2012 - 4:31pm User admin changed the meta tags for type ... admin
nodewords May 30 2012 - 4:31pm User admin changed the meta tags for type ... admin
php May 30 2012 - 4:31pm Duplicate entry '203-8496' for ... admin
php May 30 2012 - 4:31pm Duplicate entry '202-8496' for ... admin
php May 30 2012 - 4:31pm Duplicate entry '201-8496' for ... admin
revisioning May 30 2012 - 4:31pm Executing publish_latest_revision action for Award ... admin view
workflow May 30 2012 - 4:31pm State of Award Award Duplicate set to ... admin view
The node has 3 terms and hence throws 3 duplicate entry errors. However, as you can see nodewords appears 3x times in the list as well (whereas it did only once prior to the update). This happens even though the action for this state change is set to "Publish the most recent pending revision" (and not an additional "save post").
Comment #4
jelo commentedHere is an update about this issue:
Workflow exposes a block on the node edit form that allows users to change workflow states directly while editing a node. This is the way we used it mainly because it saved an additional step to go to the separate workflow tab.
The custom module that fired on a presave operation was now executed three times when a state change was made on the node edit form (vs. on the workflow tab):
1) user was on node edit form and actually submits that form to "save" => 1x
2) to get the pathalias working we had added a "save post" trigger for the workflow state change => 2x
3) the second trigger "publish the most recent pending revision" for some reason must do a save post as well => 3x
Without knowing much of Drupal's internal handling of all of this, it appears that these three triggers do not happen in sequence with separate error handling, but get all executed directly without further validation. Hence, my custom module that added taxonomy terms tried to write each term into the database three times and taxonomy did not check if the terms already existed in the database.
Solution and conclusion:
- adding "Save post" is not a workable solution as it seems to duplicate what "publish the most recent pending revision" does
- to get pathauto working, require that a post gets saved without allowing a state change upon creation => this way all my problems were solved and the aliases updated fine for any subsequent state changes without the need to add several save post actions for all state changes
- I disabled the workflow changes through the node edit form and force all users to use the separate workflow tab to make state changes to avoid any duplications
- this did not only affect my custom module, but at least 2 other modules (xml sitemap and nodewords). It might affect more modules
Comment #5
rdeboerD6 is approaching end of life. Doing maintenance fixes and provided patches only.