### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [29. August 2019 um 07:39 UTC](https://meta.discourse.org/t/azure-blob-storage-plugin/79392/71 "2019-08-29T07:39:10Z")
Also… ähm… wie sollte ich diese Version stattdessen mit dem PR ziehen?
Alternativ: Wie kann ich die tatsächliche URL aus der `short-url` erhalten? Gibt es irgendwo eine Mapping-Tabelle?
Denn aktuell kann kein Anhang heruntergeladen werden, und das ist frustrierend…
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [29. August 2019 um 08:51 UTC](https://meta.discourse.org/t/azure-blob-storage-plugin/79392/72 "2019-08-29T08:51:57Z")
OK, das Ziehen von
```plaintext
git clone --single-branch --branch implement-url-for https://github.com/localjo/discourse-azure-blob-storage
```
funktioniert jetzt einwandfrei. Ich melde mich nach weiteren Tests.
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [29. August 2019 um 09:30 UTC](https://meta.discourse.org/t/azure-blob-storage-plugin/79392/73 "2019-08-29T09:30:35Z")
Dieses Problem taucht seit einigen Tagen immer wieder auf, was meiner Meinung nach mit diesem Issue zusammenhängen könnte:
```plaintext
/var/www/discourse/lib/file_store/base_store.rb:148:in `not_implemented'
/var/www/discourse/lib/file_store/base_store.rb:42:in `download_url'
/var/www/discourse/lib/cooked_post_processor.rb:386:in `add_lightbox!'
/var/www/discourse/lib/cooked_post_processor.rb:350:in `convert_to_link!'
/var/www/discourse/lib/cooked_post_processor.rb:682:in `block in post_process_images'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/nokogiri-1.10.4/lib/nokogiri/xml/node_set.rb:238:in `block in each'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/nokogiri-1.10.4/lib/nokogiri/xml/node_set.rb:237:in `upto'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/nokogiri-1.10.4/lib/nokogiri/xml/node_set.rb:237:in `each'
/var/www/discourse/lib/cooked_post_processor.rb:679:in `post_process_images'
/var/www/discourse/lib/cooked_post_processor.rb:42:in `block in post_process'
/var/www/discourse/lib/distributed_mutex.rb:31:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:27:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:27:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:12:in `synchronize'
/var/www/discourse/lib/cooked_post_processor.rb:38:in `post_process'
/var/www/discourse/app/jobs/regular/process_post.rb:26:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rails_multisite-2.0.7/lib/rails_multisite/connection_management.rb:63:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:192:in `execute_job'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:165:in `block (2 levels) in process'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/middleware/chain.rb:128:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/middleware/chain.rb:130:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/middleware/chain.rb:133:in `invoke'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:164:in `block in process'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:137:in `block (6 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/job_retry.rb:109:in `local'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:136:in `block (5 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq.rb:37:in `block in '
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:132:in `block (4 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:250:in `stats'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:127:in `block (3 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/job_logger.rb:8:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:126:in `block (2 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/job_retry.rb:74:in `global'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:125:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/logging.rb:48:in `with_context'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/logging.rb:42:in `with_job_hash_context'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:124:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:163:in `process'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:83:in `process_one'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/processor.rb:71:in `run'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/util.rb:16:in `watchdog'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-5.2.7/lib/sidekiq/util.rb:25:in `block in safe_thread'
```
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [29. August 2019 um 09:35 UTC](https://meta.discourse.org/t/azure-blob-storage-plugin/79392/74 "2019-08-29T09:35:40Z")
`download_url` muss eine weitere Funktion sein, die vom Azure Blob-Plugin nicht implementiert ist.
EDIT:
OK, die Auswirkungen des fehlenden `download_url` zeigen sich jetzt.
- Der Bildnachverarbeitungsjob schlägt weiterhin fehl
- Keine Bilder werden optimiert
- Keine Bilder werden als Lightbox angezeigt
- Die Vorschau der Themenliste kann das Vorschaubild nicht erfassen
Könnte eine nette Seele (@gerhard?) bitte `download_url` implementieren?
EDIT 2:
@gerhard, kann das so einfach sein, wie folgendes einzufügen:
```plaintext
def download_url(upload)
return unless upload
"#{upload.short_path}"
end
```
Ich würde gerne das Repository klonen, um es zu testen, aber Discourse ist mittlerweile so ein riesiges Ungeheuer geworden, dass ich nicht sicher bin, ob dabei nichts kaputtgeht!
EDIT 3:
Ich habe den folgenden PR an `localjo/discourse-azure-blob-storage` gesendet:
[https://github.com/localjo/discourse-azure-blob-storage/pull/1](https://github.com/localjo/discourse-azure-blob-storage/pull/1)
Es scheint, als würde dies die meisten sichtbaren Probleme ohne erkennbare negative Auswirkungen beheben…
---
### Author:  [@rainmanjam](https://meta.discourse.org/u/rainmanjam)
#### Post date: [23. Dezember 2019 um 18:59 UTC](https://meta.discourse.org/t/azure-blob-storage-plugin/79392/75 "2019-12-23T18:59:18Z")
Ist es möglich, einige Änderungen vorzunehmen, damit Discourse Azure-Blob-Speicher für Backups verwenden kann?
---
### Author:  [@NotAnonymous](https://meta.discourse.org/u/NotAnonymous)
#### Post date: [9. Januar 2020 um 21:55 UTC](https://meta.discourse.org/t/azure-blob-storage-plugin/79392/76 "2020-01-09T21:55:24Z")
Ich habe denselben Fehler. Wurde dein PR übernommen? Falls nicht, könntest du die vorgenommenen Änderungen teilen, damit ich prüfen kann, ob ich sie auf unserer Website umsetzen kann? Ich kann nicht auf die angezeigte GitHub-URL zugreifen.
Vielen Dank!
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [31. Januar 2020 um 09:41 UTC](https://meta.discourse.org/t/azure-blob-storage-plugin/79392/77 "2020-01-31T09:41:00Z")
Das Basis-Repository scheint verschwunden zu sein.
Du kannst versuchen, von hier zu pullen:
```plaintext
git clone --single-branch --branch implement-url-for https://github.com/schungx/discourse-azure-blob-storage.git
```
Hier sind meine Änderungen enthalten. Allerdings glaube ich, dass etwas anderes kaputtgegangen ist, was ich noch nicht behoben habe.
Ein PR, den ich zum offiziellen Repository eingereicht habe:
>
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [31. Januar 2020 um 11:25 UTC](https://meta.discourse.org/t/azure-blob-storage-plugin/79392/78 "2020-01-31T11:25:33Z")
Es scheint, als gäbe es kürzlich massive Änderungen an der S3-Speicherengine (die `azure-blob-storage` \_übernimmt\*), um gesicherte Uploads zu verarbeiten.
Dabei funktioniert die Verarbeitung von Koch-Beiträgen nicht mehr richtig. Es wird folgendes HTML generiert:
```plaintext
```
Beachten Sie Folgendes:
1. Das Attribut `src` ist auf den Link zum Thema statt auf die URL des Bildes gesetzt.
2. Die URLs im `srcset`-Attribut verschwinden alle (wahrscheinlich werden Leerzeichen zurückgegeben).
3. Keine der optimierten Bilder wird tatsächlich generiert (wahrscheinlich aufgrund der leeren URLs).
Dies ist ein HTML-Beispiel, das einwandfrei funktioniert:
```plaintext
```
Bei diesem Bild funktionierte alles einwandfrei.
Der Code zur Generierung der optimierten Bilder befindet sich in `UrlHelper.cook_url`, der erhebliche Änderungen erfahren hat, um gesicherte Uploads nach S3 zu verarbeiten.
---
### Author:  [@NotAnonymous](https://meta.discourse.org/u/NotAnonymous)
#### Post date: [31. Januar 2020 um 14:40 UTC](https://meta.discourse.org/t/azure-blob-storage-plugin/79392/80 "2020-01-31T14:40:43Z")
Danke für die Info, ich habe es basierend auf deinen Kommentaren schließlich selbst behoben.
Bei den jüngsten Änderungen habe ich das auch festgestellt. Das war eine einfache Lösung: Du musst einfach den sicheren (4.) Parameter zur optimize-Funktion im Plugin hinzufügen. Ich bin mir nicht sicher, ob weitere Änderungen erforderlich sind, aber damit ist das von dir festgestellte unmittelbare Problem behoben.
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [31. Januar 2020 um 14:43 UTC](https://meta.discourse.org/t/azure-blob-storage-plugin/79392/81 "2020-01-31T14:43:26Z")
Seit dem Upgrade vor etwa vier Tagen ist bei allen `optimized_images` das Feld `url` auf `null` gesetzt, anstatt die korrekte Bild-URL zu enthalten.
Dies führt dazu, dass Discourse auf schreckliche Weise versagt, denn `upload.thumbnail` gibt zwar einen gültigen Datensatz zurück, aber die `url` ist `null`. Sollte es nicht irgendwo eine Prüfung geben, die dies abfängt?
Das bedeutet, dass diese Zeile:
>
`img["src"]` auf `null` setzt. Ich bin mir sicher, dass das niemanden glücklich macht.
Alle Bilder in `srcset` sind leer gesetzt, weil:
>
t.url am Ende `null` ist.
Dann landet alles genau so, wie es ist. Ich bin mir ziemlich sicher, dass irgendwo im weiteren Verlauf, wenn `img["src"]` `null` ist, es auf die URL des Themas selbst gesetzt wird.
Der Schuldige ist also die Tatsache, dass optimierte Bilder NICHT erstellt werden (aber die Datensätze mit `null`-`url` dennoch angelegt werden). Es gibt keine Fehlermeldungen.
Jeder Beitrag mit Bildern, die gültige optimierte Bilder (mit gültiger `url`) haben, funktioniert weiterhin einwandfrei, auch beim erneuten Erstellen des HTML.
Jedes Bild, das zuvor hochgeladen wurde (mit gültigen optimierten Bildern), funktioniert auch beim erneuten Hochladen weiterhin einwandfrei.
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [31. Januar 2020 um 14:45 UTC](https://meta.discourse.org/t/azure-blob-storage-plugin/79392/82 "2020-01-31T14:45:14Z")
> [@NotAnonymous](#):
>
> Du musst lediglich den sicheren (4.) Parameter zur optimize-Funktion im Plugin hinzufügen.
EDIT: OK, ich habe `secure: false` zu `store_optimized_image` hinzugefügt, und alles scheint jetzt einwandfrei zu funktionieren.
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [31. Januar 2020 um 16:34 UTC](https://meta.discourse.org/t/azure-blob-storage-plugin/79392/83 "2020-01-31T16:34:14Z")
Ich bin immer noch der Meinung, dass etwas unternommen werden muss, um Situationen zu handhaben, in denen `OptimizedImage` einen `url`-Wert von `""` (nicht `null`) hat.
Dies wird _immer noch_ passieren, scheint aber nur bei bestimmten Bildern und nicht bei anderen aufzutreten. Bei bestimmten Bildern dieser Art schlägt die Erstellung kleiner Versionen beim Verwenden des `Topics List Preview`-Plugins fehl und hinterlässt somit Datensätze mit `url=""`.
Diese tauchen in der Regel nicht auf, da responsive Bilder erst ab der 1x-Mindestgröße beginnen und standardmäßig bis zur 2x-Größe hochskalieren. Daher werden die kleinen optimierten Bilder nie erreicht. Dennoch ist es besorgniserregend, dass dies eines Tages zu Problemen führen könnte…
Das bedeutet nicht, dass kein Vorschaubild in der Themenliste angezeigt wird, wenn das `Topics List Preview`-Plugin installiert ist.
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [22. Mai 2020 um 05:50 UTC](https://meta.discourse.org/t/azure-blob-storage-plugin/79392/84 "2020-05-22T05:50:32Z")
Beim Upgrade von Discourse ist ein Fehler aufgrund eines `faraday`-Konflikts aufgetreten:
```plaintext
I, [2020-05-22T05:46:54.081847 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
rake aborted!
Gem::ConflictError: Unable to activate faraday_middleware-0.11.0, because faraday-1.0.1 conflicts with faraday (>= 0.7.4, < 1.0)
/var/www/discourse/lib/plugin_gem.rb:20:in `load'
/var/www/discourse/lib/plugin/instance.rb:635:in `gem'
/var/www/discourse/plugins/discourse-azure-blob-storage/plugin.rb:10:in `activate!'
/var/www/discourse/lib/plugin/instance.rb:541:in `instance_eval'
/var/www/discourse/lib/plugin/instance.rb:541:in `activate!'
lib/discourse.rb:224:in `block in activate_plugins!'
lib/discourse.rb:221:in `each'
lib/discourse.rb:221:in `activate_plugins!'
/var/www/discourse/config/application.rb:297:in `block in '
/var/www/discourse/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/var/www/discourse/config/application.rb:296:in `'
/var/www/discourse/config/application.rb:65:in `'
/var/www/discourse/config/application.rb:64:in `'
/var/www/discourse/Rakefile:7:in `require'
/var/www/discourse/Rakefile:7:in `'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rake-13.0.1/exe/rake:27:in `'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `'
```
Verwendet `discourse-azure-blob-storage` `faraday`?
---
### Author:  [@itsbhanusharma](https://meta.discourse.org/u/itsbhanusharma)
#### Post date: [22. Mai 2020 um 05:57 UTC](https://meta.discourse.org/t/azure-blob-storage-plugin/79392/85 "2020-05-22T05:57:32Z")
Ja, das tut es
>
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [22. Mai 2020 um 06:38 UTC](https://meta.discourse.org/t/azure-blob-storage-plugin/79392/87 "2020-05-22T06:38:15Z")
Großartig.
>
Damit ist es behoben.
---
### Author:  [@meglio](https://meta.discourse.org/u/meglio)
#### Post date: [8. August 2020 um 14:08 UTC](https://meta.discourse.org/t/azure-blob-storage-plugin/79392/88 "2020-08-08T14:08:44Z")
Ist dieses Plugin immer noch defekt?
Nutzt jemand dieses Plugin aktuell für Uploads zu Azure Blob Storage? Wenn ja, ist es stabil? Bitte teilen Sie Ihre Erfahrungen mit.
[Vorherige Seite](https://meta.discourse.org/t/azure-blob-storage-plugin/79392.md?page=3)
[Nächste Seite](https://meta.discourse.org/t/azure-blob-storage-plugin/79392.md?page=5)