Taxonomy diff

The D6 version of diff does this. If you aren't seeing this, it is a bug.

there is no list of changes beyond reading the CVS commits whcih you can do at cvs.drupal.org.

core does not track taxonomy changes in 5 so there is no data for diff to work with. in general, cck fields are properly segregated and shown when differences occur. this is now in the cck download for D6. it is in the diff download for d5.

we do not currently show changues in sticky/poublished but could do that. if workflow-ng wants to implement hook_diff(), it can. make a request in that queue.

Taxonomy term comparison is not happening in D7. It is in D6.

I've written a patch that supports taxonomy term reference and node reference field diffs. The thing is that it doesn't really make sense without #1224996: node_diff() only diffs modified existing values, ignores newly added or removed ones (otherwise, it'll only show a diff if you remove one term and add another from that vocab at the same time). So I'm attaching two versions of the patch - one being against the 7.x-2.x branch, and one against a local branch with the patch from the afore-mentioned issue applied. I'm sure there's a better way to handle dependent patches, I'm just not sure what it is :-/

Also, the solution isn't ideal, in that it explicitly supports the above-mentioned field types. It should be more generic. I'm wondering if drunken monkey's plans for this module include a dependency on Entity API?

Forgot to change the status...

So... the patch in #1224996: node_diff() only diffs modified existing values, ignores newly added or removed ones got in (w00t), but I needed to write a follow-up patch because it wasn't working with the Preview changes functionality. So now I've rolled a version of the taxonomy/noderef support patch that will apply to the latest 2.x code patched with that follow-up patch...

Subscribing...

Yes, this would be wonderful!

I've give this some tries over the weekend.

Hi !

I needed this for one of my clients so I did it.
It may be perfectable but it works well.
It has been initially designed to work with tags so when you just change the value of a classical taxonomy field, you will see it like a term was removed and another added.

The patch apply well on the last dev version (7.x-2.0+10-dev)

Enjoy

Hi,

There is a little upgrade for my previous patch.
Two files :
- add-taxonomy-support-248778-13.patch if you patch directly from the dev branch
- add-taxonomy-support-248778-13-incremental.patch if you patch from my previous post

Enjoy

There another little patch fixing an issue showing warnings when the taxonomy field have a cardinality of 1 and is empty.
Files applies as seen in #14.

Time to push this to -dev?
Somewhat related: #1365750: Generalize API and Integrate with core field types

I don't know if the official maintainers are still keeping an eye on this project.

I personally would prefer diff to parse and decide what available fields are present to prevent every module that implements hook_diff() from having to do this themselves. Using the code from the other thread, this would reduce the amount of code required here to only 8 or 10 loc

@Alan : you are right but my purpose here was to propose a quick fix to this old issue.

@Encarte : it is a functional regression but regarding to the huge changes made to the core between D6 and D7 we cannot blame anybody.

I would like to have more time to help but I am already responsible of another module which may feel abandoned ;)

I would love to be paid for helping Drupal grow, but I am not, so I try to help as I can. Thank you for the link, I missed it and it looks really interesting.

I didn't roll a patch in the other thread, but from basic testing, the functionality was sound. If that, or similar approach, gets in, this issue could be reduced to:

/**
* Implements hook_field_diff_view().
*/
function taxonomy_field_diff_view($entity_type, $entity, $field, $instance, $langcode, $items) {
  $diff_items = array();
  foreach ($items as $delta => $item) {
    if (!empty($item['tid']) && $term = taxonomy_term_load($item['tid'])) {
      $diff_items[$delta] = $term->name . ' [tid:' . $term->tid . ']';
    }
  }
  return $diff_items;
}

That is, if visually scanning the delta values is enough, cf. with a full report. :)

OK, trying to push forward with full coverage of all core fields. I've refactored the other approach slightly, but this will add minimal functionality by itself.

Many fields will get free diff support as I am checking both the safe_value and value fields rather than just the value column.

