ID and version for default BG images?

[erasmus]

Trying to construct a default value for the already uploaded "pre-made" BGs. Where can I find the version & ID values? @avorio

[avorio]

In the console.

Here's the metadata for the first background image I uploaded:

https://cloudinary.com/console/media_library#/dialog/image/upload/bg-1

[erasmus]

Yes, I just can't find the ID there. Unless it is bg-1.jpg.

Version is v1468772151.

So how do I make the following URL should fetch it:

artboard/v1468772151/bg-1.jpg/?cutout=dp-cutout3.png&text=go+crazy

I guess I need to populate the DB with that specific image first, right? And if so, we should probably add the static files (layouts and BGs on Cloudinary) to some SQL source file...

[avorio]

Yes, I just can't find the ID there. Unless it is bg-1.jpg.

Yes, it is. You'll see that on the right-hand side where its full URL appears...

[erasmus]

Yes, got that. But I can't generate an artboard with it.

[avorio]

About your question — I'm not sure I understand what you mean. The database does not need to be aware of all the cutout options nor background options in Cloudinary.

These are handled by the Cloudinary API only.

[avorio]

Yes, got that. But I can't generate an artboard with it.

Try using bg-1.jpg only, i.e. without the version number.

[erasmus]

Nope, neither https://danandphil.herokuapp.com/artboard/v1468772151/bg-1.jpg/?cutout=dp-cutout4.png&text=go%20outside

nor

https://danandphil.herokuapp.com/artboard/bg-1.jpg/?cutout=dp-cutout4.png&text=go%20outside

works...

[avorio]

It seems that you haven't understood how the backend works :)

Those URLs do not work because there are no artboards in the database matching those parameters. You're probably trying to access an artboard that you generated in your local server. They would not appear in production. The files might be in Cloudinary, but that's not enough. There must be an artboard matching those parameters in the database.

I just created a new artboard and that is indeed accessible in production:

https://danandphil.herokuapp.com/artboard/v1469558725/lbz6xfxrfhxlnoyeh4ml.png/?cutout=dp-cutout4.png&text=go%20climbing

That's because production knows about this artboard. It'll only generate artboard pages for artboards created in the production app. If it doesn't know it, it'll return an error 404. [Even when the files exist in Cloudinary, as in the case when you create artboards locally.]

[erasmus]

Ah, I wasn't clear. That's what I meant with:

I guess I need to populate the DB with that specific image first, right? And if so, we should probably add the static files (layouts and BGs on Cloudinary) to some SQL source file...

So there's like a few (maybe more to come) background images that users can select, right. We still need to include them in the artboard screen and add the text + overlays... How do you suggest we do that?

[avorio]

You don't need the database at all for that.

Add them to the UI and [the files] to Cloudinary.

The rest is magic :)

[erasmus]

I generate the final view (on btn click) with a GET request to /artboard/etc/etc/

If user has uploaded an image - great - it works /artboard/v1469558188/hxmr3rxemenvoihosmqr.jpg/?etc

How do I generate the final artboard view, if user has not uploaded an image? I don't have a URL to put into my window.location.href call...

Does my question make sense? Otherwise, let's pick up on skype?

[avorio]

Huummmmmmmmmmmmmmmmmmmmmmm

Now we are talking!

You're right: that's a missing piece of the backend. My oversight! Sorry.

The backend as it is does not support that. I'll have to handle it somehow.

What do you pass to the final page when the user does not upload anything?

[erasmus]

I'll pass the default value which should be something like bg-1.jpg. (default backgroundmay change in final version...)

[avorio]

Actually, you should just pass the name of the file as it exists in Cloudinary.

Example (brackets included only for emphasis):

https://danandphil.herokuapp.com/artboard/[bg-1.jpg]/?cutout=dp-cutout4.png&text=go%20climbing

Is that ok?

I can generate a view based on this second URL structure, no problem. That's an easy win!

[erasmus]

Yes, I'll pass whatever name from Cloudinary. (bg-1.jpg just happens to also be the name on Cloudinary)

So we're creating a different URL syntax for the pre-made images? And keep the normal (with version ID) for the artboards with uploaded images?

[avorio]

Yes. Unless we need database records for those artboards. Do we?

(For stats, for example)

[erasmus]

nope, not for now. Just want a solution that works :)

[erasmus]

I've now implemented a check that returns the URL in the correct syntax no matter if it's a pre-selected or user-uploaded image. So now all URLs follow the syntax:

https://danandphil.herokuapp.com/artboard/[version]/[bg-1.jpg]/?cutout=dp-cutout4.png&text=go%20climbing

[avorio]

Fix implemented in #72.

We now have two different URL structures: one for uploaded bgs, another for default bgs.

They are, for example, and respectively:

/artboard/v1470084154/dtm4au1b2wasfo153pog.png/?cutout=dp-cutout1.png&text=go%20outside
/artboard/bg2.jpg/?cutout=dp-cutout1.png&text=go%20outside

From the PR deployment:

https://danandphil-pr-72.herokuapp.com/artboard/bg1.jpg/?cutout=dp-cutout3.png&text=google%20it

https://danandphil-pr-72.herokuapp.com/artboard/v1470085326/dsvhrf93yzp8uvj5bhfw.png/?cutout=dp-cutout1.png&text=go%20outside

@rashagen You now need to update your client-side script to take the user to the right URL. As it is, you're sending users to something like [version_id]/bg1.jpg. When it's one of the default background images used, you should omit the [version_id] bit to trigger the second URL pattern.