smd_meta_image: create image/article metadata via IPTC on upload

etc · 2019-10-07 16:18:43

Bloke wrote #319575:

Wait, yes it does need the callback as it needs to update the article to inject all the image IDs into the article_image field when they’re all uploaded, in the order they are presented to the <input/> box.

Done, but I dunno how to respect the order of all images. I fear that this “batch” callback is fired on each image upload. Needs testing/thinking…

Bloke · 2019-10-07 16:26:58

Cool, thank you. I’ll run some tests as soon as I can.

etc · 2019-10-07 19:28:37

Nope, this callback was useless, sorry, removed. We don’t upload all files in one array any more, so every file would trigger this callback with only its own id as data. The only way I can see atm is to subscribe to JS callbacks (uploadEnd is fired when all files have been uploaded) and issue an ajax request to the server. But that’s too cumbersome, we need something easier.

Bloke · 2019-10-07 22:44:45

etc wrote #319580:

Nope, this callback was useless, sorry, removed.

I did take a cursory look at the code before you axed the callback, and that was my conclusion too. Shame, it would have been neat.

subscribe to JS callbacks (uploadEnd is fired when all files have been uploaded) and issue an ajax request to the server. But that’s too cumbersome, we need something easier.

Do we know how many files in total there are in the <input/> at the moment the upload button is clicked? If so, can we transmit that as another param? So we have fileInputOrder and, say, fileInputTotal sent with each file? That gives us (effectively) an image X of Y at the server so I can count up how many I’ve inserted and when it matches the total, I can trigger the article insertion using the metadata I stashed from the image designated as ‘1’.

etc · 2019-10-08 07:24:05

Bloke wrote #319584:

I did take a cursory look at the code before you axed the callback, and that was my conclusion too. Shame, it would have been neat.

It would work in 4.5 where all files were sent in one request. But since we’ve been asked to overcome PHP max post size limits, now they are sent separately, in chunks if necessary. Only client-side JS knows now when everything is uploaded.

Do we know how many files in total there are in the <input/> at the moment the upload button is clicked? If so, can we transmit that as another param? So we have fileInputOrder and, say, fileInputTotal sent with each file? That gives us (effectively) an image X of Y at the server so I can count up how many I’ve inserted and when it matches the total, I can trigger the article insertion using the metadata I stashed from the image designated as ‘1’.

We could, but how would you know to which file “package” the uploaded files belong? I think you need to send a unique id with every package and insert image ids into corresponding article. It’s just not clear where to store this unique id: custom field, separate table?

Bloke · 2019-10-08 08:48:36

etc wrote #319586:

how would you know to which file “package” the uploaded files belong?

Ah. Do the sequence numbers not begin at 1 for each set? I guess since everything’s ajax now it will only reset to 1 on page full refresh, right?

I just wondered if perhaps during a single “batch” or “package” of images, they could be numbered starting at 1 in the fileInputOrder param. Doesn’t matter what order they arrive, as each image calls file_insert() via the plugin anyway so I can test this ‘sequence number’ and stash the metadata for the one tagged as ‘1’ and increment a counter each time I see an image so I know how many have been inserted and can store the image IDs as I go.

Then, when I’ve seen them all (i.e. have inserted fileInputTotal images) I can trigger the article creation, stuff the metadata I stored from image ‘1’ into it, stuff the list of image IDs I collated into the article image field and commit.

If the sequence counter can be reset to ‘1’ again when uploadEnd fires, would that work? So the next batch of images uploaded start at 1 again.

etc · 2019-10-08 08:55:27

Bloke wrote #319587:

If the sequence counter can be reset to ‘1’ again when uploadEnd fires, would that work? So the next batch of images uploaded start at 1 again.

Dunno what would happen if you start two long batch uploads at once, from different browser tabs. If they contain the same number of files, the server has no means to differentiate them.

Bloke · 2019-10-08 10:22:57

etc wrote #319588:

Dunno what would happen if you start two long batch uploads at once, from different browser tabs. If they contain the same number of files, the server has no means to differentiate them.

True. Though I wouldn’t expect anyone who was using the plugin to work that way, it’s not outside the realm of possibility.

And I suppose different users could be doing it at the same time too huh. So unless we somehow knew which user the upload belonged to, we’re sunk.

Drat.

Bloke · 2019-10-08 10:25:21

What about if we timestamped the upload process the moment it began? Or assigned it a UUID of some description (even an md5). In effect, giving it a unique key based on the time the Upload button was hit. If that’s sent along with each file, that ties them to a ‘group’ or batch and they could then be differentiated server side from any other upload that may occur concurrently.

