Symphony.

@nickdunn Nice changes. Will be possible to reset history or anything similar?

Nope, it’s a readonly audit trail.

nickdunn, thats cool, thanks for the update!

incidently on release of new symphony release, how easy would an upgrade be with current extensions installed?

moonoo2

Is your question regarding this extension in particular or Symphony in general?

symphony in general

Usually straight forward.

Best to keep discussions on-topic — start a new discussion thread if you have unrelated questions please :-)

Some UI updates. I’ve used Nils’ Mediathek tabs idea as this is a really neat and tidy UI concept

Agreed, organizes the revisions nicely. Really loving this!

nickdunn, appologies just so much to learn! :)

no worries off topping issue.

moonoo2

Retrofitting this sort of functionality into the core is almost like making a triangle into a square — adding a completely new dimension to the mix. I’m not sure it would be possible to integrate into Symphony 2. But I would like to think the boys consider this for Symphony 3 or above.

Some UI updates. I’ve used Nils’ Mediathek tabs idea as this is a really neat and tidy UI concept …

Nice! Did you really manage to align the tabs to the right in a cross-browser way? I had some strange problems with misaligned tabs while creating this sort of thing for my Mediathek field. That’s why the tabs are pushed a few pixels to the left in my implementation.

Did you really manage to align the tabs to the right in a cross-browser way?

All is good in Firefox 3.5 and Safari 4 but I haven’t checked in others yet.

@nickdunn: This looks really promising. You’re spot on with this solution! I’ve struggled with some third party modules for Drupal and your solution outshines all of those modules by far.

Yet another thing to the wishlist. How about a log message form field? It can be used to write a short description of the changes made to a revision and it should be displayed in the revision history. This would really make the publishers work easier.

Nick, are there any news on this extension? It would be quite handy for a project at work in January …

I haven’t got any plans to re-ignite this project until 2.1 is released. I’m conscious of having to re-do work when the 2.1 changes are released, so I’m holding tight.

I have another cool extension waiting for 2.1 too ;-)

Thanks Nick, I’ll have to find another solution (damn!).

I have another cool extension waiting for 2.1 too ;-)

Me too :P

I thinking about trying this extension on my person site. The readme says:

Entry Revisions prefers simple sections of text field

This is just fine for me but I have a question: Does the extension just ignore “problematic” fields like an upload of Mediathek field?

I just tried the current alpha version and I get a fatal error when trying to create a new entry:

Table 'sym_entry_revisions' doesn't exist
An error occurred while attempting to execute the following query
SELECT published FROM sym_entry_revisions WHERE `entry_id`=0 AND published='yes'

Backtrace:
[/www/htdocs/webseiten/hananils/symphony/lib/toolkit/class.mysql.php:275] MySQL->__error();
[/www/htdocs/webseiten/hananils/symphony/lib/toolkit/class.mysql.php:313] MySQL->query();
[/www/htdocs/webseiten/hananils/symphony/lib/toolkit/class.mysql.php:348] MySQL->fetch();
[/www/htdocs/webseiten/hananils/extensions/entry_revisions/lib/class.revisionmanager.php:158] MySQL->fetchCol();
[/www/htdocs/webseiten/hananils/extensions/entry_revisions/lib/class.revisionmanager.php:147] RevisionManager->isEntryPublished();
[/www/htdocs/webseiten/hananils/extensions/entry_revisions/fields/field.revisions.php:35] RevisionManager->getDefaultRevision();
[/www/htdocs/webseiten/hananils/symphony/content/content.publish.php:404] fieldRevisions->displayPublishPanel();
[/www/htdocs/webseiten/hananils/symphony/content/content.publish.php:487] contentPublish->__wrapFieldWithDiv();
[/www/htdocs/webseiten/hananils/symphony/content/content.publish.php:29] contentPublish->__viewNew();
[/www/htdocs/webseiten/hananils/symphony/content/content.publish.php:34] contentPublish->__switchboard();
[/www/htdocs/webseiten/hananils/symphony/lib/toolkit/class.administrationpage.php:81] contentPublish->view();
[/www/htdocs/webseiten/hananils/symphony/lib/core/class.administration.php:88] AdministrationPage->build();
[/www/htdocs/webseiten/hananils/symphony/lib/core/class.administration.php:204] Administration->__buildPage();
[/www/htdocs/webseiten/hananils/index.php:20] Administration->display();

There is a table called sym_fields_revisions, though.

This is just fine for me but I have a question: Does the extension just ignore “problematic” fields like an upload of Mediathek field?

Nope, it doesn’t ignore them. It just prefers simple fields ;-)

This is a simple way of saying that it will store the “state” of the entry, but if related entries change then these are not saved.

An example: If I have the Entry Revisions field in my Articles section and this section has a Select Box Link to a Categories section showing the entries from that section in the dropdown. I select category and save my article. A few revisions down the line I end up deleting the category entry from the Categories section. If I roll back my Article, the old category won’t be in the list for selection.

So Entry Revisions saves a snapshot, but not of related entries. The same would apply for Mediathek. It would save the selections of the assets in the Mediathek field, but not the values of the entry in the related section itself.

What Entry Revisions actually does it serialise the data of a full Symphony Entry object to a string and stores it in the database. To rebuild the entry I get the string, unserialise the array and rebuild the Entry object from it.

I just tried the current alpha version and I get a fatal error when trying to create a new entry:

Ah yes. I never added that CREATE TABLE to the install! You’ll need both of these:

CREATE TABLE `sym_entry_revisions` (
  `id` int(11) NOT NULL auto_increment,
  `entry_id` int(11) NOT NULL,
  `revision` int(11) NOT NULL,
  `entry_data` longtext NOT NULL,
  `published` enum('yes','no') default 'no',
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

CREATE TABLE `sym_entry_revisions_history` (
  `id` int(11) NOT NULL auto_increment,
  `entry_id` int(11) NOT NULL,
  `revision` int(11) NOT NULL,
  `date` datetime NOT NULL,
  `author_id` int(11) default '0',
  `action` varchar(255) NOT NULL default '',
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

Nick, have you ever tried this extension in a section containing a Mediathek fields. For some reasons I get a Mediathek error after saving an entry where $data['relation_id'] returns NULL when it should effectively return an id.

Not sure if this is a bug in the Mediathek or in your extension. It doesn’t make sense to me at all … any ideas?

P. S.: It seems like the $data variable passed to displayPublishPanel() in field.mediathek.php equals 100 which it shouldn’t and which it doesn’t without the entry revision field. The section without the entry revision field works fine, it contains the following field types:

• text input
• textarea
• select box
• date and time
• tag list
• mediathek

The last three may be problematic in the entry revision context as they contain varying numbers of sub-items.