Symphony.

A new Extension, “Populate Entry” is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

This extension enables authors to choose an existing entry to populate a new entry with.

Populate Entry

Version: 1.0.2
Author: Carsten de Vries <carsten@vrieswerk.nl>
Build Date: 21 September 2009
Github Repository: http://github.com/carsten/populate_entry/tree/master
Requirements: Symphony 2

Choose an existing entry and with its existing values create a new entry. Use the link that is added to the end of each table row in the entry overview. To populate an existing entry with data from another entry, open the entry you wish to populate and put ?from-entry=ENTRY_ID behind the pages URL.

To do: add support for more field types (from extensions). Improve the way existing entries can be populated.

Installation

1. Upload the “populate_entry” folder in this archive to your Symphony ‘extensions’ folder.

2. Enable it by selecting “Populate Entry”, choose Enable from the with-selected menu, then click Apply.

3. Entry overview pages now have links to create a new entry from existing entries.

Change Log

1.0.2 - 21 September 2009 Changed link text to Copy and fixed right arrow character issues.

1.0.0 - 23 July 2009 Initial Release

Download

• Git repository
• Direct download

Very cool! Installing soon :-)

Nice! This sounds like something that could be a few steps away from a versioning system.

Nice work :)

I have attempted to start a versioning system, but it seems quite complicated. It would require a second “versioning” MySQL table for each field of each section. Each entry update or entry creation needs insertions in several MySQL tables. Modifying the core to do this is one thing, but creating an extension that allows you to do this is much more complicated.

So, this extension grabs all field data from each entry, converts it to JSON, ans uses a jQuery plugin to populate fields where possible. E.g. it is not possible to copy uploads.

Well, I guess a few giant leaps for mankind away. I really didn’t know what it might take. Thanks for the info.

Here’s another thought: is it possible that the jQuery plugin could populate fields for front end forms?

If you give your front-end form fields identical names, and if you include these javascript files it should work: {$root}/symphony/extension/populate_entry/data/?section=SECTIONHANDLE&entry=ENTRYID and {$root}/symphony/extension/populate_entry/assets/jquery.populate.js

However, this gives rise to a safety issue: all content can be retrieved with this first javascript file. Perhaps, on the admin side some sections should be specified which are allowed to be pulled.

That is a concern.

On another note, it would be interesting if this could address the problem of being able to pull Markdown into front end entry forms.

I think the Markdown problem can be solved more elegantly in the core. Fields can provide more than one item in the “Included Elements” list when creating a Data Source (Rowan’s BiLink is an example, it provides three ways to render the field’s output). I’m thinking that the Textarea field could be modified such that when a Text Formatter is in use, it provides the original field but also a “{field} (unformatted)” list as an option to use in a Data Source.

Since this is provided in the core, it’d be considered a core modification. But it doesn’t need a modification to Symphony’s core — just a change to the Textarea field itself. I might give it a stab.

But back on-thread — this is amazing! Very useful indeed.

Just had a thought of another way to achieve this. When using Symphony events, if you specify an id in the POST array then Symphony will update that entry. If the id is not present, it will create a new entry. Does the backend work in the same way? If so, an even simpler implementation would be to append ?duplicate=true when viewing an entry, and use JS to remove the id field from the form. When saving, this would create a new entry. I haven’t tried it, but it might solve the problems you’ve found with your current implementation.

This week two requirements have arisen at work with similar discussions:

• How difficult would it be to create a “Duplicate Entry” button which created a true duplicate? After some thought, perhaps not too difficult. At the database level it’s just a case of replicating rows. The only problem I forsee are File Upload and Unique Input Fields which don’t accept two fields of the same value (either the file exists, or text is the same)
• How difficult would it be to create a “Version History” of an entry, such as that every save of the entry stores its content and can be rolled-back to a previous version. There has been talk of a versioned text field for use in a Wiki, but this could be expanded for entries.

Food for thought.

I just tried this out. The entry ID isn’t sent in the POST so this idea doesn’t work. However by changing the @action of the form to ...../new/ rather than ......./edit/{id}/ you can submit the form and it will create a new entry!

It maintains Select Box Link values from this entry (i.e. when there is a select box in the form) but it won’t maintain relationships to the entry. To solve that you would need some PHP to duplicate the relationships themselves.

All we need now is to be able to pass prepopulate[{id}] to the /edit/ forms (as we can with /new/ forms) and you could achieve “Duplicate as Draft” functionality, passing a “Published=No” checkbox value on the querystring.

This extension is awesome!

One thing I was wondering, as I am trying this out while using nickdunn’s Order Entries extension: would it be possible to configure the extension to ignore specific types of fields. The Order Entries extension automatically populates a new entry with the next number for the sort value. The Populate Entry extension overwrites this value. Not a huge deal if a client starts adding several entries with the same sort value. As soon as the entries are sorted, the Order Entries extension will sort things out. It would be a nice little extra, to add some polish to the usability of the interface, though.

Carsten, did you get a chance to look at my suggestions? Changing the fundamental way this extension works could solve the problems you discovered.

Nick, I’m quite busy with finishing some business before taking a holiday so I haven’t had any time to look into it. It should not be so hard to modify the form action with jQuery. While it might fix some safety issues, the problems with saving file uploads and not maintaining relationships to entries will remain. Perhaps it is easier to check whether the data is retrieved by someone who is logged in.

A better solution would be to create an extension that will enable true duplicates and versioning. A database model would greatly help with the development of such a development.

Bauhause: go to /content/content.data.php and in the PHP switch statement make sure that you have case 'order_entries': break; to ignore this field type.

I haven’t added a configuration page for this extension, but some more flexibility could be nice. I thought about specifying for which sections this extension should be enabled, for instance. Also, manually adding behavior for certain field types could be added.

Thanks, carsten. Works great.

Great work Carsten! I can’t wait to use this!

This is awesome extension.. it makes me look like the shit to my client.. being able to turn around a solution in a day for them is awesome!

Thanks for this Carsten..

On a note.. is there scope to change how it looks in the list of entries?

at present I see &rarr new as the link to duplicate entry!

The arrow used for the button in populate_entry does not seem to render correctly in opera!

&rar new instead of the arrow and new in firefox..

Is there a way of altering what is presented in the entry page?

I assume that this is a really simple bug. If you look at line 10 of assets/populate_entry.js, you will find &rarr new which should be → new. You might try this in your version and send a bug report.

Found it and changed it! to “→ Copy”

Shall I place a bug report or is it ok to reference your post as a report of bug?

moonoo