images were perfect on all browsers until yesterday afternoon - what is the fix or is this a dropbox issue?
We are rolling out a fix for issues with raw=1 and dl=1 links that started recently. Please try again and let us know if it's still not working.
@phantompower wrote: ...Is there an option to generate a dropbox link without the rlkey ...
...
Is there an option to generate a dropbox link without the rlkey ...
Hi @phantompower,
No, all new links follow that scheme already and no way back. It's not your issue actually. Something else changed recently. Let's hope it's not something intentional and will be fixed. We'll see...
@phantompower wrote: ...or another work around anyone can think of? ...
...or another work around anyone can think of? ...
The only thing I can think of is to put somewhere in your code a statement like:
l = /^https:\/\/www.dropbox.com/.test(l) ? l.replace('www.dropbox.com','dl.dropboxusercontent.com') : l
Here 'l' is a variable carrying the link. 😉
Hope this helps (to some extent at least).
Thanks - there seems to be a general consensus on other threads that this is an intentional move to restrict people using it as a streaming host. They may even monetise that facility down the line. Who knows. I've found another host removed that works really well for this purpose. It means completely rebuilding the MP3 library I've spent years creating but I can do that over time as and when I need the songs to be visible. (we only show around 40 MP3s at one time for a 3 month period and then we switch to new songs - they are learning resources for a choir)
I think this is a pretty poor business move on Dropbox's part by not even acknowledging what is going on. They obviously are aware of the issue, but can't be bothered to address their customer base?
This has sorted the problem for me.
@iggy097 wrote: ... They obviously are aware of the issue, but can't be bothered to address their customer base?
... They obviously are aware of the issue, but can't be bothered to address their customer base?
Hm...🤔 Really?
@iggy097, If so, that would be rather exception. 😁 This is NOT the first case when Dropbox staff learn from posts here in the forum that something changes. I think it's the same again. 🙂 It's something normal for Dropbox. 🤷
PS: Probably Dropbox management keeps regular support staff "on dark" so not slip some upcoming drawback movement out by mistake.
That means ALL of my previous hyperlinks everywhere on the web, on posts that are not longer editable, are dead and can never be repaired. If this is really the case, then dam you Dropbox!! This is the second time some stupid and unnecessary change made by you code monkeys who just cannot resist tinkering with things that work perfectly well, have borked all my hyperlinks.
You have one very, very angry customer here!!
I currently have image files running and being shared [to anyone with the link] from Dropbox to be used on our company's emails. They are shared via links with the customization of adding "raw=1" at the end of the links so they can work [as I found online that is your way around using them for multi-link access purposes].
Currently we aren't receiving access to those images no longer but instead of the default image logo. Something stopped working. Was it the permissions? Did I go over the bandwidth of how many times those links in our email signatures could be shared?
Looking for help and a resolution to replace or fix.
All product images on my website have been uploaded using the links and changing them from "dl=0" to "raw=1". All products were displayed correctly up until Friday afternoon. Now all I see are broken image icons on all product photos. For reference, I have well over 200 images that are now no longer working. I've tried viewing the site from Chrome, Microsoft Edge, Safari, and also tried incognito mode as well and it still shows broken image icons. Tried to sync all photos again with no luck. Below is a screenshot from this weekend.
Any suggestions?
@Здравко wrote: @iggy097 wrote: ... They obviously are aware of the issue, but can't be bothered to address their customer base? Hm...🤔 Really? @iggy097, If so, that would be rather exception. 😁 This is NOT the first case when Dropbox staff learn from posts here in the forum that something changes. I think it's the same again. 🙂 It's something normal for Dropbox. 🤷 PS: Probably Dropbox management keeps regular support staff "on dark" so not slip some upcoming drawback movement out by mistake.
To add to this a lot of the staff team are currently on holiday as its a public holiday over here where they are based. Plus given they dont work over weekends doesnt help.
@Photo O. wrote: You have one very, very angry customer here!!
Please, please take this as a lesson to NOT use Dropbox for things its not intended for - i.e. a hosting service. It simply isnt designed for this and any hosting applications have almost worked 'by accident' rather than intentional. This is not the first, second or even third time this has happened and I can pretty much guarantee it will happen again.
Changing "https://www.dropbox.com" to "https://dl.dropboxusercontent.com" on every single image should make them work again. I did so with a script for more than 500 audios a while ago and everything is back to normal.
@Mark wrote:... any hosting applications have almost worked 'by accident' rather than intentional. ...
... any hosting applications have almost worked 'by accident' rather than intentional. ...
Hm...🤔 Strange! In such a case there is some documentation, describing embedding, existing almost 'by accident' as seems. 😀
@lisadbx wrote: We are rolling out a fix for issues with raw=1 and dl=1 links that started recently. Please try again and let us know if it's still not working.
Hi @lisadbx,
Almost, but not exactly! You have fixed the HTML redirection, but the other addition is still there! What about CORS?! 😉
Hope this will be fixed too.
My www.dropbox.com/scl/fi/....?raw=1 urls seem to be working again for a few minutes now. Both images and PDF files.Did Dropbox reverse the change?
They started (HTML redirect fixed), but still not embeddable - CORS.
@Здравко Interesting, I don't have any CORS issues with ?raw=1 urls. I tested JPG, MP4, MP3 and PDF file formats embedded directly into a page using iFrame inChrome, Edge and FireFox.Perhaps you have a different use case?
I just checked and there is still no any CORS related header declaration in the response! Such a link CANNOT be embedded without such a declaration - only can be fetched alone.
On try to embed something:
Confirming that new shared images using RAW=1 are working for me in a public message forum. I haven't checked yet if older images are working.
Hopefully, this means they fixed the problem and that this wasn't an intentional policy change.
Okay, back to waiting and seeing now. 😺
Update: I checked older images in the forum, and they seem to be displaying correctly, too.
Looks like the older ones are working for me as well again.
All good here, lisabx.
New shared images and old ones are working as they should. Please thank the Dropbox Team for me! 😺
Dropbox states below they have rolled out a fix for the raw=1 link problem.
Hmm I am able to embed with both raw=1 and https://dl.dropboxusercontent.com
We reverted the breaking change that was rolled out around 5/3, and I don't think there are any CORS related changes recently.
Perhaps you have a new browser setting?
Another know issue that prevents direct download is if the link is not public.
It works, already as I said in other thread.
Hi lisadbxyes, it is working fine now for both dl=1 and raw=1Many thanks
