Known > 0.9.9 Micropub of Photo issues #13
Comments
|
Image is added into the post html idno/known#2138 (previously restricted to an image that was part of a check–in, hence the error.log: |
|
I’m having my own issues at the moment, between different domain names. However, you would have to add your blog URL to the Wordpress or compatible blog section so that micro.blog’s app can authorise itself to/with Known. |
|
Might try idno/known#2265 once it has been merged. |
|
... Now merged, lmk if this resolves your problem |
|
There’s still two runs through with upload from a blog URL, had to add blog URL to /etc/hosts since server could not resolve itself. Eventual post does have an editable image. |
|
I believe the double run is within the endpoint code, it uses uploadfromURL() (or whatever the function is actually called). I tried to get a proxy in place to observe Micro.blog posting on macOS… |
|
I believe this is the same problem as I reported on idno/known#2267 |
|
@mapkyca I tried to add in the debug line from idno/known#2273 (plus a couple of my own to illustrate) Result:
https://definitely.cz/2018/on-the-way-to-4mwh https://definitely.cz/file/35b68aa733c2154ba25fd87498bfbdbf is uploaded (?), and used in the second request producing https://definitely.cz/file/53421427f115a552cb5688c22b3d70b8/ around line 262 |
|
This sortof implies that ->postMedia() is being called. No object is available at this point. TBH I'm not entirely sure why an event is being triggered here - seems unnecessary. However, you're getting two loops because the first loop the client is posting the photo data (as opposed to using a url which some other clients use), this is returned and used as a url for the second event where the actual post object is created. I'll double check that this itself doesn't call an attempt to create another file from URL which would seem inefficient as it'd create two copies of files, but either way wouldn't result in duplicate photo posts. |
|
@mapkyca I think @jeremycherfas’ is a different issue within the micropub code. The other side of @jeremycherfas’ coin is that any additional images attached to an Instagram post appear to go missing… |
|
I notice the JSON payload still has the html payload which was removed elsewhere in a previous commit. So, there are two problems: 1) You're not seeing a photo, 2) @jeremycherfas is seeing two ... ? |
|
I see a photo, which seems to be derived from one previously uploaded. |
|
I'm not sure whether the images going missing is the problem or not. My plan is to update to master later this afternoon and then post a multi-image to IG. And then see. I haven't looked at the new debugging options yet. |
|
@cdn the double pass appears to be normal behaviour for some clients - uploading the image first, getting a url, then passing that url in a create action. Other clients post a url which is then retrieved in a single pass. |
|
Did a test post via PESOS/OwnYourGram with two images:
|
|
I received both images: https://definitely.cz/2018/inverter-output-sky-at-noon @jeremycherfas should be happier with recent HEAD And a re–run of previous ones because the ccTLD changed :o) |
|
I suspect when a micro.blog client uses Micropub the Known code runs the else of the initial postCreate() if |
|
Have mostly got things working Forked extension; Micro.blog's Sunlit app is still a stumbling block, but less vital. |
While trying to do this:
Use the micro.blog apps (macOS/iOS) to create a post with an image on Known
I encountered this error:
Photo post is created, image does not show
Some other notes:
Uploaded images seem to be cycled twice through the system, since the url passed to uploadFromUrl() includes the known blog url, and notably no file extension which leads to MIME fun (a blank $mimetype)
This has a couple of solutions: mime_content_type($tmpname); or @cleverdevil’s use of finfo_open()
Give us some context:
version.knownfile0.9.9 2018032701 / 0.9.9-a 2018041302
postgres
I see other odd things in /var/log/nginx/error.log like :
notice - PHP [8] Undefined variable: entity in /<webroot>/IdnoPlugins/IndiePub/Pages/MicroPub/Endpoint.php:128" while reading response header from upstreamWhich pertains to:
https://github.com/idno/Known/blob/master/IdnoPlugins/IndiePub/Pages/MicroPub/Endpoint.php#L128
The text was updated successfully, but these errors were encountered: