Copy/clone page created/modified dates

[adrian]

The current behavior is that the created and modified dates are brought across to the new page, but I wonder if this is expected / desired behavior. For my current use, I'd prefer they weren't but before submitting an issue I'd like to know what others think.

Thanks!

[wbmnfktr]

Never really thought about that detail but in terms of naming...

Clone = I'd expect the same created/modified dates

Copy = I wouldn't be shocked if those dates would be different

 

An option in the module settings to change the behaviour could be nice - at least in your case. I can't really remember a situation in which I used those date. I almost always rely on additional date fields.

 

[adrian]

Thanks for your thoughts @wbmnfktr - it's actually weird to me that the core module is called "Clone" but the page list action button is called "Copy".

I kind of agree with clone having the same dates because a clone should be identical, but I also don't think that in reality anyone actually wants a clone in the end - usually it's just a quick way to start a new page from existing content and modifying it to your needs after that. 

An option for changing the behavior might be a decent approach to the problem.

Anyone else have any thoughts?

I think in reality I'll probably end up hooking into ___clone or ___cloned and adjust "created" via SQL (or the quite save option) because I don't honestly see that Ryan will want to change the current behavior.

 

[szabesz]

34 minutes ago, adrian said:

I think in reality I'll probably end up hooking into ___clone or ___cloned and adjust "created" via SQL (or the quite save option) because I don't honestly see that Ryan will want to change the current behavior.

When done, please share ( you always do that anyway ? ) 

[adrian]

This works:

$this->addHookAfter('Pages::cloned', function(HookEvent $event) {
    $p = $event->arguments(1);
    $p->created = time();
    $p->save(array('quiet' => true));
});

This doesn't handle "modified", but for my needs I don't need that because publishing the newly cloned page will adjust that automatically then. But, if you do, you could add this to the hook:

$sql = "UPDATE `pages` SET `modified` = NOW() WHERE `id` = '".$p->id."';";
$this->wire('db')->query($sql);

 

[Robin S]

On 5/11/2019 at 6:19 AM, adrian said:

For my current use, I'd prefer they weren't but before submitting an issue I'd like to know what others think.

I've never needed to use ProcessPageClone but I would have expected the created/modified time to be set to the time the new page is cloned from the old page. Maybe there are use cases for cloning the created/modified times, so perhaps the issue could be a feature request for the option to determine what happens to created/modified times on the cloned page?

[adrian]

12 minutes ago, Robin S said:

I would have expected the created/modified time to be set to the time the new page is cloned from the old page

Yeah, me too ?

[bernhard]

13 hours ago, Robin S said:

I would have expected the created/modified time to be set to the time the new page is cloned from the old page.

Same here.

[adrian]

https://github.com/processwire/processwire-issues/issues/905

 

[adrian]

This is now fixed in the core.

[gmclelland]

@adrian - Thanks for reporting back to keep us updated!

[wbmnfktr]

6 hours ago, adrian said:

This is now fixed in the core.

fixed... was is broken? ? 

Glad to have a consistent behaviour the majority wants to see.

[adrian]

In case anyone is interested, cloning also doesn't update the createdUser and modifiedUser values. I have submitted an issue: https://github.com/processwire/processwire-issues/issues/927 but in the meantime, I am using:

$this->addHookAfter('Pages::cloned', function(HookEvent $event) {
    $p = $event->arguments(1);
    $p->createdUser = $this->wire('user');
    $p->save(array('quiet' => true));
    $sql = "UPDATE `pages` SET `modified_users_id` = '".$this->wire('user')->id."' WHERE `id` = '".$p->id."';";
    $this->wire('db')->query($sql);
});

Modified can't be changed via the API, hence the SQL. I suppose created could also be done this way, but hopefully this is just a temporary fix assuming Ryan agrees to change the current behavior.

[adrian]

What does everyone think of the cloned page keeping the name of the source page? I am using my PageRenameOptions module so this doesn't affect me, but I expect most site editors who use the copy button won't expect that they have to re-"name" a new page to match the title.

[bernhard]

I think that having different page titles and names is not what a user wants 90% of the time. I think it would be great to have it synched by default (eg a checkbox that enables custom pagenames only if the user really wants to). This could then also work when a page is cloned and the title is changed. The pagename would automatically change.

[adrian]

9 hours ago, bernhard said:

I think that having different page titles and names is not what a user wants 90% of the time. I think it would be great to have it synched by default (eg a checkbox that enables custom pagenames only if the user really wants to). This could then also work when a page is cloned and the title is changed. The pagename would automatically change.

Thanks for your thoughts - I don't see Ryan having a checkbox for this on all page edits - I think there are too many folks who don't think a page's name (URL) should ever change. I guess I am talking about this only in terms of the copy/clone operation because I think it will create a real mess of page names with the current behavior.

But again, my module works around this and it's the first thing I install on all my sites so I am not too invested in seeing this change happen but thought if others weren't aware of the way it currently works and don't like it, they might want to submit a Github issue. Any takers?

[teppo]

2 hours ago, adrian said:

Thanks for your thoughts - I don't see Ryan having a checkbox for this on all page edits - I think there are too many folks who don't think a page's name (URL) should ever change.

I'm in the "URLs should never change" camp myself ?

To clarify: page names should remain constant even if titles are changed, and it's a good thing that they do – for UX, for SEO, and for various other reasons as well. While automatic redirect from old URL makes things better in some ways, it still isn't nearly as good as a constant URL structure. That being said, one problem I've ran into quite often is that name is (by default) "hidden" on the Settings tab, and I've never had much luck in explaining to non-technical clients that the Settings tab indeed contains values that should sometimes be changed (or checked after making changes).

