• Resolved efoertsch

    (@efoertsch)


    Using WooCommerce Media API to upload photos and getting what looks like plugin php error (I am not WordPress/PHP knowledgable)

    Running WP 5.5.1 , WooCommerce Version 4.4.1, WooCommerce Media API V2.3

    Log trace snippet as follows:

    D/LoggingInterceptor: request
    Sending request https://staging9.online.xxxxx.org/wp-json/wc/v2/media on null Content-Type: application/x-www-form-urlencoded
    Authorization: Basic xxxxxxx
    {“date”:”2020-09-12T23:58:12.161Z”,”media_attachment”:”……”,”media_path”:”https://staging9.online.xxxxx.org/wp-content/uploads/2020/58/TM-0912-10-01.jpeg”,”media_type”:”image”,”status”:”publish”,”title”:”TM-0912-10-01.jpeg”}
    D/LoggingInterceptor: response
    Received response for https://staging9.online.xxxxxx.org/wp-json/wc/v2/media in 1476.3ms
    server: nginx
    date: Sat, 12 Sep 2020 23:59:07 GMT
    content-type: application/json; charset=UTF-8
    vary: Accept-Encoding
    x-robots-tag: noindex
    link: <https://staging9.online.householdgoods.org/wp-json/&gt;; rel=”https://api.w.org/&#8221;
    x-content-type-options: nosniff
    access-control-expose-headers: X-WP-Total, X-WP-TotalPages, Link
    access-control-allow-headers: Authorization, X-WP-Nonce, Content-Disposition, Content-MD5, Content-Type
    expires: Wed, 11 Jan 1984 05:00:00 GMT
    cache-control: no-cache, must-revalidate, max-age=0
    x-httpd: 1
    host-header: 8441280b0c35cbc1147f8ba998a563a7
    x-proxy-cache-info: DT:1

    <br />
    <b>Warning</b>: Illegal string offset ‘rendered’ in <b>/home/customer/www/staging9.online.xxxxxx.org/public_html/wp-content/plugins/woo-media-api/class-woocommerce-media-api-controller.php</b> on line <b>80</b><br />
    <br />
    <b>Warning</b>: Cannot modify header information – headers already sent by (output started at /home/customer/www/staging9.online.xxxxx.org/public_html/wp-content/plugins/woo-media-api/class-woocommerce-media-api-controller.php:80) in <b>/home/customer/www/staging9.online.xxxxx.org/public_html/wp-includes/rest-api/class-wp-rest-server.php</b> on line <b>1372</b><br />
    {“code”:”rest_upload_sideload_error”,”message”:”Sorry, this file type is not permitted for security reasons.”,”data”:{“status”:500}}

    The page I need help with: [log in to see the link]

Viewing 11 replies - 1 through 11 (of 11 total)
  • Thread Starter efoertsch

    (@efoertsch)

    I hate to admit it but part of my problem might be that I had the wrong value for month in the URL. (I am blaming that on to many hours riding herd on a hot laptop). Other complications preventing me from retesting fix. Stay tuned.

    Thread Starter efoertsch

    (@efoertsch)

    Still getting some error after fixing month value in url. Still looking around for a fix.

    I am getting the same error. It is driving me batty. Any new info on the cause of the string offset error?

    Thread Starter efoertsch

    (@efoertsch)

    We got further by adding the following line to the wp-config.php file:
    ‘define(‘ALLOW_UNFILTERED_UPLOADS’, true);’

    It got us past the rest_upload_sideload_error, but still no joy. Calling the API returns the same warning, and what looks like a valid response. But in looking at the Media Library, there is a entry made, but the image is named something like ‘unnamed-file.c’ , and the image file is corrupt.

    I added the same Allow_Unfiltered and got the same result as you. I noticed in the media json reply there is a big hint:

    “media_type”: “file”,
    “mime_type”: “application/json”,

    The media_type should be image and the mime_type should be image/jpeg (in my case).

    In the body of my post I state the media_type and mime_type:
    {
    “date”: “2020-09-25T01:15:55”,
    “title” :”test.jpg”,
    “media_type”: “image”,
    “mime_type”: “image/jpeg”,
    “slug” : “test-logo”,
    “media_attachment”: “/9j/4AAQSkZJRgABAgECWAJYAAD/wAARCADUAZAD…”
    }

    It appears those parameters are being ignored. Which is why WP won’t let the file upload unless the filter is turned off.

    BTW, I have three sites. Two work. Only the one hosted by GoDaddy gives me this problem.

    I just remembered. There is a problem with this plug-in. See the post called “Mime type media”.

    You have to add a few lines to “wp-content/plugins/woo-media-api/class-woocommerce-media-api-controller.php”

    This worked for me.

    Thread Starter efoertsch

    (@efoertsch)

    Thanks for the tip. For reference, I searched for the post and found https://www.ads-software.com/support/topic/mime-type-image/. I passed it on to the server guy and we will give it a try. Stay tuned.

    Thread Starter efoertsch

    (@efoertsch)

    Getting there but not sure I am home yet. I can upload an image via Postman but
    1. Still get the warning html ‘<b>Warning</b>: Illegal string offset ‘rendered’ in…’ before what looks like a vaild response.
    2. The filename is apparently generated by the system like ‘T’, ‘T-1’
    3. And the url does not indicate it points to a jpg, e.g. ‘https://aaaaa.org/wp content/uploads/2020/10/T-2’ . Uploads via WooCommerce web site have url like ‘https://aaaaa.org/wp-content/uploads/2020/09/IMG_20200902_093420-1.jpg

    But I see the photo in media library. Going to carry on and add the urls to the product to see if the photos will display with the product OK.

    • This reply was modified 4 years, 5 months ago by efoertsch.
    • This reply was modified 4 years, 5 months ago by efoertsch.
    Thread Starter efoertsch

    (@efoertsch)

    OK. Here’s a bit of a summary that will hopefully save someone hours or days of spinning wheels.

    Got everything working for product and image uploads and Android app is being used in production. Here’s abbreviated WC setup I used.

    1. Created ‘Android App’ user.
    2. Created WC API key for ‘Android App’ and set access to ‘Read/Write’
    3. Applied FAST CGI fix and JSON basic auth – https://support.metalocator.com/en/articles/1654091-wp-json-basic-auth-with-fastcgi
    4. To keep WP from overwriting above changes also updated .htaccess file per https://perishablepress.com/stop-wordpress-changing-htaccess/.
    5. Installed WC Media API – https://www.ads-software.com/plugins/woo-media-api/
    6. Activated WC Media API Plugin
    7. Updated WC plugin file – https://www.ads-software.com/support/topic/mime-type-image/
    8. In my particular case every WC product is unique with it’s own SKU. To upload photos with image names related to the SKU, the SKU with appended photo sequence number were placed into the media.title.raw and media.title.rendered fields (Otherwise photos got names of ‘T’, ‘T-1’ as noted in prior post)
    9. But WC would duplicate the photos uploaded and assign an additional sequence number, i.e. if I uploaded image SKU-01.jpg it created a SKU-01-1.jpg and then associated SKU-01-1.jpg to the product. The original uploaded photo was then extraneous. So my app logic was:
    a. Upload product info to create new product
    b. Upload photo(s), use the returned source_url value in next step
    c. Associate photos to product by updating product, placing source_url value into product.image.src field
    d. Delete the original uploaded photos

    Hello @efoertsch Thank you very much for your solutions, I just have a question, where are the media.title.raw and media.title.rendered fields, I can’t find them, you can extend the explanation of those two fields, Thanks

    Thread Starter efoertsch

    (@efoertsch)

    (I think this is what happened. Haven’t thought about the code since I posted above what I ended up doing.)

    I found those fields via the returned JSON from the WP Media API after my initial success in uploading a photo via the WC Media API. The documentation from https://developer.www.ads-software.com/rest-api/reference/media/ is pretty sparse on details. Note the title field is defined as an object, but there are not details as to what is contained in the object. On examining the returned media JSON I saw those fields in the title field and gave them a try to see if the photos would retain the proper SKU-01 type naming convention – which they did.

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘rest_upload_sideload_error’ is closed to new replies.