tags:

views:

120

answers:

3

Hi, our application wants to be able to create static, searchable pages based on user profile information, which would be linkable to other public profiles.

I am looking at LinkedIn as an example...it seems like they actually auto-generate the page to be a static file that is indexable and searchable.

Can someone suggest how we would do this? I am thinking there would need to be a cron job that runs and writes a the path and file name.

The user may want to keep the whole page private, in which case I imagine it would need to delete it.

There's alot of sub-requirements but that's the general concept and wanted to start getting ideas and feedback.

Thanks.

+2  A: 

You can do without the cron job if you generate the static pages in real time whenever the profile information is created/updated or whenever user changed the setting to keep info public/private. This way you are not constantly looping through all users, and do not depend on another component (your cron job) to be running.

+1  A: 

One alternative would be to adopt an explicit RESTful information architecture so that a profile resource ("page") is addressable with a permanent URL. The resulting resource could be a static page. Or not. That would be an implementation detail invisible to the search engine crawler and any web browser accessing the resource.

Brad
I am using qcodo/php...would that mean there is an actual permanent URL stored on the server?
AFG
Unfortunately, I do not know about qcodo.
Brad
A: 

umnik700's answer is fairly dead-on if you're not considering issues related to authentication or who gets to see what. Consider the difference between the profiles you see when you're logged into Facebook versus those same profiles' publicly facing, searchable counterparts. Even MySpace, with a lot less consideration for search engine privacy, has viewability that is dependent on your relationship to the other person, defaulting, for private profiles, to "This profile has been set to private by the user" or something to that extent.

If you're looking to suddenly scale out a social tool where individuals are eliciting their personal information, I would suggest umnik700's answer (dynamically generate the content, but not the URLs, for public versions of the profile) with the following corollary: you need to be able to support privacy preferences varying from extremely strict to completely open, and default to a version that at least errs on the stricter, more private version of the profile. If you're just now pushing out searchable personal content when there never was any way to find it outside the site before, it's important not to abuse information given under different pretenses.

I know this probably requires maybe more scalability and added functionality than you were hoping this project would take, but to do otherwise could be most likely taken as a violation of your user base's tacit trust. Anyway, the best strategy to do this will probably require you to lean on your database more anyway, so it might be time to rework it a bit--including adding some privacy preferences.

Robert Elwell
Yes, there is a privacy public or not public for the information...I'm trying to figure out what the actual technical mechanism is from within php -- I guess I would have to write a file name, but don't like that idea of making a directory writeable, so usingof a separate subdomain called "public"
AFG
I'm pretty sure you can set up your htaccess file to ignore specific directories and load up the index of a top-level directory, effectively using the unique URL as an identifier toward the user without any messy variables. This is similar to the Zend Framework routing to a controller and action
Robert Elwell