Hello,
I have noticed that Flexinode does not allow me to compare revisions when using the Diff.module. I have also noticed that when I view revisions, the revision list shows the correct number of revisions, but viewing any revision just gives the current vresion of the document. I believe this is why Diff.module is not working as it is essentially comparing two same documents together.

I have examined the node_revisions table in MySQL and any revised flexinode documents definitely create a new revision and each revision is different.

Is this a problem with flexinode interaction to the revision system? Or is this a bug in the revision system?
Thanks.

Comments

carlivar’s picture

I can confirm this. I haven't investigated in detail, but I see that the data in various revisions in node_revisions is correct (i.e. different). Viewing the revisions via the UI does not seem to work however.

I see that the flexinode_data table does not seem to be revision-aware. Perhaps this has something to do with it?

carlivar’s picture

I found a fix for this, though it's rather crude.

In the flexinode.module file, find the flexinode_view function and comment it out. On my 4.7.0 file you would comment out lines 638-641. Voila, revisions will now work properly!

Why does this work? Because the HTML body for the "node view" of a flexinode is all contained in the node_revisions table. So we're forcing Drupal to display the flexinode from the node table rather than flexinode generating the node view itself from its data that is not revision aware.

This seems strange. Why have the flexinode_view function at all if the core node view works fine? Maybe it is so flexinode data can be edited outside of flexinode and it will still show up in the node view. But I don't really like this very much because the flexinode view exists twice... it is both generated in the flexinode_view function as well as stored statically in the node_revisions table. Seems like flexinode needs to pick one or the other.

The proper fix would be to add a vid field to flexinode_data, I would imagine (make it revision aware).

Kieg Khan’s picture

You little champ, this is what I love about this community, someone always comes up with a solution.
I agree that this is probably not the best solution, so it would be nice to find out why the flexinode author has not just utilised the revision system for content display and reserved the flexinode data for flexinode editing.

I have made the change, but I will still configure a few flexinode types and make sure it works in all situations.
Thanks.

kylebrotherton’s picture

Version: » 4.7.x-1.x-dev

I have the same problem, where revisions don't work with flexinode. And commenting out that particular section seems to work, but...

My problem is that this 'solution' changes a few things in the layout, so the flexinode nodes look 'messed up'.

I'm hoping for a better fix to this bug.

pathscollide’s picture

Sorry to do a "me too" on this, but I was seriously disappointed when I discovered this bug while building my site (and subsequently had it confirmed by this open issue). I guess if you only need revisions to work for one custom content type, you can use this workaround http://drupal.org/node/35686 (doesn't involve flexinode). However, that would become very tedious if you want several custom content types (and would defeat the purpose of flexinode...!).

I would be great if someone could come up with a clean fix for this. It seems like it shouldn't be *too* difficult, right?? (he says, speaking out of total ignorance....).

Kieg Khan’s picture

Hello,

I have since created specific node types using the http://drupal.org/node/35686 solution. I am not sure what the long term viability of this solution is as I would expect the base Drupal could change and make the custom type break.

I have also downloaded the most recent flexinode module and am very disappointed that the revisions error is still there. While flexinode is a great idea and allows my editors to manage node types within Drupal, every document we create is versioned and relies heavily on the revisions system, so this is definitely true for flexinode content.

I hope the author / maintainer can take notice of this issue and please work on a solution.

Bye.