Moving the "name" inputfield to content tab and how to regenerate all urls in a site

[Michael Murphy]

I think the name inputfield (used to generate page urls) is hidden away on the settings tab. The url is an important part of a website and I fear that most clients don’t ever see this, or forget about it when changing page titles.

Is there a way to move the name inputfield to the main Content area? Maybe below the title field - something like this screenshot :

Or alternatively, maybe the page name could be updated whenever the page title is changed (with an option to override)?

I recently had to regenerate all the urls in my site for various reasons. It was quite simple with the api - this was the code that I used

<?php

$pagesToCheck = $pages->find("template=playground|category");

$count = 0;

foreach ($pagesToCheck as $toCheck) {

$oldName = $toCheck->name;

//this creates the new url - use Sanitizer::translate if your titles have special characters
$newName = $sanitizer->pageName($toCheck->title, Sanitizer::translate);

if($oldName != $newName){

//print out the pages to be changed
echo $toCheck->title .' : '. $oldName . ' > '. $newName;
echo '<br />';

//replace the old url with the new one
$toCheck->name = $newName;

//save the page
$toCheck->save();

$count ++;

}

}

if($count == 0){
echo '<p>looks like all urls have been updated!</p>';
}

?>

[Soma]

If u set advanced mode u can set an option on the template system or advanced tab to move name to content.

[WillyC]

bad two raname aftar u.crated page

evry.time u raname a page.

u kill a link

may be

cd ..

[ryan]

The main reason why name isn't on the content tab by default is because you could be breaking links (internal or external) every time you change it. It's one of those things that ideally should never change after its been created. But if you do expect changes, I suggest installing the Page Path History module, which will keep track of those changes and setup 301 redirects.

[Michael Murphy]

thanks Soma, I had never used the advanced setting before (whole new world!). It kind of solves the problem - the Name field gets added to the top of the content tab above the Title (and open by default). It does not appear that you can change the field description or placement.

I agree that changing urls is quite dangerous, but it's definitely something that editors should be more aware of when creating or changing content. I think this could be best solved with a simple module that displays the current url below the Title field.

The next thing I want to move is the "hidden" status option, which is another thing clients frequently ask (how do i hide a page?).

[ryan]

The next thing I want to move is the "hidden" status option, which is another thing clients frequently ask (how do i hide a page?).

Instead of moving these things, why not teach the client how to use the 'settings' tab? These things are kept out of the 'content' tab for a few good reasons:

First is that they are things that are less likely to change after the page is created, so keeping them out of the content tab reduces the possibility of mistakes.

Second is that these are fields where changes are potentially costly. You change any one of the things on this page and you could affect navigation or site structure. This differentiates them from just about any custom field, which affect the content of the page, rather than the type or structure.

Third is that the fields in 'settings' are common among all pages, so it's a means of establishing a baseline consistency among all pages. Rather than the client having to figure out where 'name' or 'hidden' are, they know that no matter where they go, 'name' and 'hidden' are always in the same place.

I like to tell clients: "If you know how to edit one page, you know how to edit any page", and they find a lot of comfort in that. Since ProcessWire is driven by custom fields, it's possible for the editing scenario to change a lot from template to template. As a result, it's preferable (IMO) to have the page fundamentals (the things that are always there) kept together for consistency.

[Michael Murphy]

we can teach clients how to do things, but that does not really lead to a better system. I would prefer to see how the client uses the system and then adapt it to what best fits their workflow. If i notice they are using the hide page functionality often, then perhaps this would be better placed somewhere else.

This is a pretty edge case scenario, so I may be wrong, but I’d like to test and see. I really think the most innovative area of CMS will be around improving the workflow and user experience for each client and specific project. This is something that PW already handles very well and I’d like to push it further.

[ryan]

Michael, the status checkboxes actually can't be moved to the content tab. But you can add your own checkbox to perform a similar function. If you create a new field called 'toggle_hidden' (or whatever you want to call it) then you would just include "toggle_hidden!=1" in all of your $pages->find() calls.