staging.inyokaproject.org

Dieser Wiki Artikel

https://wiki.ubuntuusers.de/qt-fsarchiver/

ist nicht mehr aufrufbar.

Ich wollte diesen Artikel ergänzen. Die Vorschau anzeigen klappte nicht. Irgendwas ist an diesem Artikel schiefgelaufen. Ich hatte schon vor ca. 5 Wochen die gleichen Probleme.

Ich wollte lediglich mit einem Satz auf Kinetic hinweisen. Konnte auch keine Vorschau anzeigen und im Effekt geschah das gleiche wie jetzt: Der Artikel war nicht mehr aufrufbar.

Ich habe das auch im Forum angezeigt. Irgendjemand hat eingegriffen und die Seite war wieder erreichbar. Vielleicht kann wieder jemand helfen und vielleicht auch erkennen, wieso es diese Probleme gibt.

Mit dem "Schwester"-Artikel

https://wiki.ubuntuusers.de/fsarchiver/

gibt es keine Probleme.

Grüße aus Südbaden

Dieter_Ubuntu schrieb:

Dieser Wiki Artikel

https://wiki.ubuntuusers.de/qt-fsarchiver/

führt zu:

Fehler 502: Bad Gateway

Sowohl beim Aufruf als Internet-Link als auch als UU-Wiki-Link.

Der Artikel qt-fsarchiver ist wieder erreichbar. Danke

Aber: Ich klickte auf Bearbeiten, änderte nichts am Inhalt und wollte mir die Vorschau anzeigen lassen. Es geht nichts. Es werden keine Daten hochgeladen. Nach 5 Minuten oder länger habe ich abgebrochen.

Warum kann dieser Artikel nicht mehr bearbeitet werden? Hat er zu viele Anhänge (Photos)? Wäre natürlich ein Jammer, wenn ich den Artikel nicht weiter bearbeiten kann.

Grüß aus Südbaden

Hallo zusammen, als ich vorhin den Wiki-Artikel zum Dateibrowser Caja editiert habe, bin ich leider aus dem W-LAN geflogen. Gemerkt habe ich es daran, dass der Browser beim Abspeichern der Seite nicht mehr reagiert hat. Interessanterweise wird auf der Seite "Neueste Änderungen" mein Beitrag gleich dreimal angezeigt (vermutlich ausgelöst durch das dreimalige Drücken des "Speichern"-Knopfes). Beim Versuch, den Artikel aufzurufen, wird mir "Fehler 502: Bad Gateway" angezeigt. Mich würde interessieren, ob dieses Problem nur bei mir besteht oder ob die Seite generell nicht mehr erreichbar ist. Alle anderen getesteten Wiki-Seiten funktionieren einwandfrei. Besten Dank und einen guten Rutsch!

Hej,

wird sich hieran irgendwann noch etwas ändern? → https://wiki.ubuntuusers.de/Baustelle/Ubuntu_Installation_%E2%80%93_Gegen%C3%BCberstellung_der_Flavours/a/revision/992368/

Gruß black tencate

black_tencate schrieb:

wird sich hieran irgendwann noch etwas ändern? → https://wiki.ubuntuusers.de/Baustelle/Ubuntu_Installation_%E2%80%93_Gegen%C3%BCberstellung_der_Flavours/a/revision/992368/

Das dort nach x Minuten kein Bad Gatway mehr erscheint? Aktuell nicht, weil das eine alte Revision vom Artikel ist. Wenn die nach 30 Sekunden nicht rendert, erscheint diese gar nicht mehr. Deren Rohtext/Rohformat sollte man aber immer ansehen können.

Viele Grüße
Chris

Hej chris34,

chris34 schrieb:

...Aktuell nicht, weil das eine alte Revision vom Artikel ist. Wenn die nach 30 Sekunden nicht rendert, erscheint diese gar nicht mehr. Deren Rohtext/Rohformat sollte man aber immer ansehen können.

das sieht dann für mich so aus, als ob man künftig Seiten (❓ wegen vieler Bilder ❓) gar nicht mehr bearbeiten kann? (so wie beispielsweise Edgy Eft o.ä.)

