Radical Idea "Save New" or "Save As" for write.

mrdale · 2012-11-03 20:59:46

For the love of [your favorite deity] let’s get a f*!ing “save as” or “save new” button on the write page.

I believe this has been standard practice since computers first saved files to storage devices and I have yet to hear any kind of rational argument against… And I’ve been bitching about it since 2005, which is long enough for the devs to have gotten together and produced a 6 year old human or numerous adult ponies — let alone a button that simply saves a duplicate of an article.

colak · 2012-11-04 05:29:33

I would develop the idea of Mary’s plugin to add a functionality to the button which not only duplicates but also switches the status to draft for the new article. This will allow for title changing (important for some url schemas) as well as further editing.

Bloke · 2012-11-04 11:06:04

mrdale wrote:

a button that simply saves a duplicate of an article

colak wrote:

I would develop the idea of Mary’s plugin to add a functionality to the button which not only duplicates but also switches the status to draft for the new article.

And therein lies the problem. What exactly should the core do?

Just duplicate it.
Duplicate it and prepend “Copy of “ to the title.
Duplicate it and append “ (Copy)” to the title.
Duplicate it and allow you to specify the new title/URL-only title.
If you’re going to the trouble of allowing the new title to be supplied, why not allow the section and categories and custom fields… ad infinitum to be altered at the same time?
Keep status the same or change status.
If changing status, which status?
Clone from the List views too?
Available for everyone or just for certain priv levels?
Save New for Forms and Links too?

And possibly any combination of the above. We can’t please everyone, so which segment of the user base should we appease?

Perhaps when/if modal windows get rolled in it would be the right time to implement this because we could pop up a mini panel to allow the salient details of the current item to be altered and then the Save button would duplicate it and take you to the Edit view for the clone.

Until then, this feature comes with all sorts of implied baggage like how far to extend the ‘new’ concept, myriad options, or (possibly annoying) workflow decisions we could make on behalf of the user; therefore this would probably be best served as a plugin for utmost flexibility. The fact that nobody has stepped up to update Mary’s plugin might indicate it’s not a high priority for the majority (of course, it might be many other factors, like time to do the feature justice, or grudging acceptance of the current paradigm).

So make some suggestions on exactly what this feature should do. If we can come up with a reasonable scope for something that broadly fits with people’s view of what is genuinely useful, then it may well appear in core. Until then, badger someone to make a plugin.

Last edited by Bloke (2012-11-04 11:08:56)

colak · 2012-11-04 14:16:47

Well, I was trying to keep it simple but as you pointed out it could be more complex

I think that the functionality would work wonders if

We open an existing article
edit what needs to be edited in all fields
click the “save new” or “save as” (whatever the button will be called)
a script checks if the title OR the url_only title has changed (If it hasn’t we are prompted to do so)
a new article is created.

mrdale · 2012-11-04 15:42:58

+1 to colak’s suggestion

colak · 2012-11-04 16:05:23

Bloke wrote:

Available for everyone or just for certain priv levels?

Does anyone have an opinion about this?

mrdale · 2012-11-04 16:43:06

Bloke wrote:

Just duplicate it.

Duplicate it and prepend “Copy of “ to the title.

Duplicate it and append “ (Copy)” to the title.

Duplicate it and allow you to specify the new title/URL-only title.

If you’re going to the trouble of allowing the new title to be supplied, why not allow the section and categories and custom fields… ad infinitum to be altered at the same time?

Keep status the same or change status.

If changing status, which status?

Clone from the List views too?

Available for everyone or just for certain priv levels?

Save New for Forms and Links too?

Opinions are like (well you know)… here are mine.

No
Perhaps,
- No In the case of “Write Screen” sometimes you’ll want the same title all other times you’ll manually edit it.
- Yes In the case of the “Article Screen” working on multiple articles.
Perhaps, ditto, actually prefer this option in the case of multiple articles on the “Article Screen”
Yes, kinda. Why not just check for a change in title and use that for the url-title, otherwise append (n)
Definitely! I assumed you would allow changes to all article content
Keep the status
Don’t
Sure, choice for multiples would be great.
No opinion (shockingly).
Bonus!

Last edited by mrdale (2012-11-04 17:03:20)

Bloke · 2012-11-04 23:34:23

Hmph it totally didn’t cross my mind about changing all the elements prior to Save New. I’m losing the plot, sorry.

If you alter various things but don’t alter the Title, the worst case scenario is that the UI will alert you to the fact you have two articles with the same URL and it’s up to you to alter it if that’s undesirable / an oversight. A few thoughts:

