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. ;((
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
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
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”
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.
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.
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).
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.
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 …
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.
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.
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.
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 …
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…
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…
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.