Gruß black tencate

Hallo,

der Artikel https://wiki.ubuntuusers.de/Baustelle/Ubuntu_Installtion_EFI/ ist auch vom 502: Bad Gateway betroffen. Aktuell hat er 25 Anhänge mit einer Datengesamtmenge von ca. 1,5 MB. Zwischenzeitlich hat ich mal auf 23 reduziert - was für diesen Artikel das Minimum wäre - da ging es scheinbar mit dem Rendern gerade so.

Laut Wiki/Syntax (Abschnitt „Bilder“) liegt der Artikel damit um den Faktor 3 über dem Soll. Mit Optimierungen könnte ich die Datengesamtmenge maximal auf ca 1 MB drücken. Auf der anderen Seite rendert der Artikel Baustelle/Ubuntu Installation mit 50 Anhängen, die auch nicht besonders stark optimiert sind, scheinbar ohne Probleme.

Ist es tatsächlich so, dass im Moment nicht mehr als 500kb gerendert werden können oder könnt Ihr sonst irgendwelche aktuellen Angaben bezüglich Zahl der Anhänge und Gesamtdatenmenge machen?

Vielen lieben Dank!

LG, Newubunti

Hej,

ich bin zwar auch kein Fan von Bildern, besonders im Forum, aber manchmal ist es schon so: "Ein Bild sagt mehr als tausend Worte". Newubunti schrieb:

... Ist es tatsächlich so, dass ...

wenn dem so ist, wie wär 's mit

• *ironie ein* Ausweichen auf ein (sich auch) Wiki (nennendes) wie → Installationsanleitung_Linux_Mint_20 (da sind 30 Bilder wohl kein Problem) *ironie aus*

• in Fällen, wo es mit ausreichend wenig Bildern nicht geht, so eine Seite teilen in Teil A, B…

Gruß black tencate

black_tencate schrieb:

das sieht dann für mich so aus, als ob man künftig Seiten (❓ wegen vieler Bilder ❓) gar nicht mehr bearbeiten kann? (so wie beispielsweise Edgy Eft o.ä.)

