deane.barker

I want to run it in a sub-directory of an existing virtual host, and using a shared database. Does it play well with others?

Poor choice of words, sorry. I only meant "weirdness" in relation to what I'm specifically trying to do here.

A valid point, but one could ask why you're creating the page from that first step anyway? Why not move the Name the Title to the second page, have the first page template selection only, then create the page after they save from the second step? It seems to me that all the weirdness could be avoided by just consolidating the two screens.

If you're automatically setting the name and title, and there's only one template that can be used, then, yes, it should be a one-step process. We work with another CMS which is architecturally very similar to PW. If you cannot select a content type for that spot (meaning there's only one that can be used), then you go directly to the editing form without the "pick a content type" screen in between. Editors understand it just fine.

I found the $this->config->advanced line, but can't figure out where to set that intelligently. I'm setting it in init right now, and that shows the System tab, but I realize there's likely a more intelligent way to show this.

I see the pageClass property of Template, and I see how both Pages and PagesType support using it to instantiate objects, but I don't see where it's managable in the UI. Am I missing it, or do I need to add it myself to the admin UI module?

Okay, I found it. I had to comment out a half-dozen lines in that ProcessPageAdd module, but it all works fine. I would love to do this without hacking the core, obviously. To do this, I'd need hooks immediately before database insert, then again after, I think. Although, with a little more work, the code would be fairly innocuous and could be included in the core -- it would never trigger on a default install since the "Name" field would always be shown and validated, and therefore always contain a value. For the code to ever execute, you need to save a page with no name, and that couldn't happen unless you deliberately messed around with the Add New screen to remove the "Name" field.

Yeah, I'm hot on the trail of this. Give me some clue where to find the UI for the "Add New" admin screen so I can shut off the Name field there and do an end-to-end test of the theory.

My solution is ugly, but it works. Just inside Pages->__save if($page->name == '') { $page->name = 'temp' . microtime(); } Then towards the bottom of that function, just before the hooks are run: if(substr($page->name,0,4) == 'temp') { $page->name = $page->id; $page->title = $page->id; $this->save($page, $options); } Obviously, this needs to be made quite a bit more robust (the string "temp" is collision-prone as hell), but the theory works. In general. Set a random-ish temporary name, with a detectable pattern (starting with "temp" in this case) Insert (to get an ID) After the Insert, if the name matches the temporary name pattern, set name and title to the ID and re-save.

No, isSaveable returns an error when the name has no name. I'm hacking up a solution, just to see how feasible the idea is.

Yeah, I totally get this. I just want to set Name and Title automatically. I want to find a way to hide both these fields, and set these to arbitrary values if no value was entered (set them to the page ID, for instance). What would be helpful is not to require any validation on these fields, behind-the-scenes. When you save a page, if they have not been set, set them to the page ID. Setting them can still be enforced by validation on the UI, but have a failsafe so that the UI can be altered and pages still save just fine. I could probably do this client-side with some Javascript. If they select "Person" from the dropdown, disable both fields then, when the form is submitted, set them to random values. Then, hook the post-save event, and reset them to the page ID, after which they'll be managed automatically. But, we're wandering down the hack rabbit hole pretty quickly here...

I agree. The Title field will exist, but I will set it automatically every time the page is published. Behind the scenes, the data will be there. I just need the user to not have to set it.

The problem with removing the Title field is that this leaves the Add New page in a weird state -- no Title, but a Name field (the URL segment). Since there's no Title, the Name doesn't get set automatically, so you're asking someone to input a raw URL segment (without one being suggested). It looks odd, to say the least.

Oh...I get it. It won't show up on any Add New page now since it's not global. Nice.

But how does PW know that you don't need a Title until you select "Person" from the template dropdown?

I have a "Person" template, with fields for FirstName and LastName. There is no need for this page to have a "Title" because the title should always be "LastName, FirstName". I have successfully created the hook to do this -- when you publish, the Title of the page is set to "LastName, FirstName" and the page is saved. Then I hid the Title field on the Edit Page screen. However, PW still requires that you Title the page when you first create it. So, you are asked to enter a Title, URL segment, and select a template. Is it possible to suppress the Title field on the Add New screen? I think this is going to be hard, because on that screen, you haven't even picked a template yet, so PW has no way of knowing you're creating a Person and should therefore not enter a Title. This is a specific example of a more general problem -- when the Title of a page should be formed from structured data found in the template definition, how do you handle the apparent need for an editor to enter a Title which will immediately be reset? This is a training issue -- you could explain this to editors, but they'll find it confusing ("So...when do I enter a title? On this one? Why not on this one?").