managing end-user created content

[bmacnaughton]

I'm working on a web site that allows the user to create vector graphics that end up being saved as both PNG and SVG files. Each end-user is mapped to a PW user via their email. They can create as many vector graphics images as they would like, each of which is saved as PNG and SVG. We would like to make the PNG file directly accessible via a unique URL (not the actual file location).

I'm kind of new to PW, so pardon me if I'm missing obvious things.

My solution so far has been to store the files in a user-ID-based directory where the filename encodes various bits of information about the image. When the user navigates to their repository, the file names are read and packaged into a data structure for straightforward access. All of that is done with PHP code, nothing is PW specific.

I arrived at this because I didn't know how to:

1) store an arbitrary number of SVG and PNG files in the DB in a way that links them to the specific user.

2) store the meta-information about the SVG and PNG files in such a way that it can queried seamlessly as other PW fields

It seems to me that the only way to do this is to create my own DB tables (or single table that  stores meta-information and a reference to the files or blobs if the files are in the DB). But maybe I'm just not looking in the right place.

This also comes up in that I'd like to create a short-URL that maps to a specific file. Doing this with a separate table, where key short-URL maps to file-reference, is the way I'd naturally do it. But is there another way to do so?

This may be a bit unclear, but the root of the question is how do I store an arbitrary number of items using PW? 

[LostKobrakai]

I'd suggest creating a page for each graphic, so it's easy to store metadata. You can also use a pagefield to link graphics to users. For the file storage I'd suggest using the FieldtypeSecureFile module, which allows you to store files anywhere on your system (just need write permission) so you're super flexible and outside the webroot the files cannot accidentally be accessed directly.

[bmacnaughton]

Can you expand on this a bit or point me at some docs? Point me at an example code? I'm new enough to PW that what you're saying sounds good, but I'm not sure what to do based on it. 

[LostKobrakai]

Something to read on the topic of page setups: https://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/

Here is the forum topic about the mentioned file module: https://processwire.com/talk/topic/10671-fieldtypesecurefile/

[adrian]

This tutorial from soma might also be useful: https://processwire.com/talk/topic/4602-flexible-downloads-using-pages/

Also, if you're working with SVG files, these two modules might be of interest:

http://modules.processwire.com/modules/image-rasterizer/

http://modules.processwire.com/modules/file-validator-svg-sanitizer/

[bmacnaughton]

Thanks for the links. So if I am understanding correctly, you recommend creating pages with unique names for both situations: the SVG/PNG file pair and the unique-URL to SVG/PNG mapping, e.g., something like this (forgive any errors, I'm coding it right here):

// create new page
$p = new Page();
$p->template = 'svg-png-page';
$p->parent = '/repository';
$p->svg_png_name = $the_file_name;
$p->user_id = $user->id;
// populate other meta-data here

$p->save();

So then, in another place, when I want to find all the saved images for this particular user, I would do something like:

$items = $pages->find("template=svg-png-page, user=$user->id");

Then I would iterate on $items as any other array (or WireArray).

And it would be similar for the unique-short-URL to image mapping - the template would hold a single field, a reference to the svg_png_name (or the page ID or a file), something similar to:

 // create new page
$p = new Page();
$p->template = "unique-url-mapping";
$p->parent = '/maps';
$p->file = $the_file_name;
// populate any additional meta-data

$p->save();

Does a page have to have a name or title?

Thanks for the pointers so far.