URL Name generate from field other than Title

[peterb]

Is there a simple way to have the URL Name generate from a field other than Title? I need to do this just for 1 template type.

thanks, peter

[Adam Kiss]

No.

Why would you do that?

(Although I'm sure Ryan will come up with something

[ryan]

Peter,

There isn't currently a way to do that directly, but there are some alternatives. It would help me to understand the context of your need. What's the field you want it to generate from?

To disconnect name+title: You could uncheck the "global" option on the title field, and that would prevent it from appearing on the "add page" screen, which would basically disconnect title and name. In that scenario, you'd be forcing the user to enter a name for a page independently of anything else.

You could hook into the $pages->save() function and automatically set the page name for new pages (those that don't have an ID yet).

You could create your own Process module for adding pages, perhaps extending ProcessPageAdd. Then edit /admin/page/add and select your Process rather than the default.

You could also setup another page and Process for adding pages of a specific type in your admin.

There are other options too. What approach is best probably depends on the situation... tell me more and we can figure it out.

Ryan

[peterb]

I have a page template for "files". Each file page is an uploaded pdf. There will be 5,000+ of them. I would prefer the name displayed in the admin "pages" be meaningful, and display the file name. A title field is not really needed at all. These pages will never be viewed on a site as pages, but will be pulled into other template pages... by "client"

thanks, peter

[Adam Kiss]

Wouldn't be one page with files field better?

I mean, one hidden page called /download/ and there you go – bazillion of PDF files (althought, I'm not sure how PW acts when there is 1000+ files in one field)

[peterb]

not really, then I loose all of the organization, pagination, and search ability of PW

[ryan]

5000+ files would be more than you'd want to put on a page, just because it would be difficult to manage from an administrative standpoint. So I think your approach with pages is fine. I'm just hoping you are adding all these files with some automated API functions rather than manually.

So it sounds like the main thing is how they appear in the admin page list? If that's the case, we can easily change what appears in the page list. By default the page list displays the title field (if there is one) and otherwise displays the name field. You can modify that behavior by going to Modules > Process > Page List and editing the fields to display. You can display a field specific to your files template, and it'll get ignored by all the templates that don't have that field. So here is what I think you want to do:

Go to Setup > Fields > Title. Uncheck the "global" option, so that your files template can exist without a title field (optional, if you want it to).

Go to Modules > Process > Page List. Change the "name of page field to display" to:

filefield.basename title

Replace "filefield" with the name of your files field. I'm also assuming that your file field is a single file, and not multiple files.

I've not tried doing this with file fields before, but I think it should work.. let me know what you find.

Thanks,

Ryan

[peterb]

thankyou Ryan,

lot's of goodness hidden in those modules.

The other thing that came up was when I turned of global for Title, which I like allot, I am forced to provide a URL name when creating a page. Can this be avoided? it it needs something for that field, perhaps it could just be the id?

Peter

[Adam Kiss]

@Array: have you set maximum numbers of files as 1?

@name: you could transform name of the file into url, couldn't you? I believe that every piece of information must have it's URL

[peterb]

yes, set max files to 1

adding .basename does not provide the field contents

[peterb]

ok, this is not quite it....

"filefield" in the "Name of page field to display"  resolves to "Pagefiles(1)"

"filefield.basename" in the "Name of page field to display"  resolves to ""

"filefield.url" in the "Name of page field to display"  resolves to "/pw/site/assets/files/5767/"

[ryan]

Peter,

In that case, it's not working quite how I'd planned. Now that we've got an example of this scenario, I was able to update it to work.

https://github.com/ryancramerdesign/ProcessWire/commit/570f18127dda799c5352669f7df86c40fbf2d2f5

Grab the latest commit, or just that file if you prefer.

Just tested here, so hopefully it will work there too. Let me know.

Regarding an optional 'name' field... this is considered the one common element for all pages and any other objects in ProcessWire to have. Maybe we can auto-populate it with something if omitted. Are you adding these files manually or via the API?

Thanks,

Ryan

[peterb]

thanks,

I was going to import the first 5K with your example from here:

http://processwire.com/talk/index.php/topic,24.0.html

Still need to figure out importing the pdf into a file field, and having it move to the proper folder in assets.

But then the client will be adding them by hand which is fine. It's just confusing to make them name a url, as it will never be a discrete page. If it is manadatory, can I have the URL fill in from another field via a hook?

[apeisa]

Great discussion.

Little offtopic, but I think this adds to this: are files always public (accessible everyone who knows the url) or is there access control to files also?

[ryan]

Still need to figure out importing the pdf into a file field, and having it move to the proper folder in assets.

You don't need to worry about moving the files to the proper place. Just set it to the path or URL where the file is located, and it'll take care of it for you.

<?php

$page = new Page();
$page->template = $templates->get("your-template"); 
$page->parent = $pages->get("/path/to/the/parent"); 
$page->save(); // a page has to exist before you can add files to it

// add a file to a single file field:
$page->filefield = "/path/to/file/somefile.pdf";

// or, add a file to a multi-file field: 
$page->filefield->add("/path/to/file/somefile.pdf"); 

// don't forget to save it again
$page->save();

You could also do this if the file is somewhere else online:

<?php
$page->filefield = "http://some-domain.com/some-file.pdf"; 

In all of the above examples, ProcessWire will copy the file to it's own storage location behind the scenes.

I will look at what we can do to make that name field optional or automated.

[ryan]

Little offtopic, but I think this adds to this: are files always public (accessible everyone who knows the url) or is there access control to files also?

Currently all files attached to pages are stored in /site/assets/files/[page_id]/. If someone has a URL directly to a file, there is nothing to prevent them from accessing it. Down the road, I figured we would add another dir, like /site/assets/files-private/, and those requests would get sent to PW (via the htaccess) rather than letting Apache handle them. PW would determine whether to passthru the file data based on whether they have access to the page. There is significant overhead in doing this (depending on filesize), so it's not something we'd want to do on other pages.

[apeisa]

Sounds like a great solution. It could be setting on filefield (private or public). So usually no need for private, but if you are building intranet or something like that then this is a must.

[ryan]

I totally agree. The funny thing is that this feature was actually in Dictator CMS (ProcessWire from 2003). It was designed in part by the needs of a company intranet, where they had documents for employees about benefits and stuff.

I'm not sure we can easily set it up at the field-level just because asset storage is currently provided at the page-level, and fields just get their asset storage location from their parent page. Plus, we already have a means of determining if the file should be protected: if a page lacks the "guest" role, then we can assume that it's files should be protected. That's because any page that lacks the "guest" role requires a login to access. So when a page is protected, it's asset storage dir would start with a period, i.e.

/site/assets/files/.123/

rather than:

/site/assets/files/123/

I'm thinking we'd do that rather than the /files-private/ mentioned in the previous message just because it strikes me as a littler simpler (simpler is better).

PW's htaccess file already blocks access to any dirs that start with a period. But we'd update it so that requests that match /site/assets/files/.[0-9]/ would get sent to PW, which would perform the access checking before delivering the file's contents.

[apeisa]

I'm not sure we can easily set it up at the field-level just because asset storage is currently provided at the page-level, and fields just get their asset storage location from their parent page. Plus, we already have a means of determining if the file should be protected: if a page lacks the "guest" role, then we can assume that it's files should be protected.

True. Also only one folder name need's to change if guest access changes - no moving files around etc (which would be the case if there could be private & public files on one page based on the field settings).