So yeah, cloning is indeed one of those actions that quite often result in nonsensical URLs. But since (unless I'm missing something here) built-in clone feature doesn't allow changing (or setting) the title while cloning the page, there's currently no intuitive way to handle this. If cloning did ask for a new title, it would make a lot of sense to redefine the name based on that new title as well, but changing it after the page has already been created is not such a great idea (in my opinion).

Just for the record the way WordPress displays URL ("permalink") below title but still as a "non-editable by default" field (i.e. there's a separate edit button) is, in my experience, a good compromise: this way it's much harder to miss, but still "less prominent" and clearly not just a regular field among other regular fields.

... but that's probably a sidetrack here.

[szabesz]

1 hour ago, teppo said:

one problem I've ran into quite often is that name is (by default) "hidden" on the Settings tab, and I've never had much luck in explaining to non-technical clients that the Settings tab indeed contains values that should sometimes be changed (or checked after making changes).

Because of this I either move the name filed to the content tab (which is OK for a non multilanguage site, but for more than one language it is wasting a lot of valuable space at the top of the edit page) or display the name right under the Title field's label, which is not editable but at least not so hidden as the Setting tab. There is room for improvement is this area for sure.

1 hour ago, teppo said:

Just for the record the WordPress displays URL ("permalink") below title but still as a "non-editable by default" field (i.e. there's a separate edit button) is, in my experience, a good compromise: this way it's much harder to miss, but still "less prominent" and clearly not just a regular field among other regular fields.

WP's solution is very good, except that it is single language and I've never seen their(?) multilanguage solution.

[teppo]

15 hours ago, szabesz said:

WP's solution is very good, except that it is single language and I've never seen their(?) multilanguage solution.

WP core doesn't have built-in multi-language features like that, and the way popular multi-language plugins (Polylang and WPML) handle this is by duplicating a page or post, which means that technically one post never has more than one URL – so yeah, this is a non-issue in the WP world.

[bernhard]

Ok, I get your points and agree. What do you think of displaying the url directly under the title field and show an edit icon that takes you directly to the settings tab?

I think this would make it more obvious to the editor that changing the title does NOT change the url while it gets a lot easier to change the url even when the field is "hidden" under the settings tab.

[teppo]

3 hours ago, bernhard said:

Ok, I get your points and agree. What do you think of displaying the url directly under the title field and show an edit icon that takes you directly to the settings tab?

Something along these lines would be great!

Nitpicking, but I wouldn't use an icon alone (for accessibility and usability reasons), but other than that it's definitely a feature I'd be using. Idea for a module? ?

[bernhard]

29 minutes ago, teppo said:

Nitpicking, but I wouldn't use an icon alone (for accessibility and usability reasons)

I'm always happy to improve, thx ? 

30 minutes ago, teppo said:

Idea for a module? ?

I was thinking of that... Then I thought it might make sense to put all those little admin "bugfixes" in a module that we can install on any site. But then I thought that's basically the same as AOS, so maybe it would be something for @tpr ? And it seems that @adrian already has such a module that he installs on every site that fixes issues that ryan has not fixed for a longer time?

Maybe it would make sense to open such a module up for the community for collaboration? Or maybe this would be counterproductive as it would seduce us to quick-fixing things and not properly file issue reports and wait for ryan to implement it?

[adrian]

1 hour ago, bernhard said:

And it seems that @adrian already has such a module that he installs on every site that fixes issues that ryan has not fixed for a longer time?

To be clear, PageRenameOptions does a lot more than fix this issue, and those in @teppo's camp who don't want URLs to ever change might think they shouldn't use it, but it comes with this option:

which I think makes the module useful for anyone/everyone and actually I think even with this checked, it would solve this copy/clone issue because the cloned page is unpublished and so as long as the title is changed before it is published, it will still rename the page when changing the title.

[teppo]

29 minutes ago, adrian said:

which I think makes the module useful for anyone/everyone and actually I think even with this checked, it would solve this copy/clone issue because the cloned page is unpublished and so as long as the title is changed before it is published, it will still rename the page when changing the title.

Technically yes, but I'm not entirely sure I like this idea. Perhaps it's just because I'm used to the way the system works now, but if I were editing some content, it wouldn't be obvious to me that if I change the title nothing happens – except if the status of the page is unpublished.

Again, this is obviously just something one needs to be aware of, but personally I don't feel that it's intuitive enough. It's quite possible that I'm in the minority here, but I often tweak the title multiple times while the page is unpublished, yet I've already figured out the name I want to give it. Similarly I can sometimes take a page "offline" for a bigger update, and then restore it. In my opinion a clear indicator about what the name (/URL) is, so that I remember to update it if need be, is a better solution ?

Note: I have had numerous use cases where a template behaves exactly like Adrian has described above, i.e. name is autogenerated from title. But these are usually specific cases, such as a personnel directory or something like that.

2 hours ago, bernhard said:

I was thinking of that... Then I thought it might make sense to put all those little admin "bugfixes" in a module that we can install on any site. But then I thought that's basically the same as AOS, so maybe it would be something for @tpr ?

Sure. It's not wrong to release a specific feature as a tiny stand-alone module, though – there's a case to be made for modules that do just one thing well ?

[bernhard]

43 minutes ago, adrian said:

That's a good idea. Though I'm not sure if non-technical users totally understand what that means or what is going on. 

5 minutes ago, teppo said:

Technically yes, but I'm not entirely sure I like this idea. Perhaps it's just because I'm used to the way the system works now, but if I were editing some content, it wouldn't be obvious to me that if I change the title nothing happens – except if the status of the page is unpublished.

Again, this is obviously just something one needs to be aware of, but personally I don't feel that it's intuitive enough.

I agree. I just had my first statement in an open browser window and did not submit ?