Wiki-Artikel mit eingefügten Bildern nicht mehr zu bearbeiten

moe 2017-01-20 08:52:18 UTC #1

Hallo,

wenn ich ein Wiki-Dokument anlege und dort per Copy and Paste ein oder
mehrere Bilder einfüge, kann ich zwar das Dokument noch speichern und
auch aufrufen. Leider kann ich es aber nicht mehr bearbeiten weil sich
der Browser totlädt…

Bei der 14.3er Version trat das auch schon auf, aber erst wenn es
mehrere Bilder in einem Artikel sind.
Bei der 16.1 reicht schon ein Bild aus. Das muss nicht mal groß sein
ein Teil eines Screeshots z.B.

Ich wollte das auf dem Trial-Account von Stylite testen aber da gibt es
leider kein Wiki. ;((

Moe

Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

RalfBecker 2017-01-23 08:03:06 UTC #2

Hi Moe,

Hallo,

wenn ich ein Wiki-Dokument anlege und dort per Copy and Paste ein oder
mehrere Bilder einfüge, kann ich zwar das Dokument noch speichern und
auch aufrufen. Leider kann ich es aber nicht mehr bearbeiten weil sich
der Browser totlädt…

Bei der 14.3er Version trat das auch schon auf, aber erst wenn es
mehrere Bilder in einem Artikel sind.
Bei der 16.1 reicht schon ein Bild aus. Das muss nicht mal groß sein
ein Teil eines Screeshots z.B.

Ich wollte das auf dem Trial-Account von Stylite testen aber da gibt es
leider kein Wiki. ;((

Hab’ Dich auf einen anderen Tree gezogen und Wiki installiert.

Ralf

PS.: Ist nicht mehr Stylite sondern EGroupware GmbH

Ralf Becker
EGroupware GmbH [www.egroupware.org]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 631 31657-0

moe 2017-01-23 08:20:40 UTC #3

Guten Morgen Ralf,

Hi Moe,
Hab’ Dich auf einen anderen Tree gezogen und Wiki installiert.

Danke, habe es getestet … gleiches Problem.
Bildausschnitt per Copy and Paste auf einer Wiki-Seite eingefügt.
Speichern -> OK
Dokument erneut bearbeiten -> lädt 90 Sekunden …dann weiße Seite.
Das richt nach einem Timeout, oder?

Ralf

PS.: Ist nicht mehr Stylite sondern EGroupware GmbH

Ist noch so “drin”

Moe

Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

RalfBecker 2017-01-23 08:25:02 UTC #4

Moin,

Guten Morgen Ralf,

Hi Moe,
Hab’ Dich auf einen anderen Tree gezogen und Wiki installiert.
Danke, habe es getestet … gleiches Problem.
Bildausschnitt per Copy and Paste auf einer Wiki-Seite eingefügt.
Speichern -> OK
Dokument erneut bearbeiten -> lädt 90 Sekunden …dann weiße Seite.
Das richt nach einem Timeout, oder?

Glaube ich nicht, mach’ einen Bug Report und Birgit kann danach schauen.

Ralf

Ralf

PS.: Ist nicht mehr Stylite sondern EGroupware GmbH
Ist noch so “drin”

Moe

–
Ralf Becker
EGroupware GmbH [www.egroupware.org]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 631 31657-0

moe 2017-01-24 12:25:05 UTC #5

Hallo Ralf,

Moin,

Glaube ich nicht, mach’ einen Bug Report und Birgit kann danach schauen.

Ralf

Ich hatte schon vor über einem Jahr einen Bugreport dazu gemacht.
Musste mich erstmal wieder erinnern…
Es ist die Ticketnummer #12170
Lt. Birgit wolltest du es dir mal ansehen…ist wohl untergegangen.

Das Problem scheint zu sein, dass die Bilder in der DB gespeichert
werden. Und das ist wahrscheinlich einfach zuviel…
Aber die Bilder erst im Dateimanager zu speichern wäre sehr umständlich.

So mache ich z.B. einen Screenshot (schneide ihn evtl. noch zu)
und füge ihn einfach per Strg-V in den Wikiartikel ein.

Um das über den Dateimanager zu machen. müsste ich

die Datei erstmal lokal speichern. (mind. 4-5 Klicks)
die Datei im Dateimanager hochladen (mind. 4-5 Klicks)
die Datei im Wikiartikel einfügen (8-10 Klicks)

In der Summe sind das für jedes Bild (oder Ausschnitt davon)
mindestens 16-20 Mouseklicks, die ich mit einer einzigen TastenKombi
erledigen kann. In der Summe würde es dadurch mind. 10 mal so lange
dauern. Es wäre toll wenn sich das ändern ließe.

Moe

Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

RalfBecker 2017-01-25 08:45:22 UTC #6

Hi Moe,

Hallo Ralf,

Moin,

Glaube ich nicht, mach’ einen Bug Report und Birgit kann danach schauen.

Ralf
Ich hatte schon vor über einem Jahr einen Bugreport dazu gemacht.
Musste mich erstmal wieder erinnern…
Es ist die Ticketnummer #12170
Lt. Birgit wolltest du es dir mal ansehen…ist wohl untergegangen.

Nein, Birgit hat es auf ein neues Startdatum von 25. Jan, sprich heute,
gesetzt.

Das Problem scheint zu sein, dass die Bilder in der DB gespeichert
werden. Und das ist wahrscheinlich einfach zuviel…
Aber die Bilder erst im Dateimanager zu speichern wäre sehr umständlich.

So mache ich z.B. einen Screenshot (schneide ihn evtl. noch zu)
und füge ihn einfach per Strg-V in den Wikiartikel ein.

Um das über den Dateimanager zu machen. müsste ich

die Datei erstmal lokal speichern. (mind. 4-5 Klicks)

die Datei im Dateimanager hochladen (mind. 4-5 Klicks)

die Datei im Wikiartikel einfügen (8-10 Klicks)

In der Summe sind das für jedes Bild (oder Ausschnitt davon)
mindestens 16-20 Mouseklicks, die ich mit einer einzigen TastenKombi
erledigen kann. In der Summe würde es dadurch mind. 10 mal so lange
dauern. Es wäre toll wenn sich das ändern ließe.

Ok, ich erinnere mich. Problem ist das wir für andere Apps die am
Linking vollständig Teilnehmen die Bilder automatisch zu dem Eintrag
speichern und dann den Link im CK-Editor austauschen. Wiki nimmt nur so
halb im Linking teil, weil es keine richtigen ID’s gibt sondern nur
Namen der Wiki-Seiten. Leider kann der Name bis zu 80 Zeichen lang sein,
während die Link Tabelle nur IDs mit max. 64 Zeichen erlaubt. Für den
Dateimanager ist das aber egal, da wir dort längere Dateinamen erlauben.

Sprich wir könnten das Wiki so erweitern, das wir beim Bearbeiten der
Seite einen Link bzw. zumindestens Attachment Tab einbauen und dann die
orginal Funktionalität der anderen Apps verwenden. Könnte gehen …

Frage ist halt wann und ob wir ins Wiki noch Entwicklerresourcen stecken
wollen.

Ralf

Yann_Lehmann 2017-01-25 09:11:36 UTC #7

Frage ist halt wann und ob wir ins Wiki noch Entwicklerresourcen stecken
wollen.

Das würde ich sehr befürworten :-).

Hier haben wir erst letztes Jahr begonnen das Wiki zu brauchen. Ich bin
der Meinung dass es als Teil von eGroupware sehr viel Möglichkeiten
bietet, z. B. für Anleitungen (Benutzer müssen sich nur an einer
Oberfläche gewöhnen).

Besten Dank für Eure Bemühungen
Yann

Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

moe 2017-01-25 10:51:54 UTC #8

hi Ralf,

Hi Moe,
Ok, ich erinnere mich. Problem ist das wir für andere Apps die am
Linking vollständig Teilnehmen die Bilder automatisch zu dem Eintrag
speichern und dann den Link im CK-Editor austauschen. Wiki nimmt nur so
halb im Linking teil, weil es keine richtigen ID’s gibt sondern nur
Namen der Wiki-Seiten. Leider kann der Name bis zu 80 Zeichen lang sein,
während die Link Tabelle nur IDs mit max. 64 Zeichen erlaubt. Für den
Dateimanager ist das aber egal, da wir dort längere Dateinamen erlauben.

Sprich wir könnten das Wiki so erweitern, das wir beim Bearbeiten der
Seite einen Link bzw. zumindestens Attachment Tab einbauen und dann die
orginal Funktionalität der anderen Apps verwenden. Könnte gehen …

Frage ist halt wann und ob wir ins Wiki noch Entwicklerresourcen stecken
wollen.

Ralf

vielen Dank für die Erläuterung. Aber nicht dass wir uns missverstehen.
Ich möchte die Bilder im Wiki-Artikel in den Text sichtbar einbinden und
nicht wie z.B. beim Infolog als Anhang verlinken.
Wir nutzen das genauso wie Yann Lehmann für Anleitungen usw. und da
macht sich das einfach Super wenn man die Bilder einfach vom Clipboard
direkt “reinpasten” kann.

Moe

Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

RalfBecker 2017-01-25 11:35:18 UTC #9

Hi Moe,

hi Ralf,

Hi Moe,
Ok, ich erinnere mich. Problem ist das wir für andere Apps die am
Linking vollständig Teilnehmen die Bilder automatisch zu dem Eintrag
speichern und dann den Link im CK-Editor austauschen. Wiki nimmt nur so
halb im Linking teil, weil es keine richtigen ID’s gibt sondern nur
Namen der Wiki-Seiten. Leider kann der Name bis zu 80 Zeichen lang sein,
während die Link Tabelle nur IDs mit max. 64 Zeichen erlaubt. Für den
Dateimanager ist das aber egal, da wir dort längere Dateinamen erlauben.

Sprich wir könnten das Wiki so erweitern, das wir beim Bearbeiten der
Seite einen Link bzw. zumindestens Attachment Tab einbauen und dann die
orginal Funktionalität der anderen Apps verwenden. Könnte gehen …

Frage ist halt wann und ob wir ins Wiki noch Entwicklerresourcen stecken
wollen.

Ralf
vielen Dank für die Erläuterung. Aber nicht dass wir uns missverstehen.
Ich möchte die Bilder im Wiki-Artikel in den Text sichtbar einbinden und
nicht wie z.B. beim Infolog als Anhang verlinken.
Wir nutzen das genauso wie Yann Lehmann für Anleitungen usw. und da
macht sich das einfach Super wenn man die Bilder einfach vom Clipboard
direkt “reinpasten” kann.

Ja, wenn wir sie nicht im Text speichern sollen (weil der dann zu groß
wird), müssen wir sie irgendwo anders speichern und was sich da anbietet
ist als Attachment wie bei allen Apps üblich. Dann siehst Du die Bilder
natürlich auch als Attachment, das stört ja doch nicht.

Wichtig ist Dir doch das es einfach zu bedienen ist und Du halt keine
Speicherort explizit auswählen musst …

Ralf

moe 2017-01-25 13:39:42 UTC #10

hi Ralf,

vielen Dank für die Erläuterung. Aber nicht dass wir uns missverstehen.
Ich möchte die Bilder im Wiki-Artikel in den Text sichtbar einbinden und
nicht wie z.B. beim Infolog als Anhang verlinken.
Wir nutzen das genauso wie Yann Lehmann für Anleitungen usw. und da
macht sich das einfach Super wenn man die Bilder einfach vom Clipboard
direkt “reinpasten” kann.

Ja, wenn wir sie nicht im Text speichern sollen (weil der dann zu groß
wird), müssen wir sie irgendwo anders speichern und was sich da anbietet
ist als Attachment wie bei allen Apps üblich. Dann siehst Du die Bilder
natürlich auch als Attachment, das stört ja doch nicht.

Wichtig ist Dir doch das es einfach zu bedienen ist und Du halt keine
Speicherort explizit auswählen musst …

Ralf

Ja, genau es sollte möglichst einfach sein ein Bild einzufügen (per
Strg-V aus dem Clipboard). Ich meine nicht per Drag´n´drop wie bei den
anderen Apps.
Aber das Bild muss im Artikel natürlich auch angezeigt werden, also
nicht nur ein Link zum Attachement mit dem Bild sondern das Bild selbst
muss im Artikel zu sehen sein. Wenn es zusätzlich als Anhang angezeigt
wird ist das nicht schlimm, aber vielleicht überflüssig.

Gruß Moe

Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

moe 2017-01-28 10:36:47 UTC #11

Hallo Ralf,

könntest du mir vielleicht hierzu und eine kurze Rückmeldung geben:

ob ich dich richtig verstanden habe, dass das Bild selbst dann
trotzdem im Artikel (nicht nur als Anhang) anzeigt würde?
ob das mittelfristig auf der Agenda landet?

Moe

Ja, wenn wir sie nicht im Text speichern sollen (weil der dann zu groß
wird), müssen wir sie irgendwo anders speichern und was sich da anbietet
ist als Attachment wie bei allen Apps üblich. Dann siehst Du die Bilder
natürlich auch als Attachment, das stört ja doch nicht.

Wichtig ist Dir doch das es einfach zu bedienen ist und Du halt keine
Speicherort explizit auswählen musst …

Ralf
Ja, genau es sollte möglichst einfach sein ein Bild einzufügen (per
Strg-V aus dem Clipboard). Ich meine nicht per Drag´n´drop wie bei den
anderen Apps.
Aber das Bild muss im Artikel natürlich auch angezeigt werden, also
nicht nur ein Link zum Attachement mit dem Bild sondern das Bild selbst
muss im Artikel zu sehen sein. Wenn es zusätzlich als Anhang angezeigt
wird ist das nicht schlimm, aber vielleicht überflüssig.

Gruß Moe

Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

RalfBecker 2017-01-31 09:34:40 UTC #12

Hi Moe und Yann,

wir sind jetzt ein ganzes Stück weiter gekommen mit dem Wiki

Wiki verwendet jetzt die 16.1 Api und eTemplate2.

Dadurch geht das Einfügen und “reinziehen” von Bildern jetzt. Die Bilder
werden in einem Verzeichnis im VFS gespeichert, das jeder in seinen
Einstellungs festlegen kann. Wichtig ist natürlich, dass alle die den
Artikel sehen sollen, auch auf die Bilder Zugriffen haben sollten.
Deswegen haben wir als Vorgabe /home/Default gewählt. Wie üblich kann
man als Admin die Vorgabe ändern oder ein Verzeichnis erzwingen …

Ab dem nächsten Paket wird dann auch die Installation des Wiki nicht
mehr das egroupware-epl-compat (phpgwapi und etemplate Verzeichnis)
erfordern. Wir werden Wiki allerdings nicht in die per Default
installieren Apps aufnehmen, da sich am Wiki Code / Parser (noch) nichts
geändert hat, sprich immer noch uralter, unschöner Code.

Falls Du eine Installation per Git hast, bitte mal updaten und testen
(master oder 16.1 Branch). Ansonsten halt auf das nächste Paket warten …

Ralf

Hallo Ralf,

könntest du mir vielleicht hierzu und eine kurze Rückmeldung geben:

ob ich dich richtig verstanden habe, dass das Bild selbst dann
trotzdem im Artikel (nicht nur als Anhang) anzeigt würde?

ob das mittelfristig auf der Agenda landet?

Moe

Ja, wenn wir sie nicht im Text speichern sollen (weil der dann zu groß
wird), müssen wir sie irgendwo anders speichern und was sich da anbietet
ist als Attachment wie bei allen Apps üblich. Dann siehst Du die Bilder
natürlich auch als Attachment, das stört ja doch nicht.

Wichtig ist Dir doch das es einfach zu bedienen ist und Du halt keine
Speicherort explizit auswählen musst …

Ralf
Ja, genau es sollte möglichst einfach sein ein Bild einzufügen (per
Strg-V aus dem Clipboard). Ich meine nicht per Drag´n´drop wie bei den
anderen Apps.
Aber das Bild muss im Artikel natürlich auch angezeigt werden, also
nicht nur ein Link zum Attachement mit dem Bild sondern das Bild selbst
muss im Artikel zu sehen sein. Wenn es zusätzlich als Anhang angezeigt
wird ist das nicht schlimm, aber vielleicht überflüssig.

Gruß Moe

Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

moe 2017-01-31 14:50:36 UTC #13

Hi Ralf,

danke, klingt ja sehr vielversprechend!
Ich muss dann wohl auf das nächste Paket warten…

Gruß Moe

Hi Moe und Yann,

wir sind jetzt ein ganzes Stück weiter gekommen mit dem Wiki

Wiki verwendet jetzt die 16.1 Api und eTemplate2.

Dadurch geht das Einfügen und “reinziehen” von Bildern jetzt. Die Bilder
werden in einem Verzeichnis im VFS gespeichert, das jeder in seinen
Einstellungs festlegen kann. Wichtig ist natürlich, dass alle die den
Artikel sehen sollen, auch auf die Bilder Zugriffen haben sollten.
Deswegen haben wir als Vorgabe /home/Default gewählt. Wie üblich kann
man als Admin die Vorgabe ändern oder ein Verzeichnis erzwingen …

Ab dem nächsten Paket wird dann auch die Installation des Wiki nicht
mehr das egroupware-epl-compat (phpgwapi und etemplate Verzeichnis)
erfordern. Wir werden Wiki allerdings nicht in die per Default
installieren Apps aufnehmen, da sich am Wiki Code / Parser (noch) nichts
geändert hat, sprich immer noch uralter, unschöner Code.

Falls Du eine Installation per Git hast, bitte mal updaten und testen
(master oder 16.1 Branch). Ansonsten halt auf das nächste Paket warten …

Ralf

Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

moe 2017-02-02 14:47:15 UTC #14

Hallo Ralf,

habe es gerade mal im Trial gestet … kanns bei mir wegen dem fehlenden
Paket ja noch nicht testen. funktionierte einwandfrei!
Sehr gute Arbeit!
Das einzige was mich verwunderte:
Als Pfad für die Uploads ist ja /home/Default eingestellt.
Dort liegt dann aber nix drin… ?!? Oder sind die unsichtbar?

Gruß Moe

Hi Ralf,

danke, klingt ja sehr vielversprechend!
Ich muss dann wohl auf das nächste Paket warten…

Gruß Moe

Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

RalfBecker 2017-02-03 16:43:38 UTC #15

Hi Moe,

Hallo Ralf,

habe es gerade mal im Trial gestet … kanns bei mir wegen dem fehlenden
Paket ja noch nicht testen. funktionierte einwandfrei!
Sehr gute Arbeit!

Das einzige was mich verwunderte:
Als Pfad für die Uploads ist ja /home/Default eingestellt.
Dort liegt dann aber nix drin… ?!? Oder sind die unsichtbar?

Nein, da gab’ es noch einen Fehler, den ich heute morgen behoben habe.

Die Dateien wurden deswegen nicht unter /home/Default sondern in
/home//.tmp// gespeichert und sind nur für den
Benutzer selbst zu sehen

Nochmal per Git updaten oder das neue Maintenance Release 16.1.20170203
verwenden.
Unser Hosting ist natürlich inzwischen auch upgedated.

Ralf

Gruß Moe

Hi Ralf,

danke, klingt ja sehr vielversprechend!
Ich muss dann wohl auf das nächste Paket warten…

Gruß Moe

moe 2017-02-03 16:56:15 UTC #16

Hi Ralf,

Die Dateien wurden deswegen nicht unter /home/Default sondern in
/home//.tmp// gespeichert und sind nur für den
Benutzer selbst zu sehen

Nochmal per Git updaten oder das neue Maintenance Release 16.1.20170203
verwenden.
Unser Hosting ist natürlich inzwischen auch upgedated.
Habe vorhin gesehen, dass es ein neues Paket gibt. Werde kommende Woche
mal updaten und testen.

schönes WE!
Moe

Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german