Page Rename Options

[adrian]

5 minutes ago, Macrura said:

Slight bug report - if you have a template where the title is locked, it will cause the name field to clear and then you will get an error when trying to save the page about missing required value of name...

Looking at this now and it seems like it's only an issue if you have the "Rename Without Title Change" option checked. Can you please confirm that you are using that option?

[adrian]

@Macrura - I implemented a fix based on my assumption mentioned above. I have disabled the "Rename Without Title Change" option when the title field is locked. I think this is a reasonable approach. I guess the only scenario where this isn't perfect is if a title is changed via the API such that the name is different.

Could you please try the new version and let me know if it works as expected for your needs?

 

[Macrura]

3 hours ago, adrian said:

Looking at this now and it seems like it's only an issue if you have the "Rename Without Title Change" option checked. Can you please confirm that you are using that option?

I did have that selected, as i installed it after some content was already in the system..

 

1 hour ago, adrian said:

Could you please try the new version and let me know if it works as expected for your needs?

ok sure, thanks! - that was fast!

[adrian]

Just now, Macrura said:

I did have that selected, as i installed it after some content was already in the system..

I guess that is another situation where my implemented fix may not be great. I did look at an alternative which is to grab the title from the locked div (rather than the title <input>). The only catch with this approach is that you can't be certain there isn't other html in there - for example, AOS adds a link to edit the field and with locked fields, this is also in that div, so you need to exclude that when extracting the title via js. I suppose I could pass the title to the js file in a different manner so that the updating will still work - do you think I should look into that?

 

[adrian]

@Macrura - I decided to take a different approach with this. Now all the issues I noted above are no longer relevant. Please grab 1.0.4 and let me know how it goes. 

[Robin S]

Hi Adrian,

@Sten is working on a module that uses EasySlugger to set better page names from titles that use non-latin alphabets. I was thinking that it would be cool if that module (and potentially others) could build on the features that Page Rename Options provides to select what pages are automatically renamed. What do you think about separating off the line that determines the new page name into a hookable method? Then other modules could hook into that to set a custom page name.

[adrian]

10 minutes ago, Robin S said:

What do you think about separating off the line that determines the new page name into a hookable method?

I'd be happy to, but I think the problem will be that this module mostly works with JS in realtime as the title is changed. The renameOnSave method that includes that line you referenced is only called by API changes to a page's title.

So I guess I would also need to make sure renameOnSave is also called when the new EasySlugger module is installed and activated. Or are you thinking of some other approach to this that I am missing? 

[Robin S]

13 minutes ago, adrian said:

I'd be happy to, but I think the problem will be that this module mostly works with JS in realtime as the title is changed.

Oh right, I never looked into how the module does its work. My idea isn't practical then.

Just curious: does setting the page name via JS have an advantage over hooking saveReady and setting it via the API? Do you do it that way to distinguish between title changes made in Page Edit versus the API (in case a user wants to exclude title changes made via the API)?

[adrian]

Just now, Robin S said:

Do you do it that way to distinguish between title changes made in Page Edit versus the API (in case a user wants to exclude title changes made via the API)?

I went with the JS approach only to start with because I wanted the user to be able to see what the name is in realtime when they change the title of an already existing page - the same as we can when creating a new page. There are also other options like locking the name from being changed etc which I wanted to include in the module which also work best via JS.

