Right now, you need to use page.cgi to build all the added-in pages.
The entire format is just page.cig?p=pagename (without the .ext, it defaults to .html, since it goes through the template parser)
(actually, if there is a . in the template name, the template parser should just use it "as is" rather than try to put an .html on the end, but that's a horse of a different color...)
The t= is to use a different template set than default, and that would actually be a good idea, in some ways, since you could put all your non-links pages in a different directory.
(Hey, Alex/GT.... do you see the possiblity for another template directory :) The "user_pages", which page.cgi?p= will default to if it's set in the admin.....)
It wouldn't be too hard to modify nph-build.cgi or create a plugin that will either take the directory referenced above, or a list of templates => output locations, and then parse them and write them out when links is rebuilt.
It actually would be fairly trivial, I think, except the error checking on input would probably outweight the "real" code by a factor of 5-10 : 1.
This would _actually_ be a good feature to build into Links SQL, and while Alex has frozen the features of the next release, this is so trivial, that maybe he'd consider it.
1) Add a user_pages directory option and the associated template storage directory
1a) user_pages => .../template_root/user_picked_name
1b) Used as if $CFG->{'user_pages'} when needed.
2) Output of those pages would be /build_root/user_picked_name
3) Add an option to the nph-build.cgi to "build_user_pages" if $CFG->{'user_pages'}
4) Build all the pages found in the .../template_root/user_picked_name directory and
put them into the /build_root/user_picked_name directory.
5) page.cgi would do the same thing. When a p= request came in, it would check to see if
$CFG->{'user_pages'} was set, and use that directory. Maybe you'd want to make that a
u(ser_templates) or c(ustom) flag, so that the existing p= sites continue to run.
Process finished. This is a generalized process that allow sites to set up an about or info
area. I can additional generalizations, and flags, but that is not the real purpose of Links,
and for the broadest number of users, this simple change would be more than sufficient.
It should be left to a plug-in to generalize further what page.cgi and nph_build.cgi can
do with user-defind templates, and additional template directories.
If Alex/GT doesn't get to it in the 2.1+ release, I'll probably have a module that does
ths in the IMage Galery, to allow providers to customize the look of their site slightly.
PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Plugins:http://LinkSQL.com/plugin
The entire format is just page.cig?p=pagename (without the .ext, it defaults to .html, since it goes through the template parser)
(actually, if there is a . in the template name, the template parser should just use it "as is" rather than try to put an .html on the end, but that's a horse of a different color...)
The t= is to use a different template set than default, and that would actually be a good idea, in some ways, since you could put all your non-links pages in a different directory.
(Hey, Alex/GT.... do you see the possiblity for another template directory :) The "user_pages", which page.cgi?p= will default to if it's set in the admin.....)
It wouldn't be too hard to modify nph-build.cgi or create a plugin that will either take the directory referenced above, or a list of templates => output locations, and then parse them and write them out when links is rebuilt.
It actually would be fairly trivial, I think, except the error checking on input would probably outweight the "real" code by a factor of 5-10 : 1.
This would _actually_ be a good feature to build into Links SQL, and while Alex has frozen the features of the next release, this is so trivial, that maybe he'd consider it.
1) Add a user_pages directory option and the associated template storage directory
1a) user_pages => .../template_root/user_picked_name
1b) Used as if $CFG->{'user_pages'} when needed.
2) Output of those pages would be /build_root/user_picked_name
3) Add an option to the nph-build.cgi to "build_user_pages" if $CFG->{'user_pages'}
4) Build all the pages found in the .../template_root/user_picked_name directory and
put them into the /build_root/user_picked_name directory.
5) page.cgi would do the same thing. When a p= request came in, it would check to see if
$CFG->{'user_pages'} was set, and use that directory. Maybe you'd want to make that a
u(ser_templates) or c(ustom) flag, so that the existing p= sites continue to run.
Process finished. This is a generalized process that allow sites to set up an about or info
area. I can additional generalizations, and flags, but that is not the real purpose of Links,
and for the broadest number of users, this simple change would be more than sufficient.
It should be left to a plug-in to generalize further what page.cgi and nph_build.cgi can
do with user-defind templates, and additional template directories.
If Alex/GT doesn't get to it in the 2.1+ release, I'll probably have a module that does
ths in the IMage Galery, to allow providers to customize the look of their site slightly.
PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Plugins:http://LinkSQL.com/plugin