Doing things this way round nullifies the need to offer options for altering the status, category, section, title, yahde yahde because you can alter those before clicking the button.
If you don’t alter the title, only your site cares. We’d probably assume that the user knows what they’re doing rather than take the upm_ approach of blanking out the url-only title to force it to change. After all, you may have a legitimate reason for wanting the same Title (the cloned article might be in a different Section) so to force a prefix or suffix seems intrusive. But, as you say, taking that stance from the bulk edit is counter-intuitive and some kind of indicator for the clones would be pretty much essential. That’s a tough line to tread because the behaviour would be different depending on where the article was cloned: that’s a usability frogman. Perhaps bulk-clone is not such a hot idea after all.
Save New could take on the same privs as regular saving?
Trying to keep a similar workflow with other content becomes interesting because, for example, Forms have a uniqueness constraint. So they would require a prefix/suffix, but maybe only if you hit the button without altering the name; is that confusing UX?

The Write panel’s AJAX saves may get in the way because it is assumed that the Save feature is asynchronous, and — if memory serves corectly — that’s a feature of the form itself not the button. A Save As would be cleaner if it resubmitted the form without AJAX to “start again” with a new article ID. Not sure how best to implement that. But a plugin would hit the same issue.

mrdale · 2012-11-05 01:14:30

Thoughts.

“Save as” from the “Articles” page could simply append different URL titles based on existing-title + unique numerical suffix and keep identical names. The article’s unique ID is already listed. (As a further measure, the title attribute on the title a-tag could be set to the url-title to avoid confusion.)
The only thing I think is a duplication pitfall for articles is the url-title which I think should be auto-created based on
1. New url-title based on title (if different).
2. New url-title based on title plus unique numerical suffix (would require some ajax checkin’ I suppose)
I’d assume the same privs
I think it’s ok to enforce new names on Pages, Forms and CSS because those are fundamentally different, ie they’re presentation items.

Gocom · 2012-11-05 05:02:47

Bloke wrote:

The Write panel’s AJAX saves may get in the way because it is assumed that the Save feature is asynchronous, and — if memory serves corectly — that’s a feature of the form itself not the button. A Save As would be cleaner if it resubmitted the form without AJAX to “start again” with a new article ID. Not sure how best to implement that. But a plugin would hit the same issue.

That’s true. The async functionality when attached, is permanent and can not be removed without destroying all the other event handlers for instance by cloning the element — or that is what it used to. I did some work on the async functionality and as of r4572 and r4573 the async handlers can be removed and communicated without having to worry about other events.

The attached $.fn.txpAsyncForm is fully instanced and can safely be removed. Once removed, it leaves no traces of it’s existence. No changes to global configuration and other events are left intact.

The event can be talked with, removed and registered using normal jQuery’s event methods. $.fn.txpAsyncForm has an unique namespaced ‘submit’ event, ‘submit.txpAsyncForm’. For instance the following would send an asynchronous editor form synchronously, leading to a normal page refresh:

$('form').off('submit.txpAsyncForm').submit();

Last edited by Gocom (2012-11-05 05:09:31)

Bloke · 2012-11-05 09:10:22

Gocom wrote:

I did some work on the async functionality

Awesome! One more obstacle out of the way.

Textpattern CMS

Textpattern CMS support forum

#1 2012-11-03 20:59:46

Radical Idea "Save New" or "Save As" for write.

#2 2012-11-04 05:29:33

Re: Radical Idea "Save New" or "Save As" for write.

#3 2012-11-04 11:06:04

Re: Radical Idea "Save New" or "Save As" for write.

#4 2012-11-04 14:16:47

Re: Radical Idea "Save New" or "Save As" for write.

#5 2012-11-04 15:42:58

Re: Radical Idea "Save New" or "Save As" for write.

#6 2012-11-04 16:05:23

Re: Radical Idea "Save New" or "Save As" for write.

#7 2012-11-04 16:43:06

Re: Radical Idea "Save New" or "Save As" for write.

#8 2012-11-04 23:34:23

Re: Radical Idea "Save New" or "Save As" for write.

#9 2012-11-05 01:14:30

Re: Radical Idea "Save New" or "Save As" for write.

#10 2012-11-05 05:02:47

Re: Radical Idea "Save New" or "Save As" for write.

#11 2012-11-05 09:10:22

Re: Radical Idea "Save New" or "Save As" for write.

Board footer