Combined with the sequence number and the total, would that work?

etc · 2019-10-08 11:51:09

Bloke wrote #319590:

And I suppose different users could be doing it at the same time too huh. So unless we somehow knew which user the upload belonged to, we’re sunk.

This we actually know, because the user admin cookie is sent on every connexion, be it xhr or not. But there still is a risk of confusing two uploads from the same user. Images are not really concerned, but since we can upload tons of Gb now, a user could forget about an upload he has started an hour ago.

What about if we timestamped the upload process the moment it began? Or assigned it a UUID of some description (even an md5). In effect, giving it a unique key based on the time the Upload button was hit. If that’s sent along with each file, that ties them to a ‘group’ or batch and they could then be differentiated server side from any other upload that may occur concurrently.

Combined with the sequence number and the total, would that work?

That’s what I meant by unique id (timestamp, hash, etc). I think the best way is to let plugin authors add it via some UI callback, either as hidden input (the script sends them all along with each file) or via JS. The question is: how would you treat it server-side? Every file triggers a separate request to ?event=file, so your plugin will be called anew for every file. It must then store somewhere (db?) the batch upload information (e.g. what is already uploaded) until all files are uploaded. That’s certainly feasible, but I don’t know whether we should store these batch upload ids in core or leave it with plugin authors.

Bloke · 2019-10-08 12:07:43

etc wrote #319591:

I think the best way is to let plugin authors add it via some UI callback, either as hidden input (the script sends them all along with each file) or via JS.

That works for me. pluggable_ui()?

Every file triggers a separate request to ?event=file, so your plugin will be called anew for every file.

Yeah, that is a pickle. I was thinking originally of storing it in a global, but that won’t help as it’ll be trashed after each file is done uploading. So the only persistent storage we have is the database or filesystem. The plugin’s data column is an option, since it can be used as a scratchpad, but it could get messy updating it when each file is uploaded. And old data wouldn’t be able to be purged easily.

If we’re allowing plugin authors to set the batch ID, it should probably rest with those authors to handle them. If Txp was generating the unique IDs as part of the upload process, then it’s up to core to store them for the life of the upload and to present such info to any interested parties during callback. Since we can’t predict what people might use them for, I’d be tempted to just permit the mechanism and leave implementation to plugins.

etc · 2019-10-08 12:54:49

Bloke wrote #319592:

The plugin’s data column is an option, since it can be used as a scratchpad, but it could get messy updating it when each file is uploaded. And old data wouldn’t be able to be purged easily.

That’s actually an option, JSON decoding/encoding is not that hard. Or may be even MySQL XML functions could do.

Since we can’t predict what people might use them for, I’d be tempted to just permit the mechanism and leave implementation to plugins.

I agree, we’d just provide an order/total value.

Textpattern CMS

Textpattern CMS support forum

#13 2019-10-07 16:18:43

Re: smd_meta_image: create image/article metadata via IPTC on upload

Bloke wrote #319575:

#14 2019-10-07 16:26:58

Re: smd_meta_image: create image/article metadata via IPTC on upload

#15 2019-10-07 19:28:37

Re: smd_meta_image: create image/article metadata via IPTC on upload

#16 2019-10-07 22:44:45

Re: smd_meta_image: create image/article metadata via IPTC on upload

etc wrote #319580:

#17 2019-10-08 07:24:05

Re: smd_meta_image: create image/article metadata via IPTC on upload

Bloke wrote #319584:

#18 2019-10-08 08:48:36

Re: smd_meta_image: create image/article metadata via IPTC on upload

etc wrote #319586:

#19 2019-10-08 08:55:27

Re: smd_meta_image: create image/article metadata via IPTC on upload

Bloke wrote #319587:

#20 2019-10-08 10:22:57

Re: smd_meta_image: create image/article metadata via IPTC on upload

etc wrote #319588:

#21 2019-10-08 10:25:21

Re: smd_meta_image: create image/article metadata via IPTC on upload

#22 2019-10-08 11:51:09

Re: smd_meta_image: create image/article metadata via IPTC on upload

Bloke wrote #319590:

#23 2019-10-08 12:07:43

Re: smd_meta_image: create image/article metadata via IPTC on upload

etc wrote #319591:

#24 2019-10-08 12:54:49

Re: smd_meta_image: create image/article metadata via IPTC on upload

Bloke wrote #319592:

Board footer