Das hat mit der Anzahl an eingebundenen Bildern pro Wikiseite zu tun, ja (Also Anzahl an [[Bild( im Markup, nicht die Anzahl der Anhänge). Die SQL-Query dazu ist einfach seehr langsam. Ich meine auch eine Lösung zu kennen. Allerdings braucht das eine neue Django-Version (und an dem Update arbeitet aktuell auch niemand).

Bearbeiten sollte trotzdem gehen. Dass die neue Revision gespeichert ist, sieht man dann auch im Verlauf. Die Seite wird dann im maximal 24h auch wieder gerendert und ist dann erreichbar (inklusive dem Großrechner-Flair aus der Steinzeit, wo man mal nach einer Woche das Ergebnis erhalten hat 😈).

Ggf. bastel ich da auch mal ein „asynchrones“ Rendering. Dann würde nur noch so max. 5-10 Minuten ein 502 kommen. Ist halt auch wieder nur ein Workaround, weil die Vorschau wird dadurch bei solchen Seiten weiterhin nicht gehen. (bessere Lösung ist die Query effizienter zu machen)

Newubunti schrieb:

Ist es tatsächlich so, dass im Moment nicht mehr als 500kb gerendert werden können oder könnt Ihr sonst irgendwelche aktuellen Angaben bezüglich Zahl der Anhänge und Gesamtdatenmenge machen?

Wie oben schon geschrieben: Datengrößen von Bildern sollte nicht das Problem sein. Eher die Anzahl an [[Bild(. „Benchmark“ für die Grenze hast du ja auch gemacht:

Aktuell hat er 25 Anhänge […]. Zwischenzeitlich hat ich mal auf 23 reduziert - was für diesen Artikel das Minimum wäre - da ging es scheinbar mit dem Rendern gerade so.

Das der Artikel https://wiki.ubuntuusers.de/Baustelle/Ubuntu_Installtion_EFI/ aktuell erreichbar ist, liegt an dem oben erwähnten Mechanismus alle 24h.

Den Abschnitt in Wiki/Syntax (Abschnitt „Bilder“) kannte ich noch gar nicht. Ich denke die maximal 600 Pixel aus dem Abschnitte beziehen sich auf ein [[Bild(Bild.png, 200)]] Ob man dann noch eine Größenbeschränkung will, ist wohl eher Sache vom Wikiteam. (ggf. bring ich das direkt mal in der Diskussion zum Artikel an)
Pro Anhang beim Hochlanden haben wir noch eine Größenbeschränkung von 2,5MB. Denke damit sollte sich eigentlich arbeiten lassen. Hat aber mit dem Problem meiner Meinung nach eher weniger zu tun.

black_tencate schrieb:

wenn dem so ist, wie wär 's mit

• *ironie ein* Ausweichen auf ein (sich auch) Wiki (nennendes) wie → Installationsanleitung_Linux_Mint_20 (da sind 30 Bilder wohl kein Problem) *ironie aus*

Dafür scheint deren Software (nach Footer) 10 Jahre lang nicht aktualisiert worden zu sein 😇.

• in Fällen, wo es mit ausreichend wenig Bildern nicht geht, so eine Seite teilen in Teil A, B…

Kann man machen, ist aber halt auch eher ein „Workaround“.

Viele Grüße
Chris

Hej chris34,

chris34 schrieb:

... Bearbeiten sollte trotzdem gehen. Dass die neue Revision gespeichert ist, sieht man dann auch im Verlauf. Die Seite wird dann im maximal 24h auch wieder gerendert und ist dann erreichbar (inklusive dem Großrechner-Flair aus der Steinzeit, wo man mal nach einer Woche das Ergebnis erhalten hat 😈).

also sorry, aber wenn ich etwas an einer Seite ändere, dann möchte ich auch zeitnah anschauen können, wie genau das jetzt aussieht. 'ne Woche warten' , meinst Du so macht das Spaß.

*scnr*

Gruß black tencate

black_tencate schrieb:

chris34 schrieb:

... Bearbeiten sollte trotzdem gehen. Dass die neue Revision gespeichert ist, sieht man dann auch im Verlauf. Die Seite wird dann im maximal 24h auch wieder gerendert und ist dann erreichbar (inklusive dem Großrechner-Flair aus der Steinzeit, wo man mal nach einer Woche das Ergebnis erhalten hat 😈).

also sorry, aber wenn ich etwas an einer Seite ändere, dann möchte ich auch zeitnah anschauen können, wie genau das jetzt aussieht. 'ne Woche warten' , meinst Du so macht das Spaß.

Gut, als Feature zur Entschleunigung kann ich das also schon mal nicht verkaufen… 😀

Viele Grüße
Chris

Es gibt ja noch InyokaEdit.

Hallo,

Das hat mit der Anzahl an eingebundenen Bildern pro Wikiseite zu tun, ja (Also Anzahl an [[Bild ( im Markup, nicht die Anzahl der Anhänge). Die SQL-Query dazu ist einfach seehr langsam.

Zwei Fragen dazu:

1. Query = der SQL-Query der als Ergebnis die URL des Bilds zurückliefert, die dann in das <img>Tag im HTML verwendet wird?

2. Der Query ist doch nicht neu, oder? Sprich das Problem existiert schon seit X Monaten / Jahren? Die Seite mit den meisten Bildern im Wiki ist AFAIK Galerie. Der letzte Edit ist von August 2021, damals gab es zumindest keine Beschwerde. Kann es sein, dass das Problem da noch nicht existierte?

Gruß, noisefloor

Hej ChickenLipsRfun2eat,

ChickenLipsRfun2eat schrieb:

Es gibt ja noch InyokaEdit.

selbstverständlich verwende ich das, a b e r

1. hatte ich bis gestern mit dem Effekt "schwarzer Bildschirm" (codeseite) zu tun

   • so ganz exakt ist die Darstellung leider nicht (oder hat sich da was verbessert – war jetzt länger nicht mehr damit beschäftigt)

2. kann ich das hier local 'Sichtbare' z.B. an dieser Stelle nicht präsentieren.

Gruß black tencate