I only added the saveReady hook later when I realized that I also need to support title changes via the API (and also when the settings tab is hidden and the name isn't added to the content tab).

As far as supporting EasySlugger, I think it can be done, but probably differently - maybe I just need to add a check to see if that module is installed and then also use the saveReady hook option rather than the JS one. Or maybe the EasySlugger module can just do that anyway, even after this module has done its thing? Not sure, but let me know what you need and I am happy to support it.

 

[Robin S]

@adrian, I think there might be an problem with the "Initial differences protected" option when changing the title of a page via the API (and assuming the "Enable for API" option is checked).

My understanding is that the initial differences protected option means that the page will not be renamed if it already has a name that is different from the name that would be automatically derived from the title. So if I have a page titled "Foo" and named "bar", and I change the title to "Baz" then the page keeps the name "bar" rather than changing to "baz". But if my page is titled "Foo" and named "foo" and I change the title to "Baz" then the name changes to "baz" because there was no initial difference between title and name. Is that right?

The issue is that in renameOnSave() here your test to see if the page should be renamed will fail when it shouldn't because if the title is being changed via the API then in saveReady it will (almost) always be different than the existing page name. I think instead you would need to compare if the existing page name is different than the previous value for the title before it was changed, as only that would constitute an initial difference.

[adrian]

Thanks @Robin S for picking that up and figuring out what the problem was. I have committed a new version which fixes the issue (the same version you tested via PM).

[PWaddict]

@adrian Does the PW 3.0.111 affects the module?

[adrian]

5 minutes ago, PWaddict said:

@adrian Does the PW 3.0.111 affects the module?

I don't know - you tell me ?

I just took a very quick look and the basic functionality seems ok. Could you point me to what you are having issues with?

[PWaddict]

41 minutes ago, adrian said:

I don't know - you tell me ?

I just took a very quick look and the basic functionality seems ok. Could you point me to what you are having issues with?

I'm still using the 3.0.110. I've read about the changes on page names on 3.0.111 and that's why I asked if it affects the module.

[adrian]

9 minutes ago, PWaddict said:

I'm still using the 3.0.110. I've read about the changes on page names on 3.0.111 and that's why I asked if it affects the module.

No guarantees, but from what I can tell about those changes, I don't think it should affect this module. If you find anything though please let me know and I'll attempt to fix it ASAP.

[Robin S]

Hi @adrian,

I'm having another problem with pages not being renamed when "Enable for API" checked.

As a demo, here are my module config settings:

{"PageRenameOptions":{"version":"1.0.5","settings":{"enableForApi":1,"renameMatchTitle":1,"renameWithoutTitleChange":"","renameUnpublishedOnly":"","includeExclude":"exclude","exemptTemplates":[],"exemptPages":[],"exemptRoles":["superuser"],"initialDifference":1,"preventManualChanges":1,"liveChanges":null,"uninstall":"","submit_save_module":"Submit"}}}

In ready.php I have this hook:

$pages->addHookAfter('saveReady', function(HookEvent $event) {
	$page = $event->arguments(0);
	if($page->template == 'basic-page') {
		$page->title = uniqid();
	}
});

For any page using the basic-page template, the page gets a new title on every save as expected but the name is not updated. I tried turning off "Initial differences protected" in case that was related, but pages are not renamed then either.

[adrian]

Sorry about that @Robin S - my logic didn't properly account for API calls triggered from the backend, as is the case with this hook of yours. I assume you are saving the page via the admin?

I should have a fix shortly, but please confirm that you are saving via the admin.

[Robin S]

1 minute ago, adrian said:

but please confirm that you are saving via the admin

Yes, in this example I was saving in the admin. Thanks.

[adrian]

Hi everyone.

I've just committed v2.0.0 of this module with some BREAKING CHANGES. 

The breaking change is the removal of the "Enable for API" option.

After lots of discussion and testing with @Robin S's help we decided that it's best that this module doesn't handle renaming via the API - it's not really its intended purpose, but there are also too many complications when it comes to dealing with hooks that save pages. This has allowed me to simplify the module significantly as well as now all the renaming is done via JS which is more inline with how the PW core sets the page name when you initially title a page.

This update also adds individual Exempt Roles settings for each of relevant settings, rather than the old overarching option.

I have also done quite a bit of cleanup and refactoring, but all those should be taken of via the module's upgrade() method. That said, I still recommend taking a good look over the settings page to make sure it's still showing what you expect and that the module's behavior is still correct for your needs.

Please let me know if you find any problems.

Happy Holidays all!

[bernhard]

Hi @adrian

are you aware that the page rename seems not to work if the settings tab is disabled on a template? Is that intentional? Not a big deal for me, just realized it during debugging an issue on my site and wanted to let you know ? 

[adrian]

Hey @bernhard - it works for me. How are you disabling the settings tab?

[bernhard]

I'm using the "noSettings" property of the template. I've changed my setup, so I can't test it any more. As it works for you I don't want to investigate this one ? 

[adrian]

6 hours ago, bernhard said:

I'm using the "noSettings" property of the template.

Via the System tab setting, or are you applying via a hook or something?

6 hours ago, bernhard said:

As it works for you I don't want to investigate this one

Fair enough ? - if anyone else is having issues with this not working, please let me know.

[bernhard]

4 minutes ago, adrian said:

Via the System tab setting, or are you applying via a hook or something?

Via a RockMigration ? 

$rm->migrate([
  'templates' => [
    $this->template => [
      'icon' => $this->icon,
      'tags' => RockChimp::tags,
      'fields' => ['title'],
      'parentTemplates' => [RockChimp::tpl_messages],
      'noChildren' => 1,
      'noSettings' => 1,
      'pageClass' => '\RockChimp\Message',
      'pageLabelField' => "fa-{$this->icon} {title}",
    ],
  ],
]);

 

[adrian]

Sorry, I have no idea cause that should result in the same thing.

If you do feel like debugging, you'll see that the way I handle renaming when the settings is hidden is to move the name field to the Content tab and then hide it (https://github.com/adrianbj/PageRenameOptions/blob/8665aca5023417163841603fda8037df2ccbe245/PageRenameOptions.module#L95-L98)

You could check to see that the field is correctly being placed there and that it is changing when the title is changed. The easiest way to do that is to use the browser dev console with this after you've changed the title.

$('#Inputfield__pw_page_name').val();

If not, then at this point I'll need to hear from someone else.