I would love it if someone can review the patch here.

http://drupal.org/node/1365750#comment-6108002

I've spent the last 30min setting up core fields: list, number, text, image, file, taxonomy terms but it will be tomorrow before I get a chance of working on the implementation of these.

Not sure how hook_diff() works, but the code in #23 appears to introduce XSS vulnerabilities via $term->name. However, if diff.module itself is sanitizing everything returned by hook_diff() before display, we're fine. Someone should double-check before this gets RTBC or committed.

Massive patch over in #1365750: Generalize API and Integrate with core field types needs some testers. If accepted, this will make this issue a duplicate.

@dww
These were getting escaped, but I didn't check. Without directly tracing to these functions, I guess this is where that is done:

class DrupalDiffFormatter extends DiffFormatter {
  function _added($lines) {
    foreach ($lines as $line) {
      $this->rows[] = array_merge($this->emptyLine(), $this->addedLine(check_plain($line)));
    }
  }

  function _deleted($lines) {
    foreach ($lines as $line) {
      $this->rows[] = array_merge($this->deletedLine(check_plain($line)), $this->emptyLine());
    }
  }

  function _context($lines) {
    foreach ($lines as $line) {
      $this->rows[] = array_merge($this->contextLine(check_plain($line)), $this->contextLine(check_plain($line)));
    }
  }
}

That callback in #23 sets the #old and #new parameters. And cf. current implementation, this would be an issue that would have come up really quickly!

          $view_new = $new_node->{$field_name}[$langcode][$delta]['value'];
          $result["{$field_name}_{$delta}"] = array(
            '#name' => $instance['label'],
            '#old' => explode("\n", $view_old),
            '#new' => explode("\n", $view_new),
          );

In another task, I'm refactoring the field comparison.

These are two raw outputs based on selecting to display the term id or not. Currently the output is controlled by a system variable that defines the defaults.

The change in the ID to the more verbose form was to ensure that all displays were similar for the core fields. See #1458814: File (and image) field support for screenshots for file and image comparisons to see this.

The default is to hide the term id as this is what happens in Drupal 6.x

This should be resolved with the new branch, 7.x-3.0-alpha1 or 7.x-3.0-dev.

This is still alpha, so test carefully before use on a production site and report any issues back to the queues.

If there is going to be a 7.x-2.1 release, should not this fix be adapted to that branch as well as to 3.x?

Agreed, this should probably be fixed in 7.x-2.x as well.

Thanks,
-Derek

I was probably being very overly cautious just making the first release of the 3.x branch an alpha. There are a few dozen users of 3.x already and no reported issues. Fixes Option list, core Term fields, File & Image fields.

In contrib already:
Commit 2025356 on Countries 7.x-2.x has added support.
Commit 7b3e640 on Name Field 7.x-1.x

Patches for Diff Field support in the queues include:
#1685698: Provide field support for diff (email field)
#1350604: Diff support for Date fields
#1595702: Diff support of field collection fields
#1686024: Diff (7.x-3.x) support for Link fields

And there were about 10 or 15 other features / bugs resolved in the process.

So afaict, you are losing out by sticking with 2.x even if the core fields are fixed. So please test if 3.x if fully functional on your site and report back with any issues. Backporting will only slow the release of 3.0

If these go into the 2.x branch, all core fields should be considered together as the repetitive instance looping is causing performance issues. Maybe just terms and option lists fields.

Moving forward with 3.x, within the next couple of weeks, the field display level diff settings will be removed (only currently visible via additional module) and the content type settings moved to a singular location, and that will be released a either rc1 or beta1. No additional functionality is planned, other than unifying these settings. Note that with the release of alpha version, marks the end of rapid prototyping of the 3.x branch and additional functionality will go though the issue queues in a more sedate manor, preferably introducing automated testing for existing and new functionality.

This is fixed in 7.x-3.x. Backport requests should be made in separate issues, if absolutely necessary.